Re: wnpp situation

[Jari Aalto]

Bas Zoetekouw <[EMAIL PROTECTED]> writes:

> Hi David!
>
> About ITP's, they should be retitled to RFPs, rather than closed.  That
> way, other people can have a go at packaging the software.
>

I concur. If someone did not produce a packge withing NN days (say 3
months) after ITP, the system should automtically send the ITP
sumitter mail, that his packaging effort has been returned to stae RFP
and he is no longer the "owner" of that ITP.

Jari


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: wnpp situation

[Christian Marillat]

Paul TBBle Hampson <[EMAIL PROTECTED]> writes:

> On Wed, Sep 14, 2005 at 02:34:51PM +0200, Vedran Furac wrote:
>> Btw. why then mencoder, can't be packaged? Why are only ffmpeg -dev in
>> debian: http://packages.qa.debian.org/f/ffmpeg.html?
>
> Only ffmpeg-dev is in Debian as ffmpeg upstream recommends static linking
> due to not having fixed the API/ABI.

Upstream recommends nothing. Upstream simply don't care about shared
libraries.

Christian


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: your mail

[Stephen Gran]

This one time, at band camp, Talal Al-Azem said:
> Hello.  I have recently installed emacs-bidi on suse 9.1, kde 3.2.3.  I have
> it running, but when I try to type in Arabic script in the right-to-left, it
> doesn’t appear correctly…i.e. don’t see anything on the screen, but I see
> the cursor moving.
> 
> Any ideas?  Thanks, and sorry for what must be such a ridiculous ly basic
> question.
> 
> p.s. any advice on a bidi sensitive (for arabic) latex editor on KDE or
> Gnome?  thanks.

This list is for general discussion of the development of Debian.  It
sounds like your question would be better suited to one the user
discussion lists.  The main one is debian-user@lists.debian.org, but
there are also several others aimed at people who use Debian in other
languages.  I do not remember offhand if there is an Arabic list at the
moment, however, sorry.  The full list of available mailing lists can be
found at http://lists.debian.org/
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Bug#328434: ITP: grepmap -- Parse module map files produced by depmod

[Colin Watson]

Package: wnpp
Severity: wishlist
Owner: Colin Watson <[EMAIL PROTECTED]>

* Package name: grepmap
  Version : 0.1.0
  Upstream Author : Scott James Remnant <[EMAIL PROTECTED]>
* URL : http://archive.ubuntu.com/ubuntu/pool/main/g/grepmap/
* License : GPL
  Description : Parse module map files produced by depmod

 This package contains a utility to parse the map files produced by the
 depmod tool in the module-init-tools package and output the list of
 modules you should load for a device.

We've been using this in Ubuntu for some time, so I know it works well;
I've just failed to get round to shifting it into Debian until now.

I realise that this package will eventually be superseded by changes in
(or rewrites of) the udev/hotplug stack. However, in the meantime it
allows the process of booting a system using hotplug to be substantially
sped up, by replacing some slow shell code that forks lots of
subprocesses with faster C code. I expect this to be useful when
experimenting with versions of d-i that use hotplug in the near future.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

removal of support for /etc/hotplug/usb/

[Marco d'Itri]

After having been deprecated for a long time, support for map files in
the /etc/hotplug/usb/ directory will be removed from the udev-hotplug
subsystem. This is scheduled to happen next month, when most of the
current hotplug package will be replaced by a new coldplug program
which will be part of udev.

While udev provides and currently enables by default an helper program
to maintain compatibility with /etc/hotplug.d/, no such program exists
for map files and I do not think it would be useful to write one
(conversion to hotplug.d scripts would be easier).

This means that the following packages will have to convert their map
files to udev rules files. Please remember that rules files MUST NOT be
installed in /etc/udev/rules.d/ but in /etc/udev/, and packages should
create symlinks to rules.d/ only when installed for the first time and
never again.

If you want to keep support for 2.4-based systems which can only use the
old hotplug package then you will need to convert your script to an
hotplug.d script, but please remember that future versions of udev will
disable by default processing of hotplug.d and dev.d.

Let me know if you have any questions or need help to fix your package.
Many of the scripts can be replaced with an udev rule to set the
appropriate permissions or directly start/stop the relevant daemon, I
added some comments below for a few packages which I checked.

The affected packages are:

libgpib-bin
bluez-bcm203x
eagle-usb-utils
eciadsl
gpsd
hpoj
pmp-common
kino (just run killall or start-stop-daemon from the rule)
libgphoto2-2 (should use a proper rule to change the permissions)
nut-usb
kcontrol (should use a proper rule to change the permissions)
libnjb-hotplug
openct
sl-modem-daemon

-- 
ciao,
Marco


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#323227: new list: debian-planet to distribute planet.debian.org postings; archive to enable searching

[Andrew Pollock]

On Wed, Sep 14, 2005 at 01:01:42PM +0200, Alexander Schmehl wrote:
> * Tollef Fog Heen <[EMAIL PROTECTED]> [050914 10:47]:
> > | Maybe, if you don't want your output to be found on the Internet, you
> > | should not make it available on the Internet?
> > I think there is a difference between putting it all in one place with
> > a public archive and having the content available, but not organised
> > into a public archive.
> 
> Don't know how planet works, but if we have somewhere the "get feed from
> $foo" and "get hackergotchi from $bar" configuration, can't we just add
> an "doesn't like to get to the list archive" configuration option, too?
> 

Or run a second Planet instance, specifically for the purpose of being
archived, that is opt-in?

regards

Andrew


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Managing users and groups within multiple devel chroots.

[Andrew Pollock]

On Wed, Sep 14, 2005 at 02:12:54PM -0700, Rob Browning wrote:
> 
> Is it possible to configure a set of chroots (woody, sarge, whatever)
> so that all of the chroot passwd/group DBs will stay in sync with each
> other and with the host DB automaticall, so that, for example, a
> useradd, usermod, or userdel, will automatically affect all of the DBs
> simultaneously and safely?

I haven't investigated if adduser supports this properly (and I suspect it
doesn't), but LDAP authentication across the whole lot would do the trick.
 
> For this to work right, in addition to everything else, I assume that
> Debian policy would also have to guarantee that no package will ever
> remove a user/group when purged, and no package will balk if the
> user/group it needs already exists.
> 

regards

Andrew


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: removal of support for /etc/hotplug/usb/

[Andrew Pollock]

On Thu, Sep 15, 2005 at 12:21:08PM +0200, Marco d'Itri wrote:
> After having been deprecated for a long time, support for map files in
> the /etc/hotplug/usb/ directory will be removed from the udev-hotplug
> subsystem. This is scheduled to happen next month, when most of the
> current hotplug package will be replaced by a new coldplug program
> which will be part of udev.
> 
> While udev provides and currently enables by default an helper program
> to maintain compatibility with /etc/hotplug.d/, no such program exists
> for map files and I do not think it would be useful to write one
> (conversion to hotplug.d scripts would be easier).
> 
> This means that the following packages will have to convert their map
> files to udev rules files. Please remember that rules files MUST NOT be
> installed in /etc/udev/rules.d/ but in /etc/udev/, and packages should
> create symlinks to rules.d/ only when installed for the first time and
> never again.
> 
> If you want to keep support for 2.4-based systems which can only use the
> old hotplug package then you will need to convert your script to an
> hotplug.d script, but please remember that future versions of udev will
> disable by default processing of hotplug.d and dev.d.
> 
> Let me know if you have any questions or need help to fix your package.
> Many of the scripts can be replaced with an udev rule to set the
> appropriate permissions or directly start/stop the relevant daemon, I
> added some comments below for a few packages which I checked.
> 
> The affected packages are:
> 
> libgpib-bin
> bluez-bcm203x
> eagle-usb-utils
> eciadsl
> gpsd
> hpoj
> pmp-common
> kino (just run killall or start-stop-daemon from the rule)
> libgphoto2-2 (should use a proper rule to change the permissions)
> nut-usb
> kcontrol (should use a proper rule to change the permissions)
> libnjb-hotplug
> openct
> sl-modem-daemon
> 

And using the very funky dd-list, gives us a potentially more useful list:

Eduard Bloch <[EMAIL PROTECTED]>
   sl-modem

Paul Brossier <[EMAIL PROTECTED]>
   kino

Debian Qt/KDE Maintainers 
   kdebase

Eric Dorland <[EMAIL PROTECTED]>
   openct

Edd Dumbill <[EMAIL PROTECTED]>
   bluez-utils

Shaun Jackman <[EMAIL PROTECTED]>
   libnjb

Robert Jordens <[EMAIL PROTECTED]>
   gpib

Tilman Koschnick <[EMAIL PROTECTED]>
   gpsd

Cyril Martin <[EMAIL PROTECTED]>
   eagle-usb

Frederic Peters <[EMAIL PROTECTED]>
   libgphoto2

Mark Purcell <[EMAIL PROTECTED]>
   hpoj

Arnaud Quette <[EMAIL PROTECTED]>
   nut

Joe Wreschnig <[EMAIL PROTECTED]>
   pmp-common

Marco d'Itri <[EMAIL PROTECTED]>
   eciadsl

regards

Andrew


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Managing users and groups within multiple devel chroots.

[Ernestas V.]

Perhaps hard/symlinking original /etc/passwd, /etc/shadow and /etc/group 
to chrooted environments would help?


Rob Browning wrote:


Is it possible to configure a set of chroots (woody, sarge, whatever)
so that all of the chroot passwd/group DBs will stay in sync with each
other and with the host DB automaticall, so that, for example, a
useradd, usermod, or userdel, will automatically affect all of the DBs
simultaneously and safely?
 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Managing users and groups within multiple devel chroots.

[Peter Samuelson]

[Ernestas V.]
> Perhaps hard/symlinking original /etc/passwd, /etc/shadow and
> /etc/group to chrooted environments would help?

Symlinks won't work.  Think about what a chroot environment *is*.

Hardlinks will only work if the programs that edit /etc/passwd and
/etc/group overwrite them rather than copy / unlink.

Bind mounts will work
(mount --bind /etc/passwd /mnt/sarge-chroot/etc/passwd)
but apparently don't support locking all of a file's representations,
so you would need to be careful not to run adduser in multiple chroots
at once (like doing several dist-upgrades in parallel, or having users
log in to different chroots and all try to change their passwords at
once).


signature.asc
Description: Digital signature

Re: Managing users and groups within multiple devel chroots.

[Marco d'Itri]

On Sep 15, Peter Samuelson <[EMAIL PROTECTED]> wrote:

> Bind mounts will work
> (mount --bind /etc/passwd /mnt/sarge-chroot/etc/passwd)
> but apparently don't support locking all of a file's representations,
What about bind-mounting the /etc/.pwd.lock lock file too?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: XINE and plugins without Depends cause hangs due to a bug

[Adeodato Simó]

* Adeodato Simó [Wed, 14 Sep 2005 02:38:28 +0200]:

>   I believe the "not coping" above is a xine bug, but one that I have no
>   time, nor interest, on hunting, reporting upstream, or whatever. I
>   will file it in our BTS, though, by sending a copy of this mail. But
>   still, and in the meantime, its effects are biting our users for real.
  
  New upstream version 1.0.2 contains a patch "to cope", so:

>   I plan on workarounding this in a NMU by reverting to plain
>   dh_shlibdeps behavior until the bug described above gets fixed.

  The NMU will backport the patch instead.

  Cheers,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Don't ask the barber whether you need a haircut.
-- Daniel S. Greenberg


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Try that job

[Sarah Brandon]

USA located financial company is in search of the agents in the United Kingdom.
You have to be older then 22.
Honest and serious.
Also you need to have basic financial skills and accounting skills.
Salary is 2700-3300 pounds per month.
It is possible to use as a part time job.
Send me your resume to email : [EMAIL PROTECTED]
Thank you for the assistance,


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Managing users and groups within multiple devel chroots.

[Richard Atterer]

On Wed, Sep 14, 2005 at 02:12:54PM -0700, Rob Browning wrote:
> Is it possible to configure a set of chroots (woody, sarge, whatever)
> so that all of the chroot passwd/group DBs will stay in sync with each
> other and with the host DB automaticall, so that, for example, a
> useradd, usermod, or userdel, will automatically affect all of the DBs
> simultaneously and safely?

>From the adduser/addgroup manpage:
  
  If the file /usr/local/sbin/adduser.local exists, it will be executed
  after the user account has been set up in order to do any local setup. 
  The arguments passed to adduser.local are: username uid gid
  home-directory, and the environment variables DEBUG and VERBOSE will be
  set according to the settings in the master program.

You can use this to execute the same adduser/addgroup command in the 
chroot. While this doesn't guarantee that the different files are 100% in 
sync, I think it'll get close enough for practical usage.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#327029: Non-functional with read-only /dev

[SZALAY Attila]

Hi All (and sorry for my English)!

I have a bug about syslog-ng. This bug is a reincarnation of an already
closed bug, but I afraid, if I close this too, another incarnation will
be happened.

The problem is, that nor sysklogd nor syslog-ng could operate if
couldn't write to /dev. (They try to remove /dev/log and create it
again).

What should I do?
Fill a bug with base-system to make /dev/log to be a link to somewhere?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Build-Depend'ing on libasound2-dev just for Linux

[Lawrence Williams]

Hello,

I am working on a package that Build-Depends on libasound2-dev, but can be 
built on non-Linux OSs. Is there any way to shape the Build-Dep so that 
libasound2-dev is only used if we are building for a Linux system?

I seen an example of a possible choice in xorg-x11 packages that Build-Dep on 
linux-kernel-headers, but I wasn't sure if I should follow their example:

linux-kernel-headers (>= 2.6.13+0rc3-1.1) 
[!hurd-i386 !netbsd-i386 !kfreebsd-i386]

In Debian, does this prevent it from building on anything other than Linux??

Lawrence


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Build-Depend'ing on libasound2-dev just for Linux

[Nico Golde]

Hallo Lawrence,

* Lawrence Williams <[EMAIL PROTECTED]> [2005-09-15 17:46]:
> I am working on a package that Build-Depends on libasound2-dev, but can be 
> built on non-Linux OSs. Is there any way to shape the Build-Dep so that 
> libasound2-dev is only used if we are building for a Linux system?
> 
> I seen an example of a possible choice in xorg-x11 packages that Build-Dep on 
> linux-kernel-headers, but I wasn't sure if I should follow their example:
> 
> linux-kernel-headers (>= 2.6.13+0rc3-1.1) 
> [!hurd-i386 !netbsd-i386 !kfreebsd-i386]
> 
> In Debian, does this prevent it from building on anything other than Linux??

It does prevent the build on the specified archs, yes.
Regards Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org


pgpzVjYgRVdUX.pgp
Description: PGP signature

Re: Build-Depend'ing on libasound2-dev just for Linux

[Lawrence Williams]

Thanks Nico,

But I want the libasound2-dev Build-Depend to only be used if we are building 
for Linux, not BSD or anything else :)

Lawrence

On September 15, 2005 01:20 pm, Nico Golde wrote:
> It does prevent the build on the specified archs, yes.
> Regards Nico


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Build-Depend'ing on libasound2-dev just for Linux

[Nico Golde]

Hi,
* Lawrence Williams <[EMAIL PROTECTED]> [2005-09-15 17:56]:
> But I want the libasound2-dev Build-Depend to only be used if we are building 
> for Linux, not BSD or anything else :)

oh sorry, misunderstandig.
regards nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org


pgpPWd0nLEnuC.pgp
Description: PGP signature

Re: Build-Depend'ing on libasound2-dev just for Linux

[David Nusinow]

On Thu, Sep 15, 2005 at 01:13:14PM -0230, Lawrence Williams wrote:
> I seen an example of a possible choice in xorg-x11 packages that Build-Dep on 
> linux-kernel-headers, but I wasn't sure if I should follow their example:
> 
> linux-kernel-headers (>= 2.6.13+0rc3-1.1) 
> [!hurd-i386 !netbsd-i386 !kfreebsd-i386]
> 
> In Debian, does this prevent it from building on anything other than Linux??

This was the goal of the line you mention. Unfortunately, I'm not aware of
any sort of simple test like "linux-kernel-headers (>=foo) [linux]" in
dpkg, so I had to explicitly remove non-linux ports from the requirement.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#327029: Non-functional with read-only /dev

[Marco d'Itri]

On Sep 15, SZALAY Attila <[EMAIL PROTECTED]> wrote:

> What should I do?
Tell the user to learn how UNIX works, and stop bitching.
AF_UNIX sockets must be created on a rw file system, and a symlink will
not work.
So either he uses udev, or in some way makes his own writeable /dev.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Managing users and groups within multiple devel chroots.

[Rob Browning]

"Ernestas V." <[EMAIL PROTECTED]> writes:

> Perhaps hard/symlinking original /etc/passwd, /etc/shadow and /etc/group 
> to chrooted environments would help?

Thanks for the suggestion, but I suspect that locking wouldn't work
correctly in such an arrangement.

If you could tell the system to use a separate directory for the db
files and bind mount that directory among all the chroots, then
perhaps that would fix the locking problem (presuming the default
setup uses fs locks).

Thanks again
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Build-Depend'ing on libasound2-dev just for Linux

[Kevin B. McCarty]

David Nusinow wrote:

> On Thu, Sep 15, 2005 at 01:13:14PM -0230, Lawrence Williams wrote:
>> I seen an example of a possible choice in xorg-x11 packages that Build-Dep 
>> on 
>> linux-kernel-headers, but I wasn't sure if I should follow their example:
>> 
>> linux-kernel-headers (>= 2.6.13+0rc3-1.1) 
>> [!hurd-i386 !netbsd-i386 !kfreebsd-i386]
>> 
>> In Debian, does this prevent it from building on anything other than Linux??
> 
> This was the goal of the line you mention. Unfortunately, I'm not aware of
> any sort of simple test like "linux-kernel-headers (>=foo) [linux]" in
> dpkg, so I had to explicitly remove non-linux ports from the requirement.

Doesn't the type-handling package do what you guys are looking for?
Looks like it needs to be used somehow in combination with sed and a
debian/control.in file, perhaps in "debian/rules clean"...

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Build-Depend'ing on libasound2-dev just for Linux

[David Moreno Garza]

On Thu, 2005-09-15 at 13:13 -0230, Lawrence Williams wrote:
> Hello,
> 
> I am working on a package that Build-Depends on libasound2-dev, but can be 
> built on non-Linux OSs. Is there any way to shape the Build-Dep so that 
> libasound2-dev is only used if we are building for a Linux system?

You may be interested on type-handling package. From its description:

This package provides a script known as "type-handling", whose 
purpose is converting System and CPU combinations into the 
architecture variable names that dpkg can understand.

This is also used on several packages.

--
David Moreno Garza <[EMAIL PROTECTED]>   | http://www.damog.net/
   <[EMAIL PROTECTED]>  | GPG: C671257D
  Not only is it better to have loved and lost, it's cheaper.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Build-Depend'ing on libasound2-dev just for Linux

[David Moreno Garza]

On Thu, 2005-09-15 at 13:05 -0400, Kevin B. McCarty wrote:
> Doesn't the type-handling package do what you guys are looking for?

Yes, it does. And it rocks.

--
David Moreno Garza <[EMAIL PROTECTED]>   | http://www.damog.net/
   <[EMAIL PROTECTED]>  | GPG: C671257D
  Infinita tristeza.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#327029: Non-functional with read-only /dev

[SZALAY Attila]

On Thu, 2005-09-15 at 18:30 +0200, Marco d'Itri wrote:
:
> Tell the user to learn how UNIX works, and stop bitching.
> AF_UNIX sockets must be created on a rw file system, and a symlink will
> not work.

On FreeBSD it works. So I think it's possible.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Managing users and groups within multiple devel chroots.

[Rob Browning]

Richard Atterer <[EMAIL PROTECTED]> writes:

>>From the adduser/addgroup manpage:
>   
>   If the file /usr/local/sbin/adduser.local exists, it will be executed
>   after the user account has been set up in order to do any local setup. 
>   The arguments passed to adduser.local are: username uid gid
>   home-directory, and the environment variables DEBUG and VERBOSE will be
>   set according to the settings in the master program.
>
> You can use this to execute the same adduser/addgroup command in the 
> chroot. While this doesn't guarantee that the different files are 100% in 
> sync, I think it'll get close enough for practical usage.

Ahh.  I had forgotten about that, and you're right, it might be "close
enough", but if it's possible to arrange for unified handling, I'd
really prefer that.

The main problem is that I want a solution that handles all users and
groups, and I want tools like adduser to continue to work correctly.
So far I haven't been able to tell if the behavior of adduser and the
related tools is configurable.  I can see how to authenticate against
other sources via lipam, but not how to re-route modifications.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#327029: Non-functional with read-only /dev

[Wouter Verhelst]

On Thu, Sep 15, 2005 at 07:12:16PM +0200, SZALAY Attila wrote:
> On Thu, 2005-09-15 at 18:30 +0200, Marco d'Itri wrote:
> :
> > Tell the user to learn how UNIX works, and stop bitching.
> > AF_UNIX sockets must be created on a rw file system, and a symlink will
> > not work.
> 
> On FreeBSD it works. So I think it's possible.

If I'm not mistaken, FreeBSD got rid of static /dev ages ago, and has
had a (properly implemented) DevFS-like thing since.

-- 
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: Build-Depend'ing on libasound2-dev just for Linux

[Adeodato Simó]

* Lawrence Williams [Thu, 15 Sep 2005 13:13:14 -0230]:

> I seen an example of a possible choice in xorg-x11 packages that Build-Dep on 
> linux-kernel-headers, but I wasn't sure if I should follow their example:

> linux-kernel-headers (>= 2.6.13+0rc3-1.1) 
> [!hurd-i386 !netbsd-i386 !kfreebsd-i386]

> In Debian, does this prevent it from building on anything other than Linux??

  Of course not, read Policy. What is saying is, "this package needs
  l-k-h to build, _unless_ we're on hurd-i386, netbsd-i386, or
  kfreebsd-i386; in that case, it's ok that l-k-h is not present".

* David Moreno Garza [Thu, 15 Sep 2005 12:10:38 -0500]:

> On Thu, 2005-09-15 at 13:05 -0400, Kevin B. McCarty wrote:
> > Doesn't the type-handling package do what you guys are looking for?

> Yes, it does. And it rocks.

  No, it does not (rock). And, fortunately, it's going to die. If you're
  curious what's going to replace it, check Guillem Jover's patch in
  #291939 (last message in the bug).

  When/if it gets implemented, you'll be able to:

Build-Depends: libasound2-dev [linux-any]
Build-Depends: firebird2-dev  [any-i386]

  Cheers,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
I went to the race track once and bet on a horse that was so good that
it took seven others to beat him!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Build-Depend'ing on libasound2-dev just for Linux

[Wouter Verhelst]

On Thu, Sep 15, 2005 at 12:10:38PM -0500, David Moreno Garza wrote:
> On Thu, 2005-09-15 at 13:05 -0400, Kevin B. McCarty wrote:
> > Doesn't the type-handling package do what you guys are looking for?
> 
> Yes, it does. And it rocks.

Dude, throw away the crackpipe. It's one of the most ugly hacks I've
ever seen. It works, but that's about it.

-- 
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: Build-Depend'ing on libasound2-dev just for Linux

[Aurelien Jarno]

Lawrence Williams a écrit :

Hello,

I am working on a package that Build-Depends on libasound2-dev, but can be 
built on non-Linux OSs. Is there any way to shape the Build-Dep so that 
libasound2-dev is only used if we are building for a Linux system?


I seen an example of a possible choice in xorg-x11 packages that Build-Dep on 
linux-kernel-headers, but I wasn't sure if I should follow their example:


linux-kernel-headers (>= 2.6.13+0rc3-1.1) 
[!hurd-i386 !netbsd-i386 !kfreebsd-i386]


In Debian, does this prevent it from building on anything other than Linux??


Currently this is the solution. In the future, dpkg should support 
build-depencies like [linux-any] or [any-i386]. See the bug #291939. I 
hope this support will be available soon.


Bye,
Aurelien

--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Build-Depend'ing on libasound2-dev just for Linux

[Aurelien Jarno]

Kevin B. McCarty a écrit :

David Nusinow wrote:



On Thu, Sep 15, 2005 at 01:13:14PM -0230, Lawrence Williams wrote:

I seen an example of a possible choice in xorg-x11 packages that Build-Dep on 
linux-kernel-headers, but I wasn't sure if I should follow their example:


linux-kernel-headers (>= 2.6.13+0rc3-1.1) 
[!hurd-i386 !netbsd-i386 !kfreebsd-i386]


In Debian, does this prevent it from building on anything other than Linux??


This was the goal of the line you mention. Unfortunately, I'm not aware of
any sort of simple test like "linux-kernel-headers (>=foo) [linux]" in
dpkg, so I had to explicitly remove non-linux ports from the requirement.



Doesn't the type-handling package do what you guys are looking for?
Looks like it needs to be used somehow in combination with sed and a
debian/control.in file, perhaps in "debian/rules clean"...



type-handling is ugly and should be considered as deprecated. It will be 
replaced in the future by a the support of build-dependencies like 
[linux-any]. I hope the support will appear soon there (the patch to 
support that is in the BTS).


Please also don't switch your package to type handling, and wait for the 
new dpkg, as it violates the new Debian Policy, which says that you 
should not change the build-depencies at build-time.


Bye,
Aurelien

--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Build-Depend'ing on libasound2-dev just for Linux

[David Moreno Garza]

On Thu, 2005-09-15 at 20:05 +0200, Wouter Verhelst wrote:
> Dude, throw away the crackpipe. It's one of the most ugly hacks I've
> ever seen. It works, but that's about it.

I have to say it works well for me and I like it.

--
David Moreno Garza <[EMAIL PROTECTED]>   | http://www.damog.net/
   <[EMAIL PROTECTED]>  | GPG: C671257D
  Depression is a way of life.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#327029: Non-functional with read-only /dev

[Christoph Hellwig]

On Thu, Sep 15, 2005 at 07:44:00PM +0200, Wouter Verhelst wrote:
> On Thu, Sep 15, 2005 at 07:12:16PM +0200, SZALAY Attila wrote:
> > On Thu, 2005-09-15 at 18:30 +0200, Marco d'Itri wrote:
> > :
> > > Tell the user to learn how UNIX works, and stop bitching.
> > > AF_UNIX sockets must be created on a rw file system, and a symlink will
> > > not work.
> > 
> > On FreeBSD it works. So I think it's possible.
> 
> If I'm not mistaken, FreeBSD got rid of static /dev ages ago, and has
> had a (properly implemented) DevFS-like thing since.

It has the same underlying issue as the Linux one.  The FreeBSD
developer don't seem to care, though.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Managing users and groups within multiple devel chroots.

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Pollock <[EMAIL PROTECTED]> writes:

> On Wed, Sep 14, 2005 at 02:12:54PM -0700, Rob Browning wrote:
>> 
>> Is it possible to configure a set of chroots (woody, sarge, whatever)
>> so that all of the chroot passwd/group DBs will stay in sync with each
>> other and with the host DB automaticall, so that, for example, a
>> useradd, usermod, or userdel, will automatically affect all of the DBs
>> simultaneously and safely?
>
> I haven't investigated if adduser supports this properly (and I suspect it
> doesn't), but LDAP authentication across the whole lot would do the trick.

If you are using the chroot for e.g. building with sbuild/buildd, you
don't really want the LDAP stuff in your minimal chroot.

As an alternative suggestion to the original poster, have a look at
the latest schroot:
http://people.debian.org/~rleigh/schroot-0.1.6.tar.bz2

Note this is not an official release, it's a CVS snapshot, since I
only added the necessary support over the last two days.  Here's an
example of it in action, in verbose mode to illustrate:

$ schroot -c sarge -v
run-parts: executing /etc/schroot/setup.d/00check
AUTH_USER=rleigh
AUTH_VERBOSITY=verbose
CHROOT_TYPE=plain
CHROOT_NAME=sarge
CHROOT_DESCRIPTION=Debian sarge (stable)
CHROOT_MOUNT_LOCATION=/srv/chroot/sarge
CHROOT_MOUNT_DEVICE=(null)
CHROOT_LOCATION=/srv/chroot/sarge
run-parts: executing /etc/schroot/setup.d/10mount
run-parts: executing /etc/schroot/setup.d/20network
`/etc/resolv.conf' -> `/srv/chroot/sarge/etc/resolv.conf'
run-parts: executing /etc/schroot/setup.d/30passwd
`/etc/passwd' -> `/srv/chroot/sarge/etc/passwd'
`/etc/shadow' -> `/srv/chroot/sarge/etc/shadow'
`/etc/group' -> `/srv/chroot/sarge/etc/group'
run-parts: executing /etc/schroot/setup.d/50chrootname
Setting chroot name to sarge
[sarge chroot] Running login shell: “/bin/bash”
(sarge)[EMAIL PROTECTED]:~/projects/schroot/schroot$ id
uid=1000(rleigh) gid=1000(rleigh) 
groups=20(dialout),24(cdrom),25(floppy),29(audio),40(src),44(video),46(plugdev),1000(rleigh),1001(sbuild)
(sarge)[EMAIL PROTECTED]:~/projects/schroot/schroot$ logout
run-parts: executing /etc/schroot/setup.d/50chrootname
run-parts: executing /etc/schroot/setup.d/30passwd
run-parts: executing /etc/schroot/setup.d/20network
run-parts: executing /etc/schroot/setup.d/10mount
run-parts: executing /etc/schroot/setup.d/00check
$

Notice that the /etc/schroot/setup.d/30passwd was used to sync the
passwd and related files by copying them into the chroot from the main
system.  While it's a simple copy in this case, you can easily
customise the script to sync the other way on session shutdown, and
make this as complex as you like if you want to take care of the
locking issues properly.

The scripts allow one to customise and configure the chroot quite
easily, so it can (for example) mount block devices on demand, and
(later tonight, once I write it) create, mount and destroy LVM
snapshots on the fly.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFDKcGKVcFcaSW/uEgRArw3AJ9pgH22e3HR9LG7AZvv4NRsBi2umgCg6IKV
COrNTpFmtq1cLJFeQwCQVPM=
=Xj9z
-END PGP SIGNATURE-

Re: Build-Depend'ing on libasound2-dev just for Linux

[Wouter Verhelst]

On Thu, Sep 15, 2005 at 01:17:06PM -0500, David Moreno Garza wrote:
> On Thu, 2005-09-15 at 20:05 +0200, Wouter Verhelst wrote:
> > Dude, throw away the crackpipe. It's one of the most ugly hacks I've
> > ever seen. It works, but that's about it.
> 
> I have to say it works well for me and I like it.

It's incredibly confusing. Really, what's more clear?

Build-Depends: type-handling, fooishbar | hurd-i386

or

Build-Depends: fooishbar [!hurd-i386]

? They both do exactly the same thing, except that the latter clearly
says out loud that you do /not/ need fooishbar on hurd-i386, whereas the
other requires some brain parsing and quite some thought.

-- 
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: architecture alias and disto rebuild

[Guillem Jover]

Hi,

On Tue, Sep 13, 2005 at 11:58:40AM +0200, Adeodato Simó wrote:
> * Bill Allombert [Mon, 12 Sep 2005 17:39:36 +0200]:

> > So I propose a alternate solution:
> 
> > If the distro foobar rebuild packages on i386, they could use
> > i386foobar as architecture name instead of i386, this way every
> > package they rebuild will be clearly marked as such. 
> 
> > Of course, if foobar want to allow regular Debian package to be installed,
> > they can just patch dpkg so that it accept both kind of package.
> 
> > The morale of the story is: since we have now comprehensive plateform
> > handling with CPU-SYSTEM, why not go a little farther and add a BUILDER
> > field with the suitable logic in dpkg so that it allow to install
> > packages from any builder by default ?
> 
>   This would be a gross hack, and I don't see why people who don't
>   bother to use a simple, clean and tested mechanism to mark rebuilds
>   (namely, dch -i) would go and use this other yet-to-be-implemented
>   one.

I agree with Adeodato that this "solution" is a gross hack, but I'd
rather start using something like dpkg-sig over the .deb files, so you
would be able to check from where does that specific .deb file come
from, be it Debian official or a deriviative, etc, w/o having to
modify the sources.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Managing users and groups within multiple devel chroots.

[Rob Browning]

Roger Leigh <[EMAIL PROTECTED]> writes:

> Notice that the /etc/schroot/setup.d/30passwd was used to sync the
> passwd and related files by copying them into the chroot from the main
> system.  While it's a simple copy in this case, you can easily
> customise the script to sync the other way on session shutdown, and
> make this as complex as you like if you want to take care of the
> locking issues properly.
>
> The scripts allow one to customise and configure the chroot quite
> easily, so it can (for example) mount block devices on demand, and
> (later tonight, once I write it) create, mount and destroy LVM
> snapshots on the fly.

Hmm.  That seems like a nice tool, but in this case, I want to keep
the chroots around all the time with home bind mounted so that the
chroots are available to everyone, and I don't want there to be any
period of time after installing a package in one chroot (or on the
host) where the users/groups don't match everywhere.

In truth, if LDAP can be configured to work completely transparently
for *all* users/groups, so that, for example, adduser automatically
uses it when packages are installed, then that would be just fine, but
I was under the perhaps mistaken impression that an LDAP approach
wouldn't be that transparent.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Build-Depend'ing on libasound2-dev just for Linux

[Josselin Mouette]

Le jeudi 15 septembre 2005 à 20:16 +0200, Aurelien Jarno a écrit :
> type-handling is ugly and should be considered as deprecated. It will be 
> replaced in the future by a the support of build-dependencies like 
> [linux-any]. I hope the support will appear soon there (the patch to 
> support that is in the BTS).

If support for it is in etch's dpkg, we will be able to use it *after
the etch release*. The policy has always been to require only dpkg
features from the previous stable release.

> Please also don't switch your package to type handling, and wait for the 
> new dpkg, as it violates the new Debian Policy, which says that you 
> should not change the build-depencies at build-time.

Of course, using type-handling for generating a control file in the
clean target is a crazy idea. The sane way to use it is:
Build-Depends: libasound2-dev | not+linux
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: This is a digitally signed message part

Re: Managing users and groups within multiple devel chroots.

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rob Browning <[EMAIL PROTECTED]> writes:

> Roger Leigh <[EMAIL PROTECTED]> writes:
>
>> Notice that the /etc/schroot/setup.d/30passwd was used to sync the
>> passwd and related files by copying them into the chroot from the main
>> system.  While it's a simple copy in this case, you can easily
>> customise the script to sync the other way on session shutdown, and
>> make this as complex as you like if you want to take care of the
>> locking issues properly.
>>
>> The scripts allow one to customise and configure the chroot quite
>> easily, so it can (for example) mount block devices on demand, and
>> (later tonight, once I write it) create, mount and destroy LVM
>> snapshots on the fly.
>
> Hmm.  That seems like a nice tool, but in this case, I want to keep
> the chroots around all the time with home bind mounted so that the
> chroots are available to everyone, and I don't want there to be any
> period of time after installing a package in one chroot (or on the
> host) where the users/groups don't match everywhere.

I think bind mounts are probably appropriate in this case.  That's
what I was using until yesterday, but then I wanted to make the most
use of my new toy ;-)

You could use schroot with all the mounts set up if you wanted.
That's how I use it, but I do get tired of the huge mount table.



I now have LVM snapshotting working!

$ ./schroot -c sid-snap -v
run-parts: executing /etc/schroot/setup.d/00check
AUTH_USER=rleigh
AUTH_VERBOSITY=verbose
CHROOT_TYPE=lvm-snapshot
CHROOT_NAME=sid-snap
CHROOT_DESCRIPTION=Debian sid snapshot
CHROOT_MOUNT_LOCATION=/mnt
CHROOT_MOUNT_DEVICE=/dev/hda_vg/sid_chroot
CHROOT_DEVICE=/dev/hda_vg/sid_chroot
CHROOT_MOUNT_OPTIONS=-o atime,sync,user_xattr
CHROOT_LVM_SNAPSHOT_OPTIONS=--size 2G
run-parts: executing /etc/schroot/setup.d/05lvm
  Logical volume "sid_chroot-snapshot" created
run-parts: executing /etc/schroot/setup.d/10mount
mount: you didn't specify a filesystem type for /dev/hda_vg/sid_chroot-snapshot
   I will try type ext3
/dev/mapper/hda_vg-sid_chroot--snapshot on /mnt type ext3 (rw,sync,user_xattr)
proc on /mnt/proc type proc (rw)
/dev/pts on /mnt/dev/pts type none (rw,bind)
tmpfs on /mnt/dev/shm type tmpfs (rw)
/home on /mnt/home type none (rw,bind)
/tmp on /mnt/tmp type none (rw,bind)
run-parts: executing /etc/schroot/setup.d/20network
`/etc/resolv.conf' -> `/mnt/etc/resolv.conf'
run-parts: executing /etc/schroot/setup.d/30passwd
`/etc/passwd' -> `/mnt/etc/passwd'
`/etc/shadow' -> `/mnt/etc/shadow'
`/etc/group' -> `/mnt/etc/group'
run-parts: executing /etc/schroot/setup.d/50chrootname
Setting chroot name to sid-snap
[sid-snap chroot] Running login shell: “/bin/bash”
(sid)[EMAIL PROTECTED]:~/projects/schroot/schroot$ logout
run-parts: executing /etc/schroot/setup.d/50chrootname
run-parts: executing /etc/schroot/setup.d/30passwd
run-parts: executing /etc/schroot/setup.d/20network
run-parts: executing /etc/schroot/setup.d/10mount
/tmp umounted
/home umounted
tmpfs umounted
/dev/pts umounted
proc umounted
/dev/mapper/hda_vg-sid_chroot--snapshot umounted
run-parts: executing /etc/schroot/setup.d/05lvm
  Logical volume "sid_chroot-snapshot" successfully removed
run-parts: executing /etc/schroot/setup.d/00check
$

Now the only remaining feature is disconnected session management, and
it's basically complete.


- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFDKeA4VcFcaSW/uEgRAlesAJ0ZcXY4X9oHcPZlraPVDjE4/8WRuACdHWur
uFXPNny7PQdpwBqyy/k/qCA=
=ZXU5
-END PGP SIGNATURE-

Re: Build-Depend'ing on libasound2-dev just for Linux

[Steve Langasek]

On Thu, Sep 15, 2005 at 01:05:31PM -0400, Kevin B. McCarty wrote:
> David Nusinow wrote:

> > On Thu, Sep 15, 2005 at 01:13:14PM -0230, Lawrence Williams wrote:
> >> I seen an example of a possible choice in xorg-x11 packages that Build-Dep 
> >> on 
> >> linux-kernel-headers, but I wasn't sure if I should follow their example:

> >> linux-kernel-headers (>= 2.6.13+0rc3-1.1) 
> >> [!hurd-i386 !netbsd-i386 !kfreebsd-i386]

> >> In Debian, does this prevent it from building on anything other than 
> >> Linux??

> > This was the goal of the line you mention. Unfortunately, I'm not aware of
> > any sort of simple test like "linux-kernel-headers (>=foo) [linux]" in
> > dpkg, so I had to explicitly remove non-linux ports from the requirement.

> Doesn't the type-handling package do what you guys are looking for?
> Looks like it needs to be used somehow in combination with sed and a
> debian/control.in file, perhaps in "debian/rules clean"...

Not in debian/rules clean.  Unsupervised editing of debian/control leads to
RC bugs.

-- 
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

piuparts mass bug filing, summary

[Lars Wirzenius]

Greetings from your friendly neighborhood package torturer.

I ran piuparts on most of etch/main. This resulted in somewhere between
one and two thousand failures. For a long time, I read and tried to
figure out what the cause of each failure was. Eventually I gave up:
there were too many failures that were caused by a dependency, and
investigating each log file took way too much time. I concluded that
there was no point in testing A, if it depends on B, and B is untested.
And if B fails, well, testing of A will also fail, as far as piuparts is
concerned.

Thus I wrote a small tool to run piuparts in this way. This resulted in
much fewer failures, and in fact a manageable number. It means, however,
that about two thirds of the archive isn't getting tested for now.

At the moment, I'm all caught up with etch: all packages that can be
tested with my scheme have been tested. I'll be running my script daily,
and reporting any new failures as bugs (after the proper analysis, of
course). I've filed bugs from all failed logs so far (not too many, only
66, I think: 319601, 325901, 325905, 325907, 325911, 325913, 325921,
325923, 326046, 326050, 326235, 326240, 326248, 326264, 326266, 327076,
327122, 327144, 327146, 327238, 327242, 327521, 327522, 327526, 327530,
327532, 327535, 327537, 327540, 327544, 327615, 328250, 328252, 328256,
328261, 328283, 328284, 328295, 328296, 328297, 328300, 328301, 328310,
328315, 328320, 328321, 328322, 328326, 328327, 328329, 328330, 328331,
328332, 328362, 328366, 328472, 328476, 328478, 328486, 328487, 328490,
328491, 328492, 328493, 328495, 328497; as you can see, some people are
impolite enough to insert their bugs in the middle of my log processing
runs, ruining my pretty consecutive numbers).

Here's some statistics of the current situation:

  already-failed: 71
  already-tested: 4234
  dependency-untested: 10393
  ignoring-important-required-essential: 122
  unknown-dependency: 384

So, about ten thousand packages are waiting for a dependency to be
tested first. Circular dependencies probably prevent most of those (if A
depends on B, and B depends on A, neither will be tested with my current
setup). I don't want to spend much time on breaking the circular chains
to run piuparts: circular dependency chains tend to make the testing
fail anyway at removal time (though not deterministically), so running
piuparts on such can be a waste of time.

Since I'm filing bugs on piuparts failures, and will include relevant
information, I don't think there's much point in setting up a system for
providing log files on the web. If you want them, mail me in private; if
enough people do that, I'll reconsider.

I may expand to contrib and non-free. I don't expect to write more
summaries of this, unless there's unexpected surprises that overwhelm
me.

If you want to test a package, the following command works with piuparts
0.10 [1], on current sid, when run against etch:

sudo piuparts -d etch -al liwc.log liwc

If you add a "-s etch.tar.gz" option, piuparts will save the chroot it
creates with debootstrap, and then you can replace that option with "-b
etch.tar.gz" in future runs, which will be much faster.

I run piuparts against etch instead of sid, because sid is in quite a
turmoil, what with all the transitions going on. (For example, while
testing the above command, I got errors about lib64gcc1.)

I would like to see people use piuparts, or other ways, to test their
packages before they upload them. This should catch all sorts of easy
mistakes, such as failing to remove log files, or removing alternatives
the wrong way.

Remember: a piuparts a day keeps the torturer away from the bts.


[1] I've just uploaded 0.10. It will probably take a day or so to be on
the mirrors. You can get it from here in the mean time:
http://liw.iki.fi/liw/temp/piuparts_0.10-1_all.deb 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Interfaces for dpkg/deb packages

[Christopher Crammond]

Greetings All:

First-time poster, please be gentle.  :)

I was curious as to where I might be able to find out what
non-command-line interfaces into .deb packages are available.  For
instance, is there a C interface that could pull out information such as
Name, Version, Release, etc... ?

I posted the above question on the debian-policy mailing list, and I got
back that .deb is simply an AR file & that writing my own routines
shouldn't be too hard.  While I agree, I figure this is probably already
done/documented somewhere else (say the dpkg project).  Where is the
right place to start asking questions?

For instance, the parse.c file in dpkg-1.10.28/lib looks promising, but
where can I get more information about this?

Thanks,
-- christopher

-- 
Christopher Crammond, Software Engineer
Open Country, Inc.
[EMAIL PROTECTED]
650.591.8080 ext 246


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Build-Depend'ing on libasound2-dev just for Linux

[Aurelien Jarno]

Josselin Mouette a écrit :

Le jeudi 15 septembre 2005 à 20:16 +0200, Aurelien Jarno a écrit :

type-handling is ugly and should be considered as deprecated. It will be 
replaced in the future by a the support of build-dependencies like 
[linux-any]. I hope the support will appear soon there (the patch to 
support that is in the BTS).



If support for it is in etch's dpkg, we will be able to use it *after
the etch release*. The policy has always been to require only dpkg
features from the previous stable release.



I hope that what you are saying does not apply to dpkg-dev, as I was 
actually speaking about that one (dpkg being the source package). That's 
why I think it should be possible to add this functionality to the 
etch's dpkg. The packages using it just have to declare a versioned 
build-dependency on the corresponding dpkg-dev.


But if what you said is really true, that means we have hundred of 
packages fucked in etch, all the ones that use the new dpkg-architecture 
functionalities.


Please also don't switch your package to type handling, and wait for the 
new dpkg, as it violates the new Debian Policy, which says that you 
should not change the build-depencies at build-time.



Of course, using type-handling for generating a control file in the
clean target is a crazy idea. The sane way to use it is:
Build-Depends: libasound2-dev | not+linux


It is maybe a crazy idea, but it is the only one that work. What you 
suggest simply doesn't work, as not+linux is a provided package, and the 
autobuilders are not able to see it. In short a package with such a 
build-dependency will FTBFS on non linux architectures, if built by an 
autobuilder.


Bye,
Aurelien

--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reviving the Debian FAQ

[Javier Fernández-Sanguino Peña]

On Tue, Sep 13, 2005 at 10:39:37PM -0400, Kamaraju Kusumanchi wrote:
> I am taking the liberty to write this even though I am not a DD. Hope 

Well, I said DDs in my mail because i was mailing -devel, but
the document is open to contributions from anyone,  just like anything
in Debian :-)

> one use? I wrote an FAQ on that and is currently hosted at
> 
> http://people.cornell.edu/pages/kk288/debian_choosing_distribution.html
> 
> It would be nice if you can include this in the Debian FAQ. Needless to 
> say, I would be happy to hear comments on the above document.

Could you please license that FAQ with a license compatible (preferably the
same) aas the onee the current FAQ uses? That would allowo me to freely copy
& paste content there (and changeit to sgml,  etc.)

Regards

Javier


signature.asc
Description: Digital signature

Re: Reviving the Debian FAQ

[Javier Fernández-Sanguino Peña]

On Wed, Sep 14, 2005 at 10:48:07AM +0200, Henning Makholm wrote:
> Scripsit Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]>
> 
> > I've fixed some of a), b) or c) with the help of Santiago Vila who is doing
> > the Spanish translation but more peer review is needed here.
> 
> Note that the document at the official URL you quote is probably
> obsolete; it identifies itself as being a February 2003 version.

FWIW, that has been fixed now and the document at www.debian.org
is now in sync with the CVS.

Regards

Javier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reviving the Debian FAQ

[Kamaraju Kusumanchi]

Javier Fernández-Sanguino Peña wrote:


On Tue, Sep 13, 2005 at 10:39:37PM -0400, Kamaraju Kusumanchi wrote:
 

I am taking the liberty to write this even though I am not a DD. Hope 
   



Well, I said DDs in my mail because i was mailing -devel, but
the document is open to contributions from anyone,  just like anything
in Debian :-)
 


Thanks for the encouraging words.


one use? I wrote an FAQ on that and is currently hosted at

http://people.cornell.edu/pages/kk288/debian_choosing_distribution.html

It would be nice if you can include this in the Debian FAQ. Needless to 
say, I would be happy to hear comments on the above document.
   



Could you please license that FAQ with a license compatible (preferably the
same) aas the onee the current FAQ uses? That would allowo me to freely copy
& paste content there (and changeit to sgml,  etc.)
 

How can I do that? Are there some instructions that I need to follow or 
just say in the document that others are free to copy the contents? I am 
sorry but I am very new to licensing and stuff like that.


thanks
raju

--
Kamaraju S Kusumanchi
Graduate Student, MAE
Cornell University
http://www.people.cornell.edu/pages/kk288/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reviving the Debian FAQ

[Kamaraju Kusumanchi]

Henning Makholm wrote:

Scripsit Kamaraju Kusumanchi <[EMAIL PROTECTED]>


I object to the notion that

| Testing is intended for Debian developers. If you are not a Debian
| developer, then install unstable as opposed to testing.

which rather permeates the document.



I read that somewhere in one of the official Debian documentation and 
just copied it there. But I did a google search upon seeing Henning's 
email and all I could find are links to my webpage.


Anyway thanks for pointing that out. I will be changing it over this 
weekend.



In principle testing is just a staging area for the next stable
version. Not many people *need* to run it, but it has been found to be
useful for users who want newer software than stable has yet don't
want to risk the breakage-of-the-day in unstable. There's even said to
be security support these days :-)



Yes. I have not updated the document after the announcement regarding 
testing-security-support was made. Thanks for pointing it out.



I don't think we as a project should endorse documentation that
encourages running unstable. Our official attitude should be that
unstable is only for people who want to be our guinea pigs. People who
run it without wanting to be guinea pigs nevertheless become ones, and
when things break for them, they don't get any sympathy.



The document does not endorse using unstable. It clearly encourages to 
use stable. But if one wants to choose between unstable and testing then 
it says to go with unstable. Even then I warn the user sufficiently 
enough (I think).


raju


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

downgrading optimization for m68k [was: Bug#328453: pbzip2_0.9.4-1(m68k/unstable/zeus): FTBFS on m68k]

[Anibal Monsalve Salazar]

On Thu, Sep 15, 2005 at 07:22:25AM -0500, Stephen R Marenka wrote:
>Package: pbzip2
>Version: 0.9.4-1
>Severity: serious
>Justification: fails to build on release candidate arch.
>Tags: sid
>
>
>pbzip2 fails to build from source on m68k. This is likely due
>to bug #317475 on gcc-4.0. As a workaround, you might try compiling with
>less optimization or gcc-3.3/gcc-3.4.

It would be nice if the optimization downgrade is done _only_ for
m68k as I did it for pbzip2 with the attached patch.

>A full buildd log is available at 
>
>
>Other buildd logs may be available at 
>
>
>--
>Stephen R. Marenka If life's not fun, you're not doing it right!
><[EMAIL PROTECTED]>

Anibal Monsalve Salazar
--
 .''`. Debian GNU/Linux
: :' : Free Operating System
`. `'  http://debian.org/
  `-   http://v7w.com/anibal
debdiff cache/pbzip2/pbzip2_0.9.4-1.dsc cache/pbzip2/pbzip2_0.9.4-2.dsc
diff -u pbzip2-0.9.4/debian/changelog pbzip2-0.9.4/debian/changelog
--- pbzip2-0.9.4/debian/changelog
+++ pbzip2-0.9.4/debian/changelog
@@ -1,3 +1,9 @@
+pbzip2 (0.9.4-2) unstable; urgency=low
+
+  * debian/rules: no optimizacion for m68k, closes: #328453.
+
+ -- Anibal Monsalve Salazar <[EMAIL PROTECTED]>  Thu, 15 Sep 2005 23:38:32 
+1000
+
 pbzip2 (0.9.4-1) unstable; urgency=low
 
   * New upstream release, closes: #325794.
diff -u pbzip2-0.9.4/debian/rules pbzip2-0.9.4/debian/rules
--- pbzip2-0.9.4/debian/rules
+++ pbzip2-0.9.4/debian/rules
@@ -10,7 +10,8 @@
 # Uncomment this to turn on verbose mode.
 export DH_VERBOSE=1
 
-CFLAGS = -Wall -g
+DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
+CFLAGS = -Wall
 
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
@@ -18,6 +19,10 @@
CFLAGS += -O2
 endif
 
+ifneq (,$(findstring m68k,$(DEB_HOST_ARCH)))
+   CFLAGS = -Wall -O0
+endif
+
 configure: configure-stamp
 configure-stamp:
dh_testdir
@@ -31,7 +36,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE)
+   $(MAKE) CFLAGS="$(CFLAGS)"
 
touch build-stamp
 
only in patch2:
unchanged:
--- pbzip2-0.9.4.orig/Makefile
+++ pbzip2-0.9.4/Makefile
@@ -11,16 +11,16 @@
 
 # Standard pbzip2 compile
 pbzip2: pbzip2.cpp
-   $(CC) -O3 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o pbzip2 
pbzip2.cpp -pthread -lpthread -lbz2
+   $(CC) $(CFLAGS) -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o pbzip2 
pbzip2.cpp -pthread -lpthread -lbz2
 
 # Choose this if you want to compile in a static version of the libbz2 library
 pbzip2-static: libbz2.a pbzip2.cpp
-   $(CC) -O3 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o pbzip2 
pbzip2.cpp -pthread -lpthread -I. -L. -lbz2
+   $(CC) $(CFLAGS) -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o pbzip2 
pbzip2.cpp -pthread -lpthread -I. -L. -lbz2
 
 # Compatability mode for 32bit file sizes (less than 2GB) and systems
 # that have compilers that treat int as 64bit natively (ie: modern AIX)
 pbzip2-compat: pbzip2.cpp
-   $(CC) -O3 -o pbzip2 pbzip2.cpp -pthread -lpthread -lbz2
+   $(CC) $(CFLAGS) -o pbzip2 pbzip2.cpp -pthread -lpthread -lbz2
 
 # Install the binary pbzip2 program and man page
 install: pbzip2


signature.asc
Description: Digital signature

Re: downgrading optimization for m68k [was: Bug#328453: pbzip2_0.9.4-1(m68k/unstable/zeus): FTBFS on m68k]

[Stephen R Marenka]

On Fri, Sep 16, 2005 at 10:40:50AM +1000, Anibal Monsalve Salazar wrote:

> >to bug #317475 on gcc-4.0. As a workaround, you might try compiling with
> >less optimization or gcc-3.3/gcc-3.4.

> +ifneq (,$(findstring m68k,$(DEB_HOST_ARCH)))
> + CFLAGS = -Wall -O0
> +endif

For the record, -O2 seems to work fine. The segfaults only seem to 
apply to -O3 and better (at least in my experience).

-- 
Stephen R. Marenka If life's not fun, you're not doing it right!
<[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Build-Depend'ing on libasound2-dev just for Linux

[Lawrence Williams]

Thanks,

Your option sound like exactly what I need. The package using libasound2-dev 
during build only needs it if we are using Linux. The packages could possibly 
be built on a Debian BSD port or whatever in the future.

I apologize if my e-mail wasn't clear. The linux-kernel-headers build-dep is 
probably the sanest solution for my package, as it would cut out a lot of old 
cruft that has been hanging around.

Are those archs (hurd-i386 netbsd-i386 kfreebsd-i386) defined by dpkg or 
another package like type-handling??

Thanks everyone :)

Lawrence

On September 15, 2005 03:26 pm, Adeodato Simó wrote:
> * Lawrence Williams [Thu, 15 Sep 2005 13:13:14 -0230]:
> > I seen an example of a possible choice in xorg-x11 packages that
> > Build-Dep on linux-kernel-headers, but I wasn't sure if I should follow
> > their example:
> >
> > linux-kernel-headers (>= 2.6.13+0rc3-1.1)
> > [!hurd-i386 !netbsd-i386 !kfreebsd-i386]
> >
> > In Debian, does this prevent it from building on anything other than
> > Linux??
>
>   Of course not, read Policy. What is saying is, "this package needs
>   l-k-h to build, _unless_ we're on hurd-i386, netbsd-i386, or
>   kfreebsd-i386; in that case, it's ok that l-k-h is not present".
>
> * David Moreno Garza [Thu, 15 Sep 2005 12:10:38 -0500]:
> > On Thu, 2005-09-15 at 13:05 -0400, Kevin B. McCarty wrote:
> > > Doesn't the type-handling package do what you guys are looking for?
> >
> > Yes, it does. And it rocks.
>
>   No, it does not (rock). And, fortunately, it's going to die. If you're
>   curious what's going to replace it, check Guillem Jover's patch in
>   #291939 (last message in the bug).
>
>   When/if it gets implemented, you'll be able to:
>
> Build-Depends: libasound2-dev [linux-any]
> Build-Depends: firebird2-dev  [any-i386]
>
>   Cheers,
>
> --
> Adeodato Simó
> EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
>
> I went to the race track once and bet on a horse that was so good that
> it took seven others to beat him!

Re: downgrading optimization for m68k [was: Bug#328453: pbzip2_0.9.4-1(m68k/unstable/zeus): FTBFS on m68k]

[Steinar H. Gunderson]

On Fri, Sep 16, 2005 at 10:40:50AM +1000, Anibal Monsalve Salazar wrote:
> It would be nice if the optimization downgrade is done _only_ for
> m68k as I did it for pbzip2 with the attached patch.

Does pbzip2 make sense for m68k at all? I've never seen an SMP m68k...

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reviving the Debian FAQ

[Miles Bader]

Kamaraju Kusumanchi <[EMAIL PROTECTED]> writes:
> The document does not endorse using unstable. It clearly encourages to 
> use stable. But if one wants to choose between unstable and testing then 
> it says to go with unstable.

It's fine to give reasons why unstable might be preferable given such a
choice (though your general tone seems somewhat unfairly biased against
testing -- you make it sound scarier that it really is).  But the sentence
"Testing is intended for Debian developers. If you are not a Debian
developer, then install unstable as opposed to testing" is nonsensical;
just get rid of it.

-miles
-- 
97% of everything is grunge


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: downgrading optimization for m68k [was: Bug#328453: pbzip2_0.9.4-1(m68k/unstable/zeus): FTBFS on m68k]

[tony mancill]

Stephen R Marenka wrote:
> On Fri, Sep 16, 2005 at 10:40:50AM +1000, Anibal Monsalve Salazar wrote:
> 
> 
>>>to bug #317475 on gcc-4.0. As a workaround, you might try compiling with
>>>less optimization or gcc-3.3/gcc-3.4.
> 
> 
>>+ifneq (,$(findstring m68k,$(DEB_HOST_ARCH)))
>>+ CFLAGS = -Wall -O0
>>+endif
> 
> 
> For the record, -O2 seems to work fine. The segfaults only seem to 
> apply to -O3 and better (at least in my experience).

This seems to affect one of the packages I sponsor as well:

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325557

If gcc-4.0 is going to puke on lots of packages that use -O3, doesn't it
make more sense to upload a patched gcc-4.0 for m68k that silently
changes the optimization level back to 2 untile the problem with the
compiler can be fixed rather than upload and recompile a large number of
packages for every architecture?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: downgrading optimization for m68k [was: Bug#328453: pbzip2_0.9.4-1(m68k/unstable/zeus): FTBFS on m68k]

[Steve Langasek]

On Thu, Sep 15, 2005 at 07:15:16PM -0700, tony mancill wrote:
> Stephen R Marenka wrote:
> > On Fri, Sep 16, 2005 at 10:40:50AM +1000, Anibal Monsalve Salazar wrote:

> >>>to bug #317475 on gcc-4.0. As a workaround, you might try compiling with
> >>>less optimization or gcc-3.3/gcc-3.4.

> >>+ifneq (,$(findstring m68k,$(DEB_HOST_ARCH)))
> >>+   CFLAGS = -Wall -O0
> >>+endif

> > For the record, -O2 seems to work fine. The segfaults only seem to 
> > apply to -O3 and better (at least in my experience).

> This seems to affect one of the packages I sponsor as well:

>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325557

> If gcc-4.0 is going to puke on lots of packages that use -O3, doesn't it
> make more sense to upload a patched gcc-4.0 for m68k that silently
> changes the optimization level back to 2 untile the problem with the
> compiler can be fixed rather than upload and recompile a large number of
> packages for every architecture?

If you have a patch that fixes the ICEs on m68k, by all means please forward
it to the BTS.

But a larger question is, why are so many packages being built entirely with
-O3 when policy recommends -O2?  Policy does say it's ok to use other
compiler flags if appropriate, but I'd be surprised if all of these packages
have been benchmarked to confirm that -O3 actually gives measurable
performance benefits.

-- 
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: downgrading optimization for m68k [was: Bug#328453: pbzip2_0.9.4-1(m68k/unstable/zeus): FTBFS on m68k]

[Joe Wreschnig]

On Thu, 2005-09-15 at 19:47 -0700, Steve Langasek wrote:
> On Thu, Sep 15, 2005 at 07:15:16PM -0700, tony mancill wrote:
> > Stephen R Marenka wrote:
> > > On Fri, Sep 16, 2005 at 10:40:50AM +1000, Anibal Monsalve Salazar wrote:
> 
> > >>>to bug #317475 on gcc-4.0. As a workaround, you might try compiling with
> > >>>less optimization or gcc-3.3/gcc-3.4.
> 
> > >>+ifneq (,$(findstring m68k,$(DEB_HOST_ARCH)))
> > >>+ CFLAGS = -Wall -O0
> > >>+endif
> 
> > > For the record, -O2 seems to work fine. The segfaults only seem to 
> > > apply to -O3 and better (at least in my experience).
> 
> > This seems to affect one of the packages I sponsor as well:
> 
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325557
> 
> > If gcc-4.0 is going to puke on lots of packages that use -O3, doesn't it
> > make more sense to upload a patched gcc-4.0 for m68k that silently
> > changes the optimization level back to 2 untile the problem with the
> > compiler can be fixed rather than upload and recompile a large number of
> > packages for every architecture?
> 
> If you have a patch that fixes the ICEs on m68k, by all means please forward
> it to the BTS.
> 
> But a larger question is, why are so many packages being built entirely with
> -O3 when policy recommends -O2?  Policy does say it's ok to use other
> compiler flags if appropriate, but I'd be surprised if all of these packages
> have been benchmarked to confirm that -O3 actually gives measurable
> performance benefits.

I don't know if it gives measurable benefits, but all Python extensions
use -O3 by default (from /usr/lib/python2.3/config/Makefile). Personally
I think it's dumb, but maybe the Python maintainers know better? This is
what triggered the bug in python-flac for me. Overriding distutils isn't
something I've figured out yet (doing so is a task for the weekend).
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: downgrading optimization for m68k [was: Bug#328453: pbzip2_0.9.4-1(m68k/unstable/zeus): FTBFS on m68k]

[Wouter Verhelst]

On Thu, Sep 15, 2005 at 07:15:16PM -0700, tony mancill wrote:
> If gcc-4.0 is going to puke on lots of packages that use -O3, doesn't it
> make more sense to upload a patched gcc-4.0 for m68k that silently
> changes the optimization level back to 2 untile the problem with the
> compiler can be fixed rather than upload and recompile a large number of
> packages for every architecture?

It would make even more sense to spend that time and effort on finding
the bug and the patch for it.

I'm preparing to run a binary search for that bug; just need to put the
final pieces in place (Yes, I've asked upstream, but haven't gotten a
reply as of yet).

-- 
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: Reviving the Debian FAQ

[Kamaraju Kusumanchi]

Miles Bader wrote:

But the sentence
"Testing is intended for Debian developers. If you are not a Debian
developer, then install unstable as opposed to testing" is nonsensical;
just get rid of it.

-miles


This has been corrected now. The corresponding question and answer are 
given below so that the experts can offer their opinion. Your comments 
are most welcome.




10. OK! so far so good. Could you tell me whether to install testing or 
unstable?


This is a rather subjective issue. There is no perfect answer but only a 
"wise guess" could be made while deciding between unstable and testing. 
My personal order of preference is Stable, Unstable and Testing. The 
issue is like this:


Stable is rock solid. It does not break.

Testing breaks less often than Unstable. But when it breaks, it takes a 
long time for things to get rectified. Sometimes this could be days and 
it could be months at times. But in unstable things get rectified within 
couple of days.


But there are times when tracking testing would be beneficial as opposed 
to unstable. One such situation occurred to me due to the gcc transition 
from gcc3 to gcc4. I was trying to install labplot package on a machine 
tracking unstable and it could not be installed in unstable as some of 
its dependencies have undergone gcc4 transition and some have not. But 
the package in testing is installable on a testing machine as the gcc4 
transitioned packages have not "trickled down" to testing.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Interfaces for dpkg/deb packages

[Wouter Verhelst]

On Thu, Sep 15, 2005 at 02:40:06PM -0700, Christopher Crammond wrote:
> Greetings All:
> 
> First-time poster, please be gentle.  :)
> 
> I was curious as to where I might be able to find out what
> non-command-line interfaces into .deb packages are available.  For
> instance, is there a C interface that could pull out information such as
> Name, Version, Release, etc... ?

There is a C++ one that can do such things: libapt-pkg, available with
the apt package.

-- 
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: Bug#323227: new list: debian-planet to distribute planet.debian.org postings; archive to enable searching

[Tollef Fog Heen]

* Alexander Schmehl 

| * Tollef Fog Heen <[EMAIL PROTECTED]> [050914 10:47]:
| > | Maybe, if you don't want your output to be found on the Internet, you
| > | should not make it available on the Internet?
| > I think there is a difference between putting it all in one place with
| > a public archive and having the content available, but not organised
| > into a public archive.
| 
| Don't know how planet works, but if we have somewhere the "get feed from
| $foo" and "get hackergotchi from $bar" configuration, can't we just add
| an "doesn't like to get to the list archive" configuration option, too?

Sure, that's fine with me at least.  I don't care much if it's opt-in
or opt-out, since planet's opt-in in the first place.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Build-Depend'ing on libasound2-dev just for Linux

[Tollef Fog Heen]

* Josselin Mouette 

| If support for it is in etch's dpkg, we will be able to use it *after
| the etch release*. The policy has always been to require only dpkg
| features from the previous stable release.

This is for Build-Depends, which doesn't have that restriction, aiui.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Work-needing packages report for Sep 16, 2005

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 178 (new: 5)
Total number of packages offered up for adoption: 84 (new: 0)
Total number of packages requested help for: 16 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   doc-debian-ko (#327764), orphaned 4 days ago
 Description: Debian FAQ and other documents to Korean

   ipkungfu (#327437), orphaned 6 days ago
 Description: iptables-based Linux firewall

   irmp3 (#327776), orphaned 4 days ago
 Description: A Multimedia Audio Jukebox application

   rhdb-admin (#327775), orphaned 4 days ago
 Description: Graphical tool to administer PostgreSQL/RHDB Databases

   windowlab (#327438), orphaned 6 days ago
 Description: small and simple Amiga-like window manager

173 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 84 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 84 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot-cross ltsp-server dfsbuild aboot

   athcool (#278442), requested 324 days ago
 Description: Enable powersaving mode for Athlon/Duron processors

   debtags (#321654), requested 40 days ago
 Description: Enables support for package tags
 Reverse Depends: libdebtags1-pic debtags-edit

   dselect (#282283), requested 299 days ago
 Description: a user tool to manage Debian packages

   grub (#248397), requested 493 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: webmin-grub grubconf replicator dfsbuild
 grub-splashimages

   gtkpod (#319711), requested 53 days ago
 Description: manage songs and playlists on an Apple iPod

   lsdvd (#316922), requested 73 days ago
 Description: read the contents of a DVD

   mwavem (#313369), requested 94 days ago (non-free)
 Description: Mwave/ACP modem support software

   parted (#262885), requested 409 days ago
 Description: Searching co-maintainer for the parted package.
 Reverse Depends: libparted1.6-dbg libparted1.6-i18n prep-installer
 qtparted partconf parted parted-udeb elilo-installer gparted
 autopartkit partman-base partman-efi partconf-mkfstab
 libparted1.6-dev aboot-installer lvmcfg-utils mindi
 partconf-find-partitions

   pbbuttonsd (#270558), requested 373 days ago
 Description: PBButtons daemon to handle special hotkeys of Apple
 computers
 Reverse Depends: pbbuttonsd-dev gtkpbbuttons gtkpbbuttons-gnome
 powerprefs

   php-pspell (#326173), requested 13 days ago

   qmailadmin (#267756), requested 387 days ago
 Description: web interface for managing qmail with virtual domains
 [contrib]

   sourcenav (#263051), requested 409 days ago
 Description: Source code analysis, editor, browser and build tool:
 Looking for co-maintainer

   sql-ledger (#320442), requested 48 days ago
 Description: A web based double-entry accounting program

   squashfs (#267078), requested 391 days ago
 Description: Tool to create and append to squashfs filesystems

   stlport4.6 (#263052), requested 409 days ago
 Description: STLport C++ class library
 Reverse Depends: libstlport4.6-dev

See http://www.debian.org/devel/wnpp/help_requested for more information.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Interfaces for dpkg/deb packages

[Tollef Fog Heen]

* Christopher Crammond 

| I was curious as to where I might be able to find out what
| non-command-line interfaces into .deb packages are available.  For
| instance, is there a C interface that could pull out information such as
| Name, Version, Release, etc... ?

No, there is no libdpkg yet.  There are rumours that one will be
written in the not-too-distant future, however.  (That is, there is a
libdpkg.a, but it's statically linked into dpkg and not distributed.)

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reviving the Debian FAQ

[Steve Langasek]

On Fri, Sep 16, 2005 at 12:52:01AM -0400, Kamaraju Kusumanchi wrote:
> Miles Bader wrote:
> >But the sentence
> >"Testing is intended for Debian developers. If you are not a Debian
> >developer, then install unstable as opposed to testing" is nonsensical;
> >just get rid of it.

> This has been corrected now. The corresponding question and answer are 
> given below so that the experts can offer their opinion. Your comments 
> are most welcome.

> 10. OK! so far so good. Could you tell me whether to install testing or 
> unstable?

> This is a rather subjective issue. There is no perfect answer but only a 
> "wise guess" could be made while deciding between unstable and testing. 
> My personal order of preference is Stable, Unstable and Testing. The 
> issue is like this:

> Stable is rock solid. It does not break.

> Testing breaks less often than Unstable. But when it breaks, it takes a 
> long time for things to get rectified. Sometimes this could be days and 
> it could be months at times. But in unstable things get rectified within 
> couple of days.

Wouldn't it be a good idea to qualify exactly what *kinds* of breakage
you're talking about here?

At any given time, there are a large number of packages in unstable that
contain RC bugs that keep them (or particular versions of them) out of
testing.  Some of these are reported in the BTS, and some of them aren't.
You can use apt-listbugs to tell you about the first class of these bugs
before you install the package, and the second class of bugs are normally
those that prevent a package's dependencies from being installable *at all*,
but these are both still issues that the user of unstable should be aware of
and willing to accept.

Furthermore, the fact that maintainers upload directly to unstable means
that bugs there *can* be fixed within a couple of days; it does not ensure
that they *are* fixed that quickly.  Feel free to check the BTS for evidence
of packages with longstanding RC bugs in unstable.

> But there are times when tracking testing would be beneficial as opposed 
> to unstable. One such situation occurred to me due to the gcc transition 
> from gcc3 to gcc4. I was trying to install labplot package on a machine 
> tracking unstable and it could not be installed in unstable as some of 
> its dependencies have undergone gcc4 transition and some have not. But 
> the package in testing is installable on a testing machine as the gcc4 
> transitioned packages have not "trickled down" to testing.

Yes, this kind of situation happens to some subset of packages in unstable
*constantly*, unless there is a freeze in progress.

-- 
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