Re: Print Alternative
On Mon, Jan 03, 2005 at 01:05:18AM -0200, Fernanda Giroleti Weiden wrote: > So, here goes my suggestion and a request: what do you think of using > the alternatives system for printing? We could do. I'm not sure how it would all work together though, alternatives work fine with binaries but with daemons it gets tricky. > My suggestion to the name of this alternative is "print" which should > point to the command used to print (ex.: /usr/bin/lpr) Most of the packages conflict with each other and supply lpr and other similiar binaries. You probably need to go and check what the configuration thing actually needs. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org
Re: intent to package hamradio stuff
Joop wrote: > I have the intention to package: > > colrconv-0.99.2: curses based convers client > xconvers-0.4: convers client for X and lesstif I was going to do that one, but you can and I'll clean up tnt and dpbox. - Craig -- Craig Small VK2XLZ, PGP: AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90 |@work: [EMAIL PROTECTED],@play: [EMAIL PROTECTED]| |@home: [EMAIL PROTECTED], @debian:[EMAIL PROTECTED]| |@web: http://www.triode.net.au/~csmall @spam:[EMAIL PROTECTED]| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RAMRUN and subdirectories in /var/run (Was: Bug#390687: lprng does not start with new initscripts RAMRUN option)
Hello, I have received a bug report saying that lprng will not start when the initscripts are run with the RAMRUN option. This is because RAMRUN does not make and subdirectories. What is RAMRUN supposed to do? Does it just make an empty tmpfs partition? Is there now a new expectation that all and any packages have to test for directories in /var/run (and /var/lock too I guess) and re-create them if not found? If there was a change, why was it not announced? Why not mention something like this on d-d-a as it is gonig to hit a fair few packages. - Craig (please CC me, thanks) -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Why is procps procps.sh in init.d?
Hello, I've been looking at bug #343620 where /etc/init.d/procps.sh should not exit out. I can see why this could cause problems. However, while I can see that bug #52228 asks for procps to be sourced, I can see no good reason for doing so. Isn't the whole point of the /etc/init.d/.sh files to setup environment variables for subsequent init scripts. The procps init script sets kernel variables, when you remove all the stuff what it basically does is /sbin/sysctl -p Which sets the kernel variables found at /etc/sysctl.conf Is there any good reason keeping it like that, it appears to be it would be best to make it /etc/init.d/procps - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: header sanity check?
On Thu, Jul 06, 2006 at 09:05:28PM -0700, Tyler MacDonald wrote: > So it's really easy to package a -dev package with a header file, that > #include's a header file in a package that it doesn't depend on. Yes it is, it's a compile time problem of someones program. > to catch this or if there are any requirements. pbuilder won't even catch it > if the Build-Depends for the source package contains all the -dev packages > needed. If that particular header file is not used in the compiling then it cannot be caught, as it doesn't result in an error. It is not as easy as it sounds. We have enough trouble with libraries (it's a similiar sort of issue). Consider if you include stdio.h You need to depend on libc6-dev right? Until libc7 comes along, then you're in trouble. Also a lot of headers have things like #ifdef HAVE_FOO_H and only include foo.h if you have it. Lot's of portable autoconf'ed stuff does it like that. Or perhaps parts of the headers only "activate" under certain circumstances. A program that could use mysql or postgresql databases, for example, may need some of their headers if you use that feature. It would be nice to trap all sorts of problems, but I believe this would create more than it would solve. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to Package udmsearch
udmsearch is a website indexer and, I'm going to package it! More info about it at http://mysearch.udm.net/ -- Craig Small VK2XLZ, PGP: AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90 Eye-Net Consulting http://www.eye-net.com.au/ <[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Re: Unofficial projects related with Debian.
Fabio Massimo Di Nitto <[EMAIL PROTECTED]> wrote: > IPv6 is an official subproject founded by Craig Small, even if we host > experimental packages outside Debian for various reasons. I think that might be way, way too formal for what it is. I'm not too fussed what it is called as it was setup pragmatically for a practical purpose. The problem was with IPv6 was there was no coordination. Someone would make a package or have a technique for IPv6 but noone else knew about it so there was duplication and wastage. I thought this was silly, as did a lot of others but I was also a Debian webmaster (though in the end it didn't matter). So I went to the other webmasters and said I want to put up a page about IPv6 in Debian so there was a rallying point or a start where people could lookup the current status. Jay said fine, but you've got webspace as p.d.o/~csmall/ so stick it there because it is just a lot easier but there should be a link to it from the main Debian website and oh by the way there were these other things and they should have a link too so write up a page with all these Debian bits so we don't have to think too hard when the next one comes along. That's how the IPv6 sub-project started. I'm pleased that despite my lack of effort it has done very well. That is due to other people stepping up and doing things, such as Fabbione. Just like TINC, there are no subprojects, they're just a figment of a developer's Debian webspace and a link off the page on the main site. I'm not going to buy into what they *should* be, but a least you know how IPv6 started. - Craig I'm not on debian-devel, so please CC me. -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
procps init.d scripts in rcS.d
Hello, I'm looking at bug #343620 where procps.sh should not exit because it is being sourced by the rc scripts and it exiting kills the calling script. Simple enough so far. What I am unsure about is why procps.sh should be a .sh file anyway. The script sets kernel parameters, I'm pretty sure it doesn't muck around with the environment. I had a look at the bug where I changed it to a .sh file (Bug #52228 ) but there doesn't appear to be a good reason for doing it there. Finally, procps.sh (or procps init script soon possibly) is called at runlevel S with a 30 prefix, which means it is before the network is enabled. I've people at times mention it should be moved, others not. NOW is the time to mention it, either way. My preference is to leave it where it is, but if there is a really good reason why it should be moved then let's hear it. My reasons for leaving where it is are: * It doesn't change any behaviour * Setting up all the funky networking parameters should be done before you up your interfaces. Please CC me. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497476: ITP: gw6c -- Client to connect to IPv6 tunnel brokers
Package: wnpp Severity: wishlist Owner: Craig Small <[EMAIL PROTECTED]> * Package name: gw6c Version : 5.1 Upstream Author : Hexaco * URL : http://go6.net/4105/download.asp * License : BSD Programming Lang: C Description : Client to connect to IPv6 tunnel brokers TSP is a control protocol used to establish and maintain static tunnels. The Gateway6 client (gw6c) is used on the host computer to connect to a tunnel broker using the TSP protocol and to get the information for its tunnel. When it receives the information for the tunnel, the Gateway6 client creates the static tunnel on its operating system. Hexaco have "helpfully" mixed their daemon code with their GUI code which has some ugly license and is completely useless for non-windows systems anyway. The source package will be fixed so it only has the BSD licensed daemon code. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Run "guest CPUs" under Linux? I need your help
Hello, I'm the Debian maintainer for procps, which is the package that gives you things like ps,killall and top. The latest version of procps now handles all 7 cpu numbers, so all is well? Actually no, since kernel 2.6.24 there is a 9th CPU field! It's called a guest field and is the amount of time the CPU spends running a virtual CPU. My problem is, its not defined too well. I get 0 all the time as I run a standard Linux installation. What am I looking for? * Someone who knows that this field means, or * Someone who can spend some time with me checking some things and has something in that field. Look for the 9th number in your cpu lines in /proc/stat $ grep cpu /proc/stat cpu 10056425 163340 3340784 167972553 1183037 103876 31053 0 0 cpu0 10056425 163340 3340784 167972553 1183037 103876 31053 0 0 That second 0 right at the end is my "guest cpu" time. If you don't have 0 and got some time, can you reply back? I'll probably just need some greps of a few lines in /proc Ideally you have a rather large number there, or at least something that is in the same order as the others. This work will then mean the tools will get updated so they properly reflect that time. I suppose if you have 0 there then you don't have to care, because its not going to change your results. The biggest question is, is that number part of the 100% of the CPU time or is it a susbset of say, system time. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435969: ITP: pidgin-musictracker -- Plugin for Pidgin which displays the current music track in your st
Package: wnpp Severity: wishlist Owner: Craig Small <[EMAIL PROTECTED]> * Package name: pidgin-musictracker Version : 0.4.1 Upstream Author : Arijit De <[EMAIL PROTECTED]> * URL : http://code.google.com/p/musictracker/ * License : GPL Programming Lang: C Description : Plugin for Pidgin which displays the current music track in your status MusicTracker is a plugin for Pidgin (previously known as Gaim) which displays the music track currently playing in the status message of various accounts such as AIM, Yahoo, MSN, Gtalk (Jabber), etc., i.e. any protocol Pidgin supports custom statuses on. Features * Currently supported players: Amarok, Rhythmbox, Audacious, XMMS, * MPC/MPD, Exaile, Banshee, Quod Libet on Linux. * Allows you to customize the status string with various fields * extracted from your media player such as artist, album, track, duration, progress bar, etc. * Works around Pidgin's lack of support for MSN status messages by * using the nickname instead. * Different status messages for various media player states such as Playing, Paused and Stopped. * Supports per-account status format customization. * Optional Profanity filter for words in the status. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-k7 (SMP w/1 CPU core) Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#565578: ITP: gjay -- An automatic and learning DJ for Audacious
Package: wnpp Severity: wishlist Owner: Craig Small * Package name: gjay Version : 0.3.0 Upstream Author : Craig Small * URL : http://gjay.sourceforge.net/ * License : GPL Programming Lang: C Description : An automatic and learning DJ for Audacious This was in Debian a while ago but madduck canned it because (I believe) upstream wasn't going to work on it. I've now adopted and developed the project on sourceforge and will be packaging it soon. It now works on 64-bit arches and with audacious. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
TCP SYN cookies and Bug #520668
Hello, There has been a bug opened for a while to enable TCP SYN cookies by default. The current situation is /etc/sysctl.conf has this option, but it is commented out. The procps (sysctl.conf) bug is http://bugs.debian.org/520668 you may also like to read the discussion about tcp(7) man page at http://bugs.debian.org/253588 which discusses the mechanism too. The general argument seems to be that: - SYN cookies, when activated, break certain options like large windows within TCP The counter-argument is that: - Under the circumstances you have cookies activated your backlog is full so you lose the TCP session anyhow. While initially skeptical, I can see that under high TCP loads having some sort of connection is better than having no connection. Connections with large windows will be dropped, but they would be anyhow. My proposal is to change sysctl.conf so by default it will have TCP SYN cookies ENABLED. Anyone is quite able to change this but the default is proposed to be enabled. Before I make this change, I am emailling debian-devel for comments. I am looking in particular for information about why it could be harmful (if it is). Please CC the BTS so I've got some tracking of it, thankyou! - Craig Further references: http://cr.yp.to/syncookies.html http://lwn.net/Articles/277146/ http://en.wikipedia.org/wiki/SYN_cookies -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#520668: TCP SYN cookies
Hello, Regarding the procps bug 520668 which was asking for the TCP SYN cookies to be enabled by default, I've looked at the various emails to and for. While it does seem like it would be a good idea at times, there is not a consensus that it is a good *default* Nothing about this bug would change peoples ability to edit sysctl.conf for their own setup. Some important points brought up, paraphrased: * I disagree generally that if the default is 'off' then the best solution is always 'off'. Often new features are off by default, because they are new. * SYN cookies disable features, under attack this probably doesn't matter but under non-attack high loads it does [1] * SYN cookies solve one part of the overload problem, but are still put on the overloaded queue [2] - I actually see this as a good thing, at least you know the new connections are verified Significantly, from this bug's point of view, from Julien Cristau [3]: > I believe procps is the wrong place to make this change. If we decide > that syncookies should be enabled, then that should be done in the > linux-2.6 package, IMO I happen to agree and in future I'll treat further sysctl key options like this: * Generally a bad idea or only for very specific circumstances - close * Something useful for some subset of Debian machines - commented out in sysctl.conf * Something everyone should have - reassign to the kernel The TCP syn cookies is alreeady a commented out line in sysctl.conf Should it be the default for everyone? Then if so the kernel folk can decide, I'm re-assigning it to the kernel package. - Craig [1] http://lists.debian.org/debian-devel/2010/02/msg00296.html [2] http://lists.debian.org/debian-devel/2010/02/msg00314.html [3] http://lists.debian.org/debian-devel/2010/02/msg00278.html -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free signature.asc Description: Digital signature
Re: When and how can we migrate out of CVS and WML ? (Re: How to make Debian more attractive for users)
On Thu, Jul 29, 2010 at 08:19:47PM +0200, Gerfried Fuchs wrote: > Hi! > > * Charles Plessy [2010-07-29 16:53:18 CEST]: > > Le Thu, Jul 29, 2010 at 12:32:54PM +0300, Teemu Likonen a écrit : > > > * 2010-07-23 00:27 (+0900), Charles Plessy wrote: > > > > in my opinion, it is not only a question of design, but of > > > > infrastructure. For me, the combination of CVS and WML finally eroded > > > > all my motivation over the years for keeping some life in the pages > > > > under /devel/debian-med. I would welcome any change of VCS and > > > > language, even if it means losing the history or rewriting the pages > > > > from scratch. > > Rewriting everything from scratch would include losing translation > effort which is very huge. I actually don't welcome changes that tell > our translators technicly: "Thanks for your effort so far, but we throw > it all away." > > About change of VCS - there are (minor) efforts going on with respect > to try out wether git would work as backend. Any help is of course > appreciated, in any direction. I would welcome any change too, but to > some degree that sentence has the sounding of "if someone else does it" > added to it. I don't really mind switching from CVS to git, or remaining on CVS for that matter. I prefer git but it really is not that big an issue. > As about moving away from WML: I am open for something that offers us > also the needed flexibility for pulling in automated information and > doesn't put too much burden onto our translators. WML is the only one where I've seen those language slices. It seems to do its job rather well though I am aware of kludges within the website backend to do its stuff at times. The problem with replacing WML is; what do you replace it with? and will it bring any real benefit? Admitedly for my own pages I've moved away from wml in places but that's because I'm using smarty AND I'm using that for different reasons to what the website needs. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100730055013.gb8...@enc.com.au
Bug#610175: ITP: mudlet -- Graphical MUD client with fast lua scripting support
Package: wnpp Severity: wishlist Owner: Craig Small * Package name: mudlet Version : 1.1.1 Upstream Author : Heiko Koehn,Bruno Bigras,Vadim Peretokin and others * URL : http://www.mudlet.org/ * License : GPL Programming Lang: C++ Description : Graphical MUD client with fast lua scripting support A completely redesigned MUD (Multi User Dungeon) client that is easy to use and customise. Both power users and plain gamers alike will feel at home with Mudlet, without having to waste too much timer figuring out how to do something. Mudlet is designed to be very fast and efficient right from the start. It's scripting engine is designed to handle thousands of lines under one second. The scripting framework uses Lua - a small, fast and efficient scripting language. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110115210058.20854.12148.report...@elmo.enc.com.au
Re: Are we losing users to Gentoo?
Gee, it's a pretty bad topic, but anyway... On Fri, Nov 29, 2002 at 03:58:51PM -0500, Joey Hess wrote: > There's a straight 2 click path to a directory with an ISO image on it > on the gentoo site. For freebsd, it's 3 obvious clicks to a ftp site > directory, then click on arch and version. For netbsd, 5 clicks to a > mirror (one hidden far down a page). For debian, it's 4 clicks, _if_ you > avoid the unofficial images, and the false path that leads only to them. > And _if_ you happen to pick one of the small fraction of listed mirrors > that really work. > > So no, in this case our web site is behind all but netbsd in structure, > and behind netbsd in the sory state of our cdrom mirror network. Finding ISOs is possible but a pain in the arse and it should be a lot simpler. jigdo is ok but quite often you just want the damn ISO image and be done with it. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Re: The Debian Mentors Project
On Mon, May 12, 2003 at 09:33:50PM -0700, tony mancill wrote: > Appropos of this and Colin's statement, my suggestion is to make only a > deb-src URL available on the site, and to only host source packages. For > packages destined for the Debian archive, it's critical that they be > reviewed as source, and that they build from source. I do a fair amount > of sponsoring, and never have need for a binary of the package being > sponsored. As a long-time sponsor of a few people and packages (but nothing like the tmancill sponsor/advocate machine) I'd have to agree with Tony. I only use the tar.gz, diff and dsc from my sponsors. So the deb-src is a good idea. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Bug#194155: ITP: ehnt -- Extreme Happy Netflow Tool - Obtains useful information out of netflow data
Package: wnpp Version: unavailable; reported 2003-05-21 Severity: wishlist * Package name: ehnt Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.some.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : Extreme Happy Netflow Tool - Obtains useful information out of netflow data (Include the long description here.) The purpose of this software is to get some useful information from netflow without too much trouble. The flow reports come out in text and show flow summaries (such as top n ASes, protocols, etc per m minutes). NetFlow is a packet protocol that is used by routers such as Cisco and Juniper. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux gonzo 2.4.20-xfs #1 Sat Mar 22 00:02:16 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: Bug#110875: sysctl should disable ECN by default
On Sat, Sep 01, 2001 at 04:04:12PM +0200, Eduard Bloch wrote: > I suggest to disable ECN? in the default network configuration. > This should be done in Woody since we don't like our users to be > confused just because of the ECN support in kernel is turned on. This would be an abuse of the procps package and would only work on systems that are installing procps for the first time, which is a very small minority of machines. If ECN causes so much problems, then dont enable it in the default kernel. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Assistance required for procps bug
Hello, I have bug #142292, #109237 and #106414 for procps. The common thing is that if System.map file is a multiple of 1024 (or 4096 not sure which) ps crashes. Thanks to Dark for getting me that far. Can someone look at 106414 and Dark's analysis and help me out here? I'm not subscribed to debian-devel so contact me direct. thanks! -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (Possible) bug in fglrx dependencies in Sid(Unstable)
On Sat, Aug 09, 2014 at 04:02:45PM +0200, Cyril Brulebois wrote: > Well that's: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754249 Ah that explains why it tries to get removed. > Instead of trying to mix things up, you probably should be using the > free driver. Until the proprietary one gets fixed, or forever. :) I'd avoid fglrx if I could. It crashes lots of things now because the libclutter problem. The problem is, that a lot of chipsets just don't work with the free one. The whole muxless video switching thing. > (BTW dd@ isn't the right place to get user support or to report bugs.) I'll shush now too. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811130040.gc13...@enc.com.au
Re: Improving our response to "duplicate" packages in Debian
On Sat, Jun 30, 2012 at 08:41:07AM +0200, Michael Hanke wrote: > On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote: > > We really need to find better ways to involve new users in core teams, > > and that means removing from our collective consciousness the idea that > > you come in Debian to package your new favorite piece of software. > > I have to disagree -- and I would even make the bold claim that > "packaging your favorite piece of software" is a very common (if not the > most common) entry point for _people_ into Debian. One could see the I'd go even further and say that the reason why people start on something generally in Free Software projects is to "scratch their itch" which in Debian could well mean packaing your favourite piece of software. I'd be surprised if many newly-minted Debian maintainers would want to tackle a core project from day one. There is a lot to learn and just get used to and I'd also rather that people working on the core stuff have some idea, as well as some history of doing the right thing. So if we went down that way we've removed one very big incentive "your fav project is packaged" and created a disincentive "work on highly visible project X with all its complicated history". > "pet projects" as the price we need to pay to make participation in > Debian very attractive (not even talking about the role that "pet That's a good way of putting it. Also who can predict what is really a pet project. I bet the first medical related project that was ITP'ed on Debian people were thinking 'huh, why that here?' and yet I hear now there is quite a large and vibrant community around this sort of thing. Some sort of cull for dead projects is definitely a good idea! -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120630223401.gd7...@enc.com.au
Re: Package changelog should contain, well, a log of changes
On Sat, Jul 14, 2012 at 12:24:44AM +0200, Jonas Smedegaard wrote: > On 12-07-13 at 08:39pm, Cyril Brulebois wrote: > > Jonas Smedegaard (13/07/2012): > > > Please proofread your changelog before releasing a packaging, and make > > > sure all entries describe what was _changed_. ^ > > > > SNCR, > > KiBi. > > I fail to extract any meaning out of the above. > Could you please elaborate? It should of been package not packaging. I got that bit. Still, I'm not sure what "Stevie Nicks Concert Reviews" or the "Society for New Communications Research" has got to do with it. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120713224622.ga25...@enc.com.au
Re: Multilicense `debian/copyright` file
On Sat, Jul 14, 2012 at 01:09:21AM -0400, Aliaksei Sheshka wrote: >Hi debian-devel list! >Please help me to write a proper `debian/copyright` file. >Original COPYING file says: >Several parties hold copyright to various parts of IRRToolSet. One or >more >of the following licenses may apply to the code contained within this >distribution. >1. USC (and occasionally USC/IBM) license >. >2. RIPE NCC license > >3. GNU General Public License version 2 >... >What should put in the `debian/copyright` then ? You got to love old software with its horribly confusing and mishmash of licenses! The USC license is an expat style license. The RIPE NCC one is a mit style one so they should be compatible with GPL v2. Oh by the way they are wrong about GPL in their COPYING file. Have a look at src/dataset/unsigned.Set.cc: software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. I have no idea why they have parts of the C library in the source code. Anyhow, you probably need to collect all the license types and authors and group them somehow. Good luck, it looks a little messy in there! - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120714062521.ga2...@enc.com.au
Re: nacl and CPU frequency.
On Sat, Sep 22, 2012 at 05:29:45PM +0100, peter green wrote: > I therefore conclude that if it's not returning elapsed times in true CPU > cycles it probablly doesn't matter much if the supposed CPU speed and the > real CPU speed are not exactly the same. > > As such unless someone objects I plan to patch the code to fallback to > using bogomips as a "psuedo CPU speed" if true CPU speed cannot be > determined. procps has been struggling with this for years, though ita mainly around the CPU ticks versus real seconds. If you are really bored, have a look at some old procps bugs where this sort of thing has broken. We've narrowed it down to a small handful of checks. The real value is probably unknown for some devices so we just set it to a fixed value. The point is, trying to guess this sort of stuff will probably give you the wrong number so a "pseduo CPU speed" is probably as bad as anything else you can come up with, so find something simple. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120923225625.ga17...@enc.com.au
Re: Plan to release a gplv3 compliant debian-based release
On Wed, Jul 03, 2013 at 01:16:04AM +0200, Marco d'Itri wrote: > On Jul 02, Ben Hutchings wrote: > > > You're slipping. Your trolling used to be way more subtle. > I do not think that Svante has ever been trolling. My initial thought was WTF but Ben's email seem to make it all clear. Are you saying the initial email was serious, really? It's a completely bad idea. BSD is fine, but GPL2 is not? - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130703014218.gf7...@enc.com.au
pidof changing from sysvinit-devel to procps
Besides my Debian duties I am also upstream for procps. I have been in discussion with the sysvinit-tools upstream and they want to find a new home for pidof so it "fits" with similiar tools (pidof used to be in procps in the dark ages). This means shortly that pidof will disappear from sysvinit-tools and appear in procps. If your package uses pidof, we need to talk about it NOW so that this change doesn't put you in the lurch. I believe merely depending on procps will do what is needed, with the right version. If your package uses, or you have a strong case for, non-LSB pidof flags then it is essential you speak up. The command line options that may be going are -c -n -m This is not strictly a Debian thing so you can always speak up about the options at [1]. For most people (hopefully) this change should be invisible; but for the minority that it's important, now is the time. - Craig [1] http://www.freelists.org/archive/procps -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130809111050.ga6...@enc.com.au
Re: pidof changing from sysvinit-devel to procps
On Fri, Aug 09, 2013 at 04:46:26PM +0400, Игорь Пашев wrote: > Since we are talking about pidof, I'd like to note that pgrep is more > portable ;-) They'll actually share some of the same codebase after this change. pidof is bascially a cut-down pgrep. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130811001411.gb22...@enc.com.au
Re: pidof changing from sysvinit-devel to procps
On Fri, Aug 09, 2013 at 03:14:14PM +0200, Ondřej Surý wrote: >And is there a strong reason why we don't move whole procps into >essential?A It used to be there and then it was decided it wasn't essential. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130811001451.gc22...@enc.com.au
Re: pidof changing from sysvinit-devel to procps
On Fri, Aug 09, 2013 at 01:39:20PM +0200, Ben Hutchings wrote: > I don't think this is a sensible thing to ask. There may be lots of > scripts using pidof that their maintainers don't know about. I suggest > using codesearch.debian.net to find the packages. For the three flags that might go, the results are: -c: corosync, glusterfs and sheepdog -n: no packages -m: not available on Debian pidof > I also wonder whether it would not be more sensible to split procps into > essential and non-essential binary packages. Aside from pidof, I bet > there are lots of scripts using pkill, pgrep, /bin/kill and ps without > the necessary dependency now. (I saw one using ps just the other day: > #719126.) I happen to think this is probably the best way. There are lots of things using pidof and ps in scripts, usually init scripts. (As an aside, this is probably wrong; there is a lsb function for this sort of thing; also kill `pidof blah` is not nice either). It would come down to what is left over and is it worth putting it into another package. lsb-base uses pidof and libc6 preinst amongst other things also calls it. For reference, procps lost it's Essential flag in early 1998, though I cannot locate the bug report on it. Other than my email about it[1] I don't see any other discussion. - Craig [1] http://lists.debian.org/debian-devel/1998/02/msg01095.html -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130811012846.ga20...@enc.com.au
Re: iproute transitional package going away...
On Wed, Sep 25, 2013 at 05:02:58PM +0200, Andreas Henriksson wrote: > Craig Small >gogoc Thanks for the note. gogoc 2.1-5 now uses iproute2. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130930003726.gf32...@enc.com.au
Re: pidof changing from sysvinit-devel to procps
On Sun, Aug 11, 2013 at 11:28:47AM +1000, Craig Small wrote: > On Fri, Aug 09, 2013 at 01:39:20PM +0200, Ben Hutchings wrote: > > I also wonder whether it would not be more sensible to split procps into > > essential and non-essential binary packages. Aside from pidof, I bet > > there are lots of scripts using pkill, pgrep, /bin/kill and ps without > > the necessary dependency now. (I saw one using ps just the other day: > > #719126.) > I happen to think this is probably the best way. There are lots of things > using pidof and ps in scripts, usually init scripts. (As an aside, this is > probably wrong; there is a lsb function for this sort of thing; also > kill `pidof blah` is not nice either). It would come down to what > is left over and is it worth putting it into another package. We're getting close to releasing procps upstream which will have the pidof in it. So its also getting time to work out what to do. I think I will need to split procps into two binary packages. The first will have pidof and possibly some other binaries such as ps and would need to be promoted to Essential The key thing between the two binary packages is to not pull in libncurses5w which isn't used by any Essential package currently. However libprocps would need to be installed as its a dependency on almost all the binaries. my first cut of it would be: procps-base: pidof, ps, sysctl, pgrep, pkill procps: pwdx, vmstat, tload, free, pmap, skill, slabtop, top, uptime, watch, w, snice procps-base is Essential and depends on libc6, libncurses, libprocps, libtinfo5, lsb-base, initscripts It will also Replaces and Breaks sysvinit-utils (<< some version number) as that is where pidof comes from. procps is not Essential and depends on libncurses5w as well as the above set. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131011230133.ga17...@enc.com.au
Re: .py suffixed scripts to /usr/bin/
On Thu, Oct 31, 2013 at 04:36:35PM -0400, Yaroslav Halchenko wrote: > the hurdle again is that those then would/could conflict with the names > of the now non-free MNE toolkit, which ships files with the same names. > This Python toolkit pretty much tries to mimic and interface in few > spots the original non-free MNE toolkit, thus they chose to have the Hard for the upstream, but to me the best solution for the Debian packages would either for them to conflict with each other or use the alternatives system. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131031211955.gb32...@enc.com.au
Re: [PATCH] netplug - Allow to specify custom script file via param '-s'
On Thu, Nov 07, 2013 at 05:20:08PM +0100, Pali Rohár wrote: > Again, after month I have not got any responce. > CCing everybody from this thread. What to do? I'd say you got an "email problem". If I were the recpient of this email I wouldn't know what you were asking. I get lots of emails and look after many packages. I assume you want a reply from these people. A simple "To recap, package X needs package Y to do Z, further details are at W" will mean more chance of a reply. The email as currently sent is a bit context-free to me. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131107212342.gd19...@enc.com.au
Re: Popularity of bzr-builddeb and dh-make
On Thu, Oct 11, 2012 at 02:38:46PM -0700, Steve Langasek wrote: > dh-make isn't so relevant now that debhelper 7 exists. cp > /usr/share/doc/debhelper/examples/rules.tiny debian/rules && dch > --create, manually create debian/control and debian/copyright, and that's > about it. dh-make comes from the era when deb-make (anyone remember that) was around which, I think, was before debhelper was around. It was basically written to fix a "problem" which was bad templates getting into the Debian archive. debhelper has gotten smarter with every release and gradually what dh-make has had to do is getting reduced. I'm not sure we're at the point of removing dh-make (it's an open question; I'm really not sure) but perhaps we will be there one day. As it was written to solve a problem, if the problem goes then we won't need it. Steve with his years of packaging experience is not probably a good sample of one to base this upon. I'd be curious to see if newer packagers use it or not. As far as what packaging-dev recommends or suggests, I've never used it so don't really care either way. I am curious why a specific tool is recommended over a generic one (I don't use bzr anywhere so it would be useless for me). - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121012050353.ga26...@enc.com.au
Re: No native packages?
On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote: > I am guilty myself of maintaining a native package (and another one > is waiting in NEW). However, I will be happy to switch to a > non-native format once I figure out a releasing work-flow that is > convenient for me. Changing from native packages to non-native sounds like increasing my work-load for absolutely no gain to Debian (or myself). Harder to merge downstream changes? How? We know how to merge patches don't we? I do double-releases for other stuff; its a pain but for those cases essential. I don't recommend it if you don't need to. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130128214934.ga14...@enc.com.au
Re: No native packages?
On Mon, Jan 28, 2013 at 11:59:56PM +0100, Benjamin Drung wrote: > Other distributions gain from your extra work. Image the opposite. You > want to package a software that is only available in a downstream > distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a > non-native format or a native format? If I want it enough I'm not going to care. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130129002044.ga25...@enc.com.au
Re: Git packaging workflow discussion on planet.d.o
On Thu, Apr 04, 2013 at 02:25:30PM +, Jeremy Stanley wrote: > makes a lot of sense. If your packaging workflow does not rely on > importing the contents of release tarballs, then for projects like > this you miss some content unless you re-run the same release > scripts post-facto. That was the part I didn't understand. What are people doing to solve this generated files at release problem? I've solved this as upstream and a Debian developer by having tarballs. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130409231104.gb16...@enc.com.au
Re: Bug#707601: ITP: debmake -- helper script to make the Debian source package
On Mon, May 13, 2013 at 12:36:39AM -0500, Steve Langasek wrote: > This sounds almost exactly like what dh-make already does, with a few > incremental enhancements. Why should we have this in the archive as a > separate package, instead of improving the existing tool? Dividing efforts > between two packages seems like a sure recipe for both tools falling behind > in the long term. I wondered that myself actually. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130513105451.gb16...@enc.com.au
Re: How many users for /usr/bin/view ?
On Wed, Nov 27, 2013 at 03:54:23PM -0800, Russ Allbery wrote: > Perhaps this is just because I'm an old UNIX person, but I would expect > the view command to launch vi in read-only mode. So I'm in favor of > dropping linking it to see. Oh good, I'm not the only one. /etc/alternatives/view -> /usr/bin/vim.gnome I get annoyed when it does that other mime-y thing so I'm all for it going. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131128005433.ga18...@enc.com.au
Re: pidof changing from sysvinit-devel to procps
On Sat, Oct 12, 2013 at 10:01:33AM +1100, Craig Small wrote: > my first cut of it would be: > procps-base: pidof, ps, sysctl, pgrep, pkill > procps: pwdx, vmstat, tload, free, pmap, skill, slabtop, top, uptime, > watch, w, snice > > procps-base is Essential and depends on libc6, libncurses, libprocps, > libtinfo5, lsb-base, initscripts > It will also Replaces and Breaks sysvinit-utils (<< some version number) > as that is where pidof comes from. pidof is now in the just released procps upstream which means these changes will occur very soon. I'll work with the sysvinit-utils people on getting the right version. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131207223442.ga24...@enc.com.au
dpkg with new Essential (Was: pidof changing from sysvinit-devel to procps)
As pidof is moving from sysvinit-utils to procps-base in the next release, I want to check I've got the way dpkg handles flags correctly. procps-base will contain the new pidof and will be Essential: yes Breaks: sysvinit-utils << 2.88dsf-43 Now, if there is a new Essential package, is that automatically installed? What happens with the Essential and Breaks, one says "install this now" the other says "dont install this if a verison of sysvinit-utils is there". That's a bit of a conflict. Is Replaces a better way of doing this as procps-base is replacing one file from sysvinit-utils? Other than removing pidof, is there anything the syscinit-utils people need to do? As its a bit tricky, I really don't want to mess up the inter-dependencies. A non-working file init uses is a bad thing. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131209025656.gb29...@enc.com.au
Re: dpkg with new Essential (Was: pidof changing from sysvinit-devel to procps)
On Mon, Dec 09, 2013 at 11:42:13AM -0800, Steve Langasek wrote: > You must use versioned Replaces, and *not* versioned Breaks, for the case of > moving files between Essential packages. Since (as others have mentioned) > the version of sysvinit-utils that drops pidof needs to add a Pre-Dep ond > procps-base, the Pre-Depends<->Breaks relationship makes it impossible for That makes sense actually. Install procps-base first, the Replaces lets it replace pidof Install new sysvinit-utils, it pre-depends on procps-base so pidof is there. It's not critical that the new procps-base gets installed, just that either the old sysvinit-utils OR the new procps-base is there so we have a pidof somewhere. Thanks everyone for your comments. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131209220327.gd23...@enc.com.au
Re: [Pkg-sysvinit-devel] procps with pidof is released
On Mon, Dec 09, 2013 at 10:03:09PM +, Ben Hutchings wrote: > Discussed here: > > http://thread.gmane.org/gmane.linux.debian.devel.general/185723/focus=185725 That's the "leaving" side, the "arriving" side is. http://www.freelists.org/post/procps/Adopting-pidof-from-sysvinittools Not sure what is happening with killall5. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131209220656.ge23...@enc.com.au
Re: [Pkg-sysvinit-devel] procps with pidof is released
On Mon, Dec 09, 2013 at 12:18:00PM -0800, Steve Langasek wrote: > [sending this to both pkg-sysvinit-devel and debian-devel, instead of having > two separate threads.] Good idea. It looks like you're talking here not about the sysvinit maintainers, but > the *Red Hat* sysvinit maintainers. Perhaps the rewrite of pidof is > something that we want to pick up, but the rationale for including it in the > procps package doesn't apply to Debian at all. Right, can someone go and ask the sysvinit-utils or sysvinit-tools upstream what they are going to do? If they are going to keep pidof then the change is not required. If the projects plans is to retire/move it, then we will need to move it too. I'm not sure exactly who the exact upstream project it is. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131209221052.gf23...@enc.com.au
Re: [Pkg-sysvinit-devel] procps with pidof is released
On Tue, Dec 10, 2013 at 09:10:52AM +1100, Craig Small wrote: > upstream what they are going to do? If they are going to keep pidof > then the change is not required. If the projects plans is to Which I did. For the moment they have no plans moving pidof though they don't seem terribly fussed either way (that's my read of it anyhow). What I have done is used the --disable-pidof flag in procps configure step. This means procps does *not* have pidof and it can remain in sysvinit-tools for the time being. If the upstream decides to move it, we'll work out what to do then. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131216114707.ga31...@enc.com.au
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
On Sat, Dec 28, 2013 at 05:59:35PM -0500, Stephen M. Webb wrote: > Nope. An organization that will not accept the GPLv3 because of the > tivoization and patent clauses will not accept > GPLv2 or later. The "or later" clause means a downstream can invoke their > rights under the GPLv3 to demand secret > encryption keys or upstream can revoke the license for patent action. These > organizations do not accept GPLv2+ because > it's effectively GPLv3. Oh man, you can tell they never worked under the NM process under me then, because that was one of my favourite questions. The "(at your option)" is absolutely critical here. Those organizations that have taken that line have missed this point. That's what stops things like "tentacles of evil". That version of that software will always be GPL v2, or if they (and only they) like, GPL v3. It is their decision for that particular release of software. Now, the developer might choose to license under GPLv3 next release, but then he/she/them could relicense under whatever license they collectively feel like it too. GPL-2+ means I release it as GPLv2, but any user of my software can choose to have it under GPLv3. It also means subsequent developers could release it as v3, but that could/would be a fork if the primary development is still ongoing. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131230030728.ga23...@enc.com.au
Re: Can we please change the Subject: ?
On Tue, Feb 11, 2014 at 07:50:32PM +0100, Matthias Urlichs wrote: > Your email has no old Subject:, no References: and no In-Reply-To: headers. > So … whatever or whoever you're talking about … I was confused what it was about too. I think I've been over-eager with the ^D key in mutt again. It was probably about how nice the weather has been lately. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140212012902.gb19...@enc.com.au
Bug #739874 - procps doesn't build on i386
I got a bug report stating that there is no i386 build for procps. First I'm not really sure that's how bug reports work, but anyhow. There doesn't seem to be a publically available i386 Debian machine that supports building packages. This makes it nearly impossible to support that architecture because I need to see what is going wrong. I actually think the problem is something quirky with the specific builder host, but have no way of knowing this. The reason is that multiple versions of procps have been build and this 6-line change for the latest did not touch the failed program or has anything to do with it (the fix was for sysctl, the failure was in ps). The problem seems to be the SCHED_BATCH scheduler didn't appear or apply to program. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224201024.ga22...@enc.com.au
Re: Bug #739874 - procps doesn't build on i386
On Tue, Feb 25, 2014 at 12:06:56AM +0300, Cyril Brulebois wrote: > No, I wasn't sure what Craig was not sure about, that's why I tried to > connect the dots with the usual FTBFS bug reports developers might be > (more?) familiar with. You guessed right, I understood what you meant and got a way forward; thanks! - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224214859.gd9...@enc.com.au
Re: Bug #739874 - procps doesn't build on i386
On Mon, Feb 24, 2014 at 09:27:08PM -0500, Stephen Powell wrote: > and extracted with dpkg-source. In other words, on my machine at least, > I did not get a FTBFS error. It looks like its something strange on that particular pbuilder. The problem is that barriere is even stranger and the programs won't compile due to a header clash that has never been seen before. It seems libc6-dev 2.18 has introduced a new define which clashes with something top has. /usr/include/i386-linux-gnu/bits/waitflags.h:53:3: note: previous definition of 'P_PID' was here This small problem gets bigger each day. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140225065217.ga10...@enc.com.au
Re: Bits from the Security Team
On Thu, Mar 06, 2014 at 12:54:00AM +0100, Vincent Danjean wrote: > I'm not sure I will let this setup (hidepid=1) on my computers. My > current POV (that can change) is that I prefer to be able to do the > maximum of thing as a normal user (top, ps, read log (I'm in the > adm group), ...) ans switch to root when I really need to do some > modifications. You apparently can have a "special" group that can see everything. That might be worthwhile for a default. It makes things like pstree look odd, so I'll be expecting some new bug reports. Someone might like to fix mount(8) too, especially the bit about procfs if this is the new default. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306012106.ga30...@enc.com.au
Re: Bits from the Security Team
On Fri, Mar 07, 2014 at 01:57:17PM +0100, Stephan Seitz wrote: > On Thu, Mar 06, 2014 at 12:21:06PM +1100, Craig Small wrote: > >You apparently can have a "special" group that can see everything. > Aren’t there PAM modules which can grant capabilities to certain users? No idea, adduser thisuser thatgroup seems a reasonably simple fix. > >That might be worthwhile for a default. > >It makes things like pstree look odd, so I'll be expecting some new bug > >reports. > It will break software like nagios with check_procs. Any ideas how > one can solve this? dpkg-stateoverwrite doesn’t support > capabilities, only the standard chmod commands. That's why I think there should be a defined group. Then anything that needs or anyone that wants, "normal" access just gets added to this group. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140308215200.gf7...@enc.com.au
Re: jquery debate with upstream
On Wed, Mar 12, 2014 at 12:58:51PM +, Ian Jackson wrote: > I have a completely different approach to the DFSG. The DFSG is not > carefully drafted document and it doesn't stand up to detailed > legalistic interpretation. Rather, it is a statement of aims and > values. That was certainly how I remember the crafting of it as well. Removing source files you don't use seems very, well, meta to me. Once all other problems are solved and we've got nothing to do, perhaps then we should look at it. It provides no benefit except work for developers. FWIW, I think the concept of a graphic needing its source is also bogus. It means that the upstream have to hang onto some script they might of used once years ago for.. what reason? To give you a concrete example, I made the SPI logo (and I think it is the current one, it looks like it) using gimp and some sort of lisp script. I don't have that script anymore, does that make the logo non-free? Should that change the status of the graphic? If, instead of a script I manually typed/moused the commands, does that change the status? - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140313120208.gb12...@enc.com.au
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
On Fri, Apr 25, 2014 at 09:41:37AM +0100, Neil Williams wrote: > The package is wrong if lintian reports the error. Fix the package. Not always, the way lintian checks is wrong. I'm not buying into is minimised source or not, but no matter which way you sit on that issue, the lintian checks for source-is-missing need some work. See bug 744972 for some details, but basically the source for foo/bar/baz.min.js doesn't need to be found in foo/bar and called baz.js Just in case others get this message, can see the source code and wonder why. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140425115856.gc30...@enc.com.au
Re: Redefining critical bug severity (was: how to deal with a missed so bump already uploaded ?)
On Sat, May 17, 2014 at 08:46:20AM -0700, Russ Allbery wrote: > The confusion seems to always be around the "unrelated software" part of > that definition. The intended meaning is completely unrelated software on > the system, indicating a package that's mangling the system in some > fundamental way, but I've frequently seen people believe, sincerely, that > reverse dependencies, Perl programs that use a buggy module, or X programs > on a system with a buggy video driver qualify as unrelated software. > > This makes me think that part of the bug definition is adding more > confusion than clarity. Should we just drop it? I must admit I never really understood the meaning of unrelated software and it does cause confusion. It could mean anything from anything that isn't in that specific package (so includes dependencies), or anything except itself and depencies (so includes suggests), reverse depends or something else. > makes the entire system unusable, or causes serious data loss, or > introduces a security hole on systems where you install the package > > is closer to how we actually use the severity, and would avoid some of > these bug severity arguments. I agree. I also agree that there isn't, for me, much difference between the top three severities on how I treat the bugs. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140519210509.ge26...@enc.com.au
Re: Bug#631592: RFC: Adding "Pre-Depends: libtinfo5" to libncurses5
On Mon, Sep 12, 2011 at 07:46:51PM +0200, Sven Joachim wrote: > b) Add the Pre-Depends and wait for someone to whine that no consensus >on debian-devel was reached according to Policy §3.5. > I'm inclined to go with b), so if anybody has objections, please raise > them soon. I think we had one maybe and one yes. FWIW I think we need to do b) as well. - Craig -- Craig Small VK2XLZhttp://www.enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org old fingerprint: 1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 NEW fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 signature.asc Description: Digital signature
Re: what's the difference between [s/i/m/l/k/n] ?
On Sun, Mar 01, 2015 at 05:54:36AM +, lumin wrote: > When learning on how to package software, > I am confused about what's the difference between the > essence of [s/i/m/l/k/n]. > (single binary, indep binary, multiple binary, ...) What is copied out of /usr/share/debhelper/dh_make/debian[simlkn] That essentially is what the difference is. You would normally use "s" unless there was a good reason not to. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150302105857.ga25...@enc.com.au
mudlet bug #787354: icon had wrong license
Hi, I'm trying to work out what would be the best way forward for this. mudlet has an icon, mudlet.svg which had a cc-by-nc-sa license. I reported it to upstream who basically said "oh yeah, we stuffed up, not sure how it got there, fixed now". Do I need to rebuild mudlet for jessie to fix this? It seems to be quite a lot of mucking around just for something we know has the wrong license. If it needs rebuilding, does this mean I also have to muck around with the source file too as it has this the "incorrect file"? Alternatively I could make a note in the bug report and not make it a serious level so its not RC. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150608124145.gb19...@enc.com.au
Re: mudlet bug #787354: icon had wrong license
On Mon, Jun 08, 2015 at 02:05:11PM +0100, Adam D. Barratt wrote: > With my SRM hat on, we're generally happy to consider the issue resolved if > the package in unstable contains the correct license information and the > file(s) involved are other distributable, as at that point it's basically a > documentation issue rather than a licensing one. Assuming that's the case, > no separate update for Jessie would be required. Thanks, I'll document and downgrade (to make it non-RC) the bug. Yes, its a purely a documentation issue. See https://bugs.launchpad.net/mudlet/+bug/1404763 -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150612105047.gb8...@enc.com.au
Re: mudlet bug #787354: icon had wrong license
On Fri, Jun 12, 2015 at 04:13:59PM +0200, Tobias Frost wrote: > Am Freitag, den 12.06.2015, 20:50 +1000 schrieb Craig Small: > > On Mon, Jun 08, 2015 at 02:05:11PM +0100, Adam D. Barratt wrote: > > > With my SRM hat on, we're generally happy to consider the issue resolved > > > if > > > the package in unstable contains the correct license information and the > > > file(s) involved are other distributable, as at that point it's basically > > > a > > > documentation issue rather than a licensing one. Assuming that's the case, > > > no separate update for Jessie would be required. > > Thanks, I'll document and downgrade (to make it non-RC) the bug. > > Yes, its a purely a documentation issue. > > Ähm, just a question: the license is *non-commercial*. Is it really > distributable in main then? I'd guessed not, but I'm happy to learn > something new... It's a documentation issue, not a license issue. ie what is written is not what they wanted to say. Essentially: Me: "Hey this is a NC license" Them: "Oops, sorry, its supposed to be GPL" - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150612231546.gb11...@enc.com.au
Re: Security concerns with minified javascript code
On Wed, Aug 26, 2015 at 12:28:22AM -0700, Vincent Cheng wrote: > In that case, perhaps those who are most vocally in favour of > enforcing build-time javascript minification would care to work on a > debhelper addon to do so (similar to how dh-autoreconf makes dealing That to me seems the best way forward. > reproducibility by themselves. Choosing to whack people on the head > with Policy (or equivalent) instead is likely to be more > counterproductive than anything else. I tend to ignore it and find it annoying noise. You might as well say "abandon packaging certain types of webapps in Debian" for all the use some of the discussion is. I don't have people saying that javascript should be buildable or its an ideal, just with people saying it must. When faced with the realities it just goes back to the "well, it should" again. As a maintainer with packages that have javascript this is not very helpful. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: Script to generate common license texts
On Fri, Sep 04, 2015 at 11:08:20PM +0530, Balasankar C wrote: > Is there any script which takes abbreviation of a license (like > GPL-3+) as input and generates the license text that can be used in > debian/copyright (80 character wrapped, one space before each line, > paragraph separated with periods - the whole deal. Steal them or use them from dh-make. $ ls /usr/share/debhelper/dh_make/licenses/ apache artistic blank bsd gpl2 gpl3 lgpl2 lgpl3 mit If you just lift them a few :%s/%blah%/this/g in vi or equivalent and you're done. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: Have to get rid of at least some packages
Michael Meskes wrote: > Here's a list of my packages. It also contains the packages for which I made > the last non-maintainer upload. [...] > djtools 1.0-2 I'll take djtools if it hasn't already gone. - Craig (sitting on the end of a dead 7513 :< ) -- Craig Small VK2XLZ, PGP: AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90 |@work: [EMAIL PROTECTED],@play: [EMAIL PROTECTED]| |@home: [EMAIL PROTECTED], @debian:[EMAIL PROTECTED]| |@web: http://www.triode.net.au/~csmall @spam:[EMAIL PROTECTED]| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_make
[EMAIL PROTECTED] wrote: > I have recently created a debian/rules file with dh_make, it used "-g" for > CXXFLAGS and "-g -O2" for CFLAGS. Is there any reason for not using -O2 for > C++ compilation? Also do we really want debugging symbols in all the > binaries? > > The C++ code compiled with -O2 seems to run well, so I don't think there's > any compiler error for my setup (latest EGCS) at least... I don't think we need to include debugging code, I'm not sure where the -g comes from in the CXXFLAGS as I thought I didn't set that anywhere. scooter$ grep CXX /usr/lib/debhelper/dh_make/*/* scooter$ - Craig -- Craig Small VK2XLZ, PGP: AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90 |@work: [EMAIL PROTECTED],@play: [EMAIL PROTECTED]| |@home: [EMAIL PROTECTED], @debian:[EMAIL PROTECTED]| |@web: http://www.triode.net.au/~csmall @irc:seeS @icw:5723597|
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Wed, 17 May 2023 at 14:10, Steve Langasek wrote: > Over on debian-arm@lists, there has been discussion on and off for several > months now about the impending 32-bit timepocalypse. As many of you are > aware, 32-bit time_t runs out of space in 2038; the exact date is now less > than 15 years away. It is not too early to start addressing the question > of > 32-bit architecture compatibility, as there are already reports in the wild > of calendar failures for future events on 32-bit archs. > Hi Steve, Have they also considered the same issue with utmp? https://github.com/thkukuk/utmpx/blob/main/Y2038.md Some of it is reasonably easy to fix by changing the utmp-related calls with the systemd equivalents, but not all fields are available. - Craig
New Essential package procps-base
Hello, For quite some time (since 2006!) there has been a discussion at[1] about changing from the sysvinit-utils version of pidof to the procps one. A quick scan of the various distributions shows that only Debian and Ubuntu (and I assume most other downstreams) use the sysvinit-utils version. So to rehash some old drafts, here's the proposal. What: Create a new package procps-base. This uses the existing procps source package and just enable building of pidof. procps-base will be an Essential package and only contain pidof. Why: This would bring the pidof variant in line with other distributions. sysvinit-utils would no longer need to be Essential (though that's a separate issue) and would only have init-d-script, fstab-decode, and killall5. The majority of usage of pidof is in init or pre/post scripts, which really should be using the LSB pidofproc function. That function in turn optionally uses pidof if the pidfile parameter is not given. That's probably a way forward for sometime in the future to not need procps-base Essential, but it is a way off. sysvinit-utils requires only libc6 while procps-base require libproc-2 but this is the same library used for the ps,top,w etc tools which are installed on most systems. 1: https://bugs.debian.org/810018
Re: Bug#810018: New Essential package procps-base
On Wed, 15 Nov 2023 at 23:03, Guillem Jover wrote:
> I'm all in for shrinking the essential-set. If there is consensus to
> switch pidof implementations that also seems fine to me in the abstract.
> But this shuffling around of essential-ness and new tiny packages and
> stuff seems a bit unnecessary to me, more so when this increases the
> bootstrapping-set. I'd also rather see instead a _proper_ transition to
> get sysvinit-utils out of the essential-set, and then at some later
> point procps can take over pidof.
>
There really is two options then:
1) Switch pidof to new Essential package procps-base THEN update/fix the
dependent packages
2) Update/fix the dependent packages THEN move pidof to standard procps.
Independent? of either: re-work init scripts to use start-stop-daemon
For people that want the standard pidof #1 is preferred, for people
concerned about Essential's size #2 is preferred.
Most of the pidof usage can be broken down into a few sets:
* Used in comments/documentation - can be ignored for "pidof is Essential"
purposes
* Used in init or pre/post scripts - should probably be using pidofproc
* Within their programs use something like system("pidof myprog")
and then there are a few other odd ones that don't fit into those three.
Then there's the following, which I guess complicates things:
>
> $ dpkg -S bin/pidof | cut -d: -f2
>/bin/pidof
>
I'm not sure what the complication is here.
Also why is killall5 not a candidate too?
There's no other implementation of killall5 though it is probably something
that could be done with one of the other /.*kill.*/ programs.
Significantly, I don't think there is any real dependency of this program
in other programs, codesearch seems to be only for documentation.
> I think the status_of_proc function could be switched to use
> start-stop-daemon (s-s-d) --status instead of pidofproc. To replace
> pidof inside pidofproc I guess s-s-d could grow some option to print
> the pid, I'd be happy to implement that. After doing a quick scan over
> codesearch.debian.org, I notice that it looks like many current uses
> of pidofproc should instead probably be using status_of_proc, and others
> seem to just be fetching the pid to then perform some action that could
> instead all be done directly with s-s-d.
>
I agree that this is a good idea. It will be more about removing the
Essential flag on any package.
- Craig
Re: Y2038-safe replacements for utmp/wtmp and lastlog
On Wed, 8 May 2024 at 09:03, Jun MO wrote: > 1) I hope there will still be the original > w(1)/last(1)/lastb(1)/lastlog(1)/faillog(1) > tools which can still read *old* format utmp/wtmp/lastlog in Debian at > least for > a while after switch to Y2038-safe replacements. Those tools can read > I can only speak for w. It currently prefers what it gets from systemd or elogind, effectively iterating over the sessions coming from sd_get_sessions() if sd_booted() returns true. If sd_booted() returns false, then it uses the old utmp/utmpx files for now. Besides the Y2038 issue, the utmp "API" is pretty awful with things like errors pretty much undetectable. There is also the problem about who (e.g. which process) should be writing to those files as you have pointed out in your email. For now w/uptime will use utmp as a fallback, but I'll be happy if this gets updated to something better; it's a low-priority for me because systemd/elogind do what I need most of the time. - Craig
Re: Hosting the original youtube-dl sources on salsa?
I though I saw something about it being reinstated but without the..
rolling encryption I think they called it.
Obviously you would want to confirm and qualify that but it might change
things.
- Craig
On Fri, 30 Oct 2020, 07:18 Rogério Brito, wrote:
> Dear people,
>
> As many of you may know, the RIAA issued a resquest for GitHub to take down
> the youtube-dl repository.
>
> The tree had some fixes that were *not* in the latest release that I
> uploaded a few days ago (I am the maintainer of youtube-dl in Debian, just
> to make things clear).
>
> Since the tree was taken down (and, to boot, of the 18 forks listed in the
> takedown request, mine was explicitly listed), I fear that me uploading the
> lastest tree to GitHub is asking for trouble.
>
> Given this situation, can I upload a backup of youtube-dl to salsa under my
> user account? I already maintain the packaging of youtube-dl in a
> different
> repository that is both on GitHub and on salsa. Should I take it down from
> salsa?
>
> If these are not the appropriate mailing lists to send this to, please
> point
> me to better places. I was in a hurry and I decided to send this as soon as
> I found out places that seemed suitable.
>
>
>
> Thanks for any help and support,
>
> Rogério Brito.
>
> --
> Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
> http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
> DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
>
>
Re: CITL Releasing 7000 defects/vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I got my reports for two of my packages (I'm upstream for both too). The first problem is I couldn't find what version of the program they found the bug in. I also looked closely at one specific example and it didn't crash at all. Unless there was some underlying problem with a previous version of atoi() I cannot actually see what sending it what it got would do anything other than what I see (effectively "meh, you sent 0 Ill exit now"). - Craig On 2020-11-01 at 23:34, calumlikesapple...@gmail.com wrote: > On Sun, 2020-11-01 at 14:56 -0800, Russ Allbery wrote: > > Utkarsh Gupta writes: > > > > > That said, it'd be a bit weird if they don't report these issues and ask > > > for a CVE assignment against these. Anyway, the security team might > > > know more about this. > > > > It appears to be the output of automated fuzz testing, which based on past > > experience means that a large percentage of the crashes are probably not > > exploitable. > > Oh, it's definitely the result of automated fuzzing. Their entire website > is about using automated fuzzers to find code defects. Plus, I don't think > any sane person would spend their time concocting test cases for crashes in > 0x (a nokia firmware writer) without bothering to report the bugs they > found in binutils (a somewhat more common package). > > Further, I would argue that many of the crashes might not be just > unexploitable, but appropriate. If given highly unusual and bizarre input, > crashing with SIGABRT might be the most sane response. > > > The raw data is not hugely useful in aggregate unless you enjoy fixing > > edge-case buffer management bugs that no one is likely to care about (such > > as in options parsing code). It can be made useful by tracking down where > > the crash happens and then figuring out if that's part of an attack > > surface, but that's quite a bit of work which they're clearly not > > volunteering to do. > > That being said, I do think we should at least take a look. A ton of > security bugs are just buffer overflows, and it has been shown that even > tiny bugs can lead to remote code execution. I recently read > googleprojectzero.blogspot.com/2014/08/the-poisoned-nul-byte-2014-edition.html > which goes from writing a single null byte past the end of a linked list to > full privileges, despite security features like ASLR. Even if none of their > test cases can be used to exploit modern packages, we'd at least know. > > I agree with Daniel Leidert that Debian should take charge of this, rather > than expecting each of the package maintainers to individually request the > CITL data and test it. Perhaps QA could get the master copy, devise a > script to find the unfixed test cases, and notify package maintainers. > > > Thanks for taking the time to read my wall of words, > Calum M -BEGIN PGP SIGNATURE- Version: FlowCrypt Email Encryption 7.9.7 Comment: Seamlessly send and receive encrypted email wsFzBAEBCgAGBQJfo9SsACEJEAIhZsD/PITjFiEEXT3w9TizJ8CqeneiAiFm wP88hOP8Xg/+LJYPcP0kP57uYkeQBF9l3eHQOkdRSSWWo5trijUrcva88y8U kDjofUJUD2ok8PzHtBWgLe75zyjtBzyHdzTnjPRt7V2qXn8mlhw7mda2QJQK SRJ+4qoEcZdnHgkqcAxCzE9VFh/Q9vD08IqDxLB4gIkOrA6WCIEnXdjaQ86i N9cVST3obAWTYvgXlEdUv2m60aIxhYB0GEwxrM05ZqpZmx9K9uE2NFBNjVg0 S3aSS/9IBffLWv7wLJKaZc0xfSczB9y8S1dt/8CBOSDgxVtoI+b4cf4KiTuf oniXYGJBz/P8bS5NnzaeNCrsmfNK5ugUGu7XJvnxsgpy75kBXoZciBtaqiJF pvNYct2SLpbWyDF4+60ATFhhd6xdxCpv8eCgx8WpHvMenZ+vISCxSdVmvKna xYd9HFyu0AZCRD9taA+CUYVs6NNeDlxQL8IE6km5FJRwSXbDo0EY2s7SySrt HYEr4mFCSdHsdXTbvIRKHm0fUVmfKyVorvKPq9z3JR40HmdP9kCjtNRu2VYW nVBoWA7LoehKbH4KtFNbNmunqefQrI6KjsKiML73BJCrirn0ITK40onxOi2h Y5nG2hz6yYKD2ypSGWmcePcRxplhO/iQxHCI+2XEAQuoSGO0FHgP/pnn8L8m 6pkC/8fkJUDaXivNfr+zH4wJE6vTX54YMqw= =DoyM -END PGP SIGNATURE- 0x3938F96BDF50FEA5.asc Description: application/pgp-keys
Re: deduplicating jquery/
Hi, WordPress has a bunch of these dependencies which float in and out of lining up between what Debian has and what upstream WordPress uses. As an added bonus, they sometimes slightly adjust their copies. I use lintian overrides and dh-linktree and this helps, but the result is less than good and often just means WordPress ships with its own copies of javascript libraries. It makes me rather sad, but fixing it would cost a lot of time (and also what Russ said, which was a good summary of the problem) so I don't see a good solution. But if you ever find one, I'll gladly update WordPress to use it :) - Craig
Re: TEMP Ids
Hi, The TEMP IDs are automatically generated by the security tracker and are a placeholder for the CVE ID. They are unique but generally should not be quoted outside the tracker. The issue should (but not always) get a real CVE ID so yes it can change to that. If you were looking for a fixed reference the bug number is probably a better option. - Craig
Re: merged /usr vs. symlink farms
On Fri, 20 Aug 2021 at 09:56, Theodore Ts'o wrote: > P.S. I had a vague memory that there was some update in the long > distant past where we did require a manual upgrade of dpkg first. Or > is my memory playing tricks on me? I do know that a manual update of > dpkg is the first step in a crossgrade > There was an instance of this. I cannot remember if it was the libc4/a.out or something to do with libstdc but it was library-related and a bit of a pain for end-users. In any case, it was not an ideal situation or something we should aim for. - Craig
Re: Gmail bounce unauthenticated @debian.org addresses
On Fri, 4 Mar 2022 at 23:34, Ansgar wrote: > On Fri, 2022-03-04 at 13:27 +0100, Stephan Lachnit wrote: > > On Fri, Mar 4, 2022 at 12:47 PM Baptiste Beauplat > > wrote: > > > As a reminder debian.org addresses does support DKIM. After > > > configuration on your mail server, you can publish your DKIM public > > > key > > > to db.debian.org [1][2]. > > > > Can you point to some quick guide on how to do this for gmail? The > > support page seems kinda confusing to me. > > This usually requires you running your own mail server (for outgoing > mail). > > I don't think mail providers like GMail allow you to set up DKIM for > individual IP addresses. This is basically how I do it. My setup is I have G-Suite or whatever its name is this week and a separate outbound server. I'm not sure what the "to do this for gmail" means here, so there is three parts to this: * What Gmail does with DKIM * How I send emails from @debian.org using mutt etc * How I send emails from @debian.org using Gmail First, Gmail likes DKIM signed mails; some of these bounces are caused by DKIM problems. DKIM is basically a signature to say the senders server is allow to send those emails. You have to set it up (sign) on the outbound servers and check it on the inbound servers. For any of my servers/laptops I send outbound email to my own outbound server. This server signs emails using opendkim with the dropbear.xyz key or the debian key depending on the from address. It's no good sending email from j...@cow.com with a key good for j...@sheep.net Last of all, to send emails within Gmail using csm...@debian.org as my from address, you go into Settings->Accounts->Send mail as. The outbound mailserver is my server (that signs my debian emails). Of course my outbound server requires a username and password to send emails so that is recorded in the settings too (and is unique for each sending system/server). The result is this goodness I can see with an email from my laptop into Gsuite using my debian email address: Authentication-Results: mx.google.com; dkim=pass header.i=@debian.org header.s=debian1.csmall.user header.b=uVHcNrjO; header.i is identity, e.g. what domain are you trying to prove you can use. header.s is selector, which is what method/key am I using to prove this. header.b is the hash/signature. I'm a network engineer, not a mail server admin so this might not be 100%, but it does give me the happy mailserver headers I want. - Craig
Re: Integration with systemd
On Fri, 1 Nov 2019 at 08:27, Thomas Goirand wrote: > However, this doesn't mean that anything non-systemd must implement all > things that systemd does, or just die. It really doesn't make sense to > tell that, for example, OpenRC should be forced into implementing a > parser of .timer files, just because some maintainers wont care about > cron jobs. These cron jobs could be maintained by those who care, just > like with sysv-rc scripts, as a best-effort basis. > I think this, or something like this, is the policy update the project needs. I think this is a fine option, but does the project as a whole think so, or perhaps they do with some changes? At the moment, my guess is most developers have no idea what the "right" (e.g. what the project as a whole believe is right) solution for this. Should I just use systemd support only? With sysvinit? If I get bug reports about lack of support for one or the other how important is it? - Craig > Thomas Goirand (zigo) > >
Kernel parameters protecting fifos and regular files
Hi, About 2 years ago the procps package added protection for hard and soft symlinks. The bug report was 889098 and has seemed to work fine. There is also now bug #914859 which would extend this same protection for other files, as mentioned in [1] On the one hand, having all these file types protected by default would be very nice. On the other, it may break things in odd ways though I suspect this is quite rare. A system administrator is, of course, able to set these to whatever they would like, but what should the default be? My personal preference is to lock them down by default, by setting both to mode 2. However the impact is way more than my handful of systems I use, hence the wider email. Putting it another way, are there any real strong reasons for not doing this? - Craig 1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5
Re: Kernel parameters protecting fifos and regular files
On Thu, 30 Jan 2020 at 05:26, Moritz Mühlenhoff wrote: > I'm in favour of setting both to 1. From a quick search Ubuntu carried a > patch > in their systemd package to set this as well (LP 1845637). > > protected hardlinks/symlinks are enabled via a Debian-specific kernel patch > by default, so I'd say that src:linux should be patched as well, this > changes > the default at the deepest level and the /etc/sysctl.conf kicks in for > anyone running custom built kernels. > OK, I'll make them both 1 rather than 2 so there is some consistency. I note the concern some have brought up about procps is not installed in some minimal installations but that's not the problem we're trying to solve here. They'll be in the next release. Thanks all for the input. - Craig
Re: Replacing web assets with symlinks to packaged versions
Hi Enrico, Have you looked at dh-linktree? I use that in wordpress so if the package has the right files it makes symlinks to the relavant spot and adds the package to the binary dependency. - Craig
Re: manpages.debian.org has been modernized!
On Thu, Jan 19, 2017 at 4:24 AM Michael Stapelberg wrote: > Furthermore, the design of the site has been updated and now includes > navigation panels that allow quick access to the manpage in other > Debian versions, other binary packages, other sections and other > languages. Speaking of languages, the site serves manpages in all > their available languages and respects your browser’s language when > redirecting or following a cross-reference. > I had a look at some of my manpages. They look good! It's a nice clean appearance with doing sensible things like pulling out a TOC and cross-references. > We’d love to hear your feedback and thoughts. Either contact us via an > issue on https://github.com/Debian/debiman/issues/, or send an email > Being upstream for some packages and a Debian developer, I totally get the thing about the github issues log versus the Debian BTS too. Someone should fix that; but of course there are so many hours in the day. - Craig -- Craig Small (@smallsees) http://dropbear.xyz/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: What can Debian do to provide complex applications to its users?
On Sat, 17 Feb 2018 at 02:11 Raphael Hertzog wrote: > I'm sure we are missing lots of good applications due to our requirements. > What can we do to avoid this? > [...] > What do you think? Do you have other ideas? Are there other persons > who are annoyed by the current situation? > I'd like to start this with, I don't have an answer. However it is annoying! I have wordpress that ships some javascript libraries purely because the ones in Debian are ancient or not packaged. Ideally I'd like to use to just depend on some other packages but the problem is, is the javascript library shipped by wordpress the same as the upstream? Certainly dh_linktree (thanks Raphael!) help here, but its a problem I don't want to encounter. Then I have another program. It's written in C++ so most of that side of things is fine, but it uses Lua plugins and this is where the drama starts. I just ship with the embedded ones, because version control of the (hypothetical) lua library packages and syncing it with whatever arbitary version of the library the program needs is hard. Finally, for programs I write and use myself, if its a C program I'm pretty sure I'll find what I need for libraries, but in other languages not so much. In the ancient days, we used to have some of these problems with binaries and shared libraries. Then newer, for their time, distributions such as Debian came in with versioned dependencies between the binary and the library. That didn't help when upstream used their own hacky un-maintained for years version of some library but it caught most of the cases. So, perhaps there needs to be a new way for some of these newer packaging methods. I don't think we can say package all the things, even Debian has its limits. - Craig -- Craig Small https://dropbear.xyz/ csmall at : dropbear.xyz Debian GNU/Linuxhttps://www.debian.org/ csmall at : debian.org Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: What can Debian do to provide complex applications to its users?
On Tue, 20 Feb. 2018, 09:44 Vincent Bernat, wrote: > ❦ 19 février 2018 22:33 GMT, Holger Levsen : > > >> a bit like backports that are not security supported > >> either. > > > > this is now the 2nd mail within 24h were you claim this *wrongly*. > > > > backports are (supposed to be) getting security support. if you dont do > > this for your backports, you shouldnt have upload rights. > > From https://backports.debian.org/FAQ/: > > Q: Is there security support for packages from backports.debian.org? > > A: Unfortunately not. This is done on a best effort basis by the people > who track the package This looks like a language confusion. There is no security *team* support but there is security *package updates* by the individual maintainers. The individual contribution sounds optional here in the FAQ but from my experience with backports it's strongly encouraged. - Craig > > -- Craig Small https://dropbear.xyz/ csmall at : dropbear.xyz Debian GNU/Linuxhttps://www.debian.org/ csmall at : debian.org Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: Packaging examples
Hi Kip, On Mon, 26 Feb. 2018, 09:34 Kip Warner, wrote: > This installs the example files as expected in > /usr/share/doc/foo/examples/, but I was still left to wonder what the > best practise was given that dh_installexamples(1) exists and seems to > want to do the same based on the contents of debian/foo.examples? > Not all upstream Makefiles are that good. My preference would be if their Makefile is doing the right thing then use that and have no debian/foo.examples file. The main thing is that the example files get put in the right spot and it's clear to someone how those files arrive there. The only other catch is to ensure the install-examples or whatever the Makefile target is called is actually run; either directly out of debian/rules or as part of the Makefile install target. - Craig -- Craig Small https://dropbear.xyz/ csmall at : dropbear.xyz Debian GNU/Linuxhttps://www.debian.org/ csmall at : debian.org Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Bug#892907: ITP: python-pytest-vcr -- pytest plugin for managing python-vcr cassettes
Package: wnpp Severity: wishlist Owner: Craig Small * Package name: python-pytest-vcr Version : 0.3.0 Upstream Author : Tomasz Kontusz * URL : https://pypi.python.org/pypi/pytest-vcr * License : MIT Programming Lang: Python Description : pytest plugin for managing python-vcr cassettes Allows pytest-runner tests to use a simple decoration for their python-vcr tests. Requires python-pytest and python-vcr which are both already packaged. This is required for testing the Mastodon python module which I am also going to ITP. While I can maintain it, I excpect this will form under the DPMT and use their salsa project.
Bug#893213: ITP: python-mastodon -- Python wrapper for the Mastodon API
Package: wnpp Severity: wishlist Owner: Craig Small * Package name: python-mastodon Version : 1.2.2 Upstream Author : Lorenz Diener * URL : https://github.com/halcy/Mastodon.py * License : MIT/X Programming Lang: Python Description : Python wrapper for the Mastodon API Mastodon is an ActivityPub and OStatus based twitter-like federated social network node. It has an API that allows you to interact with its every aspect. This is a simple python wrapper for that api, provided as a single python module. This will be maintained by me but will be part of the Debian Python Modules Team.
Re: make compilation not so gray
On Fri, 25 May 2018, 22:21 Adam Borowski, wrote: > But, nice folks who make gcc have introduced an option which helps here: > -fdiagnostics-color. It's very nice even for terse logs (such as the > kernel), but for our use case it gives a ridiculously good improvement: > instead of having to read a log pretty much line-by-line, you wiggle the > scrollbar and watch for that speck of red flashing by. > I think this is a great idea. There have been many others in this thread but just turning on the colour would be an improvement. - Craig > -- Craig Small https://dropbear.xyz/ csmall at : dropbear.xyz Debian GNU/Linuxhttps://www.debian.org/ csmall at : debian.org Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: Confusing our users - who is supporting LTS?
I've seen this sort of thing done elsewhere and the way they did it was to put a large amount of separation between the two. So the main site only mentioned the old releases in a historical context and pointed to a separate website which did the LTS. Any page for the older versions had a prominent common banner stating this. The Debian website doesn't really show this. Forget being a developer for a moment and look at https://www.debian.org/releases/jessie/ for example, it's not terribly clear. Or https://packages.debian.org/jessie/procps is this still maintained? Eg "After /date/ Debian version X is no longer supported by the Debian project, see ancientdebian.org". Every page every time. I'm not saying as annoying as those cookie notices, but something close. It has to be clear there is this cutoff. The fact that some developers work on it is fine, but stating that anywhere muddies the waters. Not an ideal situation and you'll still cop some emails but it might help. - Craig > -- Craig Small https://dropbear.xyz/ csmall at : dropbear.xyz Debian GNU/Linuxhttps://www.debian.org/ csmall at : debian.org Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: Looking for new maintainer(s) for net-snmp
On Fri, Dec 2, 2016 at 8:55 PM Raphael Hertzog wrote: > the net-snmp source package is looking for a new maintainer: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835654 I didn't see anyone reply except for someone saying they could help. As I seem to gather orphans for some reason I'll put my hand up to maintain this; welcome to the seeS orphanage net-snmp! You'll be joining other ex-orphans such as procps, psmisc and wordpress (but we don't talk about lprng which got kicked out). I've had a love/hate relationship (is there any other sort with snmp) with snmp the protocol for over 20 years and have poked around the code before. Looks like the package has missed a few transitions (ssl and mysql seem the obvious two) and needs some love. No disrespect to the previous maintainers, I have been in the exact same place with other packages and know how it is. If you're thinking you'd like to help I certainly can do the team maintainer thing, just let me know where you're looking at. It's all in git now so it's reasonably simple to keep things in-line. I got upload privileges so don't need an uploader but if the older maintainers of net-snmp want to lend a hand from time to time, that would be great. So, uh, let me fix wordpress jessie first! - Craig > -- Craig Small (@smallsees) http://dropbear.xyz/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: DAK Commands for Bikesheds
On Thu, Sep 17, 2015 at 11:19:57PM -0400, The Wanderer wrote: > I concur that this sort of wordplay in naming is a *nix tradition; > however, I withhold comment as to whether the name "bikeshed" is > appropriate in this case, as the first I remember hearing about them is > this thread and I don't know enough about the context to form a > defensible opinion. The irony is arguing about the name could be considered bikeshedding to some. At least, *I* found it amusing. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
vim plugin dependency and libruby
I've been helping someone with a vim plugin called vim-command-t[1] and we've both hit a snag. The problem is that when I used pbuilder it linked the plugin to libruby 2.2 but my vim is linked to libruby2.1 Now, the package has in its dependencies libruby2.2. libruby2.2 and libruby2.1 are both installed. As far as dpkg is concerned, all is well. Is there some way of putting some dependency onto vim to say "I want the vim linked to libruby2.2". One idea is to figure out what version they did link to it and put that in, but that's hard to maintain and doesn't work across architectures nicely. Generically the problem is: binary foo linked to libbar1, control file pulls in libbar1 plugin baz linked to libbar2, control file pulls in libbar2 But when foo tries to load plugin baz, it fails. Is it a problem with the plugin? Should it be using "ruby things" via the binary? - Craig [1] http://mentors.debian.net/package/vim-command-t -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: vim plugin dependency and libruby
Thanks James, If it is "just me" then its an easy fix. - Craig On Sun, Nov 29, 2015 at 8:39 AM James McCoy wrote: > On Sun, Nov 29, 2015 at 08:24:15AM +1100, Craig Small wrote: > > I've been helping someone with a vim plugin called vim-command-t[1] and > > we've both hit a snag. The problem is that when I used pbuilder it > > linked the plugin to libruby 2.2 but my vim is linked to libruby2.1 > > Your vim is outdated, then. Vim was rebuilt over 2 weeks ago as part of > the Ruby 2.2 transition. The only time there should be a discrepancy is > in the middle of a transition. > > > Now, the package has in its dependencies libruby2.2. libruby2.2 and > > libruby2.1 are both installed. As far as dpkg is concerned, all is well. > > > > Is there some way of putting some dependency onto vim to say "I want > > the vim linked to libruby2.2". One idea is to figure out what version > > they did link to it and put that in, but that's hard to maintain and > > doesn't work across architectures nicely. > > > > Generically the problem is: > > binary foo linked to libbar1, control file pulls in libbar1 > > plugin baz linked to libbar2, control file pulls in libbar2 > > > > But when foo tries to load plugin baz, it fails. Is it a problem with > > the plugin? Should it be using "ruby things" via the binary? > > No, it's just normal turbulence during a transition. I don't think > there's anything in particular that needs to be done. > > Cheers, > -- > James > GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy > > > -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: support for merged /usr in Debian
On Tue, Jan 05, 2016 at 03:55:51PM +, Ian Jackson wrote: > AFAICT the original posting in this thread is from someone who is > trying to make it easier and more automatic to try to produce Debian > installations which do not have a /usr vs / distinction. I think a lot of heat in this thread is due to people completely forgetting that is what this was about. > What is causing all the heat is the suggestion that support might be > withdrawn for currently working configurations which _do_ have a /usr > vs / distinction, or which do mount /usr using / rather than > initramfs, or some such. Which actually was never proposed. There were some "what if" type posts, but noone was mandating a merged /usr anywhere. > It seems to me that enough people want Debian to retain the > flexibility which is gained by the /usr vs / division, that we as a > project should continue to provide it. It would probably be a good idea to gather all of these use-cases and put them into the wiki under or linked to the usrmerge entry. I've seen a lot of "what about situation X" type emails in this thread with replies with "fixed with solution Y" or "not a /usr merge specific problem". Some of those would be useful to those people who have the same situation. It would also mean that any situation that hasn't got a solution is well-known. > That does not mean that every user has to have a separate /usr or that > /usr can't be mounted by the default initramfs. It does mean that > package maintainers need to continue to place files in / or /usr as > appropriate, respond approprately to reasonable bug reports, etc. So the idea would be, at this stage. 1) People who want a merged /usr install the usrmerge package 2) Package maintainers would still install in /usr/bin or /bin etc - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: Overall bitrot, package reviews and fast(er) unmaintained package removals
On Wed, Apr 6, 2016 at 3:26 PM Paul Wise wrote: > Sounds a lot like some of these should be added to bapase: > > https://udd.debian.org/cgi-bin/bapase.cgi I think you mean https://udd.debian.org/bapase.cgi but yes, looks like a good idea. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: utmp in trixie
On Thu, 3 Apr 2025 at 09:47, Marco d'Itri wrote: > On Apr 02, Bill Allombert wrote: > > >Does that breaks the usual unix commands like 'who' ? If yes this is > who(1) specifically, yes. > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079575 . > Maybe the coreutils maintainer is already working to backport this > simple patch in time for trixie, or else you could help him. > > >dangerous. It is common to use them before deciding whether a host > >can be shut down. > You may use w(1) for the time being. > w uses the systemd method by default now which is why it reports users. I thought there was upstream coreutils support for systemd in gnulib[1] which is what who uses, so in theory it's a configure change. I must admit I don't fully follow coreutils source so may have missed something. - Craig 1: https://github.com/coreutils/gnulib/blob/bb506f75625b47d7844af2b6dc4b8192d4dea676/lib/readutmp.c#L981
Re: utmp in trixie
Hi, On Wed, 2 Apr 2025 at 06:27, Michael Stone wrote: > /run/utmp is no longer provided in trixie, which means that the > mechanisms used to show active sessions in unix for several decades no > longer work. There's a replacement mechanism provided by systemd, but > it's not 1:1. I'm the procps maintainer for both upstream and Debian. procps provides some of these tools that used to, or still can, use utmp. The Debian package and upstream with the --with-systemd configure option will both use and prefer the information provided by systemd over utmp (if both happen) to be available.) As to it being not 1:1, that's partly correct, but the longer answer is, well longer. * There are things that have just gone missing and aren't related to utmp, such as idle time. * If you compile procps without systemd and run it on a host with no utmp, you see 0 users. * There is also the fact you might not see *term users. This is because for systemd they are the same session, so you see it once. The issue with utmp is there are no rules so say gnome-terminal you'd see the user but kterm you won't (or vice-versa, I forget who does what). That is because, in a way, the right answer is it's a single user. * There might be some remote users that get missed, basically not visible via sd_session_get_remote_host() but are in ut_addr_v6 in the utmp struct. I'm not sure how common this is or why/if it happens; i suspect it is some pam_session brokenness/corner case. > I propose that for trixie *both* mechanisms are active, so > a person can choose between them (and compare the output, to better > identify gaps between the historic utmp mechanism and the new and > improved systemd facility). I've been told that the reason this can't be > done is that utmp isn't y2038 compliant, but it seems to me that we > won't be supporting trixie in y2038, so who cares? Are there any factors > to consider that I've missed? > Yes, there is definitely a Y2038 issue, there are also issues with utmp not being handled consistently and some security issues around who can do what to the file. For me and procps utils in Debian, we don't use utmp and don't need it. Having utmp there won't change the tools' outputs. If the project at large says they want the file to hang around, that's ok by me but it won't give ps/w/etc any more details. - Craig
Re: utmp in trixie
On Fri, 4 Apr 2025 at 10:16, Michael Biebl wrote: > michael@mars:~$ loginctl > SESSION UID USERSEAT LEADER CLASS TTY IDLE SINCE >3 1000 michael seat0 2116 usertty1 no - >4 1000 michael - 2125 manager -no - > > 2 sessions listed. > > michael@mars:~$ who > michael seat02025-04-02 16:38 > michael tty1 2025-04-02 16:38 > Should 'who' report what loginctl list-sessions or list-users reports? We (procps, w, etc) use the latter by checking the session class for "user*". Without that filter, the output looked a bit weird. It's probably best both who and w agree. - Craig
Re: utmp in trixie
On Fri, 4 Apr 2025 at 09:46, Chris Hofstaedtler wrote: > Maybe it needs some additional work to fully function > with current systemd versions. IIRC procps also only recently added > some new code to deal with new systemd behaviours. > That's right, we were counting sessions, not user sessions. There's an explicit check for it now. There's also w terminal mode that displays terminals not users, utmp kinda-sorta did this inconsistently. w drives it from the processes tty field so should capture them all. PS: I never understood why there's both w and who, and why they are > different implementations. > Ancient historical reasons that pre-date my involvement (< 1997). See also: why so many *kills - Craig
