Authentication problem with pbuilder
Hi, I installed the latest pbuilder (on i386) and basically did ~$ sudo pbuilder update --distribution sid ~$ pdebuild ... -> new cache content kaffe-pthreads_2%3a1.1.6-2_i386.deb added -> new cache content libbz2-1.0_1.0.2-9_i386.deb added -> new cache content libpng12-dev_1.2.8rel-4_i386.deb added -> new cache content libsablot0_1.0.2-4_i386.deb added -> new cache content sablotron_1.0.2-4_i386.deb added /var/cache/pbuilder/build/18730/etc/passwd /var/cache/pbuilder/build/18730/etc/group /var/cache/pbuilder/build/18730/etc/shadow Copying source file -> copying [../arb_0.0.20050526-3.dsc] -> copying [../arb_0.0.20050526.orig.tar.gz] -> copying [../arb_0.0.20050526-3.diff.gz] Extracting source Password: su: Authentication failure Sorry. pbuilder: Failed extracting the source -> Aborting with an error -> unmounting dev/pts filesystem ... I guess I have to set a further sudo permission here but for what program? It is 'sudo su' ? I would not really like this even if it is convinient. Did I missed something? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: planet.debian.org vs. blog illiteracy
On Tue, Sep 27, 2005 at 09:08:42AM +1000, Andrew Pollock wrote: > On Mon, Sep 26, 2005 at 03:25:05PM -0400, Decklin Foster wrote: > > I think a simple solution for this would be for the DWN people to read > > planet.debian.org and report on anything "important" that is seen there. > > Then you can just (remain) subscribe(d to) debian-news. > > > > (Unfortunately, this is more work for them, and I'm not volunteering...) > > > > That already happens. I've had a blog post of mine make it into DWN in the > past. AOL (and more than once, as a matter of fact) -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Authentication problem with pbuilder
On Wed, 28 Sep 2005 09:09:32 +0200 (CEST) Andreas Tille <[EMAIL PROTECTED]> wrote: > ~$ sudo pbuilder update --distribution sid > ~$ pdebuild [...] > I guess I have to set a further sudo permission here but for what program? > It is 'sudo su' ? I would not really like this even if it is convinient. For /usr/bin/pdebuild, and invoke "sudo pdebuild". BTW, this question is more for d-mentors than for d-devel ;-) regards, -- Ricardo Mones ~ The three principal virtues of a programmer are Laziness, Impatience, and Hubris.man perl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Authentication problem with pbuilder
On Wed, 28 Sep 2005, Ricardo Mones wrote: I guess I have to set a further sudo permission here but for what program? It is 'sudo su' ? I would not really like this even if it is convinient. For /usr/bin/pdebuild, and invoke "sudo pdebuild". Uhmm, why that? I do not want to run the whole process as root. This would immediately trigger the feeling I have to write a bug report. BTW, this question is more for d-mentors than for d-devel ;-) If your answer is really correct I'm happy that I posted it here for the sake of lazyness, because I'm not subscribed to d-mentors. IMHO package building should work with fakeroot and should not require root permissions. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Authentication problem with pbuilder
On Wed, Sep 28, 2005 at 10:06:01AM +0200, Andreas Tille wrote: > On Wed, 28 Sep 2005, Ricardo Mones wrote: > > >>I guess I have to set a further sudo permission here but for what program? > >>It is 'sudo su' ? I would not really like this even if it is convinient. > > > > For /usr/bin/pdebuild, and invoke "sudo pdebuild". > > Uhmm, why that? I do not want to run the whole process as root. This > would immediately trigger the feeling I have to write a bug report. > > > BTW, this question is more for d-mentors than for d-devel ;-) > > If your answer is really correct I'm happy that I posted it here for > the sake of lazyness, because I'm not subscribed to d-mentors. IMHO > package building should work with fakeroot and should not require root > permissions. It works with fakeroot, the user the build runs at is configureable in /etc/pbuilderrc. The reason you require root for the whole thing is because of unpacking the chroot, chrooting itself, installing build dependencies, and purging the chroot again. Only the part between build dependencies and purging the chroot (the actual package building) can do without root privileges, and pbuilder will drop root appropriately in that stage, and use (by default) fakeroot where needed. See the BUILDSOURCEROOTCMD="fakeroot" configuration entry in /etc/pbuilderrc. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Authentication problem with pbuilder
On Wed, Sep 28, 2005 at 09:49:02AM +0200, Ricardo Mones wrote: >On Wed, 28 Sep 2005 09:09:32 +0200 (CEST) >Andreas Tille <[EMAIL PROTECTED]> wrote: > >>~$ sudo pbuilder update --distribution sid >>~$ pdebuild >[...] >>I guess I have to set a further sudo permission here but for what program? >>It is 'sudo su' ? I would not really like this even if it is convinient. > > For /usr/bin/pdebuild, and invoke "sudo pdebuild". > BTW, this question is more for d-mentors than for d-devel ;-) BTW, Andreas Tille is a very experinced DD ;-) > regards, >-- > Ricardo Mones > ~ > The three principal virtues of a programmer are Laziness, > Impatience, and Hubris.man perl Oh, maybe Andreas is both too lazy and impatient. Probably he's too low on hubrisness, I'm not sure :) I'm just remembering the t-shirt he worn during debconf5, "..., I'm sorrounded by ...". Mit freundlichen Grüßen, Aníbal Monsalve Salazar -- .''`. Debian GNU/Linux : :' : Free Operating System `. `' http://debian.org/ `- http://v7w.com/anibal signature.asc Description: Digital signature
Re: Authentication problem with pbuilder
On Wed, 28 Sep 2005, Jeroen van Wolffelaar wrote:
It works with fakeroot, the user the build runs at is configureable in
/etc/pbuilderrc. The reason you require root for the whole thing is because of
unpacking the chroot, chrooting itself, installing build dependencies, and
purging the chroot again.
But this can be done via
sudo /usr/sbin/pbuilder
inside pdebuild. If pdebuild is a convenience - script it would be *really*
conveniet only if I can call it as normal user. If not it makes no real sense
to put it in /usr/bin and should go to /usr/sbin.
There is also the
PBUILDERROOTCMD="sudo"
line and if you look into the code of pdebuild you find
${PBUILDERROOTCMD} pbuilder execute ...
...
${PBUILDERROOTCMD} pbuilder build
I see no other code inside pdebuild which would really need root permissions.
Coming back to my original question: It seemed to me that a
sudo su
would be required and I wonder why.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Authentication problem with pbuilder
On Wed, Sep 28, 2005 at 10:14:49AM +0200, Jeroen van Wolffelaar wrote: > On Wed, Sep 28, 2005 at 10:06:01AM +0200, Andreas Tille wrote: > > On Wed, 28 Sep 2005, Ricardo Mones wrote: > > > > >>I guess I have to set a further sudo permission here but for what program? > > >>It is 'sudo su' ? I would not really like this even if it is convinient. > > > > > > For /usr/bin/pdebuild, and invoke "sudo pdebuild". > > > > Uhmm, why that? I do not want to run the whole process as root. This > > would immediately trigger the feeling I have to write a bug report. > > > > > BTW, this question is more for d-mentors than for d-devel ;-) > > > > If your answer is really correct I'm happy that I posted it here for > > the sake of lazyness, because I'm not subscribed to d-mentors. IMHO > > package building should work with fakeroot and should not require root > > permissions. > > It works with fakeroot, the user the build runs at is configureable in > /etc/pbuilderrc. The reason you require root for the whole thing is because of > unpacking the chroot, chrooting itself, installing build dependencies, and > purging the chroot again. You don't require root for the whole thing. pdebuild is perfectly capable of running 'sudo' when appropriate. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re[6]: ВРЕМЯ ГОВОРИТЬ ПО АНГЛИЙСКИ!!! Khan
Hello, Приходите к нам, здесь вы сможете не просто выучить язык но и отлично пообщаться. Сегодня со скидками!!! Телефоны в Москве: 105-5186 два-три-восемь-три-три-восемь-шесть Kopmels Lehnert Williams Chan Bamforth Gurchenko Cherfas Henson Canbaz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Authentication problem with pbuilder
On Wed, 28 Sep 2005, Wouter Verhelst wrote: You don't require root for the whole thing. pdebuild is perfectly capable of running 'sudo' when appropriate. This is what I thought, but have you read the beginning of this thread http://lists.debian.org/debian-devel/2005/09/msg01330.html ? Especially the Extracting source Password: su: Authentication failure Sorry. part? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please test aide 0.10-9 in experimental
After taking over aide co-maintainership in January and successfully convincing Mike to put the project on alioth, I have done some work on aide and have uploaded 0.10-8 on September 18 and 0.10-9 on September 27 to experimental. These two versions acknowledge the two NMUs we recently had and fix some issues that I thought would be worth fixing. Please test. I plan on uploading to unstable on a week, if no bad goofs surface during the experimental phase. Changelog is in the PTS, or in my blog on http://blog.zugschlus.de/archives/192-aide-0.10-9-in-experimental.html 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: planet.debian.org vs. blog illiteracy
On Mon, 26 Sep 2005 14:05:53 +0300, Lars Wirzenius <[EMAIL PROTECTED]> wrote: >I don't think there is a working way of reliably doing that. In theory, >most web logs can do "categories", but those are not being used >consistently, and they're also not really visible on planet.debian.org >in a way that lets them be processed automatically. It is already possible to have Debian Planet poll only one selected category from a blog. I use this to have only articles with category "Debian-English" appear on Debian Planet, not only because I usually blog in German. I gather that it should be possible to have articles from multiple categories appear on the Planet either by appropriately arranging the categories in a hierarchy or by multiple entries in the Planet configuration (one per category). otoh, it is nice (for me) to see the non-Debian-related opinions of my fellow developers on the Planet, so I feel that the Planet would lose some of its appeal when it only has Debian-related articles. So some categorization on the Planet itself would be a good idea, really. 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: mass bug filing on packages that are blocking use of cdebconf
On Mon, 26 Sep 2005 19:57:23 +0200, Joey Hess <[EMAIL PROTECTED]> wrote: >Mike Markley <[EMAIL PROTECTED]> > aide This is fixed in experimental (dinstall on 2005-09-27), and will go to unstable in about a week once the package (which has suffered pretty big changes) has shown not to contain any howlers. Greetings Marc, co-maintainer -- -- !! 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
Partnership between Our Sites
Dear Webmaster I looked at your website - http://lists.debian.org - and I really liked to be your partner. I own a site - http://www.replicahause.com. I would like to propose a link exchange partnership with your site. My site gets a lot of traffic every day, so a link from my site to your site will bring in a decent amount of traffic to your site. Also, as you probably already know, it will improve the link popularity and the search engine ranking of your site. I have already added a link to your site from my site at http://www.replicahause.com/shopping1.html I have used the following Title and Description for your site: Title: Debian Mailing Lists -- Index Description: Debian Mailing Lists -- Index I would really appreciate it if you could add a link to my site in return. Please use the following information for the link: Title: Rolex Replica Watches at ReplicaHause.com Description: Rolex replica watches, replica rolex watches, fake rolex watches, replica rolex daytona, replica rolex submariner at lowest prices URL: http://www.replicahause.com Here's the HTML source code that you can copy and paste in your site: http://www.replicahause.com";>Rolex Replica Watches at ReplicaHause.com - Rolex replica watches, replica rolex watches, fake rolex watches, replica rolex daytona, replica rolex submariner at lowest prices If you link back to me, I will be happy to put your website at the top of my links page (along with other sites that link back to me). If you want me to make any changes to the Title or Description of your link in my site, or if you have any questions about my proposal, please feel free to send me an email. I look forward to hearing from you soon. Best Regards, http://www.replicahause.com
Re: mass bug filing on packages that are blocking use of cdebconf
Hi, > > Of course I read debian-devel. But I fix bugs once they are > > reported. I use the BTS to track needed work in this way. > > This is of course suprerior to running vi debian/control because > beauracracy is fun. I'm transitioning one of my packages to a potential new-maintainer; and it helps to have bug reports to transfer. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Authentication problem with pbuilder
Hi, > Extracting source > Password: su: Authentication failure > Sorry. > pbuilder: Failed extracting the source > -> Aborting with an error > -> unmounting dev/pts filesystem > ... > > > I guess I have to set a further sudo permission here but for what program? > It is 'sudo su' ? I would not really like this even if it is convinient. > I've tracked the problem down to the fact that /etc/pam.d/su no longer exists with a clean install since around yesterday. Upgraded systems continue to work since /etc/pam.d/su already exists. Without /etc/pam.d/su, root running su will be asked for a password. I'm suspecting either of login 1:4.0.12-2 -> 1:4.0.12-3 pam 0.76-23->0.79-1 regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Authentication problem with pbuilder
On Wed, 28 Sep 2005, Junichi Uekawa wrote: I've tracked the problem down to the fact that /etc/pam.d/su no longer exists with a clean install since around yesterday. Upgraded systems continue to work since /etc/pam.d/su already exists. Nice that you found an issue. On the other hand my system was installed about 10 months ago and I only upgraded. I'm more or less using an up to date testing system with the exception of some packages from sid. Without /etc/pam.d/su, root running su will be asked for a password. This is not the case. I can su to any user (including root) without password if I'm logged in as root. I'm suspecting either of login 1:4.0.12-2 -> 1:4.0.12-3 login4.0.3-35 (without any changes to /etc/pam.d/su) pam 0.76-23->0.79-1 Not installed on the system in question. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: slgdbm_1.6-2_i386.changes is NEW
On Tue, 27 Sep 2005 23:03:21 +0200, Rafael Laboissiere <[EMAIL PROTECTED]> said: > * Alastair McKinstry <[EMAIL PROTECTED]> [2005-09-27 21:16]: > > My preference is for slang-foo, as it is more visible that it is > > a slang-related, rather than a generic DSO; slang-gdbm is more > > interesting to a slang developer than to a gdbm one, and this shows that. Right. > I would keep the first version really short. The only two things that > are important for now is the package naming, the installation directory > for the modules, and maybe the dependency relationships. The upstream > Makefile for slgdbm installs the module in > /usr/share/slsh/local-packages, but I moved it to /usr/share/slsh. Rather it installs the module in /usr/local/lib/slang/v2/modules, and a gdbm.sl script in /usr/local/share/slsh/local-packages, which is probably what you mean. > Do you think this is correct? As regards dependency relationships, > slgdbm has: > Suggests: slsh (>= 2.0) | jed (>= 0.99.17) | slrn (>= 0.9.8.1pl1-4) > I do not know whether this is appropriate or not. Well, it is possible to compile the gdbm module with slang 1 - of course you'd have to edit the Makefile to install in v1/modules. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to prevent a library transition
Hi, teTeX-3.0 has been sitting in experimental for a while; we have not uploaded it to unstable because it involves a library soname bump, and the release team has requested not to upload new library versions. However, there's much more to this new upstream release, also much more that requires thorough testing. Therefore I'm unhappy with the current situation, and looking for alternatives. Wouldn't it be possible to do the following: teTeX-3.0 is uploaded to unstable, including the libkpathsea4 and libkpathsea4-dev packages (it uses the library itself), but at the same time libkpathsea3 and libkpathsea-dev are still available as oldlibs, AND libkpathsea4-dev does *not* provide libkpathsea-dev. As far as I can see, in this case all other packages would continue using libkpathsea-dev (corresponding to libkpathsea3) for building, and continue to depend on libkpathsea3, which in turn would continue to be available. Only the tetex-bin deb itself would depend on libkpathsea4. Thanks to the name change from libkpathsea-dev (soname version 3) to libkpathsea4-dev, there would be no library transition at all. At some later date, we could trigger the transition, when library transitions are allowed again. I'm eager to hear your comments. (Just for the record: tetex-bin_3.0 does not contain sources for libkpathsea3; there would have to be an additional source package). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Bug#330291: Authentication problem with pbuilder
tags 330291 +patch reassign 330291 login severity 330291 serious thanks Hi, > > Extracting source > > Password: su: Authentication failure > > Sorry. > > pbuilder: Failed extracting the source > > -> Aborting with an error > > -> unmounting dev/pts filesystem > > ... > > > > > > I guess I have to set a further sudo permission here but for what program? > > It is 'sudo su' ? I would not really like this even if it is convinient. > > > > I've tracked the problem down to the fact that > /etc/pam.d/su no longer exists with a clean install > since around yesterday. > Upgraded systems continue to work since /etc/pam.d/su > already exists. > > Without /etc/pam.d/su, root running su will be asked > for a password. > > I'm suspecting either of > > login 1:4.0.12-2 -> 1:4.0.12-3 > pam 0.76-23->0.79-1 I've tracked it down to shadow; I think this is the required patch. diff -urN shadow-4.0.12-orig/debian/login.su.pam shadow-4.0.12/debian/login.su.pam --- shadow-4.0.12-orig/debian/login.su.pam 1970-01-01 09:00:00.0 +0900 +++ shadow-4.0.12/debian/login.su.pam 2005-09-28 21:16:25.598938168 +0900 @@ -0,0 +1,45 @@ +# +# The PAM configuration file for the Shadow `su' service +# + +# Uncomment this to force users to be a member of group root +# before they can use `su'. You can also add "group=foo" to +# to the end of this line if you want to use a group other +# than the default "root". +# (Replaces the `SU_WHEEL_ONLY' option from login.defs) +# auth required pam_wheel.so + +# Uncomment this if you want wheel members to be able to +# su without a password. +# auth sufficient pam_wheel.so trust + +# Uncomment this if you want members of a specific group to not +# be allowed to use su at all. +# auth required pam_wheel.so deny group=nosu + +# This allows root to su without passwords (normal operation) +auth sufficient pam_rootok.so + +# Uncomment and edit /etc/security/time.conf if you need to set +# time restrainst on su usage. +# (Replaces the `PORTTIME_CHECKS_ENAB' option from login.defs +# as well as /etc/porttime) +# accountrequisite pam_time.so + +# This module parses /etc/environment (the standard for setting +# environ vars) and also allows you to use an extended config +# file /etc/security/pam_env.conf. +# (Replaces the `ENVIRON_FILE' setting from login.defs) +auth required pam_env.so + +# The standard Unix authentication modules, used with +# NIS (man nsswitch) as well as normal /etc/passwd and +# /etc/shadow entries. [EMAIL PROTECTED] common-auth [EMAIL PROTECTED] common-account [EMAIL PROTECTED] common-session + +# Sets up user limits, please uncomment and read /etc/security/limits.conf +# to enable this functionality. +# (Replaces the use of /etc/limits in old login) +# sessionrequired pam_limits.so diff -urN shadow-4.0.12-orig/debian/passwd.su.pam shadow-4.0.12/debian/passwd.su.pam --- shadow-4.0.12-orig/debian/passwd.su.pam 2005-09-28 21:16:25.598938168 +0900 +++ shadow-4.0.12/debian/passwd.su.pam 1970-01-01 09:00:00.0 +0900 @@ -1,45 +0,0 @@ -# -# The PAM configuration file for the Shadow `su' service -# - -# Uncomment this to force users to be a member of group root -# before they can use `su'. You can also add "group=foo" to -# to the end of this line if you want to use a group other -# than the default "root". -# (Replaces the `SU_WHEEL_ONLY' option from login.defs) -# auth required pam_wheel.so - -# Uncomment this if you want wheel members to be able to -# su without a password. -# auth sufficient pam_wheel.so trust - -# Uncomment this if you want members of a specific group to not -# be allowed to use su at all. -# auth required pam_wheel.so deny group=nosu - -# This allows root to su without passwords (normal operation) -auth sufficient pam_rootok.so - -# Uncomment and edit /etc/security/time.conf if you need to set -# time restrainst on su usage. -# (Replaces the `PORTTIME_CHECKS_ENAB' option from login.defs -# as well as /etc/porttime) -# accountrequisite pam_time.so - -# This module parses /etc/environment (the standard for setting -# environ vars) and also allows you to use an extended config -# file /etc/security/pam_env.conf. -# (Replaces the `ENVIRON_FILE' setting from login.defs) -auth required pam_env.so - -# The standard Unix authentication modules, used with -# NIS (man nsswitch) as well as normal /etc/passwd and -# /etc/shadow entries. [EMAIL PROTECTED] common-auth [EMAIL PROTECTED] common-account [EMAIL PROTECTED] common-session - -# Sets up user limits, please uncomment and read /etc/security/limits.conf -# to enable this functionality. -# (Replaces the use of /etc/limits in old login) -# sessionrequired pam_limits.so diff -urN shadow-4.0.12-orig/debian/rules shadow-4.0.12/debian/rules --- shadow-4.0.12-orig/debian/rules 2005-09-28 21:16:25.599938016 +0900 +++ shadow-4.0.12/debian/rules 2005-09-28 21:33:47.577533344 +0900 @@ -115,6 +115,7 @@
Re: Authentication problem with pbuilder
Hi, > > > I've tracked the problem down to the fact that > > /etc/pam.d/su no longer exists with a clean install > > since around yesterday. > > Upgraded systems continue to work since /etc/pam.d/su > > already exists. > > Nice that you found an issue. On the other hand my system was > installed about 10 months ago and I only upgraded. I'm more or > less using an up to date testing system with the exception of some > packages from sid. The problem is that we are talking about sid here; and pbuilder depends upon a functional chroot. And you were running sid inside chroot. To summarize: today's sid was rather more unstable than usual due to shadow. regards, junichi -- Junichi Uekawa, Debian Developer http://www.netfort.gr.jp/~dancer/ 183A 70FC 4732 1B87 57A5 CE82 D837 7D4E E81E 55C1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to prevent a library transition
Le mercredi 28 septembre 2005 à 14:53 +0200, Frank Küster a écrit : > Wouldn't it be possible to do the following: teTeX-3.0 is uploaded to > unstable, including the libkpathsea4 and libkpathsea4-dev packages (it > uses the library itself), but at the same time libkpathsea3 and > libkpathsea-dev are still available as oldlibs, AND libkpathsea4-dev > does *not* provide libkpathsea-dev. Please don't do that. A library transition breaks packages in unstable for a while, but if we have both versions, we're going to have to deal with them for several *years*. That's what happened for libpng, and believe me, it's a nightmare. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: How to prevent a library transition
* Frank Küster ([EMAIL PROTECTED]) [050928 14:54]: > Wouldn't it be possible to do the following: teTeX-3.0 is uploaded to > unstable, including the libkpathsea4 and libkpathsea4-dev packages (it > uses the library itself), but at the same time libkpathsea3 and > libkpathsea-dev are still available as oldlibs, AND libkpathsea4-dev > does *not* provide libkpathsea-dev. That would work for the library issue, and would "only" makes some packages FTBFS because tetex changed (but I can think we can live with that). Even better, if you do it right, you can change the libkpathsea-dev to libkpathsea4-dev if TeTeX-3.0 has reached testing, and then the depending programs will slowly flow in (and that library transition wouldn't be as blocking as a normal one). Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Someone to take over XMTLV packages
Kenneth Pronovici <[EMAIL PROTECTED]> writes: > Hi, > I have to, I will also continue to host the backport APT repository, > although I would prefer not to. Wouldn't this be a good candidate for volatile.debian.net? Regards, Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Authentication problem with pbuilder
On Wed, 28 Sep 2005, Junichi Uekawa wrote: The problem is that we are talking about sid here; and pbuilder depends upon a functional chroot. And you were running sid inside chroot. To summarize: today's sid was rather more unstable than usual due to shadow. Sorry for my ignorance - you are perfectly all right. I verified this by untaring /var/cache/pbuilder/base.tgz, copying a clean /etc/pam.d/su* from my running system into it and rebuilded the tarball again. Then I was able to use pdebuild cleanly. Kind regards and thanks for your help Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to prevent a library transition
On Wed, Sep 28, 2005 at 02:53:59PM +0200, Frank Küster wrote: > Wouldn't it be possible to do the following: teTeX-3.0 is uploaded to > unstable, including the libkpathsea4 and libkpathsea4-dev packages (it > uses the library itself), but at the same time libkpathsea3 and > libkpathsea-dev are still available as oldlibs, AND libkpathsea4-dev > does *not* provide libkpathsea-dev. You may want to warn the maintainers of your reverse dependencies that they should not upload packages build-depending on libkpathsea4-dev, then. I imagine not everyone reads -devel, and otherwise you'll have a library transition on your hands anyway. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: slgdbm_1.6-2_i386.changes is NEW
* Paul Boekholt <[EMAIL PROTECTED]> [2005-09-28 14:38]: > On Tue, 27 Sep 2005 23:03:21 +0200, Rafael Laboissiere <[EMAIL PROTECTED]> > said: > > I would keep the first version really short. The only two things that > > are important for now is the package naming, the installation directory > > for the modules, and maybe the dependency relationships. The upstream > > Makefile for slgdbm installs the module in > > /usr/share/slsh/local-packages, but I moved it to /usr/share/slsh. > > Rather it installs the module in /usr/local/lib/slang/v2/modules, and a > gdbm.sl script in /usr/local/share/slsh/local-packages, which is probably > what you mean. Yes, this is what I meant, sorry. > > Suggests: slsh (>= 2.0) | jed (>= 0.99.17) | slrn (>= 0.9.8.1pl1-4) > > Well, it is possible to compile the gdbm module with slang 1 - of > course you'd have to edit the Makefile to install in v1/modules. The question is: can a module compiled with SLang2 be loaded by Slang1 ? In other words, is there binary backward compatibility? -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ATTN openofficeorg developers
Re: Martin in <[EMAIL PROTECTED]> > ATTN developers of openoffice org (and gnumeric) Your chances to get something changed are greatly improved by using: * a real name to send posts, * reportbug, * lower case subjects. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: How to prevent a library transition
Andreas Barth <[EMAIL PROTECTED]> wrote: > That would work for the library issue, and would "only" makes some > packages FTBFS because tetex changed (but I can think we can live with > that). Even better, if you do it right, you can change the > libkpathsea-dev to libkpathsea4-dev if TeTeX-3.0 has reached testing, I don't understand - do you mean that I change the name from libkpathsea4-dev to libkpathsea-dev, or that not *me*, but the depending packages' maintainers will change their build-dep from libkpathsea-dev to libkpathsea4-dev? > and then the depending programs will slowly flow in (and that library > transition wouldn't be as blocking as a normal one). If my second interpretation is right, we depend on maintainers' action for that. In order to make all dependencies on the old version disappear, would a "still depends on libkpathsea3" bug be RC? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Concours participez gratuitement
derniere chance de gagner 350$ en bon d achat date limite 30 septembre 2005 aucun achat requis 1 participation par personne www.equipemicrosolutions.com notez bien que c est la derniere fois que vous recevez ce email si vous n etes pas inscrit ceci est une liste qui a été récuperer d un de nos partenaires au plaisir Equipe Micro Solutions inc Pour ne plus recevoir ce message, cliquez sur le lien suivant : http://go.courrielleur.com/opt-out.php?lid=3423&uid=17389&[EMAIL PROTECTED]
Re: slgdbm_1.6-2_i386.changes is NEW
On Wed, 28 Sep 2005 15:13:08 +0200, Rafael Laboissiere <[EMAIL PROTECTED]> said: > > Well, it is possible to compile the gdbm module with slang 1 - of > > course you'd have to edit the Makefile to install in v1/modules. > The question is: can a module compiled with SLang2 be loaded by Slang1 ? In > other words, is there binary backward compatibility? No. In fact, I just found out slgdbm 1.6 does not compile with slang 1. I'll probably fix it in 1.7, but let me know if you need slang1-compatibility. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
i386-uclibc debian
Hi, I'm interested in maintaining a i386-uclibc architecture, which is, like the name says, i386 binaries linked with uClibc. My plans are: 1) Build all the packages used by debootstrap to generate a basedebs.tgz 2) Certify this basedebs works with a fresh instalation. 3) Start building a incresing number of packages, but certainly only a small subset of the i386 architecture. This is because the performance uclibc gives on old/small computers is a must to use linux on old hardware (like my crappy 486 laptop with 8Mb RAM or my pentium 133 with 32Mb RAM). I've already tested the uclibc buildroot, and it makes my 486 use only 2Mb RAM after complete boot and running a shell, but it would be much better to be able to run apt-get update, apt-get dist-upgrade... Ok, now what's the problem... The i386 packages won't be compatible with my i386-uclibc environment (as I won't have glibc installed). So I started calling the architecture i386-uclibc with gnu name i386-uclibc-linux. And I'd like to ask: Is it OK? If so, I'll submit a patch on dpkg-cross to support it (it already works on my machine). What do you think? daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: slgdbm_1.6-2_i386.changes is NEW
* Paul Boekholt <[EMAIL PROTECTED]> [2005-09-28 16:31]: > No. In fact, I just found out slgdbm 1.6 does not compile with slang 1. > I'll probably fix it in 1.7, but let me know if you need > slang1-compatibility. My guess is that we do not need SLang1 compatibility. But who knows? -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Someone to take over XMTLV packages
On Wed, Sep 28, 2005 at 03:00:40PM +0200, Emilio Jesús Gallego Arias wrote: > Kenneth Pronovici <[EMAIL PROTECTED]> writes: > > > Hi, > > > I have to, I will also continue to host the backport APT repository, > > although I would prefer not to. > > Wouldn't this be a good candidate for volatile.debian.net? You know, I asked about that once, and received no reply. So, I dropped it. KEN -- Kenneth J. Pronovici <[EMAIL PROTECTED]> pgpop5UUSKWL2.pgp Description: PGP signature
Re: i386-uclibc debian
On Wed, Sep 28, 2005 at 12:12:33PM -0300, Daniel Ruoso wrote: > What do you think? I would like to see a d-i port to that architecture! (not volunteering, sorry) Did you contact the emdebian people? Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: i386-uclibc debian
Hi, Daniel Ruoso wrote: I'm interested in maintaining a i386-uclibc architecture, which is, like the name says, i386 binaries linked with uClibc. My plans are: Well, I need an ARM bigendian uclibc port, so chances are I'm the one to coordinate with the armbe people (in fact my personal dpkg already knows of these arches). However, I can see the number of configurations to be somewhat large, so I wonder whether it makes sense to call it a new architecture (especially as uclibc binaries can happily coexist with glibc binaries as long as the same binary does not use both libraries indirectly. Given that the number of packages that make sense to run on such a system is somewhat limited, I would start out by creating "regular" i386 packages that just happen to be linked against the uclibc; said packages should be built from a special build target that is not invoked by default and generate packages with a -uc or similar suffix. For libraries, I'd even go as far as to change their soname so they can be concurrently installed to the glibc variant. This approach has several advantages: - You don't need a new arch - You can start with replacing single packages inside a running system - The packages can be added into the main archive easily if this is desired later. The i386 packages won't be compatible with my i386-uclibc environment (as I won't have glibc installed). So I started calling the architecture i386-uclibc with gnu name i386-uclibc-linux. And I'd like to ask: Is it OK? The alternative would be to rename i386 to i486 and call the new port i386. But that would be an evil transition. Simon signature.asc Description: OpenPGP digital signature
Re: i386-uclibc debian
Em Qua, 2005-09-28 às 15:39 +, W. Borgert escreveu: > On Wed, Sep 28, 2005 at 12:12:33PM -0300, Daniel Ruoso wrote: > > What do you think? > I would like to see a d-i port to that architecture! > (not volunteering, sorry) Actually... As far as i could see, this would be an easy task... > Did you contact the emdebian people? No, but I did use their resources while trying to build the cross-compiling (ok, not exactly cross, but almost). And unlike them I'm using just plain dpkg-buildpackage to build everything. That's why I choose to use it as an arch. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: i386-uclibc debian
Em Qua, 2005-09-28 às 18:03 +0200, Simon Richter escreveu: > Daniel Ruoso wrote: > > I'm interested in maintaining a i386-uclibc architecture, which is, like > > the name says, i386 binaries linked with uClibc. > However, I can see the number of configurations to be somewhat large, so > I wonder whether it makes sense to call it a new architecture > (especially as uclibc binaries can happily coexist with glibc binaries > as long as the same binary does not use both libraries indirectly). Well, the main reason is that glibc probably won't be even installed on most machines using this environment, and, the pratical reason is that it makes easier to start up like this. I mean, if I setup it as a different architecture I can use plain dpkg-buildpackage -ai386-uclibc to build it inside my i386 installation, using the cross-build infrastructure provided by the uclibc toolchain and dpkg-cross. > Given that the number of packages that make sense to run on such a > system is somewhat limited, I would start out by creating "regular" > i386 packages that just happen to be linked against the uclibc; said > packages should be built from a special build target that is not > invoked by default and generate packages with a -uc or similar > suffix. For libraries, I'd even go as far as to change their soname > so they can be concurrently installed to the glibc variant. Well... In contrast, this solution will require a bigger, much bigger, effort. > This approach has several advantages: > - You don't need a new arch I'm not sure this is an advantage, because in real world, glibc and uclibc won't be even installed together for this environment. > - You can start with replacing single packages inside a running system This is not the idea. The idea is to provide a full uclibc installation... > - The packages can be added into the main archive easily if this is > desired later. Only if I rename a lot of packages... Considering a new arch, it would be just there... > > The i386 packages won't be compatible with my i386-uclibc environment > > (as I won't have glibc installed). So I started calling the architecture > > i386-uclibc with gnu name i386-uclibc-linux. And I'd like to ask: Is it > > OK? > The alternative would be to rename i386 to i486 and call the new port > i386. But that would be an evil transition. Yeah... I thought about it... Actually, this would be a good excuse to promote i386 to i486... but certainly, this would be an evlll transition, I don't want to think about it, so, i386-uclibc starts to be an interesting option... daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Circular testing excuses for swt-gtk and swingwt
I am trying to help move swt-gtk into testing. The excuses [1] for swingwt, which depends on swt-gtk, says... * swingwt is waiting for swt-gtk * Updating swt-gtk makes 2 depending packages uninstallable on arm: libswingwt0, swingwt-demo These excuses seem to be circular between swingwt and swt-gtk. Why does updating swt-gtk make swingwt uninstallable on arm? ARM is up to date with swt-gtk 3.1-2 and swingwt 0.87-2. To aggravate the matter, swingwt is failing to build on three architectures: alpha: unmet dependencies: libswt-gtk-3.1 (= 3.0+3.1M4-5) hppa: gcj 4.0.1 ICE (internal compiler error) sparc: unmet dependencies: libswt-gtk-3.1 (= 3.1-1) Both alpha and sparc have now built libswt-gtk-3.1 (= 3.1-2), so those two unmet dependencies errors should go away I hope. Buildds are near magic to me; I am constantly in awe. I'm unable to differentiate the transient that will resolve themselves in a week or two from the permanent errors. Cheers, Shaun [1] http://bjorn.haxx.se/debian/testing.pl?package=swt-gtk
Re: Authentication problem with pbuilder
Quoting Junichi Uekawa ([EMAIL PROTECTED]): > To summarize: today's sid was rather more unstable than usual > due to shadow. Please bash the shadow maintainers..:-) Supposedly fixed in 4.0.12-5 There was a very transitional 4.0.12-4 during 15 minuteswhich claimed to fix the mess with su PAM file but didn't. I'm not sure that 4.0.12-5 will make it before dinstall run, unfortunately. 4.0.12-4 fixes the conflicts with manpages-xx packages, though. I tried to fix all this as soon as possible but unfortunately discovered about the problem very late in the day because of schedule constraints. So, I attempted a very urgent upload with barely no testing at allnot the usual way we handle things in shadow but it probably deserved it. Sorry, pals. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder status update
Hello Junichi! Junichi Uekawa Junichi Uekawa <[EMAIL PROTECTED]>: > pbuilder is doing as usual; it's now switched over to > cdebootstrap and cdebootstrap has been working fine. > Not for me. I maintain my own small mirror by apt-move together with apt-zip because I own a small modem line, but can download elsewhere. It wasn't able to use this mirror with pbuilder+cdebootstrap because cdebootstrap will see Release.gpg and Packages.gpg files, that I haven't generated (no need to do so yet). Is there any way to switch this off in cdebootstrap? Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: i386-uclibc debian
In article <[EMAIL PROTECTED]>, Daniel Ruoso <[EMAIL PROTECTED]> wrote: >I'm interested in maintaining a i386-uclibc architecture, which is, like >the name says, i386 binaries linked with uClibc. My plans are: > >Ok, now what's the problem... > >The i386 packages won't be compatible with my i386-uclibc environment >(as I won't have glibc installed). So I started calling the architecture >i386-uclibc with gnu name i386-uclibc-linux. And I'd like to ask: Is it >OK? Search for 'multiarch'. I understand (and/or hope) that in etch the multiarch effort will get off the ground. Multiarch means that you can install for example both 32-bits and 64-bits packages on a system with an x86_64 CPU and kernel. There is a 32-bits 'bash' package and a 64-bits 'bash' package and you can install either one. In your case, there would also be a 32-bits-uclibc bash. You can even use a standard install and later install the 32-bits-uclibc packages to replace the normal packages - voila. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: i386-uclibc debian
Em Qua, 2005-09-28 às 18:41 +, Miquel van Smoorenburg escreveu: > In article <[EMAIL PROTECTED]>, > Daniel Ruoso <[EMAIL PROTECTED]> wrote: > >The i386 packages won't be compatible with my i386-uclibc environment > >(as I won't have glibc installed). So I started calling the architecture > >i386-uclibc with gnu name i386-uclibc-linux. And I'd like to ask: Is it > >OK? > Search for 'multiarch'. I understand (and/or hope) that in etch > the multiarch effort will get off the ground. Hmmm... Interesting... If I follow this, it gives me one more reason to see it as another architecture, and when the multiarch support get off the ground I will benefit too. It's much better than patching and renaming packages to make them co-exist. I think I'll go on with the new architecture... daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330593: ITP: lastfm -- an audio player for last.fm personalized radio
Package: wnpp Severity: wishlist Owner: Paul Telford <[EMAIL PROTECTED]> Package name: lastfm Version : 1.0.3 Upstream Author : Last.fm Ltd <[EMAIL PROTECTED]> URL : http://www.last.fm/help/player/ License : BSD (but see below) Description : an audio player for last.fm personalized radio Last.fm is the flagship product from the team that designed the Audioscrobbler system, a music engine based on a massive collection of Music Profiles. Each music profile belongs to one person, and describes their taste in music. Last.fm uses these music profiles to make personalized recommendations, match you up with people who like similar music, and generate custom radio stations for each person. This package will allow you to play your personalized radio station streams from the last.fm website. License is listed as BSD on their site, but there are some potential problems with a couple of linked files which are GPL. Need to resolve this before I can upload. I'm already in contact with upstream and hope to be able to get it resolved. -- 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.9-prep-1-686 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: better init.d/* : who carres ?
Alfie Costa <[EMAIL PROTECTED]> writes: | Wed, 21 Sep 2005 09:32:41 +, Gerrit Pape wrote: | | ...but try come up with a rule of thumb for '%%' (big suffix), '#' | (small prefix), etc.? Maybe the 'p' in percent is for Prefix -- but no, | the Prefix is the hash symbol; two signs are bigger than one, like Roman | numerals... it's a puzzle. It's in fact easier; the keys can be visualized easily. On keyboard: # % is on the leftis on the right So, "Delete left" or "Delete right". And the more character, there more deletion (That's %% and ##). Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to prevent a library transition
On Wed, 28 Sep 2005, Frank Küster wrote: > If my second interpretation is right, we depend on maintainers' action > for that. In order to make all dependencies on the old version > disappear, would a "still depends on libkpathsea3" bug be RC? Yes, fixable with a quick-and-dirty NMU that only does a rebuild against the new one... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Bug#330601: ITP: libiec61883 -- an partial implementation of IEC 61883
Package: wnpp Severity: wishlist Owner: Marcio Roberto Teixeira <[EMAIL PROTECTED]> * Package name: libiec61883 Version: 1.0.0 Upstream Authors: Kristian HÃberg <[EMAIL PROTECTED]> (cip and amdtp) Dan Maas <[EMAIL PROTECTED]> (dv, mpeg-2, tsbuffer) Dan Dennedy <[EMAIL PROTECTED]> (dv, plug, cmp, mpeg-2) Charles Yates <[EMAIL PROTECTED]> (deque) Hugo Villeneuve <[EMAIL PROTECTED]>(amdtp) Jim Westfall <[EMAIL PROTECTED]>(mpeg-2) Pieter Palmers <[EMAIL PROTECTED]> (amdtp) * URL: http://www.linux1394.org/ * License: LGPL Description: an partial implementation of IEC 61883 This library is an implementation of IEC 61883, part 1 (CIP, plug registers, and CMP), part 2 (DV-SD), part 4 (MPEG2-TS), and part 6 (AMDTP). Outside of IIDC, nearly all FireWire multimedia devices use IEC 61883 protocols. The libiec61883 library provides a higher level API for streaming DV, MPEG-2 and audio over Linux IEEE 1394. This includes both reception and transmission. It uses the new "rawiso" API of libraw1394, which transparently provides mmap-ed DMA for efficient data transfer. It also represents the third generation of I/O technology for Linux 1394 for these media types thereby removing the complexities of additional kernel modules, /dev nodes, and procfs. It also consolidates features for plug control registers and connection management that previously existed in experimental form in an unreleased version of libavc1394. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (101, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11y Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=ISO-8859-1) (ignored: LC_ALL set to pt_BR)
Re: i386-uclibc debian
On Wed, 28 Sep 2005, Daniel Ruoso wrote: > Em Qua, 2005-09-28 às 18:41 +, Miquel van Smoorenburg escreveu: > > In article <[EMAIL PROTECTED]>, > > Daniel Ruoso <[EMAIL PROTECTED]> wrote: > > >The i386 packages won't be compatible with my i386-uclibc environment > > >(as I won't have glibc installed). So I started calling the architecture > > >i386-uclibc with gnu name i386-uclibc-linux. And I'd like to ask: Is it > > >OK? > > Search for 'multiarch'. I understand (and/or hope) that in etch > > the multiarch effort will get off the ground. > > Hmmm... Interesting... If I follow this, it gives me one more reason to > see it as another architecture, and when the multiarch support get off > the ground I will benefit too. Wouldn't it be better off as a *subarchitecture* ? (are subarchs supported by multiarch at all?) Adding archs is not that straight forward. e.g. what the heck will happen when someone tries to use config.sub or config.guess? What *should* happen then? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: i386-uclibc debian
Em Qua, 2005-09-28 às 18:07 -0300, Henrique de Moraes Holschuh escreveu: > > > Daniel Ruoso <[EMAIL PROTECTED]> wrote: > > > >The i386 packages won't be compatible with my i386-uclibc environment > > > >(as I won't have glibc installed). So I started calling the architecture > > > >i386-uclibc with gnu name i386-uclibc-linux. And I'd like to ask: Is it > > > >OK? > Adding archs is not that straight forward. e.g. what the heck will happen > when someone tries to use config.sub or config.guess? What *should* happen > then? Nothing special... dpkg-buildpackage will handle it and the (non-debian) build scripts will receive just i386 as architecture, but i386-uclibc-linux-* as tool chain. And that's why using it as an architecture makes it so easy. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wed, 2005-09-28 at 23:56 +0300, Jari Aalto wrote: > Alfie Costa <[EMAIL PROTECTED]> writes: > > | Wed, 21 Sep 2005 09:32:41 +, Gerrit Pape wrote: > | > | ...but try come up with a rule of thumb for '%%' (big suffix), '#' > | (small prefix), etc.? Maybe the 'p' in percent is for Prefix -- but no, > | the Prefix is the hash symbol; two signs are bigger than one, like Roman > | numerals... it's a puzzle. > > It's in fact easier; the keys can be visualized easily. On keyboard: > > # % > > is on the leftis on the right Not on an en_GB keyboard they aren't. (Leaving aside the fact that at least en_GB iMac keyboards don't even have a key with a # legend). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Authentication problem with pbuilder
On Wed, Sep 28, 2005 at 09:13:46PM +0900, Junichi Uekawa wrote: > > Extracting source > > Password: su: Authentication failure > > Sorry. > > pbuilder: Failed extracting the source > > -> Aborting with an error > > -> unmounting dev/pts filesystem > > ... > > I guess I have to set a further sudo permission here but for what program? > > It is 'sudo su' ? I would not really like this even if it is convinient. > I've tracked the problem down to the fact that > /etc/pam.d/su no longer exists with a clean install > since around yesterday. > Upgraded systems continue to work since /etc/pam.d/su > already exists. > Without /etc/pam.d/su, root running su will be asked > for a password. > I'm suspecting either of > login 1:4.0.12-2 -> 1:4.0.12-3 > pam 0.76-23->0.79-1 Suspect only the first. pam doesn't control any per-application config files. -- 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
Re: i386-uclibc debian
On Wed, Sep 28, 2005 at 12:12:33PM -0300, Daniel Ruoso wrote: > I'm interested in maintaining a i386-uclibc architecture, which is, like > the name says, i386 binaries linked with uClibc. My plans are: > 1) Build all the packages used by debootstrap to generate a basedebs.tgz > 2) Certify this basedebs works with a fresh instalation. > 3) Start building a incresing number of packages, but certainly only a > small subset of the i386 architecture. > This is because the performance uclibc gives on old/small computers is a > must to use linux on old hardware (like my crappy 486 laptop with 8Mb > RAM or my pentium 133 with 32Mb RAM). I've already tested the uclibc > buildroot, and it makes my 486 use only 2Mb RAM after complete boot and > running a shell, but it would be much better to be able to run apt-get > update, apt-get dist-upgrade... > Ok, now what's the problem... > The i386 packages won't be compatible with my i386-uclibc environment > (as I won't have glibc installed). So I started calling the architecture > i386-uclibc with gnu name i386-uclibc-linux. And I'd like to ask: Is it > OK? Can libstdc++ be built against uclibc? You're going to have a hard time basing a Debian port on uclibc without it. -- 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
Re: i386-uclibc debian
Em Qua, 2005-09-28 às 16:20 -0700, Steve Langasek escreveu: > > The i386 packages won't be compatible with my i386-uclibc environment > > (as I won't have glibc installed). So I started calling the architecture > > i386-uclibc with gnu name i386-uclibc-linux. And I'd like to ask: Is it > > OK? > Can libstdc++ be built against uclibc? You're going to have a hard time > basing a Debian port on uclibc without it. Well, it looks like it can[1]. But I'm downloading gcc source right now to test it... daniel [1] http://www.uclinux.org/pub/uClinux/archive/4886.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to prevent a library transition
Frank Kuester wrote: > As far as I can see, in this case all other packages would continue > using libkpathsea-dev (corresponding to libkpathsea3) for building, and > continue to depend on libkpathsea3, which in turn would continue to be > available. Only the tetex-bin deb itself would depend on libkpathsea4. > > Thanks to the name change from libkpathsea-dev (soname version 3) to > libkpathsea4-dev, there would be no library transition at all. At some > later date, we could trigger the transition, when library transitions > are allowed again. So the plan is to make sure that there are no other shared libraries linked to libkpathsea4 at all; only the executables from tetex-bin? That should work, as long as you make sure that nobody else at all links against libkpathsea4. You'll want to mail every maintainer of a package depending on libkpathsea-dev to tell them *not* to update their packages to libkpathsea4 until you give the go-ahead. And then you'll have to mail them all again when you do give the go-ahead! I notice that the symbols in libkpathsea3 are *not* versioned. I'm guessing that the symbols in libkpathsea4 aren't either (if they are, ignore the following). Accordingly, when the transition happens, you'll have to make sure nothing is linked (even indirectly) to both versions. This actually looks like it won't be a problem; I don't think there are any programs which link kpathsea through two different dependency chains (in fact, I only found one library which links to kpathsea: vflib3). -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
