Bug#755029: transition: libkolabxml
Control: tags -1 confirmed On 17/07/14 00:53, Diane Trout wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > libkolabxml has a ABI change, this affects packages generated from it, > from libkolab, and from kdepim-runtime. Libkolab and libkolabxml will be > updated simultaneously. I don't see anything from kdepim-runtime depending on libkolabxml0. > The kde team is pushing for this transition because kdepim-runtime requires > the newer versions of libkolabxml and libkolab. Go ahead. Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c776e2.70...@debian.org
Processed: Re: Bug#755029: transition: libkolabxml
Processing control commands: > tags -1 confirmed Bug #755029 [release.debian.org] transition: libkolabxml Added tag(s) confirmed. -- 755029: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755029 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b755029.14055814069966.transcr...@bugs.debian.org
Bug#754981: marked as done (RM: rails-3.2/3.2.18-1)
Your message dated Thu, 17 Jul 2014 12:37:10 +0200 with message-id <53c7a756.2090...@debian.org> and subject line Re: Bug#754981: RM: rails-3.2/3.2.18-1 has caused the Debian Bug report #754981, regarding RM: rails-3.2/3.2.18-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 754981: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754981 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, we are aiming at having only latest rails (or no rails at all) package in next Debian stable. Please remove rails-3.2 and all packages further down the tree from testing, so we can first sort it out in unstable before leaving a mess in testing. O. - -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (900, 'stable'), (800, 'testing'), (700, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJTxo+xAAoJEAyZtw70/LsHN20QAISvQtzNSw3gLpRQlETyxB7R spVknbp+wNifvg8T1/RNZjEURWu5k8lRoDQDusRuT1+W6rfO4gsHq+H7xWrBDW+n mHGkFXOI1LVYku6yQ3JGlTsrXsSnjZdNRKULr5vz7pgO+4KV2cYbm0KmO8/HEgz0 TfX+9RgNjIAgJSSrFkPsWUmlDmfBT8CK3FDauVcsvXX5tge4M8vaghKtgWL0dVKt O2TguFeUthckVo8Lih2pqJu86KMm8Bbp+/USzs8kcn2oeDLNbbPSCBwnPUIyvekf TpbxjcoN1xgx3X/JQek1BbI1s0bxbH+WZLi4MGsCuZ/W0vOreeu7lPh0noUw3+wx Ia2YiiWvfTq4ZFZk/M2dFY5Pask03ST4QBL1gSNr5GWZllAHRDfS5Kx05y6epNfP x/sKtpTi0OUwq7zqHW9f2rqjjvPmHY7AlLXmLqMZ06fkWx02Ft4NGPRKsoOHGrId TOxWzx9Vo5FUeTeCMOhq0dDIA4o1X9S0ZErUNx7wbqK9Nb4+udeHu5r0mcCBOugl 5Y8rMmTvOlsiq0uJT1+T5eQY22EoELPxaoy2zpaGOdOJ4vTsfMIhBGxUjUsttk1y AxPeytolhNq/ubj2r41hzS8ifOtLW7vdbJx6p+DV/+pUyWzDv/BC9zHmHWKZ5Bbp ahyMWqsV1to+6ZcxPoaA =65FY -END PGP SIGNATURE- --- End Message --- --- Begin Message --- On 17/07/14 08:37, Ondřej Surý wrote: > > > On Wed, Jul 16, 2014, at 22:56, Emilio Pozuelo Monfort wrote: >> On 16/07/14 16:44, Ondřej Surý wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: rm >>> >>> Hi, >>> >>> we are aiming at having only latest rails (or no rails at all) >>> package in next Debian stable. >>> >>> Please remove rails-3.2 and all packages further down the tree >>> from testing, so we can first sort it out in unstable before >>> leaving a mess in testing. >> >> This is what dak says: >> > [...a quite a long list... ] >> >> I'm not sure we're supposed to drop rails (in addition to rails-3.2) > > Yes, please. > >> as well as things like ruby-haml, ruby-markerb, ruby-moneta... >> that seem unrelated to rails. > > rails-3.2 has now a RC bug - that stuff should be autoremoved anyway > in time, right? Removing this manually would just give the debian-ruby > time to fix this much faster (e.g. before freeze). > > I could probably walk through the packages and drop the > ruby-activesupport > (which is the most common case in the depends) dependency where > applicable (f.e. I seen haml Gemfile without any rails dependency). But > most of the packages really depend on some rails component. And I > don't simply believe that all those packages will "just work" with rails > 4.1, > it needs a test rebuild. > > I have discussed this on debian-ruby list before and no objections were > raised. And we must absolutely not ship jessie with rails-3.2 or we end > up in the same nightmare as in wheezy. I know it's a harsh move, but > no rails is better than obsolete rails with no security support from > upstream. Sure, I just wanted to make sure I wasn't removing stuff that was important. I have removed it now: #20140716 # #754981 remove rails-3.2/3.2.18-1 remove rails/2:3.2.13+1 redmine/2.5.1-2 redmine-plugin-pretend/0.0.2+git20130821-1 redmine-recaptcha/0.1.0+git20121018-3 ruby-activerecord-nulldb-adapter/0.3.1-1 ruby-acts-as-taggable-on/2.4.1-1 ruby-asset-sync/1.0.0-1 ruby-awesome-nested-set/2.1.6-1 ruby-bootstrap-sass/2.3.1.0-2 ruby-carrierwave/0.8.0-2 ruby-coffee-rails/3.2.2-2 ruby-email-validator/1.4.0-1 ruby-em-synchrony/1.0.3-1 ruby-factory-girl/4.4.0-1 ruby-factory-girl-rails/4.2.1-1 ruby-fixture-builder/0.3.6-1 ruby-foreigner/1.4.1-1 ruby-i18n-inflector-rails/1.0.7-1 ruby-jquery-rails/3.1.0-1 ruby-jquery-ui-rails/4.2.0-1 ruby-mobile-fu/1.3.1-1 ruby-origin/1.1.0-1 ruby-rabl/0.10.1-1 ruby-rabl-rails/0.3.4-1 ruby-rails-autolink/1.1.0-1 ruby-recaptcha/0.3.6
please binNMU rakudo against latest parrot
Hello rakudo is currently uninstallable on amd64 and needs to be re-built with the new version of parrot to fix this. nmu rakudo_2014.03.01-1 . amd64 . -m "rebuilt with parrot 6.3.0 (Closes: #749500)" Thanks -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org signature.asc Description: This is a digitally signed message part.
Re: Java 9 dropping support for source/target level 1.5
2014-07-16 22:32 GMT+02:00 Miguel Landaeta : > It's totally normal to have technical disagreements, especially on a > non-trivial packages like that one. What I really dislike is to > see epithets like "bullshit" or "own agenda" in a technical > discussion. > +1 -- Arnaud Vandyck http://about.me/avdyk
Bug#748535: transition: gnutls28
On 2014-07-12 Andreas Metzler wrote: >> there is another binnmu candidate: [...] some new ones: nmu gobby-infinote_0.4.94-6 . ALL . -m 'Rebuild against gnutls28' nmu pycurl_7.19.3.1-1 . ALL . -m 'Rebuild against gnutls28' nmu xbmc_2:13.1~rc1+dfsg1-1 . ALL . -m 'Rebuild against gnutls28' TIA. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140717163325.ga1...@downhill.g.la
Bug#748535: transition: gnutls28
On 17/07/14 18:33, Andreas Metzler wrote: > nmu gobby-infinote_0.4.94-6 . ALL . -m 'Rebuild against gnutls28' > nmu pycurl_7.19.3.1-1 . ALL . -m 'Rebuild against gnutls28' > nmu xbmc_2:13.1~rc1+dfsg1-1 . ALL . -m 'Rebuild against gnutls28' Scheduled. Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c7fe22.6050...@debian.org
libquazip transition
Hi, I see there's a transition for libquazip. I was going to schedule binNMUs for the rdeps, but the -dev package got renamed from libquazip0-dev to libquazip1-dev, but with the latter providing the former (I guess to allow binnmus). That won't work at least with freemedforms-project because that build depends on libquazip0-dev (>= 0.4.4). May I ask why the -dev package is versioned, instead of simply being libquazip-dev, as I think it should be? Can you fix freemedforms-project to build-depend on libquazip-dev or libquazip1-dev? Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c80705.6020...@debian.org
Re: please binNMU rakudo against latest parrot
On 17/07/14 13:36, Dominique Dumont wrote: > > Hello > > rakudo is currently uninstallable on amd64 and needs to be re-built > with the new version of parrot to fix this. > > nmu rakudo_2014.03.01-1 . amd64 . -m "rebuilt with parrot 6.3.0 (Closes: > #749500)" Done, on every arch (not just amd64). You will have to close the bug yourself, wanna-build won't do that for you. Cheers, Emilio P.S.: next time please file a bug (reportbug release.debian.org is easy) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c807aa.1030...@debian.org
Bug#755094: transition: harfbuzz
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Transition is due to upstream API change: replacement of 'hb_version_check' with 'hb_version_atleast'. The impacted source packages are: webkitgtk texlive-bin qtbase-opensource-src pango1.0 gnome-font-viewer libass chromium-browser libreoffice Ben file: title = "harfbuzz"; is_affected = .depends ~ "libharfbuzz0b" | .depends ~ "libharfbuzz0c"; is_good = .depends ~ "libharfbuzz0c"; is_bad = .depends ~ "libharfbuzz0b"; -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-30-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140717165628.5892.28025.reportbug@ants
Bug#755096: transition: postgresql-9.4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, we currently have PostgreSQL 9.3 in unstable/testing. PostgreSQL 9.4.0 will be releasing around September. 9.4~beta1 is already in experimental, and 9.4~beta2 will release next Thursday. Our plan is to upload this beta2 of postgresql-9.4 to unstable, and set the 9.4 as the only supported PostgreSQL version as per /usr/share/postgresql-common/supported-versions. postgresql-9.3 will stay in unstable (and testing) until all dependencies have been moved to 9.4. This is mostly just recompiling the extension module packages; most will adjust to the new version automatically. I've tested most of the "interesting" packages, most of them do not have any issues with 9.4. For a handful, fixes have already been made upstream, pending new releases, and some need some trivial debian/ updating. All in all, atm there is only one package (pg-reorg) which I know isn't 9.4-ready, and that's probably just a matter of pinging upstream (TBD). As with the other PostgreSQL server packages, we will provide new minor versions as upstream releases them, so jessie should be releasing with something like 9.4.2, which sounds like a nice target. I believe this transition should only require little (if any) release team attention (no group of packages should need to enter testing in parallel), though of course we'd like your opinion. Does this plan look sane? Ben file: title = "postgresql-9.4"; is_affected = .depends ~ /postgresql.*-9.[34].*/; is_good = .depends ~ /postgresql.*-9.4.*/; is_bad = .depends ~ /postgresql.*-9.3.*/; Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#755096: transition: postgresql-9.4
Re: To Debian Bug Tracking System 2014-07-17 <20140717181223.ga21...@msg.df7cb.de> > I've tested most of the "interesting" packages, most of them do not > have any issues with 9.4. For a handful, fixes have already been made > upstream, pending new releases, and some need some trivial debian/ > updating. All in all, atm there is only one package (pg-reorg) which I > know isn't 9.4-ready, and that's probably just a matter of pinging > upstream (TBD). I totally forgot to mention the wiki page that tracks this: https://wiki.debian.org/pkg-postgresql/migration94 Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#755029: transition: libkolabxml
> > I don't see anything from kdepim-runtime depending on libkolabxml0. It was a transitive dependency, I wasn't sure how far to chase reverse dependencies. This was my first time trying to declare a transition. Diane -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1554203.MIYxZV8se6@myrada
Bug#755096: transition: postgresql-9.4
Control: forwarded -1 https://release.debian.org/transitions/html/postgresql-9.4.html On 17/07/14 20:12, Christoph Berg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi, > > we currently have PostgreSQL 9.3 in unstable/testing. PostgreSQL 9.4.0 > will be releasing around September. 9.4~beta1 is already in > experimental, and 9.4~beta2 will release next Thursday. > > Our plan is to upload this beta2 of postgresql-9.4 to unstable, and > set the 9.4 as the only supported PostgreSQL version as per > /usr/share/postgresql-common/supported-versions. postgresql-9.3 will > stay in unstable (and testing) until all dependencies have been moved > to 9.4. This is mostly just recompiling the extension module packages; > most will adjust to the new version automatically. > > I've tested most of the "interesting" packages, most of them do not > have any issues with 9.4. For a handful, fixes have already been made > upstream, pending new releases, and some need some trivial debian/ > updating. All in all, atm there is only one package (pg-reorg) which I > know isn't 9.4-ready, and that's probably just a matter of pinging > upstream (TBD). > > As with the other PostgreSQL server packages, we will provide new > minor versions as upstream releases them, so jessie should be > releasing with something like 9.4.2, which sounds like a nice target. > > I believe this transition should only require little (if any) release > team attention (no group of packages should need to enter testing in > parallel), though of course we'd like your opinion. Does this plan > look sane? Does all the stuff that says "todo" on the wiki need major work? Do you think all/most of that can be switched to 9.4 by November? Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c8174f.5070...@debian.org
Processed: Re: Bug#755096: transition: postgresql-9.4
Processing control commands: > forwarded -1 https://release.debian.org/transitions/html/postgresql-9.4.html Bug #755096 [release.debian.org] transition: postgresql-9.4 Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/postgresql-9.4.html'. -- 755096: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755096 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b755096.140562210727338.transcr...@bugs.debian.org
Bug#755029: transition: libkolabxml
On 17/07/14 19:37, Diane Trout wrote: > >> >> I don't see anything from kdepim-runtime depending on libkolabxml0. > > It was a transitive dependency, I wasn't sure how far to chase reverse > dependencies. > > This was my first time trying to declare a transition. No worries, that just means it's even easier as it's libkolabxml and libkolab. Please go ahead. Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c817cd.4070...@debian.org
Bug#755096: transition: postgresql-9.4
Re: Emilio Pozuelo Monfort 2014-07-17 <53c8174f.5070...@debian.org> > Does all the stuff that says "todo" on the wiki need major work? That means there's a slight chance the package might get confused by catalog changes in the new server, though there's been little change in that area that should be of interest to client applications. I've tested the packages I expect to be most likely affected, the remaining "todo" ones are mostly the ones I wouldn't expect to have troubles. That said, I need to try more of the "lib" packages. > Do you think all/most of that can be switched to 9.4 by November? Yes. In fact I expect the "formal" part of the transition (the packages that depend on 9.3) to be done until September. The rest is testing libs like jdbc that read half of the system catalog on connect will continue to work. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#753781: Heads up: transition: xserver 1.16
Thanks. I've checked that xserver-xorg-video-nv (non-free, meant for kfreebsd systems) still builds OK with xorg-video-abi-18, xserver-xorg-core (>= 2:1.15.99.903). I don't have hardware available to test it with unfortunately. I can confirm that xserver-xorg-video-nv works under kfreebsd-amd64: NVIDIA Corporation G73 [GeForce 7300 GT] (rev a1) xrandr -q Screen 0: minimum 640 x 400, current 1920 x 1080, maximum 1920 x 1080 default connected 1920x1080+0+0 0mm x 0mm ii xserver-xorg-core 2:1.15.99.904-1 ii xserver-xorg-dev 2:1.15.99.904-1 It remains to upload it into unstable by some DD. Cheers Petr -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.lnx.2.00.1407172103500.15...@contest.felk.cvut.cz
Bug#755096: transition: postgresql-9.4
Control: tags -1 confirmed On 17/07/14 20:47, Christoph Berg wrote: > Re: Emilio Pozuelo Monfort 2014-07-17 <53c8174f.5070...@debian.org> >> Does all the stuff that says "todo" on the wiki need major work? > > That means there's a slight chance the package might get confused by > catalog changes in the new server, though there's been little change > in that area that should be of interest to client applications. > > I've tested the packages I expect to be most likely affected, the > remaining "todo" ones are mostly the ones I wouldn't expect to have > troubles. That said, I need to try more of the "lib" packages. > >> Do you think all/most of that can be switched to 9.4 by November? > > Yes. In fact I expect the "formal" part of the transition (the > packages that depend on 9.3) to be done until September. The rest is > testing libs like jdbc that read half of the system catalog on connect > will continue to work. Sounds good! Since packages can migrate one by one as you explained, feel free to upload whenever you're ready. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c8264b.7060...@debian.org
Processed: Re: Bug#755096: transition: postgresql-9.4
Processing control commands: > tags -1 confirmed Bug #755096 [release.debian.org] transition: postgresql-9.4 Added tag(s) confirmed. -- 755096: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755096 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b755096.140562594318873.transcr...@bugs.debian.org
Bug#755096: transition: postgresql-9.4
Re: Emilio Pozuelo Monfort 2014-07-17 <53c8264b.7060...@debian.org> > Sounds good! Since packages can migrate one by one as you explained, feel free > to upload whenever you're ready. Thanks. Fwiw, I think the ben file needs "9." changed to "9\." Atm it is picking up some git commitish version number in the haskell-persistent-postgresql dependencies or something like that. Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140717194258.gd4...@msg.df7cb.de
Bug#753529: transition: perl 5.20
On Wed, Jul 16, 2014 at 05:04:31PM +0200, Emilio Pozuelo Monfort wrote: > On 15/07/14 21:28, Niko Tyni wrote: > > There are currently about 40 bugs open with a patch. I don't expect the > > count to go down much without an NMU campaign, so we should probably > > start one. > > Since we're going to do this transition before Jessie and those bugs will > become > RC bugs when perl is uploaded in a few days, I think you can act as if they > were > RC already and do NMUs to DELAYED. Otherwise this is a vicious circle as I > don't > want perl uploaded with 40 bugs in the archive, and you can't fix those until > perl is uploaded because they aren't RC bugs until then... :-) Thanks for the note. I've started with ossp-uuid. We're currently aiming for a sid upload on August 12th or so, but will check the status in a couple of weeks (late July) to see if the open bug count allows that. If it doesn't, the transition will probably need to be postponed until September (read: after DebConf.) I've just filed half a dozen new perl-5.20-transition bugs but I hope those are just about the last ones to crop up. Help with patches / NMUs is very welcome! https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.20-transition;users=debian-p...@lists.debian.org -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140717210150.GA13478@estella.local.invalid
Re: How would you use britney for Kali and are generalization patches welcome?
On 2014-07-16 23:57, Niels Thykier wrote: > On 2014-07-16 15:48, Raphael Hertzog wrote: >> Hello britney maintainers, >> > > Hi, :) > > [...] > > Short-term options include: > * patch Britney reject on first new uninstallable >- something like the attached patch, which /vastly/ reduces the > runtime of testing libtext-iconv-perl >- downside: you have less to go on when she reports "migrating A > breaks B", because you only get one "broken" package (which > possibly is broken indirectly) > [...] > > ~Niels > Hi again, With my patch proposed, I have run your dataset and the full run completed after about 1h and 15minutes. After that the auto-hinters start up. The main run completes with: """ start: 96+0: i-43:a-26:a-13:a-14 orig: 96+0: i-43:a-26:a-13:a-14 end: 49+0: i-17:a-9:a-11:a-12 SUCCESS (16353/9260) """ Which is "Britney-ish" for 7093 "items" migrated, 9260 items failed to migrated despite being valid candidates[1] and the number of uninstallable packages dropped from 96 to 49. The auto-hinter then takes a couple of minor hints followed by a "mega hint" (containing 8464 items). It remains to be seen if that hint will work or not, but keep in mind that my patch does not affect hints so it could be stuck here (sadly). I suspect it to be stuck though, so I suggest you patch out the auto-hinters for now. If time permits, I will play around with this a bit more and see if I cannot come up with a decent solution. ~Niels [1] The auto-hinters will take care of some of those. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c83b97.60...@thykier.net
Re: libquazip transition
Le 17/07/2014 19:25, Emilio Pozuelo Monfort a écrit : > Hi, > > I see there's a transition for libquazip. I was going to schedule binNMUs for > the rdeps, but the -dev package got renamed from libquazip0-dev to > libquazip1-dev, but with the latter providing the former (I guess to allow > binnmus). That won't work at least with freemedforms-project because that > build > depends on libquazip0-dev (>= 0.4.4). libquazip1-dev provides libquazip0-dev so build dependencies should be ok. Anyway, you are right, I need to correct the freemedforms-project source package. I'll correct this dependency in the current package. > May I ask why the -dev package is versioned, instead of simply being > libquazip-dev, as I think it should be? As the ABI version of libquazip has a possibility to evolve, I choose to include the so version in the package name. This is also a recommandation I've found in the documentation of shared libraries packaging. > Can you fix freemedforms-project to build-depend on libquazip-dev or > libquazip1-dev? Fixed on the debian med svn. -- Eric Maeker GPG: C217 B1B7 80E8 0381 FD5B C3A5 75D4 AE85 B952 0933 signature.asc Description: OpenPGP digital signature
Bug#748535: transition: gnutls28
> On 17/07/14 18:33, Andreas Metzler wrote: >> nmu xbmc_2:13.1~rc1+dfsg1-1 . ALL . -m 'Rebuild against gnutls28' That one failed everywhere. I have opened a serious bug for it. Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c852a7.5020...@debian.org
Re: libquazip transition
On Thu, Jul 17, 2014 at 23:35:55 +0200, Eric Maeker wrote: > Le 17/07/2014 19:25, Emilio Pozuelo Monfort a écrit : > > May I ask why the -dev package is versioned, instead of simply being > > libquazip-dev, as I think it should be? > > As the ABI version of libquazip has a possibility to evolve, I choose to > include the so version in the package name. This is also a > recommandation I've found in the documentation of shared libraries > packaging. > That's a bug in said documentation. -dev package names should only include a version if you intend to ship several versions for an extended period of time. Cheers, Julien signature.asc Description: Digital signature
Bug#755096: transition: postgresql-9.4
On Thu, Jul 17, 2014 at 22:42:59 +0300, Christoph Berg wrote: > Fwiw, I think the ben file needs "9." changed to "9\." Atm it is picking > up some git commitish version number in the haskell-persistent-postgresql > dependencies or something like that. > Fixed, thanks. Cheers, Julien signature.asc Description: Digital signature
Re: libquazip transition
Le 18 juil. 2014 à 01:01, Julien Cristau a écrit : > On Thu, Jul 17, 2014 at 23:35:55 +0200, Eric Maeker wrote: > >> Le 17/07/2014 19:25, Emilio Pozuelo Monfort a écrit : >>> May I ask why the -dev package is versioned, instead of simply being >>> libquazip-dev, as I think it should be? >> >> As the ABI version of libquazip has a possibility to evolve, I choose to >> include the so version in the package name. This is also a >> recommandation I've found in the documentation of shared libraries >> packaging. > That's a bug in said documentation. -dev package names should only > include a version if you intend to ship several versions for an extended > period of time. Thanks for your review and comment. You are right the version of -dev package is only required if maintener intend to ship multiple version of the ABI. There aren t any bug in the doc (see 8.4) https://www.debian.org/doc/debian-policy/ch-sharedlibs.html How can we be certain about multiple ABI. Should I ask upstream? Or is that a ´debian only decision´? > Cheers, > Julien Thanks Éric
