Bug#1082150: ITP: webext-vimium-firefox -- keyboard-based navigation and control (Firefox)
Package: wnpp Severity: wishlist Owner: Andreas Altergott X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: webext-vimium-firefox Version : 2.1.2 Upstream Contact: Phil Crosby * URL : https://vimium.github.io/ * License : MIT Programming Lang: JavaScript Description : keyboard-based navigation and control (Firefox) Vimium is a browser extension that provides keyboard-based navigation and control of the web in the spirit of the Vim editor. This package provides the Firefox version of the addon. - Why is this package useful/relevant? This extension allows one to use the Firefox web browser with Vim like navigation without the need of a mouse, which can be very comfortable for those used to Vim. - Is it a dependency for another package? No. - Do you use it? Yes. I love it. And it is actually one of the few packages I miss in Debian. - If there are other packages providing similar functionality, how does it compare? There are no other packages in debian which enhance the Firefox web browser with Vim like navigation. - How do you plan to maintain it? Inside a packaging team? I'd love to maintain it with the help of the the DebianWebextensionTeam (Mozilla WebExtension Packaging Team). - Are you looking for co-maintainers? No. But I don't mind it. Whatever fits the mozext-team best. - Do you need a sponsor? Yes.
More about removing more packages from unstable (Was: Bits from DPL)
Hi again, Am Thu, Sep 05, 2024 at 06:18:02PM + schrieb Scott Kitterman: > I'm willing to assume good faith and accept that was not your intention. > It's in the past. OK. > >I need to trust you here as the one who is doing the work. The > >discussion also was about a semi-automatic process which. Do you have > >some opinion about this? > > > I don't have any problem with a process that suggests to people doing QA work > in Debian that package removal might be appropriate based on some criteria. > I don't think that such a semi-automatic process relives the person filing > the RM bug from engaging their brain to decide if it makes sense. > > I can see how having such a tool that used criteria that has been socialized > within the project to some degree might reduce social pressure to not file > the bug. More people working on QA is always good. Nice we agree here. One more detail about package removals: As you might have seen there were about 200 removals of 32 bit architectures of r-bioc-* packages and I expect more r-cran-* packages to come. Do you see any chance to automate architecture specific removals, most favourably by dealing with a whole dependency tree. This would probably remove a lot of manual work from DDs as well as your own work. Kind regards Andreas. -- https://fam-tille.de
Re: Bits from DPL
Hi, Am Wed, Sep 04, 2024 at 11:29:39PM -0400 schrieb Scott Kitterman: > On Wednesday, September 4, 2024 6:22:14 PM EDT Pierre-Elliott Bécue wrote: > > > > OoC, what is your point, especially considering the quote of your own > > opinion Andreas made? > > > > This just seems passive-aggressive, and the fact he stepped up once > > doesn't mean he has the time or will to step up hundreds of times. > > I think it's odd that he would talk about how hesitant people are to touch > other packages when he in fact does it himself. I'm not sure who he thinks > he's speaking for, clearly not himself. I did it *after* someone with insight into the topic gave the according hint[1]. So the sequence was: 1. I filed ITS 2. Someone with insight suggested removal 3. Reassigned ITS to RM I personally see some difference between this sequence and a straight asking for removal. > I don't have statistics, but maintainer filed RM requests a pretty rare. My > impression is it's only a small fraction of the total. I processed a lot of > requests last night and almost none of the requests for package removal were > from maintainers. You are definitely the expert about package removals. > It probably was a little passive aggressive, but I don't appreciate the DPL > using the Bits from DPL message to punch down like that. If he has a point > to > make to further the discussion, it should be made as part of the discussion. My intention was to highlight interesting contributions to the entire discussion. If phrases like 'Scott Kitterman made a valid point' and 'I agree' came across as dismissive, I sincerely apologize—that was not my intent. I genuinely valued your point, and I added my own suggestion "based on defined criteria, it could help reduce some of the social pressure." Item 2. above could possibly be such a criterion, since you pointed to this actual example. > If he's only trying to bring the issue to the wider project's attention, then > I don't think picking one person's opinion to disagree with in Bits is very > appropriate. I'm sorry if there was any misunderstanding, but I'm unsure how my message gave the impression that I disagreed. Could you clarify which part led you to this conclusion? Also, just to clarify, I avoid using sarcasm in electronic communication, especially in Bits from the DPL, as it often doesn't translate well. > FWIW, all an automated process would do is create work for the FTP Team. > Those I would feel I have to scrutinize even more closely than ones filed by > a > human since no one has given it a sanity check before it gets to the FTP Team > to process. I need to trust you here as the one who is doing the work. The discussion also was about a semi-automatic process which. Do you have some opinion about this? Kind regards Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079816#8 -- https://fam-tille.de
Re: LPC: Support for Complex Cameras in Debian
Hi Ricardo, Am Tue, Sep 03, 2024 at 10:37:27PM +0200 schrieb Ricardo Ribalda Delgado: > ... > As a newer DD, I don't feel comfortable speaking on behalf of the > project just yet. I'm hoping someone from debian-dev or > debian-multimedia might be interested in participating, either in > person or virtually.s If you are a "newer DD" but with competence on the actual topic I wonder what some "older DD" who has no idea about the topic can do better than you? > Alternatively, if someone could spare 30-60 > minutes to discuss Debian's best approach with me before the event, > that would be immensely helpful. What actual question do you want to discuss? Kind regards Andreas. -- https://fam-tille.de
Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
Am Tue, Aug 20, 2024 at 06:35:52PM -0700 schrieb Otto Kekäläinen: > ... ACK to everything. > However, pushing for wider Salsa CI adoption I think makes sense as a > goal by itself, and I would be keen to hear what people think is a > reasonable way to proceed with that? ACK. What about configuring Salsa that Salsa CI is switched on by default? Since 2021 I'm discussing with Debian Java team (last mail about this in my DPL contact[1]) to not hide the "Switch Salsa CI on"-button which makes it extra hard to get Salsa CI for these packages. Not sure about other teams but IMHO the better strategy would be to make it extra hard to switch of Salsa CI. Kind regards Andreas. [1] https://lists.debian.org/debian-java/2024/06/msg7.html -- https://fam-tille.de
Re: Removing more packages from unstable
Am Tue, Aug 20, 2024 at 11:09:31AM +0200 schrieb Helmut Grohne: > > I considered adding popcon to the criteria before hitting send. In the > end, I opted for not including it based on my own cost/benefit analysis. > While popcon may be a signal for the benefit-of-keeping aspect, it > provides little value for the cost-of-keeping part that feels most > important to me. As you point out, popcon is partially considered via > the key package constraint. As others (e.g. Niels) point out, the cost > of a package largely is a function of our ability to modify it and long > lasting RC bugs are a relatively high quality signal indicating that a > package is difficult to modify. Either some of those many users > (according to popcon) eventually gets interested in doing the hard work, > or we should put it onto the chopping block. Even mailing the rc bug > would reset its last modified timer. These are very good arguments. > If there ends up being consensus for adding popcon as a signal, so be > it. I've explained my reasons and am not too strongly attached to > excluding popcon. Anyway I think while a low popcon should not really put a package on the potential removal list but a high popcon might be a good reason to remove the package from the list. My guess is that you will not find that many high popcon packages in your list so it will probably not become way shorter by removing high (by whatever definition of high) popcon packages. Thank you in any case for your investigation Andreas. -- https://fam-tille.de
Re: Removing more packages from unstable
Hi, Am Tue, Aug 20, 2024 at 02:51:49PM +0900 schrieb Simon Richter: > > enigmail > > Thunderbird has native GPG support now, including (well-hidden) support for > calling into the installed gpg binary to use a smartcard. > > > mutextrace > > Oof, I should fix that finally, because in principle a debugging layer to > find lock hierarchy violations would be good to have. > > > obs-websocket > > Websocket support was merged into the main program a while ago. To my understanding this reads like: We can remove enigmail and obs-websocket or what do you want to express? If so would you mind filing removal bugs? Kind regards Andreas. -- https://fam-tille.de
Re: Removing more packages from unstable
On 2024-08-20 Helmut Grohne wrote: > Hi fellow developers, > (modified resend, as first attempt didn't arrive) > please allow me to open a can of worms. Package removal from unstable. > Deciding when it is time to remove a package from unstable is difficult. > There may be users still and it is unclear whether keeping the package > imposes a cost. In this mail I want to argue for more aggressive package > removal and seek consensus on a way forward. +1 > What does a package cost? > There are various QA-related teams looking at packages from other [ a lot] I always notice this whenever I make a pretty minor transition, about half the packages I have to deal with are of dubious usefulness and quite unmaintainted. [...] > mixer.app [...] On one hand I am proud that I managed to remove it early from testing OTOH I should have had it removed from sid years ago. Bug filed now. cu Andreas
Re: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts
Hello, Anyone not interested in ancient history can skip this mail. On Thu, Aug 15, 2024 at 11:20:47PM +0100, Colin Watson wrote: > On 2024-07-14 (five days before the iproute2 change was made), there was > this conversation on #debian-devel: > > 19:14 Is there a reason why iproute2 ships a symlink > from /sbin/ip to /bin/ip? I've looked into the packaging repo and it > seems to predate the git log. I was involved with iproute2 during the era when some sbin->bin shuffling happened, but apparently `ip` moving happened long before and only other tools followed later on. >From debian/changelog: iproute (20010824-7) unstable; urgency=medium * Move `ip' binary to /bin to fix FHS violation (closes: Bug#134812) -- Juan Cespedes Mon, 4 Mar 2002 00:20:30 +0100 (My recollection was that formorer moved ip, but apparently not. Calling it a FHS violation is IMHO a very strong claim.) Also relevant: iproute (20051007-4) unstable; urgency=low * Moved *stat binaries to /usr/bin/ (Closes: #350703) [...] -- Alexander Wirt Sun, 5 Feb 2006 09:47:36 +0100 ... and ... iproute (20110629-1) unstable; urgency=low [ Alexander Wirt ] * Install ss to /bin instead of /sbin. [...] -- Andreas Henriksson Mon, 04 Jul 2011 17:29:04 +0200 FWIW I've personally supported sbin and bin merging at some point, just for the simple reason that I'll never get back all the time wasted on arguing with people who want things moved around (but refuse to take it up with upstream). Apparently this is something which is still taking up time and even causing new bugs. > ... > 19:52 petn-randall: > https://codesearch.debian.net/search?q=%2Fsbin%2Fip%5Cb&literal=0 has > a pretty non-trivial list of things that would need fixed before > removing that (and of course some false positives) While I generally don't support hard-coding paths, not having the sbin symlinks means we have nothing in the location where upstream install these tools, which I also think is a bad idea. (I'm not sure if other distros follows upstreams location, but I'm still willing to call having the tools in bin a Debian-ism.) For a current list of tools where we override the upstream install path, see debian/iproute2.install in the source package or at: https://salsa.debian.org/kernel-team/iproute2/-/blob/debian/sid/debian/iproute2.install > > I realize it wasn't petn-randall who made this change, but it seems a > big coincidence that the symlink was dropped a few days after this IRC > conversation; and yet it seems nobody bothered to do the most basic due > diligence that I pointed out here, which is kind of sad. (I fixed > wireless-tools after this change caused an RC bug there.) > > -- > Colin Watson (he/him) [cjwat...@debian.org] > Regards, Andreas Henriksson
Re: Accepting DEP14?
Am Sat, Aug 17, 2024 at 10:33:58AM +0200 schrieb Chris Hofstaedtler: > > > Add the following to the configuration file ~/.gbp.conf or > > debian/gbp.conf: > > Putting per-repository relevant settings into a global config and > not into the per-repo config seems to fly into the face of the DEP18 > spirit. I'd perfectly follow the DEP-14/DEP-18 spirit since if we have some common default any specifications inside team policies become void and we can get rid of those settings in ~/.gbp.conf. My personal preference would be if we make a pristine-tar branch default since this is what I observed in the wide majority of cases. > Maybe there is no issue with changing git-buildpackage after all > then. Yes. Kind regards Andreas. -- https://fam-tille.de
Re: Accepting DEP14?
Am Sat, Aug 17, 2024 at 10:17:19AM +0200 schrieb Chris Hofstaedtler: > On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote: > > IMO, and from discussions in the Debian Perl Group, the blocker is > > the conversion of existing repos, both on salsa (which should be > > doable via the API as suggested in the sketches mentioned above) and > > also locally for hundreds of developer machines [git fails horribly > > on the upstream/ → upstream/latest change]. > > I want to echo this pain. When changing the layout it seems almost > better to start from scratch. > > Additionally, in my opinion debian/latest is a mistake we should not > recommend. OK, I admit I do not mind about the actual names that are used. I mind about the fact that it makes sense to settle with some *common* repository layout for all our repositories to make sure that someone who wants to contribute to some random git repository feels home immediately. Sam said, gbp-buildpackage default is fine. If people agree here we could change DEP-14 to simply use this (despite now lots of repositories are featuring the currently suggested DEP-14 layout). Gregor and Chris underline that the choice of the names in DEP-14 are hard to convert. I'm fine with some better proposal. For me DEP-14 is an attempt to settle with some common default. I personally do not mind about the actual names. I guess its a requirement to have some automated conversation (which could be even done by Janitor for instance). If DEP-14 suggests something that fails here its hard to accept for many (including myself). Any ideas how we can come up with some suggestion that will finally enable us with some common reopsitory layout that enables automated conversion from any existing layout. IMHO we should move DEP-14 forward since having it an open suggestion for ages will not bring any progress. Kind regards Andreas. -- https://fam-tille.de
Re: Accepting DEP14?
Hi Andrey, Am Fri, Aug 16, 2024 at 07:17:52PM +0500 schrieb Andrey Rakhmatullin: > > > pristine-tar isn't the default either, so you need debian/gbp.conf if your > > > team uses it. > > > > That's correct but the teams I'm working in recommend something like: > > > > Add the following to the configuration file ~/.gbp.conf or > > debian/gbp.conf: > > Putting team-specific settings into the global ~/.gbp.conf is a bad idea > in my opinion, but also you can set DEP14 branches there in the same > way... Sure I can and probably would - but we need to decide about DEP-14 first. Kind regards Andreas. -- https://fam-tille.de
Re: Accepting DEP14?
Hi Jonas, Am Fri, Aug 16, 2024 at 02:12:21PM +0200 schrieb Jonas Smedegaard: > > Quoting Andreas Tille (2024-08-16 11:44:38) > > I prefer having no debian/gbp.conf at all in case the repository > > layout would fit team policy. > > I understand that it would be lovely if git-buildpackage supported DEP14 > without you needing to touch a thousand packages. I tried to express: I'm more than willing to convert all packages where I'm Uploader (most preferably) if DEP14 is accepted. > But do you really put on your DPL hat and raise that wishlist bug to a > matter for d-devel to debate and try solve? I tried to raise my DPL hat against my own obvious interest to rather do nothing. In other words: As DPL I consider DEP14 an advantage and would defend this even against my own interest. > Please do consider the simpler approach here: > > Step one: Discuss on d-devel if DEP14 can be accepted as-is. ... which I do. > Step two: Discuss in bugreports how various tools might be improved for > as exciting a user experience with DEP14 as sensible for each tool. In some discussions (written and aural at DebConf) I heard the opinion that a precondition for DEP-14 would be git-buildpackage support. I simply picked up this opinion as some potential reason why there is no progress for DEP-14. I do not think so which is why I wrote "If DEP14 might be accepted the motivation to fix bug #829444 would be probably way higher." Seems my wording was miserable enough to make you believe I would be in contrast to your suggestion, which is actually not. BTW, I do not think that the DPL hat can be (mis)used to draw technical decisions. I just wanted to know what might be the blocker for some decision that is pending since a long time. I'd be happy if you would understand that I mentioned my role only for the sake to learn about blockers, not to push into any direction. > Personally, I think DEP14 is usable as is, and look forward to have it > formally be declared done. Cool. So lets do this. > I do not, however, understand the details of > the DEP procedures well, however, so look forward to feedback from > others beter understanding those details. Same here. > ...but not details on git-buildpackage: Details on the formal DEP > procedures - unless those really are super intertwined. Until someone > knowledgable on DEP procedures explains how that necessitates solving > specific tooling issues as well, please pretty please discuss tooling > details, like git-buildpackage migration handling and/or default > settings, at the appropriate bugreports *without* cross-posting to > d-devel. I'm not fully sure why git-buildpackage should not be discussed here in a possible different thread. However, I agree that we can finalise the formal DEP process without mixing both discussions. Kind regards, Andreas. -- https://fam-tille.de
Re: Accepting DEP14?
Am Fri, Aug 16, 2024 at 02:58:40PM +0500 schrieb Andrey Rakhmatullin: > > pristine-tar isn't the default either, so you need debian/gbp.conf if your > team uses it. That's correct but the teams I'm working in recommend something like: Add the following to the configuration file ~/.gbp.conf or debian/gbp.conf: [DEFAULT] builder = ~/bin/git-pbuilder pristine-tar = True pbuilder-options=--source-only-changes (for instance in Debian Med team policy[1]) > Unless I've missed some recent changes. You did not miss anything, My statement was incomplete. Kind regards Andreas. [1] https://med-team.pages.debian.net/policy/ -- https://fam-tille.de
Re: Accepting DEP14?
Hi, Am Fri, Aug 16, 2024 at 11:09:58AM +0200 schrieb Andrea Pappacoda: > > In #829444 it has been proposed the addition of a new "layout" option to > gbp.conf, which would tell git-buildpackage which layout to follow, > allowing for a graceful migration. > > I've been thinking about a different approach though. What about adding > a warning to git-buildpackage when `debian-branch` and `upstream-branch` > are not set in gbp.conf? Compared to the `layout` option, it would have > the following benefits: > ... > How does it sound to you? Am I missing something? I prefer having no debian/gbp.conf at all in case the repository layout would fit team policy. So the question is whether git-buildpackage can cope with the old master + upstream + pristine-tar as well as debian/latest + upstream/latest + pristine-tar if no gbp.conf exists. Kind regards Andreas. -- https://fam-tille.de
Re: Accepting DEP14?
Hi Otto, Am Thu, Aug 15, 2024 at 01:43:40PM -0700 schrieb Otto Kekäläinen: > Yes to finalizing DEP-14 soon, but first I think we need to complete the > technical work to have git-buildpackage use DEP-14 branch names by default. Well, this is what I meant as a hen-egg-problem. It might support DEP-14 since it would be way easier to follow the DEP using the well-known and really convenient tool. However, it might be that Guido (in CC) is more motivated to adapt the tool to a DEP once its accepted. Guido, what do you think? > I tried implementing it but turned out a bit too involved.. Perhaps this should rather be discussed in the bug log. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829444 > Use DEP14 branch layout by default > = master -> debian/latest > = upstream -> upstream/latest > > Any hands available to help with this? As far as there are no concerns about DEP-14 any more it might make sense to do this. Kind regards Andreas. -- https://fam-tille.de
Accepting DEP14?
Hi, considering that it makes sense to settle with DEP14[1] first before we can decide about DEP18 I wonder what is finally needed to accept DEP14. I think its cruxial to make git-buildpackage supporting DEP14 per default[3] but I'm somehow sensing some hen-egg problem here what to do first. If DEP14 might be accepted the motivation to fix bug #829444 would be probably way higher. Just a personal note: All repositories where I'm uploader (>1000) are following git-buildpackage default layout and thus not compatible with the DEP. So accepting DEP14 would mean a lot of work for me (at least testing the suggested scripting solutions[4] carefully) and for my personal workflow I'm not really keen on pushing DEP14. However, wearing my DPL hat with the clear intention to streamline common workflows, I'd be happy if we would move forward here. Are there any blockers to accept this DEP which I might have missed? Kind regards Andreas. [1] https://dep-team.pages.debian.net/deps/dep14/ [2] https://salsa.debian.org/dep-team/deps/-/merge_requests/8 [3] https://bugs.debian.org/829444 [4] https://lists.debian.org/debian-devel/2020/09/msg00168.html https://lists.debian.org/debian-devel/2020/09/msg00172.html -- https://fam-tille.de
Updating delegation for the backports team
Backports Team delegation = I'm sorry for my mistake to copy-and-paste from last delegation text while not remembering Rhonda changed her name. I'd like to immediately fix the appointment for the Backports Team. The correct team member list is: - Alexander Wirt - Rhonda D'Vine - Micha Lenk This delegation addet the new member Micha Lenk - thanks to Micha for volunteering for this task. Sorry for Rhonda for my mistake in the latest, now invalid appointment. The delegation is not time-limited. It will be effective until further changes by present or future DPLs. Task Description The Backports Team oversee and maintain the well-being of Debian's backport service that allow Debian Developers to prepare backported packages for Debian users. Members of the Backports Team are responsible for tasks that include: - Defining the policy for backports upload, in consultation with Developers. - Running the archive infrastructure that powers the backports service, usually with the support of the FTP Masters. - Accepting and rejecting NEW packages that enter the backports repository (AKA "NEW queue processing" for the backports service). - Managing the keyring that control upload access to the backports service, performing tasks such as adding, removing, and updating keys. More info - - You can find the policy for backports upload at https://backports.debian.org/Contribute/ - More details on the activities of the Backports Team are available at <http://wiki.debian.org/Teams/Backports - If you want to help out the backports team and/or joining it, you're welcome to contact them at Thanks a lot for thw whole backports team to provide this service Andreas, Debian Project Leader. signature.asc Description: PGP signature
Re: i686 require SSE4.1-capable processor?
On Mon, 15 Jul 2024 17:31:30 +0500, Andrey Rakhmatullin wrote: >On Mon, Jul 15, 2024 at 01:42:50PM +0200, Andreas Ronnquist wrote: >> I'm maintaining a package (filezilla) which just got a bug report that >> it simply crashes on program start - It gets a SIGILL - "Illegal >> instruction". (#1076312 report [1]). >> >> After the reporter debugged it, it seems like it crashes on the >> assembler instruction "pinsrd", which looks like it was added in >> SSE4.1, while the reporter runs this on a >> >> Intel(R) Celeron(R) M CPU 420 @ 1.60GHz >> >> which only supports SSE2. (Full cpuinfo available in the report) - So, my >> question is - is this a cpu that is too old for Debian to support, or >> should we support it, and Debian gcc generates invalid code requiring SSE4.1 >> while it still should support SSE2? (Or is the problem something else >> completely?) > >Neither. >Packages built for the i386 arch need to conform to the i386 baseline, >which is currently i686. If a package contains a newer instruction it's a >bug in that package and gcc is not the cause of it, the package is. >https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0 >indeed contains at least one compile command with -msse4.1. > >(there is also a "workaround", adding a dep on some isa-support >subpackage, but it's unlikely to be the correct course of action here and >I still don't know why is it even allowed in general) > Yeah, I have discovered that it is indeed a cause of the d/rules in the filezilla package. I blame having taken over it recently, and still haven't learned the ins and outs of it. I'll take care of it. Thanks wRAR! -- Andreas Rönnquist mailingli...@gusnan.se gus...@debian.org pgpeJ_dw_ifoE.pgp Description: OpenPGP digital signatur
i686 require SSE4.1-capable processor?
Hi I'm maintaining a package (filezilla) which just got a bug report that it simply crashes on program start - It gets a SIGILL - "Illegal instruction". (#1076312 report [1]). After the reporter debugged it, it seems like it crashes on the assembler instruction "pinsrd", which looks like it was added in SSE4.1, while the reporter runs this on a Intel(R) Celeron(R) M CPU 420 @ 1.60GHz which only supports SSE2. (Full cpuinfo available in the report) - So, my question is - is this a cpu that is too old for Debian to support, or should we support it, and Debian gcc generates invalid code requiring SSE4.1 while it still should support SSE2? (Or is the problem something else completely?) -- Andreas Rönnquist mailingli...@gusnan.se gus...@debian.org [Please don't CC me, if I mail to a mailinglist, I am subscribed to it.] 1: https://bugs.debian.org/1076312
Re: DD's, Debian Mentors needs you!
Hi Phil, Am Sun, Jul 07, 2024 at 08:48:22AM +0100 schrieb Phil Wyett: > > Thank you for the kind words. I agree whole heartedly with your comments that > more people getting > involved to make for a better Debian mentors would be good. Debian mentors is > a great place to be > around and we all learn something being involved. Thanks to you and all your work for mentors.d.n. Just to clarify my mail about connecting to teams (which is done as I learned in response): I did by no means intended to lower the importance of mentors.d.n in general for Debian and newcomers. Thanks again Andreas. -- https://fam-tille.de
Re: DD's, Debian Mentors needs you!
Hi Phil, thanks for advertising Debian Mentors. Am Sat, Jul 06, 2024 at 02:45:33PM +0100 schrieb Phil Wyett: > Hi all DD's > > Debian Mentors[1] always struggles to find available Debian Developers for > final reviewing and > sponsoring of packages submitted too our part of the project. One thing I'm missing on mentors.d.n is that I it does not advertise existing teams. It happened from time to time that there was some sponsoring request of Debian Science, Debian Med or Debian Python Team related packages (surely others I did not notices). Asking on the relevant lists very easily helps getting the package in question sponsored. I have a personal sponsoring policy that I only sponsor from a Git repository in a team I'm working in. This has the advantage I can easily help by pushing some commit with extensive comment to teach the sponsee in some direct way. Making a sponsee aware how to work together with a team inside Debian is IMHO very important. Thus I would welcome if there could be some explicit hint to mentees to relevant teams. Kind regards Andreas. PS: Please do not understand my remark related to the packages below just a general remark fitting the subject. > We believe some packages are ready or very close to the quality for > sponsorship and we would request > any DD who has the time and is willing, to have a look at one or more of the > packages below and > possibly sponsor them into Debian. > > Mentors page: > https://mentors.debian.net/package/hexwalk/ > Request For Sponsorship (RFS): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065008 > > Mentors page: > https://mentors.debian.net/package/uriparser/ > Request For Sponsorship (RFS): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074542 > > Mentors page: > https://mentors.debian.net/package/mailgraph/ > Request For Sponsorship (RFS): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074552 > > Mentors page: > https://mentors.debian.net/package/dmidecode/ > Request For Sponsorship (RFS): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074553 > > Mentor page: > https://mentors.debian.net/package/selint/ > Request For Sponsorship (RFS): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074592 > > Your assistance will be extremely appreciated and if announcing a few at a > time on the 'devel' list > works, this could become a weekly thing. > > [1] https://mentors.debian.net > > Regards > > Phil > > -- > > Internet Relay Chat (IRC): kathenas > > Website: https://kathenas.org > > Instagram: https://instagram.com/kathenasorg/ > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- https://fam-tille.de
Re: Vendoring an unmaintained library?
On 2024-07-03 Alexandre Rossi wrote: [...] > #1073005 asks for the vendoring back of an unvendored library, arguing > that this particular library is unmaintained upstream, implying that the > vendored fork is better maintained. > My view on this is that if the vendored fork is better maintained, the > vendored fork should become the upstream of the Debian package. [...] FWIW both FreeBSD and Gentoo have switched to the suggested fork (last commit 2020), while the original source on sf is quite dead (last change 2013). cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: autoconf 2.72 to unstable?
On 2024-06-14 Gürkan Myczko wrote: [...] > Have never done mass bug filings, any easy way, preferably something copy > pastable, > non-interactive. Hej, How about mass-bug(1) in devscripts? cu Andreas
Re: DEP17 /usr-move: debootstrap set uploaded
Am Thu, Jun 06, 2024 at 08:14:18PM +0200 schrieb Étienne Mollier: > > 100% agreed. The care and excellence that you've brought to this work has > > been exceptional. > > Very much seconded, you have my thanks added on the stack! :) Seconded as well. You deserve a $DRINK / some sweets once we meet next time (no matter whether I might wear my DPL hat at hat time any more). ;-) Kind regards Andreas. -- https://fam-tille.de
Re: Bits from DPL
Am Mon, Jun 03, 2024 at 04:34:08PM +0200 schrieb gregor herrmann: > On Mon, 03 Jun 2024 11:00:34 +, Holger Levsen wrote: > > > > however, "costs to attend" are not the same as "costs while attending"... ACK. > Also & related, https://wiki.debian.org/HostingBSP#Sponsorships says > (emphasis mine): > > participants to a BSP can get a reimbursement of up to 100 USD for their > *travel fees*. > > whereas the discussions around the MiniDebConf Berlin were about > sponsored food, IIRC. > > Note that I'm not saying "Debian must pay for food for a week for > all people at any price, no matter what", just that "100 USD for > expenses" is not the same as "100 USD for their travel fees". > > No big deal, just maybe a chance for clarification before the next > Debian event :) The major friction point for MiniDebConf Berlin, in my opinion, was the need to raise a large amount of funds at very short notice. This should be avoided for future Debian events. My position is clear: I strongly support in-person meetings and thus I will do my best enabling active contributors to attend. If financial limitations are a barrier for active contributors, we should find ways to help. The amount of financial support needed can vary greatly depending on the region where the in-person meeting is happening. Therefore, please consider this as a rule of thumb, not a fixed (upper or lower) limit. More importantly, organizers should strive for realistic cost calculations in advance and communicate any changes as soon as possible. Finally, securing sponsors can be very helpful, and the probability of finding them is typically higher in regions with higher overall costs. Kind regards Andreas. -- https://fam-tille.de
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On 2024-05-29 Marco d'Itri wrote: > On May 28, Andreas Metzler wrote: >> I think it is bad choice to deliberately have different behavior for >> freshly installed and upgraded systems. Offering upgrades has always >> been one of the major selling points of Debian, and imho this >> implicitely includes that you do not get a worse or second class Debian >> installation when you upgrade it than if you installed from scratch. > I strongly disagree: it is a bad choice to change on upgrades a default > which may cause data loss. Hello, That is false dichotomy. data-loss will occur when people use /tmp or /var/tmp for persistent data-storage because "This has (for a couple of years) worked on Debian systems" not because "This has (for a couple of years) worked on *this* *specific* Debian system.". cu Andreas
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On 2024-05-28 Luca Boccassi wrote: [...] > - existing installations pre-trixie will get an orphaned tmpfiles.d in > /etc/ that keeps the existing behaviour unchanged (no cleanup of > /var/tmp) [...] Hello, I think it is bad choice to deliberately have different behavior for freshly installed and upgraded systems. Offering upgrades has always been one of the major selling points of Debian, and imho this implicitely includes that you do not get a worse or second class Debian installation when you upgrade it than if you installed from scratch. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: finally end single-person maintainership
Hi Stefano, Am Tue, May 21, 2024 at 02:36:47PM + schrieb Stefano Rivera: > Hi Philip (2024.05.21_10:05:59_+) > > Attempts at top-down imposition of new methods on Debian strike me as > > being unlikely to induce joy in anyone involved. > > Yeah, that doesn't fly in community projects like Debian at all. ACK. > However, there is a gap between getting a DEP approved and getting the > rest of the project to fully embrace it. That's something that takes > some leadership in the project. DPLs are in a great position to help > drive these changes forward. I confirm I see myself in the "help to get something happening" position. I'm fully aware that we can't push anything top-down. I see a big step forward in permitting some progress in the first place since I assume we have quite some volunteers who would implement this progress which is just not permitted by some rules we have. (My current challenge is to even find out what is broken first as I'm currently learning in the lintian case.) Kind regards Andreas. -- https://fam-tille.de
Re: finally end single-person maintainership
Am Wed, May 22, 2024 at 12:32:32AM +0200 schrieb Salvo Tomaselli: > > And what's the advantage? When an nmu happens the person doing it normally > doesn't bother to push to salsa anyway. At most I get a patch in the > bugreport, or I have to diff the packages and import the diff. IMHO this is a hen-egg-problem: If NMUer could expect packages beeing on Salsa we could require the NMUer to add at least a MR. I personally would prefer permissions to push even to the default branch and tag accordingly. The current situation of not having some default VCS at some default place makes injecting NMUs into the VCS impossible and it does not help to blame NMUers about this. Kind regards Andreas. -- https://fam-tille.de
Re: Any volunteers for lintian co-maintenance?
HO this is a valuable set of rules that can be used by alternative tools as well. Do you agree with this or not? As I wrote in my other mail in this thread[1] I could imagine some policy checker step after dh_clean. When thinking twice about it another step could be done before dh_builddeb which could detect lots of issues before the package is built and can save the unpackaging step. Are you targeting at this as well? Kind regards and thanks a lot for your inspiring input Andreas. [1] https://lists.debian.org/debian-devel/2024/05/msg00162.html
Re: Any volunteers for lintian co-maintenance?
tool. Accordingly, I am investing my volunteer time > on a different approach to scratch my itch. It might be interesting if you would go even more in detail. As I said I could imagine some `lintian-data` (`lintian-rules` whatever name you might prefer) that implement current policy and can be consumed by lintian as well as your imagined instant feedback tool. > -- PS on better newcomer tooling support -- > > I also feel we have also failed to look beyond linting for assisting > newcomers. Batch linting is our go to tool for all problems, but clever use > of on-line documentation and completion support help newcomers as well. My > current example problem is the synopsis part of the `Description` field. I > recall that as being something many people struggled with when I was new to > Debian. The lintian tool can spot some common cases and go "You probably > want to try again", which is not great but better than nothing. ACK > For comparison, in the on-line hover docs feature of `debputy`, I special > cased the hover docs for the synopsis to provide contextualized help. Like > "This is how your Synopsis would appear in search results from `apt search` > or `apt-get search`". It also takes the synopsis and inserts into the > sentence below > > This package provides [a|an|the] . > > Which was the test sentence I learned to use when I started contributing on > how to write the package synopsis. This feature is available to the > contributor regardless of whether there is a mistake, which enables them to > refine their synopsis at all times. > > That is obviously not the kind of tool that lintian is, but that is what I > feel we should provide as "first line" support tools for newcomers. Fully ACK that such a tool would be great. Kind regards and thanks a lot for your input Andreas. -- https://fam-tille.de
Re: Any volunteers for lintian co-maintenance?
Hi, this mail is a private response from Niels to my mail to the Debian Perl team where I explicitly asked for people helping out with lintian. So far the answer from Niels is the only response. Since he gave explicit permission to quote him in public I'm doing so hereby. Niels assumed that his answer "will not help my case" - but well, I do not think that hiding problems will help anybody else. At Tue, May 07, 2024 at 15:59:21 +0200 Andreas Tille wrote > Hi Perl folks, > ... > --> see full mail at > https://lists.debian.org/debian-perl/2024/05/msg0.html > [ From here I simply quote Niels unchanged - I'll comment probably tomorrow in detail ] Hi Andreas You are welcome to quote me in public, though I feel it will not help your cause. This reply is in private to you, so you can choose whether you want to quote me. I agree with the sentiment that important Debian tools would ideally be co-maintained. However, in the passing years, I have started to feel a disconnect with lintian, its direction and what I would like to see. I no longer use lintian and I am fundamentally not interested in picking up lintian anymore - neither as a user nor as a contributor. I have even uninstalled it from my machines. For now, I still "allow" it in my salsa-ci pipeline but my patience with it is thin. For me, lintian fails in all roles it has. It is not a good tool for newbies to get help, since it can only test build artifacts. As an example, your feedback look is a full package build followed by unpacking the package just so lintian can tell you have a typo on line 4. That is a massive waste of resources - notably developer time and mental bandwidth. It also fails as an archive QA tool in my view since the FTP masters have been unwilling to upgrade to any recent version of lintian. I think FTP master's argument lies with the very poor performance in certain corner cases that adversely affects larger packages (like linux). As a consequence, people now get auto-rejects when uploading because lintian on the FTP master server does not produce the same output as current lintian in stable or newer. For the record, I support the FTP masters here since the performance was quite horrible at some point (might be fixed, might not be) and that would just block benign uploads. In fact, I would go so far as to say that the FTP masters should remove lintian from their upload checks (partly because of this, partly because only source packages are reliably checked which neuters the original point of adding lintian to the upload queue). The latter half (archive-wide qa + performance + trust) might be fixable with a dedicated effort and then a lot of lobbying to restore's people trust in lintian. But that is a lot of work, and it will not solve the former (feedback cycles). The former requires a completely different mindset and scope for the tooling. To that end, I have decided to put my effort into `debputy` where I recently added support for linting *with* quickfixes, reformatting and editor support (the latter via LSP). I think that a much better approach to half of the issues that lintian emits and helps both newcomers and long term contributors to be much more productive. Especially for the editor support related parts, where people get instant feedback both on issues and the fix, automatic reformatting on save and completion suggestions. None of which lintian or wrap-and-sort are capable of. If I am successful, then lintian can specialize its efforts into issues only visible in packaged artifacts and thereby reduce it scope a bit. In that sense, my work might be a (minor) help to the Lintian team on the assumption they are willing to specialize more. But even if I am not successful with `debputy`, I cannot imagine I would consider returning to lintian. It does not scratch my itch and years of issues (some of which are still unfixed) have made me not want to have anything to do with the tool. Best of luck to Axel and anyone joining him to stop the bleeding. I do hope they are successful, since lintian still have valuable features for Debian as a whole that can be salvaged. But I am not going to be the "hero" that salvages that mess. If I am going to do heroics in this area, then it will be related to `debputy` with the aim to enable us to spend less mental bandwidth on daily packaging work. Best regards, Niels PS: In my view, the bleeding of lintian's quality started long before Axel joined the lintian maintenance team and I do not fault Axel for being unable to stop the bleeding. In my view, only a hero could have "managed" that at the expense of their mental health.
Correction: New appointments for the Debian Technical Committee: csmall
Dear fellow developers, sorry, the list of CTTE members in my last mail contained Simon McVittie but his term has ended already. Thanks to Simon for his previous work and here comes the corrected text (with no change but the correct list of members). As defined by our constitution (§6.2.2), the Debian Technical Committee has recommended the appointment to the committee of: * Craig Small I agree with their recommendation, and hereby appoint Craig as member of the Technical Committee, effective immediately. For reference, the nominations and votes are recorded at: https://bugs.debian.org/1065810 The Technical Committee now consists of: * Sean Whitton (chair) * Christoph Berg * Helmut Grohne * Matthew Vernon * Matthew Garrett * Stefano Rivera * Timo Röhling * Craig Small Task Description: The Technical Committee is established by the Debian Constitution, section 6. It is the body which makes the final decision on technical disputes in the Debian project. More info about the Technical Committee, including recent decisions, discussion and advice, may be found at: https://www.debian.org/devel/tech-ctte The previous CTTE Appointment mail can be found at: https://lists.debian.org/debian-devel-announce/2023/07/msg0.html Thanks to everyone on the committee who dedicate their time and skills towards Debian as well as good luck for Craig for the new position! Andreas, Debian Project Leader signature.asc Description: PGP signature
Re: Binary conflict between Midnight Commander and MinIO Client
Hi, Am Mon, Apr 22, 2024 at 09:28:29AM +0200 schrieb Philip Hands: > >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli > > Might I suggest that the link goes the other way, so that the symlink > lives in /usr/bin? That way the existence of the lib directory is > somewhat self-documenting. That's an interesting hint. In Debian Med we are using a common directories /usr/lib/debian-med/bin/ /usr/lib/debian-med/man/ where those binaries will be moved to and have some kind of a README.Debian template[1]. Changing this to have the real executable / manpage to /usr/lib/debian-med/* makes sense. We simply advise Debian Med users to set PATH to that dir and have all the name-clashed binaries inside Debian Med without additional interaction. Kind regards Andreas. [1] https://salsa.debian.org/med-team/ea-utils/-/blob/master/debian/README.Debian?ref_type=heads -- https://fam-tille.de
Re: Status of the t64 transition
Hi Sebastian, thank you for your work on t64 transition. Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher: I've spotted these Debian Med packages. > gentle > jellyfish > quorum > sbmltoolbox No idea how we can help here. Please let us know if we can do something. > anfo We like to fix gcc-12 issues (#1012893) in anfo but so far nobody managed to do so since it seems to be quite complex. If we are blocking progress with this package its probably a sign that it should be removed from Debian. > blasr We try to work on #1067374. > freebayes Upstream is working on bug #1067271. > vg This package is in a bad state in any case and we are aware of this. However, could you explain in how far is this affecting t64 transition since 32bit architectures are excluded? > If you maintain any of the packages above, please check their status and > help get them fixed. Any help in filing bugs, fixing packages, > requesting removals, etc. is appreciated so that we can look into > unblocking the whole stack and migrate it to testing. I fixed two packages of Debian Python Team and pinged about some packages in Debian Science Team. Kind regards Andreas. -- https://fam-tille.de
Re: Status of the t64 transition
On 2024-04-18 Sebastian Ramacher wrote: [...] > Let's start with the first category. Those are packages that could be > binNMUed, but there are issues that make those rebuilds not have the > desired effect. This list include packages that > * are BD-Uninstallabe, > * FTBFS but with out ftbfs-tagged RC bug, > * have hard-coded dependencies on pre-t64 libraries, > * have $oldlib | $newlib dependencies (those are at least wrong on >armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are >decrufted), > * have been rebuilt before all dependencies were built, > * have broken symbols/shlibs files producing incorrect dependencies, > * or might just be missing the binNMU (but those should be few). > hugin [...] Good morning, thanks for the update. Looking at hugin, I think it is fine on all release-architectures, none of the problems noted above apply here. Am I missing something? TIA, cu Andreas PS: fakeroot seems to be an important blocker not in the list.
Re: finally end single-person maintainership
Am Fri, Apr 12, 2024 at 09:36:25PM +0200 schrieb Bastian Blank: > > - I also think disallowing single-person maintainership would be very > > unwise, > > though I agree team maintenance in general is probably better than > > single-person maintainership. Still disallowing single-person > > maintainership > > doesnt make a team and motivation lost is often motivation lost forever. > > What would that even mean? What is a team anyway? It means you motivate others to do the work you might not be able to do by helping them in the first place. I gave other answers in several talks page[1]. Kind regards Andreas. [1] https://people.debian.org/~tille/talks/ -- https://fam-tille.de
Re: finally end single-person maintainership
Am Sat, Apr 13, 2024 at 01:16:37AM +0900 schrieb Simon Richter: > > For example, any repository that does not list debian/files and > debian/*.substvars in the gitignore will fail to build twice in a row, > because these files are created and are subsequently untracked. Sorry, no. We should teach people to build in a chroot which does not leave this stuff inside local debian/ dir. > Once people are familiar with how Debian packaging works, we can introduce > the git interfaces on top. Before that, git is more of a hindrance than a > benefit to new contributors, precisely because it looks familiar, but the > knowledge is not transferable. >From my mentoring work I can confirm this sequence is not necessary for everyone. You might have different experience, but I would not subscribe this as a general rule. Kind regards Andreas. -- https://fam-tille.de
Re: finally end single-person maintainership
understand. I'm exclusively using tarball based workflow. When creating a new package starting with importing an upstream tarball as first commit in a fresh repository (as I've shown in several live packaging workshops for instance at DebConf23). I create a local repository and a script that moves this to Salsa. > then pull them, > maybe into different branches, git-buildpackage maintains two or three branches: The main packaging branch and an upstream branch. The pristine-tar branch is optional (but default in the teams I'm working in) and just keeps the needed metainformation to create a byte identical tarball as downloaded by upstream. Maintaining these are no-brainers and done automatically by git-buildpackage (wrapped by routine-update). > and fight the diff config to let me > dirdiff two different commits. And the upstream pull will always pull > changes, not just only do it is there is an actual release (tag). I need to admit I do not understand what you mean since I never had to deal with those things. > None of that feels like an improvement over 'uscan'. One word for the > standard process of updating to a new version. And if the patches > still apply it's probably all done (I always do a meld review too to > see what changed). As I said routine-update is using `uscan` and checks whether patches apply cleanly. If not it stops and tells me I need to adjust patches. It also detects if there is just fuzz in patches, tells me to unfuzz this in some separate terminal and continues once I confirm this is done. > And I do just prefer having two directories rather than multiple > version on top of each other. My simple brain finds it a lot easier to > keep track of a version directory to diff between, rather than finding > the right runes to get git to give meld faked-up directories pointing > at revisions or branches. That's probably a matter of taste. For me its definitely not outweighting the advantages I mentioned above. > If someone can make a tool so that this workflow still works, but a > copy gets dumped into salsa, then I don't mind this new > requirement. But otherwise it seems like a big imposition. You can simply unpack your old and the new upstream tarball and do dirdiff as you want. Or am I missing something? > I do understand the argument that lots of different workflows adds > friction. But I'm just still using what used to be _the_ standard one > (insofar as we ever had such a thing). Putting everything in salsa/git > doesn't standardise workflows in itself. I think Ian/Sean identified 12 > different git-based methods in their dgit review. I agree that different workflows are not helpful. We have DEP14[1] ... but we have no efficient processes to a) accept DEPs b) dedicate to accepted DEPs > Josch's suggestion that just recording the workflow in metadata would > be useful is a good one. Then at least you know what other maintainers > are doing. And dgit's approach of unifying the archive representation > and the git representation is definitely progress in the right > direction. I was very sad to find that it didn't help us 'tarball > people' directly at all (except I guess to reduce exactly this > pressure to stop doing it and use git). I need to admit I'm not actively using dgit thus can't comment on this. But I consider myself a member of the group of 'tarball people'. I'm old enough to stick to conservative habits. The good thing of mentoring lots of newbies is that I learned a lot from them myself how to make my workflow way more efficient. > So why mandate salsa rather than make dgit more official? That lets > the people that want to use git use it for everything - even the > packages that were just uploaded as tarballs. And explicitly _doesn't_ > remove the archive VCS interface. And it supports all the git-based > workflows. (someone should probably tell IWJ this conversation is > occuring as he's taken a bit intererest in it, but no longer reads > debian-devel). Does than not solve a good chunk of this 'make it easy > to fix other packages using your standard tools' desire? As I said I'm lacking the expertise to compare my Salsa - gbp-buildpackage - workflow to some workflow with dgit. Refusing some common hosting platform simply does not work for Debian wide changes (Janitor and potential other tools which might help in transitions), no Salsa CI and other things that are simply not possible for packages outside Salsa. As last remark I'd like to say again thank you to my team mates who convinced me in 2007 (according to team metrics) to start with some VCS based workflow which finally enabled me to become as productive as I am now (despite I was arguing probably for 2-3 years the very same way as you did above. ;-) ). Kind regards Andreas. [1] https://dep-team.pages.debian.net/deps/dep14/ -- https://fam-tille.de
Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
Am Tue, Apr 09, 2024 at 01:03:10PM + schrieb Stefano Rivera: > > I have also noticed that the young people we manage to recruit are > > usually not interested too much in the boring gruntwork of maintaining > > important core packages (like adduser and sudo) but instead want to do > > "new" things. But, otoh, what would Debian be without sudo? Somebody > > needs to do that work as well. > > To some degree, this is self-fulfilling. Most core packages have a > maintainer. Drive-by contributions in a bug or MR are likely to go > ignored for years. Newbies aren't going to get pulled into these > packages, easily. > > Where core packages are up for adoption, they're probably pretty complex > and maybe not the best candidate for a new contributor. The best stuff > has probably already been adopted. > > All of this leads to the position we are in, where new contributors best > road into the project is into teams. And the best way to get some > experience is packaging something new in a team. > > I see one of the goals of promoting team maintenance as increasing the > pipeline of new contributors into the maintenance of core > infrastructure. Rather than having to wait for the current maintainers > to slowly fade away and salvage the result after years of problems. Very well said. Congratulations for remotely reading my mind and turn it into those clear words. Kind regards Andreas. -- https://fam-tille.de
Janitor (Was: About Package Maintenance)
Hi Colin, Am Tue, Apr 09, 2024 at 12:03:52PM +0100 schrieb Colin Watson: > I'm not sure how widely known it is, but the Janitor does have a > mechanism for overriding the versions of Debian it retains compatibility > with based on various considerations, and I've found it useful to land > changes there in the past so that its other facilities can still be > useful without getting in my way. Search for "compat_release" in > https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/k8s/policy.conf. Thanks a lot for this hint. I was not aware of this and for my use cases I'm happy with Janitor defaults since it makes sense for leaf packages as we usually maintain in the scientific software branch. When talking about criticism on Janitor: I personally do not see much sense in creating changes like Bump debhelper from old 10 to 11 and later Bump debhelper from old 11 to 12 etc. for packages that are not used for a long time. Thus I rather call Janitor tools right before uploading a package. But this are details. In my eyes the greatest thing in Janitor is that it proves that Debian wide changes can be done automatically and can be adjusted to users needs (by either commiting directly, create MR or to leave out packages or teams at request) and as I learned now can even work with fine graned adjustments. Kind regards Andreas. -- https://fam-tille.de
Re: finally end single-person maintainership
Hi Julien, Am Mon, Apr 08, 2024 at 03:45:48PM +0200 schrieb Julien Puydt: > > I only use salsa's git. That begs two questions: > - What do I miss by not using the web interface? If you are owner of a team repository you need to manage members. As far as I know this is only possible via web interface (I did not checked glab since I just learned in this thread about is existence.) This is sometimes a bit slow but acceptable for me since I need to deal with it once or twice a month. When intending to package something new I do not only fire up wnpp-check to look for some ITP bug but also seek on Salsa for some preliminary work done on this project without filing some ITP. I like this web search and in case you do some duplicated work you might miss it (see above for possible replacement by glab). For me Salsa CI is one of the greatest things we have. Its not "pure" Salsa but I'd say you are missing something if you are not using it. (Thanks a lot to those who are running Salsa CI!) > - What does that web interface have that people don't like? I confirm that logs from Salsa CI are sometimes a bit slow but I'm not sure whom to blame about this. For me it does not cross the borderline to "not like it" - but in Johannes Schauer wrote in this thread that slow clients might fail to show log files at all. For me the two biggest argument for using Salsa consequently are: - It enables more than one person to work on one package effectively - I've met lots of potential young contributors who expect somehow a modern collaboration tool and we are risking that young blood moves to other distros if we do not use it consequently Kind regards Andreas. -- https://fam-tille.de
Re: finally end single-person maintainership
Hi again, Am Sun, Apr 07, 2024 at 04:10:15PM +0200 schrieb Wouter Verhelst: > > > > What is your opinion about pushing logtool to Salsa? > > I did that as part of my latest upload :) > > https://salsa.debian.org/wouter/logtool Great. > (I realize now that I forgot to add VCS headers... ah well, next time > I'm sure) This happens. I was seeking Salsa before asking - if people do so they'll find it. > And that's not good, and we should work on those. > > I just don't think that mandating team maintenance drops those barriers. Do you think that mandating Salsa is a sensible step in this direction? Kind regards Andreas. -- https://fam-tille.de
Re: finally end single-person maintainership
Hi Wouter, Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst: > [Feel free to quote any part of this email which I wrote outside of this > mailinglist] OK, moving the discussion to debian-devel where it should belong. > Debian packages need to be well maintained. In some cases, having > multiple maintainers on a package improves the resulting quality of > packages. But in some other cases, it does not; one example for this > second case is my package "logtool", which I'm going to upload to fix > #1066251 soon and for which by the simple act of doing that I will > double the amount of uploads it's seen in the past five years (and the > number of uploads in the past 10 can still be counted on the fingers of > a single hand). > > This is not because it's not well maintained; it's because the package > just *does not require* a lot of work to be kept up to date: upstream > has not been active for over 20 years, but it still performs the job it > was designed to do, as it was designed to, and I see no need to have it > removed from the archive. What is your opinion about pushing logtool to Salsa? > A second good example is my package "nbd". Which is maintained on Salsa which I personally consider nice. > Similarly, the fact that a package has a "team" listed as its maintainer > not in any wayimply that the team has more than zero members. ACK, > If there are stupid barriers to helping people out by doing NMUs or > taking over packages, then by all means let's break down those barriers. I was sometimes confronted with those barriers. > But let's not try to "fix" a problem by introducing a rule that is, at > best, affecting something only very weakly related to the problem that > we are trying to solve. I would be happy to talk about rules that might help solving problems (as well as droping rules that are creating barriers). Kind regards Andreas. -- https://fam-tille.de
Re: Some t64 libraries already in testing; I'm confused
On 2024-03-31 Andreas Metzler wrote: [...] > Afaict these are broken, though: [...] > tnat64 0.06-1 false positive, grep error.
Re: Some t64 libraries already in testing; I'm confused
On 2024-03-31 Andreas Metzler wrote: > On 2024-03-31 Sven Joachim wrote: [...] >> Unfortunately the other four are not similar, but rather lacked a build >> dependency on dpkg-dev (>= 1.22.5) which would have prevented their >> migration to testing. Testing users on armel and armhf should avoid >> installing them and downgrade to the pre-t64 version if necessary. > All of those noted above except udns have already been fixed in sid. Afaict these are broken, though: cpdb-libs 2.0~b5-1.2 dante 1.4.3+dfsg-1 fuse 2.9.9-8.1 gambc 4.9.3-1.3 hdf5 1.10.10+repack-3.3 libdmapsharing 3.9.13-2 libgom 0.4-3 libgweather4 4.4.2-1 libgxps 0.3.2-4 libhinawa 4.0.1-2.2 llvm-toolchain-15 1:15.0.7-14 llvm-toolchain-16 1:16.0.6-24 llvm-toolchain-17 1:17.0.6-9 lomiri-ui-toolkit 1.3.5100+dfsg-1 ogre-1.12 1.12.10+dfsg2-6 pacman-package-manager 6.0.2-6 pangomm2.48 2.52.0-1 tnat64 0.06-1 udns 0.5-1 vte 1:0.28.2-6.1 cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Some t64 libraries already in testing; I'm confused
On 2024-03-31 Sven Joachim wrote: > On 2024-03-31 06:54 +0200, Andreas Metzler wrote: > > On 2024-03-30 Julian Gilbey wrote: [...] > >> Looking through testing, I see the following t64 libraries present: > >> libaio1t64 > >> libfyba0t64 > >> libglibmm-2.68-1t64 > >> libnetcdf19t64 > >> libudns0t64 > >> libczmq4t64 (virtual package; libczmq4 provides this) > > I have not checked all the others (libczmq4: "Undo 4.2.1-1.1. There are > > only 3 symbols with time_t, and they are not used in the distribution. > > Avoid to carry the package rename forever."), but suspect they are > > similar. > Unfortunately the other four are not similar, but rather lacked a build > dependency on dpkg-dev (>= 1.22.5) which would have prevented their > migration to testing. Testing users on armel and armhf should avoid > installing them and downgrade to the pre-t64 version if necessary. All of those noted above except udns have already been fixed in sid. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Some t64 libraries already in testing; I'm confused
On 2024-03-30 Julian Gilbey wrote: > My very limited understanding of this major transition was that the > t64 libraries are being held in unstable until (almost) everything is > ready, at which point there will be a coordinated migration into > testing. But I've now been asked to upgrade something on my testing > machine which pulls in a t64 library. Has something slipped through > the net, or is this intentional? > Looking through testing, I see the following t64 libraries present: > libaio1t64 > libfyba0t64 > libglibmm-2.68-1t64 > libnetcdf19t64 > libudns0t64 > libczmq4t64 (virtual package; libczmq4 provides this) Good morning, I also stumbled over libaio1t64 and looked at the changelog. It is not part of the transition in that it was simply rebuilt with different compiler flags and therefore broke the ABI. Instead source code changes were made to extend the ABI to support usage both from code built with t64 flags and without. I have not checked all the others (libczmq4: "Undo 4.2.1-1.1. There are only 3 symbols with time_t, and they are not used in the distribution. Avoid to carry the package rename forever."), but suspect they are similar. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: xz backdoor
On 2024-03-31 Wookey wrote: [...] > e.g. I remember it took me years to realise that I used _my_ public > key for signing, [...] Good morning, s/public/private/ - $recipient can then use your public key to verify the sig. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Debian testing/unstable users: beware of Firefox critical CVEs
On 2024-03-24 Samuel Henrique wrote: > Hello everyone, > Given our current time_t transition happening, which means packages > are blocked from migrating to testing for weeks, and that unstable > updates have become harder to apply, two critical CVE fixes for > Firefox became impossible to get it through the official repositories: [...] > I hope this is useful to those who are not aware of the issue yet. Good morning, Thanks for the heads-up. For my personal use I have simply rebuilt the sid package on trixie. However trying fix these kind of issues by rebuilding locally obviously does not scale, I will probably upgrade to unstable in due course. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Package marked for autoremoval due to closed bug?
Hi Paul, Am Fri, Mar 15, 2024 at 09:52:06PM +0100 schrieb Paul Gevers: > 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. I agree with Ian that it might make sense that Steve, who probably has a complete list of the bugs, can do this more safely than individual maintainers. (BTW, thanks again to Steve for doing all the work.) I think this migration has shown another problem which was not yet dicussed here. In Debian Med and R pkg team we identified packages where a time_t transition would be a) complex (there was no patch provided by time_t people) b) not helpful for users since usage on 32bit is probably zero Thus we considered it a good idea to remove 32bit architectures of those packages and its dependencies. This has shown that removing packages is a similarly time consuming way of dealing with this. The method to file individual bug reports for every single package on the side of the maintainer as well as dealing with the actual removal done by ftpmaster is quite inefficient. The removal bug for emboss[1] was filed six weeks ago (1 Feb 2024) and countless testing removal warnings were sent to the maintainer list since it is not fixed until now. Even worse for r-bioc-rhtslib[2] which had quite a tree of rdepends and kept several people (including ftpmaster) busy. Please understand me correctly: It is not blaming ftpmaster to be slow with ROM requests. Maybe I could have adjusted severity somehow - I just don't know any documentation what is appropriate or not. I made mistakes myself when filing ROM bugs against rdepends. My point is: I as a maintainer have control about what is inside the pool. But once a package is there I have a hard time to get it removed again. This does not make sense. We have tools who can generate a dependency tree. So filing separate bugs on one hand and deal with separate bugs on the other hand is somehow a rudiment from last century. I wished we could solve this more elegantly. Kind regards Andreas. [1] https://bugs.debian.org/1062371 [2] https://bugs.debian.org/1063376 -- http://fam-tille.de
Linker fails to find libraries in unstable but succeeds in testing
Hi, thanks to the next round of Lucas' FTBFS QA rebuilds (at least) one package of the R pkg team is affected by some strange linker issue #1066409 r-cran-v8: FTBFS: ld: cannot find -lv8: No such file or directory which boils down to[1] g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o V8.so RcppExports.o bindings.o -lv8 -lv8_libplatform -L/usr/lib/R/lib -lR /usr/bin/ld: cannot find -lv8: No such file or directory /usr/bin/ld: cannot find -lv8_libplatform: No such file or directory The Build-Depends libnode-dev provides both libraries and when I try to build the package under testing all is fine. Is there any linker issue involved that might be introduced in unstable? Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/r-cran-v8/-/jobs/5446089 -- http://fam-tille.de
Re: Package marked for autoremoval due to closed bug?
Am Thu, Mar 14, 2024 at 10:15:18PM -0700 schrieb Steve Langasek: > > 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? I'm in favor of important severity for those bugs maintainer can't do anything about. It creates a lot of noise with testing removal warnings. I simply remove all those testing removal warnings in my mailbox to cope with this and by doing so I'm probably missing real issues I should rather care about. Thanks to all who are involved in this complex migration Andreas. -- http://fam-tille.de
Re: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)
Hi Micha, Am Wed, Mar 13, 2024 at 06:25:02AM +0100 schrieb Micha Lenk: > What you are trying to accomplish is no regular bug reporting but some > manipulation of existing bugs. Hence the control server must be used directly > by sending your mail to cont...@bugs.debian.org instead of submit@... See > also the first sentence on https://www.debian.org/Bugs/server-control Works. Thanks for guiding me patiently Andreas. -- http://fam-tille.de
Re: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)
Hi Mattia, Am Mon, Mar 11, 2024 at 11:35:55PM +0100 schrieb Mattia Rizzolo: > On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote: > > I hope there is some better solution than sending single bug reports > > for those packages. If ftpmaster tooling really needs single bug > > reports I wonder how I can automatically create such bug reports with > > always the same text, just targeting at different binary packages. > > > > This also should include some means to work around the less than 5 > > bug reports per hour SPAM protection means of BTS. > > > clone the bug however many time you need and retitle the clones? What > matters for the ftp tooling is just the bug title, pretty much. > That's one single email... I admit I love this hint and tried to follow it first by this mail https://lists.debian.org/debian-r/2024/03/msg6.html To: sub...@bugs.debian.org, Debian R where I received the response "Package is missing" from BTS. So I simply tried to send this to some existing bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063376#53 by bouncing it to 1063...@bugs.debian.org Seems I did not understood BTS syntax and something is missing since nothing seems to happen regarding creation of new bugs. Any hint what might be wrong here? Kind regards Andreas. -- http://fam-tille.de
How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)
Hi, Am Mon, Mar 04, 2024 at 06:25:50PM + schrieb Thorsten Alteholz: > Control: tags -1 + moreinfo > > please file one RM bug for each package that needs to be partially removed. > This needs to be done even for dependencies of dependencies. > Please remove the moreinfo tag once that is done. As Thorsten wrote above[1] every single package needs its own bug to enable ftpmaster removing the binary packages of 32bit architectures for about 40 packages (currently affected by testing removals). I hope there is some better solution than sending single bug reports for those packages. If ftpmaster tooling really needs single bug reports I wonder how I can automatically create such bug reports with always the same text, just targeting at different binary packages. This also should include some means to work around the less than 5 bug reports per hour SPAM protection means of BTS. Any help would be welcome Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063376#23 -- http://fam-tille.de
Re: clustalw lost in debian/dists/sid/main/binary-i386/Packages.{gx}z ?
Am Mon, Mar 11, 2024 at 12:12:45PM + schrieb Colin Watson: > "rmadison clustalw" shows: Shame on me I always forget about rmadison which explains things perfectly. > So since clustalw/2.1+lgpl-7/i386 is still in oldstable and stable, it > has to be kept in the pool; files are only expired from the pool once > they're no longer referenced anywhere. (And yes, I think there's a > delay between removing references from index files and removing the > actual pool files, to avoid mirroring race conditions.) This makes perfectly sense. Thanks again for your patience Andreas. -- http://fam-tille.de
Re: clustalw lost in debian/dists/sid/main/binary-i386/Packages.{gx}z ?
Am Mon, Mar 11, 2024 at 11:41:42AM + schrieb Colin Watson: > Search for "clustalw" in https://ftp-master.debian.org/removals.txt: > > [Date: Mon, 26 Feb 2024 18:19:39 -] [ftpmaster: Thorsten Alteholz] > Removed the following packages from unstable: > > clustalw | 2.1+lgpl-7 | armel, armhf, i386 > Closed bugs: 1063063 > > --- Reason --- > ROM; emboss-lib does not support of 32 bit architectures any more > -- > > ... and in fact https://bugs.debian.org/1063063 seems to have been filed > by you? Yes, I've filed this and this was perfectly intended (even if I forgot that the bug is done meanwhile which I should have checked before asking here - sorry about this). It was just that all signs that this package exists are remaining and its just missing in the Packages file. So removing a package just means droping it from Packages file and all other things are cleaned up later on? Kind regards Andreas. -- http://fam-tille.de
clustalw lost in debian/dists/sid/main/binary-i386/Packages.{gx}z ?
Hi, I'm working on some time_t side effects on the emboss package and by doing so stumbled I upon the fact that i386 builds of packages with a Build-Dependency on clustalw are failing. You can see an example in Salsa CI for libbio-tools-run-alignment-clustalw-perl[1] which contains The following packages have unmet dependencies: builddeps:. : Depends: clustalw but it is not installable E: Unable to correct problems, you have held broken packages. When checking the package pool[2] I can find clustalw_2.1+lgpl-7_i386.deb which is easily installable in some chroot I created using sudo debootstrap --arch=i386 sid i386-chroot http://deb.debian.org/debian Debci seems to be fine in testing clustalw on all architectures[3] and according to build logs[4] all should be fine. Unfortunately wget -q -O - http://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.xz | xzgrep "Package: *clustalw" Packages.xz is empty and I wonder why. Is the Packages file for i386 just broken or is it me? Kind regards Andreas. [1] https://salsa.debian.org/perl-team/modules/packages/libbio-tools-run-alignment-clustalw-perl/-/jobs/5431253 [2] http://ftp.debian.org/debian/pool/main/c/clustalw/ [3] https://ci.debian.net/packages/c/clustalw/unstable/i386/ [4] https://buildd.debian.org/status/package.php?p=clustalw -- http://fam-tille.de
Re: Run Debian packaging tasks remotely with debusine.debian.net
Hi again, please forgot my reference to "rott" (which should have rather been "ratt") ... I'm just reading those other mails of fellow contributors having the same question. Sorry for the noise Andreas. Am Mon, Mar 11, 2024 at 11:53:10AM +0100 schrieb Andreas Tille: > Hi Colin, > > Am Fri, Mar 08, 2024 at 11:41:27AM + schrieb Colin Watson: > > > Speaking about Salsa CI: I would like to do what Enrico mentioned to > > > somehow re-run building some Salsa commit using sbuild and (optionally) > > > the autopkgtest on the result. > > > > We don't have direct support for building from git yet. Ian asked about > > that in Cambridge, and it's certainly a good idea though not currently > > in the funded plan - Raphaël gave a more detailed response starting from > > around 30:27 in the mini-DebConf video. > > Well, I've heard that question (would have had the same when watching > the talk). I was hoping that the time between the talk and the > annoucement here would have brought something new. ;-) > > > However, you can always build a source package from the commit in > > question, upload it to debusine, then start creating work requests from > > there. > > > > (This will become more interesting once we have collections and > > workflows properly in place; that will allow doing things like running > > autopkgtests of all the reverse-dependencies of a change you're > > experimenting with.) > > This kind of stuff - something like "`rott` but not on my local machine" > would be the most interesting thing for me to use debusine. > > > > > > > > > https://freexian-team.pages.debian.net/debusine/tutorials/getting-started-with-debusine.html > > > > > > This doc brought me just to creating the chroot. > > > > It goes on to describe "debusine import-debian-artifact", which you can > > use to upload packages to debusine, and "debusine create-work-request > > sbuild" based on a chroot you've created. > > > > We're definitely still at the stage where you have to poke around quite > > a bit to figure out exactly how to submit jobs, though. > > Thank you for your patient explanation >Andreas. > > -- > http://fam-tille.de > > -- http://fam-tille.de
Re: Run Debian packaging tasks remotely with debusine.debian.net
Hi Colin, Am Fri, Mar 08, 2024 at 11:41:27AM + schrieb Colin Watson: > > Speaking about Salsa CI: I would like to do what Enrico mentioned to > > somehow re-run building some Salsa commit using sbuild and (optionally) > > the autopkgtest on the result. > > We don't have direct support for building from git yet. Ian asked about > that in Cambridge, and it's certainly a good idea though not currently > in the funded plan - Raphaël gave a more detailed response starting from > around 30:27 in the mini-DebConf video. Well, I've heard that question (would have had the same when watching the talk). I was hoping that the time between the talk and the annoucement here would have brought something new. ;-) > However, you can always build a source package from the commit in > question, upload it to debusine, then start creating work requests from > there. > > (This will become more interesting once we have collections and > workflows properly in place; that will allow doing things like running > autopkgtests of all the reverse-dependencies of a change you're > experimenting with.) This kind of stuff - something like "`rott` but not on my local machine" would be the most interesting thing for me to use debusine. > > > > > > https://freexian-team.pages.debian.net/debusine/tutorials/getting-started-with-debusine.html > > > > This doc brought me just to creating the chroot. > > It goes on to describe "debusine import-debian-artifact", which you can > use to upload packages to debusine, and "debusine create-work-request > sbuild" based on a chroot you've created. > > We're definitely still at the stage where you have to poke around quite > a bit to figure out exactly how to submit jobs, though. Thank you for your patient explanation Andreas. -- http://fam-tille.de
Re: Run Debian packaging tasks remotely with debusine.debian.net
Hi Colin, Am Thu, Mar 07, 2024 at 05:06:48PM + schrieb Colin Watson: > https://freexian-team.pages.debian.net/debusine/ > > > https://meetings-archive.debian.net/pub/debian-meetings/2023/MiniDebConf-Cambridge/debusine.webm Looks good. > https://debusine.debian.net/ Jut created a token and run the first task (creating a chroot). > While for the moment Debusine may seem like a less polished version of > Salsa CI, it has very different goals, Speaking about Salsa CI: I would like to do what Enrico mentioned to somehow re-run building some Salsa commit using sbuild and (optionally) the autopkgtest on the result. > > https://freexian-team.pages.debian.net/debusine/tutorials/getting-started-with-debusine.html This doc brought me just to creating the chroot. > Please give us feedback, positive and negative; we want to make this a > tool that Debian contributors use efficiently and pleasantly. I'd love to but seems I need some kickstart help. Thanks a lot to all who worked on this Andreas. -- http://fam-tille.de
Re: dpkg --verify not helpful?
On 2024-03-02 Sven Joachim wrote:
> On 2024-03-02 08:47 +0100, Sven Joachim wrote:
>> On 2024-03-02 08:01 +0100, Andreas Metzler wrote:
>>> iirc it was recently proposed to add a suggestion to run dpkg --verify
>>> to the trixie upgrade notes to find missing files due to the usr-merge
>>> transition. (Cannot find the reference right now).
>>> However I just had file loss (due to libuuid changing its name to t64
>>> and back again) and dpkg --verify (and --audit) is happy:
[...]
>> The libuuid1t64 package has an unversioned Replaces: on libuuid1, so the
>> missing files belong to it. If you remove libuuid1t64, the files are
>> gone and libuuid1 needs to be reinstalled.
>> The libuuid1 package should do something to prevent that file loss,
>> e.g. declaring its own Replaces+Conflicts on libuuid1t64.
> Filed bug #1065242 for that problem. Thanks for noticing and bringing
> up the issue.
Hello,
thank you for the diagnosis and following up on fixing this.
FWIW
cd / && find /var/lib/dpkg/info -name '*.md5sums' -exec md5sum --check --quiet
{} +
can be used to doublecheck for files that are missing even if dpkg
--verify does not consider this to be a problem due to replaces.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
dpkg --verify not helpful?
Hello, iirc it was recently proposed to add a suggestion to run dpkg --verify to the trixie upgrade notes to find missing files due to the usr-merge transition. (Cannot find the reference right now). However I just had file loss (due to libuuid changing its name to t64 and back again) and dpkg --verify (and --audit) is happy: (sid)ametzler@argenau:/tmp$ ldd -r /usr/lib/x86_64-linux-gnu/libSM.so.6 | grep not libuuid.so.1 => not found (sid)ametzler@argenau:/tmp$ dpkg -s libuuid1 Package: libuuid1 Status: install ok installed [...] Version: 2.39.3-7 (sid)ametzler@argenau:/tmp$ dpkg --verify libuuid1 && echo success success (sid)ametzler@argenau:/tmp$ dpkg -L libuuid1 | grep /lib/ /usr/lib/x86_64-linux-gnu (sid)ametzler@argenau:/tmp$ grep /lib/ /var/lib/dpkg/info/libuui d1\:amd64.list /usr/lib/x86_64-linux-gnu (sid)ametzler@argenau:/tmp$ dpkg --contents /var/cache/apt/archives/libuuid1_2.39.3-7_amd64.deb | grep '\.so' -rw-r--r-- root/root 34872 2024-03-01 10:20 ./usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0 lrwxrwxrwx root/root 0 2024-03-01 10:20 ./usr/lib/x86_64-linux-gnu/libuuid.so.1 -> libuuid.so.1.3.0 cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: time_t and backports
On 2024-02-26 John Goerzen wrote:
> Hi folks,
> As a person that frequently uploads to bookworm-backports, I am
> wondering how we are handling the time_t transition there?
> The picture of synchronization with testing is a little complicated over
> there. If you change the default build flags, you produce unexpected
> surprises over bookworm. If you don't, the t64 packages aren't really
> t64.
Hello,
Imho you would need to undo the t64 rename for bpo instead of fiddling
with buildflags. We needed a transition because the whole distribution
needs to be built consistently with (or without) t64. bookworm is built
without.
If you backported a libfoo3 which had replaced libfoo2t64 things will
get complicated, it would be necessary to upload as libfoo3t32 but the
tooling (${t32:Provides} does not exist.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Can we switch off the testing removal messages related to t64 migration? (Was: Confusion over t64 migration)
Hi, Am Fri, Feb 09, 2024 at 06:46:58PM +0100 schrieb Andreas Metzler: > Looking at "your" bug #1062097 it looks like you were unlucky, mine all > had a fat warning "NOTICE: these changes must not be uploaded to > unstable yet!". I also was trapping into that pitfall when I was intending to fix an RC bug quickly and simply failed to read the whole message. Just happens and was reverted soon. > There was a little bit of discussion about the delay on > https://lists.debian.org/debian-release/2024/02/msg00272.html but it > has not yielded a plan yet. I perfectly understand that complex things might lead to delays. However, given that I'm in several teams with lots of libraries my mailbox gets filled with lots of messages about testing removals which are absolutely useless since I can't do anything about this. I wonder how we can get rid of these messages. Two things come into my mind: 1. Demote severity of the time_t related bugs to non-RC 2. Patch the script that sends testing removal warnings to ignore time_t related bugs It would be very convinient if this could be solved. Currently I simply remove all mails containing the pattern "testing removal" since I can't handle the current amount sensibly. Unfortunately that way I'm missing perfectly valid messages caused by "real" RC bugs. Just using the chance to thank all people working on time_t transition and release team for the generally helpful mails Andreas. -- http://fam-tille.de
Re: Confusion over t64 migration
On 2024-02-09 John Goerzen wrote: [...] > So at the moment, I am unclear why there are bugs filed with severity > serious that apparently cannot be fixed. Shouldn't they be normal with > a tag wontfix until the relevant dpkg changes are in unstable? > To put it another way, I'm not seeing why we are reporting RC bugs > against a bunch of packages before it is possible to fix them. [...] Hello John, Afaiui the transition has been delayed unexpectly. (#1063329). I *think* the priority was also chosen as signal to avoid unstable uploads for the already staged packages. Stuff should have happened quickly, before we entered the autoremoval timer. Looking at "your" bug #1062097 it looks like you were unlucky, mine all had a fat warning "NOTICE: these changes must not be uploaded to unstable yet!". There was a little bit of discussion about the delay on https://lists.debian.org/debian-release/2024/02/msg00272.html but it has not yielded a plan yet. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
On 2024-02-06 Helmut Grohne wrote:
> Package: libselinux1t64
[...]> This looks fairly innocuous. We create a minimal sid chroot and install
> libselinux1t64 using apt. What could possibly go wrong? Well, apt thinks
> that it would be a good idea to avoid coinstalling breaking packages and
> first removes libselinux1 before proceeding to install libselinux1t64.
> Unfortunately, libselinux1 is transitively essential and dpkg links it,
[...]
> both dpkg and tar are now broken. This is pretty bad. To make matters
> worse, the situation arises from the combination of Breaks + Provides
[...]
Hello,
color me stupid but isn't this fishy?
Package: libselinux1t64
Replaces: libselinux1
Provides: libselinux1 (= 3.5-2.1~exp1)
Breaks: libselinux1 (<< 3.5-2.1~exp1)
Afaiui libselinux1t64 must not fullfill dpkg 1.22.4's dependency on
"libselinux1 (>= 3.1~)". dpkg needs to be rebuilt and the rebuilt
version gets a dep on "libselinux1t64 (>= 3.5)".
Will ${t64:Provides} stop expanding to "libselinux1 = ${binary:Version
for real t64-builds? (The ones in experimental are not.) If that is case
this bug and this way of testing does not make sense.
Otherwise the plan looks flawed.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Re: 64-bit time_t transition in progress
On 2024-02-06 Alberto Garcia wrote: > On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote: > > In fact, none of the t64 binaries currently being uploaded > > to experimental have the final ABI either, we're just using > > experimental to clear binary NEW. > I was having a look at two of the packages that I maintain that have > t64 binaries in experimental and I noticed that while the binary > package does have a different name the .so files themselves are the > same. Is this expected when we're talking about an ABI break? Hello Alberto, It is expected for this ABI break yes. Essentially we are just doing a rebuild-everything-involved while making sure the package interdependencies avoid a (breaking) mixture. This is similar what we did when the C++ ABI changed.[1] cu Andreas https://lists.debian.org/debian-release/2005/04/msg00153.html -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Bug#698988: O: nvi - 4.4BSD re-implementation of vi
On 2024-02-05 Tobias Heider wrote: [...] > As an active nvi user I would love to step up and help, but the biggest > problem I see is that the choice of upstream project. Since the original > is gone there isn't a clear successor. > The BSDs all have their own forks which diverged over time (and those don't > build on Linux). > The other two options there are today are https://repo.or.cz/nvi.git which > d/control currently points to and more recently > https://github.com/lichray/nvi2. > The first has a very low commit frequency (last commit was 2020, before > that 2016) and sticks very closely to the original source. nvi2 has added > new features such as multibyte support and is starting to receive bug fixes > and features from the different *BSD forks. > I have been thinking of proposing a new package for nvi2 but maybe it > would make more sense to move this one to the more active upstream. > It looks like some of the issues we are carrying patches for in Debian > might be fixed there already and if not they seem active enough to > merge our fixes. > What would be the best way forward here? ITA and eventually switch the > upstream or start a new package and let this one continue its slow > death? Hello Thomas, On one hand it depends on whether there is significant value in keeping the other nvi around, i.e. a significant part of the userbase would be reluctant to switch. (I have no opinion on that I use vim ;-) On the other hand reducing the number of QA-maintained packages is a strong argument for switching. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: 64-bit time_t transition in progress
On 2024-02-03 Sebastian Andrzej Siewior wrote: > On 2024-02-02 08:43:52 [-0800], Steve Langasek wrote: >> debian-devel-announce wouldn't let me attach the file, but for those on >> debian-devel at least, you can find the dd-list of to-be-NMUed source >> packages attached. > OpenSSL is on the list. I did not see a NMU bug report. Was the bug > missed or can it be removed the list of packages that require a NMU? "These (0-day) NMUs started on Monday, and about 500 libraries have been uploaded to experimental so far. The goal is to get all source packages that can be SRUed to experimental uploaded by this weekend." The fact that no "We are done" message followed suggests that Steve and his colleagues are still working on it and will get to OpenSSL in due time. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Policy: versioning between releases
On 2024-01-21 Matthias Urlichs wrote: > On 21.01.24 15:34, Andreas Metzler 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. eah, but it still answers your question. ... > 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. ... If testing's foo 2.2 required bar >> 1.0.42 it would need to have a respective *versioned* dependency. > Yes I know that this cannot happen when people simply dist-upgrade, [...] I strongly disagree. A dist-upgrade is not atomic. foo and bar will/can be upgraded at separated dpkg runs by apt. If the dependencies are not strong enough we would see breakage. cu Andreas
Re: Policy: versioning between releases
On 2024-01-21 Matthias Urlichs wrote: > question: policy 3.5 states, rather unequivocally, >Every package must specify the dependency information about other >packages that are required for the first to work correctly. > Now … does that apply to crossing release boundaries? Specifically, if > foo/testing requires bar >=1.1 to work but just states "Depends: bar >=1", > and bar/stable is 1.0.42 … is that a bug? If so which severity? > If not, shouldn't that be mentioned somewhere in Policy? Offhand I didn't > find anything that even mentions Debian suites / releases, but admittedly I > only skimmed the table of content and didn't re-read the whole thing. Hello, I also do not think policy has anything to say about our release system. However according to our release notes we only support upgrading from release x to x+1, skipping releases is not allowed. This implies that one may/should change "Depends: bar (>= 1.12)" to "Depends: bar" (in an upload to sid) once we have made a stable release that includes at least bar 1.12. IIRC https://janitor.debian.net/scrub-obsolete/ implements this algoritm. cu Andreas
Debian Med video meeting today Saturday 2024-01-13 19:00 UTC
Hi, this is the call for the next video meeting of the Debian Med team that are an established means to organise the tasks inside our team. Meetings usually take us only 15-20min depending what we are talking about and how many people are joining. The next meeting is tomorrow https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240113T19 The meeting will happen at the Debian Social channel https://jitsi.debian.social/DebianMedCovid19 The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some items: - Python 3.12 transition - Evaluation of advent bug squashing - Status outreachy project Newcomers are always welcome. See you today Andreas. -- http://fam-tille.de
Debian Med sprint February 16.-18. 2024 in Berlin (in person meeting)
Hi, the Debian Med team will held its yearly in person meeting from Friday, February 16 (evening) until Sunday, February 18 (evening) in Berlin. For more detailed information please visit the Wiki page[1] and if you like to join our small meeting with bug squashing (may be Python 3.12 bug fixing etc.) you are perfectly welcome to add your name to the list of attendees. Looking forward to see you all Andreas. [1] https://wiki.debian.org/Sprints/2023/DebianMed2024 -- http://fam-tille.de
Re: DebGPT: how LLM can help debian development? demo available.
Am Wed, Jan 03, 2024 at 01:06:25PM +0100 schrieb Andrey Rakhmatullin: > On Wed, Jan 03, 2024 at 11:33:06AM +0200, Andrius Merkys wrote: > > On 2024-01-03 11:12, Andrey Rakhmatullin wrote: > > > On Wed, Jan 03, 2024 at 09:58:33AM +0200, Andrius Merkys wrote: > > > > To me the most time consuming task in Debian recently is the Python > > > > transitions. I wonder whether DebGPT could help with them. Maybe there > > > > are > > > > other, non-Debian-specific GPTs for this task, but I would prefer a > > > > Debian > > > > one. > > > As "transitions" is too broad, can you list actual problems you spend time > > > on for them? > > > > Mostly failing tests, and mostly due to API changes between subsequent > > Python 3.x versions. > So the solution is either find a patch in the upstream repo (committed or > proposed in issues/PRs) or write one yourself. Not sure what can AI help > here with. Well, may be people replacing 'assertEquals' by the new name 'assertEqual'[1] could talk with some GPT first how much work all their downstreams might have due to this kind of estetic changes to find patches? In the last year I've seen quite some changes which do not obviously serve any better purpose than fitting some esthetics pattern breaking some API. (The s/assertEquals/assertEqual/ one is not the only example.) Kind regards Andreas. [1] https://salsa.debian.org/python-team/packages/pypandoc/-/blob/debian/master/debian/patches/0005-Python3.12.patch?ref_type=heads -- http://fam-tille.de
Re: Sunsetting Debtags
[Sorry for my late reply] Dear Enrico, Am Sun, Nov 26, 2023 at 07:31:33PM +0100 schrieb Jonas Smedegaard: > Quoting Enrico Zini (2023-11-26 17:01:11) > > about a year ago I announced the intention of letting go of Debtags[1]. > > > > No successor has happened to carry over maintenance since then, so it's > > time to follow my own advice[2] and properly let go. > > Thanks a lot for all the work poured into debtags, by you, Enrico and by > everyone else contributing to that project. > > It remember the [DC5 talk] (and just now revisite the [video]), and I > recall my excitement when later same year it aptitude 0.4.0 gained > support for tag-based browsing and querying, and some years later > playing with [goplay]. I totally agree with Jonas and I like to thank you a lot for all your work. I wished I could have supported you more with DebTags since I was considering it a great and helpful system. Thanks a lot for all your work Andreas. -- http://fam-tille.de
Re: Bug#1058807: ITP: acme.sh -- Pure unix shell script implementing ACME client protocol
On 2023-12-16 Jérémy Lal wrote: [...] > * Package name: acme.sh > Version : 3.0.7 > Upstream Contact: w...@neilpang.com > * URL : https://acme.sh > * License : GPL-3 > Programming Lang: Shell > Description : Pure unix shell script implementing ACME client protocol [...] > This acme.sh tool is a must-have for everyone who stumbled upon > certbot shotcomings. It is odd that it isn't already in debian. Good, morning, letsencrypt.org lists 6 bash-implementations of the acme protocol, I do not think it is surprising that not all of them are packaged (letsencrypt.sh/dehydrated has been available in Debian forever). Not trying to discourage you from packaging, at a first glance acme.sh seems to be very much alive project. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Debian Med video meeting tomorrow Saturday 2023-12-09 19:00 UTC
Hi, this is the call for the next video meeting of the Debian Med team that are an established means to organise the tasks inside our team. Meetings usually take us only 15-20min depending what we are talking about and how many people are joining. The next meeting is tomorrow https://www.timeanddate.com/worldclock/fixedtime.html?iso=20231209T19 Despite technical issues of the last meeting I think we stick to the known Debian Social channel https://jitsi.debian.social/DebianMedCovid19 The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some items: - Status of BioConductor transition - Python 3.12 transition - Advent bug squashing Newcomers are always welcome. See you tomorrow Andreas. -- http://fam-tille.de
Re: Signature strength of .dsc
On 2023-12-06 Dimitri John Ledkov wrote: [...] > May I also do a mass bug file against the above set of packages, at > wishlist priority to nudge maintainers (or QA or Janitor) to make an > upload? > ideally bundled with any other reasonable modernisations. As such an > algorithm indicates that the package is likely to be either very > stable or in potential need of a bit of TLC ? [...] Hello, Imho submitting another (minor/wishlist cosmetic) bug-report against already neglected packages does not make sense. It is not like Debian QA is bored and has no idea where to spend effort. It should be easily possible to order/filter source packages by upload date using udd, if one were interested in investing love in packages like these. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1056784: ITP: bankstown -- barebones, fast LV2 bass enhancement plugin
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: bankstown Version : 1.0.0 Upstream Contact: https://github.com/chadmed/bankstown/issues * URL : https://github.com/chadmed/bankstown * License : MIT Programming Lang: Rust Description : barebones, fast LV2 bass enhancement plugin Description --- Speakers found in small devices have trouble reproducing bass and sub-bass faithfully. This is because they are power and space constrained, and cannot move the amount of air required to reproduce such low frequencies at audible volumes. Designers of modern devices get around this problem by taking advantage of the fact that humans are very easy to fool. We generate harmonics of bass and sub-bass frequencies to trick the human brain into thinking there is more bass than there really is. . This package contains a lv2 plugin implementing halfway-decent three-stage psychoacoustic bass approximation. Team maintenance --- I've discussed both with Debian rust-team and bananas-team and we've concluded that since this package does not yet integrate well with existing debcargo-conf tooling, we'll maintain the package under the bananas-team umbrella. Preliminary packaging is available at: https://salsa.debian.org/bananas-team/bankstown Naming --- Upstream name: bankstown crates.io name: bankstown-lv2 My proposition is that we use the upstream name as debian source name (bankstown) and then use `lv2-bankstown` binary package name, as bankstown is a lv2 plugin and that would fit generic naming conventions in Debian about packages fitting into a particular ecosystem. For reference, fedora packaging: https://src.fedoraproject.org/rpms/rust-bankstown-lv2/blob/rawhide/f/rust-bankstown-lv2.spec
Re: New Essential package procps-base
Hello, On Tue, Nov 14, 2023 at 05:29:01PM +1100, Craig Small wrote: > Hello, > For quite some time (since 2006!) there has been a discussion at[1] about > changing from the sysvinit-utils version of pidof to the procps one. A > quick scan of the various distributions shows that only Debian and Ubuntu > (and I assume most other downstreams) use the sysvinit-utils version. I support using procps implementation in Debian, to align us with the rest of the world. > > So to rehash some old drafts, here's the proposal. > > What: > Create a new package procps-base. This uses the existing procps source > package and just enable building of pidof. procps-base will be an Essential > package and only contain pidof. I however do not think pidof needs to be part of the Essential set. Instead I think pidof can just be part of procps package. The sysvinit-utils package will then pull in procps via a dependency (once sysvinit-utils stops being Essential), which would smooth the transition for all sysvinit users until LSB pidofproc has been implemented in all init scripts. > > Why: > This would bring the pidof variant in line with other distributions. > sysvinit-utils would no longer need to be Essential (though that's a > separate issue) and would only have init-d-script, fstab-decode, and > killall5. > > The majority of usage of pidof is in init or pre/post scripts, which really > should be using the LSB pidofproc function. That function in turn > optionally uses pidof if the pidfile parameter is not given. That's > probably a way forward for sometime in the future to not need procps-base > Essential, but it is a way off. Additionally most uses of pidof is `if pidof [...]; then` which will expand to false/else when the pidof command is not available (which it should be on all "normal" systems, as procps is already Priority important). A number of years ago I tested booting a regular debootstrapped system (with all priority important packages, etc) with sysvinit-utils excluded and that did not show a single warning about missing pidof. Someone might want to repeat that experiment. > > sysvinit-utils requires only libc6 while procps-base require libproc-2 but > this is the same library used for the ps,top,w etc tools which are > installed on most systems. > > > 1: https://bugs.debian.org/810018 Regards, Andreas Henriksson
Bug#1055897: ITP: speakersafetyd -- speaker protection daemon for embedded Linux systems
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: speakersafetyd Version : 0.1.4 Upstream Contact: https://github.com/AsahiLinux/speakersafetyd/issues * URL : https://github.com/AsahiLinux/speakersafetyd/ * License : MIT Programming Lang: Rust Description : speaker protection daemon for embedded Linux systems Speaker protection for Apple Silicon (and potentially other) laptops with built-in speakers. The Apple M1, M2, etc laptops do not have protection for melting speakers in hardware, so need this (unlike many other laptops). The implementation is generic enough that it could in the future support other systems as well (eg. many embedded systems might be in the same situation if they have speakers). I hope to maintain this package in the rust-team (with the help of the bananas-team). Preliminary packaging available at: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/560 See also: https://wiki.debian.org/Teams/Bananas Regards, Andreas Henriksson
Re: Linking coreutils against OpenSSL
On 2023-11-11 Michael Stone wrote:
> On Sat, Nov 11, 2023 at 11:50:31AM +0100, Andreas Metzler wrote:
> > you seem to have missed/deleted the paragraph where Ansgar suggested how
> > to do this *without* tradeoff. ("explicitly disable/enable build options
> > per arch")
> No, I didn't. That was in my original email and is one of the possibilities
> for future versions depending on the feedback from people testing to guide
> whether it makes sense to make this per-arch rather than global.
Hm. Would you mind explaining why you chose to not implement this but
instead only used a per-arch build-dep? (With the downside of wrong
builds on dirty chroots and slent breakage when a respective feature
is not found)?
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Re: Linking coreutils against OpenSSL
On 2023-11-10 Michael Stone wrote:
> On Fri, Nov 10, 2023 at 03:10:42PM +0100, Ansgar wrote:
>> Please avoid producing different results depending on the build
>> environment. That just results in non-reproducible issues in unclean
>> environments (suddenly different dependencies, different features,
>> ...).
> I think that is an acceptable tradeoff at this time; the only difference
> will be the dependencies, but that is the intent. Automated buildd packages
> should be stable. Based on further experience and feedback, one of the other
> options could be chosen instead. (I'm particularly interested in hearing
> from people who compare the different builds on arm, as that is where
> there's been an assertion of a performance regression.)
Hello,
you seem to have missed/deleted the paragraph where Ansgar suggested how
to do this *without* tradeoff. ("explicitly disable/enable build options
per arch")
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru coreutils-9.4/debian/rules coreutils-9.4/debian/rules
--- coreutils-9.4/debian/rules 2023-11-10 14:31:21.0 +0100
+++ coreutils-9.4/debian/rules 2023-11-11 11:37:05.0 +0100
@@ -13,13 +13,20 @@
DEB_CFLAGS_MAINT_APPEND += -mieee
endif
+ifeq ($(DEB_TARGET_MULTIARCH),x86_64-linux-gnu)
+opensslconf = --with-openssl=auto-gpl-compat
+else
+opensslconf = --with-openssl=no
+endif
+
BIN_PROGS = cat chgrp chmod chown cp date dd df dir echo false ln ls mkdir \
mknod mv pwd readlink rm rmdir vdir sleep stty sync touch true uname \
mktemp
d=debian/coreutils
override_dh_auto_configure:
- dh_auto_configure -- --enable-install-program=arch --with-openssl=auto-gpl-compat
+ dh_auto_configure -- --enable-install-program=arch \
+ $(opensslconf)
%:
dh $@ --with autoreconf
Debian Med video meeting tomorrow Saturday 2023-11-11 19:00 UTC
Hi, this is the call for the next video meeting of the Debian Med team that are an established means to organise the tasks inside our team. Meetings usually take us only 15-20min depending what we are talking about and how many people are joining. The next meeting is tomorrow https://www.timeanddate.com/worldclock/fixedtime.html?iso=2023T19 Despite technical issues of the last meeting I think we stick to the known Debian Social channel https://jitsi.debian.social/DebianMedCovid19 The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some items: - BioConductor transition - Python 3.12 transition - Outreachy candidates Newcomers are always welcome. See you tomorrow Andreas. -- http://fam-tille.de
Bug#1055634: ITP: asahi-nvram -- NVRAM utilities for Apple Silicon (arm) machines
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: asahi-nvram Version : 0.2.0-1 Upstream Contact: https://github.com/WhatAmISupposedToPutHere/asahi-nvram/issues * URL : https://github.com/WhatAmISupposedToPutHere/asahi-nvram/ * License : MIT Programming Lang: Rust Description : NVRAM utilities for Apple Silicon (arm) machines I intend to package the asahi-nvram utilities that are useful for Apple Silicon (arm) machines, eg. m1 and m2 (probably also m3, etc). The asahi-nvram includes the following tools (which are separate crates and will thus likely be uploaded as separate source packages): * asahi-nvram - generic utility * asahi-btsync - sync MacOS bluetooth settings to bluez * asahi-wifisync - sync MacOS wifi settings to iwd * asahi-bless - select active boot partition (These all use a common apple-nvram crate/library for parsing the nvram content.) The intention is that the packages will be maintained within the rust-team (with support from the bananas-team) and a MR is available for review at: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/555 Regards, Andreas Henriksson
Re: Bug#1055198: ITP: lzfse -- LZFSE Compression library
Hello, On Sat, Nov 04, 2023 at 08:47:11PM +0100, Timo Röhling wrote: > Hi, > > * Andreas Henriksson [2023-11-04 18:05]: > > I've previously suggested that maybe it would be better to set a > > debian-specific version (0d?), to avoid the theoretical situation that > > upstream one day ships a different ABI under the 1 so version. > Normally, I would agree, but in this particular case, Fedora already went > ahead and used SOVERSION 1 [1], so that version is "burned" and we might > just as well use it, too. > > [1] https://src.fedoraproject.org/rpms/lzfse/blob/rawhide/f/60.patch Thanks for pointing this out! > > > I would welcome peoples input here on what you think is best from the > > debian perspective. Obviously we're going to be incompatible with > > everyone else. > I don't think that "incompatible" patch you linked creates much of an issue, > because very few (if any) other library consumers will do this rather > unusual dlopen() "soft linking" dance (normal linking with e.g. "gcc > -llzfse" will automatically use the proper SONAME); besides, it is easy to > patch in Debian packages and trivial to work around with "apt install > liblzfse-dev" for everyone else. > > I do have one remark, though: the idea behind SONAME/SOVERSION is that you > have a common name for all versions which are binary backwards compatible. > Using the full version liblzfse.so.1.0 instead of libltfse.so.1 (i.e., the > SONAME) in your patch defeats that purpose: it will only work with the exact > version 1.0, but not any (hypothetical) future, backwards-compatible > versions. I hope I understood you correctly and this now adresses your concerns: https://salsa.debian.org/bananas-team/asahi-fwextract/-/commit/bfbd6f53c2e8721b9457c3a37421280a8a86dbc8 Regards, Andreas Henriksson
Re: Bug#1055198: ITP: lzfse -- LZFSE Compression library
On Thu, Nov 02, 2023 at 01:04:03AM +0100, Tobias Heider wrote: > Package: wnpp > Severity: wishlist > Owner: Tobias Heider > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: lzfse > Version : 1.0 > Upstream Authors: > URL : https://github.com/lzfse/lzfse > * License : BSD-3-Clause > Description : LZFSE Compression library > > LZFSE is a Lempel-Ziv style data compression algorithm using Finite > State Entropy coding. It targets similar compression rates at higher > compression and decompression speed compared to deflate using zlib. > > I plan to maintain this as part of the bananas team. Calling all SO versioning experts! The upstream project does not have any shared object version set. A downstream patch was introduced to set one: https://salsa.debian.org/bananas-team/lzfse/-/blob/debian/unstable/debian/patches/0001-debian-set-library-SONAME.patch Upstream has seen no activity since 2017, so trying to interact is assumed to not generate much. Also the ABI is unlikely to change (since no changes are being made). I've previously suggested that maybe it would be better to set a debian-specific version (0d?), to avoid the theoretical situation that upstream one day ships a different ABI under the 1 so version. I would welcome peoples input here on what you think is best from the debian perspective. Obviously we're going to be incompatible with everyone else[1], unless you install/runtime-depend-on the -dev package for the unversioned so symlink. Please speak now before this is submitted for NEW. FWIW lzfse is needed to extract files compressed by Apple and shipped in macOS containing embedded firmwares. See asahi-fwextract ITP: #1055206 Regards, Andreas Henriksson [1]: https://salsa.debian.org/bananas-team/asahi-fwextract/-/blob/debian/unstable/debian/patches/0001-Use-versioned-library-name-for-liblzfse.patch
Re: Bug#1055206: ITP: asahi-fwextract -- Asahi Linux firmware extractor
Hello, Filling out some of the missed information below and also providing some random thoughts of my own on this. On Thu, Nov 02, 2023 at 09:49:51AM +0100, Tobias Heider wrote: > Package: wnpp > Severity: wishlist > Owner: Tobias Heider > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: asahi-fwextract > Version : 0.6.12 > Upstream Authors: Asahi Linux Contributors > URL : https://github.com/AsahiLinux/asahi-installer/tree/main/asahi_firmware > * License : MIT > Description : Asahi Linux firmware extractor > > Scripts to extract firmware blobs from an EFI partition set up by the > Asahi Linux installer. > > I am planning to maintain this as part of the bananas team. > The firmware extractor is part of upstreams (custom) installer-repository. It also depends on asahi-scripts[1] which contains the asahi-fwupdate utility, et.al. This also contains initramfs integration to make the firmwares available during early boot and then provided as a tmpfs under /lib/firmware/vendor in the running system. Preliminary packaging is available at: https://salsa.debian.org/bananas-team/asahi-fwextract https://salsa.debian.org/bananas-team/asahi-scripts Some random thoughts: AIUI currently only initramfs-tools integration is shipped, but maybe it would be good to also provide dracut integration (as provided by upstream, if possible to integrate with debians dracut packaging)?! I don't see any asahi-scripts ITP yet. Since asahi-scripts is a dependency of asahi-fwextract I would have expected one to be posted before this. Maybe the multiple-upstream-tarballs feature could be used to package them together? But it's possibly more problems then benefits. Maybe the asahi-scripts should have a less generic binary package name? and split into multiple packages? Regards, Andreas Henriksson [1]: https://github.com/AsahiLinux/asahi-scripts
Re: mutt removed from testing while the bug was closed (fixed)
On 2023-10-26 Vincent Lefevre wrote:
> On 2023-10-26 02:03:49 +0200, Vincent Lefevre wrote:
[...]
> Hmm... This seems to be due to a bug in the BTS when the bug was
> reopened for stable. At
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051563#25
> "Bug reopened Request was from Antonio Radici to
> cont...@bugs.debian.org. (Sun, 10 Sep 2023 11:36:03 GMT) (full text, mbox,
> link).
[...]
Hello,
It was user error, plain and simple. The bug was closed and marked as fixed
in Version 2.2.12-0.1 at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051563#20
and Antonio told the BTS "No, that is true" ("reopen 1051563") and the
BTS implemented this command. The reopen should not have happened and
should have been reverted.
The documentation given in the original announcement when version
tracking was introduced [1] still applies. The nice nice graphs on the
webpages for each bug that show which versions a bug (still) applies to
are not men tioned there yet.
cu Andreas
[1] https://lists.debian.org/debian-devel-announce/2005/07/msg00010.html
Re: Hyphens in man pages
On 2023-10-15 Wookey wrote:
[...]
> OK. So I read all that, and learned a whole load of stuff I was quite
> happy not knowing about.
> However despite reading it all, and especially this bit:
> "Whenever I've maintained man pages in roff I tend to be precise in
> > the usage of - and \-, but TBH this has seemed like a lost battle,"
> I was left not actually know what - and \- represent, nor which one I
> _should_ be using in my man pages. And that seems to be the one thing
> we should be telling the 'average maintainer'.
[...]
Hello,
a pretty good guidance[1] is to
use "\-" whenever it refers to option ("-h", --help"), argument ("find
-mmin -2") or something else that is not natural language but something
that might be pasted, like a command-name ("ssh-add" or "dpkg-source")
and "-" everywhere else.
cu Andreas
[1] Well it is "guidance": pasting will work, but there might still be
places in the prose where a dash would be typographically correct. Some
of these typographical conventions are langauage specific. All this
familiar to LaTeX users.
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Debian Med video meeting tomorrow Saturday 2023-10-14 19:00 UTC
Hi, this is the call for the next video meeting of the Debian Med team that are an established means to organise the tasks inside our team. After some summer break we decided to meet only once a month every second Saturday of a month at 19 UTC. Meetings usually take us only 15-20min depending what we are talking about and how many people are joining. The next meeting is tomorrow https://www.timeanddate.com/worldclock/fixedtime.html?iso=20231014T19 The meeting is on the Debian Social channel https://jitsi.debian.social/DebianMedCovid19 The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some items: - Just say hello after some break - I might report about Debian Med BoF at DebConf if there is interest - Outreachy program Newcomers - specifically outreachy applicants are always welcome. Lets keep on the great work and see you tomorrow Andreas. -- http://fam-tille.de
Re: Bug#1053165: ITS: nunit
On Thu, 28 Sep 2023 17:22:20 +0200, Bastian Germann wrote: >Okay. What do you suggest for "team maintained" packages where there is no >active team member? >File MIA processes for each of the uploaders? And then? The MIA team's bugs >are not RC bugs, >so you cannot even NMU them based on the MIA bug. > >I think, just letting such packages rot for one or two decades does not help >anybody, certainly not our users. > I interpret it as you can NMU even if it doesn't fix RC bugs, see devref 5.11.1: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus Different delays for "only release-critical" in combination with important bugs - and then "Other NMUs: 10 days" - which to my interpretation also means fixing non-RC bugs. Of course you should always give the maintainer a chance to react though. -- Andreas Rönnquist mailingli...@gusnan.se andr...@ronnquist.net
Re: Kind invitation to join my DebConf BoF "Chatting with ftpmasters"
Short note: The print version of the slides has only 25 pages: https://people.debian.org/~tille/talks/20230911_debconf_ftpmaster_bof/ftpmaster_chat_handout.pdf Sorry for not mentioning in advance Andreas. Am Sat, Sep 09, 2023 at 07:46:08AM +0200 schrieb Andreas Tille: > Hi ftpmasters and > developers who contributed to previous discussion with ftpmaster on this list > > You might have noticed that I registered "Chatting with ftpmasters"[1] > for Debconf which is scheduled Sep 11 (Mon): 16:30 local time in Kochi > (just check the website for your local time which is printed as an > alternative). > > I'd like to invite anybody who is interested to enhance the > communication to join this BoF either at site or from remote. Locally > I'll bring some homemade sweets (quince jelly) for every member of the > ftpmaster team to thank you for all your work. > > I have put my (preliminary) slides online[2] and I'm open for comments > and enhancements. You can also add notes to etherpad[3] in advance. > > Looking forward to meet you in Kochi > Andreas. > > [1] https://debconf23.debconf.org/talks/31-chatting-with-ftpmasters/ > [2] https://people.debian.org/~tille/talks/20230911_debconf_ftpmaster_bof/ > [3] https://pad.dc23.debconf.org/p/31-chatting-with-ftpmasters > > -- > http://fam-tille.de > > -- http://fam-tille.de
Kind invitation to join my DebConf BoF "Chatting with ftpmasters"
Hi ftpmasters and developers who contributed to previous discussion with ftpmaster on this list You might have noticed that I registered "Chatting with ftpmasters"[1] for Debconf which is scheduled Sep 11 (Mon): 16:30 local time in Kochi (just check the website for your local time which is printed as an alternative). I'd like to invite anybody who is interested to enhance the communication to join this BoF either at site or from remote. Locally I'll bring some homemade sweets (quince jelly) for every member of the ftpmaster team to thank you for all your work. I have put my (preliminary) slides online[2] and I'm open for comments and enhancements. You can also add notes to etherpad[3] in advance. Looking forward to meet you in Kochi Andreas. [1] https://debconf23.debconf.org/talks/31-chatting-with-ftpmasters/ [2] https://people.debian.org/~tille/talks/20230911_debconf_ftpmaster_bof/ [3] https://pad.dc23.debconf.org/p/31-chatting-with-ftpmasters -- http://fam-tille.de
Re: Proposed MBF: Removal of libfreetype6-dev (causing FTBFS)
On 2023-08-19 Diederik de Haas wrote: > [please CC me as I'm not subscribed to debian-devel] > On Mon, 17 Jul 2023 at 21:45:13 +1000, Hugh McMaster wrote: > > On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote: > > > On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote: > > > > Currently, there are 219 build-dependencies and 29 (direct) > > > > dependencies on libfreetype6-dev, which has been released with > > > > bullseye and bookworm. [...] > > > Lintian diagnoses this as "[build-]depends-on-obsolete-package" since [...] > > Thanks for pointing this out. I wasn't aware Lintian had started > > flagging dependencies on obsolete packages some 10 months ago. > > Having Lintian issue a warning or error instead of bug filing is preferable. > While it's true that lintian did issue an error, now that src:freetype has > been updated and libfreetype6-dev has been dropped, there are a number of > packages which hadn't been updated and now FTBFS. [...] > As the FTBFS wrt libfreetype6-dev was predicted and announced [1], wouldn't > it > have been better if the MBF had taken place? > What is the recommended/appropriate way to deal with such issues? The agreed reached was not "let's ignore it, lintian has been warning about it". Instead a way forward that /should/ have avoided any breakage (versioned provides) was proposed and chosen. https://lists.debian.org/debian-devel/2023/07/msg00193.html cu Andreas
Re: Potential MBF: packages failing to build twice in a row
On 2023-08-15 Boyuan Yang wrote: [...] > where .po file that contains translation is updated every time, causing dpkg- > source to complain the diff and quit when building twoce in a row. > Take https://tracker.debian.org/pkg/ibus-array as an example. The upstream > project does not include .pot template file in the source code. The logic of > Makefile.in.in is to call msgmerge to update po translation file with > generated .pot file when .pot file is not present. This causes at least the > following diff after build: > --- ibus-array-0.2.2.orig/po/zh_TW.po > +++ ibus-array-0.2.2/po/zh_TW.po > @@ -6,7 +6,7 @@ msgid "" > msgstr "" > "Project-Id-Version: ibus-array 0.2.2\n" > "Report-Msgid-Bugs-To: https://github.com/lexical/ibus-array/issues\n"; > -"POT-Creation-Date: 2019-12-10 22:09+0800\n" > +"POT-Creation-Date: 2023-08-15 09:07-0400\n" [...] > I am looking for the advice to implement an elegant solution. What I > can think of now is to persuade upstream to embed a copy of generated > .pot template file in source code, which does not sound reasonable. > Meanwhile since Makefile.in.in is somehow widely used, this issue > likely already had impact on packages using gettext to handle > translation. You could simply set extend-diff-ignore="\.po$" in debian/source/options (untested). cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
guile-gnutls not picked up by sid autobuilders
Good morning, guile-gnutls was uploaded almost a week ago to sid, but the unstable autobuilders seem to ignore it. https://buildd.debian.org/status/package.php?p=guile-gnutls Is there anything I can do? The experimental uploads were picked up seamlessly. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
