Re: what about Netplan?
On Mon, Jul 15, 2024 at 02:57:21AM +0200, Cyril Brulebois wrote: > Lukas Märdian (2024-07-11): > > Additional benefits of Netplan: > > * Already used on Debian Bookworm [cloud] images by default > > Having started to toy with cloud images these last few days, and > learning about the various components in there, I'm not exactly sure > where /etc/netplan/90-default.yaml is coming from but it's 644 in at > least Debian 12 and Debian sid “nocloud” amd64 images (QCOW format), > leading netplan to complain about these too-wide permissions. > > I'm not sure where this file is coming from, but it'd be great to have > those permissions fixed/those warnings go away. > > I'd be glad if someone could take it up from here, I've burned up all > the time I had to spend on Netplan on the short term. Thanks already! I think that may be a cloud image specific issue. Will look deeper...
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote: > > I have drafted a new DEP at > > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: > > Enable true open collaboration on all Debian packages". > > Hi Otto, > > thank you for your initiative, > > one problem I have with NMUs in team-maintained package is that they > often bypass Salsa… Would it make sense to add to the DEP a request > that NMUs are started from and pushed to the default branch? +1 Regardless of what VCS is used, an NMU that bypasses it just makes more work for the maintainer. If not pushed, there should at minimum be an open merge request that applies cleanly to whatever was in the archive prior to the NMU. It would be nice to codify this. noah
Re: Removing more packages from unstable
On Tue, Aug 20, 2024 at 11:09:51AM +0200, Bastian Venthur wrote: > I think popcon does give a good approximation of how much percent of people > installed a certain package even if not everyone uses it, don't you agree? No, definitely not. There are hundreds of thousands of Debian systems running in various cloud environments, and I'd be surprised if any of them have ever submitted popcon data. > Last time I installed Debian it was still enabled by default. Oh? I don't think it has ever been enabled by default. noah
Re: Vancouver meeting - clarifications
On Wed, Mar 23, 2005 at 01:07:07PM +0100, Wouter Verhelst wrote: > On Wed, Mar 23, 2005 at 01:46:17AM +0100, Pierre THIERRY wrote: > > - Debian: 11 ports, 9157 packages (sarge) [17593 in sid] > > - NetBSD: 55 ports, 5300 packages > > It should be noted that the definition of 'port' isn't necessarily the > same if you compare NetBSD against Debian; for instance, NetBSD/mac68k > and NetBSD/amiga count as two ports, whereas in Debian, they count as > one (albeit the 'subarchitecture' is different) Additionally, they do not provide binaries for all their packages. In fact, the pkgsrc collection does not even follow the normal release cycle. When NetBSD is ready to release, they simply take a snapshot of pkgsrc. It's not even a requirement that the packages in pkgsrc are even buildable on all supported platforms. NetBSD is able to support as many platforms as they do because they have very different requirements for "support" than we do. It's not a good idea to compare us to them. noah pgpsqrooX3nPQ.pgp Description: PGP signature
removal of lukemftpd and lukemftp from debian
Hi all. I sent the following to Takuo KITAME on Monday, 20 March, and have yet to get a reply. Please read and comment: The lukemftpd and lukemftp packages have been replaced upstream by tnftpd and tnftp [1] and have not seen any maintainer activity since 2002. [2] The tnftp package (an ftp client) is in the archive [2], and should probably replace lukemftp. It does properly Conflict with and Replace lukemftp in debian/control. However, it also does not get any maintainer support and has had an open RC security bug with an attached patch for more than 1 year. I will prepare an NMU of the current upstream release to fix this bug ASAP. So, before I file a bug against ftp.debian.org requesting the removal of the lukemftp* packages, would anybody like to speak up in their defense? I'm willing to adopt tnftp and package tnftpd so it can replace lukemftpd, if that's what needs to happen. noah 1. http://freshmeat.net/projects/tnftpd http://freshmeat.net/projects/tnftp 2. http://packages.qa.debian.org/l/lukemftp.html http://packages.qa.debian.org/l/lukemftpd.html 3. http://packages.qa.debian.org/t/tnftp.html signature.asc Description: Digital signature
Re: System users that receive mail in /var/mail/systemuser?
On Mon, Apr 10, 2006 at 11:43:53AM -0700, Stephen Samuel wrote: > Also: in my experience, I've rarely received spam for system users other > than postmaster and webmaster -- and those are probably due to DNS > registrations and the like. Really? I get spam addressed to ftp, cyrus (the Cyrus IMAP system), postfix, apache, daemon, etc etc all the time. Those are very common user names, and (even better for the spammers) their mail is typically aliased to a group of people. They're probably in every spammers list of dictionary words to try. Still, though, even if I'd never expect legitimate mail to e.g. my proftpd user, I'd certainly not want to automatically discard it. I'd prefer a default configuration that sent it to root, but that could easily be overridden. noah signature.asc Description: Digital signature
Bug#362454: ITP: kredentials -- KDE systray applet for managing AFS and Kerberos credentials
Package: wnpp Severity: wishlist Owner: Noah Meyerhans <[EMAIL PROTECTED]> * Package name: kredentials Version : 0.7.1 Upstream Author : Noah Meyerhans (yes, that's me) * URL : http://people.csail.mit.edu/noahm/kredentials * License : MIT Description : KDE systray applet for managing AFS and Kerberos credentials Kredentials is a KDE systray applet for keeping Kerberos and AFS authentication tokens current. Each hour it renews Kerberos tickets and (optionally) obtains new AFS tokens, and it notifies the user upon final ticket expiration. -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.15.4-csail Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
appropriate use of /etc/alternatives
I intend to package the xplot utility from xplot.org. This tool is useful with the tcptrace package, which I maintain. However, there's already an xplot package that installs /usr/bin/xplot. It's not compatible with xplot.org, but does essentially the same thing (plots data in X). I suggested to the xplot maintainer, Peter Galbraith, that we use /etc/alternatives to manage a /usr/bin/xplot symlink. He doesn't think that it's an appropriate use of alternatives, since the tools are not compatible. Do others agree? On what level do tools need to be compatible in order to go into alternatives? I'm sure there are a number of examples of alternatives that are incompatible on at least some level (think nvi and vim config files, for example), but they do essentially the same thing. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpa7SHSM9XHi.pgp Description: PGP signature
Re: appropriate use of /etc/alternatives
On Fri, May 30, 2003 at 02:25:48PM -0400, Ben Collins wrote: > I agree. A user should not have to concern themselves about which one > they are using. If the command name is the same, they better support the > same functionality. But they do support the same functionality, just on different formats of data file. There are plenty of cases where a user needs to be aware of which specific alternative they're using. /usr/bin/zsh can run zsh version 3 or 4, depending on alternatives. If the user is going to write a script in zsh, he better know which version he's getting, otherwise he may write code using a feature not present in the version he's running. On some level, zsh3 is incompatible with zsh4, though they both basically do the same thing. Same with the two xplot tools. > Sounds to me like you don't even want to call the package just xplot, to > avoid confusion. Maybe xplot-ng? :) Well obviously my package won't be called xplot, there's already an xplot package. But I don't want to rename the binary that gets installed by it. If we can't use alternatives to manage /usr/bin/xplot in this case, my package will simply end up conflicting with the existing xplot package, which is neither necessary nor desirable. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgp6A72pdVAbf.pgp Description: PGP signature
Re: appropriate use of /etc/alternatives
On Sat, May 31, 2003 at 02:00:41PM +0100, Mark Brown wrote: > The binary is going to have to be renamed - even if you use an > alternative there'll still be a renamed binary there. yes, but the user would only need to know in the even that they had both alternatives installed, which I don't see happening very often. > Would it be possible to massage the data format for one xplot into the > other or modify one to accept the input of the other in a compatibility > mode? Possibly, but why create more work for the user? I guess xplot-xplotorg will just end up conflicting with xplot. It sucks, since that means the new package winds up in the ghetto (priority extra) but it's preferable to the options available. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpRkqahPTmNJ.pgp Description: PGP signature
what to do with iputils (ping, etc)
Before I go off and do something drastic like fork the iputils packages
(the packages that give us a handy little tool called 'ping') I'd like
to ask for advice from the wider community.
The iputils source package builds the iputils-{ping,tracepath,arping}
binary packages. Iputils-ping is the default ping in Debian, and is
thus rather important to get right. Unfortunately, the upstream source
and build process is a mess. The upstream developer is one of the
kernel network stack maintainers, and he wants the iputils package to
always work with the latest and greatest kernel functionality. As a
result, he includes lots of kernel headers in his programs rather than
using standard headers from /usr/include.
At one point I fixed the tracepath code so it would build using standard
headers. (I never uploaded the fix.) I haven't fixed ping, etc. The
thing is, this was so intrusive to both the build system and the code
that it can only be described as a fork. I'm not completely opposed to
forking this code, since it's fairly mature and not wildly changing (in
fact, there hasn't been a new release in quite some time... like years)
and it would allow me to clean it up a bit. But I'd like to get a
second opinion...
noah
signature.asc
Description: Digital signature
Re: what to do with iputils (ping, etc)
On Fri, Oct 21, 2005 at 08:51:43PM +0200, Marco d'Itri wrote: > > and build process is a mess. The upstream developer is one of the > > kernel network stack maintainers, and he wants the iputils package to > > always work with the latest and greatest kernel functionality. As a > > result, he includes lots of kernel headers in his programs rather than > > using standard headers from /usr/include. > So what? There is nothing wrong with this. Tell that to the hurd or kFreeBSD people. > > At one point I fixed the tracepath code so it would build using standard > > headers. > I'd say you *broke* the code. By making it no longer Linux specific? By making it use POSIX datatypes? How does that follow? (Actually, I think the tracepath packages may in fact be Linux-specific; ping and traceroute6 certainly shouldn't be.) > > second opinion... > It's not obvious which problem you are trying to solve. Bugs like 163254 and 285420. noah signature.asc Description: Digital signature
Re: what to do with iputils (ping, etc)
On Fri, Oct 21, 2005 at 12:54:53PM -0700, Thomas Bushnell BSG wrote: > > Folding the headers into the package does not advance this goal, it > retards it. The inclusion of the kernel headers into the package was an explicitly temporary fix for version 3:20020927-2: * Build system cleanup. Stop including anything from /usr/src/linux. We still define our own versions of things that should be included from /usr/src/sys, and this needs to be fixed, but I will wait until post sarge to do so. (Closes: Bug#223164) At this point the package should probably build-depend on linux-kernel-headers and use the headers from that package in order to avoid maintaining its own copy of the files. However, I'm still not convinced there needs to be anything linux specific in this package. noah signature.asc Description: Digital signature
Re: what to do with iputils (ping, etc)
On Fri, Oct 21, 2005 at 10:13:30PM +0200, Marco d'Itri wrote: > > Is a portable version required to be not working and not up to date? > If the upstream maintainer is not interested in it, yes. It depends on what you mean by "up to date". If we're only including glibc headers, then we can only use functionality that glibc supports. If we bypass glibc and directly use kernel functionality, then we get all the latest and greatest kernel networking features. However, the programs are then entirely linux specific, and may even fail to work correctly on different (typically older) version of Linux. So yes, in some sense, a portable ping may be out of date. This is exactly why the upstream author didn't accept my patches to remove the dependency on kernel headers. He cares more about the package being up to date. Our requirements may be slightly different, though. noah signature.asc Description: Digital signature
Re: what to do with iputils (ping, etc)
On Fri, Oct 21, 2005 at 10:54:58PM +0200, Marco d'Itri wrote: > > So yes, in some sense, a portable ping may be out of date. This is > > exactly why the upstream author didn't accept my patches to remove the > > dependency on kernel headers. He cares more about the package being up > > to date. Our requirements may be slightly different, though. > Please let me know if you plan to remove features from iputils, so > I will start maintaining a new, fully working package. It's worth noting that at this point I believe "portable" and "up-to-date" are not mutually exclusive. They may be in the future. That makes it somewhat hard to justify maintaining a separate package, IMO. But that's just me. noah signature.asc Description: Digital signature
Re: what to do with iputils (ping, etc)
On Fri, Oct 21, 2005 at 11:52:02PM +0200, Marco d'Itri wrote: > > How on earth does supporting that feature require incompatibility with > > other systems? > It does not, but the iputils maintainer is hinting that this is the > package status. I never said anything about the PMTU discovery features. In fact, I said that up to date != linux-specific *at this moment*. I believe that PMTU discovery is perfectly fine, given that the given sockopts exist in the libc headers. Given the fact that iputils hasn't seen an upstream update in more than 2 years, we may never actually lose *anything* by converting the package to use only libc headers. Where we may lose is if upstream adds new features that are not yet handled by libc. Even then, though, we may be able to work around them in the package by adding our own linux specific definitions when building for Linux systems. noah signature.asc Description: Digital signature
Re: what to do with iputils (ping, etc)
On Sat, Oct 22, 2005 at 12:59:41PM +0200, Adrian von Bidder wrote: > > It depends on what you mean by "up to date". If we're only including > > glibc headers, then we can only use functionality that glibc supports. > > If we bypass glibc and directly use kernel functionality, then we get > > all the latest and greatest kernel networking features. > > What kind of features are we talking about here? Hypothetical networking features that may be added to Linux in the future. As I've said, I do not believe any existing features will need to be removed in order to remove the linux specific bits of this package. The problem with making this change is really that it'll be so disruptive as to make it hard to consider the code as anything other than a fork. I'll revisit this claim, though. Maybe I can keep things from being quite so drastic. We'll see. I'm going to make an upload of iputils soon to fix a bunch of bugs, but after that, I'll see what I can do to please everybody and get the best of both worlds... noah signature.asc Description: Digital signature
per-user temp directories by default?
Within the security team, there has recently been some talk of pushing for per-user temp directories by default in etch. I'd like to see what people's reaction to such a proposal would be. There are a number of outstanding "insecure tempfile vulnerabilities", and there has been some talk that they're both too numerous and of low enough impact that they're not even worth releasing DSAs for. Never the less, they are potentially dangerous and should be dealt with on some level. We believe that using libpam_tmpdir by default should make nearly all of these vulnerabilities cease to be relevant (there are some braindead apps that have /tmp hardcoded and don't use $TMP or $TMPDIR). As far as I can tell, we would simply need to move libpam-tmpdir from priority "optional" to "required" and modify the default /etc/pam.d/common-session to include the following line: session optionalpam_tmpdir.so I have little operational experience with this PAM module, though. Does it cause problems for certain apps? If so, could these problems be solved with a less simplistic PAM configuration? noah signature.asc Description: Digital signature
Re: per-user temp directories by default?
On Fri, Nov 04, 2005 at 01:16:31PM +0100, Frank K?ster wrote: > What do the security people mean with per-user temp directories? It's > clear that $HOME/tmp would be bad, but /tmp/$USERNAME/ with proper > permissions doesn't sound so awkward. Sorry for not being more clear. The default (only?) behavior of libpam_tmpdir is to set $TMP and $TMPDIR to /tmp/user/$UID. noah signature.asc Description: Digital signature
Re: per-user temp directories by default?
On Fri, Nov 04, 2005 at 01:00:48PM +0100, Klaus Ethgen wrote: > That whould be no good idea for security environment where you do > special think to secure /tmp (make it in memory and encrypt swap). With > tempdir in users home all applications like for example gpg write > temporary files to this location which ends up unencrypted on a disk or, > more bad over an unsecure NFS share to the fileserver. > > Please don't do this by default as it break the security of many, many > systems! First of all, libpam_tmpdir doesn't put $TMP in $HOME. Second, we're talking about the *default* configuration. If you're doing something with encrypted swap or $HOME on NFS, you've already diverged quite a bit from the default configuration, so your security would not be broken even if $TMP was in $HOME. You'd simply have one single line to delete from the default pam configuration. noah signature.asc Description: Digital signature
Re: per-user temp directories by default?
On Fri, Nov 04, 2005 at 08:12:39AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote: > > There are a number of outstanding "insecure tempfile vulnerabilities", > > and there has been some talk that they're both too numerous and of low > > enough impact that they're not even worth releasing DSAs for. Never the > > Where was that talk done? I've been the one auditing that and there have been > DSAs for most of the bugs I've reported to the audit team. Granted, they are > not being issued inmediately (I usually provide the report and a patch), but > they are on the queue as far as I know. Yes, your numerous reports are what lead to this discussion, which happened within [EMAIL PROTECTED] Basically somebody was like "whoa, we'll never be able to fix all of these! And why should we, anyway, since the problems are so minor?" So it was proposed to at least provide an additional layer of safety so we can say that this class of bugs generally does not affect our default configuration. > The problem is, there's lots of those. And when I mean lots I mean that I > have a list of ~4780 binary packages of which at least ~2300 make use of > insecure tempfiles for sure and the others need to be reviewed (as the script So can we really be expected to release ~2300 DSAs to fix all these things? Even with patches to fix them, it's going to be an insane amount of work. This is exactly why we want libpam_tmpdir. > IMHO, it's a worthwhile goal for etch but it should be done at the same time > that there is a policy change mandating the use of mktemp/tempfile for shell > scripts, File::Temp in perl scripts, tempnam in Php, tmpfile in C and safe > constructs in those languages that lack a proper implementation (see #291389, > for example). You may be right that a policy change would be required. Packages would need to respect $TMP or $TMPDIR in order for this proposal to work. As has been pointed out earlier (Joey Hess mentioned CUPS breaking), this may result in a number of bugs. noah signature.asc Description: Digital signature
Re: Bits from the Security Team
On Sun, Mar 09, 2008 at 11:05:11PM +0100, Moritz Muehlenhoff wrote: > * You need to be familiar with how the wide variety Debian packages > are maintained, patched and built. If you're not scared by > packages generating their patch series by applying sed statements > from cdbs include files before passing the patches through an > awk filter to quilt until they're finally built with yada, you > might be the right person. OTOH, if you're doing that in one of *your* packages, you're probably not the right person. The security team prefers its members to be sane. ;) noah signature.asc Description: Digital signature
Bug#543956: ITP: choqok -- KDE microblogging client
Package: wnpp Severity: wishlist Owner: Noah Meyerhans * Package name: choqok Version : 0.6.6 Upstream Author : Mehrdad Momeny * URL : http://choqok.gnufolks.org/ * License : GPL Programming Lang: C++ Description : KDE microblogging client Choqok is a fast, efficient and simple to use micro-blogging client for KDE. It curently supports the twitter.com and identi.ca microblogging services. Other notable features include: * Support for user + friends time-lines. * Support for @Reply time-lines. * Support for sending and receiving direct messages. * Twitpic.com integration. * The ability to use multiple accounts simultaneously. * Support for search APIs for all services. * KWallet integration. * Support for automatic shortening urls with more than 30 characters. * Support for configuring status lists appearance. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Linux image packages going to depend on python
On Sun, Nov 29, 2009 at 02:15:41PM -0600, Manoj Srivastava wrote: > Perhaps you should consider making the script just create a > ./fstab.new file, and not overwriting /etc/fstab? makes it easier to > test the script out without altering current setup. Keeping a copy of the original file, maybe in /var/backups, might be helpful as well. noah signature.asc Description: Digital signature
Re: Mozilla renames: is Debian the only one?
On Thu, Apr 12, 2007 at 02:27:51PM -0300, Margarita Manterola wrote: > >> Gentoo has done renames of Mozilla products such as Firefox too. > >I asked one of my local gentoo devs - and he says "no - it is not > >rebranded/renamed" > > It's a USE flag called "mozbranding". It lets the user choose wether > they want to rebrand it (to Bon Echo) or not. NetBSD does something similar in their pkgsrc collection. The default uses Bon Echo, but it can be overridden to use the Mozilla branded names. noah signature.asc Description: Digital signature
Bug#502482: ITP: xplot-xplot.org -- fast tool to graph and visualize lots of data
Package: wnpp Severity: wishlist Owner: Noah Meyerhans <[EMAIL PROTECTED]> * Package name: xplot-xplot.org Version : 0.90.7.1 Upstream Author : Tim Shepard <[EMAIL PROTECTED]> * URL : http://www.xplot.org/ * License : MIT Programming Lang: C, Perl Description : fast tool to graph and visualize lots of data xplot is a fast visualization tool for examining multiple data sets in parallel plots. It supports easy zoom-in and zoom-out capabilities, and synchronized views into multiple data sets (with the -x, -y, and -tile options). The upstream package is named simply "xplot", but this conflicts with a different (incompatible) package already in the archive and is thus being packaged under a different name. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#502482: ITP: xplot-xplot.org -- fast tool to graph and visualize lots of data
On Thu, Oct 16, 2008 at 10:08:49PM +0200, Guus Sliepen wrote: > > Looks like the last release was in 2003, is this still maintained > > upstream? If not, what make it stand out beyond the other plotting apps > > we have already? > > Fast zoom-in, zoom-out and panning on multiple plots on large datasets is > something very little plotting apps do. The only good app that can do that > that I've used is kst. I haven't tried xplot, but if it can do this then it > would stand out (especially since it's a very small tool). The real reason I want to upload this is because it's useful for the tcptrace package, which has finally seen some maintainer attention after a long period of neglect. While tcptrace does include a script for converting its output to a format usable by gnuplot, it was written with the xplot.org tool in mind and works better with it. noah signature.asc Description: Digital signature
Re: Re: I hereby resign as secretary
On Fri, Dec 19, 2008 at 05:04:55PM +, Ian Lynagh wrote: > > project atmosphere. The only way we can "get things back on track" > > and re-focus our energy on the real reason we are all here... to > > create a free operating system... > > I believe that part of the problem is that we are not all here to create > "a free operating system". I have the impression that some developers > merely wish to create "an operating system", or perhaps a > "'free-enough-for-me' operating system". OTOH, it seems to me that there are people with varying degrees of pragmatism. I believe that we are all here to create a free operating system. However, there are those for whom an imperfect release is better than no release at all, while there are others who believe that if the release can't be made 100% free then it is not ready. Personally, I'm quite happy to stand in the former group. While I believe that shipping non-free blobs is distasteful and unfortunate, I believe that our users are better served by timely and functional releases. But then again, I also believe it to be insane that we don't allow ourselves to include, for example, RFCs as a part of our OS. Clearly I'm not a true supporter of free software. noah signature.asc Description: Digital signature
Re: Freedom and pragmatism (was: I hereby resign as secretary)
On Sat, Dec 20, 2008 at 09:02:04AM +1100, Ben Finney wrote: > > OTOH, it seems to me that there are people with varying degrees of > > pragmatism. > > That implies a (lamentably common) false dichotomy. Free software > goals *are* pragmatic goals. They directly affect how we interact with > the digital information that infuses our lives; essential freedom in > that sphere is a highly pragmatic goal. > > There may be reasons that compel us to reduce our freedom, and they > may also be described as ???pragmatic???. But it's wrong to imply that > those who strive for freedom don't do so for very pragmatic reasons. Of course there are pragmatic reasons for developing and evangelizing free software. If there weren't, we really would be just a bunch of fanatics. At the moment, I am most concerned with releasing lenny, and I believe that our users are not well served by continued delays. Looking back at the GR from 2006 regarding sourceless firmware in the kernel, it's clear that most of us want the issue to be resolved. However, it's also clear from the state of things today that there aren't enough people with the required skills and the motivation to resolve it. This appears to be the case both in Debian and upstream. If this was not true, then people would have worked to resolve the firmware issue in the kernel long before it became a release blocker. We can't force the people with the required skills to spend time on something for which they otherwise have no motivation. I suppose, then, that what I'm advocating is yet another compromise. It's difficult to compromise on our ideals, but I believe that continuing to delay releases over this issue is frustrating our developers and users alike. noah signature.asc Description: Digital signature
Re: Modifying debian/changelog entries
On Mon, Jan 19, 2009 at 01:20:17PM +0100, Peter Palfrader wrote: > > * Is it okay to occasionally modify old changelog entries for clarity and > > style, typos and such like, as long as you don't change the semantics? > > The occassional fix for the previous few changelog entries is probably > fine. In fact, I can think of one case where I'd actually encourage it. We occasionally update packages to solve security issues before a CVE number for the particular vulnerability is known. Retroactively modifying the changelog to include the CVE number, once it's known, helps to resolve any doubt about the specifics of the issue. noah signature.asc Description: Digital signature
deprecated server packages in lenny?
The etch release notes documented several major server packages as being deprecated, and stated that they'd be removed for lenny. These include Apache 1, php4, mysql 4, etc. Users were encouraged to migrate to their replacement packages, which were already included in etch. Can anybody suggest a set of packages in a similar state with lenny? This has been submitted as bug #512690 against release-notes. Thanks. noah signature.asc Description: Digital signature
Re: UPG and the default umask
On Tue, May 11, 2010 at 06:09:58PM -0700, Russ Allbery wrote: > UPG without a umask of 002 is pointless. One may as well just put all > users in a users group. Right, our default setup is a strange and basically meaningless blend of two different approaches to user primary groups. One approach would be for users to be in a shared group (typically "users", but a project- or organization-specific group would also be common) and would have a more restrictive default umask (probably 022, or maybe something even more strictive like 077). Users can than share files with other members of their primary group by granting access using chmod. The other approach is to use private groups, like we do in Debian, but with a more permissive default umask (probably 002). Collaboration is then achieved by setting the setgid bit on a directory where the collaborative work is being done. Either of these approaches is OK. User's files are not writable by anybody but that user unless explicit steps are taken. Our default settings, however, break both of these approaches. The first doesn't work because the group permissions are effectively meaningless, since there isn't anybody but the user in the group. The second is broken because the umask is too restrictive, so changing the group ownership of a file doesn't accomplish anything. It would be interesting to see the discussion that lead to our current default setup, if anybody feels like combing the archives... noah signature.asc Description: Digital signature
Re: all twitter client should support OAuth before they will drop Basic Auth in August
On Tue, Jun 29, 2010 at 08:54:55PM +0900, Hideki Yamane wrote: > > Waiting for qoauth [1]. > > Thanks! I haven't heard about it. Choqok author seems to make a fork from > that, see http://momeny.wordpress.com/2010/06/09/kde-oauth/#comment-248 There's no need for a qoauth fork. The change is being merged upstream. qoauth is in NEW as of last night. I'll have new choqok packages by the time it's accepted. noah signature.asc Description: Digital signature
Re: old ITP's
On Mon, Aug 26, 2002 at 08:30:13PM +0200, Bas Zoetekouw wrote: > #89421 tcptrace filed: 531, changed 531 This was mine, and I do still intend to package it. The issue that prevented me from doing so was that it wants to use another software package called xplot, written by Tim Shepard of the MIT Lab for Computer Science (see www.xplot.org). This is not compatible with the xplot package in Debian, and I didn't have time to get things straightened out. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgphRY52sAERA.pgp Description: PGP signature
Re: old ITP's
On Mon, Sep 02, 2002 at 07:06:23PM -0700, Vikram wrote: > > If you are too busy for this I still offer to look into packaging tcptrace > with xplot. If you want to go ahead and package xplot, please do. You'll need to handle the fact that we've already got an xplot package that installs a program called xplot. Consider using the alternatives system for that. You'll need to coordinate with the maintainer of the other xplot package for that to work. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpZrwUcqF3mH.pgp Description: PGP signature
Re: Potato to Woody upgrade problem
On Tue, Sep 25, 2001 at 09:40:58AM -0500, Branden Robinson wrote: > On Tue, Sep 25, 2001 at 09:28:39AM -0400, Dale Scheetz wrote: > > On the installation in question the Xservers file has everything commented > > out. The default-display-manager file contains the line: > > > > /usr/bin/X11/wdm > > > > I put the correct line into the Xservers file and wdm comes up as > > expected! Thanks! (what process should have put this in?) > > High-priority debconf questions from gdm, kdm, wdm, and xdm. One thing, though. After Branden's NMU of wdm 1.20-11.2, /etc/X11/wdm/Xservers has all X server lines commented out. It used to be that the postinst would uncomment one if the user requested it that wdm be used to manage :0. Since the debconf default-display-manager mechanism is now used to determine which display manager runs, shouldn't wdm/Xservers contain a valid server line for :0? noah (wdm maintainer) -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgplKnKWWrFqd.pgp Description: PGP signature
Re: Potato to Woody upgrade problem
On Tue, Sep 25, 2001 at 04:35:51PM +0100, Dave Swegen wrote: > > Since the debconf default-display-manager mechanism is now used to > > determine which display manager runs, shouldn't wdm/Xservers contain a > > valid server line for :0? > > Just uncommented the last line in /etc/X11/wdm/Xservers, and wdm ran > perfectly well. It was the reason why wdm did nothing. So it would seem > that postinst (or something) isn't doing the right thing). Well, it's not quite that. It's that postinst used to do something that would (possibly) result in that line being uncommented. That was how it would resolve conflicts between xdm and wdm. Of course, this also necessitated that postinst edited xdm's Xservers file to comment out its xserver line. That's against policy (one package can't touch another's config files). So now we've got a nice debconf mechanism for choosing the display manager, and all that junk about commenting and uncommenting lines is removed. However, the line in Xservers was commented by default to ensure no breakage. Nothing in the postinst script should touch that file, the file should just contain the right value by default. I will fix that unless Branden can supply me with some reason that it should not be the case. I can't imagine that there'd be one, though. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpAuOCyaPTDE.pgp Description: PGP signature
handling password expiration in display managers
Do any display managers (gdm, kdm, xdm, whatever) currently handle password expiration correctly? Currently wdm does not handle it at all (you simply can't log in), and I want to fix it. What, if anything, is the standard way for doing this? CDE's dtwm is the only display manager I've seen that supports password expiration, which it does by (as far as I can tell) replacing the standard X session with 'xterm -e passwd'. I've not done any programming with the PAM libraries, so I don't know how to catch the expiration message from the pam authentication routines. Any suggestions? Thanks. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpmOdauKrzot.pgp Description: PGP signature
Re: LVM + XFS/Ext3 (Was no space left on device: LVM, Gnus --> dpkg, apt-get ?)
On Tue, Jan 08, 2002 at 09:59:45AM -0800, Karl M. Hegbloom wrote: > > I have not tried yet, but am planning to experiment and see if it is > possible to *shrink* an XFS filesystem. In the case where I have one > LV that's larger than it needed to be, I'd like to be able to shrink > the filesystem then shrink the LV. Anyone know if that is possible? > If it's not, it should be! It is not possible to shrink XFS filesystems. > I am very convinced that XFS is the *best* filesystem for Linux. It > is way better than ext3fs for many reasons. From what I gather, it > is also superiour to IBM's JFS, and certainly superiour to Reiserfs. I felt the same way, up until a couple of months ago. I had been running only XFS on my laptop for a good 6 months or so, when suddenly very weird things started happening. Files and directories would randomly become inaccessable, hanging any command that touched them. My attempts to fix the problems lead to even more frustration. xfs_repair cannot be run unless the filesystem is completely unmounted. This is, shall we say, a major pain when your root fs is XFS. I ended up completely reinstalling, and am currently running only ext2. Not that I think ext2 is a particularly good filesystem, but it's certainly the most mature at this point. > I've had no trouble with it so far. I've been told that it is > incompatible with LILO; that it starts the filesystem at offset 0 > rather than offset 512 like other filesystems? I have not confirmed > this yet. Anyone know? It works great with GRUB. LILO and XFS are fine together. In fact, it wasn't until fairly recently that GRUB could boot from XFS. For the longest time I had to use LILO because GRUB couldn't read my XFS filesystems. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpkdlPSGcd5n.pgp Description: PGP signature
Re: RFC: Packaging buildd
On Sun, Apr 14, 2002 at 08:53:03PM +0100, Roger Leigh wrote: > Does anyone who uses buildd/wanna-build/rbuilder have any comments? I > don't yet have a big enough HDD to run an autobuilder offline, so I > have not tried to use it yet. I won't be able to do much more till > June, but I'll have plenty of time then to fix things. I have set up a few rbuilders for the security team, which involves wanna-build and sbuild. I think that packaging them is definitely possible, though it will be a PITA. A lot of the configurable stuff really doesn't have safe defaults. The postinst would probably end up being very interactive. When I set the software up, I based my work on the .debs generated by the rules script in the CVS tree, so that directory certainly isn't *completely* broken. Since I have several rbuilders left to set up ASAP, I would certainly be willing to help with the effort to create decent packages for it. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpb5jZAzV7gZ.pgp Description: PGP signature
Re: Bug#141748: ITP: openca -- Open Source Certification Authority
On Mon, Apr 08, 2002 at 07:35:07PM +1000, Brian May wrote: > > Oh, sorry, did I say 2 parts? obviously, I still have some learning to > do myself... > Now, I mean no offense by this at all, but shouldn't you leave the packaging duties of this security-critical package to somebody with more in-depth knowledge of how it works? It seems fairly obvious that you have not yet actually used the package at all. Will you be using it once it's packaged? If I'm going to be running OpenCA, I certainly want to know that the packaging is done right. It's not that I don't trust your ability to learn the package, but I think it is unwise for somebody to be responsible for this package when they're not really even clear on the basic functionality of it. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpZAl8QJJrP7.pgp Description: PGP signature
Re: Grid tasks
On Mon, Mar 16, 2009 at 02:28:08PM +0100, Steffen Moeller wrote: > > Would there be support for creating a grid task, and splitting it this way? > > > > Currently the packages are in the new queue. Should I wait until they > > actually reach unstable before creating the task? Are there any other > > obvious candidate packages? > > I don't think that there is such a thing like "the Grid". We should wait a > bit longer to > see how the world evolves around the concepts associated with grids (X.509 > certificates, > virtual organisations, ...). To me, mere computations are what may initially > drive us, but > there should be more to come. I'm not sure about that. There's a whole lot of inertia behind things like the Open Science Grid (http://www.opensciencegrid.org/). My site, with a Debian-based Condor cluster, is considering joining it right now. If we can make it easier for people to build clusters that can easily be added to such a grid, we should. Additionally, I'd argue that "The Grid" could pretty easily refer to a site-local grid. A workstation joined to a local cluster doesn't really need to care about whether it's part of something larger or not. noah (who should probably go sign up for debian-science at this point...) signature.asc Description: Digital signature
seeking co-maintainers for spamassassin
I still make active use of spamassassin, but I don't have the time these days to spend keeping up with bug reports and feature requests. Aside from the backlog, the package is generally in good shape and works well for most users. The upstream development is fairly stable, with the most recent code release happening about a year ago. Upstream rule updates are still fairly common, and although they should probably be pulled in to the package more frequently than they have, I imagine that most users are relying on sa-update to keep up-to-date. Spamassassin is written in perl, with an additional small C program (spamc). The source is maintained in svn and uses quilt for patch management. I'm perfectly happy to see patches attached to some of the open bugs, so please don't hesitate to send them in. Ideally I'd like to get a co-maintainer or two, though. Preferably these would be people who run spamassassin in production somewhere, and who are thus appropriately sensitive to the issues that come with mucking with other peoples' email. Thanks. noah signature.asc Description: Digital signature
Re: seeking co-maintainers for spamassassin
On Tue, Jun 05, 2012 at 10:48:23PM -0700, Noah Meyerhans wrote: > I'm perfectly happy to see patches attached to some of the open bugs, so > please don't hesitate to send them in. Ideally I'd like to get a > co-maintainer or two, though. BTW, this is bug #676317 in wnpp. Please follow up there if you'd like to help. noah signature.asc Description: Digital signature
Re: Ubuntu will switch to systemd
On Fri, Feb 14, 2014 at 07:40:20PM +0100, Daniel Pocock wrote: > > I have to admit that I did *not* expect this. At all. > > > > http://www.markshuttleworth.com/archives/1316 > > > > Quite the opposite - some people felt it would be inevitable that > Debian choosing systemd would effectively be a death sentence for Upstart I'm not sure I understand why. Debian and Ubuntu have been using different init systems for some time now, with Ubuntu on upstart and Debian on sysvinit. Why should our change of defaults really matter to them, when they weren't using our default anyway? Or might they be resigned to the "tight coupling" that Ian Jackson is so worried about? As Debian becomes more tightly bound to systemd, using something else may prove increasingly difficult. noah signature.asc Description: Digital signature
Re: Deprecating/removing racoon/ipsec-tools from Debian GNU/Linux and racoon from Debian/kfreebsd
On Fri, Apr 04, 2014 at 12:59:35PM +1300, Matt Grant wrote: > Systemd package support is the thing that pushed me over the edge about > this. There are no systemd unit files at all for ipsec-tools/racoon > that I know of. Please advise me otherwise, and I will look at putting > them in the current package. I've recently worked out unit files for other packages, and am happy to help come up with a suitable unit file for racoon as well. > The issues are: > > 1) Security. The racoon daemon has to run as root, with a lot of the > default GCC security flags turned off. Running as root without build-time hardening is bad, but... > 4) racoon/setkey are native IPSEC implementations across FreeBSD, > NetBSD, Mac OSX, and Linux, and thus having it available give a 'just > works' IPSEC option. ... > My main concern as maintainer are the security issues, with an old code > base running as root. The code base may be old, but it's pretty widely used and thus should have many eyes watching it. (I'm being optimistic, I know). The ipsec-tools mailing lists don't see a lot of activity, but they're by no means dead. And there was just an upstream 0.8.2 release in February. > I am willing to co-maintain this package with other developers and > maintainers. My belief is that there is likely a Debian kFreeBSD > developer/maintainer out there who would like to do this, and do a lot > of the work :-) I'm happy to help maintain ipsec-tools, as I make regular use of it and have done so for several years. I'd also be supportive of removing it for jessie+1 based on your arguments for doing so. If that's the path taken, it'd be really good if we could document (and at least partially automate?) the migration path from racoon to the preferred alternatives. noah signature.asc Description: Digital signature
Re: Forming racoon/ipsec-tools maintainers group
On Tue, Apr 15, 2014 at 08:52:43PM +1200, Matt Grant wrote: > Just emailing to tell you I have not forgotten this. This Easter I will > have the time to organise this and 'turn the crank handles'. Sounds good, thanks Matt. You might have also noticed that I just pushed a new branch to the ipsec-tools git repo to add a basic systemd unit file for racoon. I won't merge or upload it until the team is established, but I wanted to be sure I got this published before too long. http://anonscm.debian.org/gitweb/?p=collab-maint/ipsec-tools.git;a=shortlog;h=refs/heads/systemd I also hope to begin work on updating the package to 0.8.2 within the next week or so, but haven't done anything yet. http://sourceforge.net/projects/ipsec-tools/files/ipsec-tools/0.8.2/ Thanks noah signature.asc Description: Digital signature
Re: correct use of su
On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote: >What about the task of running a short program for a brief duration, e.g. >from cron scripts? Is using su considered acceptable? >e.g. /etc/cron.daily/spamassassin on wheezy has numerous references to su. There are two reasons I use su in /etc/cron.daily/spamassassin. One is to change uid/gid, and the other is to reset the shell environment to a base state. The need for this was highlighted in bug 738951. I doubt that this is a problem unique to spamassassin. 'su -l' takes care of both uid switching and environment cleansing. start-stop-daemon only helps with the first. The appropriate solution for resetting the environment isn't apparent. Should s-s-d be extended with such functionality? Or is there a more appropriate tool that I'm missing? noah signature.asc Description: Digital signature
Re: Confusing our users - who is supporting LTS?
On Tue, Oct 23, 2018 at 10:05:35PM +0200, Tollef Fog Heen wrote: > > To be clear, the ongoing cost to the cloud team of dealing with jessie > > on AWS (where this issue originally came up) has been exactly zero, > > afaict. That is, we haven't actually updated anything in >18 months. > > Users who launch a jessie image there get 8.7, with 106 pending updates. > > As long as LTS exists and users are happy with it, there's nothing > > strictly wrong with this situation. They should update their instances > > and reboot, but from there, they are free to continue using them in > > relative safety. > > I disagree with the statement that there's nothing wrong with this. Sorry; to be more precise, I meant that there's nothing wrong that can't be remedied using entirely standard and well-established workflows, e.g. dist-upgrade. There's no need to add custom apt sources, apt keys, or anything like that. dist-upgrade is something I'd expect most users to do pretty early in the lifetime of a cloud instance (and possibly regularly after that, depending on how long it's expected to remain active). noah signature.asc Description: PGP signature
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Wed, May 29, 2024 at 06:58:32PM +0200, Andreas Metzler wrote: > >> I think it is bad choice to deliberately have different behavior for > >> freshly installed and upgraded systems. Offering upgrades has always > >> been one of the major selling points of Debian, and imho this > >> implicitely includes that you do not get a worse or second class Debian > >> installation when you upgrade it than if you installed from scratch. > > > I strongly disagree: it is a bad choice to change on upgrades a default > > which may cause data loss. > > That is false dichotomy. data-loss will occur when people use /tmp or > /var/tmp for persistent data-storage because "This has (for a couple of > years) worked on Debian systems" not because "This has (for a couple of > years) worked on *this* *specific* Debian system.". Both perspectives are valid, and that is part of why this change is concerning to me. Transitioning the filesystem configuration of an existing system is inherently dangerous and can lead to data loss, as Marco points out. But leaving a system to diverge from the default Debian base configuration leads to configurtion drift that may trigger obscure bugs, untested configuration, difficult upgrades, etc. I'm not convinced the change is worth the risk. noah
Re: Proposal: plocate as standard for bookworm
On Mon, Feb 08, 2021 at 07:28:56PM +0100, Richard Hartmann wrote: > I very dimly remember updatedb being a concern when cloud images were > first discussed. Back then and today, agreed, it does not make sense > there. Agreed, but we don't install all Priority: standard packages on the cloud images anyway, and I don't see us going out of our way to add it to them even if plocate is promoted to standard. > IMO, it makes sense on both servers and desktops, so rather than > through tasksel, I would think it's a useful default to have on all > non-virtual installations. Personally I'd rather leave it out of the default install, and I really don't like the idea of running it on servers by default. First, the additional IO may impact serving latencies. Second, because servers (except maybe multi-user shell servers, but they're not the general case) are purpose-built systems, and the locate utility really doesn't contribute anything to the system's purpose. noah
Re: ps in cloud images
On Sun, Sep 12, 2021 at 09:33:54PM +0100, mooff wrote: > IMO, many human hours will be lost by the decision not to include procps in > the default cloud images. > > I understand it could be a security measure, but maybe stubs could be > offered which name the package we want (procps) > > Tracing my third call to apt-file search bin/ps ;) What cloud images are you looking at? The images built by the Debian cloud team *do* include procps. See the manifests for (some of) the current bullseye images, all of which indicate that procps is included: https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-ec2-arm64.json https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-generic-amd64.json https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-azure-amd64.json
Re: ps in cloud images
On Mon, Sep 13, 2021 at 08:59:25PM +0100, mooff wrote: > I might have been imprecise in saying 'cloud' images, but I mean: > > $ docker run -it --rm debian:bullseye bash > root@3ee3e7c4ce62:/# ps > bash: ps: command not found > root@3ee3e7c4ce62:/# That is not a cloud image. > > I think that `reportbug cloud.debian.org` would be the > place to discuss > this > > Thanks Paul. I wasn't sure where to send it. Since container images are not published by the cloud team, this would not be the right place to send this. I believe that the people publishing container images want issues raised on GitHub at https://github.com/debuerreotype/docker-debian-artifacts In my opinion, leaving procps out of the base container images is a reasonable decision. They're typically used as the basis for application-specific images, recipes for which typically pull in whatever packages are necessary or helpful for supporting the application's deployment. Populating the base images with packages that aren't strictly necessary is undesirable, and I'd argue that it would be roughly equivalent to Debian packages declaring a Depends relationship on a package that they don't strictly depend on. noah
Re: Bug#995189: RFH: isc-dhcp
On Mon, Sep 27, 2021 at 08:25:14PM +0300, Martin-Éric Racine wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > The ISC DHCP suite has a lenghty list of bug reports that have been left > unattended. Some bugs date back to DHCP 3 or even earlier. > > Additionally, recent upstream releases are still unpackaged. One release came > out well ahead of the Bullseye freeze, a bug report requesting its packaging > was filed, but it remains unanswered. > > Leaving a package with a priority Important in such utter state of neglect is > unacceptable. > > At this point, it has become clear that, at the very least, its maintainers > need help, hence why I filed this WNPP bug. It's worth noting also that ISC's DHCP client, packaged as isc-dhcp-client from the isc-dhcp source package, is considered EOL upstream. As it's still the first recommended DHCP client by ifupdown, and ifupdown is still Priority: important, most systems are likely to be installing isc-dhcp-client. We may want to start a broader conversation about the default DHCP client package in Debian. The maintainers of these packages should obviously be involved. For what it's worth, my preference would be transition to systemd-networkd with bookworm. If we keep the ifup/ifdown commands from ifupdown at all, I think they should be fairly this wrappers around their networkd equivalents. I don't think we should install something like netplan by default. And, of course, environments that currently pull in NetworkManager should continue to do so if it makes sense. Although by default, I believe that NetworkManager uses the ISC dhclient as its DHCP client, so we may want to make changes there. It has a built-in DHCP client, but seems to prefer an external client if one is available. (Of course, this conversation may already be taking place, but if so I've missed it. Please feel free to point me in the right direction.) noah signature.asc Description: PGP signature
Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote: > >> So what's happening with chromium in both sid and stable? I saw on > >> d-release that it was removed from testing (#998676 and #998732), with a > >> discussion about ending security support for it in stable. > > > > The problem really is lack of maintenance. In my opinion, chromium deserves > > an active *team* to support it in Debian. <...> The security team doesn't > > have the bandwidth to do it themselves, they need a team to help them. > > Sorry for a silly question, but whatʼs so wrong with the build done by > linuxmint.com [1], so Debian needs a whole team to duplicate their effort? > Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my > (limited) experience. > Well, you can start with the fact that the Mint chromium source packages don't even include the chromium source, let alone the sources for all the other things they build (NodeJS, and more). The biggest difficulty, as far as I can tell from my look at Chromium from several months ago, is that our patch set [1] needs a lot of attention with every chromium release. Mint doesn't apply any patches at all to the source, at least none of any real complexity. One lesson we may take from Mint, though, is that it's not worth trying to patch Chromium as much as we'd like. Anything that we can do to simplify the Chromium packaging will help us keep the package up-to-date, which in turn will help us keep our users safer. In my opinion, we should be pretty aggressive about dropping as many of the Chromium patches as possible, even if that means we link against bundled/vendored dependencies. Legal/licensing considerations are still important and I don't know if we actually *can* ship builds based on the bundled stuff. But based on the number of patches we have to disable various things [2] or build against system dependencies [3], I can't help but think we'd have an easier time keeping this package fresh if we could drop some of those. noah 1. https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series 2. https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable 3. https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system
Re: Missing CVEs in the json data
On Sun, Dec 19, 2021 at 12:26:12PM +0200, Adi Matalon wrote: >In the json data you are reporting: >[1]https://security-tracker.debian.org/tracker/data/json >There are 28947 CVES, and there are 2800~ which aren't exist in the json: >For example: >For CVE-2021-2014 exists a page: >[2]https://security-tracker.debian.org/tracker/CVE-2021-2014 - with an >informative data >But in the json the CVE doesn't exist. The web site lists (approximately) all CVEs, even those that don't apply to Debian. The JSON feed only lists CVEs that impact Debian in some form. In the case of CVE-2021-2014, Debian does not ship Mysql <= 5.7.32 in any supported release, so it is not included in the JSON file. If anything, maybe the web listing for this CVE could more clearly indicate that Debian isn't impacted. But as it is, the lack of any impacted stable releases on the web view should give a good hint. >Another example is for cve that became reject: >[3]https://security-tracker.debian.org/tracker/CVE-2021-30631 Similar to the previous one, since the CVE is rejected it cannot impact any shipped Debian versions, and thus doesn't appear in the JSON file. >I wanted to know if it is by mistake and if there is a json which includes >all cves. The JSON data for CVEs that actually impact Debian is already 29MB (minified). A full feed would be significantly larger. The downloads at https://cve.mitre.org/data/downloads/index.html might be useful to you. >Furthermore, do you have an api that returns the information in json >format for a specific cve? Not at this time. This may be worth a wishlist bug against security.debian.org. I could see how this could be a useful feature. noah
Re: WNPP/ITP/... for Amazon SDK for C++ ?
On Sun, Dec 26, 2021 at 06:08:56PM -0600, Dirk Eddelbuettel wrote: > I have a package that could take advantage of this if it were packaged, and I > am sure a number of other packages are in a similar situation given how > pervasive AWS use is. So does anybody know where this is at? > > FWIW I have packaged _subsets_ of the C++ SDK informally for my own use (also > at Launchpad) but I don't think I have the time and energy to take this on as > another package. The cloud-team could probably be a reasonable umbrella under which the package could be co-maintained. Would you be interested in co-maintaining it as part of that team? I'm not sure any of us have a lot of expertise or desire to work with C++, but we've got a lot of familiarity with cloud services, etc, and maintain other cloud service SDKs. If you can contribute on the C++ side, we could probably effectively maintain the package together. Of course, if others are already looking into packaging, they should by all means continue, with or without coordinating with the cloud-team. noah
Re: The future of src:ntp
On Mon, Jan 17, 2022 at 05:01:10PM +0100, Bernhard Schmidt wrote: > I could just step down as a maintainer/uploader and have the ntp packaging > bitrot, but this would be a large disservice to our users (unless someone > else continues to maintain it). I think another option would be to migrate > to one of the alternatives for Bookworm. The cloud team has been installing chrony by default in the images we generate since stretch and it's been a good experience for us. I'd be happy to see it become the default distro-wide. noah signature.asc Description: PGP signature
Re: Cloud team plans for cloud-hosted mirrors
On Wed, Jan 26, 2022 at 10:04:47AM +0100, Marc Haber wrote: > >> >The cloud team wants to make folks aware of a possible change to the cloud > >> >images. The team plans to register a new domain, debian.cloud, for > >> >mirrors > >> >inside of cloud provider infrastructure. For such mirrors, sources.list > >> >will > >> >look like: > >> > deb http://.debian.cloud/debian/ bullseye main > >> > >> Are the IP ranges of the Cloud Providers registered that badly that > >> deb.debian.org wouldn't reliably point to the mirrors inside the > >> provider's infrastructure? Or are the cloud providers' mirrors > >> differnet from what we expect from a Debian mirror? > > > >deb.debian.org is served from fastly and AWS CDNs - so it's outside of most > >cloud provider's infrastructure. > > So it is not possible to hook arbitrary mirrors into deb.debian.org > and we're dependent on Fastly and AWS here? > > I thought it was something more flexible. I could be misremembering the conversation, but I believe deb.debian.org is only fastly at the moment. It would be technically possible to direct some clients to other mirrors/CDNs, but the mirror admins are hesitant to introduce that level of complexity at the moment, as it would make troubleshooting significantly more difficult. If fastly becomes unreliable for some reason, then deb.debian.org would be repointed to some other back end. noah
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 09:35:27PM +0100, Marc Haber wrote: > On Wed, 09 Mar 2022 21:34:33 +0100, Pierre-Elliott Bécue > wrote: > >Considering many have replied, I'll stick to that one: > >Marc Haber wrote on 08/03/2022 at > >17:49:04+0100: > >> (3) > >> #625758 > >> --disabled-password just does not set a password for the newly created > >> account (resulting in '*' in shadow) while --disabled-login places a '!' > >> in shadow. On modern systems with PAM, both variants seem to be > >> identical, allowing login via ssh. Aside from the documentation needing > >> change to document reality, should we introduce a --no-set-password > >> option and deprecate the two older options (to be removed in trixie+2)? > > > >How about --disabled-login => shell is set to /usr/sbin/nologin ? > > I have noted that as one of the options for my summary. I assume that > in that case, the password should still be * to avoid creating an > active unlocked account with empty password? +1 to --disabled-login setting the shell to /usr/sbin/nologin with documentation being updated to reflect this. I'd suggest a default behavior of a password of '*', with the ability to override it and prompt for a real password with a "--set-password". Although honestly, I also wouldn't be opposed to requiring an extra step of calling 'usermod' to set a password for a disabled account. It's sort of a special case, and not one that has to be explicitly handled by adduser. noah
Bug#1023369: ITP: s2n-tls -- C99 implementation of the TLS/SSL protocols
Package: wnpp Severity: wishlist Owner: Noah Meyerhans X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: s2n-tls Version : 1.3.26 Upstream Author : Amazon Web Services * URL : https://github.com/aws/s2n-tls * License : Apache 2.0 Programming Lang: C Description : C99 implementation of the TLS/SSL protocols s2n-tls is a C99 implementation of the TLS/SSL protocols that is designed to be simple, small, fast, and with security as a priority. It is released and licensed under the Apache License 2.0. . The s2n-tls I/O APIs are designed to be intuitive to developers familiar with the widely-used POSIX I/O APIs, and s2n-tls supports blocking, non-blocking, and full-duplex I/O. Additionally there are no locks or mutexes within s2n-tls. . s2n-tls implements SSLv3, TLS1.0, TLS1.1, and TLS1.2. For encryption, s2n-tls supports 128-bit and 256-bit AES, in the CBC and GCM modes, ChaCha20, 3DES, and RC4. For forward secrecy, s2n-tls supports both DHE and ECDHE. s2n-tls also supports the Server Name Indicator (SNI), Application-Layer Protocol Negotiation (ALPN) and the Online Certificate Status Protocol (OCSP) TLS extensions. SSLv3, RC4, 3DES and DHE are each disabled by default for security reasons. . As it can be difficult to keep track of which encryption algorithms and protocols are best to use, s2n-tls features a simple API to use the latest "default" set of preferences. If you prefer to remain on a specific version for backwards compatibility, that is also supported. This package will be maintained by the cloud team. Initial packaging is being driven by the awscli package, version 2 of which will depend on this package.
Bug#1023412: ITP: aws-c-common -- C99 package for AWS SDK for C
Package: wnpp Severity: wishlist Owner: Noah Meyerhans X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: aws-c-common Version : 0.8.4 Upstream Author : Amazon Web Services * URL : https://github.com/awslabs/aws-c-common * License : Apache 2.0 Programming Lang: C Description : C99 package for AWS SDK for C Core c99 package for AWS SDK for C. Includes cross-platform primitives, configuration, data structures, and error handling. This package will be maintained by the cloud team. It is initially being packaged as a dependency for awscli v2.
Bug#1023415: ITP: aws-checksums -- fast, cross-platform CRC32c/CRC32 implementations
Package: wnpp Severity: wishlist Owner: Noah Meyerhans X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: aws-checksums Version : 0.1.13 Upstream Author : Amazon Web Services * URL : https://github.com/awslabs/aws-checksums * License : Apache 2.0 Programming Lang: C Description : fast, cross-platform CRC32c/CRC32 implementations Cross-Platform HW accelerated CRC32c and CRC32 with fallback to efficient SW implementations. C interface with language bindings for each of our SDKs This package will be maintained by the cloud team. Packaging is initially being driven by awscli v2 dependencies.
Bug#1025351: ITP: aws-crt-python -- Python 3 bindings for the AWS Common Runtime
Package: wnpp Severity: wishlist Owner: Noah Meyerhans X-Debbugs-Cc: debian-devel@lists.debian.org, debian-cl...@lists.debian.org * Package name: aws-crt-python Version : 0.15.3 Upstream Author : Amazon Web Services * URL : https://github.com/awslabs/aws-crt-python * License : Apache 2.0 Programming Lang: Python and C Description : Python 3 bindings for the AWS Common Runtime aws-crt-python contains python interfaces for common low-level functionality used when interfacing with Amazon Web Services service endpoints. It provides socket handling, the HTTP client implementation, authentication, logging, and error handling. The package is initially being prepared in order to support upgrading the awscli package to version 2.x, which introduces it as a dependency. It will be maintained by the cloud team. In the future, the C components in this package may be split into standalone packages that can be used independently of the python bindings if needed. For now the focus is on python. noah
Bug#1026919: ITP: amazon-ec2-net-utils -- utilities for managing network interfaces in Amazon EC2
Package: wnpp Severity: wishlist Owner: Noah Meyerhans X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: amazon-ec2-net-utils Version : 2.3.0 Upstream Contact: Noah Meyerhans * URL : https://github.com/amazonlinux/amazon-ec2-net-utils * License : Apache 2.0 Programming Lang: Shell Description : utilities for managing network interfaces in Amazon EC2 amazon-ec2-net-utils provides udev integration and helper utilities to manage network configuration in the Amazon EC2 cloud environment. It is responsible for configuring systemd-networkd with appropriate configuration for DHCPv4 and DHCPv6 as appropriate to the network environment in which an EC2 instance is running. It supports policy routing configuration to ensure compliance with Virtual Private Cloud (VPC) network anti-spoofing restrictions. IP aliasing and prefix delegation are also supported. I'm the upstream author and will maintain this package within the Debian cloud team.
setting sysctl net.ipv4.ping_group_range
There are several examples of packages installing files to /usr/lib/sysctl.d, but I haven't found any specific guidance on policies about what's appropriate for them. Since sysctl variables change the system behavior in a way that's not limited to the package changing the setting, and since the package in question (iputils-ping) is Priority: important and part of the default install, I won't want to make any changes without consulting here first. See bug #1008281 for context. [1] The proposal is to install /usr/lib/sysctl.d/iputils-ping.conf with the following content: net.ipv4.ping_group_range="0 2147483647" With that in place, unprivileged users are able to excute ping for both IPv4 and IPv6 targets without cap_net_raw (currently set as either a file-based attribute on the ping binary or acquired via setuid). But since that applies system-wide, not just to the ping binary, there may be objections. After applying this change, I believe it'd be appropriate to drop ping's setcap/setuid settings from postinst altogether, though I'd be open to other options. [2] noah 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008281 2. https://salsa.debian.org/debian/iputils/-/blob/master/debian/iputils-ping.postinst
Re: setting sysctl net.ipv4.ping_group_range
On Mon, Jan 02, 2023 at 10:11:38PM +0100, Marco d'Itri wrote: > On Jan 02, Peter Pentchev wrote: > > > I personally would prefer giving the administrator a way to change that. > > Maybe add a low priority debconf question with a "ping is not setuid" > > default, then mention that debconf setting in a comment in the file that > > the package installs in the sysctl.d/ directory. > Please don't. There are already way too many debconf questions and this > one would be totally pointless: anybody who cares to change the default > can just locally override the /usr/lib/sysctl.d/ file with a drop-in in > /etc/sysctl.d/ . +1. I don't have any desire to add debconf to iputils-ping. I'd suggest the /etc/sysctl.d/ approach for admin overrides as well. noah
Re: setting sysctl net.ipv4.ping_group_range
On Mon, Jan 02, 2023 at 10:09:44PM +0100, Marco d'Itri wrote: > > With that in place, unprivileged users are able to excute ping for both > > IPv4 and IPv6 targets without cap_net_raw (currently set as either a > > file-based attribute on the ping binary or acquired via setuid). But > > since that applies system-wide, not just to the ping binary, there may > > be objections. > I do not think that the submitter made clear why this would be > preferable, so I had to research it myself. See: > > https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange > https://github.com/systemd/systemd/pull/13141 > > Since this is one of the systemd sysctl defaults (of which I think that > we should adopt more, especially the network-related ones!) I agree with > changing this. > I would just do it in the systemd package package to allow all packages > to benefit from it without having to care if ping is installed. I'm entirely happy to reassign this request to systemd and have the setting applied more broadly. The question that arises then is what to do about the file-level capabilities on the ping binary. Ideally we drop them entirely (including the setuid fallback), but when? I could leave things completely decoupled, and simply wait until systemd makes the change and then upload iputils and assume that anybody upgrading iputils is also upgrading systemd. That seems to be what Fedora did, according to the fedoraproject.org wiki cited above. Alternatives would seem to involve some level of versioned dependency, which doesn't feel right. noah
migration from cron.daily to systemd timers
Spamassassin has traditionally supplied a cron.daily script. I'd like to provide the same functionality via a systemd timer, while still providing cron as a fallback. For the most part, this is straightforward, but there are a few details on which I'd like feedback. Current the cron.daily script is a no-op by default, and functionality is enabled by setting CRON=1 in /etc/default/spamassassin. For users running systemd, I'd expect to ship a timer unit that is disabled by default, and have them enable it with: $ systemctl enable spamassassin-daily-maintenance.timer Any issues with that? For upgrades from versions that did not include the timer, should I enable the systemd timer if the user has set CRON=1? Or should I leave the timer disabled and preserve the original behavior via cron.daily? Since the cron script is a conffile, and may have local modifications, I think it should be left in place, but would take confirmation. It'd be possible to perform the migration while still preserving local modifications, e.g. by having the shipped cron script enable the unit file, but IMO that would be gross. If the timer and the cron activity are both enabled, the cron script will be a no-op. This is accomplished with the following in the cron script: if command -v systemctl > /dev/null 2>&1 && systemctl is-enabled spamassassin-daily-maintenance.timer; then exit 0 fi Would you do this a different way? noah
Re: migration from cron.daily to systemd timers
On Tue, Jan 07, 2020 at 05:32:47PM -0600, Richard Laager wrote: > Could you check for local modifications and only enable the timer if > there were NOT local modifications? > > [ -e /etc/default/spamassassin ] && . /etc/default/spamassassin > if [ -d /run/systemd/system ] && [ "$CRON" = "1" ] && >! some_check_for_local_modifications > then > systemctl enable spamassassin-daily-maintenance.timer > fi Since existing cron.daily scripts won't have any knowledge of the timer, one possible transition process could involve having the installed cron script unconditionally enable the timer when it runs. Users who are running with a modified script in place will continue to do so. Users who are running unmodified scripts, or who revert their system to the original script during the package upgrade, will get the new behavior which will perform the transition. > If it was me, I'd just check for whether systemd is running (e.g. [ -d > /run/systemd/system ]), not whether the timer unit is enabled. That way, > at least moving forward, you're only supporting two scenarios (systemd > uses the units, non-systemd uses cron) rather than three (those two plus > the option of systemd systems still using cron). My expectation is that there will be some systemd users who will still prefer cron for some reason. Those users could, obviously, just modify the cron.daily script to remove the systemd conditional, but if we can trivially support them, then I don't mind doing so. On the other hand, transitioning people to the timer wouldn't upset me at all either. > If you were doing this new, I would suggest that you use cron.d instead > of cron.daily. Then check for systemd by prefixing your command with: > [ -d /run/systemd/system ] || ... > This way, if the user installs systemd-cron (which replaces crond and > generates systemd service & timer units from cron files), it will not > generate units for the cron job. See: > https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/systemd-crontab-generator.py#L335 I hadn't considered systemd-cron. Thanks for pointing this out... noah
Re: migration from cron.daily to systemd timers
On Wed, Jan 08, 2020 at 02:43:08AM +0100, Daniel Leidert wrote: > > For upgrades from versions that did not include the timer, should I > > enable the systemd timer if the user has set CRON=1? > > I disagree here. I don't want you to overrule my decision for a cron-script. > If > a user has enabled a cron-job you shouldn't change that to a systemd timer > unit > without the user's explicit approval. I'm not sure that I take CRON=1 as meaning "I want to use cron forever". I'd rather interpret it as "I want to enable spamassassin's daily maintenance job". The details of how it's accomplished aren't really relevant, IMO. > Please ask during installation and give the question an appropriate priority. > By choosing the priority you can even achieve a "silent" transition for > "normal" users and let more advanced users decide. Yeah, that's probably the best way in terms of user flexibility. I'm not convinced it's necessary, though, and I don't like the idea of all the other packages undergoing similar transitions all having to introduce similar debconf questions. noah
Re: migration from cron.daily to systemd timers
On Wed, Jan 08, 2020 at 02:18:34PM +0100, Daniel Leidert wrote: > > Yeah, that's my reaction as well. The point is to run the job > > periodically. > > No. The configuration says CRON=1. It doesn't say PERIODIC_CHECKS=1. Your > behavior here is pretty similar to Microsofts: Let the user decide if updates > shouldn't be automatically installed and still install a bunch of them > automatically without his approval independent of his decision. > > I have enabled a cron-job, not a systemd timer unit. And I don't want you to > silently override this. You haven't enabled a cron job, though. You've edited a file in /etc/default. The variable happens to be named CRON, but that was never a good choice. That name was introduced >15 years ago by a previous package maintainer, and is only there today due to inertia and a lack of real need to move to something else. Had the variable been named PERIODIC_CHECKS or something like that, would your objections still stand? noah
Re: migration from cron.daily to systemd timers
On Wed, Jan 08, 2020 at 11:25:56AM -0800, Russ Allbery wrote: > > As a third party with no particular ax to grind on this, I do wonder > > what the advantage is to adding another mechanism for this particular > > use case, given the need to somehow handle upgrades involving an > > existing (presumably working?) solution. > > Timer units allow the administrator to easily enable and disable them > without mucking around with changing configuration files and then dealing > with merging changes to configuration files. (I just had to deal with > this with a spamassassin upgrade as part of upgrading to the latest > stable.) They also handle suspended systems, time changes, and other > related things better than cron jobs (anacron helps with some of that, of > course). It's also quite a bit easier for an admin to adjust the period of a systemd timer than it is for a cron.daily script. cron.daily scripts are also run serially. The random delayed start feature that the spamassassin job uses to reduce load on the sa-update servers doesn't really play nicely with this, as it ends up delaying the start of subsequent jobs for no good reason. We could avoid this with cron.d, and as has been pointed out elsewhere in this thread, that might be desirable anyway, but that's still a migration that is going to be visible to administrators. IMO the migration to systemd timers can be done more smoothly, so it's still preferable. The big drawback of systemd timers, IMO, is that a nonzero exit code doesn't generate email by default the way cron does. At smaller sites, anyway, this is a perfectly sensible way of being notified of problems with the job. noah
Re: migration from cron.daily to systemd timers
On Wed, Jan 08, 2020 at 10:09:58PM +0100, Stephan Seitz wrote: > > visible to administrators. IMO the migration to systemd timers can be > > done more smoothly, so it's still preferable. > > Well, since you need to support non-systemd systems as well (like mine) the > cron script is still needed (I don’t think these timers work with elogind). > > So the migration can only take place on systems running systemd. That is a given, and has been stated more than once in this thread, from the beginning.
Re: migration from cron.daily to systemd timers
On Wed, Jan 08, 2020 at 10:32:07PM +0100, Philip Hands wrote: > I don't really care what that comment says, as that's up to the > maintainer of the package, and how they intend to deal with this in the > future, but I'm really not a fan adding unnecessary questions to debconf. Here's my proposal for how to perform this conversion: https://salsa.debian.org/noahm/spamassassin/commit/2b2020cbd2e43361d93d8efc1304f5575c0a83e1 If CRON=0, as is the default, then the cron.daily script is a no-op, as today, under systemd or non-systemd. If CRON=1 and non systemd, then the cron.daily script performs the maintenance as today. If systemd and CRON=1 and the systemd time is enabled, then the cron.daily script is a no-op. If systemd and CRON=1 and the timer is disabled, then then: a. If the administrator has created a file named /etc/spamassassin/skip-timer-conversion, then the cron script will perform the daily maintenance tasks. b. If there is no /etc/spamassassin/skip-timer-conversion file, then the cron script will enable the timer, run a single invocation of the maintenance task, and exit. Future invocations of the cron.daily script are no-op, as described above, due to the timer being enabled. I find the /etc/spamassassin/skip-timer-conversion file a little clunky, but I doubt that most people are going to bother with it, and it provides the flexibility to choose not to switch to the timer. noah
Bug#959066: ITP: amazon-ec2-utils -- Utilities to manage Amazon EC2 instance storage
Package: wnpp Severity: wishlist Owner: Noah Meyerhans * Package name: amazon-ec2-utils Version : 1.3 * URL : https://github.com/aws/amazon-ec2-utils * License : MIT Programming Lang: Python Description : Utilities to manage Amazon EC2 instance storage Amazon-ec2-utils contains tools to help manage network attached storage resources on Amazon EC2 virtual machines. This includes: - The ebsnvme-id utility to read and report information about NVME-attached EBS volumes - udev configuration to ensure that NVME storage devices are accessible via names that reflect the Amazon EC2 API drive mapping configuration This package will be maintained by the Debian cloud team.
Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking
On Sun, Jun 28, 2020 at 05:26:41PM +0200, Lucas Nussbaum wrote: > > On https://hub.docker.com/_/debian, there's: > > > > > Where to file issues: > > > https://github.com/debuerreotype/docker-debian-artifacts/issues > > This hasn't changed. The Debian official images still point to github > for bug tracking. I would expect the BTS to be used for bug tracking > (and salsa for maintaining the generation tools) Not wanting to speak for paultag or tianon, but I don't think the intent has ever been to present these as "Debian's official images for Docker." In fact, the language used is "Docker Official Images". These are "Docker's official Debian images". The difference may be subtle, but is significant. > One could argue that the Cloud team delegation does not cover Docker > images. The delegation says: > > > With the Debian Trademark Team, establish policies and procedures > > for the Debian Cloud Team regarding "Official Debian Cloud > > Images" for both open and proprietary platforms. > > The current version of those policies is, AFAIK, > https://wiki.debian.org/Teams/DPL/OfficialImages > > But I think that it would be a nice addition to change the delegation to > also include official images for virtualization environments such as > Docker, LXC, Vagrant, as well as official images for SBC such as the > Raspberry Pi (where it's often more convenient to boot a pre-built image > than use the Debian installer). This proposal increasingly diverges from any common definition of "cloud". noah signature.asc Description: PGP signature
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Fri, Oct 09, 2020 at 12:14:23PM +0200, Stephan Seitz wrote: > > is probably very handy. Even more handy is the fact that you don't > > really need to learn the command name of your image viewer and your pdf > > viewer and your html viewer and you .dia viewer and your .mp3 player > > and every other viewer you might need to handle: only the 'open' > > command. > > I don’t know about that. Normally I use mupdf for pdf, but mupdf doesn’t > allow copy & paste. So if I want to do this, I need another pdf program. > > For my FLAC music I use audacious for my playlists and ogg123 for CLI > playing. > > If I want to open an image, I’m using qiv or gimp. > > Other rules apply for attachments in mutt, so mutt is using its own mailcap > definitions. "open" is a verb commonly used to describe the action of accessing a file in Linux. You used it yourself above, and it's one of the most prominent functions in the file API. It seems sensible to provide a tool that matches the verb most commonly used to describe this action. > That’s why I need to know the different programs anyway. Why would I go for > something like open which can only use one program for the file type? You wouldn't, but that's not the point. The availability of /usr/bin/open wouldn't preclude your use of whatever program you want to use. What it would do is provide a convenient utility to support people who don't (yet) have a preference for what application they want to use to open a file. Maybe they have only basic needs, or are unfamiliar with the file type and its associated commands. There are surely many other reasons. In order to support users who might care about what application they use, or who may wish to explore alternatives, it might be nice if the 'open' command could optionally print a list of programs that support the specified file's MIME type. noah
Re: Bug#972443: ITP: rotp -- Remnants of the Precursors game
On Sun, Oct 18, 2020 at 10:13:06PM +0200, Adam Borowski wrote: > > Remnants of the Precursors is a high-quality remake of the classic Master of > > Orion (1993) game by SimTex. > > Sounds like pure awesomesity! > > > Game engine will go to contrib; while the game data [artwork,text,sound] > > will > > need to go to non-free. > > Except for this bit. So impure awesomesity? ;) Still sounds exciting, in any case. I only wish I had as much time for games today as I did in 1993... noah
Re: unattended-upgrades by default?
On Fri, Nov 04, 2016 at 04:15:58PM +0100, Rhonda D'Vine wrote: > In theory I'm all for it, but there definitely should be some more fine > tuning for that. Please don't auto-restart varnish by needrestart, it > puts a lot of load on the backend which might be a very bad idea. And > the downtime that a mysql upgrade brings along is kinda annoying. > > And: cluster setups might be a real pain here. If you restart the > cluster software at the same time you potentially run into split brain > issues. > > So: BIG yeah for single-user non-critical systems, big nay and > headaches for production nodes. Any reasonably well managed production host is going to be driven by some kind of configuration management system and the admin can override the default. They'll undoubtedly be overriding several defaults already. Overriding the default (or simply purging unattended-upgrades) is a trivial step in such an environment. And if for some reason it's not trivial, then I think this is another case for wanting the service enabled by default. noah signature.asc Description: PGP signature
Re: dpkg no longer installs conffiles??
On Wed, Nov 30, 2016 at 05:13:50AM +0100, Guillem Jover wrote: > > I don't know a suitable forum for this type of question. And please don't > > refer > > me to the high-traffic ML debian-user, I won't use that one. > > You don't need to subscribe to be able to post. Using one of the > support channels before sending to d-devel or filing bugs is always > helpful, because it saves maintainers from having to do the triaging > in case this is a local user problem. But almost everybody sends their replies only to the list. Just like you did. In fact, our mailing list code of conduct[1] explicitly requests that one not CC the original poster unless explicitly requested. I could be wrong, and I don't have any data to back up this claim, but I doubt most people seeking help from the community know about that requirement. Even if they do, I suspect that most of us will, out of habit, ignore their request and send replies only to the mailing list. FWIW, -devel and -user are at about the same volume these days. [2][3] noah [1] https://www.debian.org/MailingLists/#codeofconduct [2] https://lists.debian.org/stats/debian-user.png [3] https://lists.debian.org/stats/debian-devel.png signature.asc Description: PGP signature
Re: Confusing our users - who is supporting LTS?
On Tue, Oct 23, 2018 at 11:03:39AM -0400, Antoine Beaupré wrote: > TL;DR: Why not just delegate image management to the LTS team once > oldstable because LTS just like we do with security? Zobel also provided > a good template for the images life cycle which could clarify this on > debian-cloud@, which I fully support. We could certainly delegate. The goal for the future, though, is to have enough automation in place that continuing to support an old release is simply a matter of not turning off its image generation. For technical reasons, jessie is a bit different, but future releases should be simpler. But the question really isn't "how do we keep publishing and supporting jessie?", it's "should we keep publishing and supporting jessie?" To be clear, the ongoing cost to the cloud team of dealing with jessie on AWS (where this issue originally came up) has been exactly zero, afaict. That is, we haven't actually updated anything in >18 months. Users who launch a jessie image there get 8.7, with 106 pending updates. As long as LTS exists and users are happy with it, there's nothing strictly wrong with this situation. They should update their instances and reboot, but from there, they are free to continue using them in relative safety. > But in the cloud infrastructure, things are slightly different. The base > image isn't as important as the application and/or data that runs on > top. In the cloud, we install new "machines" all the time, sometimes as > part of CI/CD processes and those machines are not "pets", they are > "cattle" and recycled constantly. That's a very common use case, for sure, but not the only one we want to support. We definitely do have people who launch an instance and then keep it around for a long time, interacting with and configuring it by hand, just as they would with any physical server. (In fact, I recently noticed a bunch of what appeared to be jessie EC2 instances owned by our QA team; when I asked about them, I learned that they'd all been upgraded in place to stretch.) > In that sense, switching the base OS is, paradoxically, a big deal so > it actually makes sense to install an older release for newer > machines. This is why Travis CI still supports Ubuntu LTS Precise > (12.04) and Trusty (14.04), the former which isn't supported by > Canonical, and it's missing *two* more recent LTS releases, Xenial > (16.04) and Bionic (18.04). Yes, this is correct; it's also something we can continue to support, even without active engagement from the LTS team. As long as the LTS team doesn't do anything that breaks updates on the old images, we're never going to tell people that they can't launch them. The question here was simply about discoverability. If you're a Debian user just beginning exploration of public cloud alternatives, should we make it easy for you to launch LTS instead of stable? > It seems like a nice, symmetrical approach to solve the problem: just > punt this over to the LTS team. We have some capacity and knowledge. I > know I would be happy to work on those images. I'm not even sure that's necessary. I, as a member of the cloud team and maintainer of the stretch AWS images, have already expressed willingness to update the jessie images, if it's something we as a project agree is appropriate. Coming to some clearer agreement about that, especially in light of a decision to the contrary that we made within the cloud team recently, is the sticky point. The perception, afaict, is that LTS only exists because people are paid to work on it. There has not traditionally been sufficient interest within Debian to sustain support of a release for 5 years, so some companies have provided financial incentives. That's fine, but potential somewhat fragile. If that funding goes away, does LTS go away? Is LTS work, for pay, going to drain resources from volunteer work? These questions exist outside the context of the current cloud team issue. The cloud team just happens to be the one to have tripped over them in this instance. noah signature.asc Description: PGP signature
Re: Alioth: the future of mailing lists
On Tue, Sep 19, 2017 at 09:43:46AM +0200, Marc Haber wrote: > >> I have managed mailman installations for some time so I'm fairly familiar > >> with how it works, and have some time from November onwards to work on > >> this which I hope would be enough time to develop and implement a migration > >> plan. I'm CCing the alioth and DSA teams so they are aware of this. > >Do you have infrastructure for running it? > > How high are the requirements (CPU-, Memory) wise? I guess that one of > those 5 Euros a month VPSses with 50 Gig Disk and 8 GB RAM would not > be enough? We have accounts and are already running systems on the various public clouds (AWS, GCE, etc). Availability of compute resources really shouldn't be an issue for us. I am also willing to help maintain the alioth mailing list service if necessary. Maybe we could create a mailing list to coordinate this effort. ;) noah signature.asc Description: PGP signature
Re: Most optimal way to import NMU into existing git-builpackage repository?
On Fri, Oct 25, 2024 at 03:03:53PM +, Holger Levsen wrote: > > Honestly I'd be happy if we could just establish some expectation that > > the NMUer open a merge request for their changes. It can be merged > > later without losing anything or requiring additional work. Enforcement > > of this expectation would be even better, of course. > > the current expectation is that an NMU bug is opened, which contains > the debdiff. > > https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#when-and-how-to-do-an-nmu > > "... Then, you must send a patch with the differences between the current > package and your proposed NMU to the BTS. The nmudiff script in the > devscripts package might be helpful" Right, and that's not a whole lot more helpful than requiring me to download the sourcepackage and generate the debdiff myself. Sure all the content is there, but it's still a tedious amount of work that's easily forgotten. Further, it loses a little bit of metadata, in that the git commit now comes from me, rather than the person doing the actual NMU. Yes, I know this is trivial, and yes I know I can fix it with more work; I don't want NMUs to make more work for me. It makes me not like NMUs. noah
Re: Most optimal way to import NMU into existing git-builpackage repository?
On Fri, Oct 25, 2024 at 08:45:16AM +0200, Andreas Henriksson wrote: > I would very much prefer if it was possible in Debian to not allow > the archive to get out of sync with packaging git repo (for example > when it lives under salsa.debian.org/debian which uploaders should have > access to already). > That would probably also require some "tag to upload" solution to be > implemented first I presume. Honestly I'd be happy if we could just establish some expectation that the NMUer open a merge request for their changes. It can be merged later without losing anything or requiring additional work. Enforcement of this expectation would be even better, of course. noah
Re: ifupdown behaviour with IPv6 DAD failure (Was: proposal: Hybrid network stack for Trixie)
On Mon, Sep 23, 2024 at 05:48:53PM +0200, Philipp Kern wrote: > > > > I like ifupdown. It's simple and just works. > > > > > > I find this quite funny, given a recent discussion about IPv6 dad > > > issues with ifupdown on #debian-admin. > > > > The "discussion" was about ifup@eth0 being in a failed state on a > > particular server due to a DAD failure and someone having to manually > > intervene. > > I find my ghost being invoked here. > > > Chris, what behaviour do you expect here? Below I'm going to assume what > > you're getting at is that we should continue to retry DAD. > > > > To me going to a stable failure state seems desirable. Continuing to re-try > > for IPs could cause instability in the face of legitimate address > > conflicts: when the owning machine reboots the conflicting machine would > > now win the IP due to continous retrying. The change in owner would cause > > disruption to services entirely unrelated to the machine that was just > > rebooted. > > DAD did not fail, it timed out after 60 sleeps of 0.1, aka 6s. The kernel > subsequently succeeded to configure the network. The script in question was > added in response to [1] and [2] to have a pause during boot to give the > kernel time to resolve the situation before continuing the bootup. So it > left the race around because there's not that much it can do better as a > script-based setup without much state. I'm not familiar with the discussion on #debian-admin, so the details may be different, but I can point to a specific use case where we want DAD/SLAAC failure handled without marking the interface as failed. The cloud team wanted to produce working images that would support both IPv4-only and dualstack environments transparently, without knowing the type of environment in advance or requiring admin intervention. [1] We ended up coming up with something that worked, but it would have been nice if ifupdown could have handled this more gracefully. [2] We have since transitioned to systemd-networkd and netplan; bullseye is the last generation of cloud images to use ifupdown. Although the above issue certainly contributed to this decision, the primary driver for the netplan change was the cloud-init integration. noah 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804396#17 2. https://salsa.debian.org/cloud-team/debian-cloud-images/-/tree/master/config_space/bullseye/files/etc/network
Re: apt running on crashed gnome-terminal
On Sun, Dec 29, 2024 at 07:43:23PM +, Richard Lewis wrote: > > today I decided to upgrade from bookworm to trixie/testing[1][2]. I ran > > the upgrade in a gnome-terminal, and of course all gnome terminals in > > the system crashed halfway through the upgrade[1][3]. > > not much consolation, but: i supose this is why the release-notes > recommend upgrading inside screen (see also: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035401) Yes, but the discussion in #1035401 and the corresponding MR shows that this has limits as well. IMO, an upgrade between releases should happen with as few layers of software involved as possible. Local tty login or serial console is ideal. This is, of course, not always feasible. noah 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035401 2. https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/213
Bug#1090811: debian-installer: install linux-sysctl-defaults by default
On Thu, Dec 19, 2024 at 09:53:27PM +0100, Chris Hofstaedtler wrote: > > > > In theory, if we don't want to explicitly install the package in d-i, > > > > another possibility might be to bump it to Priority: standard and let > > > > tasksel install it. I'm not sure what the tradeoffs might be that would > > > > drive the decision one way or another. > [..] > > > Regarding tasksel vs. Priority, the latter has a potential for a much > > > wider impact: lots of Debian system are installed without d-i and/or > > > tasksel, and most if not all would get the package via Priority. (Think > > > of all the tools building Debian images, chroots, containers, etc., on > > > top of debootstrap/mmdebstrap/etc.) > > > > I'm not sure it's the case that most of those other systems install > > Priority: standard. Debootstrap certainly doesn't by itself, and I > > don't think the debuerreotype tool for building OCI images does either. > > In any case, your point still stands. I'll re-assign this to general > > for now, and we can discuss the options in a broader context. > > We have a mechanism for installing iputils-ping into "most" systems, why > not use the same mechanism to install linux-sysctl-defaults? > > Systems that want iputils-ping likely also want > linux-sysctl-defaults. Both iputils-ping and systemd declare Recommends on linux-sysctl-defaults. The expectation is very much that it's installed everywhere by default. The only reason it isn't today is that those packages are installed by deboostrap, which doesn't install Recommends. I believe that it's important for linux-sysctl-defaults to be part of the default installation except in unusual cases. In addition to the "make ping work" sysctl, it sets a number of other important sysctls that should be set by default (e.g. net.core.default_qdisc, fs.protected_symlinks, net.ipv4.conf.default.rp_filter and others). These are system-wide settings that we don't want changed with the installation of some package after the fact. There are at least a couple of ways we can accomplish this: * Raise the linux-sysctl-defaults priority to 'standard', which will get it installed by tasksel under d-i while still leaving it out of other debootstrapped installations (containers, etc) * Raise its priority to 'important', in which case debootstrap will install it And there are probably more. noah
Bug#1100705: ITP: azure-proxy-agent -- access control for Microsoft Azure link-local network services
Package: wnpp Severity: wishlist Owner: Noah Meyerhans X-Debbugs-Cc: debian-devel@lists.debian.org, debian-cl...@lists.debian.org * Package name: azure-proxy-agent Version : 1.0.25 * URL : https://github.com/Azure/GuestProxyAgent * License : MIT Programming Lang: Rust Description : access control for Microsoft Azure link-local network services The Azure guest proxy agent provides access control to potentially sensitive wireserver and instance metadata link-local HTTP endpoints within the Microsoft Azure cloud environment. This packaged will be maintained by the cloud team.
