Re: potential mass bug filing: sysvinit dependency
Lionel Elie Mamane a écrit : > On Tue, Sep 05, 2006 at 01:30:19PM +0200, Marco d'Itri wrote: > >> This may be a good time to remind maintainers that often a versioned >> conflict may be more appropriate than a versioned dependency. > > This seems natural to me, but the policy contains this discouraging > language: > > A Conflicts entry should almost never have an "earlier than" version > clause. This would prevent dpkg from upgrading or installing the > package which declared such a conflict until the upgrade or removal > of the conflicted-with package had been completed. > > I'm not exactly sure what is being said here. The second sentence > seems to be *exactly* the effect I would seek when doing a versioned > "earlier than" conflict. So I don't understand why the policy says one > should "almost never" have one. Perhaps the problem is with the word "completed" (ie not "initiated"). This means that the new package (with versioned conflict) cannot be unpacked until the old conflicting one has been removed (with execution of post-remove) or fully upgraded (ie unpacked AND configured). Note: All of this is speculation from me. I can be wrong. Best regards, Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new passwd
Hi, On Thu, 07 Sep 2006, Atsuhito Kohda wrote: > Hi all, > > yesterday, I failed to login svn.debian.org with ssh. > I was asked Passwd and input the correct passwd (as far > as I remembered) three times but failed. > > I was given my first passwd in 2001/01 and it was changed > in 2003/12/16 (perhaps because of compromise of Debian servers). svn.debian.org account database is separate from the usual Debian developers account. It is hooked into Alioth's account database. http://wiki.debian.org/Alioth http://wiki.debian.org/AliothFAQ Thus the password is different, if you never used svn.d.o before, you'll need to ask for a new password. The link is in one the above mentionned pages. 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: new passwd
On Thu, 7 Sep 2006 09:28:34 +0200, Raphael Hertzog wrote: > svn.debian.org account database is separate from the usual Debian > developers account. It is hooked into Alioth's account database. > > http://wiki.debian.org/Alioth > http://wiki.debian.org/AliothFAQ > > Thus the password is different, if you never used svn.d.o before, you'll > need to ask for a new password. The link is in one the above mentionned > pages. I see. I'll try it later. Thanks for your help. But then the problem is that > So I tried to get a new passwd > following the instruction of http://db.debian.org/password.html > at about 12am JST (3am UTC) but I've gotten nothing yet (after > one day already). Does the procedure echo "Please change my Debian password" | gpg --clearsign \ | mail [EMAIL PROTECTED] work yet? I get nothing even now. Regards, 2006-9-7(Thu) -- Debian Developer & Debian JP Developer - much more I18N of Debian Atsuhito Kohda Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new passwd
On Thu, 07 Sep 2006, Atsuhito Kohda wrote: > > So I tried to get a new passwd > > following the instruction of http://db.debian.org/password.html > > at about 12am JST (3am UTC) but I've gotten nothing yet (after > > one day already). > > Does the procedure > > echo "Please change my Debian password" | gpg --clearsign \ > | mail [EMAIL PROTECTED] > > work yet? I get nothing even now. Are you sure that the GPG key is still in the Debian keyring? And on the web page you mentionned, it's written that you should contact [EMAIL PROTECTED] in case of problem... 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: new passwd
On Thu, 7 Sep 2006 10:07:39 +0200, Raphael Hertzog wrote: > Are you sure that the GPG key is still in the Debian keyring? I believe so. > And on the web page you mentionned, it's written that you should contact > [EMAIL PROTECTED] in case of problem... Right. Thanks again. Regards,2006-9-7(Thu) -- Debian Developer & Debian JP Developer - much more I18N of Debian Atsuhito Kohda Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new passwd
Raphael Hertzog <[EMAIL PROTECTED]> wrote: > On Thu, 07 Sep 2006, Atsuhito Kohda wrote: >> > So I tried to get a new passwd >> > following the instruction of http://db.debian.org/password.html >> > at about 12am JST (3am UTC) but I've gotten nothing yet (after >> > one day already). >> >> Does the procedure >> >> echo "Please change my Debian password" | gpg --clearsign \ >> | mail [EMAIL PROTECTED] >> >> work yet? I get nothing even now. > > Are you sure that the GPG key is still in the Debian keyring? gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg --list-keys kohda pub 1024D/5BFA90EC 2000-04-28 uid Atsuhito KOHDA <[EMAIL PROTECTED]> uid Atsuhito Kohda <[EMAIL PROTECTED]> uid Atsuhito Kohda <[EMAIL PROTECTED]> sub 1024g/7E522785 2000-04-28 Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Brain dead package management?
Am 2006-09-01 13:53:06, schrieb Michael S. Peek: > system. In this command line, I specify that I want the lpr package > removed, and the cupsys-bsd package installed (the two are mutually > exclusive -- lpr conflicts w/ cupsys-bsd). Now, you would think that > >aptitude -y -o Aptitude::Log=/var/lib/tiem/log-20060901-120519.txt > >install kernel-image-2.6-686-smp+ apt-get --assume-yes install lrp- You NEED to put the package to be removed at first before all other packages then it works. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
coreutils/debianutils dependency cycle?
This is somewhat unexpected, given that both packages are already
installed and configured. Does anyone know what's up?
lapse:~# apt-get install --reinstall {core,debian}utils
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 27 not upgraded.
Need to get 0B/3178kB of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue [Y/n]?
E: Couldn't configure pre-depend coreutils for debianutils, probably a
dependency cycle.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' :proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
all of you that believe in telekinetics, raise my hand!
signature.asc
Description: Digital signature (GPG/PGP)
The debian boot dependency graph image
For some time now, the runtime dependencies of init.d scripts have been documented in the scripts, using the LSB convention. Now, enough scripts have this information present to make a useful graph of the dependencies in the debian boot. The current state of affairs in my sid chroot look like this: http://user.skolelinux.no/~pere/debian/lsb-info-20060907.png > The scripts listed in the upper right corner are all those scripts without dependency information available. This is the complete list for my installation: hwclockfirst.sh ifupdown-clean modutils hwclock.sh libdevmapper1.01 libdevmapper1.02 lvm hibernate ifupdown nviboot xserver-xorg vbesave sysklogd klogd acct acpid apmd apt-index-watcher atftpd cupsys dbus-1 nullmailer openbsd-inetd rsync snmpd ssh uml-utilities snmptrapfmt anacron binfmt-support acpi-support libnss-ldap A status summary for the packages used in a desktop installation is available from http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/lsblist.html>. The dotty file used to generate this graph is available from http://user.skolelinux.no/~pere/debian/lsb-info-20060907.dot > To generate your own graph, install the 'insserv' package, and run these commands to get your own /usr/share/insserv/check-initd-order -g -o > lsb-graph.dot dot -Tpng -o lsb-graph.png lsb-graph.dot If you want to make a graph using the dependency information provided in the insserv package for the scripts without such info, remove the -o flag. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The debian boot dependency graph image
On Sep 07, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > For some time now, the runtime dependencies of init.d scripts have > been documented in the scripts, using the LSB convention. Now, enough > scripts have this information present to make a useful graph of the > dependencies in the debian boot. The current state of affairs in my > sid chroot look like this: > > http://user.skolelinux.no/~pere/debian/lsb-info-20060907.png > Now, try thinking about how many of the blocks which are not listed as depending on udev actually do. -- ciao, Marco signature.asc Description: Digital signature
Re: The debian boot dependency graph image
Le jeu 7 septembre 2006 15:11, Marco d'Itri a écrit : > On Sep 07, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > For some time now, the runtime dependencies of init.d scripts have > > been documented in the scripts, using the LSB convention. Now, > > enough scripts have this information present to make a useful graph > > of the dependencies in the debian boot. The current state of > > affairs in my sid chroot look like this: > > > >> http://user.skolelinux.no/~pere/debian/lsb-info-20060907.png > > > Now, try thinking about how many of the blocks which are not listed > as depending on udev actually do. your point beeing ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpI8Xm2X0357.pgp Description: PGP signature
Re: The debian boot dependency graph image
On Thu, Sep 07, 2006 at 03:11:02PM +0200, Marco d'Itri wrote: > Now, try thinking about how many of the blocks which are not listed > as depending on udev actually do. None, because udev isn't actually a hard dependency for any of those scripts, so listing it as such is wrong. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Extended partition creation policy ?
Hi! (please CC me on replies, as I am not subscribed to the list; but will check its archives every now and then) I noticed, that when the debian installer is instructed to create two partitions, whose joint size is less than the size of the disk, then it creates one primary partition and one logical partition inside an extended partition. The issue is, that this extended partition has the size of the logical partition and not the maximum possible size (the entire empty disk space plus the logical parition). This layout seems to be special to debian, since all other distros (except debian based ones) and operating systems create extended partitions that cover the entire free disk space. This becomes a problem, when the user want to create a new partition. He has two options : - create a primary partition up side : easy to do, no problems down side : as two slots are used for the original primary partition and the extended partition, only two remain. Also more than than one primary partition is unrecomended and can be problemtatic in certain environments. - change the size of the extended partition and create logical partition(s) upside : no limits on number of partitions, no other problems downside : very few partitioning tools support this in asimple and obvious way. The most common ones (fdisk, Windows Disk Management) for example do not. My question is : What benefit does the debian way give ? Is there a possibility to change for the other "common" way ? For reference I also include the results of a small research about this on various op-systems : I started their CD based installer and in their partitioner, I created two partitions (a single partition setup usually creates a primary partition, so that would not cover our topic). I always used the default settings and values, except the following : - I asked creation of exactly two partitions - I specified their size (the sum of their sizes is less than the disk size) - for linux, I specified the partition type for the second partition as "swap" (the first partition was formatted by the default FS and used for / - root fs) That's it. The results : win XP : extended partition covers entire disk win 98 : extended partition covers entire disk debian 2.0 hamm: extended partition covers only used part of disk redhat 5.2 : extended partition covers entire disk debian 3.1 sarge : extended partition covers only used part of disk fedora 4 : extended partition covers entire disk (FC4 : I created 4 partitions, otherwise no extended partition would be created, but 3 primary partitions) As we see, the "small extended partition" is a debianism. Notes : "entire disk" means "entire disk minus the part used by the primary partition" "only used part of disk" means "the space used by the logical partition" Regards, David - http://noepatents.eu.org/ Innovation, not litigation ! --- David Balazic mailto:[EMAIL PROTECTED] HERMES Softlab http://www.hermes-softlab.com Zagrebska cesta 104Phone: +386 2 450 8846 SI-2000 Maribor Slovenija - "Be excellent to each other." - Bill S. Preston, Esq. & "Ted" Theodore Logan -
Re: Extended partition creation policy ?
Hello David, On Thursday 07 September 2006 14:14, David Balazic wrote: > I noticed, that when the debian installer is instructed to create > two partitions, whose joint size is less than the size of the disk, > then it creates one primary partition and one logical partition inside > an extended partition. > > The issue is, that this extended partition has the size of the logical > partition and not the maximum possible size (the entire empty disk > space plus the logical parition). The correct way to report this would be to file a bug report [1] against the package "partman-base". That will make sure it is brought to the attention of the debian-installer team and that its resolution will be tracked in the Debian Bug Tracking System (BTS). Could you please do that? Thanks, FJP [1] http://www.debian.org/Bugs/Reporting pgpSzVmmudrW9.pgp Description: PGP signature
Re: coreutils/debianutils dependency cycle?
martin f krafft <[EMAIL PROTECTED]> writes:
> This is somewhat unexpected, given that both packages are already
> installed and configured. Does anyone know what's up?
>
> lapse:~# apt-get install --reinstall {core,debian}utils
> Reading package lists... Done
> Building dependency tree... Done
> 0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 27 not upgraded.
> Need to get 0B/3178kB of archives.
> After unpacking 0B of additional disk space will be used.
> Do you want to continue [Y/n]?
> E: Couldn't configure pre-depend coreutils for debianutils, probably a
> dependency cycle.
Somehow on --reinstall apt does not break cycles. If you install them
individualy it works. Annoyed the hell out of me too.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The debian boot dependency graph image
On Sep 07, Pierre Habouzit <[EMAIL PROTECTED]> wrote: > > > http://user.skolelinux.no/~pere/debian/lsb-info-20060907.png > > > Now, try thinking about how many of the blocks which are not listed > > as depending on udev actually do. > your point beeing ? That if you want a really dependency-based boot process more work will be needed. -- ciao, Marco signature.asc Description: Digital signature
Re: The debian boot dependency graph image
On Sep 07, Wouter Verhelst <[EMAIL PROTECTED]> wrote: > On Thu, Sep 07, 2006 at 03:11:02PM +0200, Marco d'Itri wrote: > > Now, try thinking about how many of the blocks which are not listed > > as depending on udev actually do. > None, because udev isn't actually a hard dependency for any of those > scripts, so listing it as such is wrong. If it's in the picture then it's relevante. -- ciao, Marco signature.asc Description: Digital signature
Re: coreutils/debianutils dependency cycle?
also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2006.09.07.1659 +0200]: > Somehow on --reinstall apt does not break cycles. Where is there a cycle? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems NP: Psychomuzak / The Exstasie signature.asc Description: Digital signature (GPG/PGP)
Re: The debian boot dependency graph image
* Marco d'Itri <[EMAIL PROTECTED]> [2006-09-07 15:11]: > On Sep 07, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > > For some time now, the runtime dependencies of init.d scripts have > > been documented in the scripts, using the LSB convention. Now, enough > > scripts have this information present to make a useful graph of the > > dependencies in the debian boot. The current state of affairs in my > > sid chroot look like this: > > > > http://user.skolelinux.no/~pere/debian/lsb-info-20060907.png > > Now, try thinking about how many of the blocks which are not listed > as depending on udev actually do. I can't think of a single one that would not work with good old static dev tough udev might be the recommended way. yours Martin -- <[EMAIL PROTECTED]> Debian GNU/Linux - The Universal Operating System I AM ON TV! CIAO MAMMA! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: coreutils/debianutils dependency cycle?
martin f krafft <[EMAIL PROTECTED]> writes: > also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2006.09.07.1659 +0200]: >> Somehow on --reinstall apt does not break cycles. > > Where is there a cycle? You are right. There isn't even a cycle. Just a simple depends. That makes it even worse. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The debian boot dependency graph image
Le jeudi 07 septembre 2006 à 15:18 +0200, Martin Wuertele a écrit : > > > http://user.skolelinux.no/~pere/debian/lsb-info-20060907.png > > > Now, try thinking about how many of the blocks which are not listed > > as depending on udev actually do. > > I can't think of a single one that would not work with good old static > dev tough udev might be the recommended way. But nevertheless, they won't work if udev is installed, until the device appears. The current boot scheme is unsuitable for such cases. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: The debian boot dependency graph image
This one time, at band camp, Josselin Mouette said: > Le jeudi 07 septembre 2006 à 15:18 +0200, Martin Wuertele a écrit : > > > > I can't think of a single one that would not work with good old static > > dev tough udev might be the recommended way. > > But nevertheless, they won't work if udev is installed, until the device > appears. The current boot scheme is unsuitable for such cases. This is what the Should-Start filed is for, AIUI. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
kernel panic: pivot_root help me
Hello, We buy a IBM Blade Server. I choose 2.6 kernel and Grub on Debian 3.1 Sarge Setup. But Debian says me Kernel Panic pivot_root: No such file or directory /sbin/init : 432: cannot open dev/console: No such file Kernel panic : Attempted to kill init How to pass it? -- ,''`. 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: Extended partition creation policy ?
Am Donnerstag 07 September 2006 14:14 schrieb David Balazic: > The issue is, that this extended partition has the size of the logical > partition and not the maximum possible size (the entire empty disk space > plus the logical parition). > > This layout seems to be special to debian, since all other distros > (except debian based ones) and operating systems create extended > partitions that cover the entire free disk space. Evaluate the following case: * you install linux with the mentioned 2-partition layout * you install another OS that needs a primary partition - Installer makes extended partition full size: you have to reduce the size to install the other OS. - Installer makes two primary partitions: no problems at all - Installer makes extended partition _not_ full size: mentioned problem. As you already mentioned, the way in FC4 looks like the best approach... HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386358: O: elserv -- HTTP server that runs on Emacsen
retitle 386358 ITA: elserv -- HTTP server that runs on Emacsen Hi, > I request an adopter for this package. I've lost interest in this > package and nothing in Debian uses it apparently. If you'd like to > see it survive, please take it. You're joking, right? Reverse Depends: wysihtml-el,elserv 0.4.0+0.20011203cvs-3.2 devscripts-el,elserv I'll take the package, thanks for giving up. 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: The debian boot dependency graph image
* Marco d'Itri <[EMAIL PROTECTED]> [2006-09-07 17:11]: > On Sep 07, Wouter Verhelst <[EMAIL PROTECTED]> wrote: > > > On Thu, Sep 07, 2006 at 03:11:02PM +0200, Marco d'Itri wrote: > > > Now, try thinking about how many of the blocks which are not listed > > > as depending on udev actually do. > > None, because udev isn't actually a hard dependency for any of those > > scripts, so listing it as such is wrong. > If it's in the picture then it's relevante. Then the picture/scripts should be fixed. yours Martin -- <[EMAIL PROTECTED]> Debian GNU/Linux - The Universal Operating System NP: Imperanon - Shadowsouls NE: Schokomüsli! :)
RE: Extended partition creation policy ?
(off list) I thought to discuss it first (maybe the key people would claim it is not a bug, so a bug report would be a waste of time, more or less). I will file a bug in a day or two, depending on other mail replies. If you think that is unneccessary and I should file a bug immediately, plese say so. Regards, David > -Original Message- > From: Frans Pop [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 07, 2006 4:53 PM > To: debian-devel@lists.debian.org > Cc: David Balazic > Subject: Re: Extended partition creation policy ? > > > Hello David, > > On Thursday 07 September 2006 14:14, David Balazic wrote: > > I noticed, that when the debian installer is instructed to create > > two partitions, whose joint size is less than the size of the disk, > > then it creates one primary partition and one logical > partition inside > > an extended partition. > > > > The issue is, that this extended partition has the size of > the logical > > partition and not the maximum possible size (the entire empty disk > > space plus the logical parition). > > The correct way to report this would be to file a bug report > [1] against > the package "partman-base". That will make sure it is brought to the > attention of the debian-installer team and that its > resolution will be > tracked in the Debian Bug Tracking System (BTS). > > Could you please do that? > > Thanks, > FJP > > [1] http://www.debian.org/Bugs/Reporting >
Is lack of UTF support an RC bug? [was: Bug#386299: ekg2: Plugin/program compilation option mismatch]
On Thu, Sep 07, 2006 at 02:46:16AM -0700, Steve Langasek wrote: > severity 386299 serious > thanks > > On Wed, Sep 06, 2006 at 06:14:55PM +0100, Marcin Owsiany wrote: > > > Unicode support in ekg2 is highly experimental and not yet supported > > upstream, therefore the debian package is built without UTF-8 support. > > > On Wed, Sep 06, 2006 at 05:56:17PM +0200, Tristan Seligmann wrote: > > > Attempting to run ekg2 yields the following: > > > Try running it in some iso-8859 locale. > > That's not an acceptable answer, given that almost all locales for etch will > be Unicode by default. This makes the package unreleasable. Of course, the > package seems to only be in experimental at all, so I don't see why you > would bother to downgrade the bug... It doesn't matter for ekg2, which will stay in experimental for quite a while I'm afraid, but it is important for at least two other of my packages (which are in etch) which don't support UTF-8 at all. And I'm reasonably sure they are not the only packages in etch which don't support UTF. Who decided that we should just drop them all? After all generating a non-UTF locale and setting an environment variable isn't a very difficult workaround? I mean, when has lack of UTF support become an RC-bug? Charset support is not even mentioned in the policy, other than for debian/changelog. Don't get me wrong, I'm not against UTF-8, but just dropping everything that doesn't support it, without a former warning, sounds ridiculous. regards, Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 signature.asc Description: Digital signature
Re: The debian boot dependency graph image
On Thursday 07 September 2006 12:03, Petter Reinholdtsen wrote: > For some time now, the runtime dependencies of init.d scripts have > been documented in the scripts, using the LSB convention. Now, > enough scripts have this information present to make a useful graph > of the dependencies in the debian boot. The current state of affairs > in my sid chroot look like this: > > http://user.skolelinux.no/~pere/debian/lsb-info-20060907.png [SNIP] > > If you want to make a graph using the dependency information provided > in the insserv package for the scripts without such info, remove the > -o flag. I've tried, but it doesn't work: [EMAIL PROTECTED]:~$ sudo /usr/share/insserv/check-initd-order -g -o >lsb-graph.dot Unknown option: o Unable to properly handle multiple provides: mountdevsubfs mountvirtfs LSB header missing in /etc/rcS.d/S25libdevmapper1.02 Use of uninitialized value in split at /usr/share/insserv/check-initd-order line 69. Use of uninitialized value in concatenation (.) or string at /usr/share/insserv/check-initd-order line 84. Use of uninitialized value in concatenation (.) or string at /usr/share/insserv/check-initd-order line 93. LSB header missing in /etc/rcS.d/S70screen-cleanup LSB header missing in /etc/rcS.d/S75schroot LSB header missing in /etc/rcS.d/S80installation-report LSB header missing in /etc/rc2.d/S19spamassassin LSB header missing in /etc/rc2.d/S20apt-index-watcher Use of uninitialized value in split at /usr/share/insserv/check-initd-order line 69. Use of uninitialized value in concatenation (.) or string at /usr/share/insserv/check-initd-order line 84. Use of uninitialized value in concatenation (.) or string at /usr/share/insserv/check-initd-order line 84. Use of uninitialized value in concatenation (.) or string at /usr/share/insserv/check-initd-order line 93. Use of uninitialized value in split at /usr/share/insserv/check-initd-order line 69. Use of uninitialized value in concatenation (.) or string at /usr/share/insserv/check-initd-order line 84. Use of uninitialized value in concatenation (.) or string at /usr/share/insserv/check-initd-order line 93. LSB header missing in /etc/rc2.d/S20ddclient Unable to read /etc/rc2.d/S20inetd at /usr/share/insserv/check-initd-order line 180. i get the same error even without -o option... i've tested it on PPC, the insserv version is 1.08.0-1 HTH Francesco -- :wq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Volunteers needed to experiment with tags in debian/control
Hello, I would like to experiment with a little new plan for having tags flow again from the web submissions[1] to the Packages file. Currently the flow happens by hand, with yours truly checking every single submissions and approving it or rejecting it. This doesn't work, it's long, boring, error prone, and I haven't been doing it for a long while now. I came out with a plan to allow developers to voluntarily take care of reviewing the tags for some or all of their packages. The plan goes as this: 0) Download http://people.debian.org/~enrico/2006-09/debtags-updatecontrol 1) Edit debian/control adding an empty "Tag:" field for every *binary* package 2) In your package root directory, run debtags-updatecontrol. The script will check debtags.alioth.debian.org for new tags, and it will guide you through reviewing all the differences. 3) Have a look at debian/control: you will find that the Tag: field has been updated with the new tags 4) Upload the package: I will notice that it has the Tag: field and I'll know that I don't have to do manual review of tags for it. The script is smart enough to ask you to review only the differences between the data on Alioth and the data in your package. If you reject changes from Alioth, it will also offer you to mail the patch back to it. Now, the part about the volunteers: this has not been tested yet. Also, there is currently a big Tag override file that will override your changes. What I need is to have some packages with a Tag: field in the control file, so that I can implement and test the final part of the plan, which consists in updating the override file to let your tags through. What I am doing is trying to setup a system in which the override file isn't used to override, but just to fill in the Tag field for those maintainers who are not comfortable filling it in themselves. Finally, the tricky bit. I'm leaving tomorrow for an extended, networkless week-end in the mountains. I'm sending this mail out now hoping that when I come back there'll be some package in the archive with the Tag: field, enabling me to go on developing the missing bit. If you don't feel comfortable doing it, or debtags-updatecontrol doesn't work for you, just send me an e-mail and leave it there: I'll see to it when I come back. If you manage to upload a package with a Tag: field, please also drop me an e-mail so I'll know that it's there. Sorry for asking things and then running away. But then, I couldn't bear waiting for Tag: fields to flow in while biting my nails in front of the computer, and it's good that I cope with the stress by instead enduring the wait high up in the Alps :) Ciao, Enrico [1] http://debtags.alioth.debian.org/cgi-bin/edit.cgi?pkg=PKGNAME -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#386447: ITP: Gnome Subtitles -- Gnome Subtitles is a subtitle editor for the GNOME desktop.
Package: wnpp Severity: wishlist Owner: Tiago Bortoletto Vaz <[EMAIL PROTECTED]> * Package name: Gnome Subtitles Version : 0.0.1 Upstream Author : Pedro Castro <<[EMAIL PROTECTED]> * URL : http://gsubtitles.sourceforge.net/ * License : (GPL) Programming Lang: (C#) Description : Gnome Subtitles is a subtitle editor for the GNOME desktop. Gnome Subtitles is a subtitle editor for the GNOME desktop. Its features include: * Subtitle format auto-detection * Character encoding auto-detection * Support for time and frame-based subtitles * Support for bold, italic and underline style tags * Synchronization, including frame-rate conversion and timing * shifting * Multi-level undo * Error correction and toleration when opening subtitles * Support for the following subtitle formats (as supported at the moment by SubLib[1]): - MicroDVD - SubRip -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is lack of UTF support an RC bug?
Marcin Owsiany <[EMAIL PROTECTED]> writes: > It doesn't matter for ekg2, which will stay in experimental for quite a > while I'm afraid, but it is important for at least two other of my > packages (which are in etch) which don't support UTF-8 at all. And I'm > reasonably sure they are not the only packages in etch which don't > support UTF. Right; for instance, as noted in #229702/#236214, libfltk1.1 and its ~30 reverse-dependencies have the same limitation, which upstream won't address because doing so would break the ABI. > Don't get me wrong, I'm not against UTF-8, but just dropping everything > that doesn't support it, without a former warning, sounds ridiculous. Agreed. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is lack of UTF support an RC bug? [was: Bug#386299: ekg2: Plugin/program compilation option mismatch]
Marcin Owsiany wrote: > Who decided that we should just drop them all? After all generating a > non-UTF locale and setting an environment variable isn't a very > difficult workaround? I mean, when has lack of UTF support become an > RC-bug? Charset support is not even mentioned in the policy, other than > for debian/changelog. There's quite a way from "not properly supporting UTF, possibly mangling characters" to "needs workaround for most installs otherwise being completely unusable with opaque error message". The latter doesn't really sound like a releasable state to me. I think looking at the issue with the criterium "the distribution better not have a lot of packages with this type of fault or it's a completly useless junk collection of packages" one can see a big red blinking RC bug sign for this specific bug (as opposed to all UTF problems being RC). Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf: DbDriver "templatedb": could not sync
Hallo Wouter, if you replay plz CC me. * Wouter Verhelst schrieb [06-09-06 20:26]: > On Wed, Sep 06, 2006 at 07:29:13PM +0200, Udo Mueller wrote: > > fsck.ext3 runs without any error message. > > Did you do "fsck -f", or just "fsck"? In case you did the latter, please > run it with -f again. I ran it without -f. Today i had physical access and ran fsck -f. It showed no errors. But: The disc space is provided by a DAS Raid system. The DAS is directly attached to the box and a backup tape is attached to the DAS. While rebooting Debian i noticed some errors which are backup-tape related scsi errors. After these errors were removed dpkg work fine again. Dont know the exact reasons but it works now. Mit freundlichen Grüßen Udo Müller -- ComputerService Udo Müller Tel.: 0441-36167578 Schöllkrautweg 16 Fax.: 0441-36167579 26135 Oldenburg [EMAIL PROTECTED] Mobil: 0162-4365411 signature.asc Description: Digital signature
Re: kernel panic: pivot_root help me
Maybe if you boot using live cd and after that mount your partition and edit /sbin/init and change dev/console for /dev/console. Ozgur Karatas escreveu: Hello, We buy a IBM Blade Server. I choose 2.6 kernel and Grub on Debian 3.1 Sarge Setup. But Debian says me Kernel Panic pivot_root: No such file or directory /sbin/init : 432: cannot open dev/console: No such file Kernel panic : Attempted to kill init How to pass it? -- ,''`. 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: Linking a static library with -fPIC for flex
On Tue, Sep 05, 2006 at 04:50:24PM -0500, Manoj Srivastava wrote:
> Hi,
>
> Starting with version 2.5.31-18 of flex we have started
> providing a static library compiled with position independent code,
> namely, libfl_pic.a, in addition to the normal libfl.a library. This
> is my mail, in accordance to ?10.2 of the Debian policy.
In my opinion, libfl_pic.a is totally useless, see below.
> The problem is with packages that contain shared libraries
> with a flex scanner compiled in. Since flex generates code
> that is not self contained, and the missing symbols live in
> libfl.a.
Not self contained is quite overstated. Actually libfl.a provide
exactly 2 symbols that are defined if the program lacks them. They are:
main(): I doubt you would want a shared library to provide a
simple-minded main() function ?
yywrap(): whose code is
int yywrap (void) { return 1; }
So if you are to write a library that include a flex scanner, all you
have to do is to prvide your own yywrap() function, even if it is
just return 1; and you won't need to link with libfl.a.
Actually I always advise to provide main() and yywrap(), this way
the C file generated by flex can be compiled on a host where libfl.a is
not available.
libfl.a is only useful if you want quickly write and run a flex script
without writing the main loop. But people tend to use perl for that
nowadays.
Cheers,
--
Bill. <[EMAIL PROTECTED]>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386482: ITP: libwww-opensearch-perl -- search OpenSearch compatible web sites
Package: wnpp Severity: wishlist Owner: Ian Beckwith <[EMAIL PROTECTED]> * Package name: libwww-opensearch-perl Version : 0.06_02 (changed to 0.06.02 for Debian) Upstream Author : Brian Cassidy <[EMAIL PROTECTED]> and Tatsuhiko Miyagawa <[EMAIL PROTECTED]> * URL : http://www.perl.com/CPAN/authors/id/B/BR/BRICAS/WWW-OpenSearch-0.06_02.tar.gz * License : Dual GPL/Artistic Programming Lang: Perl Description : search OpenSearch compatible web sites WWW::OpenSearch is a perl module to search web sites that provide an OpenSearch description and handle responses in Atom or RSS. . See http://opensearch.a9.com/ for more information on OpenSearch. -- 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.16 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linking a static library with -fPIC for flex
On Tue, Sep 05, 2006 at 04:50:24PM -0500, Manoj Srivastava wrote: > > Starting with version 2.5.31-18 of flex we have started > providing a static library compiled with position independent code, > namely, libfl_pic.a, in addition to the normal libfl.a library. This > is my mail, in accordance to §10.2 of the Debian policy. > The problem is with packages that contain shared libraries > with a flex scanner compiled in. Since flex generates code > that is not self contained, and the missing symbols live in > libfl.a. However, since linking a shared library with a object > containing non position independent code stopped working with gcc 4.1 > (apparently, it was sheer luck that it worked at all). So now we also > provide libfla_pic.a for shared library packages to link with. > I was initially going to just provide libfl.a with position > independent code, which would have prevented the FTBS breakage for > scanner containing shared libraries, at the expense of a register > lost for binaries that were otherwise statically linked, and perhaps > slower execution speeds. When I broached this on IRC, people > commented that I could provide libfl_pic.a in addition to libfl.a , > but compile them both with -fPIC, and transition back at some later > point to having a non position independent static libfl.a > Then I realized I was falling into the trap of preferring > convenience to correctness; the right thing to identify and fix > packages building shared objects linked to non relocatable code. So, > now these packages can link to libfl_pic.a, and binaries can > continue to link with libfl.a. > An alternative would have been to provide a full fledged > shared library, The other alternative discussed on IRC was to make /usr/lib/libfl.so a linker script, à la libc.so. I think the below should be sufficient, giving you PIC code when shared linking is requested by the linker and non-PIC code when static linking is requested: /* GNU ld script When shared linking is requested, map the request to the PIC static library, which is the closest we come to a shared library here. */ INPUT( /usr/lib/libfl_pic.a ) Untested, though; it may actually be better to use GROUP() instead of INPUT(), I'm not sure if ld will treat the two commands the same for reduction of unused symbols. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is lack of UTF support an RC bug? [was: Bug#386299: ekg2: Plugin/program compilation option mismatch]
On Thu, Sep 07, 2006 at 06:25:26PM +0100, Marcin Owsiany wrote: > > > Try running it in some iso-8859 locale. > > That's not an acceptable answer, given that almost all locales for etch will > > be Unicode by default. This makes the package unreleasable. Of course, the > > package seems to only be in experimental at all, so I don't see why you > > would bother to downgrade the bug... > It doesn't matter for ekg2, which will stay in experimental for quite a > while I'm afraid, but it is important for at least two other of my > packages (which are in etch) which don't support UTF-8 at all. And I'm > reasonably sure they are not the only packages in etch which don't > support UTF. > Who decided that we should just drop them all? After all generating a > non-UTF locale and setting an environment variable isn't a very > difficult workaround? I mean, when has lack of UTF support become an > RC-bug? Charset support is not even mentioned in the policy, other than > for debian/changelog. > Don't get me wrong, I'm not against UTF-8, but just dropping everything > that doesn't support it, without a former warning, sounds ridiculous. It's already been pointed out that there's a big difference between "won't display non-ASCII characters correctly in a UTF-8 locale" and "won't work at all in a UTF-8 locale". There's no excuse for the latter; and as Unicode locales *are* the default for almost all new installs of etch, this does make such a package mostly unusable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
