Re: Reclaiming automake
* James Westby ([EMAIL PROTECTED]) wrote: > On (29/06/06 19:37), Eric Dorland wrote: > > * Scott James Remnant ([EMAIL PROTECTED]) wrote: > > > On Sun, 2006-06-25 at 19:11 -0400, Eric Dorland wrote: > > > > > > > Scott James Remnant dropped me an email recently, interested in > > > > improving the automake situation in Ubuntu and Debian[0]. > > > > > > > > [0] Their plan, which mirrors mine, is documented here: > > > > https://wiki.ubuntu.com/AutomakeTransition > > It would be good if you could make a page or two on the Debian wiki. One > with the details about what must happen and what must be checked, > perhaps with lists of packages that can be claimed and then marked > appropriately. It would also be good to have a page that bug reports > that are filed can reference, so that the maintainers have a clear about > what is supposed to happen. Sure, I'll take a look at doing this before I start anything. > Are the instructions at the bottom of the referenced Ubuntu page exact > enough for you? They go farther than is necessary, but if that can be done it would be great. > > > > Now before I can implement this master plan, I need to fix all the > > > > packages that still build depend on "automake"[1]. To proceed with > > > > this I'd like to file wishlist bugs (with patches) against these > > > > packages one week from today. One week after that, with the Release > > > > Team's blessing, I'd like to start NMUing as much of these packages as > > > > I can. Once that is complete, I'd like to make the transition and > > > > raise the severity of any of bugs that remain. > > > > > > > We should probably work together to cut the time down to make these > > > patches. > > > > I'm going to get started on Saturday, and I'll be on IRC > > (#debian-devel) so if you (or anyone) want to join in the fun, we can > > coordinate there. I've just filed #376047 too, so any bugs filed > > should be made to block that one. > > > > I will help out where possible. I will hopefully email you later with > information on the packages that were referenced as [1] (snipped) that > might help you out as well. Great, thanks! -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Reclaiming automake
* Scott James Remnant ([EMAIL PROTECTED]) wrote: > On Thu, 2006-06-29 at 19:37 -0400, Eric Dorland wrote: > > > * Scott James Remnant ([EMAIL PROTECTED]) wrote: > > > On Sun, 2006-06-25 at 19:11 -0400, Eric Dorland wrote: > > > > > > > Scott James Remnant dropped me an email recently, interested in > > > > improving the automake situation in Ubuntu and Debian[0]. > > > > > > > > [0] Their plan, which mirrors mine, is documented here: > > > > https://wiki.ubuntu.com/AutomakeTransition > > > > > > > If you could have another read through of that spec, now it's > > > post-draft, and make sure we're still both planning the same thing > > > that'd be great. I don't see any reason for Ubuntu to go a different > > > direction to Debian here. > > > > > > In particular I had a momentary thought about what packages should > > > actually depend/build-depend on now -- could you check that. > > > > The automaken | automake$VER is probably not wise. A new version of > > automake may not be fully backwards compatible. If it were, we > > wouldn't have these problems. Better to depend on a known version that > > works, or better still don't build depend on it at all and ship the > > generated files in the diff.gz. > > > I'd personally tend to err on the "assume it is, unless it isn't" -- > would you suggest all packages be changed to not B-D on automaken then? In my opinion this would be best practice. Some maintainers don't agree. > > I'm going to get started on Saturday, and I'll be on IRC > > (#debian-devel) so if you (or anyone) want to join in the fun, we can > > coordinate there. I've just filed #376047 too, so any bugs filed > > should be made to block that one. > > > The disadvantage of doing this for a living, rather than for fun, is > that weekends tend to be out :) I'll pick up on Monday :p You've lost your love of free software Scott :P No worries, hopefully on Monday you'll wake up to see a lot of progress. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Dropping indirect dependencies from libgnutls-config --libs
On Fri, Jun 30, 2006 at 03:42:12PM +0200, Martijn van Oosterhout wrote: > It is also used to compile contrib modules that are included in the > distribution. If you started using pkg-config you'd have introduced a > build dependancy on a GPL'd program in a BSD licenced package, not > exactly a good idea. Hmm, that's an interesting thought, but I'm not sure it's a strong concern. Stephen Gran already mentioned libtool, but regardless you can arrange things so pkg-config isn't a strict dependency. Most configure scripts support various --with-foo arguments, so people who don't wish to use pkg-config can simply pass --with-foo=$HOME/local/foo. pkg-config would thus be helpful but not a strict build dependency. > pkg-config is nice for the constellation of GPL'd libraries currently > installed on most linux systems, but once you step outside of that > it's not quite as useful. GTK is LGPL, as is most of the GNOME stack. GTK predates pkg-config, they just moved to it as of GTK 2. Previous to that there were glib-config and gtk-config scripts. -- Vincent Ho "If we hit that bullseye, the rest of the dominos will fall like a house of cards. Checkmate." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mactel linux support?
Hi, > > Your bug is meant to be already fixed (#355252), but I see there are > > some deviations between Debian and Ubuntu (which you seem to > > maintain), I'm suspecting there might be problems with Debian code > > which is only updated about 3 months ago. > > Ok, that's a possibility - there were a few patches, and we may have > ended up applying slightly different ones. I'll be reviewing these. > > I thought EFI should work with FAT (I was surprised to see blessing > > can be applied to HFS+ also), which is the first partition on the > > internal disk. > > There's two different mechanisms of booting a file under the Mac EFI - > you can either put the filename in nvram, or you can bless a file. I > believe that the blessing can only be done on HFS+ filesystems. My best guess is that 'blessing' is required due to EFI not being able to read HFS+ filesystem; this I need to look into some backing info. $ nvram -p boot-image %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%01%08%00%00%01%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00%00%00%80%02%00%00%00%00x%b6%8dV%0a%84qA%8f%e1$%164^]Y%02%02%04%04%18%004%009%00b%007%009%00d%000%000%000%00%00%00%7f%ff%04%00 SystemAudioVolume n boot-args 0x0 I don't quite grok this parameter stored as 'boot-image'; but my guess is that's what's used for the booting before anything EFI starts up... > > I'm hoping that I can switch default boot through some kind of nvram > > setting. > > You can, but you can't get into the firmware interface without having > blessed a file first. Which needs MacOS right now. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping indirect dependencies from libgnutls-config --libs
This one time, at band camp, Andreas Metzler said: > Martijn van Oosterhout wrote: > [making foo-config a wrapper around pkg-config] > > > If you started using pkg-config you'd have introduced a > > build dependancy on a GPL'd program in a BSD licenced package, not > > exactly a good idea. > [...] > > That is something I hadn't thought about, gnutls is LGPL. Thanks. I'm not sure how that's a real problem. Can you explain? It's not like you're proposing to link against libpkgconfig, even if such a thing existed. You already provide .la files, right? Am I missing something? -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#376215: ITP: octave2.9-forge -- Contributed functions for GNU Octave from http://octave.sf.net for Octave 2.9
Package: wnpp Severity: wishlist Owner: Thomas Weber <[EMAIL PROTECTED]> * Package name: octave2.9-forge Version : 2006.03.17 Upstream Author : Paul Kienzle <[EMAIL PROTECTED]> * URL : http://octave.sourceforge.net/ * License : Various (GPL, Public Domain) Programming Lang: Octave, C++ Description : Contributed functions for GNU Octave from http://octave.sf.net for Octave 2.9 The octave-forge project contains over 500 contributed functions for GNU Octave which are not in the main distribution. These functions are grouped according to the following subdirectories: audio, comm, control, general, geometry, ident, image, io, linear-algebra, miscellaneous, optim, path, plot, set, signal, sparse, specfun, special-matrix, splines, statistics, strings, struct, symbolic, time. While the main Octave distribution is conservative about accepting new functions and changes, octave-forge is very open. As a result, be prepared for some lower quality code and more rapidly changing interfaces to the functions in octave-forge. This package is compiled for Octave 2.9. If you need it for Octave 2.1, use the octave2.1-forge package. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (700, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) This package will be maintained by the Debian Octave Group on Alioth. Regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376214: ITP: octave2.1-forge -- Contributed functions for GNU Octave from http://octave.sf.net for Octave 2.1
Package: wnpp Severity: wishlist Owner: Thomas Weber <[EMAIL PROTECTED]> * Package name: octave2.1-forge Version : 2006.03.17 Upstream Author : Paul Kienzle <[EMAIL PROTECTED]> * URL : http://octave.sourceforge.net/ * License : Various (GPL, Public Domain) Programming Lang: Octave, C++ Description : Contributed functions for GNU Octave from http://octave.sf.net for Octave 2.1 The octave-forge project contains over 500 contributed functions for GNU Octave which are not in the main distribution. These functions are grouped according to the following subdirectories: audio, comm, control, general, geometry, ident, image, io, linear-algebra, miscellaneous, optim, path, plot, set, signal, sparse, specfun, special-matrix, splines, statistics, strings, struct, symbolic, time. While the main Octave distribution is conservative about accepting new functions and changes, octave-forge is very open. As a result, be prepared for some lower quality code and more rapidly changing interfaces to the functions in octave-forge. This package is compiled for Octave 2.1. If you need it for Octave 2.9, use the octave2.9-forge package. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (700, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) This package will be maintained by the Debian Octave Group on Alioth. This package is already in the archive as 'octave-forge'. We will introduce a similar package compiled for Octave 2.9, therefore the new package. Regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376187: ITP: isomd5sum -- ISO/block-level checksum utilities
Package: wnpp Severity: wishlist Owner: Ryan Finnie <[EMAIL PROTECTED]> * Package name: isomd5sum Version : 11.1.0.50 Upstream Author : Jeremy Katz <[EMAIL PROTECTED]> * URL : http://fedora.redhat.com/projects/anaconda-installer/ * License : GPL Programming Lang: C, Python Description : ISO/block-level checksum utilities isomd5sum is a set of utilities for implanting a MD5-like checksum in an ISO (or any block device), then verifying the checksum later. isomd5sum is part of Anaconda; when you boot a RH/Fedora installer and select "verify cd", it's running isomd5sum. isomd5sum is actually a subdirectory of the Anaconda tarball (anaconda-11.1.0.50.tar.bz2 as of this writing). I am currently working on packaging so anaconda=11.1.0.50-1 is the source package, while isomd5sum=11.1.0.50-1 is the binary package. Essentially a multi-binary package with only one binary package (now), if that makes sense. That way, if any other part of Anaconda proves to be useful, multiple binary packages can be associated with the anaconda source package. And before anybody asks, this has nothing to do with bug #222917. I have no intention of packaging the RH Anaconda installer itself; it's just that one of the sets of utilities embedded within anaconda are useful on its own. I am not a Debian developer, and this is my first ITP, so I will need someone to yell at me for the inevitable incorrect packaging methods when I do submit the package. :) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (100, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 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]
Re: Dropping indirect dependencies from libgnutls-config --libs
On Fri, Jun 30, 2006 at 03:42:12PM +0200, Martijn van Oosterhout wrote: > It is also used to compile contrib modules that are included in the > distribution. If you started using pkg-config you'd have introduced a > build dependancy on a GPL'd program in a BSD licenced package, not > exactly a good idea. This issue was discussed when X.org decided to use pkg-config (they didn't want to depend on a GPLed program either), and there is a MIT-licensed pkg-config reimplementation available at http://ktown.kde.org/~zrusin/pkg-config.tar.bz2 I've never tried it but it should be command-line compatible with the original pkg-config. Maybe someone could package it for Debian to solve the license concerns. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reclaiming automake
On (29/06/06 19:37), Eric Dorland wrote: > * Scott James Remnant ([EMAIL PROTECTED]) wrote: > > On Sun, 2006-06-25 at 19:11 -0400, Eric Dorland wrote: > > > > > Scott James Remnant dropped me an email recently, interested in > > > improving the automake situation in Ubuntu and Debian[0]. > > > > > > [0] Their plan, which mirrors mine, is documented here: > > > https://wiki.ubuntu.com/AutomakeTransition It would be good if you could make a page or two on the Debian wiki. One with the details about what must happen and what must be checked, perhaps with lists of packages that can be claimed and then marked appropriately. It would also be good to have a page that bug reports that are filed can reference, so that the maintainers have a clear about what is supposed to happen. Are the instructions at the bottom of the referenced Ubuntu page exact enough for you? > > > Now before I can implement this master plan, I need to fix all the > > > packages that still build depend on "automake"[1]. To proceed with > > > this I'd like to file wishlist bugs (with patches) against these > > > packages one week from today. One week after that, with the Release > > > Team's blessing, I'd like to start NMUing as much of these packages as > > > I can. Once that is complete, I'd like to make the transition and > > > raise the severity of any of bugs that remain. > > > > > We should probably work together to cut the time down to make these > > patches. > > I'm going to get started on Saturday, and I'll be on IRC > (#debian-devel) so if you (or anyone) want to join in the fun, we can > coordinate there. I've just filed #376047 too, so any bugs filed > should be made to block that one. > I will help out where possible. I will hopefully email you later with information on the packages that were referenced as [1] (snipped) that might help you out as well. James -- James Westby [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping indirect dependencies from libgnutls-config --libs
Martijn van Oosterhout wrote: [making foo-config a wrapper around pkg-config] > If you started using pkg-config you'd have introduced a > build dependancy on a GPL'd program in a BSD licenced package, not > exactly a good idea. [...] That is something I hadn't thought about, gnutls is LGPL. Thanks. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
* Mike Hommey: >> The fix is to combine the diffs before applying them, so that you only >> need one process the large Packages file once. I happen to have ML >> code which does this (including the conversion to a patch >> representation which is more amenable to this kind of optimization) >> and would be willing to port it to C++, but someone else would need to >> deal with the APT integration because I'm not familiar with its >> architecture. > > You're looking for combinediff in the patchutils package. combinediff doesn't work for the ed patches used by APT. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Booting - new idea?
On Fri, 30 Jun 2006 13:25:39 -0300 "Gustavo Franco" <[EMAIL PROTECTED]> wrote: > On 6/30/06, Mike Hommey <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 30, 2006 at 11:54:42AM +0200, Tim Dijkstra > > <[EMAIL PROTECTED]> wrote: > > > On Thu, 29 Jun 2006 15:14:07 -0300 > > > "Gustavo Franco" <[EMAIL PROTECTED]> wrote: > > > > > > > On 6/29/06, Christian Perrier <[EMAIL PROTECTED]> wrote: > > > > > > Software suspend which exists in kernel for several years? > > > > > > > > > > > > > > > And works properly in Debian since what? Weeks? Months?:-) > > > > > > > > It doesn't really work properly anywhere, does it? :-P > > > > > > Has worked properly here very well with suspend2, which isn't in > > > the stock kernel unfortunately. > > > > Has worked properly here very well with whatever is in the debian > > kernel, since 2.6.15 at least. > > > > Well Mike, maybe very well for you not for many users and some kernel > developers[0] agreed. Btw, Greg wrote an article for lwn (major > suspend changes), > read it there if you're subscribed. Really interesting content that > shows the current problems with the kernel implementation (up to > 2.6.17) that should be solved soon, since Linus came up with a > interesting patch. > > [0] = > http://thread.gmane.org/gmane.linux.power-management.general/1884/focus=1884 I didn't read the whole thread, but AFAICS it only talks about a (clever) hack to make debugging suspend-to-ram easier... grts Tim signature.asc Description: PGP signature
Re: code cpustat.c
On Fri, 30 Jun 2006 16:41:05 +0300 (EEST) "Ozgur Karatas" <[EMAIL PROTECTED]> wrote: > Hello, > i want to help as much as i can. i dont know very much but i want to > help debian evolve and improve myself at the same time. i am coding > small applications for this purpose. they could help some. You can read http://www.debian.org/devel/join/ and see what you can do for debian. grts Tim signature.asc Description: PGP signature
Re: These new diffs are great, but...
On Fri, Jun 30, 2006 at 06:29:40PM +0200, Florian Weimer <[EMAIL PROTECTED]> wrote: > * Marc Haber: > > > The machine in Question is a P3 with 1200 MHz. What's making the > > process slow is the turnaround time for the http requests, as observed > > multiple times in this thread alone. > > Then your setup is very broken. APT performs HTTP pipelining. > > On my machines, I see the behavior Miles described: lots of disk I/O. > Obviously, APT reconstructs every intermediate version of the packages > file. > > The fix is to combine the diffs before applying them, so that you only > need one process the large Packages file once. I happen to have ML > code which does this (including the conversion to a patch > representation which is more amenable to this kind of optimization) > and would be willing to port it to C++, but someone else would need to > deal with the APT integration because I'm not familiar with its > architecture. You're looking for combinediff in the patchutils package. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
* Marc Haber: > The machine in Question is a P3 with 1200 MHz. What's making the > process slow is the turnaround time for the http requests, as observed > multiple times in this thread alone. Then your setup is very broken. APT performs HTTP pipelining. On my machines, I see the behavior Miles described: lots of disk I/O. Obviously, APT reconstructs every intermediate version of the packages file. The fix is to combine the diffs before applying them, so that you only need one process the large Packages file once. I happen to have ML code which does this (including the conversion to a patch representation which is more amenable to this kind of optimization) and would be willing to port it to C++, but someone else would need to deal with the APT integration because I'm not familiar with its architecture. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Booting - new idea?
On Fri, Jun 30, 2006 at 01:25:39PM -0300, Gustavo Franco <[EMAIL PROTECTED]> wrote: > On 6/30/06, Mike Hommey <[EMAIL PROTECTED]> wrote: > >On Fri, Jun 30, 2006 at 11:54:42AM +0200, Tim Dijkstra > ><[EMAIL PROTECTED]> wrote: > >> On Thu, 29 Jun 2006 15:14:07 -0300 > >> "Gustavo Franco" <[EMAIL PROTECTED]> wrote: > >> > >> > On 6/29/06, Christian Perrier <[EMAIL PROTECTED]> wrote: > >> > > > Software suspend which exists in kernel for several years? > >> > > > >> > > > >> > > And works properly in Debian since what? Weeks? Months?:-) > >> > > >> > It doesn't really work properly anywhere, does it? :-P > >> > >> Has worked properly here very well with suspend2, which isn't in the > >> stock kernel unfortunately. > > > >Has worked properly here very well with whatever is in the debian > >kernel, since 2.6.15 at least. > > > > Well Mike, maybe very well for you not for many users and some kernel > developers[0] agreed. Btw, Greg wrote an article for lwn (major > suspend changes), > read it there if you're subscribed. Really interesting content that shows > the > current problems with the kernel implementation (up to 2.6.17) that should > be solved soon, since Linus came up with a interesting patch. > > [0] = > http://thread.gmane.org/gmane.linux.power-management.general/1884/focus=1884 Hum, this is about suspend to ram, not suspend to disk. Though suspend to ram has been working almost flawlessly for me since 2.6.9 or 2.6.10. (sometimes it freezes at wakeup time). I don't really care if the kernel developpers say it's badly done. It just works. That's all I'm asking. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Booting - new idea?
On 6/30/06, Mike Hommey <[EMAIL PROTECTED]> wrote: On Fri, Jun 30, 2006 at 11:54:42AM +0200, Tim Dijkstra <[EMAIL PROTECTED]> wrote: > On Thu, 29 Jun 2006 15:14:07 -0300 > "Gustavo Franco" <[EMAIL PROTECTED]> wrote: > > > On 6/29/06, Christian Perrier <[EMAIL PROTECTED]> wrote: > > > > Software suspend which exists in kernel for several years? > > > > > > > > > And works properly in Debian since what? Weeks? Months?:-) > > > > It doesn't really work properly anywhere, does it? :-P > > Has worked properly here very well with suspend2, which isn't in the > stock kernel unfortunately. Has worked properly here very well with whatever is in the debian kernel, since 2.6.15 at least. Well Mike, maybe very well for you not for many users and some kernel developers[0] agreed. Btw, Greg wrote an article for lwn (major suspend changes), read it there if you're subscribed. Really interesting content that shows the current problems with the kernel implementation (up to 2.6.17) that should be solved soon, since Linus came up with a interesting patch. [0] = http://thread.gmane.org/gmane.linux.power-management.general/1884/focus=1884 regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Booting - new idea?
On Fri, Jun 30, 2006 at 11:54:42AM +0200, Tim Dijkstra <[EMAIL PROTECTED]> wrote: > On Thu, 29 Jun 2006 15:14:07 -0300 > "Gustavo Franco" <[EMAIL PROTECTED]> wrote: > > > On 6/29/06, Christian Perrier <[EMAIL PROTECTED]> wrote: > > > > Software suspend which exists in kernel for several years? > > > > > > > > > And works properly in Debian since what? Weeks? Months?:-) > > > > It doesn't really work properly anywhere, does it? :-P > > Has worked properly here very well with suspend2, which isn't in the > stock kernel unfortunately. Has worked properly here very well with whatever is in the debian kernel, since 2.6.15 at least. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#374968: ITP: castpodder -- Multithreaded GUI Podcast Receiver
On Fri, Jun 30, 2006 at 03:15:03PM +0200, Hilko Bengen wrote: > John Goerzen <[EMAIL PROTECTED]> writes: > > > CastPodder is a fork and enhancement of the popular iPodder > > podcast receiver. > > I already packaged and uploaded castpodder. However, it was rejected > because copyright statement and licenses to files in the contrib/ > directory were missing. > > If you manage to find those, just let me know. I subsequently withdrew this ITP due primarily to the bugginess of castpodder. (It was nicer than ipodder, but not good enough.) That's why I wrote hpodder. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Fri, Jun 30, 2006 at 12:12:10PM +0200, Adam Borowski wrote:
> Oh, so you mean checking the _free_ RAM instead of the _physical_ RAM?
> This would be reasonable -- I didn't use this in the debian/rules
> snippet I proposed as the physical memory is a trivially discernable
> number while free RAM can be sometimes hard to tell, especially on Xen:
[...]
> Of course, when I say that something is tricky, it doesn't mean that
> someone with more clue than me can't do it.
[...]
Just grep it out of /proc/meminfo? Something like this ugly bit of
bourne shell:
echo $(
grep ^MemTotal: /proc/meminfo | awk '{ print $2 }'
) - $(
grep ^MemFree: /proc/meminfo | awk '{ print $2 }'
) - $(
grep ^Buffers: /proc/meminfo | awk '{ print $2 }'
) - $(
grep ^Cached: /proc/meminfo | awk '{ print $2 }'
) | bc
Which would give you a count of the total kb minus what's free and
in use for buffers/cache, similar to what free(1) spits out, but
probably not identical. That might not be an option on older kernels
(I seem to remember dealing with some /proc/meminfo change a while
back that broke check_swap in nagios-plugins), or at least might
differ at particular points in the kernel's release history.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
On Fri, Jun 30, 2006 at 04:55:58PM +0200, Martin Schulze wrote: > You know that you can easily turn off this feature by adjusting apt.conf: Sure, and I've done so for several of my machines now. Actually, for many enough machines that it's becoming bothersome... /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
On (30/06/06 10:51), Jaldhar H. Vyas wrote: > Following up to myself with a proper subject line. > > In bug #376146, Martin Pitt wrote: > > > In an effort to clean up the SSL certificate mess on Ubuntu servers, we > > recently converted all our supported Server packages to make use of > > the ssl-cert package instead of creating a package-specific > > self-signed SSL certificate. This allows admins to easily replace the > > certificate with a 'real' one without touching dozens of configuration > > files, and also provides a consistent setup out of the box. > > Is this is a good idea for Debian? I hadn't seen the package before and it looks pretty decent. I think it would help get some consistency between all of the packages that have to create certs. It could perhaps even be wrapped up in to a debhelper tool if it is widespread enough. > I think it is but it doesn't make sense > to switch dovecot over unless all the other ssl-cert using packages also do > it. Is this possible in the etch timeframe? I'm not sure, and maybe it's not the time to be trying to do this. Has anyone got a suggestion for a way to find the list of packages that generate a certificate in their postinst? That would help the decision. James -- James Westby [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
Steinar H. Gunderson wrote:
> On Thu, Jun 29, 2006 at 08:35:41PM +0200, martin f krafft wrote:
> > Not really. pdiff's mainly reduce download size for low bandwidth
> > connections. file:// is pretty high bandwidth, you won't notice the
> > difference.
>
> I usually notice the difference -- the other way. "aptitude update" on a
> machine that hasn't been updated in a while suddenly takes minutes instead of
> seconds...
You know that you can easily turn off this feature by adjusting apt.conf:
Acquire::Pdiffs { "false"; };
Regards,
Joey
--
Those who don't understand Unix are condemned to reinvent it, poorly.
Please always Cc to me when replying to me on the lists.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Using the SSL snakeoil certificate
Following up to myself with a proper subject line. In bug #376146, Martin Pitt wrote: In an effort to clean up the SSL certificate mess on Ubuntu servers, we recently converted all our supported Server packages to make use of the ssl-cert package instead of creating a package-specific self-signed SSL certificate. This allows admins to easily replace the certificate with a 'real' one without touching dozens of configuration files, and also provides a consistent setup out of the box. Is this is a good idea for Debian? I think it is but it doesn't make sense to switch dovecot over unless all the other ssl-cert using packages also do it. Is this possible in the etch timeframe? -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Unidentified subject!
In bug #376146, Martin Pitt wrote: In an effort to clean up the SSL certificate mess on Ubuntu servers, we recently converted all our supported Server packages to make use of the ssl-cert package instead of creating a package-specific self-signed SSL certificate. This allows admins to easily replace the certificate with a 'real' one without touching dozens of configuration files, and also provides a consistent setup out of the box. Is this is a good idea for Debian? I think it is but it doesn't make sense to switch dovecot over unless all the other ssl-cert using packages also do it. Is this possible in the etch timeframe? -- 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]
cdrtools
Hi all, are there any activities on that project? There is no mailinglist active at https://alioth.debian.org/projects/pkg-cdrtools/ and the latest cvs-entry is about 3 months ago or so. Meanwhile we have ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a10.tar.gz # apt-cache policy cdrecord gives: cdrecord: Installed: 4:2.01+01a03-5 Candidate: 4:2.01+01a03-5 Version table: *** 4:2.01+01a03-5 0 500 ftp://ftp.de.debian.org testing/main Packages 990 ftp://ftp.de.debian.org unstable/main Packages 100 /var/lib/dpkg/status which is full of bugs. Will the package be orphande next time? Elimar -- Learned men are the cisterns of knowledge, not the fountainheads ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: code cpustat.c
Or uptime(1)CesareOn 6/30/06, Sebastian Harl <[EMAIL PROTECTED]> wrote: > ps and top command gives the ram state. i am doing this to see cpu's load> and usage.As far as I can see it, you're reading the exact same information as top(1)...
Re: News from the python policy transition
On 6/29/06, Sam Morris <[EMAIL PROTECTED]> wrote: On Thu, 29 Jun 2006 16:25:17 +0200, Pierre Habouzit wrote: > Le mer 28 juin 2006 23:20, Raphael Hertzog a écrit : >> So you don't have any excuse to not update your packages any more. >> About 60% of the Python modules have already been updated, but 109 >> are left to be done: >> http://bugs.debian.org/from:[EMAIL PROTECTED] >> >> The bugs have been filled two weeks ago, it is now time to NMU the >> remaining packages where the maintainer didn't gave any update plan >> in the bug report. We need your help for that. > > I've done 16 of them already. that has also fixed 2 RC bugs as a side > effect (uninstallability bugs). > > 7 other person like me, and it's old story ! I noticed the original list didn't include the python-gmenu package. The source package (gnome-menus) produces some regular machine code packages as well as the python module package. Perhaps there are others like this? The gnome-menus bug is #373435, i dunno if there are others without the bugs, but you're welcome to redo the scan and let us know. thanks, -- stratus
Re: These new diffs are great, but...
* Marc Haber ([EMAIL PROTECTED]) [060630 10:58]: > On Fri, 30 Jun 2006 08:44:30 +0200, Martin Michlmayr <[EMAIL PROTECTED]> > wrote: > >Your guess is correct, see #372504. "This is currently a UI problem. > >It displays the line three times, but it only downloads it in the > >first. The other two lines are unpack and rred (patch)." > > So the "rred" is not a badly formatted and partially overwritten > "transferred" but an actual string? it's a restricted version of ed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: code cpustat.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ozgur Karatas wrote: > Re, > ps and top command gives the ram state. i am doing this to see cpu's load > and usage. > regards. But top(1) also does that, no? Or is the difference that it is a "running total", like ping? Still, this app is so small that it shouldn't(?) go in it's own package. moreutils seems like a good place to put it. You'll have to create a man page for it, though, and specify how you've licensed it. >> top(1) gives the exact same information. What's the advantage of your >> program? - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEpS4hS9HxQb37XmcRAvMzAJwO4YzWJubxV50xeB4v/A0G42vauACgrH5d uuqumX4csDb07INIdYQlEBA= =g+Qt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: code cpustat.c
On Fri, Jun 30, 2006 at 04:18:58PM +0300, Ozgur Karatas wrote: > ps and top command gives the ram state. i am doing this to see cpu's load > and usage. top reports these. For example: | Tasks: 112 total, 2 running, 109 sleeping, 1 stopped, 0 zombie | Cpu(s): 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Booting - new idea?
On 6/30/06, Tim Dijkstra <[EMAIL PROTECTED]> wrote: On Thu, 29 Jun 2006 15:14:07 -0300 "Gustavo Franco" <[EMAIL PROTECTED]> wrote: > On 6/29/06, Christian Perrier <[EMAIL PROTECTED]> wrote: > > > Software suspend which exists in kernel for several years? > > > > > > And works properly in Debian since what? Weeks? Months?:-) > > It doesn't really work properly anywhere, does it? :-P Has worked properly here very well with suspend2, which isn't in the stock kernel unfortunately. Oh, ok but my comment was about our kernel really. Now it also works very well here with vanilla kernel 2.6.17 and the debian package for uswsusp which I've packaged. You can try them out if you like (you need a 2.6.17 kernel), http://www.famdijkstra.org/~tdykstra/debian/uswsusp But I hope they'll get uploaded very soon. I'll take a look thanks, but did you see the recent discussion in lkml ? Linus came up with a patch to definitely solve some of the problems with the suspend model. AFAIK, it's not yet into his tree or mm, but i hope to see the changes merged in time for 2.6.18, really cool stuff there. I think you can read a summary by Greg at lwn. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: code cpustat.c
> ps and top command gives the ram state. i am doing this to see cpu's load > and usage. As far as I can see it, you're reading the exact same information as top(1)... -- Sebastian "tokkee" Harl GnuPG-ID: 0x8501C7FC http://tokkee.org/ signature.asc Description: Digital signature
Re: Dropping indirect dependencies from libgnutls-config --libs
On 6/30/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote: | 4. Custom config tools can often provide more info than available in | pkg-config (plugin or config directories). Like: : [EMAIL PROTECTED] ~ > pkg-config --variable=system_bus_default_address dbus-1 unix:path=/var/run/dbus/system_bus_socket Sure, but to take an example, PostgreSQL has had pg_config for ages and other projects use this to get the necessary parameters to compile against the installed version. There is no way pkg-config can copy the current set of command line arguments, so you have a backward compatability issue. Also, what you suggest is not exactly shorter. It is also used to compile contrib modules that are included in the distribution. If you started using pkg-config you'd have introduced a build dependancy on a GPL'd program in a BSD licenced package, not exactly a good idea. pkg-config is nice for the constellation of GPL'd libraries currently installed on most linux systems, but once you step outside of that it's not quite as useful. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: code cpustat.c
Hello, i want to help as much as i can. i dont know very much but i want to help debian evolve and improve myself at the same time. i am coding small applications for this purpose. they could help some. > On Fri, 30 Jun 2006 16:18:58 +0300 (EEST) > "Ozgur Karatas" <[EMAIL PROTECTED]> wrote: > >> Re, >> ps and top command gives the ram state. i am doing this to see cpu's >> load and usage. > > > huh? > > My top shows (admittedly not on my desktop machine;) shows: > > 15:31:22 up 50 days, 2:41, 2 users, load average: 3,81, 3,85, 3,86 > 75 processes: 70 sleeping, 5 running, 0 zombie, 0 stopped > CPU states: cpuusernice systemirq softirq iowaitidle >total 99,9%0,0%0,0% 0,0% 0,0%0,0%0,0% >cpu00 100,0%0,0%0,0% 0,0% 0,0%0,0%0,0% >cpu01 100,0%0,0%0,0% 0,0% 0,0%0,0%0,0% >cpu02 99,8%0,0%0,2% 0,0% 0,0%0,0%0,0% >cpu03 100,0%0,0%0,0% 0,0% 0,0%0,0%0,0% > Mem: 15658564k av, 15618992k used, 39572k free, 0k shrd, 1138248k > buff >10379544k actv, 3661724k in_d, 412448k in_c > Swap: 2048276k av, 1134532k used, 913744k free 5722464k > cached > > which will give the cpu load just fine... > > grts Tim ,''`. Ozgur Karatas : :' : [EMAIL PROTECTED] `. `' http://www.ozgurkaratas.com `-Powered By Debian GNU\Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
On Fri, 30 Jun 2006 11:10:37 +0200, Eduard Bloch <[EMAIL PROTECTED]> wrote: >* Marc Haber [Fri, Jun 30 2006, 08:00:57AM]: >> file:// URLs are not the only issue here - aptitude update is also >> much slower than before on a hosted box which has 100 Mbit/s >> connectivity and could load the Packages.gz in, like, two seconds. > >I have doubts, have you measured the real difference? If you box is >already to slow for patching then it would have fun with bzip2 as well. The machine in Question is a P3 with 1200 MHz. What's making the process slow is the turnaround time for the http requests, as observed multiple times in this thread alone. 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: code cpustat.c
On Fri, 30 Jun 2006 16:18:58 +0300 (EEST) "Ozgur Karatas" <[EMAIL PROTECTED]> wrote: > Re, > ps and top command gives the ram state. i am doing this to see cpu's > load and usage. huh? My top shows (admittedly not on my desktop machine;) shows: 15:31:22 up 50 days, 2:41, 2 users, load average: 3,81, 3,85, 3,86 75 processes: 70 sleeping, 5 running, 0 zombie, 0 stopped CPU states: cpuusernice systemirq softirq iowaitidle total 99,9%0,0%0,0% 0,0% 0,0%0,0%0,0% cpu00 100,0%0,0%0,0% 0,0% 0,0%0,0%0,0% cpu01 100,0%0,0%0,0% 0,0% 0,0%0,0%0,0% cpu02 99,8%0,0%0,2% 0,0% 0,0%0,0%0,0% cpu03 100,0%0,0%0,0% 0,0% 0,0%0,0%0,0% Mem: 15658564k av, 15618992k used, 39572k free, 0k shrd, 1138248k buff 10379544k actv, 3661724k in_d, 412448k in_c Swap: 2048276k av, 1134532k used, 913744k free 5722464k cached which will give the cpu load just fine... grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#374968: ITP: castpodder -- Multithreaded GUI Podcast Receiver
John Goerzen <[EMAIL PROTECTED]> writes: > CastPodder is a fork and enhancement of the popular iPodder > podcast receiver. I already packaged and uploaded castpodder. However, it was rejected because copyright statement and licenses to files in the contrib/ directory were missing. If you manage to find those, just let me know. Cheers, -Hilko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: code cpustat.c
Re, ps and top command gives the ram state. i am doing this to see cpu's load and usage. regards. > top(1) gives the exact same information. What's the advantage of your > program? > > Cheers, > Sebastian > > -- > Sebastian "tokkee" Harl > GnuPG-ID: 0x8501C7FC > http://tokkee.org/ ,''`. Ozgur Karatas : :' : [EMAIL PROTECTED] `. `' http://www.ozgurkaratas.com `-Powered By Debian GNU\Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: code cpustat.c
> This code is written to > take CPU loading statistics. cpustat; shows the usage load statistic of > your CPU. top(1) gives the exact same information. What's the advantage of your program? Cheers, Sebastian -- Sebastian "tokkee" Harl GnuPG-ID: 0x8501C7FC http://tokkee.org/ signature.asc Description: Digital signature
code cpustat.c
Hello,
I have written a program which gives CPU statistics, then what should i do
for putting this program in to the debian? This code is written to
take CPU loading statistics. cpustat; shows the usage load statistic of
your CPU. I Code tested for Intel Processors. After then code will be
ported for AMD. Can we add this debian?
$vi cpustat.c
/*
* /linux/fs/cpustat.c
*
* Copyright (C) 2006 Ozgur Karatas
*/
/*
* This code is written to take CPU statistics. cpustat; shows the usage
statistic of your CPU.
* The Code tested for Intel Processors. After then code will be ported
for AMD.
*/
#include
int main (void)
{
FILE *fp;
char *str;
char buf[1000];
unsigned long long int c_user = 0;
unsigned long long int c_user_ = 0;
unsigned long long int c_nice = 0;
unsigned long long int c_nice_ = 0;
unsigned long long int c_sys = 0;
unsigned long long int c_sys_ = 0;
unsigned long long int c_idle = 0;
unsigned long long int c_idle_ = 0;
double u;
double n;
double s;
double i;
double t;
again:
fp = fopen("/proc/stat", "r");
while (!feof(fp)) {
fgets(buf, sizeof(buf), fp);
if (strncmp(buf, "cpu ", 4) == 0) {
break;
}
}
fclose(fp);
c_user_ = c_user;
c_nice_ = c_nice;
c_sys_ = c_sys;
c_idle_ = c_idle;
str = buf + 4;
c_user = strtoull(str, &str, 0);
c_nice = strtoull(str, &str, 0);
c_sys = strtoull(str, &str, 0);
c_idle = strtoull(str, &str, 0);
if (c_user == 0 &&
c_nice == 0 &&
c_sys == 0 &&
c_idle == 0) {
goto again;
}
u = (float) (c_user - c_user_);
n = (float) (c_nice - c_nice_);
s = (float) (c_sys - c_sys_);
i = (float) (c_idle - c_idle_);
t = u + n + s + i;
u = (u * 100) / t;
n = (n * 100) / t;
s = (s * 100) / t;
i = (i * 100) / t;
printf("total:%.1f user:%.1f nice:%.1f sys:%.1f idle:%.1f\n", t, u, n,
s,
i);
sleep(1);
goto again;
return 0;
}
--
,''`. Ozgur Karatas
: :' : [EMAIL PROTECTED]
`. `' http://www.ozgurkaratas.com
`-Powered By Debian GNU\Linux
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reclaiming automake
On Thu, 2006-06-29 at 19:37 -0400, Eric Dorland wrote: > * Scott James Remnant ([EMAIL PROTECTED]) wrote: > > On Sun, 2006-06-25 at 19:11 -0400, Eric Dorland wrote: > > > > > Scott James Remnant dropped me an email recently, interested in > > > improving the automake situation in Ubuntu and Debian[0]. > > > > > > [0] Their plan, which mirrors mine, is documented here: > > > https://wiki.ubuntu.com/AutomakeTransition > > > > > If you could have another read through of that spec, now it's > > post-draft, and make sure we're still both planning the same thing > > that'd be great. I don't see any reason for Ubuntu to go a different > > direction to Debian here. > > > > In particular I had a momentary thought about what packages should > > actually depend/build-depend on now -- could you check that. > > The automaken | automake$VER is probably not wise. A new version of > automake may not be fully backwards compatible. If it were, we > wouldn't have these problems. Better to depend on a known version that > works, or better still don't build depend on it at all and ship the > generated files in the diff.gz. > I'd personally tend to err on the "assume it is, unless it isn't" -- would you suggest all packages be changed to not B-D on automaken then? > I'm going to get started on Saturday, and I'll be on IRC > (#debian-devel) so if you (or anyone) want to join in the fun, we can > coordinate there. I've just filed #376047 too, so any bugs filed > should be made to block that one. > The disadvantage of doing this for a living, rather than for fun, is that weekends tend to be out :) I'll pick up on Monday :p Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Debian mactel linux support?
Junichi Uekawa <[EMAIL PROTECTED]> wrote: > Your bug is meant to be already fixed (#355252), but I see there are > some deviations between Debian and Ubuntu (which you seem to > maintain), I'm suspecting there might be problems with Debian code > which is only updated about 3 months ago. Ok, that's a possibility - there were a few patches, and we may have ended up applying slightly different ones. > I thought EFI should work with FAT (I was surprised to see blessing > can be applied to HFS+ also), which is the first partition on the > internal disk. There's two different mechanisms of booting a file under the Mac EFI - you can either put the filename in nvram, or you can bless a file. I believe that the blessing can only be done on HFS+ filesystems. > I'm hoping that I can switch default boot through some kind of nvram > setting. You can, but you can't get into the firmware interface without having blessed a file first. Which needs MacOS right now. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new tar behavior and --wildcards
On Wed, Jun 28, 2006 at 10:36:20AM +0200, Bill Allombert wrote: > On Wed, Jun 28, 2006 at 07:02:15AM +0200, Christian Perrier wrote: > > > Debian still has to provide an upgrade path for users upgrading from > > > Sarge. > > > We cannot blindly break users scripts. > > > > Here, the only way seems to be putting an entry in NEWS.Debian (for > > users script, ie things not under our control). > > In addition, I would suggest we reinstate the previous behaviour, but > display a warning when wildcards are used but --wildcards is not set. > The warning would tell people about the migration and explains they must > fix their scripts to use --wildcards before upgrading to etch+1. I can only second that - we really should support our users at least that much (see point 4 in the social contract). Breaking users' scripts in these ways needs more than a simple note in NEWS.Debian (you'll get dozens of them when upgrading from sarge to etch). Cheers, -- Guido signature.asc Description: Digital signature
Re: make -j in Debian packages
On Fri, Jun 30, 2006 at 08:41:33AM +0200, Ingo Juergensmann wrote: > On Fri, Jun 30, 2006 at 03:22:48AM +0200, Goswin von Brederlow wrote: > > The same can't be said for upstream makefiles though. Many sources > > don't build with -j option. Right, that's just what I said :p It's the upstream and the maintainer who know whether -j is safe or not -- the end-user or buildd are not expected to guess this. What the end-user and buildd are supposed to have to say about is whether they want a fast or a low-mem build. > > I'm not sure if debian/rules should somehow enforce -j1 in those > > cases That would be opt-out, and everyone here seems to be against it in this place. Just let's not confuse maintainer's opt-foo and the builder's opt-foo. > > or if only packages that benefit from -jX should add support for > > some DEB_BUILD_OPTION or CONCURENCY_LEVEL env var. The later > > would always be the save option. The former would have lots of > > hidden bugs that prop up suddenly on rebuilds or security fixes. Hell yeah. > I'm strictly in favour of being on the safe side. If maintainers > would start now to add -j4 to their makefiles, we would end in more > FTBFS bugs, It's them who are supposed to have a clue whether their packages can handle -j or not. If they are wrong, well, unlike typical SMP issues, this is actually a bug which is pretty likely to pop up in the first build. This means before the upload is actually done, or, for abysmal maintainers, when the faster autobuilders get the package. > When we want to introduce some sort of concurrency builds, we > should do it that way that the impact is as small as possible > (opt-in). Start with some packages that are known to build fine > with -jX and choose 1-2 buildds on some archs to implement this > feature for a small test. Good idea. That's why I started with a small but not tiny (1MB of sources) package of very little importance. It appears to build fine, and when I built it on a box with 24MB of memory, the machine didn't croak. So, here: take either this test package (kbtin), or, even better, take the snippet between the marked () lines in debian/rules and apply it to a bigger package. I claim that it will handle both small and big machines well by default, and obey CONCURRENCY_LEVEL if it's set. This is not "intelligent design", there is a clear way to prove my claims false. > > Maybe someone should do a complete archive rebuild with -j1 and -j4 on > > a smp system and compare the amount of failures to get an overview how > > bad it would be. Ugh, wrong. A "complete archive rebuild" won't do anything if the change is done in debian/rules, and it is known to be a bad idea for any non-SMP-clean package already. We're talking about allowing the maintainers to enable their packages to make use of concurrency if they believe that: 1. their packages are SMP-safe 2. the amount of memory taken won't exceed like 128-256MB. > > > Thus, my counter-proposal: > > > Let's allow maintainers to use make -jX according to their common > > > sense, requiring obeying an env variable to opt out. > > and let the maintainer pass that env variable down a -jX. > > How about this option: > > We write a tool "concurency-helper" that gets a set of requirements of > > the source and outputs a suitable concurency level for current build > > host. Requirements could include: > > --package pkg > >Let the tool know what we build. The tool can have overrides in > >place for packages in case special rules apply. > > --max-concurency X || --non-concurent > >Limit the concurency, possibly to 1, for sources that have problems > >with it. Although such sources probably just shouldn't support this. > > --ram-estimate X [Y] > >Give some indication of ram usage. If the host has too little ram > >the concurency will be tuned down to prevent swapping. A broad > >indication +- a factor of 2 is probably sufficient. The [Y] would > >be to indicate ram usage for 32bit and 64bit archs seperately. > >Given the pointer size ram usage can vary between them a lot. > > --more-concurent > >Indicate that there are lots of small files that greatly benefit > >from interleaving I/O with cpu time. Try to use more concurency > >than cpus. > > The tool would look at those indicators and the hosts resources in > > both ram and cpus and figure out a suitable concurency level for the > > package from there. > > What do you think? > > Of course this is a more complex approach, but I think it's an approach into > the right direction. I would like to have settings for distcc to get added > (like --use-distcc and --distcc-hosts) A good idea. My proposal was to keep it simple, at the cost of being too cowardly when distcc is in use. If the helper is stored in a common place, this would also handle duplication of code. > > > Rationale: > > > Nearly every buildd and nearly every user building the packages on > > > his own wil
Re: make -j in Debian packages
On Fri, Jun 30, 2006 at 03:26:15AM +0200, Goswin von Brederlow wrote: > Adam Borowski <[EMAIL PROTECTED]> writes: > > Still, the buildd admin has no way to estimate how much a sub-process > > of a package is going to use, the maintainer has at least a rough > > idea. Since the maintainer's action is needed anyway, he can as well > > provide this estimate. > > And then the buildd admin can set CONCURRENCY_LEVEL to 1 to centrally > > disable any parallelism of this kind. > > One could patch make to use concurency when the ram permits. This > would involves checking the current ram usage and forking more builds > if there is enough Oh, so you mean checking the _free_ RAM instead of the _physical_ RAM? This would be reasonable -- I didn't use this in the debian/rules snippet I proposed as the physical memory is a trivially discernable number while free RAM can be sometimes hard to tell, especially on Xen: Mem:588472k total, 574028k used,1k free,4k buffers Swap: 1048568k total, 24k used, 1048544k free, 238984k cached this is on a box where the only currently accessed process is mutt (+sshd and $EDITOR). Who cares if apache's processes which didn't handle a single request in two months (the real server is elsewhere) are in the physical memory? Who cares about idle dovecot? The box is for all practical purposes completely idle as of right now. Of course, when I say that something is tricky, it doesn't mean that someone with more clue than me can't do it. > as well as suspending submakes when swapping starts. But i guess > that would greatly complicate make itself. Actually, make -l already does something very similar. It stops -j from forking any new processes (above 1) once the system load exceeds a given value. And while the "system load" is a lousy measure, make won't ever starve off the build, it will in the worst case behave as make -j1, which is what Ingo wants. Cheers and schtuff, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping indirect dependencies from libgnutls-config --libs
* "Martijn van Oosterhout" | On 6/30/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote: | > Is there a reason why gnutls-config and xml2-config aren't just tiny | > wrappers around pkg-config for backwards compatibility? IMO, it's | > kinda silly to have each package provide its own -config script with | > its own set of bugs, rather than having a shared set of bugs in | > pkg-config. :-) | | 1. Maybe they need to work on systems where pkg-config isn't available That should be nowhere; pkg-config is written to be portable. | 2. Maybe they predate the existance of pkg-config They can still be transitioned to use pkg-config now. | 3. Some of the pkg-config bugs were bad enough as to make you want | to avoid it Probably not, but if so they should file bugs and help get them fixed. | 4. Custom config tools can often provide more info than available in | pkg-config (plugin or config directories). Like: : [EMAIL PROTECTED] ~ > pkg-config --variable=system_bus_default_address dbus-1 unix:path=/var/run/dbus/system_bus_socket ? -- 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: Booting - new idea?
On Thu, 29 Jun 2006 15:14:07 -0300 "Gustavo Franco" <[EMAIL PROTECTED]> wrote: > On 6/29/06, Christian Perrier <[EMAIL PROTECTED]> wrote: > > > Software suspend which exists in kernel for several years? > > > > > > And works properly in Debian since what? Weeks? Months?:-) > > It doesn't really work properly anywhere, does it? :-P Has worked properly here very well with suspend2, which isn't in the stock kernel unfortunately. Now it also works very well here with vanilla kernel 2.6.17 and the debian package for uswsusp which I've packaged. You can try them out if you like (you need a 2.6.17 kernel), http://www.famdijkstra.org/~tdykstra/debian/uswsusp But I hope they'll get uploaded very soon. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
#include * Marc Haber [Fri, Jun 30 2006, 08:00:57AM]: > On Thu, 29 Jun 2006 11:43:45 -0700, Tyler MacDonald <[EMAIL PROTECTED]> > wrote: > >Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: > >> I usually notice the difference -- the other way. "aptitude update" on a > >> machine that hasn't been updated in a while suddenly takes minutes instead > >> of > >> seconds... > > > > Yes, this is what I'm getting at. :-) Should this be considered a > >bug in apt-get (file:// urls should never use diffs)? > > file:// URLs are not the only issue here - aptitude update is also > much slower than before on a hosted box which has 100 Mbit/s > connectivity and could load the Packages.gz in, like, two seconds. I have doubts, have you measured the real difference? If you box is already to slow for patching then it would have fun with bzip2 as well. Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
On Fri, 30 Jun 2006 08:44:30 +0200, Martin Michlmayr <[EMAIL PROTECTED]> wrote: >Your guess is correct, see #372504. "This is currently a UI problem. >It displays the line three times, but it only downloads it in the >first. The other two lines are unpack and rred (patch)." So the "rred" is not a badly formatted and partially overwritten "transferred" but an actual string? 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: Dropping indirect dependencies from libgnutls-config --libs
On 6/30/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote: Is there a reason why gnutls-config and xml2-config aren't just tiny wrappers around pkg-config for backwards compatibility? IMO, it's kinda silly to have each package provide its own -config script with its own set of bugs, rather than having a shared set of bugs in pkg-config. :-) 1. Maybe they need to work on systems where pkg-config isn't available 2. Maybe they predate the existance of pkg-config 3. Some of the pkg-config bugs were bad enough as to make you want to avoid it 4. Custom config tools can often provide more info than available in pkg-config (plugin or config directories). -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping indirect dependencies from libgnutls-config --libs
* Mike Hommey | On Thu, Jun 29, 2006 at 07:38:56PM +0200, Andreas Metzler <[EMAIL PROTECTED]> wrote: | > Hello, | > currently "libgnutls-config --libs"' output looks like this, | > -L/usr/lib -lgnutls -L/usr/lib -ltasn1 -lgcrypt -lgpg-error | > listing both direct (-lgnutls) and indirect dependencies. - Its output | > can be used for static linking. | > | > I am pondering (and have now been asked by bts) on changing this to | > only say -lgnutls for Debian, which is enough for dynamic linking. - | > Static linking would be broken except for | > a) libtool using packages (.la lists the indirect dependencies) | > or | > b) packages using pkg-config --libs --static to get the indirect | > dependencies[1] | | I got a similar report on libxml2, which suggested the use of | xml2-config --libs to get the direct libs and xml2-config --libs | --static to get everything. Same semantics as pkg-config. Is there a reason why gnutls-config and xml2-config aren't just tiny wrappers around pkg-config for backwards compatibility? IMO, it's kinda silly to have each package provide its own -config script with its own set of bugs, rather than having a shared set of bugs in pkg-config. :-) -- 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: News from the python policy transition
Hello, On Wed, 28.06.2006 at 23:20:46 +0200, Raphael Hertzog <[EMAIL PROTECTED]> wrote: > Please look for your name (or your team) in the list below and start > updating those as well! I'm expecting to update roundup this or the next weekend at the latest to fix all currently outstanding bugs, including the new Python transition. Roundup wasn't listed in the first packages list, or I missed it when I looked for it. Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
