| Message ID | f76a2547-3d80-284e-269a-fe3d4fdd072b@gmail.com |
|---|---|
| Headers | show |
Vincent, Thanks! According to this comment in the netpbm package, ‘advanced’ was not the prime choice: ;; At the time of first packaging, the "super-stable" and ;; "stable" versions did not compile with newer libpng; ;; we needed the "advanced" version. ;; The currently highest stable version is 10.47.53, ;; the currently highest advanced version is 10.69.4, ;; svn release 2397. Stable has moved up quite a bit, to 10.86.13. Could you try building it first? Vincent Legoll 写道： > There's something strange (to me) happening with the netpbm > update, > probably related to svn-fetch. > > The hash did not change for the version update. You're still asking Guix to fetch and build the old revision, since you only changed the VERSION field. The source isn't affected by that variable: (uri (svn-reference (url "http://svn.code.sf.net/p/netpbm/code/advanced") (revision 2965))) You can find the corresponding SVN revision on the release page[0] or: ;; To determine the correct release: "svn log version.mk". Kind regards, T G-R [0]: https://sourceforge.net/p/netpbm/code/HEAD/tree/ PS: I updated haproxy on master already.
Hello Tobias, On 26/05/2020 00:45, Tobias Geerinckx-Rice wrote: > Vincent, > > Thanks! According to this comment in the netpbm package, ‘advanced’ was > not the prime choice: > > ;; At the time of first packaging, the "super-stable" and > ;; "stable" versions did not compile with newer libpng; > ;; we needed the "advanced" version. > ;; The currently highest stable version is 10.47.53, > ;; the currently highest advanced version is 10.69.4, > ;; svn release 2397. D'oh, I think I had my eyes closed when doing this last one... > Stable has moved up quite a bit, to 10.86.13. Could you try building it > first? I tried but it does not build as-is, there's a problem with a patch not applying any more. I'll have a look tomorrow, now is time for some zzz. > PS: I updated haproxy on master already. Grrr, I think I git pulled just before you pushed... Hopefully the remaining ones are still useful. Thanks for the eye-opener
On Mon, May 25, 2020 at 11:56:25PM +0200, Vincent Legoll wrote: > Here is the update series to celebrate our come back to repology. > > They are only build-tested, though. > > All should have few dependents, and even ffmpeg could go to master. I pushed the FFmpeg update. In general, it's hard to decide what to do with this bug ticket, since some of the patches can't be pushed to master. Should we close it? Leave it open? I think the best move is to split the patches into their own bug ticket.
On 26/05/2020 19:56, Leo Famulari wrote: > In general, it's hard to decide what to do with this bug ticket, since > some of the patches can't be pushed to master. Should we close it? Leave > it open? I think the best move is to split the patches into their own > bug ticket. All the patches are independent, I just did them all in a series to minimize the email churn. I was thinking committer(s) would cherry-pick the ready ones (all but haproxy (already done by Tobias), netpbm & mupdf). Just tell me what you prefer.
Vincent,
Vincent Legoll 写道：
> Hopefully the remaining ones are still useful.
Yup! Took about a day to rebuild all ffmpeg dependents by which
time it had alread been merged. I've pushed the 6 other
straightforward-looking ones to master.
Don't hesitate do submit these as separate bugs next time, but
there's nothing wrong with this format so long as you keep track
of which packages have(n't) been merged.
Kind regards,
T G-R
Hello Tobias, On 27/05/2020 04:02, Tobias Geerinckx-Rice wrote: > Vincent Legoll 写道： >> Hopefully the remaining ones are still useful. > > Yup! Took about a day to rebuild all ffmpeg dependents by which > time it had alread been merged. :-) > I've pushed the 6 other straightforward-looking ones to master. Thanks, if I keep doing such independent series, I'll order them by growing number of dependents, hoping it'll help a bit... > Don't hesitate do submit these as separate bugs next time, but there's > nothing wrong with this format so long as you keep track of which > packages have(n't) been merged. OK, I think I'll go to separate issues next time, as it's not a lot more work, and should avoid having to track the series status. But that was only a quick'n'dirty return to package updates, I have a guix-installer.sh to take care of...
On Wed, May 27, 2020 at 04:02:34AM +0200, Tobias Geerinckx-Rice via Guix-patches via wrote: > Yup! Took about a day to rebuild all ffmpeg dependents by which time it had > alread been merged. I've pushed the 6 other straightforward-looking ones to > master. Sorry, I didn't realize you were doing that! I find that FFmpeg updates work reliably so I usually just test VLC and MPV before pushing.
Leo, Leo Famulari 写道： > Sorry, I didn't realize you were doing that! No worries! I didn't announce it anywhere. Just made sense to rebuild [the dependents of] the whole series. > I find that FFmpeg updates work reliably so I usually just test > VLC > and MPV before pushing. Thanks for the tip. Kind regards, T G-R
Let's close this issue, as I won't be working on mupdf or netpbm any time soon, they're still on the TODO, but are a bit buried. And I would use separate issues anyways if resuming work on them.