gnat-4.4 is blocking most big transitions atm

[Luk Claes]

Hi

gnat-4.4 FTBFS on mipsel which is blocking gcc-defaults from migrating
to testing which is blocking at least the poppler and gnome related
transitions. xulrunner was reuploaded again and needs to be built
everywhere first before we can reconsider forcing it in.

cmake and xulrunner had some strange build failure when generating the
debs, it would be good if someone can reproduce (or not ;-)) any of this
build failures (gnat-4.4, cmake, xulrunner) while the mipsel buildds are
catching up.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: gnat-4.4 is blocking most big transitions atm

[Andreas Marschke]

On Saturday 28 November 2009 09:46:51 Luk Claes wrote:
> Hi
> 
> gnat-4.4 FTBFS on mipsel which is blocking gcc-defaults from migrating
> to testing which is blocking at least the poppler and gnome related
> transitions. xulrunner was reuploaded again and needs to be built
> everywhere first before we can reconsider forcing it in.
> 
> cmake and xulrunner had some strange build failure when generating the
> debs, it would be good if someone can reproduce (or not ;-)) any of this
> build failures (gnat-4.4, cmake, xulrunner) while the mipsel buildds are
> catching up.
> 
> Cheers
> 
> Luk
> 
It would probably be nice if you could tell what build failures those are in 
case somebody know what they are and how to fix them. 
Would be nice if you could attach them here.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: gnat-4.4 is blocking most big transitions atm

[Luk Claes]

Andreas Marschke wrote:
> On Saturday 28 November 2009 09:46:51 Luk Claes wrote:

>> gnat-4.4 FTBFS on mipsel which is blocking gcc-defaults from migrating
>> to testing which is blocking at least the poppler and gnome related
>> transitions. xulrunner was reuploaded again and needs to be built
>> everywhere first before we can reconsider forcing it in.
>>
>> cmake and xulrunner had some strange build failure when generating the
>> debs, it would be good if someone can reproduce (or not ;-)) any of this
>> build failures (gnat-4.4, cmake, xulrunner) while the mipsel buildds are
>> catching up.

> It would probably be nice if you could tell what build failures those are in 
> case somebody know what they are and how to fix them. 
> Would be nice if you could attach them here.

The build failure for gnat-4.4 is filed as an RC bug (#558146), the ones
of cmake and xulrunner could be temporary (happened on the buildds
without a log unfortunately), trying to reproduce them should shed more
light on them.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: gnat-4.4 is blocking most big transitions atm

[Sune Vuorela]

On 2009-11-28, Luk Claes  wrote:
> Andreas Marschke wrote:
>> On Saturday 28 November 2009 09:46:51 Luk Claes wrote:
>
>>> gnat-4.4 FTBFS on mipsel which is blocking gcc-defaults from migrating
>>> to testing which is blocking at least the poppler and gnome related
>>> transitions. xulrunner was reuploaded again and needs to be built
>>> everywhere first before we can reconsider forcing it in.
>>>
>>> cmake and xulrunner had some strange build failure when generating the
>>> debs, it would be good if someone can reproduce (or not ;-)) any of this
>>> build failures (gnat-4.4, cmake, xulrunner) while the mipsel buildds are
>>> catching up.
>
>> It would probably be nice if you could tell what build failures those are in 
>> case somebody know what they are and how to fix them. 
>> Would be nice if you could attach them here.
>
> The build failure for gnat-4.4 is filed as an RC bug (#558146), the ones
> of cmake and xulrunner could be temporary (happened on the buildds
> without a log unfortunately), trying to reproduce them should shed more
> light on them.

cmake is currently building on my ancient mipsel box.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558394: ITP: twitim -- Twitter client for GNOME

[Youhei SASAKI]

Package: wnpp
Owner: Youhei SASAKI 
Severity: wishlist

* Package name: twitim
  Version : 1.3
  Upstream Author : Yoshizumi Endo 
* URL or Web page : http://code.google.com/p/twitim/
* License : GPL2 or later.
  Description : Twitter client for GNOME

 Twitim is a Twitter client for the GNOME Desktop.  It features XMPP
 connections, custom watchlists, sounds, and pop-up notifications.

---
Youhei SASAKI 
Key fingerprint: 8BF1 ABFE 00D2 526D 6822  2AC6 13E0 381D AEE9 95F4



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: gnat-4.4 is blocking most big transitions atm

[Florian Weimer]

* Luk Claes:

> The build failure for gnat-4.4 is filed as an RC bug (#558146),

This appears to be a bug in tar, perhaps due to a subarchitecture
mismatch:

| /bin/bash: line 1:  1933 Illegal instruction tar -cf - .

Is this really something that can be fixed on the gnat-4.4 side?  Does
"tar -cf - ." work at all in the relevant chroot on mayer?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

libsdl1.2-1.2.14 in Experimental, could use some testers if possible

[Barry deFreese]

Hi folks,

I just uploaded libsdl1.2-1.2.14 to experimental.  I would appreciate any
testing folks could do on it as soo many packages depend on it.

I had to remove a lot of existing patches as they are applied upstream or the
code was re-factored enough as to not warrant them anymore.

I would especially appreciate some feedback from any kfreeBSD folks as I
re-applied the patch for the joystick stuff but had to re-factor it a little.

Thanks!

Barry deFreese


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Linux image packages going to depend on python

[Bastian Blank]

Hi folks

The Linux image packages needs to do some modifications to core
configuration files like fstab in the future to allow newer kernels to
work. To do this and the planned further extension I intend to make all
linux image packages depend on python.

The python package is already part of the standard system via the
priority, so for most people this will not make any difference. However
there was concerns about the size from the embedded people, so I
consider to restrict that to python-minimal.

Bastian

-- 
Live long and prosper.
-- Spock, "Amok Time", stardate 3372.7


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux image packages going to depend on python

[Patrick Matthäi]

Am 28.11.2009 18:52, schrieb Bastian Blank:

Hi folks

The Linux image packages needs to do some modifications to core
configuration files like fstab in the future to allow newer kernels to
work. To do this and the planned further extension I intend to make all
linux image packages depend on python.

The python package is already part of the standard system via the
priority, so for most people this will not make any difference. However
there was concerns about the size from the embedded people, so I
consider to restrict that to python-minimal.
   


Hi,

if the embedded people may have problems with it, would it be an option 
to rewrite the code (whatever it does) in Perl? I may help out there..


Cheers.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558419: ITP: merlin -- alternative database backend for nagios3 with support for redundant and distributed monitoring

[Wolfgang Barth]

Package: wnpp
Severity: wishlist
Owner: Wolfgang Barth 


* Package name: merlin
  Version : 0.6.6
  Upstream Author : Andreas Ericsson 
* URL : http://www.op5.org/community/projects/merlin
* License : GPL
  Programming Lang: C
  Description : alternative database backend for nagios3 with support for 
redundant and distributed monitoring

Merlin is a replacement for the well known database backend ndoutils.
The philosophy of the merlin's layout is one nagios object class = one
database table. It has builtin support for redundant and/or distributed
monitoring.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: gnat-4.4 is blocking most big transitions atm

[Mike Hommey]

On Sat, Nov 28, 2009 at 09:46:51AM +0100, Luk Claes wrote:
> Hi
> 
> gnat-4.4 FTBFS on mipsel which is blocking gcc-defaults from migrating
> to testing which is blocking at least the poppler and gnome related
> transitions. xulrunner was reuploaded again and needs to be built
> everywhere first before we can reconsider forcing it in.

Only mipsel is lagging (my guess is that the package is built, but only
waiting for a buildd admin gpg signature).

> cmake and xulrunner had some strange build failure when generating the
> debs, it would be good if someone can reproduce (or not ;-)) any of this
> build failures (gnat-4.4, cmake, xulrunner) while the mipsel buildds are
> catching up.

xulrunner had a change in 1.9.1.5 that triggered a binutils bug on
mips*. There is a workaround in 1.9.1.5-2 to prevent the FTBFS to happen
on mips*.

Cheers,

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: gnat-4.4 is blocking most big transitions atm

[Luk Claes]

Mike Hommey wrote:
> On Sat, Nov 28, 2009 at 09:46:51AM +0100, Luk Claes wrote:
>> Hi
>>
>> gnat-4.4 FTBFS on mipsel which is blocking gcc-defaults from migrating
>> to testing which is blocking at least the poppler and gnome related
>> transitions. xulrunner was reuploaded again and needs to be built
>> everywhere first before we can reconsider forcing it in.
> 
> Only mipsel is lagging (my guess is that the package is built, but only
> waiting for a buildd admin gpg signature).

It seems to fail reliably on the buildds with the error reported in the
RC bug... it's not waiting for a buildd admin and tar seems to work fine
for other packages.

>> cmake and xulrunner had some strange build failure when generating the
>> debs, it would be good if someone can reproduce (or not ;-)) any of this
>> build failures (gnat-4.4, cmake, xulrunner) while the mipsel buildds are
>> catching up.
> 
> xulrunner had a change in 1.9.1.5 that triggered a binutils bug on
> mips*. There is a workaround in 1.9.1.5-2 to prevent the FTBFS to happen
> on mips*.

We are talking about the most recent versions... the logs seem to be
lost though :-(

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: gnat-4.4 is blocking most big transitions atm

[Florian Lohoff]

On Sat, Nov 28, 2009 at 04:09:06PM +0100, Florian Weimer wrote:
> * Luk Claes:
> 
> > The build failure for gnat-4.4 is filed as an RC bug (#558146),
> 
> This appears to be a bug in tar, perhaps due to a subarchitecture
> mismatch:
> 
> | /bin/bash: line 1:  1933 Illegal instruction tar -cf - .
> 
> Is this really something that can be fixed on the gnat-4.4 side?  Does
> "tar -cf - ." work at all in the relevant chroot on mayer?

LD_LIBRARY_PATH / LD_PRELOAD tricks going on? 

Flo 
-- 
Florian Lohoff f...@rfc822.org
"Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen."
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin 


signature.asc
Description: Digital signature

Re: Linux image packages going to depend on python

[Neil Williams]

On Sat, 28 Nov 2009 18:56:01 +0100
Patrick Matthäi  wrote:

> Am 28.11.2009 18:52, schrieb Bastian Blank:
> > Hi folks
> >
> > The Linux image packages needs to do some modifications to core
> > configuration files like fstab in the future to allow newer kernels to
> > work. To do this and the planned further extension I intend to make all
> > linux image packages depend on python.

This sounds like a maintainer-script issue rather than a direct
requirement of the image itself. Would it be possible for the scripts
to check for python support and continue *without error* if python is
not found? This way, systems that do not have python but *do* have a
setup capable of implementing whatever changes are suitable can still
use a vanilla Debian kernel, e.g. during debugging.

Note 'suitable' - no matter what the kernel does or thinks it needs, it
is not necessarily suitable for the maintainer scripts to fiddle with
system config files on every system.

> > The python package is already part of the standard system via the
> > priority, so for most people this will not make any difference. However
> > there was concerns about the size from the embedded people, so I
> > consider to restrict that to python-minimal.

python-minimal is still a 1.2Mb download and an extra 4Mb unpacked.

> 
> Hi,
> 
> if the embedded people may have problems with it, would it be an option 
> to rewrite the code (whatever it does) in Perl? I may help out there..

This only affects Debian vanilla kernels and embedded systems that use
those as standard are probably OK with python. Systems that omit python
will also omit perl (via changes mediated via Emdebian where perl is not
essential - there is no "essential" in Emdebian) and use customised
kernels.

Where this does have an impact is on experimentation and debugging
using embedded stuff - it makes it one step harder to test with a
vanilla Debian kernel.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpMEjI58HbVX.pgp
Description: PGP signature

Re: gnat-4.4 is blocking most big transitions atm

[Philipp Kern]

On 2009-11-28, Luk Claes  wrote:
>>> gnat-4.4 FTBFS on mipsel which is blocking gcc-defaults from migrating
>>> to testing which is blocking at least the poppler and gnome related
>>> transitions. xulrunner was reuploaded again and needs to be built
>>> everywhere first before we can reconsider forcing it in.
>> Only mipsel is lagging (my guess is that the package is built, but only
>> waiting for a buildd admin gpg signature).
> It seems to fail reliably on the buildds with the error reported in the
> RC bug... it's not waiting for a buildd admin and tar seems to work fine
> for other packages.

Well, the buildd rem crashes all the time.  That's not xulrunner's fault.

Kind regards,
Philipp Kern



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bits from the FTPMaster meeting

[Guillem Jover]

On Tue, 2009-11-24 at 10:25:59 +, Neil Williams wrote:
> On Sat, 21 Nov 2009 03:01:06 +0100
> Guillem Jover  wrote:
> > Well, IMO any program implementing .deb extraction w/o using something
> > like --fsys-tarfile, --extract or --control from dpkg-deb (until we
> > have the upcoming libdpkg...), should be prepared to handle the format
> > described in deb(5), and deserves a bug otherwise. The fact that the
> > Debian archive only accepts a subset of the valid .deb format, or that
> > we might not want to have bzip2 compressed packages in the base system
> > is a matter of policy in Debian, and does not mean others might want to
> > do otherwise.
> 
> Fixed in multistrap 2.0.4, just arriving in sid.

Checking the svn repo I still see at least one problematic piece of
code. In “emrootfslib (unpack_debootstrap)” it's using ar + tar, and
using a temporary file when it could just use a pipe, but it could have
just used ‘dpkg-deb -X’ instead of ‘dpkg -x’ to get the list of files.
Then you get any format supported by dpkg-deb for free, in addition to
being a bit more optimal.

> I'll update deb-gview for its next release, although I'll need some
> real packages using data.tar.bz2 before I can test it.

You could repack an existing .deb using dpkg-deb and the -Z option.
But please, make sure to read deb(5) and support any valid deb package.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bits from the FTPMaster meeting

[Neil Williams]

On Sat, 28 Nov 2009 22:25:31 +0100
Guillem Jover  wrote:

> On Tue, 2009-11-24 at 10:25:59 +, Neil Williams wrote:
> > On Sat, 21 Nov 2009 03:01:06 +0100
> > Guillem Jover  wrote:
> > > Well, IMO any program implementing .deb extraction w/o using something
> > > like --fsys-tarfile, --extract or --control from dpkg-deb (until we
> > > have the upcoming libdpkg...), should be prepared to handle the format
> > > described in deb(5), and deserves a bug otherwise. The fact that the
> > > Debian archive only accepts a subset of the valid .deb format, or that
> > > we might not want to have bzip2 compressed packages in the base system
> > > is a matter of policy in Debian, and does not mean others might want to
> > > do otherwise.
> > 
> > Fixed in multistrap 2.0.4, just arriving in sid.
> 
> Checking the svn repo I still see at least one problematic piece of
> code. In “emrootfslib (unpack_debootstrap)”

I did say that multistrap was fixed - emrootfslib is part of emsandbox
which is meant to serve Emdebian Crush, not multistrap. Currently, all
development on Emdebian Crush is stalled - including the root
filesystem installation methods. The current code is there to support
Lenny and has no support for Squeeze or Sid because the only packages
available for Crush are for ARM, not armel or any other Debian
architecture. There is no ARM support in Squeeze, therefore changes made
in any package after the release of Lenny have no effect on any part of
the Emdebian Crush packages or support system, including emrootfslib.
Crush development will only restart when we have a new build system
based on multiarch that can cope with more than one architecture.

http://lists.debian.org/debian-embedded/2009/08/msg5.html

It's the old "single-developer-now-unavailable" problem.

As I said, the issue is fixed in multistrap - which is the only place
in that SVN repo where the fix actually matters. It is not currently
possible to use emrootfslib with any package more recent than the
version released in Lenny - no other packages exist for it to use and
new packages cannot be built for it to use.

Once Crush development does restart, the systems used to generate and
install root filesystems may well migrate to multistrap anyway -
basing the multistrap on the modified packages in the Emdebian Crush
repository.

emrootfslib is a specialised component of a specialised tool for a
specialised set of packages with a specialised purpose. General changes
in dpkg have negligible impact on it.

multistrap, however, is a much more general purpose script intended to
work with Emdebian Grip. As Grip is binary-compatible with standard
Debian, multistrap works with standard Debian too - hence the fix
uploaded to Sid.

Crush 1.0 was a learning curve, a proof of concept, with only a few
hundred packages on a single architecture. Lots of parts of the build
system for Crush 1.0 will not survive into Crush 3.0; as the systems
mature, the need for such specialised tools becomes less relevant. Only
then can Crush be usable enough to support more packages and more
architectures.

A lot of that testing and development is going on now within Emdebian
Grip. Once multiarch allows us to solve the fundamental breakage in the
build system used for Crush 1.0, we can start to look to the future.

> > I'll update deb-gview for its next release, although I'll need some
> > real packages using data.tar.bz2 before I can test it.
> 
> You could repack an existing .deb using dpkg-deb and the -Z option.

deb-gview doesn't repack anything. It inspects the contents of the .deb
directly using libarchive. deb-gview does not use dpkg.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpw8hqcc1B1d.pgp
Description: PGP signature

A good example of Debian's excellent attitude to bug reports (was: Bug#533830: uses most of CPU (solved?))

[Ben Finney]

[context: a bug, that has been hard to track down for a while, sees a
flurry of activity and improvement in multiple installations; and then
the developer sees fit to apologise. I disagree; praise is appropriate.]

On 28-Nov-2009, Mark Hindley wrote:
> Sorry to have taken so long to get to the bottom of this.

Surely you jest. This has been a prime example of a *good* response to
a bug report, and I'm saying so here on ‘debian-devel’ to highlight a
major reason why I preferentially choose Debian for systems under my
control.

The delay was, if I understand correctly, largely for want of a decent
set of repeatable test cases. Once you had access to those (through
users willing to repeat them on your behalf), your speed of
improvements to the application has been exemplary.

Rapid brainstorming and feedback of possible fixes, for a bug that the
developer can't even replicate, involving exchanges across the world
by email directly between the users and the developer. It doesn't even
*compare* to projects without a free software code base and an open
email-based bug tracker, so you have an advantage in Debian there.

But even those are insufficient. This has been possible because of
a package maintainer who sincerely cares less about programmer ego
than about finding a proper resolution to the bug for the sake of
all its users.

So, I repudiate your “sorry”, and retort with “thank you” instead.
More like this, please!

-- 
 \  “One bad programmer can easily create two new jobs a year. |
  `\  Hiring more bad programmers will just increase our perceived |
_o__) need for them.” —David Lorge Parnas, 1999-03 |
Ben Finney 


signature.asc
Description: Digital signature

Re: Linux image packages going to depend on python

[Manoj Srivastava]

On Sat, Nov 28 2009, Neil Williams wrote:

> On Sat, 28 Nov 2009 18:56:01 +0100
> Patrick Matthäi  wrote:
>
>> Am 28.11.2009 18:52, schrieb Bastian Blank:
>> > Hi folks
>> >
>> > The Linux image packages needs to do some modifications to core
>> > configuration files like fstab in the future to allow newer kernels to
>> > work. To do this and the planned further extension I intend to make all
>> > linux image packages depend on python.
>
> This sounds like a maintainer-script issue rather than a direct
> requirement of the image itself. Would it be possible for the scripts
> to check for python support and continue *without error* if python is
> not found? This way, systems that do not have python but *do* have a
> setup capable of implementing whatever changes are suitable can still
> use a vanilla Debian kernel, e.g. during debugging.
>
> Note 'suitable' - no matter what the kernel does or thinks it needs, it
> is not necessarily suitable for the maintainer scripts to fiddle with
> system config files on every system.

Indeed. Editing configuration files that belong to other
 packages is a policy violation; and even editing configuration files
 blonging to he package itself must preserve all user changes.

It seems to be that a better approach is to inform the user, and
 let the admin make the changes needed.

manoj
-- 
Any clod can have the facts, but having opinions is an art. Charles
McCabe
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux image packages going to depend on python

[Ben Hutchings]

On Sat, 2009-11-28 at 16:43 -0600, Manoj Srivastava wrote:
> On Sat, Nov 28 2009, Neil Williams wrote:
> 
> > On Sat, 28 Nov 2009 18:56:01 +0100
> > Patrick Matthäi  wrote:
> >
> >> Am 28.11.2009 18:52, schrieb Bastian Blank:
> >> > Hi folks
> >> >
> >> > The Linux image packages needs to do some modifications to core
> >> > configuration files like fstab in the future to allow newer kernels to
> >> > work. To do this and the planned further extension I intend to make all
> >> > linux image packages depend on python.
> >
> > This sounds like a maintainer-script issue rather than a direct
> > requirement of the image itself. Would it be possible for the scripts
> > to check for python support and continue *without error* if python is
> > not found? This way, systems that do not have python but *do* have a
> > setup capable of implementing whatever changes are suitable can still
> > use a vanilla Debian kernel, e.g. during debugging.
> >
> > Note 'suitable' - no matter what the kernel does or thinks it needs, it
> > is not necessarily suitable for the maintainer scripts to fiddle with
> > system config files on every system.
> 
> Indeed. Editing configuration files that belong to other
>  packages is a policy violation; and even editing configuration files
>  blonging to he package itself must preserve all user changes.
> 
> It seems to be that a better approach is to inform the user, and
>  let the admin make the changes needed.

The specific requirement here is to prepare for a transition from old
PATA ("IDE") drivers to libata-based drivers.  libata presents ATA/ATAPI
drives as SCSI devices, so hard drive partitions will change
from /dev/hdX to /dev/sdX.

In preparation for this partition, /etc/fstab and the kernel parameters
in boot-loader configs should be changed to specify partitions by UUID
or label name so that they work with both old and new kernel versions.
There will be a debconf question as to whether this should be done
automatically, but it is not appropriate to expect all users to make
this change manually.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.


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

Re: Bits from the FTPMaster meeting

[Guillem Jover]

On Sat, 2009-11-28 at 22:31:29 +, Neil Williams wrote:
> On Sat, 28 Nov 2009 22:25:31 +0100 Guillem Jover wrote:
> > On Tue, 2009-11-24 at 10:25:59 +, Neil Williams wrote:
> > > I'll update deb-gview for its next release, although I'll need some
> > > real packages using data.tar.bz2 before I can test it.
> > 
> > You could repack an existing .deb using dpkg-deb and the -Z option.
> 
> deb-gview doesn't repack anything. It inspects the contents of the .deb
> directly using libarchive. deb-gview does not use dpkg.

You were asking for a package compressed with something els than gzip
for testing purposes, I was offering an easy way to get you one from
any existing package by repacking using dpkg-deb.

Still that will not give you testing coverage for all valid .debs,
like having members starting with _ inbetween the mandatory ones,
additional members afterwards, etc.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bits from the ftp-team

[Julien Cristau]

On Tue, Nov  3, 2009 at 14:14:16 +, Mark Hymers wrote:

> First of all, the following parts of the archive are temporarily
> non-functional:
> 
>  * {o-,}p-u-new to {o-,}p-u migration (sometime this week)
> 
What's up with that?

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bits from the FTPMaster meeting

[Neil Williams]

On Sun, 29 Nov 2009 00:13:14 +0100
Guillem Jover  wrote:

> On Sat, 2009-11-28 at 22:31:29 +, Neil Williams wrote:
> > On Sat, 28 Nov 2009 22:25:31 +0100 Guillem Jover wrote:
> > > On Tue, 2009-11-24 at 10:25:59 +, Neil Williams wrote:
> > > > I'll update deb-gview for its next release, although I'll need some
> > > > real packages using data.tar.bz2 before I can test it.
> > > 
> > > You could repack an existing .deb using dpkg-deb and the -Z option.
> > 
> > deb-gview doesn't repack anything. It inspects the contents of the .deb
> > directly using libarchive. deb-gview does not use dpkg.
> 
> You were asking for a package compressed with something els than gzip
> for testing purposes, I was offering an easy way to get you one from
> any existing package by repacking using dpkg-deb.

Ah, sorry - misunderstood. Thanks.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpBdjNYDTAcQ.pgp
Description: PGP signature

Re: Linux image packages going to depend on python

[Manoj Srivastava]

On Sat, Nov 28 2009, Ben Hutchings wrote:

> On Sat, 2009-11-28 at 16:43 -0600, Manoj Srivastava wrote:
>> On Sat, Nov 28 2009, Neil Williams wrote:
>> 
>> > On Sat, 28 Nov 2009 18:56:01 +0100
>> > Patrick Matthäi  wrote:
>> >
>> >> Am 28.11.2009 18:52, schrieb Bastian Blank:
>> >> > Hi folks
>> >> >
>> >> > The Linux image packages needs to do some modifications to core
>> >> > configuration files like fstab in the future to allow newer kernels to
>> >> > work. To do this and the planned further extension I intend to make all
>> >> > linux image packages depend on python.
>> >
>> > This sounds like a maintainer-script issue rather than a direct
>> > requirement of the image itself. Would it be possible for the scripts
>> > to check for python support and continue *without error* if python is
>> > not found? This way, systems that do not have python but *do* have a
>> > setup capable of implementing whatever changes are suitable can still
>> > use a vanilla Debian kernel, e.g. during debugging.
>> >
>> > Note 'suitable' - no matter what the kernel does or thinks it needs, it
>> > is not necessarily suitable for the maintainer scripts to fiddle with
>> > system config files on every system.
>> 
>> Indeed. Editing configuration files that belong to other
>>  packages is a policy violation; and even editing configuration files
>>  blonging to he package itself must preserve all user changes.
>> 
>> It seems to be that a better approach is to inform the user, and
>>  let the admin make the changes needed.
>
> The specific requirement here is to prepare for a transition from old
> PATA ("IDE") drivers to libata-based drivers.  libata presents ATA/ATAPI
> drives as SCSI devices, so hard drive partitions will change
> from /dev/hdX to /dev/sdX.

This is fine. /etc/fstab is used by mountall.sh, mount, and
 swapon explicitly -- so arguably mount is the related package that
 "owns" the configuration file. Here is what policy has to say about it:

,[ 10.7.4. Sharing configuration files ]
|  If two or more packages use the same configuration file and it is
|  reasonable for both to be installed at the same time, one of these
|  packages must be defined as _owner_ of the configuration file, i.e.,
|  it will be the package which handles that file as a configuration
|  file.  Other packages that use the configuration file must depend on
|  the owning package if they require the configuration file to operate.
|  If the other package will use the configuration file if present, but
|  is capable of operating without it, no dependency need be declared.
| 
|  If it is desirable for two or more related packages to share a
|  configuration file _and_ for all of the related packages to be able to
|  modify that configuration file, then the following should be done:
|  1.   One of the related packages (the "owning" package) will manage
|   the configuration file with maintainer scripts as described in
|   the previous section.
|  2.   The owning package should also provide a program that the other
|   packages may use to modify the configuration file.
|  3.   The related packages must use the provided program to make any
|   desired modifications to the configuration file.  They should
|   either depend on the core package to guarantee that the
|   configuration modifier program is available or accept gracefully
|   that they cannot modify the configuration file if it is not.
|   (This is in addition to the fact that the configuration file may
|   not even be present in the latter scenario.)
| 
|  Sometimes it's appropriate to create a new package which provides the
|  basic infrastructure for the other packages and which manages the
|  shared configuration files.  (The `sgml-base' package is a good
|  example.)
`


> In preparation for this partition, /etc/fstab and the kernel parameters
> in boot-loader configs should be changed to specify partitions by UUID
> or label name so that they work with both old and new kernel versions.
> There will be a debconf question as to whether this should be done
> automatically, but it is not appropriate to expect all users to make
> this change manually.

While it  is not appropriate for the user to do it manually,
 there is still a policy compliant way to do what is needed:
  A) Have mount provide the use-uuids-in-fstab script, and have ask the
 user if one may call it. If so, call it in the postinst
  B) Detect if the fstab changes have happened, and if not, take
 appropriate action.

Also, as a project, we still support user created kernel images;
 and it is  being nice to such users that the tools to automate the
 fstab conversion for newer kernels; and not leave them out in the
 cold. 

Once the mount package provides the modify fstab script, users
 can update their fstab ahead of t

Re: Linux image packages going to depend on python

[Steve Langasek]

On Sat, Nov 28, 2009 at 06:52:42PM +0100, Bastian Blank wrote:
> Hi folks

> The Linux image packages needs to do some modifications to core
> configuration files like fstab in the future to allow newer kernels to
> work. To do this and the planned further extension I intend to make all
> linux image packages depend on python.

I agree with Manoj that it's better to have this done centrally in the
maintainer scripts of a single package, on which the linux-image packages
can depend.  Among other things, this prevents local modifications from
being lost if a user adds non-UUID-based fstab entries after the UUID
conversion was first done.

> The python package is already part of the standard system via the
> priority, so for most people this will not make any difference. However
> there was concerns about the size from the embedded people, so I
> consider to restrict that to python-minimal.

python-minimal is an artifact inherited from the Ubuntu packaging, where the
package is Essential: yes and python is Priority: important.  Nothing should
depend on python-minimal except for python itself, in Debian *or* in Ubuntu;
to do so is contrary to the express wishes of python upstream.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Depends/Recommends?: Linux image packages going to depend on python

[Osamu Aoki]

On Sat, Nov 28, 2009 at 11:00:21PM +, Ben Hutchings wrote:
> On Sat, 2009-11-28 at 16:43 -0600, Manoj Srivastava wrote:
> > On Sat, Nov 28 2009, Neil Williams wrote:
> > 
> > > On Sat, 28 Nov 2009 18:56:01 +0100
> > > Patrick Matthäi  wrote:
> > >
> > >> Am 28.11.2009 18:52, schrieb Bastian Blank:
> > >> > Hi folks
> > >> >
> > >> > The Linux image packages needs to do some modifications to core
> > >> > configuration files like fstab in the future to allow newer kernels to
> > >> > work. To do this and the planned further extension I intend to make all
> > >> > linux image packages depend on python.

Depends: or Recommends:?

... 
> > Indeed. Editing configuration files that belong to other
> >  packages is a policy violation; and even editing configuration files
> >  blonging to he package itself must preserve all user changes.
> > 
> > It seems to be that a better approach is to inform the user, and
> >  let the admin make the changes needed.
> 
> The specific requirement here is to prepare for a transition from old
> PATA ("IDE") drivers to libata-based drivers.  libata presents ATA/ATAPI
> drives as SCSI devices, so hard drive partitions will change
> from /dev/hdX to /dev/sdX.
> 
> In preparation for this partition, /etc/fstab and the kernel parameters
> in boot-loader configs should be changed to specify partitions by UUID
> or label name so that they work with both old and new kernel versions.
> There will be a debconf question as to whether this should be done
> automatically, but it is not appropriate to expect all users to make
> this change manually.

Why not keep the main maintainer script to be /bin/sh and use python
within optional compoent.  I mean:

1. Recommends: python-minimal
2. The main maintainer script is written in /bin/sh which checks existance 
   of python-minimal and its sanity.
 2.1 If python-minimal exists and in good shape, pose debconf question
 as described above using maintainable python code.
 2.2 If python-minimal does not exist or not in good shape, skip debconf 
 question assuming "No" and go to debconf information message just 
 via /bin/sh.

This way, the maintainer script works on any system.  Desktop uses will
have easier time and anyone botheres to remove python from system is not
affected.

In my observation, all maintainer scripts of basic packages should
follow this kind of approach when ever it use scripts except /bin/sh or
/bin/bash.  I remember that the maintainer script of kernel used to use
script for initramfs creation written in perl.  An broken perl
transition caused some problem under such situation.  

Osamu

PS: I guess this can be done just with awk/sed but I guess it is more
difficult to read than perl or python.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org