Re: DD needing a sponsor to upload
On Sun, Feb 06, 2005 at 01:01:47AM +0100, Nicolas Boullis wrote: >Hi, > >As I moved recently, I currently have no decent Internet connectivity. >Hence, I'm quite unable to keep an unstable system up-to-date, si I >can't build packages to upload. Several packages of mine are in need of >an upload, especially libcdio and vcdimager. I have uploaded the source >packages to my debian homepage on http://people.debian.org/~nboullis. >Could someone please build the binary packages and upload for me? >(As far as I know source-only uploads are not allowed, and anyway, I >can't be sure it'll work fine with an up-to-date sid; I only tested with >a one month old sarge.) Changes: vcdimager (0.7.21-1) unstable; urgency=low . * New upstream release. * Rebuild against libcdio3 and libiso9600-3. * Hack ltmain.sh to build programs with rpath as .libs/lt/foobar rather than .libs/lt-foobar. * Regenerate the manpages accordingly. Does the new vcdimager version fix the RC bug #290685? >Thanks in advance, > >Nicolas Boullis > >PS: please CC your replies to me (MFT set accordingly) as I currently >can't track d-d. Anibal Monsalve Salazar -- .''`. Debian GNU/Linux : :' : Free Operating System `. `' http://debian.org/ `- http://v7w.com/anibal signature.asc Description: Digital signature
Re: Inconsistent naming of ethernet interfaces...
On Feb 06, salman h <[EMAIL PROTECTED]> wrote: > In the future, if I swap out my dual NIC with a newer > one, I'd like a way to be able to produce the new > mappings automatically. Perhaps I could do it like apt-get install udev or apt-get install guessnet -- ciao, Marco signature.asc Description: Digital signature
Re: apply to NM? ha!
On Monday 31 January 2005 16:16, Anthony Towns wrote: > >>1) - a community where people are pleasant to each other, where > >>disagreements are discussed politely, and where people who are unable to > >>be civil are not glorified for their behaviour. > > > > This isn't too far from the situation we have. > > Really? A moment ago you were saying that flaming a polite, competent > coder was a respectable way to become famous. Flaming competent coders can be a quick way to become infamous. Read my messages again and you will discover that I did not say that flaming good coders makes anyone famous, just that good coders can generally ignore the idiots. > In any case, mere civility is a woefully low bar to set. Is there really > some reason Debian shouldn't be an absolute pleasure to be involved in, > ubiquitously and continually? Perhaps we can't hope to never receive > nasty comments from outsiders, but is there any particular reason we > can't make our development forums technical, productive, kind, and > generous? While we have an open posting policy for the Debian lists with no moderation it is impossible to have "kind and generous" lists. Make all posting by non-subscribers moderated (and all postings to this list by non-DDs moderated) and have a set of rules for posting that are enforced and there might be an improvement. With such a system the post that started this thread would not have gone to the list and would instead have received a message from a moderator explaining why it's a bad message to send to the list. However such changes are extremely unlikely to happen. But even enforcing rules about posting won't necessarily make the lists "kind and generous". Some lists and forums that I have read which have such behavior rules are filled with posts that try to get as close as possible to the line without crossing it. However to get the result that one flame might get they use a series of more subtle attacks carried out over a period of weeks or months. The end result is often a cold-war in the list which can over the period of years end in a split in the community. One list that I am on has had two such splits over the course of a few years due to on-going subtle attacks which didn't quite break the rules. Two forums that I have lurked on have had cold wars that greatly exceed the scope of anything that happens on the Debian lists (they ended up having PCs hacked, lawyers called in, and lots of other nasty stuff). Finally even if you prevent flame wars and cold wars in the community that doesn't mean that things will always be working well. In some communities there are no flames so people who offend others just get ostracised. The problem with that is that every time you are late replying to an email the other person might think that you hate them. It's really annoying when someone thinks that I have a grudge against them just because their email is in my queue of 5000 messages that need to be read. PS I've been in discussion with the originator of this thread off-list. He seems OK now that he's calmed down, and doesn't seem likely to lose it again in that manner. He'll probably end up becoming a DD if given a chance. Things seemed to work out OK in this instance. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debug packages cluttering the archive
El dom, 06-02-2005 a las 01:14 -0500, Glenn Maynard escribiÃ: > On Sat, Feb 05, 2005 at 10:33:53PM -0700, Joel Aelwyn wrote: > > It was brought up on IRC, a couple of weeks ago (my apologies, but I don't > > recall who brought it up, nor do I have a log) that it is now possible > > to strip debugging information from a binary or library, and keep the > > debugging information in a separate file. When invoking GDB (I don't know > > Wow. I've wanted this for a while, and VC has done it for years (at least > since 1998)--it's a little disappointing that this has apparently been > around for a couple years and still isn't mainline (/usr/bin/strip shows > no sign of the -f option mentioned in the info page found from your > google search). I had no idea it was even implemented, though. > > (Aha: the strip tool mentioned is in elfutils, which is non-free. Blah.) dh_strip does that. (man dh_strip) We are using it for generating -dbg packages for both pwlib and openh323, reducing their size in a factor of 35, and also speeding up compilation, as no other libs must be rebuilt. Regards, -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: About valid and invalid user names
On Sat, 05 Feb 2005 13:38:36 +0100, Marc Haber <[EMAIL PROTECTED]> wrote: >adduser has two bug reports open where people are asking for user name >rules to be relaxed. One report wants "." to be allowed in user names, >another wants usernames to start with numbers. > >May I ask for your opinion before denying or following the requests? After the discussion, I am now inclined to do the following: By default, adduser will verify the user against a configurable regexp, default being the most conservative ^[a-z][a-z0-9\-]*$. The --force-badname option will change the regexp to a hardcoded ^[-\._A-Za-z0-9]*\$?$, allowing users to happily hang themselves. This gives the somewhat funny situation that the default can be configured to be less restrictive than --force-badname, but I doubt that it would be sensible to have --force-badname turn off all checks. Your opinion? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Debug packages cluttering the archive
On Sat, 5 Feb 2005 22:33:53 -0700, Joel Aelwyn <[EMAIL PROTECTED]> wrote: >1) It would become possible (I'm not sure if it would be *sane*) to >include debugging information for all binaries and libraries in a fairly >straightforward manner - and one which could target a directory that, like >/usr/share/doc or others, can safely be purged by the local admin if they >don't want the disk bloat. I would not like to see this in Debian before dpkg can be configured to exclude subtrees (like /usr/share/doc, for example) from installation. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: About valid and invalid user names
* Marc Haber: > By default, adduser will verify the user against a configurable > regexp, default being the most conservative ^[a-z][a-z0-9\-]*$. The > --force-badname option will change the regexp to a hardcoded > ^[-\._A-Za-z0-9]*\$?$, allowing users to happily hang themselves. This > gives the somewhat funny situation that the default can be configured > to be less restrictive than --force-badname, but I doubt that it would > be sensible to have --force-badname turn off all checks. The current --force-badname check is /^[A-Za-z_][-_A-Za-z0-9]*\$?$/. Wouldn't it make more sense to add the "." just to the second character class? User names starting with "-" could be truly awful. Even if a custom regular expression has been configured, you should check for "\n" and ":" in user names and reject them, just to be sure (and maybe a few more funny characters). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: About valid and invalid user names
On Sun, 06 Feb 2005 12:31:39 +0100, Florian Weimer <[EMAIL PROTECTED]> wrote: >The current --force-badname check is /^[A-Za-z_][-_A-Za-z0-9]*\$?$/. >Wouldn't it make more sense to add the "." just to the second >character class? That one wouldn't solve the "I want my usernames to start with a digit" issue. > User names starting with "-" could be truly awful. But a local problem, in that case. >Even if a custom regular expression has been configured, you should >check for "\n" and ":" in user names and reject them, just to be sure >(and maybe a few more funny characters). Just being sure will prompt strange bug reports. There is always useradd doing its own checks behind though. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: [Pre-RFA] Intending to drop twenty-some packages
* Dirk Eddelbuettel | | - time (dead upstream) | | -- picked up by Tollef (no new upload yet). Thanks, Tollef! Just uploaded. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debug packages cluttering the archive
Le samedi 05 février 2005 à 22:33 -0700, Joel Aelwyn a écrit : > It was brought up on IRC, a couple of weeks ago (my apologies, but I don't > recall who brought it up, nor do I have a log) that it is now possible > to strip debugging information from a binary or library, and keep the > debugging information in a separate file. > Switching dh_strip to use this would provide a number of benefits: This is already the case. > 2) Even if only applied to -dbg packages, it would make -dbg packages > significantly smaller (only needing the debug symbols file, not a complete > secondary copy of the library). Significantly smaller, but not enough. See for example a library using it: Package: libfontconfig1 Installed-Size: 192 Size: 89824 Package: libfontconfig1-dbg Installed-Size: 517 Size: 158768 I wouldn't say it can be included in the library package as is. And doing it for all libraries would still clutter the archive. > 3) Allows you to generate a -dbg package without doing a second build-run > over the libraries or having to do strange convolutions to package both > stripped and unstripped libraries without duplicating the build. > > 4) Allows you to use debugging on any library without having to restart > the application with a suitable LD_LIBRARY_PATH (nor does it run afoul of > things that muck with library search paths or don't permit the environment > to override it for security reasons). This brings a lot of benefits, and that's why dh_strip now supports it, but I'm afraid this is irrelevant to the issue I'm talking about. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Debug packages cluttering the archive
On Sun, Feb 06, 2005 at 01:14:09AM -0500, Glenn Maynard wrote: > On Sat, Feb 05, 2005 at 10:33:53PM -0700, Joel Aelwyn wrote: > > It was brought up on IRC, a couple of weeks ago (my apologies, but I don't > > recall who brought it up, nor do I have a log) that it is now possible > > to strip debugging information from a binary or library, and keep the > > debugging information in a separate file. When invoking GDB (I don't know > > (Aha: the strip tool mentioned is in elfutils, which is non-free. Blah.) You can do this with strip and objcopy, see the manpage for --only-keep-debug Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debug packages cluttering the archive
On Sun, Feb 06, 2005 at 01:14:09AM -0500, Glenn Maynard wrote: > (Aha: the strip tool mentioned is in elfutils, which is non-free. > Blah.) objcopy(1): --only-keep-debug Strip a file, removing any sections that would be stripped by --strip-debug and leaving the debugging sections. The intention is that this option will be used in conjunction with --add-gnu-debuglink to create a two part executable. One a stripped binary which will occupy less space in RAM and in a dis- tribution and the second a debugging information file which is only needed if debugging abilities are required. The suggested proce- dure to create these files is as follows: 1. "foo" then... 1. create a file containing the debugging info. 1. stripped executable. 1. to add a link to the debugging info into the stripped exe- cutable. Note - the choice of ".dbg" as an extension for the debug info file is arbitrary. Also the "--only-keep-debug" step is optional. You could instead do this: 1. 1. 1. 1. ie the file pointed to by the --add-gnu-debuglink can be the full executable. It does not have to be a file created by the --only-keep-debug switch. -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apply to NM? ha!
Russell Coker wrote: On Monday 31 January 2005 16:16, Anthony Towns wrote: 1) - a community where people are pleasant to each other, where disagreements are discussed politely, and where people who are unable to be civil are not glorified for their behaviour. This isn't too far from the situation we have. Really? A moment ago you were saying that flaming a polite, competent coder was a respectable way to become famous. Flaming competent coders can be a quick way to become infamous. Read my messages again and you will discover that I did not say that flaming good coders makes anyone famous, just that good coders can generally ignore the idiots. What you said was ] Some people are (in)famous for nothing in their lives apart from ] flaming a good Linux programmer. -- http://lists.debian.org/debian-devel/2005/01/msg01836.html And frankly you were right the first time -- it can be both, but either way it's a good way to make a name for yourself. Rewarding bad behaviour just creates more of it. Even just tolerating it reduces good behaviour -- by encouraging the people who won't tolerate to leave. In any case, mere civility is a woefully low bar to set. Is there really some reason Debian shouldn't be an absolute pleasure to be involved in, ubiquitously and continually? Perhaps we can't hope to never receive nasty comments from outsiders, but is there any particular reason we can't make our development forums technical, productive, kind, and generous? While we have an open posting policy for the Debian lists with no moderation it is impossible to have "kind and generous" lists. While we're unwilling to provide any reward for good behaviour, or any punishment for bad behaviour (except in the form of further bad behaviour -- ie, flaming the flamer), things aren't going to change, certainly. Make all posting by non-subscribers moderated (and all postings to this list by non-DDs moderated) and have a set of rules for posting that are enforced and there might be an improvement. And there are certainly far more options than just that one. However such changes are extremely unlikely to happen. They certainly won't happen unless someone makes them happen. But even enforcing rules about posting won't necessarily make the lists "kind and generous". Fundamentally, "kind and generous" isn't about "enforcing rules". I realise we're all programmers, and "enforcing rules" is the terms in which we think; but no set of rules is remotely sufficient to get people to be kind and generous in /any/ circumstances. And yet, that doesn't imply that kindness and generosity are impossible. The point of any rules, or moderation, or whatever is to /encourage/ good behaviour, and discourage bad behaviour. One very simple class of behaviour that's easily divided into good and bad is on-topic and off-topic posting; and yet our rewards and punishments are pretty much inversed for those. The response to that scenario is pretty predictable; and I don't think your posting history is remotely alone in reflecting it. But if we've got lots of bad outcomes, how do we resolve them? I don't think it's reasonable to blame you personally for your signal:noise ratio; personally I think you're exactly the sort of person who should be participating in -devel. And in any case, you're far from alone. Some lists and forums that I have read which have such behavior rules are filled with posts that try to get as close as possible to the line without crossing it. However to get the result that one flame might get they use a series of more subtle attacks carried out over a period of weeks or months. That's a nice theory, but if you look at -devel, it's fairly rare that "one flame" gets a result, and we usually spend months or years going over the issue anyway. Finally even if you prevent flame wars and cold wars in the community that doesn't mean that things will always be working well. That things won't be working perfectly forever, doesn't say anything about whether it's worth trying to make them better. That some solutions aren't adequate doesn't imply that no solution will ever be adequate, either. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debug packages cluttering the archive
Josselin Mouette wrote: > The most obvious solution I can come up for this issue is to build a > separate tree with DEB_BUILD_OPTIONS="noopt nostrip", at least for i386. > That means having a dedicated machine that would be used to run a buildd > for that. Unfortunately, I don't have such a machine, and I don't know > of an available i386 project machine. > > Are there some people here who'd be interested, or who could point me to > available resources? If not, do you have other ideas to make debugging > packages easily available? My feeling for some time has been that we should introduce a separate section in the archive, or a separate archive and come up with the infrastructure to upload -dbg packages to there, with separated debugging symbols in them (see dh_strip). This could be done for nearly all binary packages, not just libraries. Then people who want all the -dbg packages available can just add an apt line and install them at will. This could be done with varying levels of support in the official archive. Ideally we could just upload -dbg packages and have katie split them out into a separate section and generate Packages files for that. However like the data section I don't know if this is likely to ever happen, very few people are able to set it up. It would be nice if we could set up a third party site first that collects the packages, but it's hard to do because ideally you want to get -dbg packages from the autobuilders too, and you don't want them to hit the regular archive. The approach that seems IMHO to be most likely to be doable is to modify katie to ignore the -dbg packages in Incoming, not add them to the main archive, and shunt them to a holding directory, and then set up a separate archive to hold them, either on a debian machine or a debian.net machine and tie this in so it gets new -dbg packages from the holding directory. -- see shy jo signature.asc Description: Digital signature
Re: not starting packages at boot
On Fri, Jan 21, 2005 at 12:09:42PM +0800, Dan Jacobson wrote: > Now that maintainers realized that one might like a package installed, > but perhaps only plans to use it unoften, it only makes sense for not > starting at boot to be offered as a friendly configuration option, > instead of needing some devious guerilla techniques to thwart the > packages starting. For packages I maintain that provide system services, I use another solution than making it a configuration option. The packages are split into a package providing the programs, and a -run package providing the service. Users that don't want the service to be enabled by default simply don't install the -run package. This additionally has an advantage concerning virtual packages representing a system service, such as ftp-server, mail-transport-agent, system-log-daemon, or imap-server. Here's the rationale from the bincimap-run package: $ sed -ne '18~1p' , Fri, 17 Oct 2003 07:45:52 + $ Regards, Gerrit. -- Open projects at http://smarden.org/pape/. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
apt-deb: [was Re: Always run dpkg --dry-run -i before running dpkg -i!]
a long time ago, in a thread far, far away... Michelle Konzack wrote: > What about > > dpkg-scanpackages . /dev/null >Packages > > in the same directory and entering the informations > in "/etc/apt/sources.lists" ? > > After an "apt-get update" you can use "apt-get install" > to get your package running William Ballard wrote: > That's a good idea. Thanks! I wrote a shell script to do this called "apt-deb". It turned out a bit complex / ugly in the end! It appears to work ok. You can get it at http://nipl.net/hacks/apt-deb Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: About valid and invalid user names
On Sun, 2005-02-06 at 12:15 +0100, Marc Haber wrote: > By default, adduser will verify the user against a configurable > regexp, default being the most conservative ^[a-z][a-z0-9\-]*$. The > --force-badname option will change the regexp to a hardcoded > ^[-\._A-Za-z0-9]*\$?$, allowing users to happily hang themselves. This > gives the somewhat funny situation that the default can be configured > to be less restrictive than --force-badname, but I doubt that it would > be sensible to have --force-badname turn off all checks. How about adding an additional check to the code path without --force-badname that checks that the username is a valid POSIX username. That is, make it check against the configurable regexp only when --force-badname is not given, and against the hardcoded one in both occasions. This would avoid the "funny situation" and not break any POSIX-following tools. -- Petri Latvala signature.asc Description: This is a digitally signed message part
Re: DD needing a sponsor to upload
Hi, On Sun, Feb 06, 2005 at 08:53:52PM +1100, Anibal Monsalve Salazar wrote: > Changes: > vcdimager (0.7.21-1) unstable; urgency=low > . >* New upstream release. >* Rebuild against libcdio3 and libiso9600-3. >* Hack ltmain.sh to build programs with rpath as .libs/lt/foobar rather > than .libs/lt-foobar. >* Regenerate the manpages accordingly. > > Does the new vcdimager version fix the RC bug #290685? You're quite right, I somehow forgot the Closes: parts in the changelog... I just reuploaded the source package. Would you build and upload for me? Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
removing problemes with deluser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I found a bug with adduser package that deluser will remove system directories like /bin (or like / as other user found). This will happen if the homedirectory is /bin of some system accounts which should be removed and the option REMOVE_HOME in /etc/deluser.conf is set to 1. This Bug / Problem renders the system unusable so the severity is critical. The (co-)maintainer see this as only wishlist and told me to complain about this in this list. Maybe the Severity of critical is not absolutely correct and should be important. (I think, it is.) But the severity of wishlist is impossible! More over as also other Users have had the same problem and see it similar to me. Maybe it is not a bug of deluser than of the debian police but it is a critical bug. The both bug reports are: #293559 and #271829 Please reply to fix the problem as soon as possible. Regards Klaus Ethgen Ps. For me the bug is not a problem anymore as I do not do use deluser anymore and remove a user by hand with vipw. But I do not think that the problem is gone therewith as for other users the problem still sleeps until they trigger the problem. - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]> Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iQEVAwUBQgZG35+OKpjRpO3lAQL6hwgAorbNOFy7/sJpn9hpt6beo8NFoOAmOQ0E uFgx0FfwVB0GMc3SEuHDWUuORPTGyYNNPOx75CfLJujvC8tfi9mOsmBBhvOb6WiB L32mijWXsuva7Loa9TZlI39ysq4fgV4lpLkvC0jddk3A/L4huO+r+d4b4qT6OCKH EH6CTS/OHb9K9WTz+++qghl26t14awz6qQkLcz4RkI8k0Pr2LAYcvbZ2j+YPpLNQ VIHHkf7z6cF9n1/8H8cKdMnZWgXgQgDgbR9Kv8PtPn/avymC+XjQHa82GQEDMGjK ivZcW0BGnTwmRgcGP2yZpFuO4tKxCh+bnlVgz+qKpeAshCEasiGU2A== =MHiE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Why didn't #290810 hold eximdoc4 from sarge?
Hi, #290810 was filed to keep eximdoc4 from moving to sarge. However, after reaching the proper age, eximdoc4 moved to sarge despite of the bug. What did we do wrong? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: About valid and invalid user names
On Sun, 06 Feb 2005 18:06:17 +0200, Petri Latvala <[EMAIL PROTECTED]> wrote: >On Sun, 2005-02-06 at 12:15 +0100, Marc Haber wrote: >> By default, adduser will verify the user against a configurable >> regexp, default being the most conservative ^[a-z][a-z0-9\-]*$. The >> --force-badname option will change the regexp to a hardcoded >> ^[-\._A-Za-z0-9]*\$?$, allowing users to happily hang themselves. This >> gives the somewhat funny situation that the default can be configured >> to be less restrictive than --force-badname, but I doubt that it would >> be sensible to have --force-badname turn off all checks. > >How about adding an additional check to the code path without >--force-badname that checks that the username is a valid POSIX username. >That is, make it check against the configurable regexp only when >--force-badname is not given, and against the hardcoded one in both >occasions. This would avoid the "funny situation" and not break any >POSIX-following tools. Nice idea. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: removing problemes with deluser
On Sun, 6 Feb 2005 17:33:35 +0100, Klaus Ethgen <[EMAIL PROTECTED]> wrote: >This Bug / Problem renders the system unusable so the severity is >critical. The (co-)maintainer see this as only wishlist and told me to >complain about this in this list. See adduser 3.60 from the experimental distribution. Excerpt from the changelog: | * Add a new config option NO_DEL_PATHS to deluser.conf with a | sensible default in the deluser source code. In the default | configuration, deluser will not zap any important system directories | any more. Thanks to Ernst Kloppenburg and Klaus Ethgen. (mh) | Closes: #293559, #271829 You should have received this in a "fixed-in-experimental" message from the BTS after I uploaded the new version. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Debug packages cluttering the archive
Joey Hess <[EMAIL PROTECTED]> writes: > Josselin Mouette wrote: >> The most obvious solution I can come up for this issue is to build a >> separate tree with DEB_BUILD_OPTIONS="noopt nostrip", at least for i386. >> That means having a dedicated machine that would be used to run a buildd >> for that. Unfortunately, I don't have such a machine, and I don't know >> of an available i386 project machine. >> >> Are there some people here who'd be interested, or who could point me to >> available resources? If not, do you have other ideas to make debugging >> packages easily available? > > My feeling for some time has been that we should introduce a separate > section in the archive, or a separate archive and come up with the > infrastructure to upload -dbg packages to there, with separated > debugging symbols in them (see dh_strip). This could be done for nearly > all binary packages, not just libraries. Then people who want all the > -dbg packages available can just add an apt line and install them at > will. The packages could end up in main-dbg, contrib-dbg, non-free-dbg. The dpkg-dev package could be patched to put -dbg packages there automatically and Katie would just follow the changes file. Or packages could just change their control file (alowing for some test packages to do it first). Alternatively debug packages could be in binary--dbg and the dpkg/apt multiarch patches can be used to include/exclude that tree. dpkg-dev needs some patching to allow multiarch uploads (uploads with debs for more than one arch) but thats on the TODO list anyway. This would have the advantage that SCC would allow to mirror the debug packages only to some mirrors, e.g. only an eperimental mirror. > This could be done with varying levels of support in the official > archive. Ideally we could just upload -dbg packages and have katie split > them out into a separate section and generate Packages files for that. If dpkg-dev mangles the architecture or section to *-dbg then all katie needs is those extra archs/sections in the config file. So adding support to the software would be trivial. Convincing ftp-master might be the problem. > However like the data section I don't know if this is likely to ever > happen, very few people are able to set it up. It would be nice if we > could set up a third party site first that collects the packages, but > it's hard to do because ideally you want to get -dbg packages from the > autobuilders too, and you don't want them to hit the regular archive. > > The approach that seems IMHO to be most likely to be doable is to modify > katie to ignore the -dbg packages in Incoming, not add them to the main > archive, and shunt them to a holding directory, and then set up a separate > archive to hold them, either on a debian machine or a debian.net machine > and tie this in so it gets new -dbg packages from the holding directory. That sounds more complicated then just alowing them in the normal way as extra arch or section. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debug packages cluttering the archive
On Sun, Feb 06, 2005 at 08:52:28AM -0500, Joey Hess wrote: > My feeling for some time has been that we should introduce a separate > section in the archive, or a separate archive and come up with the > infrastructure to upload -dbg packages to there, with separated > debugging symbols in them (see dh_strip). This could be done for nearly > all binary packages, not just libraries. Then people who want all the > -dbg packages available can just add an apt line and install them at > will. We'll have to do a load of changes to the library packages when we introduce multiarch in etch anyhow; can't we do this at the same time? (Ie.: "New policy says you must follow multiarch, and make -dbg packages in libdevel-dbg"). I fail to see the big point of -dbg for non-libraries, though. Archive bloat is still a problem, though. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing problemes with deluser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Marc, Am So den 6. Feb 2005 um 18:24 schriebst Du: > See adduser 3.60 from the experimental distribution. Excerpt from the > changelog: > > | * Add a new config option NO_DEL_PATHS to deluser.conf with a > | sensible default in the deluser source code. In the default > | configuration, deluser will not zap any important system directories > | any more. Thanks to Ernst Kloppenburg and Klaus Ethgen. (mh) > | Closes: #293559, #271829 > > You should have received this in a "fixed-in-experimental" message > from the BTS after I uploaded the new version. Yes, I have. But this is not the point of my message. I think long bevore if I should write the Mail you told me to do. I whanted to know about the severity as wishlist for such a grave bug (or tell it problem) is not adequate I think. The problem is that who decide what severity is a bug? And isn't it the gravety like descripted in the debian policy that define how grave is a bug? Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]> Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iQEVAwUBQgZYQJ+OKpjRpO3lAQLy9gf+KFSRSgIlqOvtuCCnm+qPlcILnHeMfdG/ yVartCfDE06Ab5GQwTvmOcYydLs1/A/AcsKoi14CgqqkybWPRoPQMNcqE0dT7lLi 7TfI8flPoQwTY7t9YLAO6zhA88YbzfDpnJp3quKMwBsnQKAdZCGp5wpSdr46LB1Y VuZNZ3yRRq5UOLf7BFAoVTgOkSH5bLCZTByghm5TJFEkO/HDz6TIMSZSK1oIBlZO sS0JIIQ7EiiONgZ3Q7ow4/g0Xc4Mgkt/fILsFQ4amFAA1M7ePcgWVNZJYqZcRJxY SjmTczcmu8hevwyVBMRTKwDBq4kIU40pXqtQ1lojrFn9qwgShKUD4w== =isPW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing problemes with deluser
On Sun, 6 Feb 2005 18:47:44 +0100, Klaus Ethgen <[EMAIL PROTECTED]> wrote: >But this is not the point of my message. I think long bevore if I should >write the Mail you told me to do. I whanted to know about the severity >as wishlist for such a grave bug (or tell it problem) is not adequate I >think. The problem is that who decide what severity is a bug? I will leave that explanation to people knowing the project better. The issue that killed your system would not have happened if you had used the default configuration or if you had refrained from trying to remove a default account. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Why didn't #290810 hold eximdoc4 from sarge?
On Sun, Feb 06, 2005 at 05:35:48PM +0100, Marc Haber wrote: > #290810 was filed to keep eximdoc4 from moving to sarge. However, > after reaching the proper age, eximdoc4 moved to sarge despite of the > bug. > > What did we do wrong? You probably did open the bug before the dinstall run that installed the new package. Therefor britney was confused and thought the bug would apply to the package in sarge, too (as at the time it saw the bug the first time the version in sid and sarge were identical). So the package in sid wasn't more buggy than the one in sarge ... Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debug packages cluttering the archive
Steinar H. Gunderson wrote: > On Sun, Feb 06, 2005 at 08:52:28AM -0500, Joey Hess wrote: > > My feeling for some time has been that we should introduce a separate > > section in the archive, or a separate archive and come up with the > > infrastructure to upload -dbg packages to there, with separated > > debugging symbols in them (see dh_strip). This could be done for nearly > > all binary packages, not just libraries. Then people who want all the > > -dbg packages available can just add an apt line and install them at > > will. > > We'll have to do a load of changes to the library packages when we introduce > multiarch in etch anyhow; can't we do this at the same time? (Ie.: "New > policy says you must follow multiarch, and make -dbg packages in > libdevel-dbg"). I fail to see the big point of -dbg for non-libraries, > though. It would be nice to have, especially for debugging huge packages on slow architectures, where a debug build takes a while. > Archive bloat is still a problem, though. Not if mirror admins can select if they want to mirror -dbg. This means: -dbg must be a separate archive. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293903: ITP: pandalex -- a PDF parsing API
Package: wnpp Severity: wishlist * Package name: pandalex Version : 0.5.1 Upstream Author : Michael Still <[EMAIL PROTECTED]> and contributors * URL : http://stillhq.com/extracted/pandalex.tgz * License : GPL Description : a PDF parsing API Pandalex is a library containing a lex/yacc based parser for PDF. Programs make use of the library by registering callback hooks that the parser calls at various points of the parse. . This is intended as a first step toward writing The PDF Reader That Doesn't Suck (TM). -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-12custom2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#293688: ITP: ttf-tibetan -- A Unicode OpenType font for Tibetan, Dzongkha and Ladakhi
On Sat, 5 Feb 2005 [EMAIL PROTECTED] wrote: > A freely available Tibetan Machine Uni font from the THDL project > (http://www.thdl.org/). The font contains almost 4,000 glyphs and can generate > over 20,000 different combinations with full support for the Sanskrit > combinations found in chos skad texts. > Do you need a sponsor? -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library packaging doc...
On Sat, Feb 05, 2005 at 10:46:27PM +0900, Junichi Uekawa wrote: > Hi Joey > > > > > > > Just request to [EMAIL PROTECTED] while pointing them our message on > > > this list. > > > > Or see and follow the instructions summarised on > > http://master.debian.org/~joey/misc/webwml.html#ddp > > > According to the page you pointed to, it seems to tell me > that I should send request to you, > after approval of debian doc people. Yes. But I thought previous discussion omplicitly gave you a status of being part of debian-doc. > Hereby I am sending a request. Just to be sure... hereby agreeing and requesting him a part of the group. > I consider that with this thread debian-doc people have given approval. Good luck. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why didn't #290810 hold eximdoc4 from sarge?
On Sun, 6 Feb 2005 19:38:58 +0100, Frank Lichtenheld <[EMAIL PROTECTED]> wrote: >On Sun, Feb 06, 2005 at 05:35:48PM +0100, Marc Haber wrote: >> #290810 was filed to keep eximdoc4 from moving to sarge. However, >> after reaching the proper age, eximdoc4 moved to sarge despite of the >> bug. >> >> What did we do wrong? > >You probably did open the bug before the dinstall run that installed >the new package. Therefor britney was confused and thought the bug would >apply to the package in sarge, too (as at the time it saw the bug the >first time the version in sid and sarge were identical). So the package >in sid wasn't more buggy than the one in sarge ... I see. So we will wait two days before filing the dummy bug on eximdoc4 next time. Thanks for enlightening. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#293930: ITP: aefirion -- A Class5 SoftSwitch.
Package: wnpp Severity: wishlist * Package name: aefirion Version : 0.0.1 Upstream Author : The Aefirion Project <[EMAIL PROTECTED]> * URL : http://www.aefirion.org/ * License : GPL Description : A Class5 SoftSwitch. The Aefirion project aims to develop a telecommunications switch that can be classified as Class5, which means that it should eventually be nearly NEBS compliant. It is intended to be a rock solid gateway rather than a super PBX, and focuses on stability and interoperability. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#293930: ITP: aefirion -- A Class5 SoftSwitch.
On Sun, Feb 06, 2005 at 10:49:14PM +0100, Kilian Krause wrote: > Description : A Class5 SoftSwitch. > > The Aefirion project aims to develop a > telecommunications switch that can be classified > as Class5, which means that it should eventually > be nearly NEBS compliant. It is intended to be a > rock solid gateway rather than a super PBX, and > focuses on stability and interoperability. After reading your description, I still have zero idea what this package really is or does. Could it be reworded so people not into telecommunications would have an idea of what it does? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#293688: ITP: ttf-tibetan -- A Unicode OpenType font for Tibetan, Dzongkha and Ladakhi
On Sun, 2005-02-06 at 14:55 -0500, Jaldhar H. Vyas wrote: > Do you need a sponsor? Yes I do, thank you for asking. It may take some time however before I have anything ready for examination and possible upload due to my lack of experience with Debian packaging. But I'm working on it.. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Fri, Feb 04, 2005 at 01:14:09PM +, Brian M. Carlson wrote: > I think this is an awful idea. This means that developers will no longer > test their packages before uploading, and we will have more bugs than > before. Why build X [0] when you don't "have to"? > > [0] No attack on Branden, but it's the largest package I could think > of. You already don't have to build any arch packages, just indep. Its just not widely publicized that it works, oops now it is. ;) I don't know if it was ever actually technically required that you upload arch packages. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293965: ITP: libvideo-ivtv-perl -- Perl extension for using V4l2 in the ivtv perl scripts
Package: wnpp Severity: wishlist Owner: tony mancill <[EMAIL PROTECTED]> * Package name: libvideo-ivtv-perl Version : 0.13 Upstream Author : James A. Pattie <[EMAIL PROTECTED]> * URL : http://sourceforge.net/project/showfiles.php?group_id=73219&package_id=83888 * License : GPL Description : Perl extension for using V4l2 in the ivtv perl scripts The Video::ivtv module will provide helper methods for working with videodev2.h structures and making ioctl calls that have proven to be too difficult to create pack strings for in perl itself. This is not supposed to be an equivalent of the Video::Capture::V4l module which was created for videodev.h. The package is necessary for running the utilities included with ivtv-0.2 and newer. - Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.10 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
