Bug#280611: ITP: libcli
Package: wnpp Severity: wishlist * Package name: libcli Version : 1.8.1 Upstream Author : David Parrish <[EMAIL PROTECTED]> * URL : http://libcli.sf.net/ * License : LGPL Description : emulates a cisco style telnet command-line interface libcli provides a consistant Cisco style command-line environment for remote clients, with a few common features between every implemtation. The library is not accessed by itself, rather the software which uses it listens on a defined port for a Telnet connection. This connection is handed off to libcli for processing. libcli includes support for command history, command line editing and filtering of command output. J. -- Purrr.
Bug#280675: ITP: l2tpns
Package: wnpp Severity: wishlist * Package name: l2tpns Version : 2.0.5 Upstream Author : David Parrish and others <[EMAIL PROTECTED]> * URL : http://l2tpns.sf.net/ * License : GPL Description : L2TP LNS which does not require l2tpd, pppd or any kernel patches. L2TPNS is half of a complete L2TP implementation. It supports only the LNS side of the connection. L2TP (Layer 2 Tunneling Protocol) is designed to allow any layer 2 protocol (e.g. Ethernet, PPP) to be tunneled over an IP connection. L2TPNS implements PPP over L2TP only. Also supports ISP features like speed throttling, walled garden, usage accounting, and more. (This will require libcli, which I ITPed earlier today as #280611) J. -- Too many freaks, not enough circuses. [ Black Cat Networks ] [ 0845 PAYG dialup ] [ ADSL from £20+VAT/month ] [ http://www.blackcatnetworks.co.uk/ ]
Re: Bug#280675: ITP: l2tpns
On Wed, Nov 10, 2004 at 10:34:04PM +, Jonathan McDowell wrote: > * Package name: l2tpns > Version : 2.0.5 > Upstream Author : David Parrish and others <[EMAIL PROTECTED]> > * URL : http://l2tpns.sf.net/ > * License : GPL > Description : L2TP LNS which does not require l2tpd, pppd or any kernel > patches. > >L2TPNS is half of a complete L2TP implementation. It supports only >the LNS side of the connection. > >L2TP (Layer 2 Tunneling Protocol) is designed to allow any layer 2 protocol >(e.g. Ethernet, PPP) to be tunneled over an IP connection. L2TPNS > implements >PPP over L2TP only. > >Also supports ISP features like speed throttling, walled garden, usage >accounting, and more. Please stop following up to this ITP and telling me you don't understand the description unless you have prior experience of L2TP in an ISP environment. If you don't know what L2TP is or how an LNS fits into the picture, then this package probably isn't for you. I don't believe any of the terms used should be alien to the sort of person this package will be of use to. J. -- Is this desire? | .''`. Debian GNU/Linux Developer | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA + | `-DSA keys on the keyservers.
Re: Bug#285518: misdn-utils includes a firmware loader
On Wed, Dec 15, 2004 at 11:33:30PM +, Matthew Garrett wrote: > Manoj Srivastava <[EMAIL PROTECTED]> wrote: > > Well, if you need the non-free component to be on the file > > system, why is this different from contrib? Why can't say of > > everything in contrib that well, if the non-free jvm were to > > magically appear on the file system this java code would work? Or any > > other non-free stuff that needs to be on the fs? > The requirement for the non-free component exists, even if it isn't on > the filesystem. What philosophical benefit is there to distinguishing > between non-free code in a chip on a device and non-free code that > exists on the filesystem but is executed on that device? How is the > cause of free software advanced? How is the experience of our users > improved? Look Matthew, you're an intelligent fellow, but you really don't seem to get the whole firmware argument. If we refuse to handle non-free firmware being loaded onto devices and require they come with it already inside then we get to play the "I can't see it, it doesn't matter" game, which gives the purists a warm fuzzy feeling, knowing no dirty non-free 0s and 1s live on their hard disc. This improves the experience for our users - they get to have the warm fuzzy feeling too, knowing that in sacrificing the ability to use many modern toys and gadgets they are purer of mind and body. Even better is the fact that they doubley can't use the hardware because we're too busy arguing about the firmware to make a release! To be sure, to be sure -- no bread's a lot betther than half a loaf. J. -- 101 things you can't have too much of : 44 - Fame.
Re: Bug#285518: misdn-utils includes a firmware loader
On Thu, Dec 16, 2004 at 06:29:46PM -0500, Glenn Maynard wrote: > On Thu, Dec 16, 2004 at 12:02:30AM +0000, Jonathan McDowell wrote: > > If we refuse to handle non-free firmware being loaded onto devices and > > require they come with it already inside then we get to play the "I > > can't see it, it doesn't matter" game, which gives the purists a warm > > fuzzy feeling, knowing no dirty non-free 0s and 1s live on their hard > > disc. > > > > This improves the experience for our users - they get to have the warm > > fuzzy feeling too, knowing that in sacrificing the ability to use many > > modern toys and gadgets they are purer of mind and body. Even better is > > the fact that they doubley can't use the hardware because we're too busy > > arguing about the firmware to make a release! > No, there's a very concrete reason: given an installation of Debian > main, the driver works. Drivers that require non-free firmware don't > work out of the box; they say "sorry, for [legal|philosophical][1] > reasons, we can include this driver but we can't completely the > installation automatically like everything else; go hunt down the > firmware and come back". Any other software doing that would go > straight to contrib, but people want to make an exception for drivers. If you're trying to install the distro and your ADSL modem/wireless card/SCSI controller needs some firmware to work at all, then going and hunting down the firmware could prove a bit tricky. > Your sarcasm and condescension make me wonder why you're here at all, > though; you appear to regard Debian's founding principles with contempt. No, I'm just aware of the fact that the Social Contract contains more than Clause 1. I accept Free Software is a very important part of Debian, but I'm also able to work out that if our users can't even install our free software then we're not really doing much for the promotion of Free Software nor are we managing to serve our users. J. -- "For the Limit, I will forgive| Black Cat Networks Ltd all." -- David Damerell, afw.| http://www.blackcatnetworks.co.uk/ | UK Web, domain and email hosting
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 10:35:37PM +, Matthew Garrett wrote: > Andrew Pollock <[EMAIL PROTECTED]> wrote: > > That said, this (rather large) blocker shouldn't be the issue it has > > been for this release for the next one. The two biggest blockers to > > releasing any time soon have been the installer and the security > > infrastructure. I'm actually not abreast of what the issue is with > > the security infrastructure, so I don't know if it's likely to be a > > blocker all over again come etch release time. I'd like to think > > it's going to easier to release etch sooner. > It shouldn't be forgotten that the biggest blocker after these things > is probably a general failure to actually care all that much. How many > people are actually behaving as if a release is just around the > corner? How can we fix this? We've spent most of the past year thinking a release might be just round the corner. We can only cry wolf so many times before the world stops believing us and finds an option that actually works. J. -- She's the one for me. She's all I really need, oh yeah. Bring some pragmatism back to Debian - mjg59 for DPL!
Re: Debian Woody -> Sarge upgrade report
On Fri, May 06, 2005 at 04:21:13PM -0400, Roberto C. Sanchez wrote: > Last night (when I should have been working a project for my advanced > algorithms class) I decided it was time to upgrade my personal server > from Woody to Sarge. I am writing this email im the hopes that the > release team and devs find it helpful and that other users who upgrade > can make use of the information. > > In summary, here are the things that I saw: > > 4. sslwrap upgrade completely choked over openssl > > In detail: > > 4. The upgrade to sslwrap tried to generate an ssl certificate. For > some reason (I suspect becuase I have created my own CA), openssl > errored out, causing the sslwrap postinst to fail. This caused me > repreated problems as it would hang up the postinst of other packages. > I finally copied /etc/ssl and /etc/sslwrap off to another location, > purge both openssl and sslwrap, reinstall both, remove /etc/ssl and > /etc/sslwrap, and replace them with my backup copies. I am not sure > why this happened, but I am pretty sure it is a bug. I have not yet > filed a bug since I am not sure if it should go against openssl or > sslwrap. Sugestions would be appreciated. H. I run with my own CA signed cert and had no problems with a Woody -> Sarge upgrade of sslwrap on Friday. Can you send me your /etc/sslwrap/debian_conf and the output of "grep sslwrap /etc/inetd.conf" (assuming you're running it from inetd)? J. -- Revd. Jonathan McDowell, ULC | noodles is angry with him signature.asc Description: Digital signature
Re: Debian Woody -> Sarge upgrade report
On Mon, May 16, 2005 at 09:27:23AM -0400, Roberto C. Sanchez wrote: > Jonathan McDowell wrote: > > H. I run with my own CA signed cert and had no problems with a > > Woody -> Sarge upgrade of sslwrap on Friday. Can you send me your > > /etc/sslwrap/debian_conf and the output of > > "grep sslwrap /etc/inetd.conf" (assuming you're running it from inetd)? > Did you want to see what they looked like before or after the upgrade? Both, if possible. Whatever you've got easily would be a good start though. J. -- Web [ I don't bite. Well, that's wrong. I do bite. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.23 signature.asc Description: Digital signature
Re: Debian Woody -> Sarge upgrade report
On Mon, May 16, 2005 at 11:21:12AM -0400, Roberto C. Sanchez wrote: > Quoting Jonathan McDowell <[EMAIL PROTECTED]>: > >On Mon, May 16, 2005 at 09:27:23AM -0400, Roberto C. Sanchez wrote: > >>Jonathan McDowell wrote: > >>> H. I run with my own CA signed cert and had no problems with a > >>> Woody -> Sarge upgrade of sslwrap on Friday. Can you send me your > >>> /etc/sslwrap/debian_conf and the output of > >>> "grep sslwrap /etc/inetd.conf" (assuming you're running it from inetd)? > >>Did you want to see what they looked like before or after the upgrade? > > > >Both, if possible. Whatever you've got easily would be a good start > >though. [both the same and as follows:] > # grep sslwrap inetd.conf > ssmtp stream tcp nowait root/usr/sbin/tcpd /usr/sbin/sslwrap -cert > /etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 25 > imaps stream tcp nowait root/usr/sbin/tcpd /usr/sbin/sslwrap -cert > /etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 143 > > /etc/sslwrap/debian_config: > run_mode="inetd" > used_addr="127.0.0.1" > with_certificate="true" > certfile="/etc/ssl/server_key_and_cert.pem" > overwrite_corrupted_certfile="false" > check_cert="true" > ports="imaps, ssmtp" > I no longer have sslwrap installed since postfix-tls now properly grabs port > 465 without dying and cyrus21 supports imaps (though last night I switched > to courier, which also natively does imaps). Yes, these days sslwrap is thankfully not so necessary as applications are now able to link against the crypto code themselves. > The problem, if you refer to my original mail, is that something about > the CA was confusing sslwrap, which I believe tried to generate its > own cert. Is your root cert installed into the openssl framework (ie plumbed into /etc/ssl/certs)? I think if that's not the case then as you have "check_cert" set to true it'll fail to be able to validate the cert. I'm surprised you haven't seen errors about this before on boot however. J. -- /-\ | "Bother", said Pooh, "Who put sand |@/ Debian GNU/Linux Developer |in the Vaseline?!?". \- | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361098: ITP: libdata-structure-util-perl -- Change nature of data within a structure
Package: wnpp Severity: wishlist Owner: Jonathan McDowell <[EMAIL PROTECTED]> * Package name: libdata-structure-util-perl Version : 0.11 Upstream Author : Pierre Denis <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~pdenis/Data-Structure-Util/ * License : Perl (Artistic/GPL) Programming Lang: Perl/C Description : Change nature of data within a structure Data::Structure::Util is a toolbox to manipulate the data inside a data structure. It can process an entire tree and perform the operation requested on each appropriate element. For example: It can transform all strings within a data structure to utf8 or transform any utf8 string back to the default encoding. It can remove the blessing on any reference. It can collect all the objects or detect if there is a circular reference. It is written in C for decent speed. I am packaging this as it's required by recent versions of libopensrs-perl, which I already maintain. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365167: ITP: remote-tty -- multiuser "tip"/"cu" replacement with logging
Package: wnpp Severity: wishlist Owner: Jonathan McDowell <[EMAIL PROTECTED]> * Package name: remote-tty Version : 4.0 Upstream Author : Paul Vixie <[EMAIL PROTECTED]> * URL : ftp://ftp.isc.org/isc/rtty/ * License : ISC Programming Lang: C Description : multiuser "tip"/"cu" replacement with logging This is Paul Vixie's rtty serial console tool. It allows runs a server per port which then support multiple connections at time from "tip"/"cu"-like clients. It also supports logging of output from the port, even when no client is connected. This can be invaluable for post mortem diagnosis of crashes of serial consoled machines. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages that could be dropped
On Tue, Dec 26, 2000 at 06:59:16PM -0500, Ben Collins wrote: > On Tue, Dec 26, 2000 at 03:22:21PM +0100, Christian Kurz wrote: > > > > |silo (195 days old) > > > > Has this package been removed from unstable and if yes, why? It's > > currently still listed in the wnpp but I could find it which apt-cache > > search silo. > You can only remove this if you want sparc to be unbootable, which I > hope is not your intention. Um, I was going to adopt this until I saw: silo (0.9.9-1) unstable; urgency=low * New upstream * Took over silo's packaging -- Erick Kinnee <[EMAIL PROTECTED]> Mon, 4 Sep 2000 10:54:23 -0500 Which I assumed meant Erick had done so? J. -- /-\ | One-seventh of your life is spent |@/ Debian GNU/Linux Developer | on Monday. \- |
Re: Authentication with LP for DD's using gnupg
On Fri, Aug 01, 2008 at 08:32:52AM -0700, Steve Langasek wrote: > On Fri, Aug 01, 2008 at 12:07:34PM +0200, Martin Zobel-Helas wrote: > > rsync keyring.debian.org::keyrings/keyrings/debian-keyring.gpg > > can be synced publicly > > Well, what trust path does that give us if LP uses rsync to copy the data? > It would seem possible for someone to steal a DD's LP account then by > MITM'ing this rsync. There's an md5sums.txt file included in the rsync (keyrings/md5sums.txt) that will either be signed by me (5B430367) or James Troup (AB2A91F5). J. -- 101 things you can't have too much of : 11 - Coffee. This .sig brought to you by the letter J and the number 47 Product of the Republic of HuggieTag -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Popular packages in Ubuntu that is missing in Debian/main
On Mon, Dec 01, 2008 at 06:04:50PM +0100, Florian Weimer wrote: > * Marco d'Itri: > > On Dec 01, Gunnar Wolf <[EMAIL PROTECTED]> wrote: > > > >> But anyway, and knowing this is not an Ubuntu list... Does anybody > >> know why on Earth is Acroread popular? Why isn't a PDF regularly > > > I need it to view some large/complex PDF files with reasonable > > performace. > > Have you tried evince? For some reason, it used to be faster than the > other free viewers (including xpdf itself). Did evince ever get support for PDF annotations? I found myself having to install Adobe Reader to try and get shared document review working, which seems to use the annotation with XML files feature. J. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Popular packages in Ubuntu that is missing in Debian/main
On Mon, Dec 01, 2008 at 08:10:36PM +0100, Florian Weimer wrote: > * Jonathan McDowell: > > > On Mon, Dec 01, 2008 at 06:04:50PM +0100, Florian Weimer wrote: > >> * Marco d'Itri: > >> > On Dec 01, Gunnar Wolf <[EMAIL PROTECTED]> wrote: > >> > > >> >> But anyway, and knowing this is not an Ubuntu list... Does anybody > >> >> know why on Earth is Acroread popular? Why isn't a PDF regularly > >> > >> > I need it to view some large/complex PDF files with reasonable > >> > performace. > >> > >> Have you tried evince? For some reason, it used to be faster than the > >> other free viewers (including xpdf itself). > > > > Did evince ever get support for PDF annotations? > > No one doubts that nothing is as feature-laden as Adobe Reader. That wasn't the point I was trying to make; I was asking a genuine question about the status of evince (and would have been delighted to have been pointed at a repo with experimental code I could try out). J. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Free solutions for PDF annotations/shared reviews
On Tue, Dec 02, 2008 at 01:14:02AM +0100, Michael Banck wrote: > On Mon, Dec 01, 2008 at 10:19:42PM +0000, Jonathan McDowell wrote: > > That wasn't the point I was trying to make; I was asking a genuine > > question about the status of evince (and would have been delighted > > to have been pointed at a repo with experimental code I could try > > out). > > Were you looking for http://svn.gnome.org? No. I was looking for someone to say "You fool, that support is already there inn the 'annotations' branch on svn.gnome.org" or some such. All I've found about Evince annotations support is http://live.gnome.org/Evince/Annotations which has a lot of discussion, a pointer to some code from a SoC 2007 project but no indication as to whether the feature is expected to work or not in it. I was hoping someone would be able to indicate if it was worth my time trying out that code, or if there was somewhere alternative to look. Anyway, I'm probably hugely off topic now. If anyone has experience with Free software and PDF annotations I'd love to hear about it, otherwise I'll try to find some time to build up the SoC work and see what happens. J. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What about David Frey (dfrey)?
On Fri, Feb 19, 2010 at 11:08:35AM +0100, markus schnalke wrote: > Does anyone know if he is still active? Or better: Is he still a DD? > > I am intrested in adopting one of his orphaned packages and wanted to > talk to him before. Unfortunately df...@d.o is bouncing with: > > host master.debian.org [70.103.162.29]: 550 Unrouteable address > > However, I found him on db.debian.org. > > Can anyone clarify? He retired from the project last May. Try david at eos.lugs.ch J. -- Revd. Jonathan McDowell, ULC | "Reality Or Nothing!" -- Cold Lazarus signature.asc Description: Digital signature
Bug#579481: ITP: plconfig -- a tool for configuring HomePlug powerline bridges
Package: wnpp Severity: wishlist * Package name: plconfig Version : 0.0.2 Upstream Author : Manuel Kasper * URL : https://neon1.net/prog/plconfig.html * License : 2 clause BSD Programming Lang: C Description : a tool for configuring HomePlug powerline bridges plconfig is a command line tool for configuring ethernet over powerline devices that conform to the HomePlug specification. As well as being able to set the network encryption key for such devices it can also display their parameters and statistics information. J. -- Wake up, wake up dead man. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100427214357.ga20...@earth.li
Re: Bits from keyring-maint
On Wed, Sep 15, 2010 at 03:14:48PM +0200, Marco d'Itri wrote: > On Sep 15, Christian PERRIER wrote: > > > I would like to know the process which lead to selecting these > > > figures. > > Apparently, just like many other things in the project: the folks > > doing the work (and appointed for this by the project through the > > DPL) examine the situation, make plans and decisions and then > > announce them. > I suppose that this was not the result of cargo cult engineering, so > if these new recommended key values have been selected as the result > of a process I am curious to know the rationale which lead to the > choice. It really looks like a simple question to me. > > I am just asking for a rationale. I would like to know if the new > recommended key values have been selected as the result of a process, > and what the rationale is, or if this is cargo cult engineering. The key driver is moving away from SHA-1 based keys, but as part of the same process we want to increase key length from 1024 bits. If you're generating a new key and have no reason not to do so then we're recommending 4096 bits (as the largest easily generated size with our current tools). Yes, this is way beyond what anyone is going to be able to attack, and there are many, many other easier attack vectors people could use against Debian instead, but we do end up with keys hanging around for a long time (10+ years in many cases) and we feel it makes sense to rule out key strength as a problem given the increases in processing power since we started out with 1024 bits. We won't refuse 2048 bit keys; whether that be because you're using a hardware OpenPGP smartcard, or have a slower machine and feel it makes a big difference, or have just made an reasoned out decision that this is sufficient. J. (wearing a rather fetching keyring-maint hat) -- Web [101 things you can't have too much of : 29 - T-shirts.] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 signature.asc Description: Digital signature
Re: Bits from keyring-maint
On Wed, Sep 15, 2010 at 11:57:25AM -0400, Perry E. Metzger wrote: > On Wed, 15 Sep 2010 12:41:49 -0300 Henrique de Moraes Holschuh > wrote: > > On Wed, 15 Sep 2010, Felipe Sateler wrote: > > > On 14/09/10 01:18, Gunnar Wolf wrote: > > > > - Your new key should be signed by two or more other Debian > > > > Developers > > > > > > The NM and DM processes require only one signature. Why is it > > > harder to replace a key than to become a DD? > > > > Or rather, why the requirements for the first key any weaker than > > those for DD key replacement? > > Or rather, what is the specific threat that the policy is designed to > address? Does it succeed? The question for a key for a new DM/DD is "Are we sure this person is who we think it is?". For a replacement key for an existing key it's "Are we sure this key belongs to the person we already know of as a different key, and that they want the key replaced.". The first is simpler than the second and doesn't risk locking a developer out from access to the project. Personally I'd like to require 2 signatures for new DM/DDs but I understand that would raise the bar to project entry in an unhelpful fashion. J. -- Documentation - The worst part | .''`. Debian GNU/Linux Developer of programming. | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers. signature.asc Description: Digital signature
Re: A request for those attending key signing parties
On Mon, Jan 31, 2011 at 09:18:18PM +0100, Martin Zobel-Helas wrote: > a more theoretical question quite related to this: > > If one plans to have the key replaced in the keyring, and we have a > fellow DD in the keyring who's only trust path to other Debian > Developers goes via that key (this might become a real scenario when we > do a bigger round of key replacements) will that key replacement really > happen? Thus CCing keyring maintainers. I've had a few conversations with developers who are known to be the single path to many DDs about holding off on their key replacements, and been keeping an eye in general on our connectedness over time. In some occasions we have pushed back on developers who want to replace their keys with a minimal number of signatures when their old keys are well integrated. Overall the connectedness seems to have stayed about level; in January 2009 we had 89.6% of the keys is in the reachable subset and 84.0% in the strong subset. By the end of 2010 these numbers had increased to 91.1%/85.2%. Yes, some of that is because we've removed inactive keys, but I think it's an indicator that (so far) the key replacements have not been weakening our web of trust. J. -- Web [ If I hold really still maybe all of this will just go away. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110201173635.gc30...@earth.li
Re: need help in resolving the Apache-Expat-XML::Parser conflict
On Sun, Sep 09, 2001 at 03:51:05PM -0500, Ardo van Rangelrooij wrote: [AxKit not working due to Apache expat linkage] > I've no problem NMU'ing apache, but that might break other packages > (which?). There are two ways to NMU: > > 1. leave out expat: this is the simplest way since it only requires a > small change in the debian/rules file > > 2. build with the least version of expat (as described in bug #96093): > that's more work given the way it's currently packaged (the upstream > source are in tarballs which are unrolled during build) > > Any help in resolving this situation is greatly appreciated. Option 2 isn't actually that hard to do - you can put a patch against the tarball in debian/patches and it'll get applied when the tarball is unrolled. However why is Apache build with expat? Surely either option 1 removes functionality or doesn't and if it doesn't then is there any reason not to choose it over linking expat dynamically? And if it does then Option 2 makes more sense. J. -- Web [ I've got a trigger inside. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.19
Re: jabber.deb
On Mon, Sep 10, 2001 at 03:05:30AM -0500, Scott Dier wrote: > * Bernd Eckenfels <[EMAIL PROTECTED]> [010910 02:28]: > > On Sun, Sep 09, 2001 at 05:30:54PM +0200, clemens wrote: > > > where is the icq transport in the debian packages? > > tere are no transports in the debian server package. I will package > > msn transport after i have updated the jabber server, not sure if i > > will package all transports, they seem to mean a lot of work. > Oo an updated jabberd? I might think about doing icq at least. > aim becomes. uh. user intensive because of the aim binary requirement. > :| I'm running the ICQ, MSN, AIM & Yahoo transports on my server so I'll package any of these that no one else grabs. However I'm wondering about whether there'll be a uniform method of adding a new transport to the server or if the onus will be on the user to do the configuration? J. -- 101 things you can't have too much of : 29 - T-shirts.
Re: jabber.deb
On Tue, Sep 11, 2001 at 10:39:24AM +0200, Bernd Eckenfels wrote: > On Mon, Sep 10, 2001 at 09:57:29AM +0100, Jonathan McDowell wrote: > > I'm running the ICQ, MSN, AIM & Yahoo transports on my server so I'll > > package any of these that no one else grabs. However I'm wondering about > > whether there'll be a uniform method of adding a new transport to the > > server or if the onus will be on the user to do the configuration? > > Kind of /etc/jabberd/jabber-xml.d/ would be nice, eh? That would be excellent. > Meanwhile send me patches/correnctions for your transport to be added > (commented out) to the main config file. I would ike to take msn-t > only. Are you planning to have all the transports running under the main server or with separate instances? Any idea when a package with the appropriate bits for transport building (jabberd.h, lib/lib.h & platform-specifics IIRC) will be available? J. -- Web [ "Tax free porn, man. Think about it." -- Jasper Janssen, ] site: http:// [ asr. ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.19
Re: proposal for an Apache (web server) task force
On Thu, Sep 13, 2001 at 10:33:39PM -0500, Ardo van Rangelrooij wrote: > Martin F Krafft ([EMAIL PROTECTED]) wrote: > > also sprach Ardo van Rangelrooij (on Thu, 13 Sep 2001 08:42:44AM) > > > I would like to propose to form an Apache (web server) task force to > > > maintain the Apache packages currently maintained by Johnie Ingram > > > (netgod) (and potentially related packages if the need arises). > > count me in. > Excellent! > > There are a couple of things we can start with: > > - filing a request for the mailing list > - putting together a web page similar to that of the X Strike Force >with a link to the packages and their bug lists, a todo list, etc. > - an NMU of the packages with an Uploaders field in the control file >(see the thread about multiple maintainers per package on this list) > - setting up a CVS archive somewhere > > If I interpret all the responses correctly there're four people on the > task force. I propose we all go over the bug list and make an inventory > in terms of difficulty to solve. That should give us a better idea of > the status and how much we can do before the freeze. I'm keen to help (and have been slowly working on a second NMU of Apache to fix some of the current bugs), but I'd really like to see something from Johnnie saying this was ok. It's not exactly polite to hijack someones package with no input from them. A strike force is different than just doing the odd NMU IMO. J. -- /\ | Incest is best. | | http://www.blackcatnetworks.co.uk/ | \/
Re: grsecurity kernel patch ITO
On Wed, Dec 19, 2001 at 08:14:30AM +0100, Russell Coker wrote: > I have packaged the grsecurity kernel patch, but it hasn't gone into unstable > apparently because of the process of freezing for woody release. > > Now the LSM kernel patch that I maintain is getting some of the features of > grsecurity (the next version has a port of OpenWall to 2.4.16) and I have > less interest in it. > > The main patch package is on http://www.coker.com.au/grsec/ FWIW I have now taken over the maintainence of this and you can find my work at: http://www.earth.li/~noodles/grsec/ It's been updated for the 2.4.17 kernel. J. -- /-\ | CAFFEINE! |@/ Debian GNU/Linux Developer | \- | pgptBMeEkQtb4.pgp Description: PGP signature
Re: Notes from keyring-maint; end of the world not predicted
On Wed, May 20, 2009 at 07:43:53PM +1000, Ben Finney wrote: > Jonathan McDowell writes: > > * Replacement of the old key with the new one should not cause any > > other key to no longer be in Debian's Web of Trust nor strongly > > connected subset. > > Is there a simple way of checking whether this is true for a given key? > > > * Replacement of the old key with the new one should not cause a > > significant weakening of Debian's Web of Trust. I don't have exact > > figures for this at present, but it'll be based on the Betweenness > > Centrality and mean-minimum-distance calculations most probably. > > Is there a simple way of getting a metric of this for a given key? The "easiest" way is probably to install the signing-party package and then use keyanalyze: rsync -az --progress keyring.debian.org::keyrings/keyrings/debian-keyring.gpg \ ./debian-keyring.gpg gpg --no-default-keyring --keyring ./debian-keyring.gpg \ --delete-key gpg --no-default-keyring --keyring ./debian-keyring.gpg \ --import pgpring -S -k debian-keyring.gpg | process_keys > preprocess.keys keyanalyze and then you should have an output/ directory. status.txt has the reachable/strongly connected set sizes at the bottom. other.txt will show you the average MSD. Historic stats for the debian-keyring are at: http://keyring.debian.org/stats/ if you want to compare (2009-05-06 is what you'll get from the above rsync at present). cwot isn't currently packaged, it might possibly be a useful addition to signing-party. J. -- Don't hit the keys so hard, it hurts. signature.asc Description: Digital signature
Re: Determining, ad hoc, whether someone is a DD
On Wed, Oct 15, 2014 at 03:02:07PM +0100, Ian Jackson wrote: > Many of our lookup interfaces don't give out a clear indication of the > status of the person you are looking up. Eg db.debian.org contains > DMs and DDs and the public lookup doesn't distinguish. > www.debian.org/devel/people lists maintainers, DMs and DDs without > distinction. (This is contrary to the information on > https://wiki.debian.org/DebianDeveloper.) > > AFAICT there are two ways right now to find out whether someone is a > DD from primary sources[1]: > > * Install debian-keyring from sid and hope that it is up to date >enough. This is a 51Mby download. It involves having a sid >chroot, or messing about downloading the .deb by hand. If you want the version of the keyring the project infrastructure is using then the canonical way to obtain it is: rsync -az --progress keyring.debian.org::keyrings/keyrings/ . There is a sha512sums.txt file included which will be signed by myself, gwolf or dkg. To the main point of your email there is discussion about ensuring that even DMs have usernames and I believe it would be a good idea for LDAP to then have a separate group to indicate when someone is a DM vs a DD. J. -- Web [ "Scattered f***ing showers my ass." -- Noah ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 signature.asc Description: Digital signature
Re: Reminder: Removing < 2048 bit keys from the Debian keyrings
On Sat, Nov 08, 2014 at 09:59:08PM +0100, Richard Hartmann wrote:
> Can you put this list, and a count, in a place I can wget from?
You've trimmed all context so I'm not entirely clear if you're looking
for the key list or something else. If it's the key list you should be
able to calculate it yourself from the keyrings:
rsync -az keyring.debian.org::keyrings/keyrings/ .
gpg --no-default-keyring --list-keys --with-colons \
--keyring ./debian-keyring.gpg \
--keyring ./debian-maintainers.gpg | \
awk -F ':' '/^pub:.:1024:/ { print $5 " " $10 }'
This will give slightly more people than my list as I effectively did
the above on our working tree, which is not public, while the rsync will
provide the currently active keyring. At present the above lists 468
contributors, while the active tree has 429 with weak keys.
J.
--
] http://www.earth.li/~noodles/ []I'm a consultant because I'd [
] PGP/GPG Key @ the.earth.li [] rather be self-unemployed. [
] via keyserver, web or email. [] [
] RSA: 4096/2DA8B985[] [
signature.asc
Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On Thu, Apr 26, 2012 at 09:27:43AM +0300, Eray Aslan wrote: > On Thu, Apr 26, 2012 at 03:23:18AM +0800, Chow Loong Jin wrote: > > I think Arto Jantunen explained it pretty well earlier in this > > thread: > > > Reliability in the case of modern kernels and modern hardware > > > means event based, not static. The hardware in a modern computer > > > comes and goes as it pleases (usb devices being the worst example, > > > but scanning > > That's the thing. Hardware do not come and go as it pleases on my > servers and I do not want anything happening when someone inserts a > usb device. It's nice on my laptop but not on my servers. It comes and goes on my servers. I bring online new storage devices, and change their sizes when I decide I want more space. Sometimes I bring online a lot of temporary space and then take it away when I'm done. These are production servers with Fibre Channel attached storage and this is not a unique use case. Having to manually fiddle with rescan-scsi-bus etc to see the new devices is a PITA and I welcome any attempt to make this a more seamless process. Don't assume dynamic device detection is only about personal machines or USB. It's useful in a much wider context. J. -- We are talking one charming motherf**king pig. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120426172344.gg20...@earth.li
Re: amd64 as default architecture
On Tue, May 22, 2012 at 08:51:17PM +0100, Ben Hutchings wrote: > On Tue, May 22, 2012 at 09:18:21PM +0200, Sven Joachim wrote: > > On 2012-05-22 20:40 +0200, Simon McVittie wrote: > > > On 22/05/12 19:24, Sven Joachim wrote: > > > > > >> and anything that uses libx86 won't work either (#492470). ... > > The lrmi backend uses vm86 mode which is not supported under an x86_64 > > kernel. > > So the x86emu backend should be built too if there are any 64-bit > systems that need libx86 - and maybe for other reasons as well. > That's not a big deal, though, surely? Which backend to use is a compile time option, so this would be switching to always use the x86emu backend. Not a big issue if we're going to drop 32 bit kernels entirely, a performance impact on those machines if we're not. J. -- Web [ Keyboard: Used for entering errors into a system. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120522213434.gp20...@earth.li
Re: CD sizes again (and BoF reminder!)
On Sun, Jul 08, 2012 at 02:12:44PM -0600, Joey Hess wrote: > Cyril Brulebois wrote: > > It looks to me like a current debian-installer build installs grub2, > > with no option for grub-legacy, even in expert mode. > > grub-legacy is still used for multipath and sataraid. > Something was going to be done to make grub2 support those, but > I don't know the status. wheezy's grub2 is much better at multipath than squeeze's - I've switched several production machines to the wheezy variant because It Just Worked for me, while the squeeze version would fail to figure out devices whenever update-grub was run. J. -- 101 things you can't have too much of : 27 - Ice cream. signature.asc Description: Digital signature
Re: Debian not suitable for SSD due to apt/dpkg?
On Mon, Oct 01, 2012 at 03:37:19PM +0200, Holger Levsen wrote: > On Montag, 1. Oktober 2012, Michael Hanke wrote: > > Just a data point: > > interesting, thanks. > > what are the main (ssd related) advantages of running a 3.2 kernel > instead of the 2.6.32 from squeeze? (I don't want to run 3.2 due to > wlan/intel gfx problems, though last time I tried was three months > ago, might been fixed by now.) For one thing our 2.6.32 kernel doesn't have full discard/trim support available, but the 3.2 kernel does. J. -- Revd Jonathan McDowell, ULC | I can only see one nipple. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121001162653.gx2...@earth.li
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
On Tue, Mar 04, 2014 at 12:45:05PM +0800, Paul Wise wrote: > On Tue, Mar 4, 2014 at 12:28 PM, Gunnar Wolf wrote: > > > About a schedule: No, we do not currently have it. We should work on > > getting a plan for this. Now, it is not an easy task to get done, and > > as we might effectively end up locking out many DDs, I'm thinking (and > > I have not yet talked this over in the team, but we should discuss it) > > we should get formal support from the project in the form of a GR or > > something like that... Of course, that after sketching a real plan > > with stages and dates. > > Surely this is well within keyring-maint purview and a GR is thus > unnessecary? Running the plan by debian-project seems a reasonable > level of consultation. We didn't need one for removing PGPv3 keys so I don't see why we'd need one for 1024D v4 keys. I have already suggested a timescale to -project but haven't seen any comments on it other than "you should script this" and "should we relax the requirement for 2 signatures". J. -- Minorities are the foundation of society. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140304053811.gh27...@earth.li
Re: Updating GPG howto (http://keyring.debian.org/creating-key.html)
On Wed, Apr 06, 2011 at 12:15:49PM +0200, Vincent Caron wrote: > On Wed, 2011-04-06 at 01:09 +, brian m. carlson wrote: > > On Tue, Apr 05, 2011 at 05:15:15PM +0200, Vincent Caron wrote: > > > 2/ It is suggested to update gnupg.conf with: > > > > > > personal-digest-preferences SHA256 > > > cert-digest-algo SHA256 > > > default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES > > > CAST5 ZLIB BZIP2 ZIP Uncompressed > > > > > > Is it still needed with GnuPG 1.4.11 ? > > > > This isn't strictly needed with any version of GnuPG. However, these > > settings choose algorithms which are known to be stronger (avoiding MD5 > > and the mandatory but somewhat weakened SHA1). Setting > > default-preference-list specifies which algorithms you prefer in your > > key's self-signature (which you can always change later). > > Implementations are forbidden from using algorithms (other than the > > default must-implement ones) that you do not specify in your > > self-signature. Using cert-digest-algo chooses the algorithm you will > > use in signing keys. And finally, personal-digest-preferences is the > > algorithm you will use when signing data. > >That's a nice explanation that would fit on > http://keyring.debian.org/creating-key.html It's not entirely accurate. The point of those lines are to ensure that older (certainly lenny and earlier, I'm not sure when the default changed) versions of GnuPG don't use SHA1 when signing keys (either your own or others). J. -- It's ten o'clock; do you know where your processes are? This .sig brought to you by the letter L and the number 13 Product of the Republic of HuggieTag -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110407172610.go4...@earth.li
Re: Facilitating external repositories
On Thu, Aug 13, 2015 at 07:53:52PM +0200, Jakub Wilk wrote: > * Anthony Towns , 2015-08-12, 23:12: > >debian-keyring is a 51MB deb, that's pretty big. > > FWIW, it could be shrunk to ~10MB if the keys were minimized > (--export-options export-minimal). We recently switched to export-clean to retain only signatures that can be verified. This brings it down to 26M for debian-keyring.gpg (by far the largest keyring), while still providing the signatures within the Debian trust space. J. -- ] http://www.earth.li/~noodles/ [] 101 things you can't have too much [ ] PGP/GPG Key @ the.earth.li [] of : 42 - Pepsi. [ ] via keyserver, web or email. [] [ ] RSA: 4096/0x94FA372B2DA8B985 [] [ signature.asc Description: Digital signature
Re: GCC-5 transition will move to testing tonight
On Sat, Sep 05, 2015 at 09:25:46PM +0200, Niels Thykier wrote: > Thanks to Adam, Julien, Jonathan, Matthias, Scott, Simon and many > others, we are ready to migrate the bulk of the GCC-5 transition and > related sub-transitions to testing tonight. Apologise for the short > notice. I continue to be impressed at the fine work the release team do for Debian. Based on conversations at DebConf I'd expected a much longer period of instability and lack of updates to testing. While I understand we're not out of the woods yet I'd like to thank everyone who's worked hard on dealing with this major transition. J. -- ] http://www.earth.li/~noodles/ [] Time is an illusion. Lunchtime[ ] PGP/GPG Key @ the.earth.li [] doubly so. [ ] via keyserver, web or email. [] [ ] RSA: 4096/0x94FA372B2DA8B985 [] [ signature.asc Description: Digital signature
Bug#917546: ITP: binutils-xtensa-lx106 -- GNU binary utilities, for Xtensa lx106 core
Package: wnpp Severity: wishlist Owner: Jonathan McDowell * Package name: binutils-xtensa-lx106 Version : 2.31.1-11+1 * URL : https://www.gnu.org/software/binutils/ * License : GPL Programming Lang: C Description : GNU binary utilities, for Xtensa lx106 core Bare metal binutils for chips using the Xtensa lx106 core, such as the Espressif ESP8266 wireless modules. The programs in this package are used to manipulate binary and object files that may have been created for the Xtensa architecture. This package is primarily for those developing for the ESP8266 platform and is not needed by normal users or developers. The ESP8266 is a commonly used component in the IoT ecosystem; devices such as the SonOff power switches and various wifi lightbulbs are all based upon it, as well as a full Arduino stack being available. Espressif have committed to availability until at least 2026. As this is targeted towards embedded platforms it will be maintained within the Debian Electronics Team. It is built using the binutils-source base package rather than pulling in an additional copy of binutils.
Bug#917547: ITP: gcc-xtensa-lx106 -- GNU C compiler for Xtensa lx106 core
Package: wnpp Severity: wishlist Owner: Jonathan McDowell * Package name: gcc-xtensa-lx106 Version : 8.2.0-13+1 * URL : http://gcc.gnu.org/ * License : GPL Programming Lang: C Description : GNU C compiler for Xtensa lx106 core Bare metal C cross compiler for chips using the Xtensa lx106 core, such as the Espressif ESP8266 wireless SoCs. This package is primarily for those developing for the ESP8266 platform and is not needed by normal users or developers. This is the counterpart to the binutils-xtensa-lx106 ITP (#917546). As stated there the ESP8266 is a commonly used component in the IoT ecosystem; devices such as the SonOff power switches and various wifi lightbulbs are all based upon it, as well as a full Arduino stack being available. Espressif have committed to availability until at least 2026. As this is targeted towards embedded platforms it will be maintained within the Debian Electronics Team. It is built using the gcc-8-source base package rather than pulling in an additional copy of gcc-8.
Re: tag2upload (git-debpush) service architecture - draft
On Wed, Jul 24, 2019 at 02:56:22AM +0100, Ian Jackson wrote: > I wrote this draft design doc / deployment plan for the tag-to-upload > service, perhaps best summarised by Sean like this: > > We designed and implemented a system to make it possible for DDs to > upload new versions of packages by simply pushing a specially > formatted git tag to salsa. For the record I am in favour of this as a service. I'm not a dgit user, but I am a salsa user who pushes release tags there and then uploads to the archive. Reducing this to a single action sounds like less work for me and result in less likelihood of me forgetting a step (either the push to salsa, or sometimes an upload). > Please see this blog post to learn about how it works: > https://spwhitton.name/blog/entry/tag2upload/ I've clarified with Ian that despite Sean's blog talking about the debian-keyring package the dgit infrastructure correctly uses the keyring in /srv/keyring.debian.org/ as deployed by DSA on the Debian infrastructure. > TAG-TO-UPLOAD - DEBIAN - DRAFT DESIGN / DEPLOYMENT PLAN > === > > Overall structure and dataflow > -- > > * Uploader (DD or DM) makes signed git tag (containing metadata >forming instructions to tag2upload service) > > * Uploader pushes said tag to salsa. [1] > > * salsa sends webhook to tag2upload service. > > * tag2upload service > : provides an HTTPS service accessible to salsa's IP addrs > : fishes url and tag name out of webhook json > ! checks that url is basically sane > - retrieves tag data (git shallow clone) > ! parses the tag metadata > ! checks to see if it is relevant > ! verifies signature > ! checks to see if signed by DD, or DM for appropriate package > - obtains relevant git history > - obtains, if applicable, orig tarball from archive > - makes source package > # signs source package and "dgit view" git tag > - pushes history and both tags to dgit git server > - uploads source package to archive > > * archive publishes package as normal The piece of information that I think is missing here (and I've been able to discover in person) is that the "trusted" piece (all the !s) is keeping state during the processing of a particular tag/upload. That is, the trusted component gets handed the tag info, verifies it is sane, hands it off to the untrusted component to fetch + build a source package for, then does as much verification as it can that what it gets back from the untrusted component is the same package/version as expected. Looking at risk factors I think the major ones are dealt with: * The package build is still performed by the buildd, not by this new service, so there shouldn't be exposure to build issues for tag2upload. * tag2upload is making the appropriate checks that the signer of the tag has the right to upload the package to the archive; either is a full DD or is a DM with appropriate DAK ACL rights. * Automated signers for uploads are not new; buildds are already doing this for binary packages. * The complexity is in creating the source package; figuring out the source format type, potentially applying patches etc. This is pushed out to the untrusted component. * Given that the tag signer is independently able to do an upload this does not provide any additional avenue for them to push a nefarious package into the archive. > [1] In principle other git servers would be possible but it would have > to be restricted to ones where we can either avoid, or stop, them > being used as a channel for a DoS attack against the tag2upload > service. If we're hoping to pitch salsa as being the default place for Debian packages to live is limiting this service to salsa not a decent carrot? J. -- "For the effect of psychedelics on the development community, well, there's Enlightenment, isn't there?" -- Adam J. Thornton, asr.
Re: tag2upload (git-debpush) service architecture - draft
On Mon, Jul 29, 2019 at 09:46:51 +0200, Ansgar wrote: > There are also other issues, for example: > > - Such a service would bypass various sanity checks on the archive >side, including various permission checks. tag2upload checks the Debian Keyring and the DM ACL (from dak)/DM keyring. What other checks are done per key that are avoided by this? The proposed Git-Tag-Info field has the fingerprint of the original key that signed the tag, if there are further keyring related checks that ftp-master wish to perform themselves. > - Such a service would need to properly validate the PGP signature. >The archive really shouldn't rely on a third-party service for this. >(In particular the service in question here doesn't do that as far as >I can tell.) I'm not clear on what the issue is here; perhaps you can expand? A DD/DM has to sign the tag in Salsa[0], tag2upload does the appropriate check that the tag is signed by a key that has the appropriate permissions to do a source upload of the package in question. There's no third party service being trusted here. The keyrings are from Debian and the intent is to have tag2upload being run on Debian infrastructure - indeed that's my understanding of part of the main reason Ian has brought up his draft architecture here, to work out what needs changed/included to make that possible. It's not clear to me why this is significantly different from a security perspective than the buildds; in fact as this service does not build anything other than a source package it's much more auditable than the binary uploads they perform[1]. J. [0] Other Git Hosting Services Are Available. [1] Until Reproducible Builds are at 100%. -- 101 things you can't have too much of : 40 - Star Wars toys.
Re: RFC: advise against using Proton Mail for Debian work?
On Wed, Nov 15, 2023 at 11:21:06PM +0100, Norwid Behrnd wrote: > I would like to add an observation tangential to your points A), explanation > to new contributors, and B) potentially advise against the use of Proton Mail > for Debian work to yield a «no, Proton Mail can be useful for some Debian > work». I'll chip in, without wearing any hats, to comment that: a) I completely agree with all the sentiments raised about not storing the private portion of OpenPGP keys on other people's systems; this extends to systems run by DSA (in the distant past we had to do a clean up of DD keys that had been stored on master). but b) Proton Mail are active members of the OpenPGP ecosystem and are doing good work in trying to improve it's usefulness and usability. I have no reason to object to their use within Debian, as long as upload keys are not stored there. J. -- /-\ | "Do I scare you?" "No." "Do you |@/ Debian GNU/Linux Developer | want me to?" -- Wayne's World. \- | signature.asc Description: PGP signature
Re: Signature strength of .dsc
On Mon, Dec 04, 2023 at 11:07:38AM +0100, Simon Josefsson wrote: > Judit Foglszinger writes: > >> > Dmitri, could you re-run the numbers with the debian-maintainer > >> > keyring? > >> > >> That is correct. I have updated the results now. The 2,455 no > >> public key has now become 1,238 > > > > Another is the DN keyring. Also I'd expect many keys to be found in > > older versions of the keyring package/keyring repository and on > > keyservers like keyserver.ubuntu.com > > Removing old keys is usually a bad idea -- could these be moved to a > "archived" keyring instead? I assume having them in the "live" > keyring is not possible if the presence of a key in that file is used > to make authorization decisions. > > You want to be able to verify old signatures in 20+ years too, and > then you need to be able to find the corresponding public key. For a long time we had a "removed" keyring, but we decided that we didn't want to continue shipping a keyring that was explicitly a set of keys we could not vouch for the trust of (whether that be because they were revoked, lost, weak, or whatever). If you really want to find old keys there is 15+ years of history in the keyring git repository, as Judit mentioned: https://salsa.debian.org/debian-keyring/keyring/ J. -- Web [ Barndoors. Barndoors. Barndoors. Profile. Profile. VARILITE! ] site: https:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 signature.asc Description: PGP signature
Re: Bug#1051541: ITP: rustic -- fast, encrypted, and deduplicated backups powered by Rust
On Tue, Dec 05, 2023 at 08:59:56AM -0700, Scarlett Moore wrote: > * Package name: rustic > Version : 0.5.4 > Upstream Contact: Alexander Weiss > * URL : https://github.com/rustic-rs/rustic > * License : Apache-2.0 or MIT > Programming Lang: Rust > Description : fast, encrypted, and deduplicated backups powered by Rust > > Restic (https://github.com/restic/restic/) is a great backup tool IMHO. The > compatible Rust implementation rustic is a lot faster and has a lot more other > features over the Golang version, for example: ... > I think that'd be a very useful utility to have in Debian. Perhaps once it no longer states: | rustic currently is in beta state and misses regression tests. It is not | recommended to use it for production backups, yet. J. -- The end is nearer. | .''`. Debian GNU/Linux Developer | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers.
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Thu, Sep 08, 2022 at 05:58:25PM +0200, Dylan Aïssi wrote: > Hi, > > I have been asked several times regarding when Debian will switch its default > sound server from PulseAudio to PipeWire without having an official answer. > Thus, I suppose it's the right time to start a discussion about that. Perhaps, now this has actually got as far as testing, someone will be so kind as to at least comment on #996750, which I opened almost a year ago. It's had no follow-ups and I'm now seeing the same behaviour on a system that only has an external screen - it doesn't actually go into power save mode. I suspect there's something going on with pipewire and HDMI audio, but it's a regression from a pulseaudio setup. J. -- If we sleep together, will you like me better?
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Sun, Oct 02, 2022 at 07:29:31PM +0100, Jonathan McDowell wrote: > On Thu, Sep 08, 2022 at 05:58:25PM +0200, Dylan Aïssi wrote: > > Hi, > > > > I have been asked several times regarding when Debian will switch its > > default > > sound server from PulseAudio to PipeWire without having an official answer. > > Thus, I suppose it's the right time to start a discussion about that. > > Perhaps, now this has actually got as far as testing, someone will be so > kind as to at least comment on #996750, which I opened almost a year > ago. It's had no follow-ups and I'm now seeing the same behaviour on a > system that only has an external screen - it doesn't actually go into > power save mode. I suspect there's something going on with pipewire and > HDMI audio, but it's a regression from a pulseaudio setup. After a bit more patience, and some experimentation, I'm going to have to recant. It might be taking a _little_ longer to actually hit power save, but it is now happening and it does seem to recover ok. Apologies for the noise, I'll follow up to the bug. J. -- 101 things you can't have too | .''`. Debian GNU/Linux Developer much of : 33 - Jokes. | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers.
Bug#1027427: ITP: rcheevos -- RetroAchievements helper library for game emulators
Package: wnpp Severity: wishlist Owner: Jonathan McDowell X-Debbugs-Cc: debian-devel@lists.debian.org, debian-devel-ga...@lists.debian.org, nood...@earth.li * Package name: rcheevos Version : 10.5.0 * URL : https://github.com/RetroAchievements/rcheevos * License : MIT Programming Lang: C Description : RetroAchievements helper library for game emulators rcheevos is a set of C code, or a library if you will, that tries to make it easier for emulators to process RetroAchievements data, providing support for achievements and leader boards for their players. Keep in mind that rcheevos does not provide HTTP network connections. Clients must get data from RetroAchievements, and pass the response down to rcheevos for processing. Not all structures defined by rcheevos can be created via the public API, but are exposed to allow interactions beyond just creation, destruction, and testing, such as the ones required by UI code that helps to create them. Finally, rcheevos does not allocate or manage memory by itself. All structures that can be returned by it have a function to determine the number of bytes needed to hold the structure, and another one that actually builds the structure using a caller-provided buffer to bake it. At present rcheevos does not build a dynamic library, so my plan is to package the header files and a static .a in librcheevos-dev. It is currently embedded in the retroarch package, but is also required by the Kodi libretro wrapper, which I am working on. I plan to maintain this as part of the Debian Games team.
Bug#1027903: ITP: kodi-game-libretro -- Libretro compatibility layer for the Kodi Game API
Package: wnpp Severity: wishlist Owner: Jonathan McDowell X-Debbugs-Cc: debian-devel@lists.debian.org, debian-devel-ga...@lists.debian.org, debian-multime...@lists.debian.org, nood...@earth.li * Package name: kodi-game-libretro Version : 20.2.0 * URL : https://github.com/kodi-game/game.libretro * License : GPL Programming Lang: C++ Description : Libretro compatibility layer for the Kodi Game API This add-on provides a wrapper that allows Libretro cores to be loaded as game add-ons within Kodi. Libretro cores are shared libraries that use the Libretro API, so the wrapper is responsible for translating function calls between the Libretro API and the Kodi Game API. I plan to maintain this as part of the Debian Games team - while Kodi is under the Multimedia team the only requirement from that side is the kodi-addons-dev package.
Re: Running without swap messages]
On Thu, Jul 21, 2016 at 04:24:36PM +0100, Ian Jackson wrote: > Uhhh. You run your systems with no swap at all ? > > That's your prerogative, of course. But it's far from a default (or > recommended) configuration. I think that if you configure your system > without swap, it is up to you do whatever else is necessary to make it > work. That might involve making /tmp not be on a tmpfs (if it is the > default for some reason). I run my laptop without swap and with /tmp on tmpfs; I have 16G RAM. I have not noticed problems. I do this because I'm using a single SSD and I'd rather not end up hammering the SSD if something is doing insane things with memory. I'd assumed this was a reasonable configuration these days - am I misinformed? J. -- 101 things you can't have too much of : 3 - Sleep.
Re: debian-keyring not updated?
On Sat, Dec 03, 2016 at 11:39:44PM +0530, Pirate Praveen wrote: > On ശനി 03 ഡിസംബര് 2016 11:26 വൈകു, Mattia Rizzolo wrote: > > Yes, the package is not updated every time there is a keyring push. > > What's tagged is what is live on the debian.org infrastructure, not > > what's in the package (and probably you shouldn't rely on that either if > > you need an up-to-date keyring locally). > > > Thanks for the info. Previous uploads were more frequent so I wondered > if there was an issue. If you want the active keyring then the canonical way to get it is use rsync from keyring.debian.org::keyrings/keyrings/ - the sha512sums.txt file is always signed by one of keyring-maint. We also try to keep the read-only copy of the keyring git repo at https://anonscm.debian.org/cgit/keyring/keyring.git/ up to date when a new keyring is made active (pending changes are kept within a private repo for potential security reasons), but that's primarily because there are various things that use the git changelog to understand what changes have happened. The only time we make a concerted effort to ensure the debian-keyring package is up to date in the archive is around the release, so that stable has as current a copy as possible at the point of release. We do generally try and keep it up to date in unstable, but if you care about what's current you should always use the rsynced version. J. -- /-\ | 101 things you can't have too much |@/ Debian GNU/Linux Developer | of : 34 - Beaches. \- | signature.asc Description: Digital signature
Re: Looking for maintainer(s) of the sigrok packages
Aaron, if you're still interested in getting involved in looking after these I can help with giving things a look over and sponsoring their uploads (with the aim that you'd eventually go for at least DM status and be able to do the uploads yourself). On Fri, Jan 27, 2017 at 06:44:54PM +0100, Uwe Hermann wrote: > Hi, I'm looking for a maintainer (or a team of maintainers) for all > sigrok packages in Debian (see www.sigrok.org for details). > > I've already officially RFA'd the packages a few minutes ago. > > Lack of spare time doesn't currently allow me to keep the packages > up-to-date in a timely manner, plus I'm part of upstream and I'd like > to spend more time with upstream development rather than distro stuff. > > Hence, I'm looking for active DDs to take over the following packages: > > libsigrok-dev - sigrok hardware driver library - development files > libsigrok0-dev - sigrok hardware driver library (transitional dummy package) > libsigrok2 - sigrok hardware driver library - shared library > libsigrokdecode-dev - sigrok protocol decoding library - development files > libsigrokdecode0-dev - sigrok protocol decoding library (transitional dummy > package) > libsigrokdecode2 - sigrok protocol decoding library - shared library > libserialport-dev - Crossplatform serial port handling library - development > files > libserialport0 - Crossplatform serial port handling library - shared library > pulseview - sigrok logic analyzer, oscilloscope, and MSO GUI > sigrok - Logic analyzer and protocol decoder software suite (metapackage) > sigrok-cli - command-line frontend for the sigrok software > sigrok-firmware-fx2lafw - Firmware for Cypress FX2(LP) based logic analyzers > > Optionally, there are also still old open RFPs for these additional (less > important) sigrok-related packages: > > #669073 RFP: sigrok-dumps -- example logic analyzer protocol data for sigrok > #669074 RFP: sigrok-firmware -- firmware files for various logic analyzers > #681881 RFP: sigrok-util -- sigrok related utilities > > If any active DD is interested in taking over these packages, please > go ahead, no need to ask for permission. It probably makes sense to > have at least the packages that directly depend on each other be > maintained by the same DD(s). > > I'll be happy to answer any questions regarding upstream releases, > shared libs, versioning, etc. etc. However, I'll not be able to do any > sponsoring or mentoring of non-DDs (lack of spare time, see above). J. -- /-\ | "I've checked, but I can't find |@/ Debian GNU/Linux Developer | anything in the bible which \- |supports C++." -- Malcolm Ray signature.asc Description: Digital signature
Re: Looking for maintainer(s) of the sigrok packages
(It's probably reasonable to take this offlist now; no one else has spoken up as being interested.) On Mon, Jan 30, 2017 at 06:52:19PM +, Aaron Brady wrote: > I would still be interested yes, I'd let it fall off my radar because > without someone to sponsor my uploads it's hard to proceed and yeah, I aim > to eventually go for DM status. > > I went down a rabbit hole with pulseview which requires some fairly large Qt > dependency work to get up-to-date, but concentrating on the core sigrok > packages it should be possible to get those updated much sooner than > pulseview. > > I will need to see if that will definitely break / FTBFS the existing > pulseview version. Pulseview 0.2 is already not in testing due to a FTBFS so I wouldn't worry about it too much. 0.3 already supports QT5 which should make moving over easier. I think getting the core sigrok packages up to date is a good first step; probably in experimental during the freeze as there's a dependency from collectd on libsigrok2 which we don't want to affect. You previously mentioned using git-buildpackage; do you have an existing repo I can look at? > On Mon, 30 Jan 2017, Jonathan McDowell wrote: > > >Aaron, if you're still interested in getting involved in looking after > >these I can help with giving things a look over and sponsoring their > >uploads (with the aim that you'd eventually go for at least DM status > >and be able to do the uploads yourself). > > > >On Fri, Jan 27, 2017 at 06:44:54PM +0100, Uwe Hermann wrote: > >>Hi, I'm looking for a maintainer (or a team of maintainers) for all > >>sigrok packages in Debian (see www.sigrok.org for details). > >> > >>I've already officially RFA'd the packages a few minutes ago. > >> > >>Lack of spare time doesn't currently allow me to keep the packages > >>up-to-date in a timely manner, plus I'm part of upstream and I'd like > >>to spend more time with upstream development rather than distro stuff. > >> > >>Hence, I'm looking for active DDs to take over the following packages: > >> > >>libsigrok-dev - sigrok hardware driver library - development files > >>libsigrok0-dev - sigrok hardware driver library (transitional dummy package) > >>libsigrok2 - sigrok hardware driver library - shared library > >>libsigrokdecode-dev - sigrok protocol decoding library - development files > >>libsigrokdecode0-dev - sigrok protocol decoding library (transitional dummy > >>package) > >>libsigrokdecode2 - sigrok protocol decoding library - shared library > >>libserialport-dev - Crossplatform serial port handling library - > >>development files > >>libserialport0 - Crossplatform serial port handling library - shared library > >>pulseview - sigrok logic analyzer, oscilloscope, and MSO GUI > >>sigrok - Logic analyzer and protocol decoder software suite (metapackage) > >>sigrok-cli - command-line frontend for the sigrok software > >>sigrok-firmware-fx2lafw - Firmware for Cypress FX2(LP) based logic analyzers > >> > >>Optionally, there are also still old open RFPs for these additional (less > >>important) sigrok-related packages: > >> > >> #669073 RFP: sigrok-dumps -- example logic analyzer protocol data for > >> sigrok > >> #669074 RFP: sigrok-firmware -- firmware files for various logic analyzers > >> #681881 RFP: sigrok-util -- sigrok related utilities > >> > >>If any active DD is interested in taking over these packages, please > >>go ahead, no need to ask for permission. It probably makes sense to > >>have at least the packages that directly depend on each other be > >>maintained by the same DD(s). > >> > >>I'll be happy to answer any questions regarding upstream releases, > >>shared libs, versioning, etc. etc. However, I'll not be able to do any > >>sponsoring or mentoring of non-DDs (lack of spare time, see above). J. -- /-\ | Mac system message: Like, dude, |@/ Debian GNU/Linux Developer |something went wrong. \- | signature.asc Description: Digital signature
Re: [Pkg-sssd-devel] Bug#854354: sssd prevents system booting up
On Mon, Feb 06, 2017 at 02:50:27PM +0200, Timo Aaltonen wrote: > On 06.02.2017 12:49, Jonathan McDowell wrote: > > Package: sssd > > Version: 1.50.0-2 > > Severity: grave > > > > I updated my stretch system this morning which led to it failing to > > reach a login prompt; the system would start up and then avahi-daemon, > > ModemManager and NetworkManager would all fail to start, then > > systemd-logind would fail. This repeated in a continuous loop. Initially > > suspecting ModemManager or NetworkManager I tried removing them (the > > machine has wired ethernet, configured via /etc/network/interfaces), but > > this did not help. > > > > Looking at the errors provided by systemd in my logs led me to: > > > > https://lists.debian.org/debian-user/2017/02/msg00025.html > > > > which provided the clue I needed to try downgrading ssd from 1.15.0-2 > > (which was pulled in by the update this morning) to 1.14.2-1 (the > > previously installed version). The machine subquently rebooted cleanly. > > > > A coworker's machine was similiarly affected, and the same solution > > worked there. > > This is now fixed in 1.15.0-3 which had to wait for -2 to migrate first. > > Sorry for the inconvenience, the easiest way to restore sanity while you > wait for -3 is to remove /etc/systemd/system/sssd.service.wants. Demoting #854048 to "so that sssd can automigrate" seems to me to be abuse of the bug severity; this bug caused serious problems logging in for users of sssd and the package should not have migrated to testing. The existence of a work around is not a sufficient reason to do so; systems that ended up with the upgraded package would end up not coming up to a login prompt with an unclear root cause. J. -- "Scattered f***ing showers my ass." -- Noah
Re: Debian part of a version number when epoch is bumped
On Tue, Feb 06, 2018 at 10:19:25PM +, Colin Watson wrote: > On Tue, Feb 06, 2018 at 12:28:54PM +0100, Mattia Rizzolo wrote: > > On Tue, Feb 06, 2018 at 08:37:44AM +, Colin Watson wrote: > > > I disagree - reusing file names with different contents in a > > > Debian-format archive is IMO always wrong regardless of the time elapsed > > > between uses - but it's unlikely to be worth arguing. > > > > Do you happen to know what was the reason somebody way back in time > > decided to not consider the epoch in the filenames? > > My understanding is that it would have caused some kind of problems for > common operations at the time involving things like tar, but I'm afraid > I forget the details. Ian Jackson would probably know ... You can't put a : in a filename on a FAT filesystem. J. -- ... Purranoia: The fear that your cat is up to something.
Re: Raising the problem of Debian Single Sign On + Alioth (again)
On Fri, Feb 23, 2018 at 06:54:29PM +0100, Alexander Wirt wrote: > On Fri, 23 Feb 2018, Enrico Zini wrote: > > On Fri, Feb 23, 2018 at 03:49:06PM +0100, Alexander Wirt wrote: > > > > Are there other ways in stretch of getting apache to > > > > authenticate against gitlab? > > > I would wait for the gsoc project. And on the alioth sprint, > > > several people decided against using salsa as backend for sso, but > > > the other way round. So please don't. > > > > Please do not switch Alioth off, nor disable creation of new > > accounts on alioth, until then. Being able to get a SSO certificate > > as a non-DD is currently a required step to become a DD. > Then the dd process should get fixed, not making again something to a > backend which isn't meaned like that (we had the same problem with > alioth and debconf). Like it or not Alioth provides more services than just hosting repositories. One of these is authentication. Enrico has made a concerted effort to work out how Salsa can be used in a similar manner as Alioth to provide that authentication behaviour, with as little effort on the part of all concerned as possible, and your response is that you don't want Salsa to be used for that. This is absolutely the Salsa team's choice to make, but you have to accept that as a result once Alioth is turned off there will be no way for prospective DMs or DDs to authenticate to nm.debian.org. The attitude of "well nothing to do with us, the NM team should sort it out" is not appreciated. J. -- "F**k a duck." -- Walt Disney signature.asc Description: PGP signature
Re: Raising the problem of Debian Single Sign On + Alioth (again)
On Fri, Feb 23, 2018 at 08:17:26PM +0100, Alexander Wirt wrote: > On Fri, 23 Feb 2018, Jonathan McDowell wrote: > > > On Fri, Feb 23, 2018 at 06:54:29PM +0100, Alexander Wirt wrote: > > > On Fri, 23 Feb 2018, Enrico Zini wrote: > > > > On Fri, Feb 23, 2018 at 03:49:06PM +0100, Alexander Wirt wrote: > > > > > > Are there other ways in stretch of getting apache to > > > > > > authenticate against gitlab? > > > > > I would wait for the gsoc project. And on the alioth sprint, > > > > > several people decided against using salsa as backend for sso, but > > > > > the other way round. So please don't. > > > > > > > > Please do not switch Alioth off, nor disable creation of new > > > > accounts on alioth, until then. Being able to get a SSO certificate > > > > as a non-DD is currently a required step to become a DD. > > > > > Then the dd process should get fixed, not making again something to a > > > backend which isn't meaned like that (we had the same problem with > > > alioth and debconf). > > > > Like it or not Alioth provides more services than just hosting > > repositories. One of these is authentication. Enrico has made a > > concerted effort to work out how Salsa can be used in a similar manner > > as Alioth to provide that authentication behaviour, with as little > > effort on the part of all concerned as possible, and your response is > > that you don't want Salsa to be used for that. > > > > This is absolutely the Salsa team's choice to make, but you have to > > accept that as a result once Alioth is turned off there will be no way > > for prospective DMs or DDs to authenticate to nm.debian.org. > thats nonsense. alioth clearly showed that in the past, noone knows that > better than me. Because we would have to support it. > > > The attitude of "well nothing to do with us, the NM team should sort it > > out" is not appreciated. > Thats nonsense, I am working on an sso replacement for some time, since > nobody stepped in when we asked for it. Make up your mind. Either "then the DD process should be fixed" (as you wrote above) or we need an SSO replacement. If the latter then I think everyone is in full agreement and I appreciate the fact you're working on it. J. -- Web [ 101 things you can't have too much of : 38 - clean ] site: https:// [underwear.] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 signature.asc Description: PGP signature
Re: Updated proposal for improving the FTP NEW process
On Wed, Mar 07, 2018 at 06:02:10AM +, Chris Lamb wrote: > Andrey Rahmatullin wrote: > > > > I know for a fact that quite regularly licence checks on binNEW > > > > packages causes RC bugs to pop up. I acknowledge it may be a > > > > burder for the ftp team, but that reason alone probably deserves > > > > to keep binNEW as it is. > > > > > > That would seem to justify some sort of randomized spot checks > > > [..] > > > > Exactly. > > Whilst it does seem a little odd, there is some merit the current > system where packages get essentially-arbitrary chosen for a cursory > glance by a member the FTP team. Speaking as someone who has taken over a package, been negligent in ensuring debian/copyright was up to date and hit NEW as the result of a soname update I am grateful for the time that the FTP team (Chris, as it happens) invested to do a quick sanity check and tell me I was an idiot. As a result I discovered licensecheck and have become much better (though I doubt perfect) at ensuring such things stay up to date. If we had enough spare people power then I've no doubt a concerted sweep across the archive would find lots of packages that could do with some TLC, whether copyrights or elsewhere, but realistically that's just not going to happen. J. -- ] https://www.earth.li/~noodles/ [] Minorities are the foundation of [ ] PGP/GPG Key @ the.earth.li[] society. [ ] via keyserver, web or email. [][ ] RSA: 4096/0x94FA372B2DA8B985 [][
Re: Convenient access to Debian keyrings
On Sun, Apr 02, 2017 at 11:29:22AM +0800, Paul Wise wrote: > On Sun, Apr 2, 2017 at 7:06 AM, gregor herrmann wrote: > > > % crontab -l | grep debian-keyring > > 30 17 * * * /usr/bin/rsync -rlptDq > > "keyring.debian.org::keyrings/keyrings/*.gpg" > > /home/gregoa/.gnupg/debian-keyring > > The rsync protocol is unencrypted, I'd suggest switching this to SSH > (one colon instead of two). You could also use rsync over TLS on port > 1873 (uses the same cert as via http). I couldn't easily work out how > to do it with stunnel but the following works with socat. I thought > there was also a way to verify the keyring when it was at rest but > can't find where I saw that. If you do an rsync of keyring.debian.org::keyrings (no second keyrings/) you get a sha512sums.txt file as well which will be signed by one of keyring-maint. J. -- Give me liberty or I will cut | .''`. Debian GNU/Linux Developer you.| : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers. signature.asc Description: Digital signature
Re: DPL election terms 1 year was Re: X facts about Debian - some fact checking and looking for ideas.
On Tue, Aug 29, 2017 at 11:37:09PM +0530, shirish शिरीष wrote: > Dear all, > > Please CC me if somebody puts a reply > > Another query but of more recent vintage is the idea of having yearly > elections for choosing DPL. Now while sadly Ian Murdock is not there > but am sure there are more than enough people who know and remember > why Ian Murdock felt the need to have yearly elections instead of a > 2-5 year term. Can I suggest that debian-devel is not an appropriate forum for your research into Debian's past? I would suggest -curiosa, -research or perhaps -project would all be better places to ask these questions. J. -- There are never any bugs you haven't found yet.
Re: Alioth: the future of mailing lists
On Tue, Sep 19, 2017 at 03:16:23PM +0200, Wouter Verhelst wrote: > On Mon, Sep 18, 2017 at 02:55:26PM +0200, Raphael Hertzog wrote: > > On Mon, 18 Sep 2017, Axel Beckert wrote: > > > Alexander Wirt wrote: > > > > - Distribution lists for use in the Maintainer: field. We suggest > > > > that, with maybe some extra code, this use-case could be well served > > > > by the tracker.debian.org service for almost all purposes. > > > > > > Reading https://tracker.debian.org/docs/about.html#email-interface it > > > seems that the e-mail address @tracker.debian.org is usable > > > not only for tracker-generated mails. > > > > Hum, that documentation is a bit outdated. What you have to use is > > actually dispatch+@tracker.debian.org. But I would not want > > people to use this email address in Maintainer fields. > > > > Instead we should use @packages.debian.org. But for this we > > need a lintian upload and a lintian backport to be installed on > > ftp-master: > > Er, that would create a mail loop. @packages.debian.org > redirects to the data of the maintainer field. If you put that address > in the maintainer field, it redirects to itself, again and again and > again and again and... My understanding is that Raphaël fixed that last year: https://anonscm.debian.org/cgit/webwml/packages.git/commit/?h=debian-master&id=5f4f27920e996e521d32dfb5a9693a09348d18d5 (linked from the bug report he referenced in his email that you quote) J. -- "Reality Or Nothing!" -- Cold Lazarus
Re: Team naming policy on salsa.debian.org
On Mon, Dec 25, 2017 at 11:45:37AM +0100, Alexander Wirt wrote: > Teams > - > > For larger projects you can also create a group to host your projects. > To avoid clashes with usernames (that share the same namespace as > groups) we are requiring groups to have a '-team' suffix to their > name. Groups can be created using the same self-service portal > https://signup.salsa.debian.org. For larger, already-established > teams it is also possible to ask us to create the group with a name > not conforming to the normal team namespace. Examples are teams like > *debian-qa*. Please create an issue in the support[1] project. Is there a policy here? I'm seeing a mix of formats rather than any consistency. For example for keyring-maint should we request debian-keyring as a group, or just use keyring-team? DSA and ftp-master have gone for the latter (dsa-team + ftp-team) but I'd assumed the former was more appropriate for an official Debian entity. Likewise for pkg-electronics I was expecting pkg-electronics-team (to match, e.g., pkg-suricata-team) but I see things like libvirt-team as well so the pkg- prefix doesn't seem to be consistently used/unused. Guidance appreciated. I don't want to make an effort to move over and update URLs etc only to have to do so a second time because the team name wasn't of the correct format. J. -- 101 things you can't have too | .''`. Debian GNU/Linux Developer much of : 50 - Escalators. | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers. signature.asc Description: PGP signature
Re: support for merged /usr in Debian
On Fri, Jan 08, 2016 at 06:38:05PM +0100, Marc Haber wrote: > On Fri, 8 Jan 2016 15:01:53 +, Jonathan Dowland > wrote: > >and since you are running sid anyway, it wouldn't even help you, so > >I'm puzzled why you suggested it. > > You obviously don't see the difference between a customer, a client > machine and a server. This might be a matter of language, so I'll > explain it. You're not communicating clearly and this is indeed causing problems in this thread. You said "all my clients run unstable", not "all my client machines run unstable". You've also later said "I've not installed any new Debian systems at any client site". It is not unreasonable that the casual reader will assume you are using the term to mean a 3rd party who you are managing system for. To attempt to add some signal to my noise, the gist of this thread seems to be that Marco wants to make it easy for those who wish to have a merged /usr to do so, and is not planning to force this upon anyone. As far as I can tell what he wants to happen is a) files in / and /usr locations not to conflict and b) policy to state that this should be the case. I find it hard to object to this request, even without a merged /usr approach. There is a separate discussion which has been going on for much longer which is about whether / and /usr are well supported as separate filesystems, but that seems to have little to do with whether usrmerge is undertaken or not. J. -- ... "OK ... First I'll access the secret military spy satelite that is in geosynchronous orbit over the midwest. Then I'll ID the limo by the vanity plate "MR. BIGGG" and get his approximate position. Then I'll reposition the transmission dish on the remote truck to 17.32 degrees east, hit WESTAR 4 over the Atlantic, bounce the signal back into the aerosphere up to COMSAT 6, beam it back to SATCOM 2 transmitter number 137 and down on the dish on the back of Mr. Big's limo... It's almost too easy." -- Garth Algar, Wayne's World signature.asc Description: Digital signature
Re: support for merged /usr in Debian
On Fri, Jan 08, 2016 at 07:09:59PM +0100, Marc Haber wrote: > On Fri, 8 Jan 2016 17:54:49 +0000, Jonathan McDowell > wrote: > >You're not communicating clearly and this is indeed causing problems > >in this thread. You said "all my clients run unstable", not "all my > >client machines run unstable". You've also later said "I've not > >installed any new Debian systems at any client site". It is not > >unreasonable that the casual reader will assume you are using the > >term to mean a 3rd party who you are managing system for. > > You're right to blame for only speaking english for 30 years of my > life and living in a country where TV programs are dubbed. I am also > deeply worried about the Operating System I still care about after 15 > years and which works so hard to feel not like a home any more. I'm not sure how you've taken any of this meaning from my message. You have inconsistently used certain terms such that it's not surprising they have been misunderstood by others in this thread. I am not in any way complaining about your grasp of the English language. > >To attempt to add some signal to my noise, the gist of this thread seems > >to be that Marco wants to make it easy for those who wish to have a > >merged /usr to do so, and is not planning to force this upon anyone. > > I would believe that if it were somebody else. If you are going to assume bad faith on the parts of other developers then it is very unlikely you will see a satisfactory resolution of this discussion. It doesn't seem a helpful way to view your interactions with the project. I'll accept Marco's style can be very abrupt, but having a knee-jerk reaction that he must be up to no good is not helpful. > >As far as I can tell what he wants to happen is a) files in / and > >/usr locations not to conflict and b) policy to state that this > >should be the case. > > If that is really the gist of those editorial changes[1], then this is > actually a misunderstanding. Maybe UsrMerge is even a misnomer. These are not editorial changes. There's a clear desire for a change in the way things are handled, and I don't believe there is any need to ascribe an ulterior motive to it. Marco wants to be able to merge / and /usr on his systems. Various other people do as well. If we, as a project, say that we should not have duplicate file names between these portions of the file system then they can have their desire and the rest of us can continue to keep them separate. It seems to me to be one of those requests that really doesn't cause an imposition on those who can't care about the change (or even actively don't want to do it), while being really quite helpful to those who want to do things a bit differently. J. [1] NMF. -- 101 things you can't have too | .''`. Debian GNU/Linux Developer much of : 48 - Pies.| : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers. signature.asc Description: Digital signature
Re: DTBs in the ESP, why?
On Tue, Oct 22, 2024 at 01:42:26PM +0900, Simon Richter wrote: > On 10/22/24 05:44, Aurelien Jarno wrote: > > > This is a native package useful for the riscv64 port, but which might also > > be > > useful for some arm boards, therefore the goal is to provide the binary as a > > arch:all package. > > I remember the absolute insanity when ACPI was new and we basically assumed > any pre-2000 BIOS would have bad tables, and if you wanted ACPI, you needed > to bring your own tables. > > I do not wish to repeat this experience, and my feeling is that the way the > boot specifications are written for riscv, with every side pushing > responsibility away from themselves, we are going exactly that way. It's worth noting this is also a problem for ARM64 laptops, not just riscv64 boards; my X13s requires a DTB on the EFI partition to boot successfully. I too would prefer not to undo the progress that has been made from the every board is special days, but here we are. J. -- Purranoia: The fear that your cat is up to something.
Re: GnuPG 2.4 before Trixie freeze
On Mon, Jan 13, 2025 at 11:08:11AM +0100, Simon Josefsson wrote: > Daniel Kahn Gillmor writes: > > I welcome review and critique of the packaging for this tricky package, > > which is pretty deeply embedded in Debian (though getting less so, as > > apt no longer requires it and we have many other OpenPGP implementations > > available today). I'd be even more delighted with offers of active > > co-maintenance beyond the work that Andreas and i have been doing. > > I've offered help, but my impression has been that it not giving up on > the schism thing has been more important than getting Debian to ship > upstream code to users and let people decide what they want to use. > > Sometimes it is better to let other make decisions rather than to make > decisions for others. I agree, but in this instance given the reliance we have upon GnuPG throughout the Debian ecosystem I believe it's important we ensure that the default configuration of what we ship is compatible with OpenPGP. Power users can feel free to play with OpenPGP v6 / LibrePGP enhancements, but for the vast majority of folk sticking to RFC compliant v4 is going to make the most sense. Given what I've seen in this thread though it sounds like the appropriate patches have been worked out and it might be feasible to get 2.4 into unstable? J. -- 101 things you can't have too much of : 31 - Hot showers. signature.asc Description: PGP signature
Re: GnuPG 2.4 before Trixie freeze
On Mon, Jan 13, 2025 at 02:04:00PM +0100, Simon Josefsson wrote: > Jonathan McDowell writes: > > On Mon, Jan 13, 2025 at 11:08:11AM +0100, Simon Josefsson wrote: > >> Daniel Kahn Gillmor writes: > >> > I welcome review and critique of the packaging for this tricky package, > >> > which is pretty deeply embedded in Debian (though getting less so, as > >> > apt no longer requires it and we have many other OpenPGP implementations > >> > available today). I'd be even more delighted with offers of active > >> > co-maintenance beyond the work that Andreas and i have been doing. > >> > >> I've offered help, but my impression has been that it not giving up on > >> the schism thing has been more important than getting Debian to ship > >> upstream code to users and let people decide what they want to use. > >> > >> Sometimes it is better to let other make decisions rather than to make > >> decisions for others. > > > > I agree, but in this instance given the reliance we have upon GnuPG > > throughout the Debian ecosystem I believe it's important we ensure that > > the default configuration of what we ship is compatible with OpenPGP. > > Power users can feel free to play with OpenPGP v6 / LibrePGP > > enhancements, but for the vast majority of folk sticking to RFC > > compliant v4 is going to make the most sense. > > I understand this concern, but I believe there is a strong bias for > Debian developers to care about our own use-cases a lot which may not be > particulary relevant outside the scope of Debian-internal development. > > I believe it would be perfectly fine to ship verbatim upstream unpatched > GnuPG 2.4 and work out any Debian-specific quirks and requirements we > have and put quirks into tools that are external to GnuPG itself. I don't agree. For trixie I would like us to ship a GnuPG which _by default_ does not emit LibrePGP packets. I'm fully in favour of that ability being available to folk who chose to explicitly enable it, but I don't think it's a responsible default for us to ship. It's a simple fact that the OpenPGP ecosystem, including GnuPG, is complicated for folk who are not devoting significant time to understanding it all. We've seen that previously in terms of having to write documentation about how to generate keys with secure settings, or explain why we've made certain decisions that deviate from what an out-of-the box config would give. We're not an outlier in patching GnuPG to provide OpenPGP v4 defaults. (This email written wearing no hats, but definitely informed by the fact I'm part of keyring-maint.) J. -- "I'm a paranoid agnostic. I doubt the existence of God, but I'm sure there is some force, somewhere, working against me." -- Marc Maron signature.asc Description: PGP signature
Re: GnuPG 2.4 before Trixie freeze
On Tue, Jan 07, 2025 at 07:01:51PM +0100, Andreas Metzler wrote: > On 2025-01-07 Simon Josefsson wrote: > [...] > > > I believe this would be good, I frequently run into GnuPG bugs in the > > 2.2.x branch that was fixed years ago in 2.4 and today I mostly these on > > Debian because others moved on to 2.4.x. Andreas, can you give a > > current status of pending issues for experimental->unstable upload? > > Hello, > ... guessing I might be the Andreas in question ... > > Afaik there is no /known/ blocker except for the libgnupg-interface-perl > test error #1088155. > > Should we move to 2.4? 2.4 is not a LTS release and will also EOL in > trixie' soon (2026-06-30). I haven't been fully following the GnuPG situation, but did the situation where 2.4 would generate v4 keys that weren't fully compatible with the wider ecosystem get solved? Is the patch RedHat et al are carrying sufficient for that? J. -- Revd Jonathan McDowell, ULC | Covered in paint and high as a kite.
Re: OpenPGP certificates with SHA-1 issues in Debian keyrings
[I don't have enough time at present to fully drive this from a keyring-maint PoV, but without any hats on I thought I'd add a couple of extra bits of information.] On Fri, Mar 21, 2025 at 01:11:20AM +0100, Guillem Jover wrote: On Thu, 2025-03-20 at 22:00:04 +0100, Christoph Biedl wrote: Being one of those on the list, I'm even more confused than I'd be about this anyway. Ok, let me try to clarify, then! So those people you listed: * Did they something wrong (although certainly with best intentions)? I don't think so, or at least if they did something explicitly, probably not wrong at the time they did it. No fault on the part of the user. Previous versions of GnuPG had defaults whereby even if you generated a large RSA key, rather than a 1024 bit DSA key, it would use SHA-1 for UID + subkey binding signatures. It took some explicit manual configuration before a key was ever created to avoid this. * Is this a problem if apparently everything went fine in the many past years? I think there's widespread agreement that using SHA-1 in a security context is not wise at this point in time. The problem is that when using GnuPG this is sometimes invisible unless asked for explicitly. My understanding is that there aren't any known attacks against SHA-1 self-sigs in OpenPGP at present. Given the issues with SHA-1 migration away from it makes sense, but it's Sequoia making a decision to treat SHA-1 self-sigs as no longer valid, combined with dpkg's switch to Sequoia, that's driving the issue here. I note that the Sequoia lint checks are not available in bookworm, you need to use the version in trixie/sid. I'm happy to try to address anything that seems unclear, or get someone else who might be able to answer! And as Holger suggested elsewhere, we can probably also create a FAQ on the wiki with some of this to point to people. Thanks for doing this, Guillem. J. -- ] https://www.earth.li/~noodles/ [] "f u cn rd ths, u cn gt a gd jb n [ ] PGP/GPG Key @ the.earth.li[] cmptr prgrmmng." -- Simon Cozens, [ ] via keyserver, web or email. []ox.os.linux [ ] RSA: 4096/0x94FA372B2DA8B985 [][
Re: Change the expectation that emails should wrap at 80 characters
On Fri, Feb 28, 2025 at 06:30:00PM +0100, tho...@goirand.fr wrote: > On Feb 27, 2025 12:02, Blair Noctis wrote: > > actually struggle to read the hard-wrapped-at-80-then-wrapped-again text. > The standard for email is 74 chars, not 80... RFC2822 says 78 characters. https://datatracker.ietf.org/doc/html/rfc2822#section-2.1.1 J. -- Sunday morning is every day for | .''`. Debian GNU/Linux Developer all I care... and I'm not | : :' : Happy to accept PGP signed scared. | `. `' or encrypted mail - RSA | `-key on the keyservers.
Re: Change the expectation that emails should wrap at 80 characters
On Sun, Mar 09, 2025 at 10:13:51PM +0100, Philip Hands wrote: > Soren Stoutner writes: > > On Saturday, March 8, 2025 4:23:56 PM MST Philip Hands wrote: > >> Soren Stoutner writes: > >> > At this point in the discussion I would like to progress toward a > >> > decision. > >> > > >> > One way to do so would be a GR. On one hand, using a GR to > >> > modify one line of the code of conduct for the mailing list seems > >> > like a rather large hammer for a rather small problem. But on > >> > the other hand, many people feel strongly enough about this that > >> > a GR might be the only mechanism where people will feel like the > >> > outcome is fair. > >> > > >> > My question is, is there any other decision making process that > >> > would be preferable to a GR to decide this issue? > >> > >> You seem to be under the impression that there's an emerging > >> consensus in favour of your idea. > > > > Yes, I feel like there are a majority of Debian Developers who are > > in favor of making the change that I propose, partially based on the > > number of people who have commented only once in the conversation > > with a short message in favor of the change. > > OK, so that provoked me to check if it's my input filter that's > defective, or yours. > Having skimmed through the 106 mails I currently see in this thread, > this is the way I'd summarise people's preferences (if anyone sees > that I've mis-characterised their view, I promise it was not > intentional, so please forgive me and correct my mistake) > * Unclear … > Jonathan McDowell To clarify, given I didn't explicitly state a position, I am against the proposal that we should switch to not wrapping email text. I'm generally in favour of format=flowed as this seems to offer the best of both worlds (a graceful degradation to the current state of affairs for clients that don't support it, and some hints about where it's ok to wrap for clients that do) and have made use of Colin Watson's helpful suggestions to fix my own configuration to use this. I J. -- Suburbia: where they tear out the trees & then name streets after them. signature.asc Description: PGP signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Tue, Mar 11, 2025 at 04:29:24PM +0100, Simon Josefsson wrote: However if Debian dismiss those ideas, the argument that the fully free installer doesn't exist because "nobody is working on this, go create them and it will happen" does not seem valid to me. My reading is that these images doesn't exist because Debian had a vote saying they should not exist. I hope this will change in the future. Creating them won't change the decision, but it may be input to renewed discussion. Debian had a vote where we made it clear that we were ok with making use of limited project + developer resources and only testing + shipping an installer which also includes the non-free-firmware component. It wasn't "this should not exist" it was "we're not trying to double your workload, images team". I've not seen _anyone_ suggest that the project would try and stop someone from going off any building CD images that didn't include non-free-firmware, just that we don't expect the existing images team to have to expend more effort to make that happen. J. - Bored of this argument going round in circles. -- ] https://www.earth.li/~noodles/ [] I'm out of bed and dressed. What [ ] PGP/GPG Key @ the.earth.li[] more do you want? [ ] via keyserver, web or email. [][ ] RSA: 4096/0x94FA372B2DA8B985 [][
Re: Misconfigured bookworm upgrades
On Fri, Feb 28, 2025 at 10:57:31AM +, Colin Watson wrote: > Ian Fleming wrote: "Once is happenstance. Twice is coincidence. The third > time it's enemy action." I've only got as far as coincidence so far, but > it's still enough to make me wonder. > > The following bugs on openssh both report problems with applying a recent > security update on bookworm, because it depends on a libssl3 version that > was added to bookworm in a point release: > > https://bugs.debian.org/1098272 > https://bugs.debian.org/1099091 > > This is clearly (to my mind) a misconfiguration, so I've rejected them as > bugs on openssh: we don't support installing only security updates and never > upgrading to packages from new point releases, because those aren't > rigorously separate streams: security updates are built against the stable > suite and so may pick up versioned dependencies against it. But seeing two > users who seem to have their systems configured this way makes me wonder > what's going on. Does anyone know of documentation somewhere that > recommends configuring stable systems this way? As a datapoint, I have not seen documentation that recommends doing this, but I have on occasion removed the main archive from my sources.list leaving only security updates. I have done this post point release when I do not yet have a window scheduled for a reboot post point release update, but do want to get security fixes. It did not occur to me that such a thing could be considered a misconfiguration, I've always assumed that libraries wouldn't change enough in stable that this sort of thing would occur. J. -- 101 things you can't have too much of : 36 - Spare video tapes.
Re: git branches vs debian specific git tools (Re: RFC for changes regarding NMU in developers reference
On Wed, May 14, 2025 at 12:33:49PM +0300, Andrius Merkys wrote: On 2025-05-14 12:29, Simon Josefsson wrote: Indeed this is a mess. (I wouldn't count d/control Vcs-* though?) d/control has Homepage as well. Has there been any work towards a single-file declarative file syntax to generate all the debian/ files? Yes, there was such an effort advocated by one person, but I cannot recall any details about it to help locating it. Perhaps you mean Niels Thykier's work on debputy: https://people.debian.org/~nthykier/blog/tag/debputy.html J. -- Revd Jonathan McDowell, ULC | I don't know. I'm a dog.
