Bug#1024540: transition: libpinyin
On 2022-11-21 20:46, Sebastian Ramacher wrote: Please go ahead after filing the bug against malitt-keyboard. Ok. * maliit-keyboard bug: https://bugs.debian.org/1024593 * libpinyin 2.7.92-2 uploaded to unstable
Bug#1023495: transition: ruby3.1
Hi, We have been performing the rebuilds and fixing packages for a while, you can see the results of our last test rebuild (from the beginning of this month) here: https://people.debian.org/~kanashiro/ruby3.1 Some package listed as build failures were actually fixed already. From the list we have in the transition tracker: https://release.debian.org/transitions/html/ruby3.1-default.html Apart from the packages not in testing, only 2 packages are failing to build in the first dependency level: - dislocker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024589 . This one seems unrelated to this transition. - uwsgi: this needs a trivial patch in d/control to replace 3.0 with 3.1 in the uwsgi-plugin-rack-ruby3.0 binary name. This will be done once ruby3.1 becomes the default in unstable. All the others seem good to go. With that in mind, we would like to ask the Release Team if we can start the transition in unstable and change the default to 3.1. TIA! -- Lucas Kanashiro
Bug#1023731: BioC Transition blocked by new dependencies
Hi Nilesh, Le lun. 21 nov. 2022 à 18:29, Nilesh Patra a écrit : > > Lastly I also want to higlight that: while bioc transition is in theory a > transition (I agree) > but to my understanding, there is no _real_ API change. It is just the tool > taking the > API field from DESCRIPTION file into consideration, and causing FTBFS if it > does not match. > > In principle, building a package that has an older API value in DESCRIPTION > file with the newer > one does not break anything, it rather looks as updates of various packages > disguised as an API > change, and at least in debian land, to me it just appears as a broken tool > config and not a real > transition (like library transition, for example the recent onetbb one). > Before having this r-api-bioc virtual package, transitions were even worse. We had a lot of autopkgtest issues only because a mix of r-bioc pkgs installed from the old and from the new bioconductor releases. Issues which solved by themselves when the transition is over and of course, users were complaining about broken packages during the transition. We were losing a lot of time to investigate these issues. With this r-api-bioc mechanism, we don't allow this mixture of r-bioc pkgs and thus we limit these temporary issues. Adding this r-api-bioc virtual package has another consequence, now we can take advantage of the transition tracker and upload packages following levels. Before the order of the uploads were a bit random and again we lose of lot of time to figure out in which order we have to update them. Best, Dylan
Bug#1024588: marked as done (genomicsdb needs hinting into testing)
Your message dated Mon, 21 Nov 2022 21:38:36 +0100 with message-id and subject line Re: Bug#1024588: genomicsdb needs hinting into testing has caused the Debian Bug report #1024588, regarding genomicsdb needs hinting into testing 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.) -- 1024588: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024588 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal binary-any + binary-all, but binary-any does not build on most architectures. This results in autopkgtest failure due to missing binaries on the architectures without binaries where autopkgtest is anyway run due to the binary-all. --- End Message --- --- Begin Message --- Hi, On 21-11-2022 21:05, Adrian Bunk wrote: binary-any + binary-all, but binary-any does not build on most architectures. This results in autopkgtest failure due to missing binaries on the architectures without binaries where autopkgtest is anyway run due to the binary-all. Hint added, thanks. Paul OpenPGP_signature Description: OpenPGP digital signature --- End Message ---
Re: Bug#983912: grub2: consider renaming signed source packages to grub2-signed-*
On Sun, 20 Nov 2022, Salvatore Bonaccorso wrote: On Wed, Mar 03, 2021 at 10:52:39AM +0100, Ansgar wrote: Source: grub2 Version: 2.04-16 Severity: normal X-Debbugs-Cc: ftpmas...@debian.org, debian-release@lists.debian.org grub2 currently uses grub-efi-signed-* as source package names for the Secure Boot signed packages. While releasing the last security update we found a small issue with these names: dak processes source packages in lexiographic order, so it would process grub-efi-signed-* before grub2 when accepting all packages at once from the "embargoed" policy queue. But the grub-efi-signed-* binary packages have Built-Using: grub2; as grub2 is not accepted from embargoed at this point in time, the /binary/ uploads will be rejected in this case. (This problem exists in principle with all Built-Using relations.) How hard would it be to enhance dak to not require any specific ordering? One way could be to process the same list repeatedly, until no additional packages have been accepted for an entire pass. Regards, Anne Bezemer
Bug#1024588: genomicsdb needs hinting into testing
Package: release.debian.org Severity: normal binary-any + binary-all, but binary-any does not build on most architectures. This results in autopkgtest failure due to missing binaries on the architectures without binaries where autopkgtest is anyway run due to the binary-all.
Processed: Re: Bug#1024540: transition: libpinyin
Processing control commands: > tags -1 confirmed Bug #1024540 [release.debian.org] transition: libpinyin Added tag(s) confirmed. -- 1024540: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024540 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1024540: transition: libpinyin
Control: tags -1 confirmed On 2022-11-21 08:03:26 +0100, Gunnar Hjalmarsson wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-input-met...@lists.debian.org > > Hello Release Team, > > libpinyin upstream made a SOVERSION bump from 13 to 15, and the Debian > packaging has been changed accordingly in libpinyin 2.7.92-1 in > experimental. These are the packages affected by the transition: > > fcitx-libpinyin > fcitx5-zhuyin > ibus-libpinyin > ibus-libzhuyin > maliit-keyboard > > I have changed the sources as appropriate and successfully test built the > packages against the new libpinyin. > > As regards maliit-keyboard I plan to ping the maintainer (aka submit a bug) > and possibly do an NMU. The other affected packages are maintained by > Debian's IME team, and as a team member I plan to upload them myself. > > The autogenerated ben tracker looks as expected: > > https://release.debian.org/transitions/html/auto-libpinyin.html > > Please consider libpinyin for transition. Please go ahead after filing the bug against malitt-keyboard. Cheers -- Sebastian Ramacher
Bug#1023535: transition: protobuf
Control: tags -1 = confirmed On 2022-11-10 23:10:29 +0100, Sebastian Ramacher wrote: > Control: block -1 by 1022248 1018945 > > On 2022-11-06 09:08:57 +0100, László Böszörményi wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi RMs, > > > > There's a long awaited transition of Protobuf. It clashes with the > > ruby3.1-default transition, but as I know its rebuilds are just > > starting[1]. > > On the other hand I'm done with the rebuilds and patched all issues, > > this transition may start immediately at your decision. The only > > downside is that the Sid version of cura-engine is FTBFS and to fix > > it, the libarcus transition (only affecting this package) will need to > > be done. > > > > Failing packages and fixes in detail. > > Level 2: > > android-platform-frameworks-base has my patch already applied [2] for > > experimental (not Sid!). > > libarcus builds in Sid, but not the version in experimental for which > > I provided a fix [3]. > > target-factory changed library symbols [4], maintainer will need to update > > that. > > > > Level 3: > > cura-engine fails with the Sid version [5], with the libarcus > > transition done it compiles fine. > > grpc-java for which I provided the fix [6], the maintainer noted he > > will be ready to update the package. > > llvm-toolchain-13 for which I provided the fix [7], other problems > > seem to be fixed with the upload just happened. > > llvm-toolchain-14 for which I also provided the fix [8], its other > > problem [9] might be wrongly closed by cross referenced > > llvm-toolchain-15 package - but Sylvestre Ledru seems to be aware of > > issues anyway. > > Let's wait until icu and libbpf are done. Please go ahead Cheers > > Cheers > > > > > Thanks for considering, > > Laszlo/GCS > > [1] https://bugs.debian.org/1023495#5 > > [2] https://bugs.debian.org/1012572 > > [3] https://bugs.debian.org/1023497 > > [4] https://bugs.debian.org/1023496 > > [5] https://bugs.debian.org/1023498 > > [6] https://bugs.debian.org/1023500 > > [7] https://bugs.debian.org/1023532 > > [8] https://bugs.debian.org/1023532 > > [9] https://bugs.debian.org/1023444 > > > > -- > Sebastian Ramacher > -- Sebastian Ramacher
Processed: Re: Bug#1023535: transition: protobuf
Processing control commands: > tags -1 = confirmed Bug #1023535 [release.debian.org] transition: protobuf Added tag(s) confirmed. -- 1023535: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023535 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1024027: marked as done (transition: ros-class-loader)
Your message dated Mon, 21 Nov 2022 20:27:46 +0100 with message-id and subject line Re: Bug#1024027: transition: ros-class-loader has caused the Debian Bug report #1024027, regarding transition: ros-class-loader 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.) -- 1024027: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024027 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: transition Hi release team, I would like to transition the new ros-class-loader. The auto generated ben file seems fine and I've rebuild all listed packages successfully. Cheers Jochen --- End Message --- --- Begin Message --- On 2022-11-15 00:35:06 +0100, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > Hi Jochen > > On 2022-11-14 12:47:05 +0100, Jochen Sprickerhof wrote: > > Control: tags -1 - moreinfo > > > > Hi Sebastian, > > > > > On 2022-11-13 21:51:03 +0100, Jochen Sprickerhof wrote: > > > > Package: release.debian.org > > > > Severity: normal > > > > User: release.debian@packages.debian.org > > > > Usertags: transition > > > > > > > > Hi release team, > > > > > > > > I would like to transition the new ros-class-loader. The auto generated > > > > ben file seems fine and I've rebuild all listed packages successfully. > > > > > > ros2-rcpputils with a SONAME bump also prepared in experimental. Can we > > > do those two at the same time? > > > > Yes, the auto generated ben file for both look fine and I've rebuild all > > listed packages successfully. > > Please go ahead with both. The old binaries of both packages got removed. Closing. Cheers -- Sebastian Ramacher--- End Message ---
Bug#1023955: marked as done (transition: rocksdb)
Your message dated Mon, 21 Nov 2022 20:27:08 +0100 with message-id and subject line Re: Bug#1023955: transition: rocksdb has caused the Debian Bug report #1023955, regarding transition: rocksdb 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.) -- 1023955: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023955 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: transition Hi RMs, Simple transition of RocksDB to version 7.7.3 as only balboa is affected. It builds fine with the new RocksDB version in experimental as well. I think it may start immediately, but it's your decision of course. Regards, Laszlo/GCS --- End Message --- --- Begin Message --- On 2022-11-13 15:59:36 +0100, László Böszörményi wrote: > On Sun, Nov 13, 2022 at 1:54 PM Sebastian Ramacher > wrote: > > It doesn't conflict with any other ongoing transitions, so please go > > ahead. > Thanks, uploaded. The old binaries got removed. Closing. Cheers -- Sebastian Ramacher--- End Message ---
Bug#1023846: transition: gdal
On 11/20/22 20:19, Sebastiaan Couwenberg wrote: On 11/19/22 20:18, Sebastian Ramacher wrote: On 2022-11-11 11:55:45 +0100, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 1023480 1023506 1004795 998833 984398 1023520 1012950 For the Debian GIS team I'd like to transition to GDAL 3.6.0. Please go ahead > Thanks. gdal (3.6.0+dfsg-2) has been uploaded to unstable and took a while to get built on s390x, but is not built & installed on all release architectures. grass is built & installed on all release architectures, libgdal-grass can be binNMUed. qgis had a source upload to fix the FTBFS with python3.11 and cmake 3.25. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1022248: marked as done (transition: icu)
Your message dated Mon, 21 Nov 2022 19:43:08 +0100 with message-id and subject line Re: Bug#1022248: transition: icu has caused the Debian Bug report #1022248, regarding transition: icu 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.) -- 1022248: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022248 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: transition Hi RMs, My intention is to release Bookworm with ICU 72.1 which is already packaged and is in experimental. As Sid has the previous,71.1 release the transition is plain, I don't expect any breakage. The rebuilds are ongoing and only level1 and level2 are ready at this time. Transition is similar to the previous ones, this time boost1.74 needs to be binNMUed after level1 before other level2 packages and pyicu will need a sourceful upload (its Git version seems to be ready, but I wait for its release). The only FTBFS is from the Sid version of nodejs (18.10.0+dfsg-6) due to a flaky self-test - its experimental version (18.11.0+dfsg-3) doesn't suffer from it. I will post more when I build all levels of the transition. Regards, Laszlo/GCS --- End Message --- --- Begin Message --- On 2022-11-21 19:20:39 +0100, László Böszörményi (GCS) wrote: > On Tue, Nov 8, 2022 at 2:00 AM Sebastian Ramacher > wrote: > > On 2022-10-30 14:08:55 +0100, László Böszörményi wrote: > > > Package 0ad and gnucash fail to build [1][2] with ICU 72.1 and bugs are > > > filed. > > > Package supercollider failed to build due to another issue [3]. Its > > > packaging Git has a working fix and after applying that it was built > > > with ICU 72.1 as well. > > > > Alright, please go ahead. > Friendly ping on what needs to be done for this transition? ICU > itself migrated to testing more than a week ago. Thunderbird, the last > reverse dependency needed for this transition, just migrated. Other > reverse dependencies are already Sid only. How can I check what's > still missing? With thunderbird migrated, the old binaries got removed from testing. So this transition is done. Cheers -- Sebastian Ramacher--- End Message ---
Bug#1022248: transition: icu
On Tue, Nov 8, 2022 at 2:00 AM Sebastian Ramacher wrote: > On 2022-10-30 14:08:55 +0100, László Böszörményi wrote: > > Package 0ad and gnucash fail to build [1][2] with ICU 72.1 and bugs are > > filed. > > Package supercollider failed to build due to another issue [3]. Its > > packaging Git has a working fix and after applying that it was built > > with ICU 72.1 as well. > > Alright, please go ahead. Friendly ping on what needs to be done for this transition? ICU itself migrated to testing more than a week ago. Thunderbird, the last reverse dependency needed for this transition, just migrated. Other reverse dependencies are already Sid only. How can I check what's still missing? Thanks, Laszlo/GCS
Bug#1023731: BioC Transition blocked by new dependencies
On 2022-11-21 16:39:26 +0100, Andreas Tille wrote: > Hi Sebastian, > > Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher: > > On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: > > > Control: block -1 by 1024563 > > > Control: block -1 by 1024565 > > > Control: block -1 by 1024567 > > > > > > Some of the BioConductor packages need new dependencies. > > > I have pushed these to new queue and set the ITP bugs as > > > blocker. > > > > As this is happening every r-bioc transition, could this be handled > > before starting the transition the next time? > > This is really hard to do, thought. The new packages are needing those > packages from the transition. I actually injected two packages from > higher levels manually to be able to build one of the new packages. So > we really need to upload the start of the transition and I do not see > any sense in not documenting what we are doing without the transition > tracker. Others have already answered this part. > However, to make us understand your suggestion better: Is there any > drawback on your side if the transition of a closed set of packages if > the transition is delayed by new processing? Some packages are also involved in other transitions. For example, currently a hdf5 transition is prepared in experimental. While we could now also start the hdf5 transition, completing hdf5 would not be possible until this one is done. Now replace the hdf5 transition with another lock-step transition such as this one. Then we suddenly have two set of packages that can only migrate together. Especially for lock-step transition a quick turn around is thus greatly appreciated. I will remember for the next time that I'll ask you to stage everything in experimental or to give me a list of packages that require NEW dependencies so that we can get those removed early in the transition to not hold of the transition by NEW delay. Cheers -- Sebastian Ramacher
Bug#1023550: transition: qcustomplot
Hi Filippo On 2022-11-21 09:58:08 +0100, Filippo Rusconi wrote: > > > > > For the libs under my control, the transition is already prepared and > > > > > these > > > > > projects are going to be linking against the Qt6-built library, > > > > > contrary to all > > > > > the other packages detailed below. > > > > > > > > > > For the other libs listed above, I have already checked that they > > > > > would build if > > > > > some modifications were performed. I have already git branches ready > > > > > for the > > > > > packages under git VCS. For the others (source deb), I have patches > > > > > available. > > > > > > > > > > The modifications are lean: change -lqcustomplot to -lQCustomPlot for > > > > > many and > > > > > also sometimes use the CMake-based configuration involving first > > > > > find_package(QCustomPlot) and second the QCustomPlot::QCustomPlot > > > > > formalism for > > > > > the linker. > > > > > > > > > > That is: almost one- or two-liner patches. > > > > > > > > Could you please file bugs for those so that maintainers are aware? > > > > > > Yes, I'll do that. I have already informed them individually of the > > > process and > > > provided them with the relevant patch. > > > > Thanks! Please go ahead with the transition. > > I'm sorry, what should I do? Shall I upload the package to unstable? Yes, please upload the package to unstable to start the transition. Cheers -- Sebastian Ramacher
Bug#1023731: BioC Transition blocked by new dependencies
On Mon, Nov 21, 2022 at 06:11:41PM +0100, Andreas Tille wrote: > Hi Adrian and others, > > Am Mon, Nov 21, 2022 at 06:33:52PM +0200 schrieb Adrian Bunk: > > > This is really hard to do, thought. The new packages are needing those > > > packages from the transition. I actually injected two packages from > > > higher levels manually to be able to build one of the new packages. So > > > we really need to upload the start of the transition and I do not see > > > any sense in not documenting what we are doing without the transition > > > tracker. > > >... > > > > Your transition is special because you are manually uploading every > > single package involved in the transition. > > > > You could upload everything to experimental, run a local ben tracker > > against experimental, and when the transition is complete in > > experimental contact the release team for the transition in unstable. > > > > The actual transition is then a batch of "Upload to unstable". > > Thanks for all helpful hints. I understand that with some effort over > the current workflow it is possible to do the transition differently. > The only thing which I did not yet understood is the actual drawback of > the current workflow. I do not think that it takes specifically longer > than other transition - we just have a different set of showstoppers to > get it done in 24 hours. Personal experience+opinion: I have been involved with quite a few bioc transitions and often times you and me were the _only_ people who did the entire transition. I have noticed several times that the NEW processing takes quite sometime, and the way forward (for me) has been to manually patch the DESCRIPTION file to patch it to be compatible with new r-bioc api until the dependency from new is accepted. The new processing time tends to create delay with respect to bioc packages migrating to testing and this creats a terrible amount of noise. And then what comes next is a bunch of workarounds to get things moving, and this takes a quite a lot of energy at my end which I'd like to spend somewhere else. I have not been entirely happy with the way it happens, and would like if we can do the transition differently with less friction, less days of wide-uninstallability. The advantage with a reprepo thing that Sebastian suggests is that everything (possibly) will migrate as soon as it is uploaded. Once you have stored the sources into a reprepo, all you need to do is run a script to do all the uploads. > In the past we got support by ftpmaster when > pinging them and explaining the transition issue. Which takes time as well, and at least my experience regarding transition new processing has not been quite same as you. Lastly I also want to higlight that: while bioc transition is in theory a transition (I agree) but to my understanding, there is no _real_ API change. It is just the tool taking the API field from DESCRIPTION file into consideration, and causing FTBFS if it does not match. In principle, building a package that has an older API value in DESCRIPTION file with the newer one does not break anything, it rather looks as updates of various packages disguised as an API change, and at least in debian land, to me it just appears as a broken tool config and not a real transition (like library transition, for example the recent onetbb one). -- Best, Nilesh signature.asc Description: PGP signature
Bug#1023731: BioC Transition blocked by new dependencies
Hi Adrian and others, Am Mon, Nov 21, 2022 at 06:33:52PM +0200 schrieb Adrian Bunk: > > This is really hard to do, thought. The new packages are needing those > > packages from the transition. I actually injected two packages from > > higher levels manually to be able to build one of the new packages. So > > we really need to upload the start of the transition and I do not see > > any sense in not documenting what we are doing without the transition > > tracker. > >... > > Your transition is special because you are manually uploading every > single package involved in the transition. > > You could upload everything to experimental, run a local ben tracker > against experimental, and when the transition is complete in > experimental contact the release team for the transition in unstable. > > The actual transition is then a batch of "Upload to unstable". Thanks for all helpful hints. I understand that with some effort over the current workflow it is possible to do the transition differently. The only thing which I did not yet understood is the actual drawback of the current workflow. I do not think that it takes specifically longer than other transition - we just have a different set of showstoppers to get it done in 24 hours. In the past we got support by ftpmaster when pinging them and explaining the transition issue. If I'm missing the point here I'm perfectly fine to enhance the procedure - I just fail to see the actual problem we want to solve by the suggested methods. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1024261: debhelper: dbgsym packages contain directoryr writable by build user
Axel Beckert: Hi, Helmut Grohne wrote: 308 armel 313 armhf 316 i386 613 mipsel I think it is fairly safe to say that the problem affects 32bit architectures. Could this be https://bugs.debian.org/1023286 in fakeroot as well as Niels pointed out in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024520#37 ? Regards, Axel It is. Helmut and I discussed this on IRC and Helmut's findings is based on that IRC discussion between him and I in relation to #1023286. (Which people not IRC had no chance of knowing, so putting the context here for good measure) Thanks, ~Niels
Bug#1023731: BioC Transition blocked by new dependencies
On Mon, Nov 21, 2022 at 04:39:26PM +0100, Andreas Tille wrote: >... > Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher: > > On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: > > > Control: block -1 by 1024563 > > > Control: block -1 by 1024565 > > > Control: block -1 by 1024567 > > > > > > Some of the BioConductor packages need new dependencies. > > > I have pushed these to new queue and set the ITP bugs as > > > blocker. > > > > As this is happening every r-bioc transition, could this be handled > > before starting the transition the next time? > > This is really hard to do, thought. The new packages are needing those > packages from the transition. I actually injected two packages from > higher levels manually to be able to build one of the new packages. So > we really need to upload the start of the transition and I do not see > any sense in not documenting what we are doing without the transition > tracker. >... Your transition is special because you are manually uploading every single package involved in the transition. You could upload everything to experimental, run a local ben tracker against experimental, and when the transition is complete in experimental contact the release team for the transition in unstable. The actual transition is then a batch of "Upload to unstable". > Kind regards > Andreas. cu Adrian Example for the status of the ongoing python3.11-add transition in experimental: $ cat tracker/python3.11-add.ben title = "Add Python 3.11 as supported version"; is_affected = .build-depends ~ /python3-all-dev|python3-all-dbg/ | .build-depends-arch ~ /python3-all-dev|python3-all-dbg/; is_good = .depends ~ /python3 \(<< 3\.12\)|python3.11|python3-dbg \(<< 3\.12\)|python3.11-dbg/; is_bad = .depends ~ /python3 \(<< 3\.11\)|python3-dbg \(<< 3\.11\)/ | .breaks ~ /python \(>= 3\.11\)|python-dbg \(>= 3\.11\)/; notes = "#1021984"; $ ben download --suite experimental --preferred-compression-format xz Downloading /home/bunk/Sources... Downloading /home/bunk/Packages_armhf... Downloading /home/bunk/Packages_amd64... Downloading /home/bunk/Packages_mips64el... Downloading /home/bunk/Packages_armel... Downloading /home/bunk/Packages_i386... Downloading /home/bunk/Packages_arm64... Downloading /home/bunk/Packages_mipsel... Downloading /home/bunk/Packages_ppc64el... Downloading /home/bunk/Packages_s390x... $ ben tracker -cd tracker Parsing /home/bunk/Sources... Parsing /home/bunk/Packages_amd64... Parsing /home/bunk/Packages_arm64... Parsing /home/bunk/Packages_armel... Parsing /home/bunk/Packages_armhf... Parsing /home/bunk/Packages_i386... Parsing /home/bunk/Packages_mips64el... Parsing /home/bunk/Packages_mipsel... Parsing /home/bunk/Packages_ppc64el... Parsing /home/bunk/Packages_s390x... Computing data for (unknown) python3.11-add Generating html/python3.11-add.html Generating ./export/packages.yaml Cleaning up... Generating index... $ cp -a /usr/share/ben/media html/ $ html/python3.11-add.html can then be viewed with any web broswer (or html/ copied to a public webserver like people.d.o). Different from the release team tracker, "ben download" above will get updated data only every 6 hours after dinstall.
Bug#1023731: BioC Transition blocked by new dependencies
On 11/21/22 17:21, Andreas Tille wrote: Am Mon, Nov 21, 2022 at 04:49:43PM +0100 schrieb Sebastiaan Couwenberg: This is really hard to do, thought. The new packages are needing those packages from the transition. I actually injected two packages from higher levels manually to be able to build one of the new packages. So we really need to upload the start of the transition and I do not see any sense in not documenting what we are doing without the transition tracker. You can rebuild the packages that are already in the archive and include them in a local repo (e.g. managed with reprepro) and used by the chroot where the rebuilds are performed. Use that to prepare the NEW uploads to experimental, file the transition bugreport once all packages have passed NEW, and move those to unstable once the transition is ACKed. Well, probably everything is possible, but as I said the tracker comes pretty handy to know the dependency relation. I really would like to know what might be the real problem of the delay of the transition in this specific case. Making me understand this problem would increase the motivation to do something else than currently. To prepare for GIS transition sI run my own ben instance to generate the trackers (for testing, unstable, and experimental), it's relatively easy to setup. If you'd like help to setup a ben instance for the R team, let me know. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023731: BioC Transition blocked by new dependencies
Am Mon, Nov 21, 2022 at 04:49:43PM +0100 schrieb Sebastiaan Couwenberg: > > This is really hard to do, thought. The new packages are needing those > > packages from the transition. I actually injected two packages from > > higher levels manually to be able to build one of the new packages. So > > we really need to upload the start of the transition and I do not see > > any sense in not documenting what we are doing without the transition > > tracker. > > You can rebuild the packages that are already in the archive and include > them in a local repo (e.g. managed with reprepro) and used by the chroot > where the rebuilds are performed. Use that to prepare the NEW uploads to > experimental, file the transition bugreport once all packages have passed > NEW, and move those to unstable once the transition is ACKed. Well, probably everything is possible, but as I said the tracker comes pretty handy to know the dependency relation. I really would like to know what might be the real problem of the delay of the transition in this specific case. Making me understand this problem would increase the motivation to do something else than currently. Kind regards Andreas. -- http://fam-tille.de
Bug#1023731: BioC Transition blocked by new dependencies
On 11/21/22 16:39, Andreas Tille wrote: Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher: On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: Some of the BioConductor packages need new dependencies. I have pushed these to new queue and set the ITP bugs as blocker. As this is happening every r-bioc transition, could this be handled before starting the transition the next time? This is really hard to do, thought. The new packages are needing those packages from the transition. I actually injected two packages from higher levels manually to be able to build one of the new packages. So we really need to upload the start of the transition and I do not see any sense in not documenting what we are doing without the transition tracker. You can rebuild the packages that are already in the archive and include them in a local repo (e.g. managed with reprepro) and used by the chroot where the rebuilds are performed. Use that to prepare the NEW uploads to experimental, file the transition bugreport once all packages have passed NEW, and move those to unstable once the transition is ACKed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023731: BioC Transition blocked by new dependencies
On 21 November 2022 at 16:39, Andreas Tille wrote: | Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher: | > On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: | > > Some of the BioConductor packages need new dependencies. | > > I have pushed these to new queue and set the ITP bugs as | > > blocker. | > | > As this is happening every r-bioc transition, could this be handled | > before starting the transition the next time? It could, resources and volunteers willing. BioConductor leads the upcoming release as 'devel' just like we do. There is no reason to wait apart from having to set up new processes. I now also look behind a complete r-cran-* set of 20k packages for the two Ubuntu LTS flavors (it's a longer story but it reuses RSPM / PPM packages from RStudio / posit). For that effort, I just rebuilt the 240 BioConductors pulled in from the CRAN package graph for both LTS variants. I got all that done in a few hours on Saturday (after mulling over the problem and working out a script to determine build order by number of r-bioc-* depends). "Formal packaging" in Debian proper is more work, but there is no reason not to run a test build in a container, or even upload to 'experiemental' a few weeks prior to the (well telegraphed) BioConductor release. If someone wants to run with this (and knows a little R) I would be happy to discuss my 'build order' setup script (bare and hackish at it is). Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1023731: BioC Transition blocked by new dependencies
Hi Sebastian, Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher: > On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: > > Control: block -1 by 1024563 > > Control: block -1 by 1024565 > > Control: block -1 by 1024567 > > > > Some of the BioConductor packages need new dependencies. > > I have pushed these to new queue and set the ITP bugs as > > blocker. > > As this is happening every r-bioc transition, could this be handled > before starting the transition the next time? This is really hard to do, thought. The new packages are needing those packages from the transition. I actually injected two packages from higher levels manually to be able to build one of the new packages. So we really need to upload the start of the transition and I do not see any sense in not documenting what we are doing without the transition tracker. However, to make us understand your suggestion better: Is there any drawback on your side if the transition of a closed set of packages if the transition is delayed by new processing? Kind regards Andreas. -- http://fam-tille.de
Bug#1023731: BioC Transition blocked by new dependencies
On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: > Control: block -1 by 1024563 > Control: block -1 by 1024565 > Control: block -1 by 1024567 > > Some of the BioConductor packages need new dependencies. > I have pushed these to new queue and set the ITP bugs as > blocker. As this is happening every r-bioc transition, could this be handled before starting the transition the next time? Cheers -- Sebastian Ramacher
Processed: BioC Transition blocked by new dependencies
Processing control commands: > block -1 by 1024563 Bug #1023731 [release.debian.org] transition: r-api-bioc-3.16 1023731 was not blocked by any bugs. 1023731 was not blocking any bugs. Added blocking bug(s) of 1023731: 1024563 > block -1 by 1024565 Bug #1023731 [release.debian.org] transition: r-api-bioc-3.16 1023731 was blocked by: 1024563 1023731 was not blocking any bugs. Added blocking bug(s) of 1023731: 1024565 > block -1 by 1024567 Bug #1023731 [release.debian.org] transition: r-api-bioc-3.16 1023731 was blocked by: 1024565 1024563 1023731 was not blocking any bugs. Added blocking bug(s) of 1023731: 1024567 -- 1023731: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023731 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1023731: BioC Transition blocked by new dependencies
Control: block -1 by 1024563 Control: block -1 by 1024565 Control: block -1 by 1024567 Some of the BioConductor packages need new dependencies. I have pushed these to new queue and set the ITP bugs as blocker. Kind regards Andreas. -- http://fam-tille.de
Bug#1023550: transition: qcustomplot
Greetings, Sebastian, On Sat, Nov 19, 2022 at 08:17:41PM +0100, Sebastian Ramacher wrote: Hi Filippo On 2022-11-11 10:56:08 +0100, Filippo Rusconi wrote: Greetings Sebastian, Thank your for your message. On Thu, Nov 10, 2022 at 11:04:54PM +0100, Sebastian Ramacher wrote: > Control: tags -1 moreinfo > Control: forwarded -1 https://release.debian.org/transitions/html/auto-qcustomplot.html > > Hi Filippo > > On 2022-11-06 15:29:32 +0100, Filippo Rusconi wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: lopi...@debian.org, gl...@debian.org, debian-science-maintain...@lists.alioth.debian.org > > > > (please explain about the transition: impacted packages, reason, ... > > for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) > > > > Greetings, > > > > Fundamental reason: Qt5 and Qt6 are in the archive. > > > > I am requesting a transition from package libqcustomplot2.0 to > > libqcustomplot2.1. Source package is qcustomplot. The change involves a change > > in the library name itself, from libqcustomplot2.0 to both libQCustomPlot2.1 and > > libQCustomPlotQt6.so.2.1.0 (see below). > > > > I have prepared the packaging in the following git repos branch: > > > > https://salsa.debian.org/science-team/qcustomplot/-/tree/qt5-and-qt6 [...] > > For the libs under my control, the transition is already prepared and these > > projects are going to be linking against the Qt6-built library, contrary to all > > the other packages detailed below. > > > > For the other libs listed above, I have already checked that they would build if > > some modifications were performed. I have already git branches ready for the > > packages under git VCS. For the others (source deb), I have patches available. > > > > The modifications are lean: change -lqcustomplot to -lQCustomPlot for many and > > also sometimes use the CMake-based configuration involving first > > find_package(QCustomPlot) and second the QCustomPlot::QCustomPlot formalism for > > the linker. > > > > That is: almost one- or two-liner patches. > > Could you please file bugs for those so that maintainers are aware? Yes, I'll do that. I have already informed them individually of the process and provided them with the relevant patch. Thanks! Please go ahead with the transition. I'm sorry, what should I do? Shall I upload the package to unstable? Thank you for your patience. Sincerely, Filippo -- ⢀⣴⠾⠻⢶⣦⠀ Filippo Rusconi, PhD ⣾⠁⢠⠒⠀⣿⡁ Research scientist at CNRS ⢿⡄⠘⠷⠚⠋⠀ Debian Developer ⠈⠳⣄ http://msxpertsuite.org http://www.debian.org
Re: Bug#1024261: debhelper: dbgsym packages contain directoryr writable by build user
Hi, Helmut Grohne wrote: > 308 armel > 313 armhf > 316 i386 > 613 mipsel > > I think it is fairly safe to say that the problem affects 32bit > architectures. Could this be https://bugs.debian.org/1023286 in fakeroot as well as Niels pointed out in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024520#37 ? Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
