Re: dh_movefiles, tar vs. mv
On Fri, 2005-02-25 at 11:32 -0800, Oliver Kurth wrote: > On Fri, 2005-02-25 at 20:25 +0100, GOMBAS Gabor wrote: > > On Fri, Feb 25, 2005 at 07:54:27PM +0100, Frank KÃster wrote: > > > > > Correct. So, why not use mv? > > > > Add a new "--move" flag to dh_installfiles, come up with some exact > > numbers showing the build time/disk usage savings for your favorite Big > > Package (hard numbers usually very helpful for promoting new features), > > and send the numbers together with the patch to the debhelper maintainer. > > > > Someone already mentioned that a complex package might want to install > > the same file to multiple different locations, so making this the > > default is probably not feasible. > > How about hard linking with ln instead? You would have the best of both > approaches: it is fast, and still possible to have the same file in > multiple packages. I believe Python distutils (like autoconf/automake for Python) uses this approach for its various build/dist targets, and there don't seem to have been any problems/complaints. It also cuts down on hard drive space requirements. However, it probably shouldn't be default. A hard link would be a pretty incompatible change if someone modifies the file after it's been dh_installed (I don't have any concrete examples, but I suspect something does it, if only because 13000 packages guarantees every nasty hack appears at least once :). -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: splitting a source package into 2 source packages
On Saturday 26 February 2005 08:45, sean finney wrote: > so i'm thinking these two packages should be generated from their own > respective tarballs (and i'm not sure why they weren't in the first > place). however, one thing that's not clear to me is whether or not the > new second source package will have to make it through the NEW queue. > if it does, this is a problem given that NEW seems to be stalled and the > previous version of the package will be totally broken when the other > is updated. Upload it to experimental. When the packages reach it after NEW-processing, you can re-upload them to unstable without any delay. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir Ãber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Problems with - and ' in some man-pages
Hi, in some man pages (e.g. ImageMagick, dh_installmime but I've met other ones), the dashes and single quotes are not really what they look like, but some other unicode letter. This has two major drawbacks: - search for options become nearly impossible (try searching for -m, without using -). - cut&paste doesn't work. (this has also the drawback that not all fonts have the said characters, but that's all right) I'm pretty sure, it's somehow due to the fact that I have set LANG=en_IE.UTF-8 (unicode being important of course). Nevertheless, I don't know if it's a problem of the manpage system or of the manpage writers, and how the writers could circumvent/solve the problem. And this information would be useful before I start filing bugs, or!? Thanks for any help, Eric -- Gewalt ist die letzte Zuflucht der Inkompetenz. Violence is the Last Resort of the Incompetent. Gwalt jest ostatnem schronieniem niekompetencji. La violence est le dernier refuge de l'incompetence. ~ Isaac Asimov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with - and ' in some man-pages
> Nevertheless, I don't know if it's a problem of the manpage system or of > the manpage writers, and how the writers could circumvent/solve the > problem. And this information would be useful before I start filing > bugs, or!? This is a bug in the manpages themselves. The unformatted source should have - for hyphenating normal prose, as in "happy-go-lucky", and \- to denote the minus signs used as characters on the command line and other such places. If the proper groff characters are used, your cut&paste and searching problems will vanish and everything will look pretty. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with - and ' in some man-pages
* Eric Lavarde [Sat, 26 Feb 2005 10:04:45 +0100]: > I'm pretty sure, it's somehow due to the fact that I have set > LANG=en_IE.UTF-8 (unicode being important of course). > Nevertheless, I don't know if it's a problem of the manpage system or of > the manpage writers, and how the writers could circumvent/solve the > problem. And this information would be useful before I start filing > bugs, or!? Clint already told you how "writers" cand solve the problem. In the meantime, you may find useful the workaround described in the last paragraph of /etc/groff/man.local. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Don't be irreplaceable, if you can't be replaced, you can't be promoted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updating config files: permissions!?
On Sat, Feb 26, 2005 at 12:12:31AM +0100, Torsten Landschoff wrote: > During upgrades the slapd package (for example) has to do some > adjustments on config files (it asks the user for permission of course). > > Problem: How do I make sure the new config files have the same > permissions!? Currently I do > > chmod --reference=OLD NEW > chown --reference=OLD NEW > mv NEW OLD > > but this will break with ACLs. And what happens with SELinux!? Can't > find anything in debian-policy about it, shouldn't we define that > handling? You can't solve this problem atomically. However, you can do this: mv OLD TMP cat NEW > TMP mv TMP OLD rm NEW Which is almost as good. The point being that rather than create a new file, you truncate the old one and replace its contents (but avoid ever leaving a half-populated file in place; no file is better than a mangled file). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: procmail and Large File Support
On Fri, Feb 25, 2005 at 07:45:47PM -0600, Ron Johnson wrote: > On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote: > > I have several reports saying procmail does not support mbox folders > > larger than 2GB. Questions: > > OT here, but WTF are people smoking, to have 2GB mbox files? Consider a spam-bin folder that you don't split by month or whatever and don't check very often. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: procmail and Large File Support
On Sat, 2005-02-26 at 10:23 +, Colin Watson wrote: > On Fri, Feb 25, 2005 at 07:45:47PM -0600, Ron Johnson wrote: > > On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote: > > > I have several reports saying procmail does not support mbox folders > > > larger than 2GB. Questions: > > > > OT here, but WTF are people smoking, to have 2GB mbox files? > > Consider a spam-bin folder that you don't split by month or whatever and > don't check very often. Maildir? -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "I don't pretend we have all the answers. But the questions are certainly worth thinking about." Arthur C. Clarke -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: procmail and Large File Support
On Sat, Feb 26, 2005 at 04:27:48AM -0600, Ron Johnson wrote: > On Sat, 2005-02-26 at 10:23 +, Colin Watson wrote: > > On Fri, Feb 25, 2005 at 07:45:47PM -0600, Ron Johnson wrote: > > > On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote: > > > > I have several reports saying procmail does not support mbox folders > > > > larger than 2GB. Questions: > > > > > > OT here, but WTF are people smoking, to have 2GB mbox files? > > > > Consider a spam-bin folder that you don't split by month or whatever and > > don't check very often. > > Maildir? Not everyone likes maildir; I gave up on it after experimenting with it and realising that making it harder for myself to use standard Unix text-processing tools on my mailboxes was just too annoying. This is true of spam-bin folders more than other folders, if anything. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Brain Trauma - Flatline EP (PRE-ORDER!)
BRAIN TRAUMA - FLATLINE EP! PRE-ORDER YOUR COPY NOW!!! That is correct. You can now pre-order your copy of FLATLINE, the debut EP from the underground phenomena, Brain Trauma. Now, "why would I preorder a copy?" you may ask. Well, this is why... ONLY for those who pre-order there copies, Myself and Toxik Flow will personally unwrap each one of the cds and AUTOGRAPH THAT SHIT!!! So if you want your copy of flatline to be a true collectors item, PRE-ORDER THAT SHIT BEFORE WE RUN OUT!!! You can pre-order your copy right now by visiting the store at http://www.kasketrecords.com or by following the below link... https://www.paypal.com/xclick/business=sales%40kasketrecords%2ecom&undefined _quantity=1&item_name=Brain%20Trauma%20%2d%20Flatline%20EP%20%28Pre%2dOrder% 29&item_number=KASK004%2dA&amount=7%2e00&no_shipping=2&no_note=1¤cy_co de=USD Also, you can peep out the official sampler for FLATLINE by clicking below... http://www.kasketrecords.com/media/BrainTrauma-FlatlineSampler.mp3 And one more thing... For those interested in seeing titties, click the adress below to vote on who should win the free copy of the FLATLINE EP!!! Thats right, a bunch of titties with BRAIN TRAUMA and KASKET RECORDS written on them!!! http://www.kasketrecords.com/forum/viewtopic.php?p=102 -Kasket Kyle http://www.kasketrecords.com Note: Pre-Ordered copies of the EP will be shipped on the official release date (TBA) To be removed from this list, please respond to this e-mail with "REMOVE" in the subject title. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.4.0 - Release Date: 2/22/2005 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: procmail and Large File Support
On Fri, 25 Feb 2005, Steve Langasek wrote: > > The version in experimental has -D_FILE_OFFSET_BITS=64, and it works > > on files larger than 2GB, but I have only tested it on the i386 > > architecture. > > Please use the value of $(getconf LFS_CFLAGS) instead; it appears (based on > past exim4 bug reports) that using -D_FILE_OFFSET_BITS=64 on natively 64-bit > systems such as alpha causes surprising breakage of some glibc APIs. Ok, will do that. > > * Would the release managers approve this change for sarge? > > If this is the only change, yes. Hmm, while we are at it, I think it would be good to fix #295604 as well. This is the (trivial) patch: diff -ru procmail-3.22.orig/src/header.h procmail-3.22/src/header.h --- procmail-3.22.orig/src/header.h 1999-07-06 08:12:22.0 +0200 +++ procmail-3.22/src/header.h 2005-02-17 00:34:47.0 +0100 @@ -168,3 +168,5 @@ X(readreceiptto, "Read-Receipt-To:") /* miscellaneous extension */ X(fakesender, "Fake-Sender:") X(envelopeto, "Envelope-To:")/* exim extension */ +X(useragent, "User-Agent:") +X(nntppostingdate, "NNTP-Posting-Date:") -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with - and ' in some man-pages
Hi, thanks to both Clint and you for the help. In /etc/groff/man.local, I removed the comments in front of: . if '\*[.T]'utf8' \ .char - \N'45' and removed the negation ! in front of the first condition: . if '\*[.T]'utf8' \ .tr \[oq]' (I could have removed the condition alltogether) You made my day! :-) Eric Adeodato Simà wrote: * Eric Lavarde [Sat, 26 Feb 2005 10:04:45 +0100]: I'm pretty sure, it's somehow due to the fact that I have set LANG=en_IE.UTF-8 (unicode being important of course). Nevertheless, I don't know if it's a problem of the manpage system or of the manpage writers, and how the writers could circumvent/solve the problem. And this information would be useful before I start filing bugs, or!? Clint already told you how "writers" cand solve the problem. In the meantime, you may find useful the workaround described in the last paragraph of /etc/groff/man.local. -- Gewalt ist die letzte Zuflucht der Inkompetenz. Violence is the Last Resort of the Incompetent. Gwalt jest ostatnem schronieniem niekompetencji. La violence est le dernier refuge de l'incompetence. ~ Isaac Asimov
Re: Package xxx has broken dep on yyy: normal?
On Fri, 25 Feb 2005 17:16:57 -0800, Steve Langasek <[EMAIL PROTECTED]> wrote: >That said, any package that is uninstallable in testing for such a long >period of time almost certainly has an RC bug that should be filed. In the >case of gpe-contacts, this is definitely so; the package currently in >unstable cannot be built using sources in the archive (it depends on a >library that currently awaits ftp-master NEW processing), so should not have >been uploaded to main. Chances are that it was uploaded together with the library it depends on, relying on ftpmasters doing their work, as in processing new packages in reasonable time. Please note also, that currently there is no official statement that the NEW queue is frozen, and queries regarding the obviously stalled NEW queue are - as usual - ignored. 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: splitting a source package into 2 source packages
On Sat, 26 Feb 2005 09:56:29 +0100, David Schmitt <[EMAIL PROTECTED]> wrote: >On Saturday 26 February 2005 08:45, sean finney wrote: >> so i'm thinking these two packages should be generated from their own >> respective tarballs (and i'm not sure why they weren't in the first >> place). however, one thing that's not clear to me is whether or not the >> new second source package will have to make it through the NEW queue. >> if it does, this is a problem given that NEW seems to be stalled and the >> previous version of the package will be totally broken when the other >> is updated. > >Upload it to experimental. When the packages reach it after NEW-processing, >you can re-upload them to unstable without any delay. Even uploads to experimental are currently stalled by ftpmasters not processing NEW packages without any official statement for the cause. 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: list of packages on private website
Hi, * Goswin von Brederlow <[EMAIL PROTECTED]> [2005-02-26 16:07]: > Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes: > > That's rather OT, but I wanted to target my question at developers, cause > > I suppose that's the only group which would be able to help me. > > > > I would like to put on my homepage list of packages that I maintain. > > I suppose that the easiest way would be to fetch this information from > > ldap database. I don't want to reinvent the wheel, and I'm sure some of > > you have already similar lists on your websites. > > > > I'm also quite sure you want to share your code with others, don't you? ;) > > > > So if someone could announce that he/she has some code, and in turn makes > > my life easier, then it's time to do that. > > > > The perfect solution would be some script which would download these > > information once a week and build static pages from it. This way > > I wouldn't overload database. > > > > So... who wants to share his code? ;) > > How about: > > http://people.debian.org/~igloo/status.php?email=brederlo%40informatik.uni-tuebingen.de&packages=&arches= I like this one: http://people.debian.org/~ms/ Regards Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | mutt-ng.berlios.de | grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpOwjISjXKFk.pgp Description: PGP signature
Mouse problem
I have Trust 3011A Wireless optical deskset mouse and keybord and use Debian sarge. I tried in XF86Config-4 Section "InputDevice" Identifier"Configured Mouse" Driver"mouse" Option"CorePointer" Option"Device""/dev/psaux" Option"Protocol""ExplorerPS/2" Option"Emulate3Buttons""no" Option"ZAxisMapping""6 7" EndSection Section "InputDevice" Identifier"Generic Mouse" Driver "mouse" Option "Protocol" "ExplorerPS/2" Option "Device" "/dev/input/mice" Option "Buttons" "7" Option "ZAxisMapping" "6 7" Option "Resolution" "100" Option "Emulate3Buttons" "no" Option"SampleRate" "800" EndSection #xmodmap -e "pointer = 1 2 3 6 7 4 5" #imwheel -p -k -b "67" but xev did't react when I press the additional sided buttons I would like to tell me what is the problem with this and where I am wrong.Thank you. -- Това писмо е изпратено от www.mail.bg Безплатната поща в mail.bg предлага: - Силна защита срещу СПАМ/рекламни писма - 30MB безплатно (SMS от 2лв=3GB!) - 30MB макс. размер на прикачен файл - SMS за ново писмо (всички оператори) - WAP достъп от GSM и без компютър - Безплатен POP3 достъп - 24 часов телефон за помощ/поддръжка __ БЕЗ ИЗЛИШНИ ВЪПРОСИ РЕГИСТРИРАЙТЕ СВОЙ БЕЗПЛАТЕН АДРЕС НА http://www.mail.bg
I NEED YOUR QUICK RESPONSE SIR.
Mrs.Lydia JOHNSON C/o Eglise Uganda Catholic church Liberte Sicap, Dakar Senegal. Good Day, I know this mail will come to you as a surprise, nevertheless I am Mrs. Lydia Johnson, aged 59 years, the wife of Major Stephen Johnson, Chief Security Officer and Aide-decamp to the president Charles Tailor of Liberia. As a result of the on-going war in my country, I am saddled with problems of my ill health of protracted diabetes and high blood pressure which is getting of increase in the resent times and also getting a trust worthy individual abroad to receive the sum of US$12.5million and 15 kg worth of Diamond on our behalf. Due to this war crises presently in my city Monrovia our home town, my husband managed to sneak me and my son David 25 years of age and four other of my daughters out of Monrovia to Dakar senegal for safety. We were sneaked into Dakar Senegal through the land boarder by the help of some government militant group. My husband adviced me to get a trust worthy individual abroad to receive the deposit.I feel confident therefore to introduce myself and this offer to you based on this problem of war in my country and our present condition as all our foreign contacts and connections got lost during this crises, all properties burnt by the rebels. I am desperately in need to move and re-locate this huge deposit to your country for safe keeping on the advice of my husband as this is the only wealth remaining for the future survival and well being of our large family.For your percentage for assistance, a negotiable percentage will be discussed as soon as I receive your response based on this plead for your assistance as our lives are highly in danger due to war.I pray and plead for your help. God bless you as you heed to my plead for assistance. Sincerely yours. Mrs.Lydia Johnson and Son David. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.5.0 - Release Date: 25/02/2005
missing sent packets of via-rhine
hi! i'v got some troubles with the via-rhine driver resp. the via nic and hope someone can give me some hint. the problem:i'm sending some ethernet frames from kernel to the nic (with dev_queue_xmit). everything seems to be ok, /proc/net/dev lists all packets sent, but the target nic did not receive all frames. to exclude failures on the receiving station, i used different receiving stations with different nics. allways the same - missing frames. sending frames out of user mode leads to no loss, sending frames out of kernel mode with some timegap between two dev_queue_xmit calls leads to no loss. just "fast" sending of frames leads to this loss. i compiled the via-rhine driver with highest debug-level to check the problem in detail.here is the debug output of sending 10 frames, where just 6 frames were received at the destination station: eth0: VIA Rhine monitor tick, status .eth0: Transmit frame #39 queued in slot 7.eth0: Transmit frame #40 queued in slot 8.eth0: Interrupt, status 0002. Tx scavenge 7 status .collisions: 0:0 Tx scavenge 8 status .collisions: 0:0eth0: exiting interrupt, status=.eth0: Transmit frame #41 queued in slot 9.eth0: Transmit frame #42 queued in slot 10.eth0: Transmit frame #43 queued in slot 11.eth0: Transmit frame #44 queued in slot 12.eth0: Interrupt, status 0002. Tx scavenge 9 status .collisions: 0:0 Tx scavenge 10 status .collisions: 0:0 Tx scavenge 11 status 8000.eth0: Interrupt, status 0002. Tx scavenge 11 status 8000.eth0: Interrupt, status 0002. Tx scavenge 11 status .collisions: 0:0 Tx scavenge 12 status 8000.eth0: exiting interrupt, status=.eth0: Interrupt, status 0002. Tx scavenge 12 status .collisions: 0:0eth0: exiting interrupt, status=.eth0: Transmit frame #45 queued in slot 13.eth0: Transmit frame #46 queued in slot 14.eth0: Transmit frame #47 queued in slot 15.eth0: Transmit frame #48 queued in slot 0.eth0: Interrupt, status 0002. Tx scavenge 13 status .collisions: 0:0 Tx scavenge 14 status .collisions: 0:0 Tx scavenge 15 status 8000.eth0: exiting interrupt, status=.eth0: Interrupt, status 0002. Tx scavenge 15 status .collisions: 0:0 Tx scavenge 0 status .collisions: 0:0eth0: exiting interrupt, status=.eth0: VIA Rhine monitor tick, status . so as far as i can estimate this output (i do not have technical documentation of the nic) everything looks right.the status of all 10 frames was set to 0. i guess this means "frame sent"just frame 5 (frame 43 at slot 11 in the debug output) is a little bit confusing me. there is an interrupt with status 0002 (TxDone) and the next frame in the ring buffer still has the status DescOwn. ???but it seams not serious to me. does anyone got an idea why i'm losing frames? a bug in the driver, or bug of the nic? thank you and best regards, roman
Re: dh_movefiles, tar vs. mv
Oliver Kurth <[EMAIL PROTECTED]> schrieb: > On Fri, 2005-02-25 at 20:25 +0100, GOMBAS Gabor wrote: >> On Fri, Feb 25, 2005 at 07:54:27PM +0100, Frank Küster wrote: >> >> > Correct. So, why not use mv? >> >> Add a new "--move" flag to dh_installfiles, come up with some exact >> numbers showing the build time/disk usage savings for your favorite Big >> Package (hard numbers usually very helpful for promoting new features), >> and send the numbers together with the patch to the debhelper maintainer. >> >> Someone already mentioned that a complex package might want to install >> the same file to multiple different locations, so making this the >> default is probably not feasible. > > How about hard linking with ln instead? You would have the best of both > approaches: it is fast, and still possible to have the same file in > multiple packages. I didn't look closely, but I think it might need quite some changes to the code. It seems dh_install uses cp -a for directories, and you cannot use hard links with directories (at least not generally, here on my ext3 $HOME it does not work. And I suspect it could end in great mess). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: dh_movefiles, tar vs. mv
* Frank Küster [Sat, 26 Feb 2005 19:34:45 +0100]: > I didn't look closely, but I think it might need quite some changes to > the code. It seems dh_install uses cp -a for directories, and you cannot > use hard links with directories (at least not generally, here on my ext3 > $HOME it does not work. And I suspect it could end in great mess). I remember that I once modified my dh_install to use cp -al. That will make each file be a hardlink, even if you copy a dir. It's fast. I wouldn't mind that dh_install accepted an option to behave like that. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Taking any religion too seriously --even the Church of Emacs-- can be hazardous to your health. -- Richard Stallman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_movefiles, tar vs. mv
Colin Watson <[EMAIL PROTECTED]> wrote: > My point is that half the reason why dh_install was introduced instead > of dh_movefiles is to copy files, not move them, and it seems odd that > now there's a thread asking how to get dh_install to move files. If you > want to move files, don't use dh_install. I never asked how to get dh_install to move files. I asked what the reasons are why neither dh_install nor dh_movefiles use it. And it seems to me that the summary of the answers is: It is unwanted in most cases, in particular because of idempotency. But in cases where idempotency is less important than other things - time and disk space savings - there is no technical reason not to use it in package building. Using hard links may be an alternative, but not without major changes to the code. I have not yet decided whether I'm going to prepare a patch for dh_install, for an optional "--move" behavior, or just use it in a handcrafted way in my packaging script. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: dh_movefiles, tar vs. mv
On Saturday 26 February 2005 01:37 pm, Adeodato Simó wrote: > * Frank Küster [Sat, 26 Feb 2005 19:34:45 +0100]: > > I didn't look closely, but I think it might need quite some changes to > > the code. It seems dh_install uses cp -a for directories, and you cannot > > use hard links with directories (at least not generally, here on my ext3 > > $HOME it does not work. And I suspect it could end in great mess). > > I remember that I once modified my dh_install to use cp -al. That will > make each file be a hardlink, even if you copy a dir. It's fast. > > I wouldn't mind that dh_install accepted an option to behave like that. See bug #296917. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ |All generalizations are dangerous. | \ Evil Overlord, Inc: http://www.eviloverlord.com --/ pgpmqh7SGPS8n.pgp Description: PGP signature
Re: Automatic building of (parts of) the archive
David Schmitt <[EMAIL PROTECTED]> schrieb: > On Friday 25 February 2005 18:43, Frank Küster wrote: >> in order to test whether packages that build-depend on tetex can still >> be built with the upcoming version 3.0, I would like to automatically >> build as many of these packages. > > Take a look at pbuilder. There are people recompiling the whole of debian > regularily with pbuilder. I regularly use pbuilder, but I don't see how this could be useful here: For every package build, it untars a new filesystem, installs dependencies, builds, and removes the complete thing again. For a mass-building of package, wouldn't one want to reuse the chroot, at least until the first FTBFS? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Automatic building of (parts of) the archive
Goswin von Brederlow <[EMAIL PROTECTED]> schrieb: > Frank Küster <[EMAIL PROTECTED]> writes: > >> Hi, >> >> in order to test whether packages that build-depend on tetex can still >> be built with the upcoming version 3.0, I would like to automatically >> build as many of these packages. I know where I can read about setting >> up a buildd, but two questions remain: >> >> - are there any scripts that hand over the next package in a list after >> one build has finished (without setting up a copy of wanna-build...)? > > You can preseed the local queue with packages just fine. Is this documented in the sbuild package, or somewhere else? For a starter, I looked at Andreas Barth's cheat sheet, but there he only mentions manual building of packages, no local queue. TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: dh_movefiles, tar vs. mv
* Daniel Burrows [Sat, 26 Feb 2005 13:42:28 -0500]: > On Saturday 26 February 2005 01:37 pm, Adeodato Simó wrote: > > I remember that I once modified my dh_install to use cp -al. That will > > make each file be a hardlink, even if you copy a dir. It's fast. > > I wouldn't mind that dh_install accepted an option to behave like that. > See bug #296917. Ah yes, precisely. :) -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 So, irregular/impure/non-elegant syntax doesn't bother me. Shit, I speak English. Mainly I just want to type less. -- William Morgan, on [ruby-talk:131589] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: svn.debian.org: Automatically putting log message into debian/changelog?
|| On Fri, 25 Feb 2005 15:09:07 +0100 || Torsten Landschoff <[EMAIL PROTECTED]> wrote: tl> Hi Joey, tl> On Thu, Feb 24, 2005 at 04:42:49PM -0500, Joey Hess wrote: >> I've done this for years using the attached script (which will work with >> both svn and cvs (less well), and can also tag releases). tl> Thanks, that was exactly what I looking for. I already had scheduled tl> some hacking for this. :) tl> Now I have to update it for svk ;) Perfect. Please, share it after change ;-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package xxx has broken dep on yyy: normal?
On Sat, Feb 26, 2005 at 04:28:36PM +0100, Marc Haber wrote: > On Fri, 25 Feb 2005 17:16:57 -0800, Steve Langasek <[EMAIL PROTECTED]> > wrote: > >That said, any package that is uninstallable in testing for such a long > >period of time almost certainly has an RC bug that should be filed. In the > >case of gpe-contacts, this is definitely so; the package currently in > >unstable cannot be built using sources in the archive (it depends on a > >library that currently awaits ftp-master NEW processing), so should not have > >been uploaded to main. > Chances are that it was uploaded together with the library it depends > on, relying on ftpmasters doing their work, as in processing new > packages in reasonable time. And if the new library package is rejected instead of being accepted? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: splitting a source package into 2 source packages
On Saturday 26 February 2005 02:45 am, sean finney wrote: > hi, > > i'm maintaining a source package that produces two binary packages. > however, one of the packages is built from a seperately distributed (same > author, same website, but different tarball and versioning scheme) > tarball. > > so i'm thinking these two packages should be generated from their own > respective tarballs (and i'm not sure why they weren't in the first > place). however, one thing that's not clear to me is whether or not the > new second source package will have to make it through the NEW queue. > if it does, this is a problem given that NEW seems to be stalled and the > previous version of the package will be totally broken when the other > is updated. > > comments would be appreciated... thanks. > > sean I seem to recall hearing that NEW processing is based solely on binary packages, so that the new source package would not need to go through NEW if it creates a binary package that is already in the archive. I couldn't find anything about this through google, though, so it may be best to upload to experimental first and see if your new packages go right in or not. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: splitting a source package into 2 source packages
El sÃb, 26-02-2005 a las 14:18 -0500, Josh Metzler escribiÃ: > On Saturday 26 February 2005 02:45 am, sean finney wrote: > > hi, > > > > i'm maintaining a source package that produces two binary packages. > > however, one of the packages is built from a seperately distributed (same > > author, same website, but different tarball and versioning scheme) > > tarball. > > > > so i'm thinking these two packages should be generated from their own > > respective tarballs (and i'm not sure why they weren't in the first > > place). however, one thing that's not clear to me is whether or not the > > new second source package will have to make it through the NEW queue. > > if it does, this is a problem given that NEW seems to be stalled and the > > previous version of the package will be totally broken when the other > > is updated. > > > > comments would be appreciated... thanks. > > > > sean > > I seem to recall hearing that NEW processing is based solely on binary > packages, so that the new source package would not need to go through NEW > if it creates a binary package that is already in the archive. > > I couldn't find anything about this through google, though, so it may be > best to upload to experimental first and see if your new packages go right > in or not. If you create a new binary, you have to wait for you package to be processed in the NEW queue. There were a proposal for that to happen (old sources don't traverse NEW when a binary package is added) but nothing happened. -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: procmail and Large File Support
On Sat, Feb 26, 2005 at 12:59:49PM +0100, Santiago Vila wrote: > On Fri, 25 Feb 2005, Steve Langasek wrote: > > > The version in experimental has -D_FILE_OFFSET_BITS=64, and it works > > > on files larger than 2GB, but I have only tested it on the i386 > > > architecture. > > Please use the value of $(getconf LFS_CFLAGS) instead; it appears (based on > > past exim4 bug reports) that using -D_FILE_OFFSET_BITS=64 on natively 64-bit > > systems such as alpha causes surprising breakage of some glibc APIs. > Ok, will do that. > > > * Would the release managers approve this change for sarge? > > > > If this is the only change, yes. > Hmm, while we are at it, I think it would be good to fix #295604 as well. > This is the (trivial) patch: > diff -ru procmail-3.22.orig/src/header.h procmail-3.22/src/header.h > --- procmail-3.22.orig/src/header.h 1999-07-06 08:12:22.0 +0200 > +++ procmail-3.22/src/header.h 2005-02-17 00:34:47.0 +0100 > @@ -168,3 +168,5 @@ > X(readreceiptto, "Read-Receipt-To:") /* miscellaneous extension > */ > X(fakesender, "Fake-Sender:") > X(envelopeto, "Envelope-To:")/* exim extension > */ > +X(useragent, "User-Agent:") > +X(nntppostingdate, "NNTP-Posting-Date:") Looks straightforward, yes. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: splitting a source package into 2 source packages
hi josh, On Sat, Feb 26, 2005 at 02:18:19PM -0500, Josh Metzler wrote: > I seem to recall hearing that NEW processing is based solely on binary > packages, so that the new source package would not need to go through NEW > if it creates a binary package that is already in the archive. > > I couldn't find anything about this through google, though, so it may be > best to upload to experimental first and see if your new packages go right > in or not. istr the same thing, and was thinking that this might be the case. since i don't suppose the ftp-master illuminati are going to come out of hiding just to answer this question, i guess i'll upload, find out, and report back :/ sean -- signature.asc Description: Digital signature
Bug#297063: ITP: specter -- packet logger for netfilter's ULOG target
Package: wnpp Severity: wishlist Owner: Grzegorz Bizon <[EMAIL PROTECTED]> * Package name: specter Version : 1.3 Upstream Author : Michal Kwiatkowski <[EMAIL PROTECTED]> * URL : http://joker.linuxstuff.pl/specter/ * License : GPL Description : packet logger for netfilter's ULOG target specter is based on Harald's Welte ulogd 1.02, but has a slightly different approach. Its modularized structure and highly-configurable parameters combined with neat netfilter's design gives you freedom in setting up your logging facility. You can not only save packets into files or databases, but also do other crazy things, like making your keyboard blink in case of high net traffic (or any other user-defined condition). .. Plugins: - EXEC plugin that executes given commands when specified packet is received - HTTP plugin which parses http traffic - PWSNIFF plugin that logs plaintext passwords as used with FTP and POP3 - OPRINT simple output module, dumping specified packets to file - Logging plugins that emulates few logging facilities - mysql and postgresql extensions available via separate packages -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-rc3 Locale: LANG=pl_PL.ISO-8859-2, LC_CTYPE=pl_PL.ISO-8859-2 (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Automatic building of (parts of) the archive
On Fri, Feb 25, 2005 at 06:43:41PM +0100, Frank Küster wrote: > Hi, > > in order to test whether packages that build-depend on tetex can still > be built with the upcoming version 3.0, I would like to automatically > build as many of these packages. I know where I can read about setting > up a buildd, but two questions remain: > > - are there any scripts that hand over the next package in a list after > one build has finished (without setting up a copy of wanna-build...)? Use 'wanna-build --merge-packages' and provide it a customised Packages file that only includes the stuff you want to build, then run buildd and it will crunch through of all of the packages. You might want to go through: http://www.debian.org/devel/buildd/ and http://www.debian.org/devel/buildd/setting-up Regards Javier signature.asc Description: Digital signature
Re: Package xxx has broken dep on yyy: normal?
On Sat, 26 Feb 2005 11:15:30 -0800, Steve Langasek <[EMAIL PROTECTED]> wrote: >On Sat, Feb 26, 2005 at 04:28:36PM +0100, Marc Haber wrote: >> Chances are that it was uploaded together with the library it depends >> on, relying on ftpmasters doing their work, as in processing new >> packages in reasonable time. > >And if the new library package is rejected instead of being accepted? How often does that happen? For some reasons, I do still have hope and tend to take the optimistic approach. 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: Automatic building of (parts of) the archive
Frank Küster <[EMAIL PROTECTED]> writes: > Goswin von Brederlow <[EMAIL PROTECTED]> schrieb: > >> Frank Küster <[EMAIL PROTECTED]> writes: >> >>> Hi, >>> >>> in order to test whether packages that build-depend on tetex can still >>> be built with the upcoming version 3.0, I would like to automatically >>> build as many of these packages. I know where I can read about setting >>> up a buildd, but two questions remain: >>> >>> - are there any scripts that hand over the next package in a list after >>> one build has finished (without setting up a copy of wanna-build...)? >> >> You can preseed the local queue with packages just fine. > > Is this documented in the sbuild package, or somewhere else? For a > starter, I looked at Andreas Barth's cheat sheet, but there he only > mentions manual building of packages, no local queue. > > TIA, Frank Its buildd specific. If its queue is empty it contacts wanna-build and puts the new packages into the queue. I can't remeber the filename but that should be easy to see from the source. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
travel to DC/Baltimore-area March 13-20 / keysigning?
Anyone in the DC-area want to meet for keysigning March 13 - 20th? I'll be there for work, but will have some free time. Please cc replies or just mail directly - bri -- Recursivity. Call back if it happens again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 08:54:36PM -0800, Thomas Bushnell BSG wrote: > Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > > I was quoting a post with actual download numbers that actually demonstrate > > that the vast majority of users are on i386: see http://blog.bofh.it/id_66. > But that doesn't show what you said you believe, which is that > supporting other archs slows the release. It's not actually all that difficult to show that there's a positive, roughly linear correlation between the number of release archs and the magnitude of certain problems that are potential release delays: - new versions of packages are not promoted to testing until they're in sync on all archs - all release-critical bugs in packages are resolved by either removing the package from testing (not always an option) or by getting a new version of the package into testing - a buildd for a single arch that is broken with respect to the package in question can therefore cause a delay in fixing a single release-critical bug in testing - the chance of a bug fix being held out of testing because of a buildd bug on some arch is roughly equal to the chance of it being held out because of a bug on a particular arch, times the number of archs[1] - when the delays cause our bug closure rate to be lower than the rate at which new release-critical bug reports are opened, we have a problem. That said, however, there is not much evidence to support the idea that dropping architectures from the list of release candidates is going to get us to the release any faster. Not only is there the possibility that the responsiveness of individual buildd maintainers should outweigh popularity as a factor in deciding which architectures to support, there's also the issue that the biggest blocker for sarge currently, the lack of testing-security buildd support, affects all but *two* architectures. Somehow, I don't think the idea of releasing with only i386 and sparc would be very popular, even if I was inclined to do so. > Easy to say. How many RC bugs have you fixed recently, and if we > dropped the other archs, how many would you have fixed? do we get to count on his behalf CAN-2005-0011, a security bug in kdeedu which is currently blocked from reaching testing because the quantlib package he maintains needs for someone to manually adjust the buildd timeout on mips and mipsel? > > - security response time (more builds to do) > Which DSAs came out later than they should have because of this > supposed delay? Nor could this possibly slow release. Prior to release, security bugs are RC bugs that are handled by the testing security team and the release team. While we would not delay the release on account of security bugs alone (since they can be fixed post-release), they are bugs that get tracked by the release team. > > - scarce resource such as release managers, ftp admins, ... > > if we have to look after arches that are *not really used*. > All of whom have said that this doesn't actually slow them at all. Hmm, no; I've only said that dropping archs because of build problems affecting individual, arbitrary packages is a stupid strategy for getting us to release. -- Steve Langasek postmodern programmer [1] With other minor factors that probably balance each other out, such as identical simultaneous breakage on multiple buildds that reduce the impact by allowing fixes in parallel or as a batch, vs. some buildd maintainers running multiple buildds who may have less time to tend an individual arch because of the total number of archs being supported signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 03:09:55PM -0500, Joey Hess wrote: > > > - security response time (more builds to do) > > Which DSAs came out later than they should have because of this > > supposed delay? Nor could this possibly slow release. > DSAs are occasionally delayed waiting on builds. The priveliged nature > of much of the information surrounding DSAs makes it impossible for me > to give a list, but I've seen it happen repeatedly. The most glaring > example in recent memory is the 6 or so months it took for us to get > updated kernels in stable for last spring's set of very bad kernel > security holes. > Security bugs which are currently not fixed in testing, and which either > would be fixed there or would not be a concern if it wasn't for the need > to support all architectures include: Just so we're clear on *which* architectures are at issue here, and why they are: > bidwatcher 1.3.17-1 needed, have 1.3.16-1 for DSA-687-1 arm, sparc builds waiting on the xfree86 chroot cleanup > bind 1:8.4.6-1 needed, have 1:8.4.4-1 for CAN-2005-0033 arm waits on cleanup of yacc alternative mess in buildd chroot > emacs21 21.3+1-9 needed, have 21.3+1-8 for CAN-2005-0100, DSA-685-1 m68k, mips builds missing due to a timestamp skew problem in the package that constitutes a sourceful bug in emacs21 which affects slow architectures *and all archs running 2.6 kernels* (hence amd64 fails, and after release any buildds that switch to 2.6 kernels in sarge would fail) > kdeedu 4:3.3.2-2 needed, have 4:3.3.1-3 for CAN-2005-0011 mips, mipsel build of quantlib needed, requires adjusting buildd timeouts > kdelibs 4:3.3.2-2 needed, have 4:3.3.2-1 for CAN-2005-0365 not actually an architecture stall problem anymore; this was a missing mipsel build, but now it's that kdelibs is hung up waiting for aspell, which is the sort of bad timing that can affect us at any moment (but is certainly more likely when uploads to unstable for all archs are spread across a longer period) > kernel-image-2.4.27-alpha (unfixed; bug #280492) for CAN-2003-0465 alpha, obviously > kernel-image-2.4.27-sparc 2.4.27-2 needed, have 2.4.27-1 for CAN-2004-1056, > CAN-2004-1235 and sparc, of course > kernel-patch-powerpc-2.4.27 (unfixed) for CAN-2004-1056, CAN-2004-1235 powerpc... > xemacs21 21.4.16-2 needed, have 21.4.16-1 for CAN-2005-0100, DSA-671-1 since resolved > xview 3.2p1.4-19 needed, have 3.2p1.4-16 for DSA-672-1 not actually an arch buildd problem, the issue here is that we have known-broken binaries on one arch that need to be removed from the archive; but if we count it, it counts for ia64. So supposing we had some sort of requirement for release archs such as "within 10 days of any source upload, there must be either a binary upload or a FTBFS report for the build", we would presently have to kick out alpha amd64 arm ia64 m68k mips mipsel powerpc sparc and keep hppa i386 s390; and if we relax this to only require "within 10 days of any source upload, assuming the source isn't buggy, there must be a binary upload for this security bug", we would be kicking out alpha arm mips mipsel powerpc sparc and keeping amd64 hppa ia64 i386 m68k s390, which I hope amply demonstrates the point to people that railing against slow or unpopular architectures is not actually going to bring about the desired outcome. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sat, Feb 26, 2005 at 05:27:48PM -0800, Steve Langasek wrote: > and if we relax this to only require "within 10 days of any source upload, > assuming the source isn't buggy, there must be a binary upload for this > security bug", we would be kicking out > alpha arm mips mipsel powerpc sparc I think those have one thing in common... > and keeping > amd64 hppa ia64 i386 m68k s390, ... and those archs has something in common as well. Who spots the point? ;) -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the ongoing xfree86 buildd saga
On Thu, Feb 24, 2005 at 08:44:04PM -0800, Thomas Bushnell BSG wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > I don't think it would hurt if maintainers whose packages are in this state > > would email the relevant @buildd.debian.org addresses and cc: > > debian-release on the message -- now, rather than waiting for the buildds to > > be fixed. Hopefully, this would save the buildd maintainers the trouble of > > having to look through all the build logs to find the ones related to this > > breakage, and they can requeue them as a batch. > So I've done this, but I am skeptical about how much it will help. > For example, if even *one* buildd maintainer doesn't requeue with some > kind of promptness, then the only way to deal with it will be to make > a new upload, which will force a recompile everywhere. If one of the buildd maintainers ignores all the packages affected by this breakage, then we're in trouble. (I currently have a list of some half-dozen packages in need of requeuing once the chroots are fixed.) This doesn't seem like a very likely eventuality. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
