Bug#997929: transition: yaml-cpp
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, I would like to upload yaml-cpp 0.7.0 to unstable which includes an ABI bump and a package name change (libyaml-cpp0.6 -> libyaml-cpp0.7). It has already been uploaded to Experimental and cleared NEW. Since the package now depends on googletest instead of including its own embedded copy, the package now builds on less architectures. Here is the package list from the automated Ben page[1]: calamares dcm2niix facter librime libzypp mir opencolorio opensurgsim pdns qtcreator ring (sid only) rivet (sid only) ros-image-common thinkfan trafficserver vast ros-rviz Let me know if you have any questions. [1] https://release.debian.org/transitions/html/auto-yaml-cpp.html -- Simon Quigley tsimo...@debian.org tsimonq2 on LiberaChat and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4
Bug#1023787: State of Debian LXQt in 2022
Dear Debian Release Team, or whoever this may concern, Let me provide some context for the current state of LXQt in Debian, and where the shortcomings exist in our current process, leading to a situation like this. Lubuntu, an officially recognized flavor of Ubuntu, has used LXQt for our default desktop environment since the 18.10 release. The Debian LXQt Team at the time was anything but receptive to our contributions and the hard work we have put into Lubuntu being as polished as it is today. This was mostly due to the inconsistent release schedule used by LXQt upstream, since they have no clear release windows, as we do in Debian and Ubuntu, respectively. In 2022, I am now seeing a consistent release schedule for the first time. With LXQt being pre-1.0 software, it was incredibly difficult to justify shipping an LXQt stack with bugs that had been fixed upstream for months. Therefore, we decided to simply carry an Ubuntu delta. Over time, a downstream-first approach, in and of itself, became difficult to justify. Especially with our refocus away from the i386 architecture, when we would encourage people to install Debian on those antiquated machines, they would be working with an incredibly old version of LXQt. There was absolutely no excuse for this: the Debian LXQt Team still existed, but always lagged at least one major version behind. That tends to add up when upstream only did a release once a year... Especially after becoming a Debian Developer and understanding what it takes firsthand, this was not something I wanted to continue. I announced that in a bug report simply to call out into the distance, to check if there was *anyone* interested in taking over the work Alf Gaida left us with, or at least interested in helping us in the effort. I received no such response, so I started uploading to Experimental, as you do when staging transitions. Several team members that held hats within Debian LXQt at some point started to step up and make questionable decisions. For example, despite becoming a Debian Developer in 2018, I was mentored to use symbols files for my library packages, to ensure ABI stability. They have been dropped, without even waiting for an acknowledgement or my perspective, because "they're too difficult to maintain." I will admit to allowing my mentee, Aaron Rainbolt, to make packaging changes that I *ONLY* intended on uploading to Experimental, with the intent of a thorough package review cycle, as I have done countless times within the Ubuntu infrastructure. Our work, despite the shortcomings, moves the needle forward for our users. There are so many bugfixes and great features included with the LXQt 1.1 release, now LXQt 1.2, that for Debian *and* for Lubuntu, we should have it in the next stable release. Aaron and I have been quite discouraged by some of the recent actions by this team. Especially uploading to unstable what should have only been uploaded to experimental (in the case of liblxqt), it shows me that we hold very different technical standards, for our packaging and for our users. If I still were to have an opinion worth hearing in the team, I would have noted that upload to be bad. It looks to me as if they're seeing this as an act of aggression, when in reality, we've been sick and tired of twiddling our thumbs, waiting for Debian to adopt the packaging we have held for three cycles now. The scene was completely silent until we showed up, for years, and suddenly it seems to be an act of aggression? I don't enjoy these types of arguments. To me at least, they're subtracting from what we're here to do: make Debian better for its users. However, it's worth noting, for the sake of answering to the Debian Release Team, that this is the result of *years* of tension. To move things forward, I would be more than happy to prepare the Debian LXQt 1.2 transition *myself*, the *right* *way*, and upload it all to Unstable *myself*, to ensure the transition is actually done smoothly. At that point, we can try to work on a healthier team environment. -- Simon Quigley si...@tsimonq2.net tsimonq2 on LiberaChat and OFTC @tsimonq2:linuxdelta.com on Matrix 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 OpenPGP_signature Description: OpenPGP digital signature
Bug#917255: transition: yaml-cpp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello Release Team, I would like to do a yaml-cpp transition to 0.6.2 before the Transition Freeze. It has been in Experimental since December 3rd and it involves a transition from libyaml-cpp0.5d1 -> libyaml-cpp0.6. I recently took over maintenance of the package, and this is my first yaml-cpp transition. Here is the Ben file: title = "yaml-cpp"; is_affected = .depends ~ /\b(libyaml\-cpp0\.5d1)\b/ | .depends ~ /\b(libyaml\-cpp0\.6)\b/; is_good = .depends ~ /\b(libyaml\-cpp0\.6)\b/; is_bad = .depends ~ /\b(libyaml\-cpp0\.5d1)\b/; An automated tracker has already been set up it seems: https://release.debian.org/transitions/html/auto-yaml-cpp.html Thanks, - -- Simon Quigley tsimo...@debian.org tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEXHq+og+GMEWcyMi14n8s+EWML6QFAlwhM74ACgkQ4n8s+EWM L6Tvug/9HrG55PvVI4ZGIbw0KiFbb8ylKSh8IpZDdeQ1xXswTYFr6oLg07y2lXUL oXVvpIZ9eR0+dM+ukF9GQVKMuyAWv3aMaXjnGHzfynF596uI0aI6Q2N4RYBEaTxw FMzWhrCx8py+Uoqb5+GqHYZFFOttJ/Xwz63iy2kj1Kmp96uflqkvVbQVAyvfRWrq rgJBqggECI9vkLC1HjPzHme5oIIA2vnNSHSZkBkoT3F2qTcHjJjI5mpmy6nCYwJz nFtdQVHfatyrJP/jspQuEmFRdGiofAxplcEGGgqpFsnA6i79QC7suUZEY/OGmKw+ fP/b+V2SgoCk9vVmVYgq44Wcp2SrfCLdOHXn2RWXx8jizVQ/NpcSdDnI3sY5BG+h johjp3pjRpJWe3Ei4iB4SMMaS5YC0uveQAzIJFZYvyYJ6Jx7twyVkXodoje9wbQc wEQGCvcYIDvmtwMgLaYVcHtkJuT0ZIhWbytdsvCe8NoIdSFxW5Zp4NBSqsRzX8FE P0ixvsBz9PfQAj8moe+zYpWKYmW3u5bme3sBksn5iFDHYiQZSehHFQZ/UE3Wcmb6 D4h7+6sTbsliW2UkI0xO9YZivgl3sf1e34c5UuGNKjoHt4gpm6OtDkmcjvNQQICs LPe+kalyYaus2VWDMX14BrLP5Hy08LUTLG3ANt3ukwCP63DeGEI= =aFgR -END PGP SIGNATURE-
Bug#917255: transition: yaml-cpp
On 12/26/18 3:39 AM, Emilio Pozuelo Monfort wrote: > On 24/12/2018 20:30, Simon Quigley wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> >> Hello Release Team, >> >> I would like to do a yaml-cpp transition to 0.6.2 before the >> Transition Freeze. It has been in Experimental since December 3rd and >> it involves a transition from libyaml-cpp0.5d1 -> libyaml-cpp0.6. I >> recently took over maintenance of the package, and this is my first >> yaml-cpp transition. > > Do the rdeps build against the new version? Yes, test builds all succeed. However, since some packages conflict with the Qt transition (that I am also helping with), it might need to wait until those rdeps are rebuild as well. Thanks, -- Simon Quigley tsimo...@debian.org tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature
Bug#917255: transition: yaml-cpp
On 1/4/19 3:50 AM, Emilio Pozuelo Monfort wrote: > On 27/12/2018 05:00, Simon Quigley wrote: >> On 12/26/18 3:39 AM, Emilio Pozuelo Monfort wrote: >>> On 24/12/2018 20:30, Simon Quigley wrote: >>>> Package: release.debian.org >>>> Severity: normal >>>> User: release.debian@packages.debian.org >>>> Usertags: transition >>>> >>>> Hello Release Team, >>>> >>>> I would like to do a yaml-cpp transition to 0.6.2 before the >>>> Transition Freeze. It has been in Experimental since December 3rd and >>>> it involves a transition from libyaml-cpp0.5d1 -> libyaml-cpp0.6. I >>>> recently took over maintenance of the package, and this is my first >>>> yaml-cpp transition. >>> >>> Do the rdeps build against the new version? >> >> Yes, test builds all succeed. >> >> However, since some packages conflict with the Qt transition (that I am >> also helping with), it might need to wait until those rdeps are rebuild >> as well. > > The new yaml-cpp failed to build on armel. Otherwise I might have acked this. Apologies, I didn't catch that. This is fixed now. Thanks, -- Simon Quigley tsimo...@debian.org tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature
Bug#902263: transition: qtbase-opensource-src
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello Release Team! We aren't ready to start the transition yet, but it would be great if you could set up the transition tracker. As usual, we have two sub-transitions in one large transition: title = "qtbase-opensource-src"; is_affected = .depends ~ "qtbase-abi-5-10-0" | .depends ~ "qtbase-abi-5-11-0"; is_good = .depends ~ "qtbase-abi-5-11-0"; is_bad = .depends ~ "qtbase-abi-5-10-0"; and title = "qtdeclarative-opensource-src"; is_affected = .depends ~ "qtdeclarative-abi-5-10-1" | .depends ~ "qtdeclarative-abi-5-11-0"; is_good = .depends ~ "qtdeclarative-abi-5-11-0"; is_bad = .depends ~ "qtdeclarative-abi-5-10-1"; This is my first transition in Debian, so I will be working with lisandro and mitya57 to ensure it goes smoothly. I'll reply to this bug when we have tested rdeps and are ready to proceed with the transition. Thank you in advance! -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature
Bug#902263: Qt transition is ready to go
Hello, We're ready to go with the Qt transition, but as Lisandro just noted in 896893, we're probably going to have to tangle the transitions. Feel free to ping me on IRC to discuss further, otherwise we're good to go. Thanks. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature
Bug#902263: Qt transition is ready to go
On 07/18/2018 07:23 AM, Emilio Pozuelo Monfort wrote: > Please wait for now. > > Emilio ACK -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature
Bug#902263: Qt transition is ready to go
ACK, thank you! -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature
Bug#1099677: transition: libgit2
Dear Timo and the Debian Release Team, Timo, thank you very much for opening this bug, I really appreciate it. It would be great to get libgit2 1.9 in before Trixie. We have successfully completed this transition in Ubuntu before Debian. You are more than welcome to upstream anything from Ubuntu you'd like, it's fully migrated. If I can assist in any way, whether it be via using my Debian Developer hat to upstream fixes, or providing advice on a specific fix, please don't hesitate to reach out. I am very happy to help. Release Team, approve this transition, pretty please with a cherry on top. ;) Warm regards, -- Simon Quigley si...@tsimonq2.net @tsimonq2:ubuntu.com on Matrix tsimonq2 on LiberaChat and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 OpenPGP_signature.asc Description: OpenPGP digital signature
