Re: -dbg packages; are they actually useful?

[Tzafrir Cohen]

On Wed, Mar 04, 2009 at 10:19:22PM -0800, Steve Langasek wrote:
> On Wed, Mar 04, 2009 at 10:03:28AM +, Tzafrir Cohen wrote:
> > On Tue, Mar 03, 2009 at 09:17:17PM -0800, Steve Langasek wrote:
> 
> > > Remaining concerns:
> 
> > > - each of these dbg packages requires manual modification to the source
> > >   package (incl. adding the package to debian/control)
> > > - each has to go through the NEW queue
> > > - each takes up space afterwards in the Packages file
> 
> > > Much better if these can be generated centrally as part of the builds.
> 
> > What about backports?
> 
> > What about locally-built packages?
> 
> What about them?  Are you suggesting that we should instead continue to
> manually add -dbg packages to all source packages for the benefit of people
> who aren't even using our binary packages?

Maybe. I'm only stating the problems I encounter.

> 
> > ("Sorry, we can't help you debug your probelem until you ditch that
> > package you built and build from source like Real Men should").
> 
> Or they could:
> 
>  - build their packages with DEB_BUILD_OPTIONS=nostrip, the standard
>mechanism for building packages containing unstripped binaries, or
>  - use the pkgbinarymangler script, available as a package from Ubuntu, to
>autogenerate debug packages from any debhelper-using package as part of
>the build

It means I have to rebuild the package. And hope I have a similar enough 
build environment to the one originally used.

With rpm there's no such problem, as a separate debug package is
created automatically. I just have to keep it somewhere.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


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

Re: Pristine source from upstream VCS repository

[Reinhard Tartler]

Russ Allbery  writes:

>> Am I right in thinking that the ‘get-orig-source’ target should ignore
>> the version strings in ‘debian/changelog’, and should instead get
>> whatever version is the latest available from upstream?
>
> I think the way that you're using it is more useful (and possible) than
> doing what an exact reading of the current text would indicate, and I do
> the same thing that you're doing.

FYI, from the ffmpeg-debian (and soon mplayer) package, we (or at least
I) use the following approach:

  SVNDATE=`date +%Y%m%d`
  debian/rules get-orig-source SVN_VERSION=${SVNDATE}

Debian rules detects the SVN_VERSION like this:

DEB_SOURCE := $(shell dpkg-parsechangelog | sed -n 's/^Source: //p')
DEB_VERSION := $(shell dpkg-parsechangelog | sed -n 's/^Version: //p')
UPSTREAM_VERSION := $(shell echo $(DEB_VERSION) | sed -r 's/[^:]+://; 
s/-[^-]+$$//')
SVN_VERSION := $(shell echo $(UPSTREAM_VERSION) | sed -nr 
's/^[0-9.:-]+\.svn([0-9]+)$$/\1/p')

[...]

get-orig-source:
dh_testdir
chmod +x debian/strip.sh
sh debian/get-orig-source.sh -d$(SVN_VERSION)

The proposed approach features:

 - a seperate shell script for the actual work
 - debian/rules figuring out the current version from debian/changelog
 - user is able to override the exact upstream version

(obvious) issues:

 - in this context, only midnight snapshots are possible
 - if upstream changes the VCS location or its layout, this mechanism
   will break
 - regex determining SVN_VERSION is very dependent on the choosen
   versioning scheme. mplayer and ffmpeg need to use a different regex!

I believe this approach matches both the letter and the spirit of debian
policy notes about that target.

Suggestions how to simplify this (espc. the get-orig-source.sh script,
see the branches on git.debian.org) are appreciated.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: Bug#517945: ITP: libxray-absorption-perl -- x-ray absorption data for the elements

[Carlo Segre]

Hi Andreas:

On Tue, 3 Mar 2009, Andreas Tille wrote:


On Mon, 2 Mar 2009, Carlo Segre wrote:


Package: wnpp
Severity: wishlist
Owner: Carlo Segre 


* Package name: libxray-absorption-perl
 Version : 2.0.1
 Upstream Author : Bruce Ravel 
* URL : http://cars9.uchicago.edu/svn/libperlxray
* License : Artistic
 Programming Lang: Perl
 Description : x-ray absorption data for the elements

This module supports access to X-ray absorption data.  It is designed
to be a transparent interface to absorption data from a variety of
sources.  Currently, the only sources of data are the 1969 McMaster
tables, the 1999 Elam tables, the 1993 Henke tables, and the 1995
Chantler tables.  The Brennan-Cowen implementation of the
Cromer-Liberman tables is available as a drop-on-top addition to this
package.  More resources can be added easily.


Hi Carlo,

can you imagine applications where this "variety of sources" includes
x-ray data from medical care?  I'm wondering whether this package might
be an interesting target for the Debian Med physics task.  Or are the
ITPed packages rather targeting at particle physics and do not really
targeting at medical care?

IMHO it would not harm if you would add the answer to this question as
a separate paragraph to the description.



Hmm, the answer is that these modules allow the calculation of how matter 
absorbs xrays of different energies.  The McMaster tables are the basic 
reference and have been extended by the Elam and Henke tables to provide 
additional quantities (fluorescence and total cross-section).  The 
calculations can beused byt many different kinds of researchers, basically 
anyone who is interested in the interaction of x-rays with matter.  I am 
sure that this includes medical physicists but I do not know if there are 
other tabulations of data specifically made for medical physics.


The calculations are probably not terribly useful to particle physicists 
though, more to condensed matter and materials physicists and chemists. 
These modules are necessary components for the horae suite of programs for 
analysis of x-ray absorption spectroscopy and they used to be hidden in 
the horae package but have been split out now.


i will certainly consider improving the long description in future 
releases.  For now, i prefer to leave them in the incoming queue as they 
are.


carlo

--
Carlo U. Segre -- Professor of Physics
Associate Dean for Special Projects, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://www.iit.edu/~segre   se...@debian.org


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

Re: -dbg packages; are they actually useful?

[Paul Wise]

On Thu, Mar 5, 2009 at 5:23 PM, Tzafrir Cohen  wrote:

> With rpm there's no such problem, as a separate debug package is
> created automatically. I just have to keep it somewhere.

That is exactly the plan for debug.debian.net.

IMO it needs to sidestep dh_strip though, since debhelper isn't
mandatory and isn't used by all packages.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: -dbg packages; are they actually useful?

[Aurelien Jarno]

On Tue, Mar 03, 2009 at 10:25:06PM -0500, Theodore Tso wrote:
> On Tue, Mar 03, 2009 at 10:12:22PM +, Steve McIntyre wrote:
> > 
> > I'm looking at my local mirror (slowly) update at the moment, and I've
> > got to wondering: are the large -dbg packages actually really useful
> > to anybody? I can't imagine that more than a handful of users ever
> > install (to pick an example) the amarok-dbg packages, but we have
> > multiple copies of a 70MB-plus .deb taking up mirror space and
> > bandwidth. I can understand this for library packages, maybe, but for
> > applications?
> 
> There are people working on ways of compressing the debuginfo
> information, and I've been told they might have results within a
> couple of months.  Part of the problem is that depending on how the
> package is built, the -dbg packages can be huge, so it makes the
> cost/benefit ratio somewhat painful.
> 

Compressing -dbg files using dh_builddeb -Zlzma, which uses lzma
compression instead of gzip, gives an average gain of 1.88 in size for
the current -dbg packages we have in sid.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Re: -dbg packages; are they actually useful?

[Russ Allbery]

Aurelien Jarno  writes:

> Compressing -dbg files using dh_builddeb -Zlzma, which uses lzma
> compression instead of gzip, gives an average gain of 1.88 in size for
> the current -dbg packages we have in sid.

Compressing with bzip2 is already supported by DAK and might help almost
as much.  (I realize that LZMA is a better compression scheme overall, but
it's apparently also deprecated, replaced with XZ, and using it in the
archive will require further DAK changes or work to switch to XZ instead.)

-- 
Russ Allbery (r...@debian.org)   


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

Re: Bug#419209: lvm2: Hangs during snapshot creation

[Bastian Blank]

severity 419209 important
thanks

On Wed, Mar 04, 2009 at 10:44:28AM +0100, Klaus Ethgen wrote:
> first of all, I raised the severity of the bug to critical as it makes
> the whole system break.

lvm2 manages blockdevices via the device-mapper framework, so it manages
the system. It is the purpose of this tool and it will not hold you from
doing stupid things.

And for now I consider taking snapshots of / or /var as stupid, because
it is impossible to recover if something goes wrong. And without a
working filesystem on this locations, the system will just block. It may
work, but it also may break horrible as the kernel interface does not
allow to do this change atomic.

> Also I add debian-devel to Cc as the bug is very
> problematic and I wonder how lvm2 was able to get into lenny with that
> big problem!

We have many software who only works for most but not for all people.

> Also I am willing to help solving the bug. My next step will be to
> import the whole version history to git and try to besect the problem.

Why do you think this would be a problem of the userspace part?

> So this bug is a complete show stopper for lenny

If you want to help you can provide the following information when it
goes wrong:
- "uname -a"
- "dmesg"
- "dmsetup table"
- "cat /proc/mounts"
- debug log of the "lvcreate -s" call, using -
- your snapshot creation script

> Am Sa den 14. Apr 2007 um 12:53 schrieb Jean-Luc Coulon (f5ibh):
> > New lvm2 version (2.02.24) hangs during snapshot creation.
> > The lvmvreate process is not killeable at this point and the system need to 
> > be
> > reboted.
> That is the correct description.

There was a bug in older kernels which blocked on devmapper table
reload, however I've only seen this with the mirror target during a
pvmove call.

>  But more over the system will be
> unbootable at all! I have to run /etc/init.d/reboot stop by hand to hard
> reboot the system. A normal shutdown will end in a hanging system with
> no remote access at all. The only solution at that point is to
> powercycle the machine which is very problematic with remote system.

This is the normal behaviour if you lock out either a filesystem or have
some parts of the kernel disfunctional after oopses.

> Am Fr den  2. Nov 2007 um 16:21 schrieb Stefan Pfetzing:
> > did you try to snapshot your /var? Because to me it seemms like the  
> > current lvm2 configurations tries to use /var/lock/lvm for its locking 
> > files, and this leads to a deadlock.
> This is not really a problem as it is irrelevant if that file is locked
> or not in the sapshoot.

It is. However I'm currently not sure if it ever tries to write/read
this files while it have an operation going.

> And I wonder why this should be a problem at all as the lvm1 was working
> pretty stable for years now.

lvm2 and lvm1 does not have many in common.

> Am So den 30. Mär 2008 um 10:52 schrieb Bastian Blank:
> > # Automatically generated email from bts, devscripts version 2.9.26
> > severity 419209 important
> The severity of this bug is absolute critical and not just important!

This is up to the maintainer. I use snapshots often and have not seen
such problems recently.

Bastian

-- 
We do not colonize.  We conquer.  We rule.  There is no other way for us.
-- Rojan, "By Any Other Name", stardate 4657.5


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

Re: xcdroast does no longer work with wodim: Who to blame?

[Matthew Johnson]

On Thu Mar 05 17:23, Russell Coker wrote:
 
> PS  What contributions are you making to any free software projects?  Please 
> note that trolling this mailing list doesn't count as a contribution.
 
I think you're being a little harsh Russell, but you're right

Bell, I don't think anyone anywhere disagrees that the copyright on
program source also applies to the binary form of the program, or to
other forms it may be converted into. Otherwise I would  be able to
pirate Microsoft office without it being illegal. After all, I'm not
copying the source. Ditto with other forms of non-text works, I don't
think any judge in the world would consider the mp3 of the latest hits
any less copyrighted than the original and that's even a lossy
transformation.

It therefore follows that any binary inherits the copyright of all the
source components which went to create it, otherwise I could clearly
steal anyone's work merely by adding enough useless code to it.

Hence we reach the same conclusion that Debian did some time ago.

matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Bug#419209: lvm2: Hangs during snapshot creation

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Do den  5. Mär 2009 um  8:46 schrieb Steve Langasek:
> > the whole system break. Also I add debian-devel to Cc as the bug is very
> > problematic and I wonder how lvm2 was able to get into lenny with that
> > big problem!
> 
> Possibly because there are many people using LVM snapshotting who haven't
> seen this bug?  I use schroot with LVM snapshots all the time on a server
> running the lenny kernel, and have never seen this bug.

Well, I did also some tests and wasn't able to trigger that bug on my
laptop too. But I also have the lvm direct on the hard disk. On my
server there is a md device underlying. So I suggest the problem is just
with a lvm on top of a md device (which you see not that often on
desktop systems). When I am at home next week (so I can restart the
system by button), I will do a bisect to find out the broken patch. I
just have the complete cvs imported to git now.

But to use the same argumentation than you, there seems to be many
people out there who suffering from this bug.

But as I downgrade the lvm2 back to etch my backup worked this night
since I updated the lvm2 the first time again. So I can prove that the
bug just happened between that two releases reported in the original
report.

> > I did use lvm1 with kernel 2.4 on etch for long time now using exact the
> > same procedure which trigger the problem right now.
> 
> Which was not a supported configuration.  Linux 2.4 was supported in etch
> only for purposes of upgrading, not for a running system.  Your decision to
> run an unsupported system actually makes it harder to track down this bug,
> since the only baseline we have for comparison in your case is a system with
> none of the relevant components in common.

Well, kernel 2.6 wasn't that stable to use it on a productive system.
(And in my opinion it isn't that stable still but there is no way to use
kernel 2.4 in lenny.) For my servers I prefer to have more stability
than more bleeding edge features!

> > Then with the release of lenny I start upgrading my stable systems. This
> > involved a kernel upgrade as lenny only runs with the very instable kernel
> > tree 2.6 and upgrade of the lvm metadata.
> 
> Claiming that the 2.6 kernel is unstable only undermines your credibility.

That's your opinion. I did test the 2.6 kernel in several versions now
and it has many instabilities. Also in 2.6 they dropped nearly the
complete oss driver so I have no sound. (The alsa driver never worked in
all of my environments. It takes just 5 minutes to get a kernel panic if
I try to use alsa. And yes, I test it also with several hardware and
with many kernel versions.) Altogether I think that the kernel
developer has to start a development tree to get the 2.6 series calm
down and get stable. Until now there is no 2.6 release which is that
stable then the kernel 2.4.

> > Days after I noticed that apt-get install froze randomly and I had to
> > reboot the system with a power cycle (reboot didn't work). First I was
> > thinking about one of the many kernel bugs in 2.6 and tried the newest
> > kernel from kernel.org. But the bug was still there. After several days
> > I end in finding the problem in the LVM2 subsystem and two days later,
> > today, I found this ug report and was very shocked! If I had know of it
> > before I had never upgrade any of may stable systems to lenny! But now
> > one of them is sticked on lenny as I know no way to revert the LVM back
> > to LVM1.
> 
> The original bug reporter claims that the hang only occurs with newer
> versions of the lvm2 userspace tools.  You could try downgrading to the etch
> version of lvm2, to see whether this resolves the problem for you.

As I mention above I can prove that this solves my problem. So the buggy
path is just in between.

> > Am Sa den 14. Apr 2007 um 12:53 schrieb Jean-Luc Coulon (f5ibh):
> > > New lvm2 version (2.02.24) hangs during snapshot creation.
> > > The lvmvreate process is not killeable at this point and the system need 
> > > to be
> > > reboted.
> 
> > That is the correct description. But more over the system will be
> > unbootable at all! I have to run /etc/init.d/reboot stop by hand to hard
> > reboot the system. A normal shutdown will end in a hanging system with
> > no remote access at all. The only solution at that point is to
> > powercycle the machine which is very problematic with remote system.
> 
> What does dmesg show for the system after the snapshot has hung?

Nothing. I also raised the log level of lvm to 7 (debug) but there is
nothing special in the log. The last lines are:
 libdm-deptree.c:1187   Creating sysvg-lv_usr-real
 ioctl/libdm-iface.c:1606   dm create sysvg-lv_usr-real 
LVM-aVvQkLwPuENl6auLtoUWJBqjM0OKG0NQ-real NF   
[16384]
 libdm-common.c:607   sysvg-lv_usr-real: Stacking NODE_ADD (253,9) 0:6 0660
 libdm-deptree.c:1463   Loading sysvg-lv_usr-real table
 libdm-deptree.c:1413   Adding target: 0 14024704 

Re: Pristine source from upstream VCS repository

[Ben Finney]

Reinhard Tartler  writes:

> Russ Allbery  writes:
> 
> > I think the way that you're using it is more useful (and possible)
> > than doing what an exact reading of the current text would
> > indicate, and I do the same thing that you're doing.
> 
> FYI, from the ffmpeg-debian (and soon mplayer) package, we (or at
> least I) use the following approach:
> 
>   SVNDATE=`date +%Y%m%d`
>   debian/rules get-orig-source SVN_VERSION=${SVNDATE}

So, in order to get the latest upstream has made available, you need
to override the default behaviour of the ‘get-orig-source’ target.

> Debian rules detects the SVN_VERSION like this:
> 
> DEB_SOURCE := $(shell dpkg-parsechangelog | sed -n 's/^Source: //p')
> DEB_VERSION := $(shell dpkg-parsechangelog | sed -n 's/^Version: //p')
> UPSTREAM_VERSION := $(shell echo $(DEB_VERSION) | sed -r 's/[^:]+://; 
> s/-[^-]+$$//')
> SVN_VERSION := $(shell echo $(UPSTREAM_VERSION) | sed -nr 
> 's/^[0-9.:-]+\.svn([0-9]+)$$/\1/p')
> 
> [...]
> 
> get-orig-source:
> dh_testdir
> chmod +x debian/strip.sh
> sh debian/get-orig-source.sh -d$(SVN_VERSION)

So, by default, the ‘get-orig-source’ target will result in the
original source archive that corresponds to the Debian package
version.

> I believe this approach matches both the letter and the spirit of
> debian policy notes about that target.

Well, it doesn't match the current wording in policy, in that your
‘get-orig-source’ by default will not get the latest from upstream,
but instead will get the upstream source version corresponding to the
Debian package version.

That supports the existing approaches discussed so far. It seems that
those of us who implement a ‘get-orig-source’ target find it more
useful to get the same corresponding upstream source each time, rather
than following policy on this issue.

I've proposed a patch to policy (in bug#466550) to bring policy in
line with this practice.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\Brain, but if we get Sam Spade, we'll never have any puppies.” |
_o__)   —_Pinky and The Brain_ |
Ben Finney


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

Re: Bug#419209: lvm2: Hangs during snapshot creation

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Do den  5. Mär 2009 um  9:48 schrieb Bastian Blank:
> severity 419209 important

It is critical as it breaks the whole system! I do not want to start a
severity war with you but please do not set the severity to wrong level.
It do not fix the bug just lowering the severity.

> On Wed, Mar 04, 2009 at 10:44:28AM +0100, Klaus Ethgen wrote:
> > first of all, I raised the severity of the bug to critical as it makes
> > the whole system break.
> 
> lvm2 manages blockdevices via the device-mapper framework, so it manages
> the system. It is the purpose of this tool and it will not hold you from
> doing stupid things.

Using snapshoots is no stupid thinks in my opinion. If you think that I
think the only stupid are your opinion.

So, enough bashing. Please stay on a objective level as this is a
critical bug in a core component which is proven to exists for many
people! Please help fixing it and do not play just with the severity!

> And for now I consider taking snapshots of / or /var as stupid, because
> it is impossible to recover if something goes wrong.

The braking happens with several lvs I had this some time with /usr some
time with /home and only one time with /var.

However snapshoting /var wasn't a problem in the past and is the
desired use of them too (also if you do not think so, but this is your
opinion!).

And I do not use snapshots for / but for another reason. I do not have
/ in lvm at all.

Ah, yes, and why do you think should /var be broken when using
snapshots? Just the snapshot might be broken. But as it is necessary to
reboot the system anyway this can be fixed easily after the boot the
same way as fixing a broken snapshot of /usr or /home. And with your
opinion it would be more stupid to use snapshots with /home cause the
most vitally data is in /home, not in /var. So, following your opinion
using snapshots at all is stupid. Please consider not to name other
people stupid.

> And without a working filesystem on this locations, the system will
> just block. It may work, but it also may break horrible as the kernel
> interface does not allow to do this change atomic.

That's wrong assuming. It was working well with lvm1 and (as I know now)
also with lvm2 up to the version in etch.

> > Also I add debian-devel to Cc as the bug is very
> > problematic and I wonder how lvm2 was able to get into lenny with that
> > big problem!
> 
> We have many software who only works for most but not for all people.

So the software is not buggy if it just works for the most people?

> > Also I am willing to help solving the bug. My next step will be to
> > import the whole version history to git and try to besect the problem.
> 
> Why do you think this would be a problem of the userspace part?

Cause just downgrading the userspace tools to 2.02.06-4etch1 fix the
bug!

I also first think of a kernel bug and, as I wrote in my mail, I did
update the kernel to the latest release to see if the bug still
persists before searching for other reasons.

> > So this bug is a complete show stopper for lenny
> 
> If you want to help you can provide the following information when it
> goes wrong:
> - "uname -a"

I just did that, the last available kernel release:
Linux ikki 2.6.28.7 #1 Sun Mar 1 13:03:56 CET 2009 i686 GNU/Linux

> - "dmesg"

Unhelpful as the system is booted new now.

> - "dmsetup table"
 ~> dmsetup table
 sysvg-lv_usr: 0 14024704 linear 9:0 97714560
 sysvg-lv_usr: 14024704 2752512 linear 9:0 65920
 sysvg-lv_var: 0 4194304 linear 9:0 2818432
 sysvg-lv_mirror: 0 117440512 linear 9:0 126615936
 sysvg-lv_local: 0 16777216 linear 9:0 7012736
 sysvg-lv_home: 0 73924608 linear 9:0 23789952
 sysvg-lv_home: 73924608 14155776 linear 9:0 111739264
 sysvg-lv_misc: 0 167772160 linear 9:0 244056448
 sysvg-lv_sec: 0 585826304 linear 9:2 65920
 sysvg-lv_sec: 585826304 22347776 linear 9:0 411828608
 sysvg-lv_hathi: 0 720896 linear 9:0 125895040


> - "cat /proc/mounts"
 ~> cat /proc/mounts 
 rootfs / rootfs rw 0 0
 /dev/root / xfs rw,noatime,nodiratime,noquota 0 0
 tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
 proc /proc proc rw,nosuid,nodev,noexec 0 0
 sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0
 tmpfs /dev tmpfs rw,size=10240k,mode=755 0 0
 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
 devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
 fusectl /sys/fs/fuse/connections fusectl rw 0 0
 usbfs /proc/bus/usb usbfs rw 0 0
 tmpfs /tmp tmpfs rw,nosuid,nodev 0 0
 /dev/mapper/sysvg-lv_usr /usr xfs rw,noatime,nodiratime,nobarrier,noquota 0 0
 /dev/mapper/sysvg-lv_var /var reiserfs rw,noatime,nodiratime 0 0
 /dev/mapper/sysvg-lv_local /usr/local xfs 
rw,noatime,nodiratime,nobarrier,noquota 0 0
 /dev/mapper/sysvg-lv_home /home reiserfs rw,nosuid,nodev,noatime,nodiratime 0 0
 /dev/mapper/sysvg-lv_misc /misc xfs 
rw,nosuid,noatime,nodiratime,nobarrier,noquota 0 0
 /dev/mapper/sysvg-lv_sec /misc/.sec xfs 
rw,nosuid,nodev,noatime,nodiratime,nobarrier,n

Re: Bug#419209: lvm2: Hangs during snapshot creation

[Wouter Verhelst]

On Thu, Mar 05, 2009 at 10:45:24AM +0100, Klaus Ethgen wrote:
> Am Do den  5. Mär 2009 um  9:48 schrieb Bastian Blank:
> > severity 419209 important
> 
> It is critical as it breaks the whole system! I do not want to start a
> severity war with you but please do not set the severity to wrong level.

Severity inflation is a very good way to lose your credibility.

'Breaks the whole system' means something like 'it removes files not
related to the package in question that will cause the system to stop
functioning', 'it spins so much at such high priority that no other
process can get CPU time anymore', or something similar.

In other words, 'critical' is reserved for bugs that cause so much
breakage that the person who did the upload should find a brown paper
bag to put over their head, or some such.

It is not meant for bugs that cause a package to stop functioning
correctly _within its own area of functionality_. If libc ceases to
function under certain circumstances, then no single application on the
entire system will run anymore, yet this is no reason to call it a
'critical' bug. If a newly-uploaded kernel will not boot, then the
entire system will become unusable, yet this does not make it a critical
bug. Similarly, if a bug in the LVM subsystem can make the kernel lock
up inside the device-mapper when doing certain operations, then this bug
remains within its own area of functionality, and the fact that the
system is inoperable after the bug triggers does not render it a
'critical' bug.

If you feel that this makes the 'critical' severity to be rare, then
that is correct -- by design.

The 'important' severity is reseved for 'a bug which has a major effect
on the usability of a package without rendering it completely unusable
to everyone'. This does apply here; 'the system ceases to operate
correctly' certainly means it has a major effect on the usability of the
LVM2 subsystem. However, as has been shown on this mailinglist,
certainly not everyone has the problems you describe -- it is not
'rendering it completely unusable to everyone'.

> It do not fix the bug just lowering the severity.

Nobody said anything of the sorts. However, inflating the bug severity
to a level that does not make sense will only make people angry, and not
cause them to speed up fixing the bug.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: -dbg packages; are they actually useful?

[Tzafrir Cohen]

On Thu, Mar 05, 2009 at 05:35:53PM +0900, Paul Wise wrote:
> On Thu, Mar 5, 2009 at 5:23 PM, Tzafrir Cohen  wrote:
> 
> > With rpm there's no such problem, as a separate debug package is
> > created automatically. I just have to keep it somewhere.
> 
> That is exactly the plan for debug.debian.net.

So, back to what I originally asked about: 

  * Locally-generated packages?
  * Backports?
  * ( Any other semi- and non-official repository)

Dear packagers, if your package is not intended for upload, please be
sure not to strip debug symbols.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


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

Come join me on SEO India

[Chirag Patel]

SEO India: SEO Ahmedabad, SEO India, Search Engine Optimization Company India


Hi Join this India's best SEO service Provider Group. share your ideas and tell 
us to every one what you know new things into this search engine world.

Click the link below to Join:
http://seosemindia.ning.com/?xgi=1UulkDw

If your email program doesn't recognize the web address above as an active link,
please copy and paste it into your web browser



Members already on SEO India
vipin, NRI, pankaj, Sunesh Thakkar, vipin



About SEO India
Search Engine Optimization Company India offers you high keyword ranking for 
your website on top most search engine

98 members
15 discussions
13 blog posts



To control which emails you receive on the corner, or to opt-out, go to:
http://seosemindia.ning.com/?xgo=vCJLKC4YgrIJ1rqfBLG393UyCBxf/2dC6d/JMvCYFJFCYENP/SsOT4fZ7QflncQcRr5H//JX6gk

Re: Installing accessibility packages by default?

[Christian Perrier]

Quoting Samuel Thibault (samuel.thiba...@ens-lyon.org):

> So, I'm asking: would it seem reasonable to ask tasksel to install
> accessibility packages along desktop packages?
> 
> I have tried to install Lenny with a gnome desktop, I ended up with
> 2.3GB disk usage.  Adding gnome-accessibility and brltty used only 83MB
> more disk.  The figures are probably quite similar in the case of a KDE
> desktop and kde-accessibility+brltty.  Considering the great help it can
> be to a not-so-small part of our users, is it too big?


Speaking for myself and considering the numbers you point here, I
support the suggestion of installing accessibility-related packages
to default desktop installs.

We have the chance in Debian to have an active accessibility team that
can commit self to guarantee a good maintenance of this part of the
system (mostly by updating tasksel tasks when needed).

We have the goal to delive "The Universal Operating System".

We share values that promote non discrimination (that's at least the
"spirit" of one of the articles of the DFSG) and we certainly are proud
of them.

For all theses reasons, I wholeheartedly support the inclusion of
accessibility-related packages in default desktop installs.

One should also note that this is, TTBOMK, the choice of commercial
desktop environments.




signature.asc
Description: Digital signature

Re: Installing accessibility packages by default?

[Andreas Tille]

On Thu, 5 Mar 2009, Samuel Thibault wrote:


It has been suggested a few times (471410, 511329, 516723) to
add an "accessibility" item to tasksel, which would e.g. install
gnome-accessibility.  The task would be automatically selected when
accessibility features was used during d-i itself.


I wonder whether this effort might profit from maintaining metapackages
for accessibility as it is done in the blends effort.  The blends-dev
has tasksel support as well - so it is easily possible to include
accessibility related packages into tasksel.  The extra profit would
be that you can provide an easy overview about accesibility related
programs in Debian - the only way I know is

   $ apt-cache search accessibility

which is quite weak.  Thinks of alternatives like

   http://blends.alioth.debian.org/science/tasks/

(which might even work for non native English speakers) and you also
have a developer related overview about bugs

   http://blends.alioth.debian.org/science/bugs/

There is no extra effort to create these web pages once you defined
the tasks.


`While it is a possible approach to have the installer explicitly
select packages for the users who are going to use the machine,
it is also obvious that an administrator might not know in advance
that a person with special needs is going to use this machine.
If we think this through, we realize that what would be most desireable
is to have accessibility infrastructure installed by default on a
default desktop, so that a person with special needs can just activate
it at login time if they need to.'


I admit that my suggestion above does not really help in this aspect.
On the other hand there were some ideas raised in the past to enable
a user to install certain tasks quickly inside the Blends framework.
Perhaps we should raise this topic again.


`What if, for example, you walk up to a friend/coworker and talk about
some issue.  You end up wanting to show them something, so you'd
actually like to login on tehir Linux machine with accessibility enabled
so that you can work together on the project.  However, since nobody
thought their machine would ever be used by a disabled person, the
necessary software would not be installed.'


The problem is that the typical admin does not have the specific
knowledge what actually is needed.  The idea to iron out this knowledge
inside the tasks files to enable admins who have not enough specific
knowledge about the needs of their users is one means to help in
this issue.


`That is why I think ultimately, accessibility infrastructure needs to be part
of the default desktop installation.  There are a few other scenarios as well,
like public workstations (for instance in universities) running Linux.
Currently, for them to be accessible, the admin staff needs to know all the ins
and outs of accessibility, or they at least have to make a conscious decission
about providing it to users.  If accessibility would work by default,
the chance of success for disabled people trying to find an accessible
computer would be much higher.'


I perfectly see the point here.  On the other hand I assume there are
most probably urgently needed packages who should be installed per
default and others which are just Recommended and Suggested.  So IMHO
it makes sense to have a accessibility-gnome / accessibility-kde
(perhaps accessibility-desktop) metapackages which are part of a
default installation.  But most probably there are other packages
which should be handled with different priority and you can perfectly
handle these by using metapackages.  The advantage of using
accessibility-gnome / accessibility-kde metapackages is that you
can perfectly handle the dependencies inside the accessibility project
because there will be no need to change d-i or the Gnome / KDE tasks.
They need only depend from one single package and you can change the
dependencies on your own in case some additional packages will show up
or some names will be changed for whatever reason.


So, I'm asking: would it seem reasonable to ask tasksel to install
accessibility packages along desktop packages?


IMHO yes - but in the way I suggested above and not by using explicite
package names.

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: Pristine source from upstream VCS repository

[Charles Plessy]

Le Thu, Mar 05, 2009 at 08:39:50PM +1100, Ben Finney a écrit :
> 
> I've proposed a patch to policy (in bug#466550) to bring policy in
> line with this practice.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466550#42

  
-   This target is optional, but providing it if
-   possible is a good idea.
+   Commonly, upstream developers will make canonical
+   original source archive files for specific versions
+   available for direct public download, and the
+   ‘uscan(1)’ tool can automate this task with an
+   appropriate ‘debian/watch’ configuration file. This
+   target is therefore optional, and required only for
+   those cases not satisfied by ‘uscan(1)’.


Hi Ben,

at the same time, your patch would make it mandatory to write a get-orig-source
target when uscan(1) can not do the job. Since there are sometimes upstreams
who change the contents of the tarball without changing its name, it means that
it is impossible to be sure that uscan can do the job, and therefore that we
would all need to use complex get-orig-source targets that monitor the contents
of the upstream tarballs. Can you soften your wording to the current "optional"
status ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Bug#518343: ITP: talk2nxt -- upload/download files from or to LEGO Mindstroms NXT

[Sebastian Reichel]

Package: wnpp
Severity: wishlist
Owner: Sebastian Reichel 

* Package name: talk2nxt
  Version : 0.2
  Upstream Author : Pascal Raymond 
* URL : http://www-verimag.imag.fr/~raymond/edu/lego/t2n/
* License : GPL-3
  Programming Lang: C++
  Description : upload/download files from or to LEGO Mindstroms NXT

This is a small CLI program for uploading files to your
LEGO Mindstorms NXT and downloading others from it using
the USB cable.
..
Apart from that you can check the battery level and get
basic information about the NXT.

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing'), (400, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)



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

Re: xcdroast does no longer work with wodim: Who to blame?

[Bill Unruh]

On Thu, 5 Mar 2009, Matthew Johnson wrote:


On Thu Mar 05 17:23, Russell Coker wrote:


PS  What contributions are you making to any free software projects?  Please
note that trolling this mailing list doesn't count as a contribution.


I think you're being a little harsh Russell, but you're right

Bell, I don't think anyone anywhere disagrees that the copyright on
program source also applies to the binary form of the program, or to
other forms it may be converted into. Otherwise I would  be able to
pirate Microsoft office without it being illegal. After all, I'm not
copying the source. Ditto with other forms of non-text works, I don't
think any judge in the world would consider the mp3 of the latest hits
any less copyrighted than the original and that's even a lossy
transformation.


That is the question that "derivative works" raises, and my only claim was
that it was a question that all copyright law, whether in the US or in Europe
addresses in some for or another. However, exactly what constitutes derivative
work is an incredibly contentious issue and there are no clear rules. It is
quite possible that a judge could fine that linking program A to library B
does NOT make the result a derivative work of library B. Or he could find it
does. It is at present simply not known.

As I said, the SCO case revolves around what consititutes derivative work.




It therefore follows that any binary inherits the copyright of all the
source components which went to create it, otherwise I could clearly
steal anyone's work merely by adding enough useless code to it.


Of course. That is precisely what copyright to some extent is supposed to do,
encourage others to build on the work. The consitition gives the Federal Gov't
in the US the right to set up copyright to encourage the creation of new
works, not just by protecting the author but by making the work public so
others can build on it. Copyright is a delicate balancing act, trading a
detested (in capitaist circles at least) for of ownership-- monopoly rights--
for public exposure exactly so others can build on it. When does that building
infringe on the monopoly rights? That is tough question which the courts are
constantly battling with.



Hence we reach the same conclusion that Debian did some time ago.



Debian's conclusion comes uncomfortably near to SCO's conclusion, that
derivative works are created if there is any whiff of prior contact. 
A library is written to be used and to be linked to other programs. That is

its purpose. To argue that in so doing it infects the linking program and
makes it a derivative work could be dangerous, but at the least could be
argued, and has been argued by reasonable people.




matt




--
William G. Unruh   |  Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy  | Advanced Research  | Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 |  and Gravity   |  www.theory.physics.ubc.ca/


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

Re: -dbg packages; are they actually useful?

[Aurelien Jarno]

On Thu, Mar 05, 2009 at 12:43:43AM -0800, Russ Allbery wrote:
> Aurelien Jarno  writes:
> 
> > Compressing -dbg files using dh_builddeb -Zlzma, which uses lzma
> > compression instead of gzip, gives an average gain of 1.88 in size for
> > the current -dbg packages we have in sid.
> 
> Compressing with bzip2 is already supported by DAK and might help almost
> as much.  (I realize that LZMA is a better compression scheme overall, but

Most of the tests shows that bzip2 is slower to decompress an archive and
has a smaller gain than LZMA.

> it's apparently also deprecated, replaced with XZ, and using it in the
> archive will require further DAK changes or work to switch to XZ instead.)

AFAIK, allowing LZMA in DAK is just a matter of changing one line in
DAK.

Do you have more details about LZMA being deprecated and replaced by XZ?
If we want to allow XZ, it will be for squeeze + 1 only.

BTW, I think we should also to disallow the compression for some
Debian packages. There is no point of compressing a package with gzip
when it contains a single source.bz2 (or .gz or .lzma) and a
changelog.gz. This is already supported by the tools, but not by DAK.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Re: Requirement for a “pro per manpage” for every command

[Adeodato Simó]

* Charles Plessy [Tue, 03 Mar 2009 13:23:37 +0900]:

> Le Tue, Mar 03, 2009 at 12:10:09AM +, Roger Leigh a écrit :

> > crap maintainer
> > bloody lazy.

> I thought I was doing something good when writing manpages, now I realise what
> I am for not writing enough : « responsable de merde putain de feignant »
> (translated in my language). Thank you for opening my eyes.

Well, I think writing missing manpages is commendable independently of
what we may agree on calling those who won't do it.

Have a nice day,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
- Oh my God, you're pimping me out for a new roof?
- And windows!
-- Andrew and Bree Van De Kamp


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

Bug#518353: RFP: clam-plugins -- Extension plugins for the CLAM audio framework

[David García Garzón]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: clam-plugins
  Version : 1.3.1~svn
  Upstream Author :  CLAM Team  
* URL : http://clam-project.org
* License : GPL
  Programming Lang: C++
  Description : Extension plugins for the CLAM audio framework

 This package provides several plugins for the CLAM audio library, including:
  * OSC support
  * Real-time 3D acoustics scene simulation (ambisonics, raytracing, HRTF's)
  * Speech synthesis and analysis
  * Simple SMS based synthesizer
  * Guitar effects
  * Sample by sample convolution effects
  * Lock-free wave file reader


Unofficial Debian Packages are available at upstream.
This depends on 'clam' (bug #493282).




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

Re: Installing accessibility packages by default?

[Samuel Thibault]

Andreas Tille, le Thu 05 Mar 2009 13:16:22 +0100, a écrit :
> On Thu, 5 Mar 2009, Samuel Thibault wrote:
> >It has been suggested a few times (471410, 511329, 516723) to
> >add an "accessibility" item to tasksel, which would e.g. install
> >gnome-accessibility.  The task would be automatically selected when
> >accessibility features was used during d-i itself.
> 
> I wonder whether this effort might profit from maintaining metapackages
> for accessibility as it is done in the blends effort.  The blends-dev
> has tasksel support as well - so it is easily possible to include
> accessibility related packages into tasksel.  The extra profit would
> be that you can provide an easy overview about accesibility related
> programs in Debian - the only way I know is
> 
>$ apt-cache search accessibility
> 
> which is quite weak.

Tags FTW.  Look for Accessibility tags and you'll find a lot of
packages.

> Thinks of alternatives like
> 
>http://blends.alioth.debian.org/science/tasks/
>http://blends.alioth.debian.org/science/bugs/

Let me point out something which I think is important (even if I think
that's not what you meant): accessibility is not a task. It's like i18n,
it's orthogonal to tasks: for all the tasks above you actually need
accessibility support.

I do not mean that the tool itself shouldn't be used of course.

> >`What if, for example, you walk up to a friend/coworker and talk about
> >some issue.  You end up wanting to show them something, so you'd
> >actually like to login on tehir Linux machine with accessibility enabled
> >so that you can work together on the project.  However, since nobody
> >thought their machine would ever be used by a disabled person, the
> >necessary software would not be installed.'
> 
> The problem is that the typical admin does not have the specific
> knowledge what actually is needed.

The admin, no, but you (the disabled person) do know and just ask your
friend/coworker to run e.g. orca (already installed by default). With
USB braille devices, it would even be possible to automatically start
it, no even need to sudo.

> The idea to iron out this knowledge inside the tasks files to enable
> admins who have not enough specific knowledge about the needs of their
> users is one means to help in this issue.

Yes, we definitely need to have some sort of database that allows people
to know the name of the tools they can try to use to help them anyway.

> I assume there are
> most probably urgently needed packages who should be installed per
> default and others which are just Recommended and Suggested.

Possibly, yes.

> So IMHO it makes sense to have a accessibility-gnome /
> accessibility-kde (perhaps accessibility-desktop) metapackages which
> are part of a default installation.

Which can Depend/Recommend/Suggest depending on the criticity of the
help provided by various packages:
- can't use the computer without it (e.g. screen reader for blind people).
- hard for me to use the computer without it (e.g. color scheme).
- makes me more efficient (e.g. dasher).

> The advantage of using accessibility-gnome / accessibility-kde
> metapackages is that you can perfectly handle the dependencies inside
> the accessibility project because there will be no need to change d-i
> or the Gnome / KDE tasks.

Yes, I also think that'd be better.

> >So, I'm asking: would it seem reasonable to ask tasksel to install
> >accessibility packages along desktop packages?
> 
> IMHO yes - but in the way I suggested above and not by using explicite
> package names.

Sure. We don't want to have to bother d-i each time new accessibility
packages get added :)

Samuel


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

Re: -dbg packages; are they actually useful?

[Russ Allbery]

Aurelien Jarno  writes:

> AFAIK, allowing LZMA in DAK is just a matter of changing one line in
> DAK.

> Do you have more details about LZMA being deprecated and replaced by XZ?

See "current state of the development" at http://tukaani.org/lzma/ and
then http://tukaani.org/xz/ and note in particular this part of the
release announcement of the latest GNU coreutils package:

Distribution note: new suffix, ".xz" replaces ".lzma".  Note the
better-compressed tar ball name below has the ".xz" suffix.  XZ Utils
(new name for the improved format/tools) is the successor to lzma.
For more info, see http://tukaani.org/xz/

It's possible that XZ archives can be uncompressed with LZMA.  I haven't
investigated further.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#436792: ITP: ganttproject Gantt chart based project

[Kouhei Maeda]

Package: wnpp
Followup-For: Bug #436792
Owner: Kouhei Maeda 

I use this tool on business, 
then I want to use this tool privately on Debian.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)



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

Re: handling group membership in and outside d-i

[brian m. carlson]

On Wed, Mar 04, 2009 at 06:12:54PM +0100, Josselin Mouette wrote:

Using things like pam_console or pam_group should not become our default
policy, unless we at least ensure /home, /var and /tmp are mounted
nosuid – and it would be better with the ability to revoke the
permissions on the open devices as well.


Mounting /var nosuid would break things:

  lakeview ok % ls -ld /var/mail
  drwxrwsr-x 2 root mail 4096 2007-05-02 00:22 /var/mail

nosuid prohibits not only suid bits, but sgid bits as well.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Support of new source packages in squeeze

[Raphael Hertzog]

Hello,

as announced earlier during the lenny dev cycle, I would like to switch to
the new source package formats ("3.0 (quilt)" and "3.0 (native)") during
the squeeze cycle so that we can benefit from the numerous improvements.
For this kind of important change, it's best to start early in the release
cycle.

Lenny's dpkg has all the support for the new source formats so in theory
we can start using new formats in squeeze except that dak doesn't support
them. After discussions with ftpmaster, and given their workload, I prepared 
a set of patches (http://lists.debian.org/debian-dak/2009/03/msg9.html).
I hope that Joerg will have time to review and test them soon. And
hopefully, they will quickly be in a state where they can be merged and
deployed on ftp-master.d.o. The associated bug report is
http://bugs.debian.org/457345

My goal is not only to accept them on ftp-master but also to update
dpkg-source to build new source package automatically. That's why I
rebuilt the archives to see what packages would not build with the
new format (without fixes). The failures are tracked here:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=hert...@debian.org;tag=3.0-quilt-by-default

I will do (thanks to Lucas Nussbaum) another archive rebuild in the
upcoming weeks to see if we have new failures. Hopefully the release team
can grant the status of release goal to this project so that we can more
easily NMU the remaining packages.

All in all, things are in a rather good shape but I still need some help.
While I tested extensively the dpkg-source side, we still need to ensure
that all our additional tools cope well with the new source package
format (*-buildpackage, apt-get source, lintian, devscripts, dput/dupload,
etc.). I know several tools in devscripts have already been fixed/enhanced
in that regard. Please try using new source packages with all those tools
(in particular if you maintain them) and file bugs if you encounter
problems and usertag them appropriately (user hert...@debian.org /
tag 3.0-quilt-by-default).

To create a new source package, simply take an existing package and
rebuild it after having put "3.0 (quilt)" or "3.0 (native)" in
the file debian/source/format (see dpkg-source(1) for more information).

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: Support of new source packages in squeeze

[Luk Claes]

Raphael Hertzog wrote:
> Hello,

Hi

> as announced earlier during the lenny dev cycle, I would like to switch to
> the new source package formats ("3.0 (quilt)" and "3.0 (native)") during
> the squeeze cycle so that we can benefit from the numerous improvements.
> For this kind of important change, it's best to start early in the release
> cycle.

What are the benefits of switching every package to the new formats?

> Lenny's dpkg has all the support for the new source formats so in theory
> we can start using new formats in squeeze except that dak doesn't support
> them. After discussions with ftpmaster, and given their workload, I prepared 
> a set of patches (http://lists.debian.org/debian-dak/2009/03/msg9.html).
> I hope that Joerg will have time to review and test them soon. And
> hopefully, they will quickly be in a state where they can be merged and
> deployed on ftp-master.d.o. The associated bug report is
> http://bugs.debian.org/457345

Right, it's a good idea to test it early in the release cycle and gradually.

> My goal is not only to accept them on ftp-master but also to update
> dpkg-source to build new source package automatically. That's why I
> rebuilt the archives to see what packages would not build with the
> new format (without fixes). The failures are tracked here:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=hert...@debian.org;tag=3.0-quilt-by-default

Did you also test if they produce the same content?

Cheers

Luk

PS: There is no call for Release Goal proposals yet, though I think it
would be a good idea to have a wiki page which all the info prepared
already.


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

Re: Support of new source packages in squeeze

[Russ Allbery]

Raphael Hertzog  writes:

> All in all, things are in a rather good shape but I still need some
> help.  While I tested extensively the dpkg-source side, we still need to
> ensure that all our additional tools cope well with the new source
> package format (*-buildpackage, apt-get source, lintian, devscripts,
> dput/dupload, etc.).

Lintian is tested with 3.0 (quilt) and 3.0 (native) packages and
LZMA-compressed data components and source tarballs as of 2.2.6.  (It's
also tested with 2.0 packages, for whatever it's worth.)  It however is
known not to work with source packages that contain multiple upstream
source tarballs.  Patches to the unpacking scripts are welcome provided
that they come with an addition to the test suite.  It's a fairly
complicated area of the code.

-- 
Russ Allbery (r...@debian.org)   


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

Re: Support of new source packages in squeeze

[Всеволод Величко]

Hello.

On Fri, Mar 6, 2009 at 12:19 AM, Raphael Hertzog  wrote:
> as announced earlier during the lenny dev cycle, I would like to switch to
> the new source package formats ("3.0 (quilt)" and "3.0 (native)") during
> the squeeze cycle so that we can benefit from the numerous improvements.

Excuse me, I understand, that it's offtopic, but where can I read
about the difference between old and newstyle source package formats?
I found nothing on the d-o sites.

-- 
Best regards,
Velichko Vsevolod


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

Re: Support of new source packages in squeeze

[Daniel Moerner]

On Thu, Mar 5, 2009 at 2:49 PM, Всеволод Величко  wrote:
> Hello.
>
> On Fri, Mar 6, 2009 at 12:19 AM, Raphael Hertzog  wrote:
>> as announced earlier during the lenny dev cycle, I would like to switch to
>> the new source package formats ("3.0 (quilt)" and "3.0 (native)") during
>> the squeeze cycle so that we can benefit from the numerous improvements.
>
> Excuse me, I understand, that it's offtopic, but where can I read
> about the difference between old and newstyle source package formats?
> I found nothing on the d-o sites.

man dpkg-source and search for "Format: 3.0"

-- 
Daniel Moerner 


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

Re: Support of new source packages in squeeze

[Jan Hauke Rahm]

On Thu, Mar 05, 2009 at 10:19:15PM +0100, Raphael Hertzog wrote:
> as announced earlier during the lenny dev cycle, I would like to switch to
> the new source package formats ("3.0 (quilt)" and "3.0 (native)") during
> the squeeze cycle so that we can benefit from the numerous improvements.
> For this kind of important change, it's best to start early in the release
> cycle.

Right. And thanks for the reminder!

> All in all, things are in a rather good shape but I still need some help.
> While I tested extensively the dpkg-source side, we still need to ensure
> that all our additional tools cope well with the new source package
> format (*-buildpackage, apt-get source, lintian, devscripts, dput/dupload,
> etc.). I know several tools in devscripts have already been fixed/enhanced
> in that regard. Please try using new source packages with all those tools
> (in particular if you maintain them) and file bugs if you encounter
> problems and usertag them appropriately (user hert...@debian.org /
> tag 3.0-quilt-by-default).

I can tell from svn-buildpackage which is definitely *not* ready for new
package formats. It even doesn't parse the new compression methods (bz2
is repacked to gz at the moment).
I started working on svn-bp improvements some time ago but as it turns
out I'm pretty much alone with that atm. So, I don't know when svn-bp
will be ready but everyone interested in helping please contact me! :)

Hauke


signature.asc
Description: Digital signature

Re: Support of new source packages in squeeze

[Michael Biebl]

Raphael Hertzog wrote:

> 
> All in all, things are in a rather good shape but I still need some help.
> While I tested extensively the dpkg-source side, we still need to ensure
> that all our additional tools cope well with the new source package
> format (*-buildpackage, apt-get source, lintian, devscripts, dput/dupload,
> etc.). I know several tools in devscripts have already been fixed/enhanced
> in that regard. Please try using new source packages with all those tools
> (in particular if you maintain them) and file bugs if you encounter
> problems and usertag them appropriately (user hert...@debian.org /
> tag 3.0-quilt-by-default).

dpkg-gencontrol: warning: unknown information field 'Format' in input data in
general section of control info file

Should I file a bug against dpkg-dev for that?

And another minor issue: vim doesn't know about the new Format field in
debian/control yet. It seems it [1] has to be updated.

Regarding lintian: For packages which already use quilt and have a quilt
Build-Depends, it would imho be useful if lintian issued a warning, that this
build-dep is no longer required with 3.0 (quilt).

Cheers,
Michael


[1] /usr/share/vim/vim72/syntax/debcontrol.vim

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Pristine source from upstream VCS repository

[Ben Finney]

On 05-Mar-2009, Charles Plessy wrote:
> at the same time, your patch would make it mandatory to write a
> get-orig-source target when uscan(1) can not do the job. […] Can you
> soften your wording to the current "optional" status ?

Agreed. I also should have used the standard document markup for
various terms.

Here is an updated patch:


=== modified file 'policy.sgml'
--- policy.sgml 2009-03-05 08:44:48 +
+++ policy.sgml 2009-03-05 23:59:38 +
@@ -1907,12 +1907,21 @@
get-orig-source (optional)

  
-   This target fetches the most recent version of the
-   original source package from a canonical archive site
-   (via FTP or WWW, for example), does any necessary
+   This target generates the original source archive for
+   the package, such that its contents exactly match the
+   original source archive used to generate the package
+   for Debian. See the “Original source archive”
+   section, below, for policy details of this file.
+ 
+
+ 
+   The actions for this target fetch the original source
+   package, corresponding to the Debian package version,
+   from a canonical archive site (for example, via FTP,
+   WWW, or a public VCS repository), do any necessary
rearrangement to turn it into the original source
-   tar file format described below, and leaves it in the
-   current directory.
+   archive file format, and leave it in the current
+   directory.
  
 
  
@@ -1922,8 +1931,14 @@
  
 
  
-   This target is optional, but providing it if
-   possible is a good idea.
+   This target is optional. A common reason to
+   forego this target is that the upstream developers
+   make canonical original source archive files for
+   specific versions available for direct public
+   download; in these cases, the package only needs an
+   appropriate debian/watch configuration
+   for uscan to fetch the original source
+   archive.
  

 


-- 
 \  “Immorality: The morality of those who are having a better |
  `\  time.” —Henry L. Mencken |
_o__)  |
Ben Finney 


signature.asc
Description: Digital signature

Re: Support of new source packages in squeeze

[Michael Biebl]

Raphael Hertzog wrote:
> 
> I will do (thanks to Lucas Nussbaum) another archive rebuild in the
> upcoming weeks to see if we have new failures. Hopefully the release team
> can grant the status of release goal to this project so that we can more
> easily NMU the remaining packages.
> 

Will you do that only for packages which already use quilt?
Or how will you rebuild packages with 3.0 (quilt) that already use dpatch or
cdbs with simple-patchsys? (the latter would at least require to normalize all
patches to -p1, create a series file and remove simple-patchsys.mk from
debian/rules).

Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#518426: ITP: r6rs-doc -- Revised^6 Report on the Algorithmic Language Scheme

[Daniel Moerner]

Package: wnpp
Severity: wishlist
Owner: Daniel Moerner 

  Package name: r6rs-doc
  Version : 1.0
  Upstream Author : Michael Sperber, et al
  URL : http://www.r6rs.org/
  License : We intend this report to belong to the entire Scheme 
community, and so we grant permission to copy it in whole or
in part without fee. In particular, we encourage 
implementors of Scheme to use this report as a starting 
point for manuals and other documentation, modifying it as 
necessary.
  Programming Lang: HTML and PDF for docs, Scheme for examples
  Description : Revised^6 Report on the Algorithmic Language Scheme

This package contains the four parts of the R6RS report in both PDF and HTML
format. These parts are defined as follows:
..
r6rs: The report gives a defining description of the programming language 
Scheme. Scheme is a statically scoped and properly tail-recursive dialect of 
the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay 
Sussman. It was designed to have an exceptionally clear and simple semantics 
and few different ways to form expressions. A wide variety of programming 
paradigms, including functional, imperative, and message passing styles, find 
convenient expression in Scheme.
..
r6rs-lib: The report gives a defining description of the standard libraries of 
the programming language Scheme.
..
r6rs-app: This document contains non-normative appendices to the Revised6 
Report on the Algorithmic Language Scheme. These appendices contain advice for
users and suggestions for implementors on issues not fit for standardization, 
in particular on platform-specific issues.
..
r6rs-rationale: This document describes rationales for some of the design 
decisions behind the Revised^6 Report on the Algorithmic Language Scheme. The 
focus is on changes made since the last revision on the report. Moreover, 
numerous fundamental design decisions of Scheme are explained. This report also
contains some historical notes. 


Chris: I have CC'd you on this ITP because you maintain r5rs-doc. I sent you an
email about a week ago about the possibility of making r6rs-doc a separate
package because it is such a radical departure from previous Scheme
reports, with the specification of a standard library. Also, the fact
that several implementors, including mit-scheme, gambit, chicken, and bigloo,
don't intend to support r6rs suggests that both r5rs and r6rs should be
in Debian concurrently. I welcome any thoughts you have about the matter.

Regards,
Daniel Moerner


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)



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

Prefix level in Quilt patches (was: Support of new source packages in squeeze)

[Ben Finney]

Michael Biebl  writes:

> Or how will you rebuild packages with 3.0 (quilt) that already use
> dpatch or cdbs with simple-patchsys? (the latter would at least
> require to normalize all patches to -p1, […]).

The ‘quilt(1)’ manpage documents a ‘-p’ option:

-p n
Create a -p n style patch (-p0 or -p1 are supported).

My preferred method of producing patches (directly from my VCS) makes
them as equivalent to ‘patch -p0’ patches. But nothing I do seems to
convince the Debian packaging tools to use anything but ‘-p1’ when
applying these patches, which fails of course.

How can I reliably inform the Debian packaging tools that my quilt
patches are in ‘patch -p0’ format?

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\Brain, but if we get Sam Spade, we'll never have any puppies.” |
_o__)   —_Pinky and The Brain_ |
Ben Finney


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

Bug#518430: ITP: libarray-unique-perl Tie-able array that allows only unique values

[Xavier Oswald]

Package: wnpp
Severity: wishlist
Owner: Xavier Oswald 


* Package name: libarray-unique-perl
  Version : 0.08-1
  Upstream Author : Gabor Szabo 
* URL : http://search.cpan.org/dist/Array-Unique/
* License : GPL, Artistic
  Programming Lang: Perl
  Description : Array::Unique - Tie-able array that allows only unique 
values

This package lets you create an array which will allow only one occurrence of
any value. In other words no matter how many times you put in 42 it will keep
only the first occurrence and the rest will be dropped.

You use the module via tie and once you tied your array to this module it
will behave correctly. Uniqueness is checked with the 'eq' operator so among
other things it is case sensitive. As a side effect the module does not allow
undef as a value in the array.


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

-- 
  ,''`.  Xavier Oswald
 : :' :  GNU/LINUX Debian Maintainer
 `. `'   GnuPG Key ID 0x88BBB51E
   `-938D D715 6915 8860 9679  4A0C A430 C6AA 88BB B51E 




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

Re: Prefix level in Quilt patches (was: Support of new source packages in squeeze)

[Paul Wise]

On Fri, Mar 6, 2009 at 10:12 AM, Ben Finney  wrote:

> How can I reliably inform the Debian packaging tools that my quilt
> patches are in ‘patch -p0’ format?

You don't want to use -p0 otherwise you'll get bugs from buxy about
not supporting dpkg source package v3. I'm using this to generate my
patches:

$ grep REFRESH ~/.quiltrc
QUILT_REFRESH_ARGS="-pab --no-timestamps --no-index"

If you actually want -p0 for some weird reason, make sure the series
file has that option in it:

$ locate debian/patches/series | xargs grep -- -p0
...
/home/pabs/devel/debian/games/gravitation/debian/patches/series:abs_path.patch
-p0
/home/pabs/devel/debian/games/passage/debian/patches/series:abs_path.patch -p0
/home/pabs/devel/debian/games/passage/debian/patches/series:amd64_fix.patch -p0
...

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Prefix level in Quilt patches

[Ben Finney]

Paul Wise  writes:

> On Fri, Mar 6, 2009 at 10:12 AM, Ben Finney  
> wrote:
> 
> > How can I reliably inform the Debian packaging tools that my quilt
> > patches are in ‘patch -p0’ format?
> 
> You don't want to use -p0 otherwise you'll get bugs from buxy about
> not supporting dpkg source package v3.

Hmm. Why does buzy have this behaviour? My first impression is that,
if buxy can't handle a ‘-p0’ patch, that's a bug.

> If you actually want -p0 for some weird reason

As mentioned, the reason is that's what is most easily output from my
VCS's ‘diff’ command which I'm using to generate the patch files.

> make sure the series file has that option in it:
> 
> $ locate debian/patches/series | xargs grep -- -p0
> ...
> /home/pabs/devel/debian/games/gravitation/debian/patches/series:abs_path.patch
> -p0
> /home/pabs/devel/debian/games/passage/debian/patches/series:abs_path.patch -p0
> /home/pabs/devel/debian/games/passage/debian/patches/series:amd64_fix.patch 
> -p0
> ...

Thank you. I didn't see this mentioned clearly in the Quilt
documentation.

-- 
 \ “Are you pondering what I'm pondering?” “I think so, Brain, but |
  `\   pants with horizontal stripes make me look chubby.” —_Pinky and |
_o__)   The Brain_ |
Ben Finney


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

Re: Prefix level in Quilt patches

[Paul Wise]

On Fri, Mar 6, 2009 at 3:07 PM, Ben Finney  wrote:
> Paul Wise  writes:
>
>> On Fri, Mar 6, 2009 at 10:12 AM, Ben Finney  
>> wrote:
>>
>> > How can I reliably inform the Debian packaging tools that my quilt
>> > patches are in ‘patch -p0’ format?
>>
>> You don't want to use -p0 otherwise you'll get bugs from buxy about
>> not supporting dpkg source package v3.
>
> Hmm. Why does buzy have this behaviour? My first impression is that,
> if buxy can't handle a ‘-p0’ patch, that's a bug.

buxy (Raphael Hertzog) has pushed dpkg-source 3.0 (quilt) source
packages into lenny dpkg and understandably wants us to switch to it
for squeeze:

http://lists.debian.org/debian-devel/2009/03/msg00348.html

The reason you cannot use -p0 with dpkg-source 3.0 (quilt) source
packages is because dpkg-source ignores options in the series file and
expects patches were generated with -p1 or -pab, a quote from the
dpkg-source manual page:

Note however that while dpkg-source parses correctly series files with
explicit options used for patch application (stored on each line after
the patch filename and one  or  more  spaces),  it does ignore those
options and always expect patches that can be applied with the -p1
option of patch. It will thus emit a warning when it encounters such
options, and the build is likely to fail.

buxy has been filing bugs on packages that fail to build as a result
of using patches generated using -p0.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#518443: ITP: libschedule-ratelimiter-perl -- Perl library to prevent events from happening too quickly

[Ryan Niebur]

Package: wnpp
Owner: Ryan Niebur 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libschedule-ratelimiter-perl
  Version : 0.01
  Upstream Author : Daniel J. Wright, 
* URL : http://search.cpan.org/dist/Schedule-RateLimiter/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl library to prevent events from happening too quickly
 Schedule::RateLimiter provides a way to voluntarily restrict how many times a
 given action may take place within a specified time frame. Such a tool may be
 useful if you have written something which periodically polls some public
 resource and want to ensure that you do not overburden that resource with too
 many requests.
 .
 Initially, one might think that solving this problem would be as simple as
 sleeping for the number of seconds divided by the number of iterations in
 between each event. However, that would only be correct if the event took no
 time at all.
 .
 If you know exactly how much time each event is going to take then you could
 build an even more complicated one-liner such as this:
 .
 sleep( (seconds / iterations) - single_event_time )

-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Re: Prefix level in Quilt patches

[Ben Finney]

Paul Wise  writes:

> On Fri, Mar 6, 2009 at 3:07 PM, Ben Finney  wrote:
> > My first impression is that, if buxy can't handle a ‘-p0’ patch,
> > that's a bug.

My apologies, I thought ‘buxy’ was perhaps the name of some service on
the Debian project infrastructure.

> The reason you cannot use -p0 with dpkg-source 3.0 (quilt) source
> packages is because dpkg-source ignores options in the series file
> and expects patches were generated with -p1 or -pab, a quote from
> the dpkg-source manual page:
> 
> Note however that while dpkg-source parses correctly series files
> with explicit options used for patch application (stored on each
> line after the patch filename and one or more spaces), it does
> ignore those options and always expect patches that can be applied
> with the -p1 option of patch. It will thus emit a warning when it
> encounters such options, and the build is likely to fail.

The question remains: If this is the behaviour of ‘dpkg-source’, I
consider it a bug. What is the reason for this explicit behaviour?

-- 
 \  “And if I laugh at any mortal thing, / 'Tis that I may not |
  `\   weep.” —“Lord” George Gordon Noel Byron, _Don Juan_ |
_o__)  |
Ben Finney


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

Work-needing packages report for Mar 6, 2009

[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: 388 (new: 1)
Total number of packages offered up for adoption: 112 (new: 0)
Total number of packages requested help for: 50 (new: 0)

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



The following packages have been orphaned:

   dog (#518398), orphaned today
 Description: Enhanced replacement for cat
 Installations reported by Popcon: 318

387 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 112 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#470795), requested 357 days ago
 Description: Co-maintainer wanted
 Reverse Depends: ampache apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (153 more
   omitted)
 Installations reported by Popcon: 42341

   ara (#450876), requested 480 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 122

   asymptote (#517342), requested 7 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 207

   athcool (#278442), requested 1591 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 217

   boinc (#511243), requested 56 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1574

   cvs (#354176), requested 1106 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (12 more
   omitted)
 Installations reported by Popcon: 22795

   dctrl-tools (#448284), requested 495 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies dlocate haskell-devscripts
   hg-buildpackage ia32-archive ia32-libs-tools mlmmj sbuild simple-cdd
 Installations reported by Popcon: 10586

   dpkg (#282283), requested 1566 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential bzr-builddeb cacao-oj6-dbg cacao-oj6-jdk
   (120 more omitted)
 Installations reported by Popcon: 83095

   drscheme (#402589), requested 815 days ago
 Description: PLT scheme programming environment
 Reverse Depends: drscheme minlog proofgeneral-minlog
 Installations reported by Popcon: 312

   elvis (#432298), requested 605 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 394

   fglrx-driver (#454993), requested 453 days ago (non-free)
 Description: non-free AMD/ATI r5xx, r6xx display driver
 Reverse Depends: fglrx-amdcccle fglrx-atieventsd fglrx-control
   fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-kernel-src
 Installations reported by Popcon: 2213

   flightgear (#487388), requested 257 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 992

   gentoo (#422498), requested 669 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 265

   gnat-4.3 (#475374), requested 329 days ago
 Description: help needed to execute test cases
 Reverse Depends: adabrowse adacontrol asis-programs ghdl gnade-bin
   gnat gnat-4.3 gnat-gps libadasockets-dev libahven14 (46 more
   omitted)
 Installations reported by Popcon: 747

   gnat-gps (#496905), requested 189 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 143

   grub (#248397), requested 1760 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: brdesktop-artwork-grub dfsbuild grub-choose-default
   grub-doc replicator startupmanager
 Installations reported by Popcon: 75825

   hotkey-setup (#483107), requested 283 days ago
 Description: auto-configures laptop hotkeys
 Installations reported by Popcon: 29280

   imagemagick (#452314), requested 470 days ago
 Description: Ima

Re: Support of new source packages in squeeze

[Raphael Hertzog]

On Fri, 06 Mar 2009, Michael Biebl wrote:
> dpkg-gencontrol: warning: unknown information field 'Format' in input data in
> general section of control info file
> 
> Should I file a bug against dpkg-dev for that?
> 
> And another minor issue: vim doesn't know about the new Format field in
> debian/control yet. It seems it [1] has to be updated.

No, I should rather remove that part of the documentation. The official
way to indicate that we want to use another format is creating
debian/source/format (like I indicated in my mail) and not that
non-supported field.

The underlying idea is that the desired format might depend from where the
package is built (from a VCS, from another source package, etc.) and
that debian/control should always be the same no matter what source
package has been used to extract it.

Updating debian/source/format on the fly is also better than updating
debian/control and that's needed if you unpack a non-standard source
package to ensure that we rebuild it with the same format.

> Build-Depends, it would imho be useful if lintian issued a warning, that this
> build-dep is no longer required with 3.0 (quilt).

Please file a wishlist bug against it, then. :)

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: Support of new source packages in squeeze

[Raphael Hertzog]

On Fri, 06 Mar 2009, Michael Biebl wrote:
> Raphael Hertzog wrote:
> > 
> > I will do (thanks to Lucas Nussbaum) another archive rebuild in the
> > upcoming weeks to see if we have new failures. Hopefully the release team
> > can grant the status of release goal to this project so that we can more
> > easily NMU the remaining packages.
> > 
> 
> Will you do that only for packages which already use quilt?
> Or how will you rebuild packages with 3.0 (quilt) that already use dpatch or
> cdbs with simple-patchsys? 

The implementation of "3.0 (quilt)" is done in a way that is (as much as
possible) not conflicting with all those patch systems. So I do nothing
special with those packages… many of them simply end up without quilt
series since all the relevant changes are in the other patch system.

That said, it is my hope that people will progressively switch to quilt
series so that we have less patch systems to deal with.

The NMU campaign certainly won't cover this, at least not for package that
do not FTBFS with the new source format. And even the others, it might be
possible that the only change done would be to add "1.0" in
debian/source/format to keep the old format until the maintainer decides
to switch to something else.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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