Re: Sbuild doesn't pick experimental over unstable
* Daniel Stender deb...@danielstender.com, 2015-07-10, 09:32: for the upcoming transition of Libvigraimpex I want to test build some packages against the version in experimental (1.10.0) locally in a Sbuild chroot. The problem is, I can add experimental as extra repository (--extra-repository), but the dependency solver won't pick over the package in Sid and always pulls 1.9.0 [1]. Is this the way it's mend to work? At least, it's a know problem... Is there a way to cheat this? --build-dep-resolver=aptitude -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150710083434.ga4...@jwilk.net
Sbuild doesn't pick experimental over unstable
Hi, for the upcoming transition of Libvigraimpex I want to test build some packages against the version in experimental (1.10.0) locally in a Sbuild chroot. The problem is, I can add experimental as extra repository (--extra-repository), but the dependency solver won't pick over the package in Sid and always pulls 1.9.0 [1]. Is this the way it's mend to work? Is there a way to cheat this? Thanks Daniel Stender [1] http://paste.debian.net/280950/ -- http://www.danielstender.com/blog/ 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/559f7503.4070...@danielstender.com
Re: Sbuild doesn't pick experimental over unstable
Hi, Quoting Daniel Stender (2015-07-10 09:32:19) The problem is, I can add experimental as extra repository (--extra-repository), but the dependency solver won't pick over the package in Sid and always pulls 1.9.0 [1]. Is this the way it's mend to work? Is there a way to cheat this? the problem is, that the experimental repository has a Release file with NotAutomatic: yes which means that apt will assign a pin priority of 1 to it. The apt resolver will only consider the packages with the highest pin priority for the solution (unless you instruct it to do otherwise) so it will by default not consider packages coming from experimental. As jwilk already noted, one solution is to choose aptitude as a resolver. Since this seems to be a common problem, I wrote an entry in the sbuild Debian wiki about this. Please extend or correct where necessary: https://wiki.debian.org/sbuild#enabling_experimental For example it currently misses that you might also be able to use --extra-repository to temporarily enable experimental. If this indeed works, please add this as a solution. Another way to solve this would be to use apt with an external resolver like this: apt-get install --simulate --solver aspcud \ -o APT::Solver::Strict-Pinning=false \ -o APT::Solver::aspcud::Preferences=-new,-removed,-changed,+sum(solution,apt-pin) \ pkg-a This would also consider packages from experimental when installing pkg-a while at the same time find the solution with the most packages with a high pin value (ie. least packages from experimental). But this would of course require a change in sbuild and would probably not be desirable because an external resolver like aspcud would have to become part of the base chroot. See apt bug #786609 for some discussion about apt's behaviour with experimental. Thanks! cheers, josch signature.asc Description: signature
RE:Sbuild doesn't pick experimental over unstable
--build-dep-resolver=aptitude Is it possible to configure this per chroot in order to avoir passing this command line each time ? Thanks Frédéric -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2175...@sun-dag3.synchrotron-soleil.fr
RE:Sbuild doesn't pick experimental over unstable
Hi, Quoting PICCA Frederic-Emmanuel (2015-07-10 10:54:20) Is it possible to configure this per chroot in order to avoir passing this command line each time ? No. But if bug #790354 (with patch) gets resolved, then you will able to pass a custom configuration file which you can then use to set custom options and also select which chroot you want to use for building. So instead of choosing the chroot you want to build with, you would then choose the sbuildrc you want to use. cheers, josch signature.asc Description: signature
Re: how to migrate from experimental to unstable
Hello List thanks for your hints. On 28/04/15 22:57, Tobias Frost wrote: Am Montag, den 27.04.2015, 19:24 +0200 schrieb Mattia Rizzolo: On Mon, Apr 27, 2015 at 7:18 PM, Jerome BENOIT g62993...@rezozer.net wrote: Hello List, it sounds as a trivial question, but I cannot figure out any answer from Google: how can we push package in experimental to unstable ? upload them again to unstable with a greater version number than experimental's. Additionally, the changelog entry should read upload to unstable or like to avoid the lintian pendantic warning experimental-to-unstable-without-comment [1] [1] https://lintian.debian.org/tags/experimental-to-unstable-without-comment.html -- tobi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/553ff66a.8050...@rezozer.net
Re: how to migrate from experimental to unstable
Am Montag, den 27.04.2015, 19:24 +0200 schrieb Mattia Rizzolo: On Mon, Apr 27, 2015 at 7:18 PM, Jerome BENOIT g62993...@rezozer.net wrote: Hello List, it sounds as a trivial question, but I cannot figure out any answer from Google: how can we push package in experimental to unstable ? upload them again to unstable with a greater version number than experimental's. Additionally, the changelog entry should read upload to unstable or like to avoid the lintian pendantic warning experimental-to-unstable-without-comment [1] [1] https://lintian.debian.org/tags/experimental-to-unstable-without-comment.html -- tobi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1430254643.19860.14.ca...@debian.org
Re: how to migrate from experimental to unstable
On Mon, Apr 27, 2015 at 07:18:35PM +0200, Jerome BENOIT wrote: it sounds as a trivial question, but I cannot figure out any answer from Google: how can we push package in experimental to unstable ? By reuploading the package with a bumped version and targeting unstable. -- WBR, wRAR signature.asc Description: Digital signature
Re: how to migrate from experimental to unstable
On Mon, Apr 27, 2015 at 7:18 PM, Jerome BENOIT g62993...@rezozer.net wrote: Hello List, it sounds as a trivial question, but I cannot figure out any answer from Google: how can we push package in experimental to unstable ? upload them again to unstable with a greater version number than experimental's. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cahkymet8_7lnww1xmnazaocvhva0u1nddpxrdhxzuty2w8m...@mail.gmail.com
how to migrate from experimental to unstable
Hello List, it sounds as a trivial question, but I cannot figure out any answer from Google: how can we push package in experimental to unstable ? Thanks in advance, Jerome -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/553e6f6b.1080...@rezozer.net
Migrating from experimental to unstable
Suppose I have a new version of my package available and I upload it to experimental during a freeze. After the freeze I'd like that new version in unstable, but I haven't made any changes in the meantime. Is there a migration process from experimental to unstable, or is it normal to bump the debian revision (because the changelog should document the move between unstable and experimental and not hide that from history I guess) and upload a new version with no other changes? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130118214604.2d27aef1@tiber
Re: Migrating from experimental to unstable
Tony Houghton h...@realh.co.uk writes: Suppose I have a new version of my package available and I upload it to experimental during a freeze. After the freeze I'd like that new version in unstable, but I haven't made any changes in the meantime. Is there a migration process from experimental to unstable, or is it normal to bump the debian revision (because the changelog should document the move between unstable and experimental and not hide that from history I guess) and upload a new version with no other changes? It's normal to bump the Debian revision and to upload with a changelog entry that starts with: * Upload to unstable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871udima9j@windlord.stanford.edu
experimental or unstable
The last release of roxterm went to experimental instead of unstable. TBH I forgot that I'd changed it to experimental at some point, but after release I thought perhaps it's just as well because of the major changes. However, I think this has resulted in few users noticing the new version and I think it's reliable enough for unstable. There's a new release ready; should I switch back to unstable for it? You're probably thinking if I'm making a new release already it can't be that stable! But only one of the changes relates to something specific to roxterm 2, and it's to make a new feature optional rather than to fix a bug https://sourceforge.net/tracker/?func=detailaid=3365527group_id=124080atid=698431. It also closes a bug in previous unstable releases (#639687). -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110903163211.322e1742@tiber.centauri
Re: experimental or unstable
Hi, [...] You're probably thinking if I'm making a new release already it can't be that stable! But only one of the changes relates to something specific to roxterm 2, and it's to make a new feature optional rather than to fix a bug https://sourceforge.net/tracker/?func=detailaid=3365527group_id=124080atid=698431. It also closes a bug in previous unstable releases (#639687). It's in almost all cases completely up to you to decide whether a package is ready to go in unstable or not (and should go in experimental instead). Best, Michael pgpxAhRZNtpx4.pgp Description: PGP signature
Re: experimental or unstable
Hi! * Tony Houghton h...@realh.co.uk [110903 17:32]: There's a new release ready; should I switch back to unstable for it? Well, ask yourself this question: Do you think the upcoming release is fit to be part of a stable release? If the answer is yes upload to unstable. If the answer is No, but I'd like to have pacakges ready for testing anyway upload to experimental. Best Regards, Alexander -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110903190152.gb1...@melusine.alphascorpii.net
Re: experimental or unstable
On Sat, Sep 03, 2011 at 09:01:52PM +0200, Alexander Reichle-Schmehl wrote: * Tony Houghton h...@realh.co.uk [110903 17:32]: There's a new release ready; should I switch back to unstable for it? Well, ask yourself this question: Do you think the upcoming release is fit to be part of a stable release? If the answer is yes upload to unstable. If the answer is No, but I'd like to have pacakges ready for testing anyway upload to experimental. I kind of fail understand the logic here. If the changes are incremental and the releases are believed to work well, the only cost of multiple uploads is a bit of bandwidth and a bit of buildd time -- ie, machine work. And if you upload to experimental, that cost is paid anyway. On the other hand, it is a lot easier to fix problems if the changes come in smaller pieces. Plus, bugs introduced in the first piece will be reported earlier, giving a better chance they'll be fixed. So, shouldn't multiple uploads be discouraged only if they require unnecessary transitions or are of questionable quality? -- 1KB // Yo momma uses IPv4! -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110903221850.ga17...@angband.pl
