Re: Tracking differences between Ubuntu and Debian for a set ofpackages
Il giorno mar, 19/09/2006 alle 20.51 +0200, Daniel Baumann ha scritto: > Hi, > > looks very nice.. do you mind publishing the source? It is on gluck.debian.org, within my home directory, or here: http://people.debian.org/~kobold/ubuntu-diff/bin/ Cheers, -- Fabio Tranchitella <[EMAIL PROTECTED]>.''`. Proud Debian GNU/Linux developer, admin and user.: :' : `. `'` http://people.debian.org/~kobold/ `- _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: Tracking differences between Ubuntu and Debian for a set ofpackages
Fabio Tranchitella wrote: > It is on gluck.debian.org, within my home directory, or here: > > http://people.debian.org/~kobold/ubuntu-diff/bin/ I know I could get it from gluck, but I wanted to be kind and ask before I take it. Thanks a lot, very well done. I'll modify it so that I can track differences between backports and etch, to keep my backports easier uptodate. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking differences between Ubuntu and Debian for a set ofpackages
Il giorno mer, 20/09/2006 alle 10.31 +0200, Daniel Baumann ha scritto: > I know I could get it from gluck, but I wanted to be kind and ask before > I take it. > > Thanks a lot, very well done. I'll modify it so that I can track > differences between backports and etch, to keep my backports easier > uptodate. Fine, that's another good use case. Could you please put it somewhere public? We could have a common area for these "track the differences between distributions" tools? -- Fabio Tranchitella <[EMAIL PROTECTED]>.''`. Proud Debian GNU/Linux developer, admin and user.: :' : `. `'` http://people.debian.org/~kobold/ `- _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: Moving /var/run to a tmpfs?
Hi On Tue, 19 Sep 2006 21:52:12 +0200 "Martijn van Oosterhout" <[EMAIL PROTECTED]> wrote: > Odd, I always thought is was because C did not have enough int types: > > char1 bytes > short 2 bytes > int 4 bytes > long 8 bytes > > If you make an int 8 bytes, you have to find some other way of > indicating one of the shorter types (short short maybe? or long > char?). Nothing says long has to be bigger that int, only thing which is defined is: sizeof(short) <= sizeof(int) <= sizeof(long) so having short, int, long of same size is not a problem. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Tracking differences between Ubuntu and Debian for a set ofpackages
Fabio Tranchitella wrote: > Fine, that's another good use case. Could you please put it somewhere > public? We could have a common area for these "track the differences > between distributions" tools? Sure, I'll do some things within the next few days with it and tell you then. Although I'm mostly just interested in my own packages, a common place would be nice, of course. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On 9/20/06, Michal Čihař <[EMAIL PROTECTED]> wrote: > char1 bytes > short 2 bytes > int 4 bytes > long 8 bytes Nothing says long has to be bigger that int, only thing which is defined is: sizeof(short) <= sizeof(int) <= sizeof(long) so having short, int, long of same size is not a problem. I think you're missing the point. If you make an int 8 bytes, what are you going to call 4 byte integers? If you call them short, what are you going to call 2 byte integers? Anyway, the link to the paper posted in this thread has many much better arguments. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/
Re: Moving /var/run to a tmpfs?
Hi On Wed, 20 Sep 2006 12:07:40 +0200 "Martijn van Oosterhout" <[EMAIL PROTECTED]> wrote: > On 9/20/06, Michal Čihař <[EMAIL PROTECTED]> wrote: > > Nothing says long has to be bigger that int, only thing which is > > defined is: > > > > sizeof(short) <= sizeof(int) <= sizeof(long) > > > > so having short, int, long of same size is not a problem. > > I think you're missing the point. If you make an int 8 bytes, what are > you going to call 4 byte integers? If you call them short, what are > you going to call 2 byte integers? There is something what forces you to have 4 byte and 2 byte types defined? > Anyway, the link to the paper posted in this thread has many much > better arguments. I just wanted to point out that ISO C defines only relationship of sizes of those types and nothing else. The other assumptions come from things we got used to, because they were valid for ILP32 model which has been used most of time. PS: No need to CC me. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Moving /var/run to a tmpfs?
On Tue, Sep 19, 2006 at 10:49:14PM +0200, Hendrik Sattler wrote: > > with an ILP64 data model. > > However, the question should rather be: *why* compilers do not define > > int to be 64bit on a 64bit architecture? And the answer is simple: > > Yes int should be 64bit on a 64bit architecture, since int is defined > > as the architectures "natural size" data type. However, it is mostly > > not because of the elsewise massively increasing porting-expenses due > > to many programmers who never thought about it and simply assumed int > > to be 32bit. > > > > So, your metaphor implicitely leads to exactly the same answer ;) > > The answer is that the LP64 scheme is used and not ILP64. > There is a good and detailed explanation available: > http://www.unix.org/whitepapers/64bit.html This does not seem to be related to having /var/run on a tmpfs or even with Debian development in general. Please at least change the Subject, or, better yet, move it to another mailing list. thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphaning my packages
Hi Qingning, > Yes, mrxvt is quite nice with its tab support, and other features. And, > mrxvt is being actively developed by the upstream authors. > Unfortunately, I have not been able to spend much time on mrxvt > lately (being busy with the real life). Indeed, I would like to give > mrxvt away to whoever wants to adopt. I could take mrxvt, too. I'll make some sponsoring arrangements and adopt the package if you don't mind. Regards, Jan signature.asc Description: Digital signature
Re: Orphaning my packages
Hi, "Jan C. Nordholz" <[EMAIL PROTECTED]> writes: > Hi, > >> > * rxvt >> as a user of rxvt I like to see it remain in Debian. I'm not a Debian >> developer > > Same for me. I'd also take rxvt and am no DD either. Michael, maybe you'd > like to agree on some kind of team maintenance? My workload is quite low > at the moment, but will rapidly increase in about four weeks... I'll > mail you off-list. after exchanging some really pleasant emails with Jan I decided to leave the rxvt package for him and his sponsor. Nethertheless I will act as a backup ;). Michael -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking differences between Ubuntu and Debian for a set ofpackages
On Wed, 20 Sep 2006, Fabio Tranchitella wrote: > Il giorno mer, 20/09/2006 alle 10.31 +0200, Daniel Baumann ha scritto: > > I know I could get it from gluck, but I wanted to be kind and ask before > > I take it. > > > > Thanks a lot, very well done. I'll modify it so that I can track > > differences between backports and etch, to keep my backports easier > > uptodate. > > Fine, that's another good use case. Could you please put it somewhere > public? We could have a common area for these "track the differences > between distributions" tools? There's also "MultiDistroTools" that are similar to this use case: https://wiki.ubuntu.com/MultiDistroTools Examples of reports generated: http://tiber.tauware.de/~lucas/versions/ http://tiber.tauware.de/~lucas/versions/ruby.html Ccing lucas since he offered this service to other Debian teams like the ruby team and the debian-multimedia team. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: stale lock files
Roger Leigh <[EMAIL PROTECTED]> writes: > Goswin von Brederlow <[EMAIL PROTECTED]> writes: > >> Write the pid and host to the lock file. When you detect a lock and >> the lock is on the local host then check the pid is still valid. If >> not the lock is stale. If the lock is from a remote host there is >> little you can do but ask. > > Why not use fcntl/lockf byte region locking on the entire file? It > gets released as soon as the process terminates, so there are no > issues with stale locks, and it works over NFS. > > > Regards, > Roger NFS isn't everything. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Setting up pbuilder or sbuild like experimental buildds
Junichi Uekawa <[EMAIL PROTECTED]> writes: > Hi, > >> Then I thought I might have forgotten APT::Default-Release, and with >> APT::Default-Release set to "unstable", I could pin experimental higher >> than 500, 700 for example, and it wouldn't upgrade the packages >> automatically, however it still doesn't work. >> >> These are the scores of the package I'm interested in: >> >> bee# apt-cache policy libglib2.0-dev >> libglib2.0-dev: >> Installed: 2.10.3-3 >> Candidate: 2.10.3-3 >> Version table: >> 2.12.0-1 0 >> 600 http://ftp.de.debian.org experimental/main Packages >> *** 2.10.3-3 0 >> 990 http://ftp.de.debian.org sid/main Packages >> 100 /var/lib/dpkg/status >> >> I checked the code of pbuilder-satisfydepends, and I see it tries all >> versions of "apt-cache show" output to see whether one of them would be >> enough, but I see no place where it would request a particular version. > > Yup, that's not supported in current pbuilder-satisfydepends codebase. > You're welcome to submit a patch, however. > > > regards, > junichi You also need to downgrade packages back to unstable when the build needed some package from experimental. So you should pin to >1000 and run apt-get dist-upgrade between builds as a minimum. Or just throw away the chroot, unpack a new one, upgrade to sid, add experimental to sources.list, run sbuild for every build. Much safer and simpler. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388490: ITP: python-wareweb -- servlet-style web framework, similar to Webware
Package: wnpp Severity: wishlist Owner: Piotr Ozarowski <[EMAIL PROTECTED]> * Package name: python-wareweb Version : 0.2 Upstream Author : Ian Bicking <[EMAIL PROTECTED]> * URL : http://pythonpaste.org/wareweb/ * License : MIT Programming Lang: Python Description : servlet-style web framework, similar to Webware Wareweb is a rethinking of the ideas behind Webware. Webware is a fairly old framework, written back in the days of Python 1.5.2, and some of the API decisions behind it now show their age. Also, many of the abstractions in Webware didn't turn out to be useful, while some other abstractions are missing. . Wareweb tries to keep the basic model of Webware, while simplifying many portions and adding some new techniques. It's not backward compatible, but it doesn't require major revamping to apply to a Webware application. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-rc7 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphaning my packages
On Wed, Sep 20, 2006 at 04:12:12PM +0200, Jan C. Nordholz wrote: > > Yes, mrxvt is quite nice with its tab support, and other features. And, > > mrxvt is being actively developed by the upstream authors. > > Unfortunately, I have not been able to spend much time on mrxvt > > lately (being busy with the real life). Indeed, I would like to give > > mrxvt away to whoever wants to adopt. > > I could take mrxvt, too. I'll make some sponsoring arrangements and > adopt the package if you don't mind. > Jan, mrxvt is yours now. Qingning signature.asc Description: Digital signature
RFA libtorrent and rtorrent
Hi, Because of recent changes in my Real Life, I cannot spend enough time on libtorrent and rtorrent as I would like. Whoever want to adopt are welcome to take over their maintenance. I would recommend them be adopted together, because they are closely related (same author), and new upstream versions are always released at the same time. Regards, Qingning signature.asc Description: Digital signature
Re: RFA libtorrent and rtorrent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Qingning Huo escribió: > Hi, > > Because of recent changes in my Real Life, I cannot spend enough time on > libtorrent and rtorrent as I would like. Whoever want to adopt are > welcome to take over their maintenance. I would recommend them be > adopted together, because they are closely related (same author), and > new upstream versions are always released at the same time. > > Regards, > > Qingning > Hi Qingning, I want to take both packages. Please write me in private wherever I need to know exactly about something weird on this packages. Cheers, - -- ~ghostbar @ linux/debian 'unstable' on i686 - Linux Counter# 382503 http://ghostbar.ath.cx/ - irc.freenode.net #talug #velug #debian-es http://debianvenezuela.org.ve - irc.debian.org #debian-es #debian-ve San Cristobal - Venezuela. TALUG -- http://linuxtachira.org CHASLUG -- http://chaslug.org.ve - irc.unplug.org.ve #chaslug Fingerprint = 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFEbEfOKCtW8rKsRgRAg4JAJ9iwXVZRzsdR/qQDOQfqy84FnHy7gCgn6a5 ydNuJQbWI/UvLfPcHi2i/+I= =yvYH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFA libtorrent and rtorrent
On Wed, Sep 20, 2006 at 10:04:14PM +0100, Qingning Huo wrote: > Because of recent changes in my Real Life, I cannot spend enough time on > libtorrent and rtorrent as I would like. Whoever want to adopt are > welcome to take over their maintenance. I would recommend them be > adopted together, because they are closely related (same author), and > new upstream versions are always released at the same time. I use rtorrent quite a bit, so I'd be glad to take over maintence. -- gram -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFA libtorrent and rtorrent
On Wed, Sep 20, 2006 at 04:23:35PM -0500, Graham Wilson wrote: > On Wed, Sep 20, 2006 at 10:04:14PM +0100, Qingning Huo wrote: > > Because of recent changes in my Real Life, I cannot spend enough time on > > libtorrent and rtorrent as I would like. Whoever want to adopt are > > welcome to take over their maintenance. I would recommend them be > > adopted together, because they are closely related (same author), and > > new upstream versions are always released at the same time. > > I use rtorrent quite a bit, so I'd be glad to take over maintence. Looks like Jose sent his mail first, so he is welcome to take them, but I'd be glad to if things fall through. -- gram -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: stale lock files
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Roger Leigh <[EMAIL PROTECTED]> writes: > >> Goswin von Brederlow <[EMAIL PROTECTED]> writes: >> >>> Write the pid and host to the lock file. When you detect a lock and >>> the lock is on the local host then check the pid is still valid. If >>> not the lock is stale. If the lock is from a remote host there is >>> little you can do but ask. >> >> Why not use fcntl/lockf byte region locking on the entire file? It >> gets released as soon as the process terminates, so there are no >> issues with stale locks, and it works over NFS. > NFS isn't everything. Of course, but you get that extra feature "for free". Why would that be a be something to avoid? Proper advisory file locking, as opposed to opening and writing out pidfiles, is more reliable for both local and distributed locking, avoiding all the issues with stale lock release (there are none--it's entirely automatic on fd close or process exit) and PIDs being reused on the local system and/or duplicated on a distributed system (there's no PID to care about, since the fcntl lock F_WRLCK is simply associated with an open file descriptor, and the kernel handles everything, including deadlocks). -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpkqXZQI6Oie.pgp Description: PGP signature
Bug#388512: ITP: inotail -- inotify enhanced tail
Package: wnpp Severity: wishlist Owner: Tobias Klauser <[EMAIL PROTECTED]> * Package name: inotail Version : 0.1 Upstream Author : Tobias Klauser <[EMAIL PROTECTED]> * URL : http://distanz.ch/inotail * License : GPL Programming Lang: C Description : inotify enhanced tail inotail is a replacement for the 'tail' program found in the base installation of every Linux/UNIX system. It makes use of the inotify infrastructure in recent versions of the Linux kernel to speed up tailing files in the follow mode (the '-f' option). Standard tail polls the file every second by default while inotail listens to special events sent by the kernel through the inotify API to determine whether a file needs to be reread. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-xenon Locale: LANG=en_GB, LC_CTYPE=de_CH (charmap=ISO-8859-1) (ignored: LC_ALL set to en_GB) signature.asc Description: Digital signature
Re: Intend to intend to hijack SeaView.
Re: Andreas Tille 2006-09-19 <[EMAIL PROTECTED]> > The situation you described qualifies for a group maintained upload. > You might keep the original maintainer in the Uploaders field for the > sake of politeness because a complete hijack is regarded rude (even > if the facts you describe would justify it IMHO). If you hijack the package, please do it properly - do not let the old maintainer rot in the Uploaders: field. Inactive maintainers as co-maintainers are a pita for MIA tracking. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#388412: ITP: libonig -- Oniguruma regular expressions library
Package: wnpp Severity: wishlist Owner: Max Kellermann <[EMAIL PROTECTED]> * Package name: libonig Version : 4.4.4 Upstream Author : K.Kosako * URL : http://www.geocities.jp/kosako3/oniguruma/ * License : BSD Description : Oniguruma regular expressions library Oniguruma is a regular expressions library. The characteristics of this library is that different character encoding for every regular expression object can be specified. This library is being used by the Ruby interpreter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intend to intend to hijack SeaView.
On Thu, 21 Sep 2006, Christoph Berg wrote: If you hijack the package, please do it properly - do not let the old maintainer rot in the Uploaders: field. Inactive maintainers as co-maintainers are a pita for MIA tracking. Ahh well, never thought about this - thanks for the hint. So just keep the debian-med development team as maintainer and everybody including the old maintainer is invited to join this group. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
