Re: bug reporting workflow is outdated
Quoth Ian Jackson ijack...@chiark.greenend.org.uk, on 2011-05-24 12:34:40 +0100: Apparently, if we don't want X Y Z done then we must resist an http interface for bug submission even if it makes it hard for reportbug to work correctly, because it's the thin end of a wedge. The fat end is a web form for users to submit bugs. Just to link this to a Place of Community Patterns: you and some of the others seem to be describing a PricklyHedge. http://meatballwiki.org/wiki/PricklyHedge Ian. --- Drake Wilson -- 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/20110524170935.GA15144@stingray.internal
Re: Debian x86 32-bits built for i586 !?
Quoth Ben Hutchings b...@decadent.org.uk, on 2011-05-15 14:36:03 +0100: There are a few new instructions on the Pentium that can be used in ring 3: cmpxchg8 and rdtsc. Linux has separate options for '586' and '586 with TSC', both of which result in -m586, so gcc does not appear to assume the existence of rdtsc. I would not expect gcc to generate cmpxchg8 except through an intrinsic, but I could be wrong. FWIW, I'm using Debian on a Soekris box with an AMD Geode. ISTR being told in the past that this is a 486-class machine, but /proc/cpuinfo reports (with some lines elided): | processor : 0 | vendor_id : Geode by NSC | cpu family : 5 | model : 4 | model name : Geode(TM) Integrated Processor by National Semi | stepping: 0 | cpu MHz : 266.571 | cpuid level : 2 | wp : yes | flags : fpu tsc msr cx8 cmov mmx | clflush size: 32 So it does have TSC, CMPXCHG8, and CMOV support. I'm not sure where that places it exactly on the ix86 processor chart; supposedly those are the main architectural differences that can actually break things compiled for i586? --- Drake Wilson -- 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/20110516015702.ga11...@drache.begriffli.ch
Re: enable/disable flags in /etc/default
(Sorry for the duplicate, Bob; forgot to send to list first time.) Quoth Bob Proulx b...@proulx.com, on 2011-03-02 17:00:19 -0700: Having daemons started automatically at installation time is a very nice feature of Debian IMNHO. Is there any harder data on which behavior various proportions or segments of the Debian user populace expect here? I gather this is a common opinion, but it's not mine. I find the current Debian behavior annoying (albeit within reason). Whenever I install a new daemon I often have to remember to pounce on [/etc/init.d/$foo_daemon stop] immediately afterwards so that my machine isn't exposing some random default configuration of foo_daemon for more than a few seconds before I have a chance to change it. I rarely install something I don't want installed. I mainly only install things that I want running, but I only want them running once I've verified the configuration. The default is often not useful to me. Examples where I insisted on manually configuring the daemon before starting it again: Apache, ejabberd, Privoxy, sshd (slightly unusual configuration), Exim (but it has Debconf questions which handle most of it), Postfix (I don't remember how that went), dnsmasq, Postgrey, Pound, radvd, I think LPRng. (Some of these may have actually started out disabled.) Counterexamples: at, cron, Chrony, syslog, DenyHosts (sort of---I reconfigured it but it wasn't in a critical way), HAL, udev, DBus, MySQL, maybe smartd, portmap. (Many of these are local system services rather than major applications on their own.) --- Drake Wilson -- 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/20110303015038.ga11...@drache.begriffli.ch
Re: Forwarding bugs upstream
Quoth Cyril Brulebois k...@debian.org, on 2011-01-12 01:59:03 +0100: If a bug is not readily reproducible or isolatable, it may be necessary to pass it over to an upstream maintainer who will know what further questions to ask. But they need to send those questions to the user, not to the Debian maintainer. In the kernel team, we often ask users to report bugs upstream for that reason. Ditto on the X side. Having a low-power proxy between developers and users is quite a bad idea (induces delays and higher load). I tend to think what would be ideal in such cases is for the package maintainer to go through the overhead motions of forwarding that require a heavy context switch (i.e., setting the ball rolling) and then subscribe the user to the relevant bug by email or some other similar communication mechanism. Which upstream bug trackers, if any, would make the above not work? Here I'm ignoring things like maintainer time to do the forwarding, assuming that that can be analyzed separately. Mainly I'm wondering about cases where the user essentially _can't_ communicate about the bug directly without going through rigamarole to create an account first or thereabouts; is this common? If so, and assuming it's much more expensive for the user to switch into bug reporting context, I find it likely that many users would give up at that point rather than having to report the bug a second time after having already expended the context switch effort to report it once. --- Drake Wilson -- 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/20110112012933.ga3...@drache.begriffli.ch
Re: Forwarding bugs upstream
(Woopsy, forgot to send to the list the first time.) Quoth Paul Wise p...@debian.org, on 2011-01-12 10:55:34 +0800: [among other responses] Sourceforge and probably Gforge/FusionForge trackers. The only tracker I'm aware of which would work is Trac, some instances of which allow anyone to put in anyone else's email address as the author of the bug. So basically most or all of them, then. Right. This doesn't leave much in the way of good options: - Having the user report bugs twice, with the second one being after a delay, creates choppy context switches that can require a pile of extra mental energy (at least in my estimation; I wouldn't mind being shown to be wrong). The create an account process is especially choppy because it requires multiple internal context switches to handle email verification and so forth. This results in giving up. At the least, as a data point, when I've reported bugs for which I didn't intend to be strongly active in helping develop a fix, it's taken more than double the total energy output when I've had to forward the bug myself: the choppy switching overwhelms everything else, and much of the time I never get around to doing it at all, whereas replying to another email would have happened quickly. - Having the maintainer be the reporter of record for upstream can result in forwarding hassle per unit time for the maintainer which is O(N) in the number of bugs. It shifts the annoyance from the previous option onto the maintainer, and condenses it in the process (the maintainer doesn't have to establish an association with the tracker multiple times, c.) but the condensation is only large for high loads for the forwarding part, and there's lots of communication delays. It also means the maintainer has to spend continuous work on things that are not necessarily useful to the package directly. - Having the maintainer forward the bug report but make the user the reporter of record doesn't work because they don't have the authority to do that, nor to override the hassle of initial association between the user and the upstream bugtracker. I wonder whether there's an optimization possible here, at least: perhaps the maintainer could forward first, but then _if_ at least N messages need to be forwarded between upstream and user, request that the user take control of the upstream bug to streamline the rest of the flow. N could be 1 or 2, for instance. --- Drake Wilson -- 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/20110112031934.ga6...@drache.begriffli.ch
Re: Bug#581434: UPG and the default umask
Quoth Don Armstrong d...@debian.org, on 2010-05-15 14:40:05 -0700: You don't need to detect UPG setups with 100% reliability; you can just do the following: 1. If there a possibility of this being a UPG setup: 2. If this user's group has the same name and GID as the user's name and UID: Hrmbl. I have existing Debian systems that use UPG with UIDs and GIDs decidedly non-matching. It only takes one extra addgroup without a corresponding adduser in the default configuration to make the IDs go out of sync, I think---or at least that's what I've observed with both lenny and current sid. I kind of doubt testing numeric ID equivalence between those two namespaces is a good idea. --- Drake Wilson -- 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/20100515231529.ga31...@drache.begriffli.ch
Re: UPG and the default umask
Quoth Aaron Toponce aaron.topo...@gmail.com, on 2010-05-10 10:40:58 -0600: On 5/10/2010 10:23 AM, Julien Cristau wrote: On Mon, May 10, 2010 at 10:14:00 -0600, Aaron Toponce wrote: Are there reasons for making the switch? With user groups, umask 002 or 022 doesn't make a difference. To switch off user groups, you set USERGROUPS=no in adduser.conf, and that's it. The biggest reason for making the change is when group collaboration becomes a necessity. FWIW (which is probably vanishingly little), I find that dealing with significant group or even inter-user interactions on Unix machines eventually gets nearly impossible in the absence of full POSIX ACL support. Modern Debian supports this well with a suitable filesystem on the backend, though depending on your interop requirements there may be other problems. In this case, the umask problem you mention: Suppose you have an 'devel' group on the system, and a central directory where the collaboration happens. Because of the default umask value being '0022', the users must make sure that they have 'umask 0002' in their shell rc file, or as appropriate, [...] goes away almost entirely if you [setfacl -m d:g::rwx] (or d:g::rx, whichever is appropriate) the central directory. (This still doesn't catch mv'd files, but neither does umask, and that's sort of another kettle of fish.) I regularly set my personal umask to 0077 because I find accidentally creating files that other users can snoop on to be more dangerous than having to chmod files after the fact. Conversely, setting default ACLs is one of the first things I do when setting up collaboration directories. --- Drake Wilson -- 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/20100510172420.ga30...@drache.begriffli.ch
Re: Adoption of Nix?
Quoth Artyom Shalkhakov artyom.shalkha...@gmail.com, on 2008-12-24 17:17:28 +0600: It looks like you completely misunderstood the idea, so lurk before you post. Thanks. Debian List Search, list devel, author match artyom shalkhakov: two matches, all in this thread, not including your most recent two messages, also in this thread. Earliest post date: today. (I'm not a prolific d-d poster myself---mostly a lurker---but I also don't grant myself the social authority to drop lurk before you post on people's heads.) Quoth Artyom Shalkhakov artyom.shalkha...@gmail.com, on 2008-12-24 22:17:35 +0600: That's too bad for you. Shallow thinking doesn't get you anywhere. And a purity war against a huge established packaging system base won't get you much of anywhere either unless you're willing to do an awful lot of the work and demonstrate that the result is both superior in practice and sufficiently continuous that it's not just an entirely different system. (Actually, realistically, I think you're unlikely to get anywhere with this regardless, for other reasons.) Quoth Artyom Shalkhakov artyom.shalkha...@gmail.com, on 2008-12-24 15:08:20 +0600: I would like to accentuate that I seek an informative discussion, not a holy war. Yet I see practical issues being raised, and responses mainly accusing them of completely misunderstanding and shallow thinking. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: renaming scripts provided by upstream
Quoth Ansgar Burchardt ans...@2008.43-1.org, on 2008-12-12 22:30:24 +0100: I understand that it should not matter to the user what language is used to implement a particular script and support omitting extensions. But what about renaming scripts provided by upstream? In this case renaming programs to comply with the Debian naming scheme creates new problems: Not being well-acquainted with this bit, I can't comment very well on what Debian policy would say, but wouldn't using the upstream name plus a non-extensioned symlink solve several of these cases? Ansgar --- Drake Wilson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: volunteers wanted for driving/finalizing a DEP on debian/copyright format
Quoth Miriam Ruiz [EMAIL PROTECTED], on 2008-12-02 21:51:04 +0100: Well, not exactly, you cannot easily see the copyright file before installing the package, can you? p.d.o appears to permit viewing copyright files of packages currently in the archive. As an example: http://packages.debian.org/changelogs/pool/main/g/gnome-games/gnome-games_2.22.3-3/gnome-games.copyright Miry --- Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Screenshots of GUI applications (again)
Quoth Joey Hess [EMAIL PROTECTED], on 2008-07-23 12:45:03 -0400: I don't buy that a screenshot without window decorations somehow looks funny. One data point: a screenshot with no window decorations loses a small amount of information, primarily the caption used for the window. Interesting ways of working around this might involve storing the caption as metadata, or storing the screenshot with decorations and then storing the rectangle corresponding to the client area as metadata. --- Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Screenshots of GUI applications (again)
Quoth Stefano Zacchiroli [EMAIL PROTECTED], on 2008-07-24 00:33:01 +0200: On Wed, Jul 23, 2008 at 11:53:14AM -0500, Drake Wilson wrote: One data point: a screenshot with no window decorations loses a small amount of information, primarily the caption used for the window. Interesting ways of working around this might involve storing the caption as metadata, or storing the screenshot with decorations and then storing the rectangle corresponding to the client area as metadata. You are assuming one application = one window, aren't you? Well, there's a difference between one application is one window and one screenshot is one window; if you have multiple windows in a single screenshot then you have to have the decorations so that you can tell them apart, so none of the above comes into play. But yes, I think the thread is wandering somewhat, so I'll shut up now. :-) --- Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#490805: ITP: txtreader -- text reader, mainly used for reading text originally novels
Quoth Chris Bannister [EMAIL PROTECTED], on 2008-07-19 00:44:04 +1200: On Mon, Jul 14, 2008 at 08:23:27PM +0800, LI Daobing wrote: Description : text viewer, mainly used for reading text originally novels Do you mean: Description : text viewer, mainly used for reading text of original novels I would more expect text viewer, originally used for reading novels. text viewer, mainly used for reading text seems fairly redundant to me. --- Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unifont - consensus on dependencies
Quoth [EMAIL PROTECTED], on 2008-06-22 10:02:15 -0700: If I must convert that to PCF it will add a dependency (on bdftopcf) that doesn't exist today. Must I never install the BDF font, but add a dependency for bdftopcf and only install a gzipped PCF version? Are you confusing Depends and Build-Depends? I'm not sure why installing PCF versions of fonts would require a Depends link; can the conversion not be done at package build time? A user who wants to use the PCF versions of the fonts wouldn't need bdftopcf, only someone who wanted to modify some glyphs and then rebuild the PCF files, right? I would tend to assume that Build-Depends: xfonts-utils is reasonable if BDF is used as an intermediary format. I see 93 packages (according to [apt-rdepends -r -f Build-Depends xfonts-utils]) that currently have that link, mostly also packages of fonts. The Debian Policy Manual does not list a directory under /usr/share/fonts/X11 for TrueType fonts. I plan to have the font be in the main/x11 Debian section, and so would like the TrueType version of the font installed under the X11 hierarchy. FWIW, various ttf-* packages that are also in the x11 section use the /usr/share/fonts/truetype directory for this; see for example ttf-bitstream-vera or ttf-freefont. 3) I'm using scripts originally written by Luis Gonzalez Miranda to convert unifont.hex files into TrueType using FontForge. Therefore I do intend to add a dependency on FontForge. There's no way around that dependency to produce the TrueType version. Again, an installed package Depends or only a Build-Depends? Is there any software still in common use that will not handle TrueType fonts? Apparently Debian no longer has support for any software that only supports BDF fonts instead of PCF fonts, so it wouldn't be considered experimental to remove a BDF font. Depending on how large the files are, I wonder whether a split package (from the same source package) with one package containing TrueType fonts and the other containing PCF fonts would be reasonable. Just a thought. --- Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unifont - consensus on dependencies
Quoth [EMAIL PROTECTED], on 2008-06-22 12:04:53 -0700: Is it best to add Build-Depends: xfonts-utils even if all a package needs from xfont-utils is bdftopcf? If you need bdftopcf to build, and bdftopcf is in xfonts-utils, I don't see another way to do it than Build-Depending on xfonts-utils unless you want to look for alternative tools or something. I am aware of the /usr/share/fonts/truetype directory. I've been running Sarge, and it is there. However, that is not under the X11 fonts tree. If I place a font in /usr/share/fonts/truetype, is it still legitimate to claim a font as being in section main/x11? If not, then there's a big pile of ttf-* packages in sid that have incorrect packaging. Since the Policy Manual is silent on this, I'd expect that to be the correct place to install TrueType fonts from a package in the x11 section, though I can't find authoritative documentation to that effect from a cursory search. I could conceivably create multiple packages, for example: - the TrueType font (most people will probably just want this and nothing else); this could be called unifont-ttf - All sources to build the unifont.hex, TrueType, PCF, and BDF versions of the font; this package could be called unifont De facto practice in the archive suggests that the TrueType package be called ttf-unifont, the PCF-only package be called xfonts-unifont, and the source package be called unifont (noting that the source package and built package namespaces are somewhat orthogonal to each other). I could have the unifont package contain the pre-built TrueType font plus all sources. It takes about an hour plus 1 Gigabyte of virtual memory to build the TrueType version with FontForge. Normally you don't provide sources in built packages unless there's a specific reason for it, as far as I know. Users can get sources using [apt-get source] or similar to retrieve the source packages. I'm not sure what effect a highly-intensive build process like that has on the autobuilder network; presumably that can be answered by someone more knowledgeable than me, but it's something you'd want to consider. In that case there wouldn't be a Build-Depends for bdftopcf. (Note that there is no way to Build-Depend on bdftopcf, because that's not a package nor a Provides that I see anywhere. You once again mean xfonts-utils, I suppose.) I put work into getting the combining characters working properly (with zero width) in the TrueType version. The BDF version doesn't have that capability, and so neither would a PCF version. That would be useful information for the package descriptions; that doesn't preclude packaging both versions. I would tend to default to packaging both versions, assuming they come from the same source, unless there's a good reason not to package the PCF version. How large are the PCF files? (I didn't see that information in your last message; if it was there, I apologize.) Is there a significant difference in the _source_ size if you reduce it to only the information needed to build the TrueType fonts, or is most of the information shared? I would tend to imagine the latter for a package of this nature. Paul Hardy [EMAIL PROTECTED] GPG Key ID: E6E6E390 --- Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#487317: perl-modules: File::Path::rmtree sets symlink target permissions to 0777
Quoth Ben Hutchings [EMAIL PROTECTED], on 2008-06-20 23:36:51 +0100:
debsums is doing it:
[strace elided]
It looks like it's unpacking the archive under /tmp, generating
checksums, then deleting the files as it goes. Before unlinking it uses
chmod, presumably to ensure the unlink will succeed. But chmod follows
sym-links, and these sym-links are absolute so it chmods the installed
files!
...and a little investigation shows debsums is just using File::Path::rmtree.
The rmtree implementation actually tries to avoid this, but does it
wrong: it _reads_ the permissions from the symbolic link, then
_applies_ changed permissions through chmod, which affects the target
instead.
It looks like this bug isn't as severe in perl-modules 5.8.8-12. The
relevant lines of code appear to be:
From perl-modules 5.8.8-12 /usr/share/perl/5.8.8/File/Path.pm:
|chmod $rp | 0600, $root
| or carp Can't make file $root writeable: $!
|if $force_writeable;
From perl-modules 5.10.0-10 /usr/share/perl/5.10.0/File/Path.pm:
|my $nperm = $perm 0 | 0600;
|if ($nperm != $perm and not chmod $nperm, $root) {
|if ($Force_Writeable) {
|_error($arg, cannot make file writeable, $canon);
|}
|}
As can be seen above, the version from 5.8.8-12 only does the
erroneous chmod if $force_writeable is turned on, whereas the version
from 5.10.0-10 does the erroneous chmod in all cases where the target
is a symbolic link.
FWIW, I have a live report of this affecting more than terminfo on my
machine, drache (as a partial confirmation of the analysis):
-rwxrwxrwx 1 root root 194924 2008-06-01 06:44
/emul/ia32-linux/lib/libncurses.so.5.6
-rwxrwxrwx 1 root root69560 2008-06-01 06:44
/emul/ia32-linux/lib/libtic.so.5.6
-rwxrwxrwx 1 root root 248288 2008-05-06 07:33 /lib/libncurses.so.5.6
-rwxrwxrwx 1 root root74128 2008-05-06 07:33 /lib/libtic.so.5.6
The other servers I coadminister don't seem to be affected, presumably
because they don't have the new perl-modules.
Possibly it would be a good idea to tell people to run something
similar to [find roots of real filesystems -xdev -not -type l -perm
/o=w] to find files that may have been affected by this if they had a
buggy version of perl-modules installed. Possibly an automated check
for bad permissions on files that exist in Debian packages would be
another improvement (I searched the Web for an existing program that
does that, but didn't find anything).
--- Drake Wilson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#487317: perl-modules: File::Path::rmtree sets symlink target permissions to 0777
Quoth Russ Allbery [EMAIL PROTECTED], on 2008-06-21 09:29:33 -0700:
There's an lchmod function that avoids this behavior, but I'm not sure
that Perl provides an interface to it without a new XS module. (It's not
portable to all systems, but it is available on Linux.)
I'm basically familiar with lchmod, but is it really available on this
platform? It doesn't seem to be. With Debian GNU/Linux unstable on
AMD64 with Linux 2.6.24.2 and GCC 4.3.1 20080523 (prerelease) (Debian
4.3.0-5), I get the following results (newlines added for clarity):
$ ln -s /dev/null foo
$ ls -l foo
lrwxrwxrwx 1 drake drake 9 2008-06-21 12:27 foo - /dev/null
$ man 2 lchmod
No manual entry for lchmod in section 2
$ man 3 lchmod
No manual entry for lchmod in section 3
$ cat lchmod.c
main() { lchmod(foo, 0700); }
$ gcc -o lchmod lchmod.c
/tmp/cc478IUh.o: In function `main':
lchmod.c:(.text+0x18): warning: warning: lchmod is not implemented and will
always fail
$ ./lchmod
$ ls -l foo
lrwxrwxrwx 1 drake drake 9 2008-06-21 12:27 foo - /dev/null
$ gcc -static -o lchmod lchmod.c
/tmp/ccqjaRGU.o: In function `main':
lchmod.c:(.text+0x18): warning: warning: lchmod is not implemented and will
always fail
$ strace ./lchmod
execve(./lchmod, [./lchmod], [/* 40 vars */]) = 0
uname({sys=Linux, node=drache, ...}) = 0
brk(0) = 0x68b000
brk(0x68bf10) = 0x68bf10
arch_prctl(ARCH_SET_FS, 0x68b850) = 0
brk(0x6acf10) = 0x6acf10
brk(0x6ad000) = 0x6ad000
exit_group(-1) = ?
Process 16730 detached
--- Drake Wilson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
