Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi On 21-05-2024 1:08 p.m., Sean Whitton wrote: PS: I've always wondered if the dgit server shouldn't track history, even if uploads don't happen via it. A dgit clone could (should?) already provide available history, even if no upload happened via it yet. Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's history. So it sort of does this. We could make it do more. Huh. Than my workflow hides this. All I'm often seeing is just the tar content represented in a commit, the latest Debian packing in another and the merge of these two (if I recall and describe what I recall correctly). I always thought that dgit clone generated that on my computer if there was no git content on the dgit server. I'll try to remember this next time I run my no-changes-source-only upload script. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: About i386 support
Hi, On 20-05-2024 4:50 p.m., Ben Hutchings wrote: There is a tension here between the interests of (a) users that want to run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to keep using 32-bit CPUs. If i386 is meant for group (a) then the baseline should be raised to include the features that 64-bit CPUs provide, but if it's also for group (b) then this mustn't happen. The Release Team expects the Debian i386 official port to go to (a). Paul, wearing his Release Team hat. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Two mistakes spotted On 19-05-2024 10:05 a.m., Paul Gevers wrote: I think there's a large majority (maybe even consensus) that believe you *should* have the packaging in VCS I meant "at least should", as in "should or must". I think what pere did [3] [3] https://people.skolelinux.org/pere/blog/45_orphaned_Debian_packages_moved_to_git__391_to_go.html Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi all,
In this discussion about mandating things, I've been wondering
On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote:
* mandate VCS-tracking
* Yes
* mandate the use of one specific VCS
* Yes: git
What do people think this should mean, a *should* or *must* in policy?
That the package has a RC bug if the packaging isn't tracked in git? And
if the packaging is in git but I forgot to push my latest changes to the
documented git server (this happens regularly to me as I do most uploads
with dgit)? RC? In all suites where the packaging version isn't pushed
for? And how about NMU's? (I just checked a random package without git:
aspell-am, last non-NMU upload was in 2013)?
If *must* and thus RC, can the issue be fixed by "NMU"? I.e. if the
person that did the changes, (and has nice local commits) somehow isn't
available, will the package (if not key) be auto-removed? Or can
everybody fix the repo? What if you don't have write access to the
existing repo? And then what if the uploader comes back and tries to
push the real history? What if my harddisk with local changes crashes
before I push (again, I forget that sometimes, but for me luckily dgit
will mostly have the commits).
Or is this "just a bug", maybe even at level important, but no other
consequences. Than I think this discussion is going to be moot. I don't
think there's much forcing possible and I think most already agree that
stuff *should* be in VCS, so this isn't going to change for those in
favor. And does it really add enough value if those that are forced are
just going to do "gbp import-dsc" for each upload to the archive on a
./debian only repository? Because that (or better) we could already
automate (see also my PS).
I'm against mandating ("must"). I think there's a large majority (maybe
even consensus) that believe you *should* have the packaging in VCS (and
I agree with that). Most packages already are (hopefully maintained) in
git (93% for testing) [1] on salsa (86%) [2], so I propose we stop the
discussion. I think what pere did [3] changed more than this whole
discussion: already 45 *orphaned* packages converted to git by 25 April,
which means my numbers above are on the low side. The remaining 438 QA
maintained (!!??) packages constitute close to 20% of the packages not
in git.
Paul
PS: I've always wondered if the dgit server shouldn't track history,
even if uploads don't happen via it. A dgit clone could (should?)
already provide available history, even if no upload happened via it yet.
[1] https://trends.debian.net/vcs_testing-stacked.png
[2] https://trends.debian.net/vcs-hosting_testing-stacked.png
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: About i386 support
Hi Andrew, Release team member hat on On 18-05-2024 12:28 p.m., Andrew M.A. Cater wrote: In reality, i386 should probably have been dropped early (or at the last minute) for bookworm; some libraries will be kept for compatibility but it's not realistic to maintain i386 for the whole of the trixie lifecycle. Please elaborate. We aren't planning to drop i386. If you have more information than I have, we'd like to learn. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: About i386 support
Hi On 17-05-2024 9:58 p.m., Victor Gamper wrote: Is it correct that debian 13 is planned to be released without an i386 iso and i386 is planned to be deprecated? Our current position is described here: https://lists.debian.org/debian-devel-announce/2023/12/msg3.html Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED
Hi Jonas, On 16-05-2024 10:35 a.m., Jonas Smedegaard wrote: Just to clarify, the package in question does not directly depend on rust-ahash 0.8.9-2, that Built-Using information is (as is the general purpose of that field, I believe) transitive. Built-Using is used for license compliance so we HAVE TO have the exact version in the archive. If the version mentioned in the Built-Using field is no longer in the archive, the package can't be accepted. Paul PS: I'm no ftp-master OpenPGP_signature.asc Description: OpenPGP digital signature
Re: new upstream version fails older tests of rdepends packages
Hi, On 08-05-2024 6:06 p.m., Bill Allombert wrote: Agreed, but gap does not actually breaks anything, it is just the tests in testing that are broken. So I can do that but that seems a bit artificial. Aha, that wasn't at all clear to me. If you don't want to do the artificial thing (which is fine, except now you depend on members of the release team), I'll manually schedule the tests. Maybe tomorrow. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Hi Luca, On 05-05-2024 10:04 p.m., Luca Boccassi wrote: > Hence, I intend to apply these changes in the next src:systemd upload > to unstable, probably next week. In case anybody is aware of packages/programs needing an update to cope with these changes, or any other issue, please let me know and I will file bugs. You filed MR341 against autopkgtest, thanks for that. Can you please hold off a bit longer than only one week to get the infrastructure updated? I'm confident that every test that has the needs-reboot restriction will start failing (which are only 21 tests according to codesearch). However, I fear that every test is at risk under common circumstances. I don't want to be rushed into an autopkgtest update and an infrastructure update for something that we can plan (there's always risk involved and I want to have the time and peace to cope with the process). Having said that, maybe we will be ready next week. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: new upstream version fails older tests of rdepends packages
Hi, On 04-05-2024 11:39 a.m., Jerome BENOIT wrote: What would be the best way to unblock the migration of gap and gap-io ? If gap isn't going to change (which might be the easiest solution), then file bugs and fix those reverse dependencies. Those bugs are RC and in due time will cause autoremoval. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Status of the t64 transition
Hi, On 27-04-2024 7:52 p.m., Andrey Rakhmatullin wrote: Can you please look at libproxy<->glib-networking? libproxy excuses show glib-networking tests failing, but they are working in sid. And that's not missing a versioned Depends and/or Breaks? I.e. this is a test only failure? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Status of the t64 transition
Hi, On 24-04-2024 7:42 p.m., Jérémy Lal wrote: Inform the Release Team and we can either schedule the combination manually, add a hint or both. Isn't it processed automatically ? What needs manual intervention and what doesn't ? Well, the migration software *tries* to figure out combinations that need to go together. It's greedy, but not infinitely so (otherwise we'd just look at unstable). If a test fails, reference runs are used to compare it to. If the reference run doesn't fail a test is a regression. Regressions are retried (after a day). Reference runs for regressions are rescheduled once they are a week old. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Status of the t64 transition
Hi, On 24-04-2024 7:38 p.m., Paul Gevers wrote: On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote: What to do with autopkgtests that fail in testing because of problems with packages in testing that are fixed in unstable, e.g. the autopkgtest for speech-dispatcher/0.11.5-2 on Inform the Release Team and we can either schedule the combination manually, add a hint or both. Or in cases like this, wait a bit. The test regressed in testing, which the migration software figures out automatically. (If you want to see earlier, you can retry "migration-reference/0" runs, which I already did for speech-dispatcher). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Status of the t64 transition
Hi, On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote: What to do with autopkgtests that fail in testing because of problems with packages in testing that are fixed in unstable, e.g. the autopkgtest for speech-dispatcher/0.11.5-2 on Inform the Release Team and we can either schedule the combination manually, add a hint or both. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian testing/unstable users: beware of Firefox critical CVEs
Hi Samuel, On 24-03-2024 11:45 p.m., Samuel Henrique wrote: In a recent case, the issue was addressed by performing a testing-proposed-update of the package. This would allow firefox-esr to be fixed on testing before the transition is over, but it would not work for those installing the firefox package from unstable on a testing machine (since there's no firefox package on testing, just firefox-esr). So, is the plan to deliver firefox-esr via tpu (after alignment with the Release Team)? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Package marked for autoremoval due to closed bug? [and 1 more messages]
Hi,
On 19-03-2024 11:32 a.m., Ian Jackson wrote:
Paul Gevers writes ("Re: Package marked for autoremoval due to closed bug?"):
For bookkeeping purposes, please usertag downgraded bugs with user
release.debian@packages.debian.org and usertag time_t-downgrade.
I was informed that time_t-downgrade isn't a valid usertag. Please use
time-t-downgrade instead.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Package marked for autoremoval due to closed bug?
Hi zigo, On 16-03-2024 12:31 a.m., Thomas Goirand wrote: But when the AUTORM period was announced as reduced, I thought like it was probably a bad call, and that the previous AUTORM was aggressive enough. I'm not aware that we reduced autoremoval times in recent history. Are you maybe confusing it with the time needed for packages to be out-of-sync [1]? That still requires someone (me) to file RC bugs and I have stopped doing that during this transition exactly to avoid autoremoval while the transition is in progress. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Package marked for autoremoval due to closed bug?
Hi, Disclaimer: exception only valid while the time_t transition is ongoing. On 15-03-2024 6:15 a.m., Steve Langasek wrote: Migration to testing is largely out of control of the maintainers at this point, it's very much dependent on folks rebootstrapping armel and armhf against the new library names. Should these bugs be downgraded again to important severity? As I'm normally watching out for out-of-sync packages, I'm fine (with my Release Team hat on) with maintainers downgrading RC bugs in testing that have been fixed in unstable and that don't require a quick update in testing (e.g. security issues probably warrant discussing the tpu path with the RT). Once time_t 64 bit is done, I'll be filling bugs for packages that don't migrate again, so the lack of the fix in testing won't go unnoticed. For bookkeeping purposes, please usertag downgraded bugs with user release.debian@packages.debian.org and usertag time_t-downgrade. Please be careful with downgrading RC bugs. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Any way to install packages+run autopkgtests on porterbox machines?
Hi, On 01-03-2024 1:58 p.m., Nilesh Patra wrote: Have you found any way around these? https://salsa.debian.org/mbanck/dd-autopkgtest/ Alternative, probably not the best solution, but until better ones are found (and as long it's not too much used): Antonio and I offer DD's access to testbeds with failed tests when contacted (preferably by signed e-mail). This is no wildcard access, we'll need to align on the time you want access. The advantage is that you run inside the setup that's used by ci.d.n on the arch you need. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems
Hi, On 29-02-2024 4:47 a.m., Christoph Anton Mitterer wrote: @d-d: - How can it happen that purge *t64 packages and at the same time install the previous package, and then the so file is missing? I mean it's clear that they use the same name, but shouldn't DPKG handle the cleanly? Well, officially downgrading isn't supported (although it typically works) *and* losing files is one of the problems of our merged-/usr solution (see [1]). I *suspect* this might be the cause. We're working hard (well, helmut is) to protect us and our users from loosing files on upgrades. We don't protect against downgrades. Obviously there might be issues, but you are running unstable *during* a transition. You have to expect some troubles. Thanks for the information, let's see if this is a real issue or not. Paul [1] https://subdivi.de/~helmut/dep17.html OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Policy: versioning between releases
Hi, On 21-01-2024 16:08, Matthias Urlichs wrote: However according to our release notes we only support upgrading from release x to x+1, skipping releases is not allowed. I'm not talking about skipping releases but about partial upgrades. Thus … > foo/testing requires bar >=1.1 to work but just states "Depends: bar >=1", and bar/stable is 1.0.42 assume that Stable has bar/stable==1.0.42 and foo/stable==2.1, while Testing has foo/stable==2.2. $USER adds Testing (or possibly stable/backports) to their apt.sources, updates foo, observes breakage, and now needs to dig through dependencies to figure out what went wrong. Because of the way we do QA on unstable to testing migration, we are in practice finding more and more of these cases. Which also means that we're supporting partial upgrades better over time. With my Release Team member hat on, I think we find these versioned relations increasingly more important to properly document, albeit not (yet?) at RC level. If I were to judge the severity, I think missing a *versioned* relation is typically severity important if with the older version (in testing or stable) a binary package (from unstable or testing) hardly works. Quite a lot of autopkgtest failures that I reported over the years fall in this category and I have not seen push back for adding the versioned relation in case of breakage of the binary's functionality. (Solving test breakage in case of version skew with versioned relations has seen push back occasionally, but that's not what we're discussing here (and I agree that regularly that's overkill)). So when I, as a maintainer, notice a problem along these lines, do I file a bug? Yes please. The solution is simple (in most cases, except for key packages and loops) while the maintenance price isn't that high (e.g. the janitor even helps to get rid of an obsolete versioned relation). Conversely, when I get this sort of bug report for one of my packages, is it OK to reply "that's not supported, go away"? I claim that nowadays we (as a project) don't expect our maintainers to reply like that. Yes, as far as I know partial upgrades are still not officially supposed to always work, but I think in practice it works quite well, so I think we support it as far as "it works most of the time reasonably well in reasonable configurations". Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi, On 20-01-2024 23:22, Steve Langasek wrote: So I think an algorithm for deciding the uploads to experimental looks like this: - download source from unstable. - apply the packagename conversion to the source. - grab the debdiff. - submit the NMU diff to the BTS. - download the source again from experimental (possibly a no-op). - apply the debdiff to the source. Except with a *lower* version number than you submitted to the BTS or in two steps below, with a higher version than you submitted to the BTS. (I assume everybody reading this realized that, but just in case.) - if it fails to apply (meaning: debian/control has changed), skip. otherwise, build and upload to experimental. - after packages have cleared binary NEW, upload sourceful NMUs to unstable for all these packages with the same debdiff as before. - if there are any packages included in the uploads to unstable that were skipped for experimental because of different sonames there, deal with binary NEW then in unstable. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Wolfram Research Debian Package Submission
Hi, On 12-01-2024 16:42, Blake Gilbert wrote: I am reaching out to you regarding a recent package submission by our Engine Connectivity Engineering team. We submitted the package CDImage M-LINUX-WolframEngine.DEB a few months ago to include Wolfram Engine in Debian packages, and I wanted to see if there was some way to help move this project forward. Would you be able to assist with this process or know the proper person to connect to? I assume you are talking about bug 1032150 [1]. I think you'd be interested in reading https://mentors.debian.net/intro-maintainers/ and seeking a sponsor via that process. Paul [1] https://bugs.debian.org/1032150 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Drawbacks of lack of mandated packaging workflow (Was: Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline)
Oops, should have waited sending... On 06-01-2024 14:30, Paul Gevers wrote: On 06-01-2024 14:15, Gioele Barabucci wrote: Aren't all these problems just inherent in Debian's lack of a mandated packaging tooling and workflow [1,2]? Might be, but that doesn't mean that problem goes away. I was talking about bugs, so, only minor. We expect maintainers to track bugs filed in the bts, so that would serve the purpose. But because *most* (according to trends.d.n) are hosted on salsa, an MR might help for an awfully big group. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Drawbacks of lack of mandated packaging workflow (Was: Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline)
Hi Gioele, On 06-01-2024 14:15, Gioele Barabucci wrote: Aren't all these problems just inherent in Debian's lack of a mandated packaging tooling and workflow [1,2]? Might be, but that doesn't mean that problem goes away. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Steve, On 05-01-2024 17:36, Rene Engelhard wrote: Also a problem is that experimental also might already contain totally unrelated updates like new upstream versions... I share this worry. Have you thought about how to handle the cases where you don't have experimental to upload to? How big is this problem? Another worry, how will you provide the required changes to the maintainers of the packages? Via BTS? For those working on salsa: MR? Both? Something else? Obviously we should not end in the situation that a new upload goes back to the old name (or are the ftp-masters so keen on this transition that that won't happen? But what about newer versions with the old name already in experimental, conform the former worry?). I've seen NMU's being ignored by subsequent uploads by the maintainer, even when they fixed RC issues which were then reintroduced. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bits from the Release Team: Cambridge sprint update
Hi On 18-12-2023 11:29, Santiago Vila wrote: El 17/12/23 a las 22:40, Steven Robbins escribió: Does that mean ceasing the "ITP" messages in debian-devel? I'd certainly welcome that! I think he really meant debian-release, as this was "Bits from the Release Team" and he was talking about "Release Team bugs", Yes, I was talking about d-release. Somehow this mistake slipped in and wasn't caught during the review. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bits from the Release Team: Cambridge sprint update
Hi, On 18-12-2023 13:18, Antonio Terceiro wrote: Will reproducibility regressions block migration to testing? Not for the near future for 2 reasons: 1) contrary to autopkgtest where removal of the test "fixes" regression, it feels that currently blocking on regression would give maintainers the wrong incentive to *not* make their packages reproducible, as there would be no way back. 2) there are still infrastructure hiccups that would hit maintainers of reproducible packages unequally hard, while we'd want the opposite if we'd have a choice. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Migration blocked
Hi, On 05-12-2023 03:52, Yadd wrote: I uploaded src:node-proxy-agents into unstable, which is the new source of node-proxy and node-https-proxy-agent. This package didn't migrate but I don't understand the reason of this block. The tracker[1] reports regressions on node-proxy and node-https-proxy-agent (which are replaced), and related logs contains "ERROR: erroneous package: rules extract failed with exit code 1". How can I fix this problem ? To be fair, I don't think you can unless you like to work on britney2 [2] and/or autopkgtest [3]. This is a corner case that our software doesn't handle correctly. So, the right course of action in a case like this is to contact the Release Team (I'm a member, so consider it done). *Maybe* a removal from unstable of src:node-https-proxy-agent and src:node-proxy would help, but I'm not convinced. Those sources should eventually go away automatically [4] (from your point of view). Paul [1]: https://tracker.debian.org/pkg/node-proxy-agents [2] https://salsa.debian.org/release-team/britney2/ [3] https://salsa.debian.org/ci-team/autopkgtest/ [4] https://ftp-master.debian.org/cruft-report-daily.txt OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Misc Developer News (#59)
Hi, On 22-11-2023 12:21, Donald Norwood wrote: The new attempt is a fresh email to d-d-a via cut and paste from the original email with the 1 correction that was needed. The email for some reason seems to be in d-d-a and d-d limbo, so I think we await the next cron run. More likely you need to do this signing of the mail differently. d-d-a is picky on accepting messages. While it worked in the past, I haven't figured out how to sign the mail in my e-mail client (thunderbird) nowadays in a way acceptable by d-d-a, and now always do the signing in-line and mail with $(mail) on *.debian.org. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Illegal Instruction Using sudo in Bookworm on i686
Hi, On 22-10-2023 23:32, r...@neoquasar.org wrote: If the distinction between "supported" and "not supported" is going to come down to specific assembler-level instructions, it would seem that that wont tell most people anything. Well, if we know which instructions we don't support, it's not too difficult to come up a script anybody can copy/paste, like the Release Notes had for stretch: if grep -q '^flags.*\bfpu\b.*\btsc\b.*\bcx8\b.*\bcmov\b' /proc/cpuinfo; then echo "OK (assuming all CPUs are of the same type)" else echo "NOT OK: Missing one or more of the required CPU extensions" fi Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Illegal Instruction Using sudo in Bookworm on i686
Hi, On 17-10-2023 22:16, Andrey Rakhmatullin wrote: Yes, assuming the pre-bookworm Debian i386 architecture fully supports it, as I don't know what *exactly* was allowed in the "almost i686" stretch-bullseye i386. According to the release notes (which *should* be authoritative, but may have bugs): The new baseline is the i686, although some i586 processors (e.g. the “AMD Geode”) will remain supported. The supported i586 processors have all the features of an i686 processor except the “long NOP” (NOPL) instruction. From: https://www.debian.org/releases/stretch/i386/release-notes.en.txt paragraph 5.1.7 Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: debvm for autopkgtests with multiple host?
Hi, On 24-09-2023 10:27, Johannes Schauer Marin Rodrigues wrote: Is the apt configuration on those systems set to something that is not the default and should be considered as well? How the unstable to testing migration runs work is that they have a testing testbed (with apt pinning making testing the APT::Default-Release without using that configuration option for $REASONS) with unstable added as an available suite. autopkgtest will create apt pinning for only those packages that were requested on the interface (by britney2, our migration software) to be added to testing. That way, we try to see what happens in testing if we would migrate the candidate source package to testing without all the rest of unstable. Be aware, there's also an ugly fall back in autopkgtest where it will remove all the pinning if it can't install all test dependencies with the pinning set-upped as described above, effectively allowing all packages from unstable to be installed. However, for the current use-case that probably happens *before* debvm/mmdebstrap runs, so that detail should not matter. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: armhf NEON exception for chromium
Hi Steve, On 15-09-2023 21:54, Steve Langasek wrote: armel != armhf Of course and nobody should be running armel on a NEON-capable CPU... Not sure why you say it like that, I guess you don't meen CI purposes here. But anyways, it seems that also the arm64 host that runs our armel and armhf VM's doesn't have NEON in the feature list. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: armhf NEON exception for chromium
Hi, On 15-09-2023 17:52, Andres Salomon wrote: Any thoughts on this? Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is empty on armel ci.debian.net workers. (I'm failing to spot neon in the list of features of that machine.) Paul [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036818 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: /usr-merge status update + next steps
Hi Helmut, On 19-08-2023 23:14, Helmut Grohne wrote: I recognize that this is quite a non-standard way to ask for a MBF. Does anyone object to me doing it in this way? I recall I said this before, but just in case. In my opinion (with my Release Team member hat on, but not on behalf of the team) this is fine. What I appreciate about using RC bugs is that in the weird case where the maintainer has good reasons why the package should migrate nevertheless (e.g. severe security implications), he has full power to achieve that. The history is also fully tracked in the BTS. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: debci / salsa ci: support for qemu runner
Hi, On 25-07-2023 16:16, Michael Biebl wrote: apparently, we in Debian struggle to find good opportunities where to spend our money. For ci.d.n, the issue is not money, but the required work to integrate it into the infrastructure. We need volunteers (or pay people to do the work), but unless they can and want to figure out everything from source [1], the bottleneck remains that the current volunteers would need to help those people understand the setup and guide them coming up with good solutions. I think support for qemu runners, i.e. supporting isolation-machine in autopkgtest on both debci and salsa ci would be an excellent opportunity. Please note that we wouldn't need this (initially) on all architectures. As long as tests run consistently, some architectures could support it and some not. Even more tuned, if we only had some workers on some architectures supporting this, we could list (manually or better) the tests that would need to be tested there explicitly somehow. All this doesn't exist yet. One step that has recently been made in debci, thanks Antonio for maintaining that, is that workers nodes should now be able to support multiple backends. No publicly available work has been done yet to utilize that. Paul [1] https://salsa.debian.org/ci-team/debian-ci-config/ OpenPGP_signature Description: OpenPGP digital signature
Re: The future of mipsel port
Hi, On 23-07-2023 17:51, Mark Hymers wrote: On Tue, 18, Jul, 2023 at 12:45:51PM +0800, YunQiang Su spoke thus.. So I consider to suggest drop mipsel support from the list of official ports. (And let's keep mips64el port). Is there consensus on this point? If so, should we start making arrangements to remove mipsel from the archive? Speaking as a member of the Release Team, but without having consulted with the others, I think we're OK with the removal. I have not been involved in removal of an architecture before, I think it's the Release Team configuration of britney2 that needs to change as the first step or at least at the same time as the actual removal from the archive, correct? Paul OpenPGP_signature Description: OpenPGP digital signature
Re: How do you cause a re-run of autopkgtests?
Hi, On 21-07-2023 14:20, David Kalnischkies wrote: How is this to be done? Should some automated mechanism for achieving this be added, and if so, where? You already found the retry button from previous replies, but you don't have to click it to get what you want… The migration software of the release team retries failures after 24 hours. Configuration specifying the retry age lives here: [1]. Paul [1] https://salsa.debian.org/release-team/britney2/-/blob/master/etc/britney.conf#L103 OpenPGP_signature Description: OpenPGP digital signature
Re: security autopkgtests ci
Hi, On 30-06-2023 22:40, Jérémy Lal wrote: Nice, but how can we see it when we prepare a package for security team ? You can't. Only the security team has access to the results. After the packages have been released the results will be published and can be seen in the history on ci.d.n, e.g. [1] where you'll see a result for security-team. Paul [1] https://ci.debian.net/packages/o/openjdk-17/oldstable/amd64/ OpenPGP_signature Description: OpenPGP digital signature
Re: security autopkgtests ci
Hi, On 30-06-2023 20:14, Jérémy Lal wrote: is there something like a CI for security uploads ? Yes. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Help with a libzstd sparc64 FTBFS on the buildd
Hi Peter, On 06-04-2023 15:37, Peter Pentchev wrote: I feel like I cannot ask for an unblock from the release managers since the sparc64 buildd started failing on this package at some point in February: sparc64 is not a release architecture. sparc64 will not be better or worse if something migrates. I suggest to consider those problem separately. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Updating python3-xlrd for pandas 1.5 compatibility
Hi Diane, On 23-02-2023 08:12, Diane Trout wrote: the version of python3-xlrd 1.2.0-3 in unstable/testing is too old to be used with pandas 1.5.3. (See Bug #1031701). Do I understand correctly that this isn't an issue from the point of python3-xlrd and that only pandas is effected? While investigating for this reply I noticed src:pandas doesn't even have a dependency in any of its binaries. As it is a really common workflow to use pandas to read excel files, it'd be nice if the version of xlrd in bookworm was compatible. As the maintainer of pandas, do you consider it an RC issue that pandas can't convert it? I guess not because you say "it'd be nice" and you don't even have the required dependency. How severe do you consider this issue for pandas? pandas has a quite extensive autopkgtest, doesn't it cover this use case? Apparently you knew this earlier, why do you bring this up now? Because of the freeze I wanted to check if it was appropriate to upload the new version, I'd hope that the "rules" are clear: https://release.debian.org/testing/freeze_policy.html#soft. You can contact the Release Team if you need further clarification. and what kind of warning I should give to the other developers. It depends. I'm worried about what you write below. THe xlrd changelog says the biggest change in going from 1.2 to 2.0 was they removed the ability to read the newer XML excel files .xslx from xlrd in favor of using openpyxl That sounds like a change that we'd normally consider inappropriate. So we'd need to balance the pain vs the gain and the additional risk of unknown delta's. I updated the source package python-xlrd to 2.0.1 and sent it through experimental, where there were no issues detected by packages that had CI tests. Indeed https://qa.debian.org/excuses.php?experimental=1=python-xlrd is clean. Unfortunately there's packages without tests. Like pandas not testing for xls loading; it wasn't even scheduled as pandas has no binaries depending on python3-xlrd. Here's the list of packages I found that have any relationship to python-xlrd, if it looked like the autopkgtests actually tested using the xlrd library and what the level of declared dependency is. (none means the package lacks autopackage tests) | nemo | none | Recommends| | odoo-14 | none | Depends | | ofxstatement-plugins | none | Depends | | psychopy | unlikely | Depends | | python3-agateexcel | yes | Depends | | python3-canmatrix| no | Recommends| | python3-drslib | no | Recommends| | python3-glue | yes | Depends | | python3-pyspectral | probably | Suggests | | python3-rows | unlikely | Recommends| | python3-tablib | unlikely | Depends | | visidata | none | Build-Depends | | vistrails| none | Build-Depends | | python-xrt | none | Build-Depends | | pyutilib | none | Build-Depends | If I read everything correctly, it seems like you're too late with this change. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: how to skip some archs for autopkgtests
Hi, On 03-02-2023 16:51, Nilesh Patra wrote: There is a "skip-not-installable" that you could decleare in d/t/control for these packages (for the corresponding tests that suffer from uninst test deps), more details here[1] Please don't use this. I regret I added it to autopkgtest because more often than not it hides real installability issues. On Fri, Feb 03, 2023 at 04:07:09PM +0100, Jonas Smedegaard wrote: How do I skip some known impossible to check architectures in autopkgtests? There's the Architecture field in the spec, but ... Concretely, the packages src:rust-hyper-rustls and src:rust-rustls-native-certs both fail on powerpc64 and s390x, due to missing packages on those architectures: https://tracker.debian.org/pkg/rust-hyper-rustls https://tracker.debian.org/pkg/rust-rustls-native-certs It is *not* that the packages are unusable on those architectures - or at least that is yet unknown. Instead, the underlying complexity is that the autopkgtest-dependencies are architecture-independent source code but packaged as architecture-dependent and not offered on those architectures. Any thoughts on how¹ to proceed? The current best way is to ask the release team to hint the package through. The problem here is that the migration software of the Release Team isn't smart enough (and there are cases where I believe there's just information missing in our control files) to figure out to not schedule some of those tests. But as the migration software looks at regressions, once the test is accepted to fail in testing, it's no longer a problem (except it looks unpleasant on your ci.d.n page). (It's a bit like the recent FTBFS on some architecture discussion we had here). Another way is to declare "Architecture: !s390x !ppc64el" in d/t/control but I think this is in-appropriate for the said case. It's not in-appropriate, but it feels like just another place to keep track of things. So I think a one-time action is better than such a place that you have to keep up-to-date. Also, if it at one day happens to succeed, you get it for free. But if you rather not bother the Release Team Paul OpenPGP_signature Description: OpenPGP digital signature
key packages RC bugs of the month February
Dear all, While I skipped one month, we're now in the mid of the first freeze, so here's another plea [1,2,3,4, 5] to fix RC bugs in key packages [6]. Currently we have 168 RC bugs in key packages affecting bookworm [7] of which 109 are unresolved in unstable or experimental, aren't pending and don't have a patch. Here are again 5 RC bugs in key packages to draw attention to this class of bugs. Remember, resolving these bugs is a collective effort. #925134 grub-efi-amd64 doesn't mount cryptodisk https://bugs.debian.org/925134 #558422 grub-pc upgrade hangs https://bugs.debian.org/558422 #924151 grub2-common wrong grub.cfg for efi boot and fully encrypted disk https://bugs.debian.org/924151 #945001 grub-efi-amd64 GRUB-EFI messes up boot variables https://bugs.debian.org/945001 #990017 grub-ieee1275 [REGRESSION] Bullseye CD installer images fail to install GRUB on OpenPOWER machines https://bugs.debian.org/990017 [Yes, these are all from the same source, the package has a long standing "Request for Help" bug open: https://bugs.debian.org/248397] I am asking for help with investigating RC bug reports, judging severity, reproducing the issue, clarifying the problem, i.e. bug triaging of all RC bugs that haven't seen activity for a while and that are still affecting bookworm. Of course ideally the bug gets fixed. Remember, if you really think a bug shouldn't be RC (particularly if you are the maintainer), downgrade it with an explanation. If in doubt, leave your note in the bug report, that's already a great help. Paul [1] https://lists.debian.org/debian-devel/2022/07/msg00133.html [2] https://lists.debian.org/debian-devel/2022/09/msg0.html [3] https://lists.debian.org/debian-devel/2022/10/msg1.html [4] https://lists.debian.org/debian-devel/2022/11/msg00080.html [5] https://lists.debian.org/debian-devel/2022/12/msg00065.html [5] https://release.debian.org/key-packages.html [6] https://udd.debian.org/dev/cgi-bin/rcblog7.cgi OpenPGP_signature Description: OpenPGP digital signature
Re: Should singularity-container make it to next release?
Hi Nilesh, On 26-01-2023 10:06, Nilesh Patra wrote: I guess something that changed since then is that upstream is aware about it and can help a bit with backporting. However the onus to maintain it in stable is still on the maintainer and security@ (to some extent) It is bit of a high-effort maintainance (in stable) as far as I can see. I may (or may not) be misunderstanding you. As a maintainer, it's up to you to commit to the effort. If you're up to it and judge it's feasible, I'm not going to block you on that. I understood you raised a concern about it being feasible, that's why we ended up here. If you commit (obviously best effort, but we'll expect you to spend time on it) *and* the security team agrees that with your commitment it's supportable, I'll remove my concern. Our concern is that we *don't* want new versions in stable to fix security issues if those new versions are not bugfix-only releases. We have to accept that for browsers, because shipping without them seems like a disservice to nearly all of our users, but still it's something we really don't like. fasttrack still has much less visibility / availability than an official stable release, or even backports. Obviously that will only be solved if it's more used (and/or if eventually it can be moved to the debian.org namespace.) But indeed. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Should singularity-container make it to next release?
Hi, On 25-01-2023 20:14, Moritz Muehlenhoff wrote: On Sat, Jan 21, 2023 at 08:34:40PM +0100, Salvatore Bonaccorso wrote: So in my understanding of the above the situation around singularity-container, which lead for buster to https://bugs.debian.org/917867 and keeping it out of the stable release, did not really change in the aspect of beeing able to patch vulnerabilities to the stable branch once upstream versions moved on, is this correct interpretation? In context from #917867, it was even in stretch at first, but needed to be removed after stretch was released in a point release. If this is correct, then we probably should not include singularity-container in bookworm, better than possibly need to remove it after bookworm release in a point release. Agreed. Cheers, Moritz I have forwarded this message as bug #1029669. Unless we get more confidence that it's supportable, let's keep it out of stable. I guess fasttrack [1] is currently the best forum to supply singularity-container to our users. Paul [1] https://fasttrack.debian.net/ OpenPGP_signature Description: OpenPGP digital signature
Re: security paperwork machine
Hi, On 23-01-2023 21:33, Alexandre Detiste wrote: A whole pre-existing private security tracker solution would be perfect; or a website where one could register all the package they care about. You mean something like [1] but then for a user instead of a team... I couldn't quickly find it, but worse case maybe make your own team as a work around? Paul [1] https://tracker.debian.org/teams/debian-accessibility/ OpenPGP_signature Description: OpenPGP digital signature
Re: Remote service accounts protection in autopkgtest?
Hi Vasyl, On 22-01-2023 22:33, Vasyl Gello wrote: Assuming I would like to test the package interacting with some proprietary third-party service on the web (like Kodi PVR addon), is there any mechanism protecting of account details so that autopkgtest machines can read them while outside world can not. Docker / podman / GitHub / GitLab all have the "secrets" command for exactly that purpose. I think adding the common GPG key for Debian autopkgtest infrastructure and exposing only the public key part of it to the public access (so everyone can encrypt the account details for autopkgtest but not decrypt them) is worth the efforts. What do you think? If I understand the proposal correctly, it's both src:debci (to manage the key) and src:autopkgtest (to use it) that would need to grow support for this. I'm personally not going to work on this any time soon, but I'm pretty sure we'll accept reasonable patches. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Multi-host networking software, autopkgtests
Hi Ian
On 06-01-2023 14:09, Ian Jackson wrote:
I have two packages which do vpn-like things (hippotat, secnet) which
I want to add autopkgtests for. The two packages have similar kinds
of requirements for their tests.
Ideally, I would:
* Somehow have two test nodes ("hosts")
* With their own /etc and /var (or, relevant parts thereof,
but it would be better to have two completely separate hosts
so I can test that the client package works even if you don't
have the server package installed, etc.)
* With their own networking setups
* With some kind of network connection between them
All of this would have to be set up from the autopkgtest test script,
which would need to be able to run commands in either node.
And ideally it would be easy to run the tests from my normal dev
environment too (without having to, say, install docker).
Ideally it would let me properly test the service startup (init
scripts, etc.) too for a full integration test, but if necessary that
can be done in a separate one-host test, since the software will
*start up* just fine even if it doesn't have a peer.
I guess I could do something ad-hoc with mount and network namespaces
and overlay filesystems. But it feels like this problem must have
been solved already ?
The part I'm not sure how to do ad-hoc is dependency management. An
autopkgtest ought to use the packages desired by the autopkgtest test
runner. So far the best option I can think of is to declare in the
autopkgtest control file *all* the relevant packages needed for any of
the two test nodes and the setup scripts; in each node, unshare the
namespaces enough that I can run apt; manually uninstall the
not-needed dependencies, and run apt autoremove.
I guess this is best discussed in https://bugs.debian.org/908274 (added
in the To)? Maybe with Wouter and other interested parties?
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Re: SONAME bumps (transitions) always via experimental
Hi, On 05-01-2023 14:13, Simon McVittie wrote: since passing NEW currently requires a source+binary upload but migrating to testing requires a follow-up source-only upload (same total number of uploads). To be fair, normal SONAME bump NEW uploads only need a arch:!all binary uploaded and normally the Release Team has been scheduling binNMU's for arch:!all binary uploads. So under quite some conditions it indeed does require an additional upload. Presumably if a maintainer finds that they need this, the ftp team would read a justification in debian/changelog and relax this rule? In my original mail I on purpose said "to also by *default* reject" (emphasis added now), exactly to not make it an absolute reject for purposes like this. Paul OpenPGP_signature Description: OpenPGP digital signature
SONAME bumps (transitions) always via experimental
Dear all, The Release Team just asked ftp-master to hold of accepting SONAME bumps targeting unstable to ease the last days before the Transition and Toolchain Freeze. The Release Team would like to ask the ftp-masters to also by default reject SONAME bump NEW uploads to unstable during the whole release cycle and instead mandate they need to go through experimental. This requires a bigger audience to agree upon, hence this message. Once accepted, the proposed workflow should also become documented in Debian policy. The benefits of all SONAME bump NEW uploads going through experimental are at least: * disentangle the start of transitions from NEW acceptance by ftp-master * auto transition trackers [1] are setup before the start of transitions * reduce the chance of uploads accidentally interfering with ongoing transitions (by more awareness and exposure via tracker.d.o). Are there objections against this workflow? (Or voices from people who like this?) Paul [1] https://release.debian.org/transitions/ OpenPGP_signature Description: OpenPGP digital signature
Re: Help setting dbconfig-common for MariaDB, not MySQL
Hi Marc, On 02-01-2023 16:58, Marc Haber wrote: On Mon, 2 Jan 2023 16:31:17 +0100, Paul Gevers wrote: On 02-01-2023 14:21, Alessandro Vesely wrote: A user complained that MySQL doesn't work, because it misses the INET6 type that the example settings use. And is this an absolute must? (It's an example after all?) It is. We need to stop having "disable IPv6" as measure 1 if something doesn't work right. It's the default IP protocol for a decade. Are you saying that MySQL doesn't support IPv6? Or just that the "INET6 type" in the context of MariaDB is a MariaDB specific implementation of something? (Sorry, I didn't investigate and assumed the latter). Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Help setting dbconfig-common for MariaDB, not MySQL
Hi Alessandro, On 02-01-2023 14:21, Alessandro Vesely wrote: please pardon my ignorance about Debian install. I'm distributing a software which could use various DBMS'es by setting a number of parameters. Example parameters are only given for MariaDB. I distribute a debian/ directory that Debian users can use to prepare a package instead of configure, make, make install. However, the debian/postinst supports MariaDB only. Do I understand you correctly that you don't want to support MySQL? Or that you don't know how to support both at the same time? Most packages in Debian that are using MariaDB or MySQL can easily support both (hence we have the default-mysql-client and virtual-mysql-client packages), and indeed dbconfig-common treats them as equal. A user complained that MySQL doesn't work, because it misses the INET6 type that the example settings use. And is this an absolute must? (It's an example after all?) Now I've added "mariadb-client | mariadb-server | dbconfig-no-thanks" to the Debian clause in debian/control. I think that's wrong. At least it would fail to install dbconfig-common in case there is a mariadb-client installed. Also, I wonder about the mariadb-server part. mariadb-server depends on the versioned mariadb-server-* package which depends on the versioned mariadb-client-* package. So in case mariadb-client wouldn't be able to be fulfilled, mariadb-server as the second alternative isn't going to help. And in my opinion you should not depend on the server part. As with most databases, the server part can live on a different host and package should really not force the server to be on the same host. I'm not clear how I could add an (optional) Conflicts mysql-something, also because I see no mysql-server in the package cache. mysql-server is available in unstable, but we don't want to support both MySQL and MariaDB in Debian stable at the same time, so currently MySQL is blocked from migration. However, derivatives choose differently (Ubuntu supports MySQL in their releases). As mentioned above, the server part can be on a different host, but ependencies are not able to describe incompatibility with what runs on the other host. Is there a way to fail if a user chooses to install the DB but MariaDB is missing? Or is the above enough? I don't think you can do it with dependencies. If you really want to go this route, you have to detect it during run time. Paul OpenPGP_signature Description: OpenPGP digital signature
key packages RC bugs of the month December
Dear all, With only 1 month to go until the first freeze, another plea [1,2,3,4] to fix RC bugs in key packages [5]. Currently we have 234 RC bugs in key packages affecting bookworm [6] of which 160 are unresolved in unstable or experimental, aren't pending and don't have a patch. Here are again 5 RC bugs in key packages to draw attention to this class of bugs. Remember, resolving these bugs is a collective effort. #1001276 binutils Hijacks libctf library name on (k)FreeBSD https://bugs.debian.org/1001276 #1000496 grub2 libvirt/kvm/qemu/grub - XML-generated VMs working under buster fail with bullseye https://bugs.debian.org/1000496 #1004184 gcc-11 generate bad code for matplotlib with -O1/-O2 on mips64el https://bugs.debian.org/1004184 #1005619 hypercorn FTBFS: dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 255 https://bugs.debian.org/1005619 #1005628 ruby-turbolinks-source FTBFS: installing symlink lib/assets/javascripts/turbolinks.js pointing to parent path /usr/share/javascript/turbolinks/turbolinks.js ... is not allowed https://bugs.debian.org/1005628 I am asking for help with investigating RC bug reports, judging severity, reproducing the issue, clarifying the problem, i.e. bug triaging of all RC bugs that haven't seen activity for a while and that are still affecting bookworm. Of course ideally the bug gets fixed. Remember, if you really think a bug shouldn't be RC (particularly if you are the maintainer), downgrade it with an explanation. If in doubt, leave your note in the bug report, that's already a great help. Paul [1] https://lists.debian.org/debian-devel/2022/07/msg00133.html [2] https://lists.debian.org/debian-devel/2022/09/msg0.html [3] https://lists.debian.org/debian-devel/2022/10/msg1.html [4] https://lists.debian.org/debian-devel/2022/11/msg00080.html [5] https://release.debian.org/key-packages.html [6] https://udd.debian.org/dev/cgi-bin/rcblog7.cgi OpenPGP_signature Description: OpenPGP digital signature
key packages RC bugs of the month November
Dear all, With about 2 months to go until the first freeze, a fresh plea [1,2,3] to fix RC bugs in key packages [4]. Currently we have 255 RC bugs in key packages affecting bookworm [5] of which 184 are unresolved in unstable or experimental, aren't pending and don't have a patch. Here are again 5 RC bugs in key packages to draw attention to this class of bugs. Remember, resolving these bugs is a collective effort. #994510 libunwind8 abuses setcontext() causing SIGSEGV on i386 with glibc >= 2.32 https://bugs.debian.org/994510 #997587 node-request FTBFS: dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1 https://bugs.debian.org/997587 #972146 mono-runtime-common /usr/share/applications/mono-runtime-common.desktop: should not handle MIME type by executing arbitrary code https://bugs.debian.org/972146 #996780 gnome-boxes Systematic system freeze few seconds after launching a Windows WM https://bugs.debian.org/996780 #1000955 libkf5globalaccel-bin /usr/bin/kglobalaccel5 eats up huge amount of CPU after suspend https://bugs.debian.org/1000955 I am asking for help with investigating RC bug reports, judging severity, reproducing the issue, clarifying the problem, i.e. bug triaging of all RC bugs that haven't seen activity for a while and that are still affecting bookworm. Of course ideally the bug gets fixed. Remember, if you really think a bug shouldn't be RC (particularly if you are the maintainer), downgrade it with an explanation. If in doubt, leave you note in the bug report. Paul [1] https://lists.debian.org/debian-devel/2022/07/msg00133.html [2] https://lists.debian.org/debian-devel/2022/09/msg0.html [3] https://lists.debian.org/debian-devel/2022/10/msg1.html [4] https://release.debian.org/key-packages.html [5] https://udd.debian.org/dev/cgi-bin/rcblog7.cgi OpenPGP_signature Description: OpenPGP digital signature
artwork for bookworm?
Dear all, Today I started the Release Team Checklist [1] and noticed: [ ] Theme (artwork) design should be finalised and decided I just found two small threads on debian-desktop [2, 3], but I'm not aware of any further activity on the artwork front. Do we have volunteers to push for the bookworm artwork creation and selection (like [3])? It's not going to happen by itself. (I might have missed the activity, pointers to it would be appreciated). Paul who is *not* going to do that. [1] https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/BookwormCheckList [2] https://lists.debian.org/debian-desktop/2022/04/msg0.html [3] https://lists.debian.org/debian-desktop/2022/08/msg0.html [4] https://wiki.debian.org/DebianDesktop/Artwork/Bookworm OpenPGP_signature Description: OpenPGP digital signature
Re: bits from the release team: are you ready to skate yet?
Hi, On 13-10-2022 17:32, Johannes Schauer Marin Rodrigues wrote: hrm... maybe I misunderstand but I thought your initial mail talked about build profiles (aka DEB_BUILD_PROFILES) and not build options (aka DEB_BUILD_OPTIONS). The policy section you cite is about DEB_BUILD_OPTIONS and not about DEB_BUILD_PROFILES. As far as I know, build profiles are not documented in policy at all yet. The bug for that is https://bugs.debian.org/757760 Am I missing something? Ok, maybe I mixed things up a bit. In the end, what matters for the Release Team is that we (potentially; in the future) want to *use* declared Build-Dependencies to figure out what we consider key packages. Building documentation is important, but if we can choose between not building documentation and not building at all, we prefer the former (exceptions exist, as always). Paul OpenPGP_signature Description: OpenPGP digital signature
Re: bits from the release team: are you ready to skate yet?
Hi josch, On 13-10-2022 14:20, Johannes Schauer Marin Rodrigues wrote: Quoting Paul Gevers (2022-10-13 10:00:42) Please also consider supporting the nodoc build profile. We are aware that nodoc is regularly used in a non-reproducible way (as intended, but with this consequence), so checking for correctness of this profile may be a bit harder. Ideally, using the profile would just make documentation binaries virtually empty. No. Ideally, using the nodoc profile would make documentation binaries not be emitted at all. This then also makes checking for correctness a lot easier because then all binary packages built with the nodoc profile will be bit-by-bit identical if your source package builds reproducibly. Policy [1] says something else: """ This option does not change the set of binary packages generated by the source package, but documentation-only binary packages may be nearly empty when built with this option. """ I suggest you try and get policy updated. [1] https://www.debian.org/doc/debian-policy/ch-source.html#debian-rules-and-deb-build-options Paul OpenPGP_signature Description: OpenPGP digital signature
key packages RC bugs of the month October
Dear all, A new month, a fresh plea [1,2] to fix RC bugs in key packages. So, here are again 5 RC bugs in key packages in the hope to draw some attention to this class of bugs. Remember, fixing these bugs is a collective effort. #913916 grub-efi-amd64 UEFI boot option removed after update to grub2 2.02~beta3-5+deb9u1 https://bugs.debian.org/913916 #987602 src:ca-certificates ca-certificates-java,default-jre-headless,openjdk-11-jre-headless: get rid of the circular dependency https://bugs.debian.org/987602 #965026 grub-emu grub-emu is unusable with orca nor BRLTTY https://bugs.debian.org/965026 #975490 u-boot-sunxi u-boot-sunxi: A64-Olinuxino-eMMC boot stuck at "Starting kernel ..." https://bugs.debian.org/975490 #991936 openssh-server openssh-server: seccomp filter defaults to SIGSYS, could break any libc or kernel upgrade https://bugs.debian.org/991936 I am asking for help with investigating RC bug reports, judging severity, reproducing the issue, clarifying the problem, i.e. bug triaging of all RC bugs that haven't seen activity for a while and that are still affecting bookworm. Of course ideally the bug gets fixed. Remember, if you really think a bug shouldn't be RC (particularly if you are the maintainer), downgrade it with an explanation. If in doubt, leave you note in the bug report. The full list I use to check for RC bugs in key packages can be found at [4]. Paul [1] https://lists.debian.org/debian-devel/2022/07/msg00133.html [2] https://lists.debian.org/debian-devel/2022/09/msg0.html [3] https://release.debian.org/key-packages.html [4] https://udd.debian.org/dev/bugs.cgi?release=bookworm_and_sid=ign=only=7=7=1=1=1=1=1=last_modified=asc=html#results OpenPGP_signature Description: OpenPGP digital signature
Re: Fixing CI bugs for a package on the REJECT list
Hi Jeff, On 26-09-2022 12:53, Jeff wrote: Short of closing #1012250, how do I get CI pipeline to pick up gscan2pdf again to debug the flaky tests? I'd appreciate any pointers. The bug has a user specified for the usertag and explicitly mentions: """ Don't hesitate to reach out if you need help [...] """ So, either using debian...@lists.debian.org or the submitter's address (mine) seems appropriate. In this case: we can trigger the test from the backside, such that you can get a fresh log, but I prefer to only do that coordinated and after you give it a try to enable more diagnostic logging, because apparently in the original logs there wasn't enough information for you. I also offer to run the test (once or twice) manually and get information out of the testbed, if you tell me the exact commands you want me to run in the testbed. Paul PS: I propose we drop debian-devel from the replies and continue our discussion in the bug, but please keep me in CC as I'm not subscribed to the bug. Be reminded that the BTS doesn't send e-mail to the submitter unless asked explicitly or unless the bug is closed. OpenPGP_signature Description: OpenPGP digital signature
Re: packages expected to fail on some archs
Hi Samuel, On 11-09-2022 17:08, Samuel Thibault wrote: We could for instance: - Add an Architecture-FTBFS field to debian/control - Add an environment variable to debian/rules so that on these archs dh fails with a different exit code that buildds would notice. - Add a Architecture-FTBFS field in the wb database that DDs can set - color packages that "never" had a successful built on an architecture different. That information is already available because that's what marks the package as "uncompiled" vs "out-of-date". I think it has added value if both cases (marked by the maintainer vs detected automatically) have value and could have different colors. Comparing it to autopkgtest, we currently color no-regression orange, while "neutral" (because of all kind of reasons, but the result of an actively set property) is blue. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Half the world being removed
Hi On 03-09-2022 19:48, Patrice Duroux wrote: Am I observing a side effect (kind of back-in-time) regarding a repair process on this issue? No. Because, for instance, the following page: https://tracker.debian.org/pkg/fwanalog has now its 'news' section showing: [2017-09-05] fwanalog 0.6.9-8 MIGRATED to testing (Debian testing watch) [2017-08-30] Accepted fwanalog 0.6.9-8 (source) into unstable (Adam Borowski) [2015-05-30] fwanalog 0.6.9-7 MIGRATED to testing (Britney) [2015-05-20] Accepted fwanalog 0.6.9-7 (source all) into unstable (Emanuele Rocca) with the lost of the 0.6.9-9 (unstable) related entries when I looked at it few days ago. That's https://salsa.debian.org/qa/distro-tracker/-/issues/63 Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Half the world being removed
Hi, On 02-09-2022 13:00, Ian Jackson wrote: I wonder if it would be possible to detect a sudden large increase in the number of autoremovals, and stop the autoremoval system instead of causing blaring klaxons for everyone in the project ? I disabled the cron job that sends out mail yesterday, so the massive klaxons shouldn't go off (or are there klaxons I'm not aware of). And indeed such a check would be worth while. But to be fair, the code is in Perl and I would be afraid that by adding the check I introduce more bugs than I solve. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Half the world being removed
Hi On 02-09-2022 07:27, Andrey Rahmatullin wrote: On Thu, Sep 01, 2022 at 11:04:38PM -0500, Steven Robbins wrote: Suddenly half the packages are marked AUTOREMOVE; many due to gcc-12 and zlib. The related two bugs are months-old. Why are things suddenly being removed?? Both are key packages per https://udd.debian.org/cgi-bin/key_packages.yaml.cgi so it must be some recent problem that causes the things to ignore that. I'll look into it tonight (UTC+2). I did make one change to udd yesterday. I thought it was safe because I just reverted an exception to allow scikit-learns removal. There are probably bugs involved. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: key packages RC bugs of the month September
Hi all, On 01-09-2022 21:10, Rene Engelhard wrote: This either should be ignored (like for bullseye) or downgrade, imho, but I didn't do it myself. I don't think there's anything actionable here... On 01-09-2022 16:52, Simon McVittie wrote: >> #919914gnome-settings-daemon >> gnome-tweaks now equates "don't suspend on lid close" with "don't lock on >> lid close" (security issue) >> https://bugs.debian.org/919914 > Honestly, I don't think this one is really RC. The > bug reporter asserts that it's a RC security issue, > but there are two contradictory user expectations (summary at > https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/84#note_502354) > and the current behaviour has been the same since Debian 10 if I'm > reading the bug history correctly. If I read these correctly, this is exactly the kind of action that a maintainer can take to make the release process smoother. If *you* as a maintainer think the bug shouldn't be RC, by all means downgrade it (ideally with an explanation just in case it's disputed later on). The Release Team doesn't *want* to go over all RC bugs and decide to ignore them, we don't have the intimate knowledge of your package to judge and it takes time to build up enough knowledge to make the judgement call. If it's disputed, we can judge it (and raise severity if needed) later on with our Release Team member hat on, but the first call is on the maintainer. Please. Paul OpenPGP_signature Description: OpenPGP digital signature
key packages RC bugs of the month September
Dear all, In the same theme as my earlier message [0], I like to ask you to please spend some time triaging (and ideally solving) old RC bugs. Some packages you may care about were removed from testing because the maintainer didn't triage or fix the bug. And then there's key packages... As a Release Team member, I'm concerned about RC bugs for key packages [1] that don't get fixed in a timely manner. It's rather trivial to remove non-key packages from testing (albeit that not being nice) while removing key packages is difficult or impossible without making bookworm useless. As the threat of autoremoval isn't there, there's quite a bunch of RC bugs in key packages affecting testing that linger without a resolution. As the freeze is drawing nearer I'd like to try an experiment: I'd like to present to you on a monthly basis the "key packages RC bugs of the month" in the hope to draw some attention to this class of bugs. Remember, fixing these bugs is a collective effort. I am asking for help with investigating RC bug reports, judging severity, reproducing the issue, clarifying the problem, i.e. bug triaging of all RC bugs that haven't seen activity for a while and that are still affecting bookworm. Of course ideally the bug gets fixed. To give examples, I mention 5 bugs below, next month hope I'll mail 5 other ones. The full list I use to check for RC bugs in key packages can be found at [2]. #919296 git-daemon-run fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist' https://bugs.debian.org/919296 #919914 gnome-settings-daemon gnome-tweaks now equates "don't suspend on lid close" with "don't lock on lid close" (security issue) https://bugs.debian.org/919914 #960679 src:fontconfig strict dependency of arch:any libfontconfig1 on arch:all fontconfig-config going wrong https://bugs.debian.org/960679 #935182 libreoffice-core Concurrent file open on the same host results file deletion https://bugs.debian.org/935182 #944871 src:docbook-xsl readds catalogs to the super catalog on every upgrade https://bugs.debian.org/944871 Paul [0] https://lists.debian.org/debian-devel/2022/07/msg00133.html [1] https://release.debian.org/key-packages.html [2] https://udd.debian.org/dev/bugs.cgi?release=bookworm_and_sid=ign=only=7=7=1=1=1=1=1=last_modified=asc=html#results OpenPGP_signature Description: OpenPGP digital signature
Re: Need a buildd build after trip through NEW -- best practice?
Hi all On 25-08-2022 02:43, Paul Wise wrote: I don't think Build-Architecture header is done yet? Neither do I. Although since we build all arch:all packages on amd64 machines now I don't think this is needed for throwing away NEW binaries? In testing and on release architectures, I'm only aware [1] of one that can't build arch:all+arch:any binaries on amd64 (cmucl), but even that one builds its arch:all binaries on amd64. I'm wondering if there are packages where this is a known issue (and with the missing header, is there a way the outside world can track this)? I recall some ports have a not-for-us list, is that exposed for amd64? So probably the feature is ready to be enabled, although maybe after the bookworm release is the best time to enable it in case there is any unforeseen autocruft/(re)bootstrap/other fallout. I think there's still time to fix stuff if we enable it soon. Paul [1] https://qa.debian.org/dose/debcheck/src_testing_main/index.html (difference between amd64 and each) OpenPGP_signature Description: OpenPGP digital signature
Re: Need a buildd build after trip through NEW -- best practice?
Hi, On 24-08-2022 02:05, Paul Wise wrote: The release team automatically do binNMUs for packages that need a rebuild to transition to testing and are able to be binNMUed Maybe my fellow Release Team members have automated this locally, but I'm not aware of shared tools (or even cron jobs) that do this. If we spot them, we *may* (and often do ) binNMU. The patch for dropping NEW binaries has been in dak for two years but its configuration options were never enabled by ftp-master so far. Dinstall::ThrowAwayNewBinarySuites Dinstall::ThrowAwayNewBinaryComponents I would be a great fan of this happening. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system
Hi, On 19-08-2022 18:10, Luca Boccassi wrote: On Fri, 19 Aug 2022 at 16:54, Paul Gevers wrote: On 19-08-2022 17:41, Luca Boccassi wrote: And if KDE Muon is indeed dead, simply having a "Conflicts: muon" and using the same path should be ok as well? No. Care to elaborate a little? Simon did that extremely well, as his suspicion was dead-on. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system
On 19-08-2022 17:41, Luca Boccassi wrote: And if KDE Muon is indeed dead, simply having a "Conflicts: muon" and using the same path should be ok as well? No. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs
Hi Edward, On 02-08-2022 18:00, Edward Betts wrote: I wonder if it would be possible to routinely run the autopkgtests on s390x, or another big-endian architecture, for 'Architecture: all' packages and make the results available. We run all autopkgtests on all architectures we have available. A failure on s390x should block you package from migrating already. Unfortunately, we enabled s390x about two months after your package migrated. Has this been suggested or attempted before? It's being done, and the result shows that indeed your package fails on s390x: https://ci.debian.net/packages/s/sqlite-fts4/ (as you already reported in a later message. Paul OpenPGP_signature Description: OpenPGP digital signature
Please fix or triage RC bugs
Dear all, Please help keeping the upcoming bookworm freeze short by fixing or triaging RC bugs in key packages [1] before the freeze starts on 12 January 2023 [2]. As you are very likely aware, Debian releases when it's ready. One of the most important criteria is the number of RC bugs. To draw attention to RC bugs in packages, we autoremove those packages after some time. Unfortunately, that doesn't work so well for key packages [3], that's why this need to be a collective effort. Paul [1] https://udd.debian.org/dev/bugs.cgi?merged=ign=1=html=bookworm=only#results [2] https://release.debian.org/testing/freeze_policy.html [3] https://release.debian.org/key-packages.html OpenPGP_signature Description: OpenPGP digital signature
Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
Hi On 28-06-2022 22:17, Scott Talbert wrote: All uploads need to be source-only (since bullseye?). To be more correct, all package that are intended to migrate to testing need to be source-only. However, in the review process of NEW binaries, the upload still needs to contain all (and one arch) binaries for the ftp-master to review. There are patches to support throw away binaries, but as far as I'm aware they haven't been merged and I don't know the status of the patches. That won't remove the need for binary uploads, but it would remove the need for a re-upload. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.
Hi, On 22-06-2022 20:04, Moritz Mühlenhoff wrote: Or if the goal is rather to experiment and expose BabaSSL to the many archs we have in Debian, then keep it in unstable only by filing a bug to block it from testing. Or better: experimental, to avoid packages starting to (build-)depend on it. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi Frédéric, On 09-06-2022 16:19, Frédéric Bonnard wrote: did you see any improvement with luajit2 ? Improvements, yes. All fixed, no. I was looking at luakit, which still fails "silently" on ppc64el, a lua script generating a .h with no symbols with luajit2, where it does work with lua. Also I see that the autopkgtest of knot-resolver still fails on ppc64el. See also https://bugs.debian.org/1012362. Best to have the conversation there. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: When uploading a package we get two mails. Could it be one ?
Hi Jérémy, On 27-05-2022 23:08, Jérémy Lal wrote: Is it some misconfiguration on my side ? I think so. When a package is uploaded, we get two emails: node-d3-color_1.2.8-3_source.changes ACCEPTED into unstable As the (team) uploader, I only got ^ that one. I believe it is sent to the maintainer of the package (pkg-javascript-de...@lists.alioth.debian.org). Accepted node-d3-color 1.2.8-3 (source) into unstable I think ^ one comes from tracker.d.o. You may want to check the headers of the e-mail. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
Hi all, On 27-05-2022 09:42, Julien Puydt wrote: ... or generate a blacklist of packages that should not trigger those removals. That exists: key packages. Or the removal watcher could have a cap on the number of warnings it sends per sensible period of time. If it exceeds this number, it sends a special warning that something is amiss to debian-devel, so we still get to know something is going wrong. Patches welcome. Code is here: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Paul OpenPGP_signature Description: OpenPGP digital signature
Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
Hi, On 24-05-2022 20:07, M. Zhou wrote: I wonder why an irrelevant package suddenly triggered autoremoval of a very large portion of packages from testing. https://udd.debian.org/cgi-bin/autoremovals.cgi Searched for keyword nvidia-graphics-drivers-tesla-470, and I got 68866 entries. There must be something wrong. https://bugs.debian.org/1011268 (but apparently my first assumption was wrong and it's another bug, most likely Simon was right. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Change package source name
Hi Yadd, On 09-05-2022 14:54, Yadd wrote: Then, after all needed tests and no-regression tests and wait for 2 weeks and the sacrifice of a goat on a full moon night, what is the way to adopt : * wait for ROM-RM of old src packages and then upload new node-regenerator * upload new node-regenerator before ROM-RM ^ This. If a source A takes over the binaries of another source B, and B no longer builds binaries, it's decrufted and removed (at least I'm confident this happens in testing, less confident about unstable, but at least the takeover happens). This obviously only works if the versions of the binaries build by source A are higher than the versions of the binaries of source B. * drop node-regerator and keep those old quick-and-dirty packages Paul Thanks for your work in this part of the archive. OpenPGP_signature Description: OpenPGP digital signature
Re: autopkgtest/sbuild environment variables: LC_ALL, HOME, XDG_RUNTIME_DIR etc
Hi Julian, On 28-04-2022 09:33, Julian Gilbey wrote: It would be really useful to be able to set up my local sbuild environment in the same way as the Debian machines (buildd and ci.debian.net) for testing purposes. As I've never used sbuild myself, I can't tell you how to set it up. But on ci.debian.net, we currently have the lxc backends which are setup with autopkgtest-build-lxc. Different backends may behave slightly different and we still have the ambition (but it will not happen any time soon I fear) to support isolation-machine which will be setup with a different tool. I'm absolutely not convinced that on the buildds and on ci.debian.net the environment is setup "in the same way" so maybe your challenge has no possible outcome. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1009757: ITP: libtie-cache-lru-perl -- Perl module that implements Least-Recently Used cache
Package: wnpp Severity: wishlist Owner: Paul Gevers X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libtie-cache-lru-perl Version : 20150301 Upstream Author : Michael G Schwern * URL : https://metacpan.org/release/Tie-Cache-LRU * License : GPL-1+ or Artistic Programming Lang: Perl Description : Perl module for Least-Recently Used cache This is an implementation of a least-recently used (LRU) cache keeping the cache in RAM. A LRU cache is similar to the kind of cache used by a web browser. New items are placed into the top of the cache. When the cache grows past its size limit, it throws away items off the bottom. The trick is that whenever an item is -accessed-, it is pulled back to the top. The end result of all this is that items which are frequently accessed tend to stay in the cache. Debian already has libtie-cache-perl, which is a different implementation of the same idea (they were even developed in competition), but this package is a dependency of the Logitech Mediaserver that I'm working on, which also needs libtie-cache-lru-expires-perl (to be ITPd). I intent to maintain this package under the Perl Team umbrella.
Re: rebuild of rpcbind (and other packages?) due to old debhelper bug 993316
Hi, On 09-04-2022 00:23, Michael Biebl wrote: # apt-file search -x ^/usr/lib/systemd/system/ | wc -l 122 I get the attached list of 65 source packages which install files into /usr/lib/systemd/system. I picked a random package from your list: caddy. It was uploaded on 2022-04-02, well after the fix of the bug in debhelper. Surely the cause of the files in that place is different (and no binNMU in 2021 could have fixed this package). Paul OpenPGP_signature Description: OpenPGP digital signature
Re: rebuild of rpcbind (and other packages?) due to old debhelper bug 993316
Hi, On 08-04-2022 19:40, Andrey Rahmatullin wrote: On Fri, Apr 08, 2022 at 05:25:11PM +0200, Vincent Lefevre wrote: Bug 993316 was fixed on 23 September 2021. Any reason why rpcbind hasn't been rebuilt yet? Was anything done for that to happen? Because otherwise the answer is "nobody did that". I would have assumed that this would be done when bug 993316 was closed. There is no mechanism to automatically rebuild affected packages when a bug in debhelper was fixed, or in any similar cases. I recall a binNMU bug was filed against the release.debian.org pseudo package to fix all affected packages. I can only assume that somehow this package slipped through the cracks. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
Hi, On 23-03-2022 12:32, Jonas Smedegaard wrote: Quoting Anthony Fok (2022-03-23 11:08:36) Rather than keeping this "Serious" bug open and keeping both gitsome and gh out of Debian testing, I think the simple solution of having gh "Conflicts: gitsome", which is one of the option specified in https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts, would suffice for now, allowing both packages to (re-)enter testing in the meantime. SZ, if you think the use of alternatives (such that both the gitsome and gh packages can be installed simultaneously) is a better solution, I'd be happy to work something out with you too. Please note that above Policy section covers only the functionality of that packaging hint, not its suitability. It is my understanding that both that specific use of Conflicts and the use of alternatives is only acceptable for executables providing same or at least largely overlapping) ABI. Do gitsome and gh provide same or quite similar ABI? It was already quoted in the bug report, policy is pretty clear (emphasis mine) (yes, I *suspect* that /usr/bin/gh does something quite different from reading the package descriptions): """ 10.1. Binaries Two different packages *must not* install programs with different functionality but with *the same filenames*. (The case of two programs having the same functionality but different implementations is handled via “alternatives” or the “Conflicts” mechanism. See Maintainer Scripts and Conflicting binary packages - Conflicts respectively.) If this case happens, one of the programs must be renamed. The maintainers should report this to the debian-devel mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, both programs must be renamed. """ Paul OpenPGP_signature Description: OpenPGP digital signature
Bits from the Release Team: bookworm freeze dates (preliminary)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [Message resent because the year was wrong] Dear all, We are currently considering the following dates as our freeze dates. If you are aware of major clashes of these dates with anything we depend on please let us know. We also like to stress again that we really would like to have a short Hard and Full Freeze (counting in weeks, rather than months), so please plan accordingly. If serious delays turn up during any of the Freeze steps, we rather (partially or completely) thaw bookworm again than staying frozen for a long time. 2023-01-12 - Milestone 1 - Transition and toolchain freeze 2023-02-12 - Milestone 2 - Soft Freeze 2023-03-12 - Milestone 3 - Hard Freeze - for key packages and packages without autopkgtests To be announced - Milestone 4 - Full Freeze On behalf of the Release Team, Paul -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmIvqMAACgkQnFyZ6wW9 dQopRgf/dkqYGQlfN8vARfT3xWYzeGG76kRzIw/DeUFrW1QAm7Im47SMmvJjwfEy 8L7Q2F7DSZfn/1Njg3DnNHvIGHAXm43Kx8EkfEk3ek5IsroVKIwuxk5CmjS/4D/S 8E8zdNQll0BzjDb6oT58ySNRB1+W2TM9GvDQ2ozZJ0JAlOHg5GMtd0veUXDyJ1Gt Vs0iHZrXgBQ4GTXI4Ig9npeYCrTAJMO0Pbm0JkyutaHECJ+ES1hRDG/tkiVoqPbZ JwKtZFJH5RwkSe8iBVwPJl0pEvZpQG/4ODTWGJsoGURPlauVEgCE40Z+24aWzkQA /OlzV92SVvXakwlpnz2Xx/FpAJbPQQ== =gUm+ -END PGP SIGNATURE- OpenPGP_signature Description: OpenPGP digital signature
Bug#1007177: ITP: libmediascan -- scanner to find media files and extract metadata from them
Package: wnpp Severity: wishlist Owner: Paul Gevers X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libmediascan Version : 0.1 Upstream Author : Andy Grundman * URL : https://github.com/andygrundman/libmediascan * License : GPL3.0 Programming Lang: C and Perl Description : scanner to find media files and extract metadata from them libmediascan consists of a C library and corresponding Perl module to: * Scan a file tree for media files * Generate audio, video, and image thumbnails at scan-time. * Determine DLNA profile information during scanning It supports change notification methods for background directory watching. The library depends on FFmpeg to handle video files, libjpeg/libpng/libgif for image and thumbnail support, and libexif for JPEG tags. libmediascan is an evolution of the work done on the Perl modules Audio::Scan and Image::Scale: http://search.cpan.org/dist/Audio-Scan http://search.cpan.org/dist/Image-Scale I intend to maintain this package inside the Perl team where its siblings are also maintained.
Re: Is removing smell from packages OK? (Was: Why? "Marked for autoremoval on 24 March due to xdelta3: #965883")
Hi all, Thanks Andreas, for taking care. On 25-02-2022 15:02, Andreas Tille wrote: My point was rather that the suggested salvage procedure might not raise any signal and I'm pretty sure that I would have lost track on this. Everybody is now free to help and fix the autopkgtest regression that causes the NMU to fail to migrate. """ /usr/bin/ld: cannot find -llzma: No such file or directory """ Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Legal advice regarding the NEW queue
Hi, Release Team member hat on, but not speaking on behalf of the team. I haven't consulted anybody on the idea I mention below. On 08-02-2022 14:59, Scott Kitterman wrote: If people want licensing and copyright issues to be treated like other RC bugs, I think the first step is to treat them like other RC bugs[1]. I have recently heard about somebody that wanted to do archive wide scanning as a service. At least I am open to add support to britney to block migration on license and copyright issues from such a service. Obviously the service would need to have a reasonable small amount of false positives and we should have an accepted process to handle those false positives. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: sid: texinfo : Depends: perlapi-5.32.1 but it is not installable
Hi, On 06-02-2022 22:05, Liang Yan wrote: Just wondering if anyone happen to know the problem. or just my mis-configration? https://lists.debian.org/debian-devel-announce/2022/02/msg0.html Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Rakudo has a transition tracker and then what ?
Hi Dod, On 03-02-2022 18:53, Dominique Dumont wrote: Hoping to automate this process, I've setup a transition tracker for Rakudo [1]. See https://lists.debian.org/debian-release/2022/02/msg00029.html and follow-up messages. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
Hi Ted, On 24-01-2022 19:44, Theodore Y. Ts'o wrote: No, dpkg-shlibsdeps doesn't save you. Again, consider the hypothetical package libshaky, which over the period of 9 months, has soname changes which generate (over time) packages libshaky3, libshaky4, libshaky6, libshaky7, and libshaky8. The latest version of libshaky sources will create the binary packages libshaky8, libshaky-bin, and libshaky-dev. Other various external packages such as say, shaky-cli uses libshaky4, shaky-gtk uses libshaky6, shaky-qt might use libshaky7, etc. Now suppose that there is a critical security bug fixed in the latest version of libshaky sources. So the security fix is might be fixed in libshaky8, but the same security bug that allows remote code execution as well as privileged escalation might apply to libshaky[3467] as well, but since the fix was only in the latest version of libshaky, you might as well have been using static libraries in libshaky. Except that is apparently not allowed by policy. Oops. I think this is the second time you write something like this, but for dynamically linked libraries, the rebuild happens (by the Release Team, (please use transition trackers for that) because we automatically track transitions [1]). Unless people don't follow the convention that your binary matches the SONAME. But nowadays we find those more and more due to autopkgtest (reverse dependencies that fail because they can't find the appropriate library). It becomes increasingly more difficult to hide the fact that your package is not named appropriately. Paul [1] https://release.debian.org/transitions/ OpenPGP_signature Description: OpenPGP digital signature
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
Hi, I'm not involved in ftp-master, but... On 21-01-2022 18:19, Andreas Tille wrote: Am Fri, Jan 21, 2022 at 09:51:12AM -0500 schrieb M. Zhou: I'd rather propose choice C. Because I to some extent understand both sides who support either A or B. I maintain bulky C++ packages, and I also had a little experience reviewing packages on behalf of ftp-team. A -- Some (e.g. C++) packages may frequently enter the NEW queue, with OLD src and NEW bins (e.g. SOVERSION bump). A portion of devs feel it is not necessary for frequently because it drastically slows down the maintainer's work. In the worst case, when the package finally passed the NEW queue, the maintainer may have to go through NEW queue again upon the next upload. (This is very likely to happen for tensorflow, etc). I have heard this argument and my mail was simply to find out what fellow developers think about this. IMHO the issue is sufficiently important to have some kind of documented consensus about this. It's not only the copyright that the ftp-master are responsible for. New binaries fill a place in the Debian namespace and they *are* the keepers of that. And https://lists.debian.org/debian-devel/2021/07/msg00231.html Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1003024: ITP: libimage-scale-perl -- fast, high-quality fixed-point image resizing
Package: wnpp Severity: wishlist Owner: Paul Gevers X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libimage-scale-perl Version : 0.14 Upstream Author : Andy Grundman * URL : https://metacpan.org/release/Image-Scale * License : GPL2+ Programming Lang: Perl Description : fast, high-quality fixed-point image resizing Image::Scale implements several resizing algorithms with a focus on low overhead, speed and minimal features. Algorithms available are: GD's copyResampled (floating-point) GD's copyResampled fixed-point (useful on embedded devices/NAS devices) GraphicsMagick's assortment of resize filters (floating-point) GraphicsMagick's Triangle filter in fixed-point Supported image formats include JPEG, GIF, PNG, and BMP for input, and JPEG and PNG for output. This module came about because the need to improve the very slow performance of floating-point resizing algorithms on platforms without a floating-point unit, such as ARM devices like the SheevaPlug, and the Sparc-based ReadyNAS Duo. Previously it would take many seconds to resize using GD on the ReadyNAS but the conversion to fixed-point with a little assembly code brings this down to the range of well under 1 second. I intent to maintain this package under the Perl Team umbrella. This package is a dependency of Logitech Squeezebox which I also ITP.
Re: releasing major library change to unstable without coordination
Hi, On 23-12-2021 15:03, Alexis Murzeau wrote: Isn't ci.debian.net doing automated builds with experimental version of dependencies ? ci.debian.net doesn't do builds except for autopkgtest that have the "needs-build" restriction, which we discourage unless really needed. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: releasing major library change to unstable without coordination
Hi, [I've read the rest of the thread so far, answering the transition question]. On 23-12-2021 00:45, Jonas Smedegaard wrote: Is it normal and ok to upload a new major release of a library to unstable, without either a) testing that reverse dependencies do not break, or b) coordinating with maintainers of reverse dpendencies _before_ such upload? What we (the Release Team) expects/hopes for is documented on the wiki [1]. A lot of the page is also valid for uploads that are known, expected or suspected to be intrusive. In case of doubt, please always coordinate with the Release Team (but don't overdo your doubt ;)). To answer your question, most people do what you expect, but not all. We (again, the Release Team) don't expect maintainers of libraries/core packages to fix all regressions caused by their uploads. What we do expect is communication. Either a plain warning (well) in advance (easy, but less effective) or by uploading to experimental, checking reverse (test) dependencies and filing (important) bugs, which are raised to serious once the upload to unstable happens. In either case, when breakage is expected, please give your reverse dependency some time to prepare to not have their package instantly RC buggy. Maybe an interesting note to all, if the bug has already aged at lower severity, the autoremoval counter starts counting immediately once the bug is raised to serious. The main point from my message may be: if we break unstable too much, we may not be able to have packages migrate to testing, because it gets harder and harder to find sets that are ready together. Having all that said, unstable is unstable. Expect breakage there. But I hope we can try to avoid unannounced large breakage when the breakage is expected. Paul [1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions OpenPGP_signature Description: OpenPGP digital signature
Re: Pb with version comparison
Hi Yadd, On 16-12-2021 19:07, Yadd wrote: * When launching another build (schroot) with this new package, build failed because dpkg considers 4.0.2+~cs54.26.36-1 < 4.0.2-9 and refuse to install gulp-4.0.2+~cs54.26.36-1 with node-is-plain-object paul@mulciber ~ $ dpkg --compare-versions 4.0.2+~cs54.26.36-1 gt 4.0.2-9 && echo true true I don't think dpkg thinks that, why do you? Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Addressing the spam from the AUTORM script
Hi Thomas, On 17-12-2021 13:38, Thomas Goirand wrote: It's been a long time I wanted to write this kind of message, but I'm unsure against which package I should report the bug. release.debian.org Would it be possible that instead, I get a single message on each AUTORM run, telling me about it? I very much would prefer a single message containing 99 identical lines, than 99 identical messages... The script sends messages to @packages.debian.org. How do you envision that it groups that in a sane way? Patches welcome, source lives here: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
Hi, On 06-12-2021 20:43, Noah Meyerhans wrote: One lesson we may take from Mint, though, is that it's not worth trying to patch Chromium as much as we'd like. Anything that we can do to simplify the Chromium packaging will help us keep the package up-to-date, which in turn will help us keep our users safer. In my opinion, we should be pretty aggressive about dropping as many of the Chromium patches as possible, even if that means we link against bundled/vendored dependencies. Legal/licensing considerations are still important and I don't know if we actually *can* ship builds based on the bundled stuff. But based on the number of patches we have to disable various things [2] or build against system dependencies [3], I can't help but think we'd have an easier time keeping this package fresh if we could drop some of those. I have good experience with some of my upstreams where they supported me by adapting their build system to enable building without the bundled/vendored dependencies. Has this been tried? Would it be worth pursuing? Paul OpenPGP_signature Description: OpenPGP digital signature
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
Hi Andres, On 05-12-2021 03:36, Andres Salomon wrote: So what's happening with chromium in both sid and stable? I saw on d-release that it was removed from testing (#998676 and #998732), with a discussion about ending security support for it in stable. I'm willing to help out with chromium packaging if the problem is simply lack of time (or I could just as easily help with something like ungoogled-chromium, #939406, if the plan is to have that in debian instead). Either way, both as a user and a developer, it is really not great to have chromium in limbo. :( The problem really is lack of maintenance. In my opinion, chromium deserves an active *team* to support it in Debian. What we have seen over the past years, are just (more or less) incidental uploads. Not enough for stable (we shipped it in bullseye because we had the impression support was picked up again, but alas). We'll not ship it in bookworm unless we see steady uploads in unstable and we see security uploads in stable. The security team doesn't have the bandwidth to do it themselves, they need a team to help them. Paul OpenPGP_signature Description: OpenPGP digital signature
