Bug#999897: ITP: qt6-virtualkeyboard -- Qt 6 Virtual Keyboard module
Package: wnpp Severity: wishlist Owner: Patrick Franz X-Debbugs-Cc: debian-devel@lists.debian.org, delta...@debian.org, debian-qt-...@lists.debian.org * Package name: qt6-virtualkeyboard Version : 6.2.1 Upstream Author : The Qt Company Ltd. * URL : https://www.qt.io/developers/ * License : GPL-3+ Programming Lang: C++ Description : Qt 6 Virtual Keyboard module Qt is a cross-platform C++ application framework. Qt's primary feature is its rich set of widgets that provide standard GUI functionality. Qt Virtual Keyboard is a virtual keyboard framework that consists of a C++ backend supporting custom input methods as well as a UI frontend implemented in QML.
Bug#999898: ITP: qt6-wayland -- Qt 6 Wayland module
Package: wnpp Severity: wishlist Owner: Patrick Franz X-Debbugs-Cc: debian-devel@lists.debian.org, delta...@debian.org, debian-qt-...@lists.debian.org * Package name: qt6-wayland Version : 6.2.1 Upstream Author : The Qt Company Ltd. * URL : https://www.qt.io/developers/ * License : LGPL-3 or GPL-2 Programming Lang: C++ Description : Qt 6 Wayland module Qt is a cross-platform C++ application framework. Qt's primary feature is its rich set of widgets that provide standard GUI functionality. The module is a toolbox for making Qt based Wayland compositors.
Remove packages from NEW queue?
I tried to remove a package from NEW with `dcut rm package.deb`, `dcut rm package.changes` and `dcut cancel package.changes`, but nothing worked. Is there even a way to remove a package from NEW? Regards, Stephan
Re: Remove packages from NEW queue?
Am 18. November 2021 10:30:37 MEZ schrieb Stephan Lachnit : >I tried to remove a package from NEW with `dcut rm package.deb`, `dcut >rm package.changes` and `dcut cancel package.changes`, but nothing >worked. >Is there even a way to remove a package from NEW? > >Regards, >Stephan > ask FTP Masters for a reject. (speculatinng on the why you want it rejected: if you want to replace it with e.g. a newer version, you can just upload the new version) -- tobi
Re: Remove packages from NEW queue?
Quoting Tobias Frost (2021-11-18 10:38:40) > (speculatinng on the why you want it rejected: if you want to replace it with > e.g. a newer version, you can just upload the new version) slightly related question: if I upload a new version to NEW, will the Age of the package be reset? I'm asking because my package has been in NEW for four months already and I'd like to avoid loosing that place by an upload of a new upstream version. Thanks! cheers, josch signature.asc Description: signature
Re: merged-/usr transition: debconf or not?
Michael Biebl writes: > Am 17.11.2021 um 19:57 schrieb Sam Hartman: >> The question is whether we ever get to a place where people can update >> files in a package currently installed to /bin/foo and instead install >> them to /usr/bin/foo. >> We have a consensus that dpkg bugs make that a bad idea. > > Is that really so? If I'm not mistaken, the problematic part was > moving files from / to /usr and at the same time moving files between > packages. So doing that at the same time can be problematic. If that > would affect many packages is another question. > > AIUI simply moving files from / to /usr within the same package is not > problematic. Won't you then end up with a package which cannot be split for the next two releases? Maybe not a big problem, but I think it will be so hard to keep track of that it's better to not move the files. Bjørn
Re: Remove packages from NEW queue?
Quoting Johannes Schauer Marin Rodrigues (2021-11-18 11:26:44) > Quoting Tobias Frost (2021-11-18 10:38:40) > > (speculatinng on the why you want it rejected: if you want to replace it > > with e.g. a newer version, you can just upload the new version) > > slightly related question: if I upload a new version to NEW, will the > Age of the package be reset? I'm asking because my package has been in > NEW for four months already and I'd like to avoid loosing that place > by an upload of a new upstream version. I guess that by "Age" you are referring to 5th column at https://ftp-master.debian.org/new.html Seems that field do get reset on new uploads: See e.g. ignition-utils which was uploaded in september and again in november - its "Age" is 2 days. Is "Age" used to rank processing of NEW requests? Is that documented somewhere? Or alternatively, do anyone have some (non cargo cult) empirical knowledge about that? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
Hi all. Johannes Schauer Marin Rodrigues writes: > slightly related question: if I upload a new version to NEW, will the Age of > the package be reset? I'm asking because my package has been in NEW for four > months already and I'd like to avoid loosing that place by an upload of a new > upstream version. Every time I see stories like this, I wonder what the consequences of the NEW queue's current workings are. This is *not* criticism of the heroic work of the FTP Masters, nor is it criticism of the objectives they have in processing the NEW queue. I do, however, worry that months of waiting to see the fruits of one's labor might be detrimental to attracting new contributors, or indeed to motivate already active ones. It also seems to be a not insigificant impediment to getting useful work, such as a SONAME bump, done quickly. At least personally, I find it harder to put in small pieces of work that result in incremental improvements if the result is having to wait months – with the added uncertainty of having to do it all again (for good reasons, but nevertheless). It may well be that I'm asking the impossible here, but it does seem to be a problem that other distributions don't suffer under to the same extent. Is it merely a matter of their standards being lower, or is there some room for improvement on our part? Apologies in advance if this is something that has been discussed a lot in the past. I'd be very interested in being pointed in the right direction in that case! Best, Gard signature.asc Description: PGP signature
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
Hi list, On 18/11/2021 11:51, Gard Spreemann wrote: Apologies in advance if this is something that has been discussed a lot in the past. I'd be very interested in being pointed in the right direction in that case! No need to apologize... searching the the devel archives on "NEW queue" reveals multiple discussions. One IMHO important thread starts at https://lists.debian.org/debian-devel/2020/02/msg00118.html. Another thread is about the NEW queue being more or less cleared about a year ago: https://lists.debian.org/debian-devel/2020/11/msg00017.html Cheers! --a
Re: merged-/usr transition: debconf or not?
On Nov 18, Zack Weinberg wrote: > And, as it has proven to be a genuinely critical problem, it is also their No, it has not. -- ciao, Marco signature.asc Description: PGP signature
Re: merged-/usr transition: debconf or not?
On Thu, 2021-11-18 at 13:09 +0100, Marco d'Itri wrote: > On Nov 18, Zack Weinberg wrote: > > > And, as it has proven to be a genuinely critical problem, it is also their > No, it has not. Indeed - it seems to me there's a convenient tendency to forget that this is not something new that has never been seen before, to be introduced without any testing. This is the default. It has been the default for multiple releases of multiple distributions. All Ubuntu installations that were not using this default are now forcibly converted upon upgrade to 21.10. And yet nobody has actually seen this happen, to the best of my knowledge. So either this combination that would allegedly not work hasn't been used once in 4+ years across multiple distros, or the required alignment of coincidences to make the issue happen is so rare that it just never happens in practice. All we have is a proof of concept. By all means, if anybody cares enough, go and fix it, no problem with that. Propose an actual, working alternative that gives the same result too - will happily spend my time to test it. And put in place QA checks and whatnot to be sure - that seems a great idea. But talks of blocking everything and reverting things with a hacky script that has never actually been used before, in the face of multiple decisions by the tech committee and no evidence whatsoever of real-world impact, and despite tens of thousands of actual, real bugs affecting Debian that don't get even a fraction of the same treatment (even the Replaces: feature has been affected by unrelated, actual, reported bugs, and might very well still be, haven't checked) seems to me a tiny bit hyperbolic and exagerated. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
On Thu, Nov 18, 2021 at 11:52 AM Gard Spreemann wrote: > > Every time I see stories like this, I wonder what the consequences of > the NEW queue's current workings are. This is *not* criticism of the > heroic work of the FTP Masters, nor is it criticism of the objectives > they have in processing the NEW queue. I do, however, worry that months > of waiting to see the fruits of one's labor might be detrimental to > attracting new contributors, or indeed to motivate already active > ones. It also seems to be a not insigificant impediment to getting > useful work, such as a SONAME bump, done quickly. At least personally, I > find it harder to put in small pieces of work that result in incremental > improvements if the result is having to wait months – with the added > uncertainty of having to do it all again (for good reasons, but > nevertheless). > > It may well be that I'm asking the impossible here, but it does seem to > be a problem that other distributions don't suffer under to the same > extent. Is it merely a matter of their standards being lower, or is > there some room for improvement on our part? I don't know if that has been proposed before, but how about waiving the NEW queue requirement for experimental packages as a start? This would allow us to work with new packages or soversion updates, and the transition through NEW to "unstable" could happen at the same time (i.e. upload to unstable for NEW and uploading again for experimental). Since packages in experimental will never land in any official release, I think dropping the NEW queue requirement has no negative impact. One could also go further and do this automatically for unstable -> testing (all package uploads allowed to unstable, new ones have to be approved by the ftp-masters before they can transition). Regards, Stephan
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
On Thu, Nov 18, 2021 at 02:52:56PM +0100, Stephan Lachnit wrote: > I don't know if that has been proposed before, but how about waiving > the NEW queue requirement for experimental packages as a start? > [...] Since packages in experimental will never land in any > official release, I think dropping the NEW queue requirement has no > negative impact. This makes no sense as NEW is mostly about checking licenses. -- WBR, wRAR signature.asc Description: PGP signature
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
On Thu, Nov 18, 2021 at 3:28 PM Andrey Rahmatullin wrote: > > On Thu, Nov 18, 2021 at 02:52:56PM +0100, Stephan Lachnit wrote: > > I don't know if that has been proposed before, but how about waiving > > the NEW queue requirement for experimental packages as a start? > > [...] Since packages in experimental will never land in any > > official release, I think dropping the NEW queue requirement has no > > negative impact. > This makes no sense as NEW is mostly about checking licenses. I think this is exactly why it makes sense. I think we can trust the DDs to not make any large mistakes (e.g. putting steam in main). Since packages in experimental aren't supposed to be used by anyone else but the DDs themselves, the "damage" of a potentially missing / wrong license is minimal, considering that DDs are aware of the fact that the packages aren't "official". I guess this raises the (maybe already answered) question if the additional license QA from NEW is for the end-product (i.e. Debian stable) or for the servers that run the Debian infrastructure, which of course includes experimental. If it's the latter, then of course this proposal doesn't work. However I find that view a bit weird. Any update can change the license or add new files with different licenses, nothing is ever checked by the ftp-masters (that would be insanity). My conclusion thus is that the NEW queue is more of an additional QA than a full legal coverage for the archive, and thus I don't see a problem with unchecked packages in experimental. Regards, Stephan
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
On Thu, 2021-11-18 at 19:28 +0500, Andrey Rahmatullin wrote: > On Thu, Nov 18, 2021 at 02:52:56PM +0100, Stephan Lachnit wrote: > > I don't know if that has been proposed before, but how about waiving > > the NEW queue requirement for experimental packages as a start? > > [...] Since packages in experimental will never land in any > > official release, I think dropping the NEW queue requirement has no > > negative impact. > This makes no sense as NEW is mostly about checking licenses. > Completely naive question that has probably already answered a million times, but: why then not limit to new source packages? Bumping an ABI or adding a new tool is as likely to imply a license change as any other version upgrade that doesn't result in new binary packages from the same sources. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
Hi, On 11/18/21 4:08 PM, Stephan Lachnit wrote: I guess this raises the (maybe already answered) question if the additional license QA from NEW is for the end-product (i.e. Debian stable) or for the servers that run the Debian infrastructure, which of course includes experimental. The latter. The license must allow Debian to redistribute the package. This is checked very thoroughly on the initial upload, and updates are expected to keep the same licensing. Whether that expectation still holds with upstreams who prefer vendor copies over using external packages is another matter, but in general these packages require more handholding anyway. Simon OpenPGP_signature Description: OpenPGP digital signature
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote: > > > I don't know if that has been proposed before, but how about waiving > > > the NEW queue requirement for experimental packages as a start? > > > [...] Since packages in experimental will never land in any > > > official release, I think dropping the NEW queue requirement has no > > > negative impact. > > This makes no sense as NEW is mostly about checking licenses. > > I think this is exactly why it makes sense. I think we can trust the > DDs to not make any large mistakes (e.g. putting steam in main). The existence of NEW means we currently don't, for completely new packages. > Since packages in experimental aren't supposed to be used by anyone else > but the DDs themselves, the "damage" of a potentially missing / wrong > license is minimal, considering that DDs are aware of the fact that the > packages aren't "official". The "damage" that's usually being discussed is Debian distributing something we can't, not users e.g. getting non-free software thinking it's free. Packages in NEW aren't even publicly accessible because of this, and discussions of switching to git-based source packages end with "we can't publish git history of random repos as we don't want to review and rewrite it". > However I find that view a bit weird. Any update can change the license > or add new files with different licenses, nothing is ever checked by the > ftp-masters (that would be insanity). Sure. -- WBR, wRAR signature.asc Description: PGP signature
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
On Thu, Nov 18, 2021 at 4:16 PM Simon Richter wrote: > > On 11/18/21 4:08 PM, Stephan Lachnit wrote: > > > I guess this raises the (maybe already answered) question if the > > additional license QA from NEW is for the end-product (i.e. Debian > > stable) or for the servers that run the Debian infrastructure, which > > of course includes experimental. > > The latter. On Thu, Nov 18, 2021 at 4:29 PM Andrey Rahmatullin wrote: > > On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote: > > > I think this is exactly why it makes sense. I think we can trust the > > DDs to not make any large mistakes (e.g. putting steam in main). > The existence of NEW means we currently don't, for completely new > packages. I guess these two answers sum it up then. Thanks. Regards, Stephan
Bug#1000154: ITP: ruby-rantly -- Ruby Imperative Random Data Generator and Quickcheck
Package: wnpp Severity: wishlist Owner: Antonio Terceiro X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ruby-rantly Version : 2.0.0 Upstream Author : Ana María Martínez Gómez, Howard Yeh, Anthony Bargnesi, Eric Bischoff * URL : https://github.com/rantly-rb/rantly * License : MIT (Expat) Programming Lang: Ruby Description : Ruby Imperative Random Data Generator and Quickcheck You can use Rantly to generate random test data, and use its Test::Unit extension for property-based testing. Rantly is basically a recursive descent interpreter, each of its method returns a random value of some type (string, integer, float, etc.). debian/control I'm packaging this as a build dependency for a new version of ruby-moneta. It seems like a pretty useful library. signature.asc Description: PGP signature
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
On Thu, 18 Nov 2021 at 19:28:28 +0500, Andrey Rahmatullin wrote: > On Thu, Nov 18, 2021 at 02:52:56PM +0100, Stephan Lachnit wrote: > > I don't know if that has been proposed before, but how about waiving > > the NEW queue requirement for experimental packages as a start? > > [...] Since packages in experimental will never land in any > > official release, I think dropping the NEW queue requirement has no > > negative impact. > > This makes no sense as NEW is mostly about checking licenses. Part of the problem with any discussion of NEW is that the answer to "is NEW for A, or for B?" is usually "yes". For new source packages, my understanding is that NEW is for: * checking for acceptable licenses / absence of unacceptable licenses - not breaking other people's rules, e.g. infringing copyright by distributing without permission to do so - not breaking our own self-imposed rules, e.g. not allowing non-free software into main/contrib * checking debian/copyright completeness - all licenses mentioned - all license text copied, unless present in common-licenses - all entities claiming copyright mentioned (historically for all licenses, now only for licenses that can be interpreted as requiring it) * package namespace control - not accepting obscure/niche packages with very short/generic names - not accepting packages with misleading names - enforcing naming conventions like `import foobar` -> `python3-foobar`, `use Foo::Bar` -> `libfoo-bar-perl`, `libfoobar-1.so.2` -> `libfoobar-1-2` and https://github.com/go-debos/fakemachine -> `golang-github-go-debos-fakemachine` - not having excessively big bundled packages - not having excessively small micro-packages * any other QA checks that the ftp team feel like doing - embedded code copies - obviously wrong packaging like a shared library in /usr/share - ??? (I don't know what else the ftp team actually look for in practice) The justification for NEW packages being unavailable to people outside the ftp team is that we don't want to be distributing them until they have had some sort of checking for redistributability (the first of my points above), because if we don't have permission to redistribute, then that's copyright infringement. I think a lot of the other inconvenient things about NEW are consequences of that. However, most of the other reasons for these checks are essentially self-imposed - for example there's no legal reason *preventing* us from distributing nvidia-graphics-drivers in main, but we don't *want* to do that, because it would break our self-imposed rules and undermine our intended mission (making an entirely Free OS). Similarly, there's no legal reason preventing us from redistributing obviously wrong packages, but we want to make a high-quality operating system, so we want to exclude those packages if we can. I think it's perhaps useful to make sure we distinguish between rules that we have because external factors force us to have those rules (like needing to avoid copyright infringement), and rules that we have chosen for ourselves (like main being self-contained and Free Software). Rules that we have chosen are something that we as a project can change, if we can reach consensus that we want to, and the impact of breaking them is whatever we as a project think it is. However, rules that come from external factors are mostly not something that we can change: in particular, needing to have permission to redistribute is something that is imposed on us by the legal system rather than something that we have chosen, and it is not within our power to change it. The only thing about those rules that could potentially be changed by project consensus would be the level of legal risk we are willing to take, in exchange for the benefit of being able to do things that benefit the project and our users. The existence of binary-NEW (for existing source packages that have added a new binary package) seems like partly namespace control, and partly an accident of implementation: packages go into these queues because their names do not appear in the overrides file that lists packages that were already accepted, and that is equally true for new binary packages in an existing source package. My understanding is that the ftp team have a policy of taking the opportunity to do all the same legal and QA checks they would do for new source packages, not just the package namespace control part, on the basis that in principle every package in the archive should be able to pass those checks at any time (and it would be a RC bug if it didn't). Of course, in practice typical uploads that do not introduce a new binary package name do not get held in a queue for manual review (because that would slow down development to a point where we could not make a practical OS distribution), so this leads to maintainers making packaging decisions that are not necessarily "right" in the abstract, such as not splitting packages tha
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
Stephan Lachnit writes: > On Thu, Nov 18, 2021 at 4:16 PM Simon Richter wrote: >> >> On 11/18/21 4:08 PM, Stephan Lachnit wrote: >> >> > I guess this raises the (maybe already answered) question if the >> > additional license QA from NEW is for the end-product (i.e. Debian >> > stable) or for the servers that run the Debian infrastructure, which >> > of course includes experimental. >> >> The latter. > > On Thu, Nov 18, 2021 at 4:29 PM Andrey Rahmatullin wrote: >> >> On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote: >> >> > I think this is exactly why it makes sense. I think we can trust the >> > DDs to not make any large mistakes (e.g. putting steam in main). >> The existence of NEW means we currently don't, for completely new >> packages. > > I guess these two answers sum it up then. Thanks. There is also the issue of cryptographic software, and the laws regarding its export from the USA, which Debian deals with by treating every package as though it _might_ at some point incorporate some crypto, and therefore registering every package with BXA as part of the NEW process. https://wiki.debian.org/USExportControl#Cryptographic_software_in_Debian_main_archive This may seem like a lot of silly nonsense, but apparently Debian's process is considered the gold standard by which they judge others, and I'd assume that one important factor there is that there is no back-door route by which we publish things from our mirrors prior to them going through this registration dance. Cheers, Phil. P.S. depending upon what exactly you're trying to do with pre-NEW packages, this may be part of the solution: https://salsa.debian.org/salsa-ci-team/pipeline/#using-automatically-built-apt-repository -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1000164: ITP: qt6-webchannel -- Qt 6 WebChannel module
Package: wnpp Severity: wishlist Owner: Patrick Franz X-Debbugs-Cc: debian-devel@lists.debian.org, delta...@debian.org, debian-qt-...@lists.debian.org * Package name: qt6-webchannel Version : 6.2.1 Upstream Author : The Qt Company Ltd. * URL : https://www.qt.io/developers/ * License : GPL-3 with Qt-1.0 exception Programming Lang: C++ Description : Qt 6 WebChannel module Qt is a cross-platform C++ application framework. Qt's primary feature is its rich set of widgets that provide standard GUI functionality. The Qt WebChannel module offers Qt applications a seamless way to publish QObjects for interaction with HTML/JavaScript clients.
Bug#1000166: ITP: qt6-webengine -- Qt 6 WebEngine module
Package: wnpp Severity: wishlist Owner: Patrick Franz X-Debbugs-Cc: debian-devel@lists.debian.org, delta...@debian.org, debian-qt-...@lists.debian.org * Package name: qt6-webengine Version : 6.2.1 Upstream Author : The Qt Company Ltd. * URL : https://www.qt.io/developers/ * License : LGPL-3 or GPL-2 Programming Lang: C++ Description : Qt 6 WebEngine module Qt is a cross-platform C++ application framework. Qt's primary feature is its rich set of widgets that provide standard GUI functionality. Qt WebEngine provides functionality for rendering regions of dynamic web content.
Re: merged-/usr transition: debconf or not?
Marco d'Itri wrote: > On Nov 18, Zack Weinberg wrote: >> as it has proven to be a genuinely critical problem > No, it has not. In the previous long thread on debian-devel on this subject, someone posted a step-by-step recipe to reproduce a phenomenon where a file that has been moved (in its package) from an installation path of /bin (for example) to /usr/bin, possibly in conjunction with a change to which package owns it, while /bin is a symlink to /usr/bin, will disappear from the file system when the updated set of packages is installed. (I regret I do not have time today to dig up the exact email in question.) Are you seriously claiming that that phenomenon is not a severity:critical bug? zw
Re: Bug#1000000: fixed in phast 1.6+dfsg-2
On Thu, Nov 18, 2021 at 05:12:10PM +0100, Sebastiaan Couwenberg wrote: >... > For the Debian package you could drop use_debian_packaged_libpcre.patch and > use the embedded copy to not block the prce3 removal in Debian. As a general comment, this would be a lot worse than keeping pcre3. If any copy of this library should be used at all in bookworm, it should be provided by src:pcre3. Switching from src:pcre3 to an older vendored copy would likely create additional security vulnerabilities for our users,[1] even with only one user in bookworm shipping it security supportable in src:pcre3 would be better than hiding vulnerabilities through vendoring. > Kind Regards, > > Bas cu Adrian [1] https://security-tracker.debian.org/tracker/source-package/pcre3
Re: merged-/usr transition: debconf or not?
Luca Bocassi wrote: ... > [merged /usr] is the default. It has been the > default for multiple releases of multiple distributions. All Ubuntu > installations that were not using this default are now forcibly > converted upon upgrade to 21.10. > > And yet nobody has actually seen [the file disappearance bug] > happen, to the best of my knowledge. I already explained why that doesn't prove the bug is a non-issue. To the contrary; it means there is an enormous installed base of systems where the bug is latent, waiting to cause problems under conditions which we can reasonably expect to occur shortly after the release of bookworm. Please do not make me repeat myself. zw
Bug#1000167: ITP: qt6-websockets -- Qt 6 WebSockets module
Package: wnpp Severity: wishlist Owner: Patrick Franz X-Debbugs-Cc: debian-devel@lists.debian.org, delta...@debian.org, debian-qt-...@lists.debian.org * Package name: qt6-websockets Version : 6.2.1 Upstream Author : The Qt Company Ltd. * URL : https://www.qt.io/developers/ * License : LGPL-3 or GPL-2 Programming Lang: C++ Description : Qt 6 WebSockets module Qt is a cross-platform C++ application framework. Qt's primary feature is its rich set of widgets that provide standard GUI functionality. QtWebSockets is a pure Qt implementation of WebSockets - both client and server.
Bug#1000168: ITP: qt6-webview -- Qt 6 WebView module
Package: wnpp Severity: wishlist Owner: Patrick Franz X-Debbugs-Cc: debian-devel@lists.debian.org, delta...@debian.org, debian-qt-...@lists.debian.org * Package name: qt6-webview Version : 6.2.1 Upstream Author : The Qt Company Ltd. * URL : https://www.qt.io/developers/ * License : LGPL-3 or GPL-2+ Programming Lang: C++ Description : Qt 6 WebView module Qt is a cross-platform C++ application framework. Qt's primary feature is its rich set of widgets that provide standard GUI functionality. Qt WebView provides a way to display web content in a QML application.
Work-needing packages report for Nov 19, 2021
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1260 (new: 5) Total number of packages offered up for adoption: 188 (new: 0) Total number of packages requested help for: 61 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: nam (#999656), orphaned 4 days ago Description: Network Animator for network simulation Reverse Depends: nam-dbg Installations reported by Popcon: 536 Bug Report URL: https://bugs.debian.org/999656 ns2 (#999653), orphaned 4 days ago Description: Discrete event simulator targeted at networking research Reverse Depends: ns2-dbg Installations reported by Popcon: 532 Bug Report URL: https://bugs.debian.org/999653 otcl (#999654), orphaned 4 days ago Description: shared library of OTcl Reverse Depends: libotcl1-dev nam ns2 otcl-shells Installations reported by Popcon: 550 Bug Report URL: https://bugs.debian.org/999654 pinpoint (#1000155), orphaned today Description: hacker-friendly presentation program Installations reported by Popcon: 46 Bug Report URL: https://bugs.debian.org/1000155 tclcl (#999655), orphaned 4 days ago Description: tcl2c++ and otcldoc program from tclcl Reverse Depends: libtclcl1-dev nam ns2 tclcl-dbg Installations reported by Popcon: 575 Bug Report URL: https://bugs.debian.org/999655 1255 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 188 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 1132 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web doc-central (139 more omitted) Installations reported by Popcon: 99458 Bug Report URL: https://bugs.debian.org/910917 aufs (#963191), requested 516 days ago Description: driver for a union mount for Linux filesystems Reverse Depends: fsprotect Installations reported by Popcon: 10048 Bug Report URL: https://bugs.debian.org/963191 autopkgtest (#846328), requested 1814 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1239 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3707 days ago Description: An e-mail client for GNOME Reverse Depends: balsa Installations reported by Popcon: 656 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 1682 days ago Description: Rust package manager Reverse Depends: dh-cargo rust-all Installations reported by Popcon: 2657 Bug Report URL: https://bugs.debian.org/860116 courier (#978755), requested 322 days ago Description: Courier mail server Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-ldap courier-mlm courier-mta courier-pcp courier-pop courier-webadmin couriergrey (3 more omitted) Installations reported by Popcon: 930 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 256 days ago Description: new maintainer need Reverse Depends: apticron autolog backintime-common btrfsmaintenance buildd checksecurity clamtk cricket email-reminder exim4-base (20 more omitted) Installations reported by Popcon: 209174 Bug Report URL: https://bugs.debian.org/984736 cyrus-imapd (#921717), requested 1014 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 423 Bug Report URL: https://bugs.debian.org/921717 dbab (#947550), requested 691 days ago Description: dnsmasq-based ad-blocking using pixelserv Installations reported by Popcon: 6 Bug Report URL: https://bugs.debian.org/947550 debtags (#962579), requested 526 days ago Description: Debian Package Tags support tools Reverse Depends: packagesearch Installations reported by Popcon: 1494 Bug Report URL: https://bugs.debian.org/962579 dee (#831388), requested 1952 days ago
Re: merged-/usr transition: debconf or not?
On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote: Luca Bocassi wrote: ... > [merged /usr] is the default. It has been the > default for multiple releases of multiple distributions. All Ubuntu > installations that were not using this default are now forcibly > converted upon upgrade to 21.10. > > And yet nobody has actually seen [the file disappearance bug] > happen, to the best of my knowledge. I already explained why that doesn't prove the bug is a non-issue. To the contrary; it means there is an enormous installed base of systems where the bug is latent, waiting to cause problems under conditions which we can reasonably expect to occur shortly after the release of bookworm. Please do not make me repeat myself. zw I'm afraid you have not. Why would the release of bookworm make any difference? There will be nothing new that hasn't already been happening for years. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: merged-/usr transition: debconf or not?
On 2021-11-18 at 20:06, Luca Boccassi wrote: > On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote: > >> Luca Bocassi wrote: >>> [merged /usr] is the default. It has been the default for >>> multiple releases of multiple distributions. All Ubuntu >>> installations that were not using this default are now forcibly >>> converted upon upgrade to 21.10. >>> >>> And yet nobody has actually seen [the file disappearance bug] >>> happen, to the best of my knowledge. >> >> I already explained why that doesn't prove the bug is a non-issue. >> To the contrary; it means there is an enormous installed base of >> systems where the bug is latent, waiting to cause problems under >> conditions which we can reasonably expect to occur shortly after >> the release of bookworm. Please do not make me repeat myself. >> >> zw > > I'm afraid you have not. Why would the release of bookworm make any > difference? There will be nothing new that hasn't already been > happening for years. I interpret Zack's comment as referring to this, which he said in https://lists.debian.org/debian-devel/2021/11/msg00205.html: > [P]eople aren't doing the package changes that trigger the bug, yet. > They can't, because that would break systems where /usr hasn't been > merged. If the bug is not fixed I expect it will start causing > problems in unstable *after* bookworm, since (as I understand the > current transition plan) bookworm+1 development is the earliest that > package maintainers may assume /bin is a symlink. IOW, I interpret him as disagreeing with you that "there will be nothing new that hasn't already been happening for years". Specifically, I parse him as arguing that: * to date, package maintainers have not yet begun moving already-packaged files from / to /usr/ (specifically because doing so would break systems that have not yet been migrated to merged-/usr, and Debian has not yet declared that such systems are unsupported), * after bookworm, package maintainers will start moving already-packaged files from / to /usr/, and * doing this will, in a non-negligible number of cases, trigger the bug to manifest on systems where that package is upgraded from a version where the move had not taken place to one where it has. (Zack, if I've gotten any of those wrong, please don't hesitate to correct me; I'll either apologize, or drop right back out of the discussion to go hide in a metaphorical hole, if not both.) Do you dispute any of those three points? If so, I'd be interested to know which one(s), and why. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
On Thu, 2021-11-18 at 19:32 +0100, Philip Hands wrote: > There is also the issue of cryptographic software, and the laws > regarding its export from the USA, which Debian deals with by treating > every package as though it _might_ at some point incorporate some > crypto, and therefore registering every package with BXA as part of the > NEW process. IIRC this no longer occurs as the BXA requested we stop notifying them. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: merged-/usr transition: debconf or not?
On Nov 18, Zack Weinberg wrote: > Are you seriously claiming that that phenomenon is not a severity:critical > bug? I am seriously claming that whatever you are referring to, if true, is such a contrived example that does not actually happen in real life (or at least, it does not happen frequently enough). -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#1000000: fixed in phast 1.6+dfsg-2
Hi, Am Thu, Nov 18, 2021 at 11:12:12PM +0200 schrieb Adrian Bunk: > On Thu, Nov 18, 2021 at 05:12:10PM +0100, Sebastiaan Couwenberg wrote: > >... > > For the Debian package you could drop use_debian_packaged_libpcre.patch and > > use the embedded copy to not block the prce3 removal in Debian. > > As a general comment, this would be a lot worse than keeping pcre3. Since I agree here I started (! not working yet!) with a patch[2]. I remember that upstream - who has basically stopped development if I remember correctly - was not even happy, that we replace the code copy. Thus I assume that they are not very interested in providing a pcre2 patch and we are on our own. > If any copy of this library should be used at all in bookworm, > it should be provided by src:pcre3. I agree and I assume we will need this. Several packages that received this bug report are not actively developed any more but used by our users. So it might be that we need to work on this ourselves and this needs time (and knowledge). > Switching from src:pcre3 to an older vendored copy would likely create > additional security vulnerabilities for our users,[1] even with only one > user in bookworm shipping it security supportable in src:pcre3 would be > better than hiding vulnerabilities through vendoring. +1 Kind regards Andreas. > [1] https://security-tracker.debian.org/tracker/source-package/pcre3 [2] https://salsa.debian.org/med-team/phast/-/blob/master/debian/patches/pcre2.patch -- http://fam-tille.de
