Re: For those who care about their packages in Debian

[Julien BLACHE]

Ben Hutchings  wrote:

Hi,

> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze.  The sooner squeeze is out, the sooner you can add
> stuff to the next release.

I'd add: stop uploading new upstream versions to unstable, or actually
any revision that isn't needed for Squeeze and won't make it into
Squeeze.

You're just making everybody else's life harder by doing this.

If you can't refrain from uploading, at least upload to experimental
until Squeeze is out.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762yz884y@sonic.technologeek.org

Re: For those who care about their packages in Debian

[Josselin Mouette]

Le mercredi 25 août 2010 à 02:09 +0100, Ben Hutchings a écrit :
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze.  The sooner squeeze is out, the sooner you can add
> stuff to the next release.

I second that, and would also suggest to extend this to the time after
squeeze is out. I’d like to see less packages with 20 popcon entries and
more maintainers for core packages. Don’t forget that the bus factor for
packages like glibc and xorg is getting dangerously close to 1.

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1282721681.5507.64.ca...@meh

Re: For those who care about their packages in Debian

[Russ Allbery]

Ben Hutchings  writes:

> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze.  The sooner squeeze is out, the sooner you can add
> stuff to the next release.

This comes up with every release, so I guess I'll reiterate what I end up
saying during every release.

This sort of request is based on erroneous assumptions, and while intended
to be helpful, can just be frustrating and demotivating to people who are
working on other things in Debian.  I don't have an undistinguished bucket
of time that's "Debian time" that I'm choosing to use on new software
packages instead of working on helping the release.  I have some Debian
time, which is going towards release issues, and I have time spent on
other projects (generally day-job projects) that involve, in part,
packaging new software for Debian.

That last bucket of time is simply not available to work on the squeeze
release, period.  If I weren't spending it on packaging new things for
Debian, I would not be spending it on Debian *at all*.  I don't think you
actually would prefer that.

I, and I suspect many other people who are working on packaging new
software for their own reasons, am quite aware of the release and are
trying to stay out of the way.  I'm uploading new upstream versions to
experimental and taking similar precautions to make sure that work
unrelated to the release doesn't interfere with the release.

If there's a specific reason why uploading completely new leaf packages to
unstable causes problems for the release coordination, please do say so on
debian-devel.  I'm personally not seeing it off-hand, but I'm probably
missing someting.  I haven't done this yet, but hadn't found any reason
why it would be a problem and could have seen myself doing that.

Please also remember that many of us just got back from DebConf enthused
about new projects, and are working on those projects while we have
emotional momentum.  Depending on how one's brain works, the alternative
to working on projects while enthused about them is not working on them
after the release; it can be never working on them at all.  It is, of
course, incumbant on us to do so in a way that doesn't interfere with the
release.

-- 
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
Archive: http://lists.debian.org/871v9n9lu4@windlord.stanford.edu

Re: For those who care about their packages in Debian

[Ben Finney]

Russ Allbery  writes:

> I, and I suspect many other people who are working on packaging new
> software for their own reasons, am quite aware of the release and are
> trying to stay out of the way.

+1

Though I'm not currently packaging any new software during this freeze,
I've worked with people who are doing so, and in past freezes have done
so myself; and the above characterises the approach taken.

> If there's a specific reason why uploading completely new leaf
> packages to unstable causes problems for the release coordination,
> please do say so on debian-devel. I'm personally not seeing it
> off-hand, but I'm probably missing someting.

If packaging new software for Debian actually is causing problems, those
problems need to be addressed.

But the solution would best entail allowing ‘unstable’ to continue to be
used for the same purpose regardless of whether a freeze is currently
active, no?

I guess the answer to that depends on the question of how continuing to
use ‘unstable’ in the same way is causing problems, and why those
problems are manifesting during a freeze and not otherwise.

-- 
 \ “In any great organization it is far, far safer to be wrong |
  `\  with the majority than to be right alone.” —John Kenneth |
_o__)Galbraith, 1989-07-28 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkwbnn0e@benfinney.id.au

Re: For those who care about their packages in Debian

[Russ Allbery]

Ben Finney  writes:

> But the solution would best entail allowing ‘unstable’ to continue to be
> used for the same purpose regardless of whether a freeze is currently
> active, no?

This, *in general*, doesn't work because of the way library transitions
work.  If you upload a new upstream version of a library to unstable, you
can really ruin the release team's month, since then other packages in
unstable can pick up dependencies to things that aren't going to be
released and it all turns into a big mess.  This is really bad, and indeed
people need to not be doing that.

Uploading new versions of leaf software isn't *as* big of a disaster, but
it does mean that updates to that software that should go into testing
can't go through the normal testing process and have to go through
testing-proposed-updates, which is way riskier.  This isn't good.  So for
anything that's releasing with squeeze, please upload any subsequent
versions *not* aimed at squeeze to experimental instead.  (Although there
are some weird exceptions; for example, we continue to upload Lintian to
unstable all the way through a release since it mostly doesn't matter what
exact version of Lintian releases with squeeze.)

But completely new packages that have never been in unstable before and
that aren't libraries and won't show up in dependencies I think don't
cause any problems other than a probably imperceptible increase in the
length of time the testing propagation scripts take to run.  But if I'm
missing something, I'd love to know and learn.

-- 
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
Archive: http://lists.debian.org/87sk2386hn@windlord.stanford.edu

Re: For those who care about their packages in Debian

[Yves-Alexis Perez]

On 25/08/2010 10:02, Russ Allbery wrote:
> Uploading new versions of leaf software isn't *as* big of a disaster, but
> it does mean that updates to that software that should go into testing
> can't go through the normal testing process and have to go through
> testing-proposed-updates, which is way riskier.  This isn't good.  So for
> anything that's releasing with squeeze, please upload any subsequent
> versions *not* aimed at squeeze to experimental instead.

Hmhm, out of curiosity, why is t-p-u “way riskier”. Would it be possible
(at one point) to “fix” it and stop using unstable as t-p-u and
experimental as unstable when freeze is in action?

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c74cf3b.1030...@debian.org

Re: For those who care about their packages in Debian

[Russ Allbery]

Yves-Alexis Perez  writes:
> On 25/08/2010 10:02, Russ Allbery wrote:

>> Uploading new versions of leaf software isn't *as* big of a disaster,
>> but it does mean that updates to that software that should go into
>> testing can't go through the normal testing process and have to go
>> through testing-proposed-updates, which is way riskier.  This isn't
>> good.  So for anything that's releasing with squeeze, please upload any
>> subsequent versions *not* aimed at squeeze to experimental instead.

> Hmhm, out of curiosity, why is t-p-u “way riskier”.

Mostly because there isn't any large pool of systems using t-p-u the way
there is for unstable, so the aging process where we get testing in
unstable before migrating the package never happens.  This means uploads
to t-p-u could potentially break more conservative testing users, which is
bad, and worse they're essentially going straight into a release
candidate, so depending on timing we could release with bad bugs.  It's
always better to get the unstable shakedown where possible.

> Would it be possible (at one point) to “fix” it and stop using unstable
> as t-p-u and experimental as unstable when freeze is in action?

We could try to get lots of people who normally use unstable to instead
test testing plus t-p-u, but I'm not sure they'd be willing to do so.  I
for example don't want to switch my unstable systems to testing plus t-p-u
for a variety of reasons.

-- 
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
Archive: http://lists.debian.org/87k4nf8602@windlord.stanford.edu

Re: Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files

[Goswin von Brederlow]

Simon Richter  writes:

> Hi,
>
> I think that we should be aiming towards descriptive domain-specific
> languages rather than imperative catch-all ones wherever possible. In
> the old days before debhelper, the rules file would explicitly move
> files around, and I think .install files are a huge step forward. I'd
> also like to see a tool to generate preinst/postrm fragments for
> diversions.
>
> There is a reason why I held a lightning talk comparing dpkg to
> Microsoft Installer at DC9. :)
>
>Simon

So maybe a debian/clean file that lists things dh_clean should remove?

Oh wait, we already have that. :)

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkwbccj3@frosties.localdomain

Re: Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files

[Goswin von Brederlow]

Ian Jackson  writes:

> Goswin von Brederlow writes ("Re: Bug#592839: dpkg-source option to remove 
> files on unpack: debian/source/remove-files"):
>> No. The files must be legal to be included. They are distributed in the
>> tarball after all. So deleting or not deleting makes absolutely no
>> difference to ftp-master. This only works for things we don't WANT to
>> use, not for things we CAN'T use. Convenience copies are a perfect
>> example for this. The deleting is there to make sure we don't
>> accidentally use them. Not to make the tarball legal. Only repackaging
>> will make a tarball with truely non-free stuff usable.
>
> There is a difference between "`only' non-free" and
> non-redistributable.  At the moment people are removing RFCs and
> GFDL-non-free docs from source packages, because those files are
> non-free; however, they are redistributable.
>
> Ian.

That was my point. Legally we CAN use those files. But we don't WANT to
use them for DFSG reasons.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vd6zcc6s@frosties.localdomain

Re: why are there /bin and /usr/bin...

[Goswin von Brederlow]

The Fungi  writes:

> On Fri, Aug 20, 2010 at 10:45:04PM +0200, Christoph Anton Mitterer wrote:
>> Of course,.. but only because your /usr is on the root-fs.
>> 
>> And there are many good reasons to put it on its own fs, as already
>> outlayed here...
> [...]
>
> No disagreement there... I'm much in favor of continuing to support
> /usr on its own filesystem for a variety of reasons. And I
> acknowledge the circularity of the argument was only partial (I did
> qualify that by calling it *somewhat* circular). My point was that,
> playing devil's advocate, it's not enough to suggest that lacking
> the tools/logic in the initrd to mount an encrypted /usr is reason
> alone to have /usr separate from the / filesystem.

We already have the logic in there to mount anything as /. /usr can't be
any harder so that isn't an argument. There is nothing you can do with
/usr that can't allready be done to /.


I think the biggest argument for multiple partitions is that / and /usr
can be read-only and that gives a huge reliability improvement. But that
argument doesn't really tell why /usr should be seperate.

The biggest argument for supporting a seperate /usr I think is for
historical reasons. Many many systems are simply setup that way and
requiring people to reinstall from scratch for an update is not the
Debian way. I think against that the other reasons are minor though
still valid even for new installs.

MfG
GOswin





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5hncbay@frosties.localdomain

Bug#594321: ITP: dkopp -- incremental backup tool to DVD and Blueray media

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: dkopp
  Version : 5.4
  Upstream Author : Michael Cornelison 
* URL : http://kornelix.squarespace.com/dkopp/
* License : GPL
  Programming Lang: C
  Description : incremental backup tool to DVD and Blueray media

Dkopp is a program used to copy or back-up disk files to DVD or
BD (Blue-ray) media. Full or incremental backups can be done,
with full or incremental media verification. A GUI is used to
navigate through directories to select or de-select files or
directories at any level. Backup jobs can be saved for later re-use.
New, deleted, and updated disk files are handled automatically,
without re-editing the backup job. An incremental backup updates the
same DVD/BD media used for a prior full backup. Files can be restored
to the same or another location on disk. Large backup jobs can be
done using multiple DVD media.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100825091518.7944.3822.report...@alessio-laptop

Re: Atlas proposal

[Goswin von Brederlow]

Sylvestre Ledru  writes:

> For now, the solution I imagine is:
> * build the package libatlas3gf-base just like it is now
> * the libatlas3gf-auto package contains the upstream tarball + the
> content of the debian/ directory
> * libatlas3gf-auto has dependencies on the build dependencies
> * when -auto is install, it will unpack both the tarball and the debian
> directory
> * it will start the build (fakeroot debian/rules custom)
> * at the end, it installs the .deb packages and removes the
> libatlas3gf-auto
>
> How does it sound ? Is it possible ?
>
> Does anybody know an other packages in the archive which does that ? (I
> just checked with fftw and optimization are done at runtime).
>
> Sylvestre

As said in other mails the "Installs the .deb" part won't work for
locking reasons.

But I have some experience with this from automatic kernel deb building
I did a few years back. So here is how I did solve the issue there:

I have a package "linux-custom" that depends on the kernel source,
patches, module sources and anything needed to build a kernel. It also
contains the .config. This coresponds to your libatlas3gf-auto package.

I also have a package "local-archive" that depends on reprepro,
generates a local signing key on first install, adds that to the apt-get
keyring and adds a file:/// url in /etc/apt/sources.list.d/.


Now when a kernel compile was needed (kernel source, patch or module
source was updated) a build job gets started in the background. It is a
good idea to delay the build a bit so dpkg/apt can finish before the
compile hogs the cpu. In my case I touch
/var/lib/linux-custom/need-rebuild and a nightly cron job starts the
build process if that exists. You might want something else or some
combination of things so the package rebuild is restarted if the system
is rebooted during build and so on.

Success or failure a mail is send to notify the user of the build result
(success just says the new package is there, failure includes
logs). When the build succeeds the generated package is added to the
local reprepro archive. The next time apt-get update/upgrade is run the
custom package is installed.

Using a local archive instead of calling dpkg -i directly avoids the
locking issues. It also allows exporting the archive for a pool of
systems. No need to build libatlas3gf 200 times for a 200 node cluster.
On the down side the upgrade of the package, while being completly
transparent, is not completly automatic. It requires 2 update/upgrade
runs.



To support building atlas on one system and installing it on many you
may want to use Depends: libatlas3gf-base | libatlas3gf-auto |
libatlas3gf-remote, libatlas3gf-base | libatlas3gf-custom.

The -base is the prebuild package, the -auto sets up the automatic
building and libatlas3gf-remote adds a file in /etc/apt/sources.list.d/
with an entry configured via debconf.  Having any one of the three
ensures atlas package updates will be available. The second part then
ensures that eigther the base or custom flavour of the lib is installed.

The important part though is that you would allow installing the -custom
package without requiring the -auto package as well.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxsbc9sn@frosties.localdomain

Re: For those who care about their packages in Debian

[Yves-Alexis Perez]

On 25/08/2010 10:13, Russ Allbery wrote:
> Yves-Alexis Perez  writes:
>> Hmhm, out of curiosity, why is t-p-u “way riskier”.
> 
> Mostly because there isn't any large pool of systems using t-p-u the way
> there is for unstable,

Yeah, good point.

> 
>> Would it be possible (at one point) to “fix” it and stop using unstable
>> as t-p-u and experimental as unstable when freeze is in action?
> 
> We could try to get lots of people who normally use unstable to instead
> test testing plus t-p-u, but I'm not sure they'd be willing to do so.  I
> for example don't want to switch my unstable systems to testing plus t-p-u
> for a variety of reasons.
> 
I have a box running testing (well, not updated due to flaky net
connection right now) which I really should pass on testing+t-p-u.

But wouldn't CUT fit nicely there?

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c74e5c9.3020...@debian.org

Re: Atlas proposal

[Josselin Mouette]

Le mercredi 25 août 2010 à 11:37 +0200, Goswin von Brederlow a écrit :
> To support building atlas on one system and installing it on many you
> may want to use Depends: libatlas3gf-base | libatlas3gf-auto |
> libatlas3gf-remote, libatlas3gf-base | libatlas3gf-custom.
> 
> The -base is the prebuild package, the -auto sets up the automatic
> building and libatlas3gf-remote adds a file in /etc/apt/sources.list.d/
> with an entry configured via debconf.  Having any one of the three
> ensures atlas package updates will be available. The second part then
> ensures that eigther the base or custom flavour of the lib is installed.
> 
> The important part though is that you would allow installing the -custom
> package without requiring the -auto package as well.

I beg any FTP master reading this to immediately reject any package
doing something as sick as what you just described.

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1282729943.5507.66.ca...@meh

Re: For those who care about their packages in Debian

[Lucas Nussbaum]

On 25/08/10 at 11:43 +0200, Yves-Alexis Perez wrote:
> On 25/08/2010 10:13, Russ Allbery wrote:
> > Yves-Alexis Perez  writes:
> >> Hmhm, out of curiosity, why is t-p-u “way riskier”.
> > 
> > Mostly because there isn't any large pool of systems using t-p-u the way
> > there is for unstable,
> 
> Yeah, good point.
> 
> > 
> >> Would it be possible (at one point) to “fix” it and stop using unstable
> >> as t-p-u and experimental as unstable when freeze is in action?
> > 
> > We could try to get lots of people who normally use unstable to instead
> > test testing plus t-p-u, but I'm not sure they'd be willing to do so.  I
> > for example don't want to switch my unstable systems to testing plus t-p-u
> > for a variety of reasons.
> > 
> I have a box running testing (well, not updated due to flaky net
> connection right now) which I really should pass on testing+t-p-u.
> 
> But wouldn't CUT fit nicely there?

It depends on your definition of CUT.

If CUT is about snapshotting testing every 3 or 6 months and having
users use those snapshots, it won't help much with testing software in
the testing suite (because users would often be using older versions
that what is in testing).

If CUT is about having more users use testing itself, then t-p-u could
be enabled too, and it would help, yes. 

(Disclaimer: in the discussion on the cut mailing list, I'm clearly in
favor of the second solution. And I have a pending action item to
summarize the discussion in a mail on -devel@ or -project@, so we can
discuss this in a larger forum. Help welcomed.)

- Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100825095332.ga21...@xanadu.blop.info

Activating t-p-u by default (was: Re: For those who care about their packages in Debian)

[Christian PERRIER]

Quoting Russ Allbery (r...@debian.org):

> > Hmhm, out of curiosity, why is t-p-u “way riskier”.
> 
> Mostly because there isn't any large pool of systems using t-p-u the way
> there is for unstable, so the aging process where we get testing in
> unstable before migrating the package never happens.  This means uploads

I wonder whether we (in D-I) could add t-p-u to the list of proposed
repositories when users install testing. We already propose security
and volatile (defaulting to both added): the same mechanism could be
made for t-p-u when users install testing.




signature.asc
Description: Digital signature

Re: Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files

[Ian Jackson]

Goswin von Brederlow writes ("Re: Bug#592839: dpkg-source option to remove 
files on unpack: debian/source/remove-files"):
> That was my point. Legally we CAN use those files. But we don't WANT to
> use them for DFSG reasons.

I think we are in vigorous agreement, but your tone makes me hesitate.
Let me summarise my understanding:

 File status:   DFSG-free   non-free butNot
redistributable redistributable
--- --  --
 
 Presence   Can and Currently removed   Must be removed,
 in .orig   should be   from .orig's by someso .orig tarball
   .tar.gz  included.   maintainers.  I think   must be repacked.
this is a waste of
time.

 Removal or May sometimes   IMO necessary toInsufficient.
 inhibition be useful toprevent accidental
 by dpkg-srcavoid acci- use, and to facilitate
 pattern or dental use. licence review
 rm by rules

Do you agree ?  In particular, do you agree that repacking .orig
tarballs to remove non-free-but-redistributable files (such as RFCs
and non-free-GFDL docs) is a waste of time ?

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19572.62635.567686.628...@chiark.greenend.org.uk

Re: Atlas proposal [and 1 more messages]

[Ian Jackson]

Goswin von Brederlow writes ("Re: Atlas proposal"):
> I also have a package "local-archive" that depends on reprepro,
> generates a local signing key on first install, adds that to the apt-get
> keyring and adds a file:/// url in /etc/apt/sources.list.d/.

I think this scheme is a very bad idea.  I don't think packages should
be recursing into the packaging infrastructure this way.  And I think
automatically adding different local repositories to the apt
configuration is pretty horrid.

> Using a local archive instead of calling dpkg -i directly avoids the
> locking issues. It also allows exporting the archive for a pool of
> systems. No need to build libatlas3gf 200 times for a 200 node cluster.

The build time problem is easily solved by the cluster admin using a
ccache, if indeed we care.

Having said that:

Josselin Mouette writes ("Re: Atlas proposal"):
> I beg any FTP master reading this to immediately reject any package
> doing something as sick as what you just described.

I don't think this is a very friendly way of putting it.  Invoking or
mentioning escalation is not necessary in what was previously a
reasonable and technical discussion.

If you dislike Goswin's idea so much you should set out your
criticisms of it.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19572.63005.455706.776...@chiark.greenend.org.uk

Re: For those who care about their packages in Debian

[Ben Hutchings]

On Wed, 2010-08-25 at 00:45 -0700, Russ Allbery wrote:
[...]
> That last bucket of time is simply not available to work on the squeeze
> release, period.  If I weren't spending it on packaging new things for
> Debian, I would not be spending it on Debian *at all*.  I don't think you
> actually would prefer that.

No indeed,

[...]
> I, and I suspect many other people who are working on packaging new
> software for their own reasons, am quite aware of the release and are
> trying to stay out of the way.  I'm uploading new upstream versions to
> experimental and taking similar precautions to make sure that work
> unrelated to the release doesn't interfere with the release.
> 
> If there's a specific reason why uploading completely new leaf packages to
> unstable causes problems for the release coordination, please do say so on
> debian-devel.
[...]

I'm not involved in the release team so I don't feel qualified to make
such a claim.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: Atlas proposal

[Reinhard Tartler]

On Wed, Aug 25, 2010 at 11:37:44 (CEST), Goswin von Brederlow wrote:

> I also have a package "local-archive" that depends on reprepro,
> generates a local signing key on first install, adds that to the apt-get
> keyring and adds a file:/// url in /etc/apt/sources.list.d/.

This sounds interesting for some use-cases. Would you mind sharing this
'local-archive' package?

Thanks!

-- 
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
Archive: 
http://lists.debian.org/87y6burh60@faui44a.informatik.uni-erlangen.de

Re: For those who care about their packages in Debian

[Ian Jackson]

Russ Allbery writes ("Re: For those who care about their packages in Debian"):
> Ben Hutchings  writes:
> 
> > Please stop filing ITPs and concentrate on packages that should be
> > included in squeeze.  The sooner squeeze is out, the sooner you can add
> > stuff to the next release.
> 
> This comes up with every release, so I guess I'll reiterate what I end up
> saying during every release.

I agree with everything you've said.

Perhaps the right answer is to simply ask people to upload
non-release-related stuff to experimental rather than unstable.  That
way one can do the itch-scratching right away; moving packages from
experimental to unstable later is easy (and anyone can do it if they
know it's wanted because it doesn't normally require much skill or
knowledge, for peripheral packages at least).

Even better would be an option to write something in your .dsc which
would cause automatic transfer of your package into unstable when
testing is unfrozen.  Distro target of "experimental-unstable"
perhaps.  That way we could automate the "flood of new packages and
distro is totally broken" effect :-).

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19573.4026.231395.224...@chiark.greenend.org.uk

list of packages that FTBFS on i386

[Kamaraju S Kusumanchi]

How do I obtain a list of packages that have FTBFS bugs filed on them and 
that are currently failing to build on i386 architecture?

I can see a list of RC-bugs at http://bugs.debian.org/release-
critical/debian/main.html . I can download that page and grep it for FTBFS. 
However, most of the FTBFS bugs seem to occur on non i386 architectures. 
Since I do not have access to non-i386 machines, it will be difficult to 
help with those. So, I just want to stick to bugs pertaining to i386 
architecture. Any ideas/suggestions?

thanks
raju
-- 
Kamaraju S Kusumanchi
http://malayamaarutham.blogspot.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/i534gg$sa...@dough.gmane.org

Seeking fellow developers feedback for iceweasel in squeeze (transient homepage & upgrade notification)

[Mike Hommey]

Hi,

For those not reading debian-rele...@l.d.o, I planned to include some
further changes to iceweasel before the freeze, except that the freeze
happened earlier than I expected. Anyways, the plan was more or less
accepted by the release team, but now that I actually started to make
the changes, I have mixed feelings on two of them. This is where I'd
appreciate feedback from my fellow developers, and why not, users.

> - Add local homepages when upgrading and running for the first time,
>   instead of the pages on http://mozilla.debian.net/

Here the more I think about it, the more I think we need something
different. (Thinking out loud) One of the reasons I wanted to use the
remote server is that it would make it easier to update the content with
news and translations, even though the content is pretty much static at
the moment.
OTOH, it has almost no interest for stable users, except maybe for the
news part, where we could have links pointing at backports for newer
upstream versions or betas.
So maybe these transient homepages (remember they only show up when
the xulrunner version changes, which won't happen in squeeze
stable/security updates or when running iceweasel for the first
time) should just thank users, and point to some useful links/rss
feeds and be done with it.

> - Improve or remove the restart popup that shows up when upgrading the
>   package. The main problem it is trying to avoid is the impossibility
>   to cleanly close iceweasel after an upgrade. I need to test further,
>   but there are chances this is really only needed when upgrading
>   between major versions. I'm not entirely sure it has a benefit for
>   other cases, though apart from one complaint on planet.debian.org, I
>   saw no feedback... there are a bunch of known issues with it, like
>   with multiple iceweasel windows, or like not activating again when
>   the user doesn't want to restart now but the browser is upgraded
>   again
>   later.

There is actually another benefit, it's that people who leave iceweasel
opened for a very long time are notified they should restart after a
security update, which is IMHO sensible. I'm not entirely convinced it's
really needed for extensions or plugins, which would make the code and
wording of the popup clearer. As for the major version upgrade problem,
I'm afraid it actually won't help much, as there are cases where either
the quit dialog or the upgrade notification will tentatively show up, 
but the underlying file won't be there anymore (like, when the upgrade
involves removing the old xulrunner). And, obviously, as the upgrade
notification thingy is not provided currently in lenny, these changes 
would only make a difference for squeeze->squeeze+1 upgrades (or 
squeeze->backports, or backports->squeeze, for that matter).
One way I can think of to alleviate the problem when the old xulrunner
is removed would be to have the upgrade notification UI part of a
separate package, and installed in the shared location for extensions
(though it would need to be somewhere that works for conkeror, too, and
shouldn't break other applications such as icedove, that don't have the
necessary binary component)

Any feedback appreciated on both subjects.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100825130859.ga10...@glandium.org

Re: For those who care about their packages in Debian

[Mike Hommey]

On Wed, Aug 25, 2010 at 01:42:34PM +0100, Ian Jackson wrote:
> Russ Allbery writes ("Re: For those who care about their packages in Debian"):
> > Ben Hutchings  writes:
> > 
> > > Please stop filing ITPs and concentrate on packages that should be
> > > included in squeeze.  The sooner squeeze is out, the sooner you can add
> > > stuff to the next release.
> > 
> > This comes up with every release, so I guess I'll reiterate what I end up
> > saying during every release.
> 
> I agree with everything you've said.
> 
> Perhaps the right answer is to simply ask people to upload
> non-release-related stuff to experimental rather than unstable.  That
> way one can do the itch-scratching right away; moving packages from
> experimental to unstable later is easy (and anyone can do it if they
> know it's wanted because it doesn't normally require much skill or
> knowledge, for peripheral packages at least).
> 
> Even better would be an option to write something in your .dsc which
> would cause automatic transfer of your package into unstable when
> testing is unfrozen.  Distro target of "experimental-unstable"
> perhaps.  That way we could automate the "flood of new packages and
> distro is totally broken" effect :-).

That would obviously require some automated way to propate from
experimental to unstable, much like unstable->testing transition
happens, when all deps are available in unstable, etc.

IMHO, this would be better to be triggered on maintainer request
and semi-manually, instead of a distro target. Another issue is that
at the time you upload to experimental, which can be very much early
in the freeze, you may not know you want that to propagate to
unstable at unfreeze time.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100825131419.ga10...@glandium.org

Re: why are there /bin and /usr/bin...

[Christoph Anton Mitterer]

On Wed, 2010-08-25 at 11:05 +0200, Goswin von Brederlow wrote:
> We already have the logic in there to mount anything as /.
Well. at least if it's a very plain setup... (see
http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices)

>  /usr can't be
> any harder so that isn't an argument.
Again,... depending on how complicated this is,... maybe multiple
stacked block layers, some over network, etc etc. this could require
much (more) stuff added to the initramfs.


Cheers,
Chris.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1282742089.3243.96.ca...@fermat.scientia.net

Re: list of packages that FTBFS on i386

[Lucas Nussbaum]

On 25/08/10 at 09:05 -0400, Kamaraju S Kusumanchi wrote:
> How do I obtain a list of packages that have FTBFS bugs filed on them and 
> that are currently failing to build on i386 architecture?
> 
> I can see a list of RC-bugs at http://bugs.debian.org/release-
> critical/debian/main.html . I can download that page and grep it for FTBFS. 
> However, most of the FTBFS bugs seem to occur on non i386 architectures. 
> Since I do not have access to non-i386 machines, it will be difficult to 
> help with those. So, I just want to stick to bugs pertaining to i386 
> architecture. Any ideas/suggestions?

You can start with
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-ftbfs;users=debian...@lists.debian.org
Those are for amd64, but most of them are not architecture-specific and
also apply to i386.

- Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100825132413.ga2...@xanadu.blop.info

Re: Seeking fellow developers feedback for iceweasel in squeeze (transient homepage

[Mike Hommey]

On Wed, Aug 25, 2010 at 03:44:54PM +0200, Fabian Greffrath wrote:
> >So maybe these transient homepages (remember they only show up when
> >the xulrunner version changes, which won't happen in squeeze
> >stable/security updates or when running iceweasel for the first
> >time) should just thank users, and point to some useful links/rss
> >feeds and be done with it.
> 
> On the other hand, they could be modeled to become actually usefull
> standard home pages with a search box and interesting links to help
> follow Debian or Mozilla development, i.e. something that users
> might actually want to keep as their home page. I remember that this
> was actually the case for Debian mozilla packages long ago.

That would be the default homepage, which is currently about:. That has
nothing to do with the homepages I'm talking about.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100825134850.ga12...@glandium.org

Re: Seeking fellow developers feedback for iceweasel in squeeze (transient homepage

[Fabian Greffrath]

So maybe these transient homepages (remember they only show up when
the xulrunner version changes, which won't happen in squeeze
stable/security updates or when running iceweasel for the first
time) should just thank users, and point to some useful links/rss
feeds and be done with it.


On the other hand, they could be modeled to become actually usefull 
standard home pages with a search box and interesting links to help 
follow Debian or Mozilla development, i.e. something that users might 
actually want to keep as their home page. I remember that this was 
actually the case for Debian mozilla packages long ago.


 - Fabian


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c751e56.7080...@greffrath.com

Re: Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files

[Manoj Srivastava]

On Wed, Aug 25 2010, Ian Jackson wrote:

> Goswin von Brederlow writes ("Re: Bug#592839: dpkg-source option to remove 
> files on unpack: debian/source/remove-files"):
>> That was my point. Legally we CAN use those files. But we don't WANT to
>> use them for DFSG reasons.
>
> I think we are in vigorous agreement, but your tone makes me hesitate.
> Let me summarise my understanding:
>
>  File status:   DFSG-free   non-free butNot
> redistributable redistributable
> --- --  --
>
>  Presence   Can and Currently removed   Must be removed,
>  in .orig   should be   from .orig's by someso .orig tarball
>.tar.gz  included.   maintainers.  I think   must be repacked.
> this is a waste of
> time.
>
>  Removal or May sometimes   IMO necessary toInsufficient.
>  inhibition be useful toprevent accidental
>  by dpkg-srcavoid acci- use, and to facilitate
>  pattern or dental use. licence review
>  rm by rules
>
> Do you agree ?  In particular, do you agree that repacking .orig
> tarballs to remove non-free-but-redistributable files (such as RFCs
> and non-free-GFDL docs) is a waste of time ?

Once I have written my watch file, and the urepack script, I
 find that the time being wasted lies in the sub-second range.  Hardly
 something I worry about, really.

manoj

--8<---cut here---start->8---
version=3
opts=pasv,dversionmangle=s/\.ds//  http://www.fvwm.org/download/ \
ftp://ftp.fvwm.org/pub/fvwm/version-2/fvwm-([\d\.]*)\.tar\.gz\
  debian debian/urepack
--8<---cut here---end--->8---



-- 
The sheep died in the wool.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sk22vlai@anzu.internal.golden-gryphon.com

Re: Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files

[Goswin von Brederlow]

Manoj Srivastava  writes:

> On Wed, Aug 25 2010, Ian Jackson wrote:
>
>> Goswin von Brederlow writes ("Re: Bug#592839: dpkg-source option to remove 
>> files on unpack: debian/source/remove-files"):
>>> That was my point. Legally we CAN use those files. But we don't WANT to
>>> use them for DFSG reasons.
>>
>> I think we are in vigorous agreement, but your tone makes me hesitate.
>> Let me summarise my understanding:
>>
>>  File status:   DFSG-free   non-free butNot
>> redistributable redistributable
>> --- --  --
>>
>>  Presence   Can and Currently removed   Must be removed,
>>  in .orig   should be   from .orig's by someso .orig tarball
>>.tar.gz  included.   maintainers.  I think   must be repacked.
>> this is a waste of
>> time.
>>
>>  Removal or May sometimes   IMO necessary toInsufficient.
>>  inhibition be useful toprevent accidental
>>  by dpkg-srcavoid acci- use, and to facilitate
>>  pattern or dental use. licence review
>>  rm by rules
>>
>> Do you agree ?  In particular, do you agree that repacking .orig
>> tarballs to remove non-free-but-redistributable files (such as RFCs
>> and non-free-GFDL docs) is a waste of time ?

ACK. That summarizes it nicely. The "Not redistributable" is a legal
problem and no amount of good will from ftp-master will change the need
to repack. The "non-free but redistributable" collumn is where
ftp-master has to be convinced.

> Once I have written my watch file, and the urepack script, I
>  find that the time being wasted lies in the sub-second range.  Hardly
>  something I worry about, really.

I find the waste of time quite irelevant. Even if unpacking, delete,
repack takes a few minutes for a large package you don't do that often
and only once for each upstream version. And that could probably be
streamlined with importing the source into a VCS and running
pristine-tar. But it means the orig.tar.gz is no longer pristine.

Worst case different debian derivates will each have different
orig.tar.gz files because their rules of what to remove differs.
I would rather have pristine tarballs across the board and different
cleanup code in debian/rules.

> manoj

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tymibvkj@frosties.localdomain

Re: why are there /bin and /usr/bin...

[Goswin von Brederlow]

Christoph Anton Mitterer  writes:

> On Wed, 2010-08-25 at 11:05 +0200, Goswin von Brederlow wrote:
>> We already have the logic in there to mount anything as /.
> Well. at least if it's a very plain setup... (see
> http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices)
>
>>  /usr can't be
>> any harder so that isn't an argument.
> Again,... depending on how complicated this is,... maybe multiple
> stacked block layers, some over network, etc etc. this could require
> much (more) stuff added to the initramfs.

No it doesn't. I could already put my / on lvm on dmcrypt on raid on
dmcrypt on lvm on raid on raid on dmcrypt on lvm. /usr doesn't allow new
modes of stacking.

The hard part is getting stacked layers to work in general. The udev
rules for lvm and mdadm go a long way there. If dmcrypt now also adds
rules (does it already have them? How do you ask for a passphrase from a
udev rule?) arbitrary stacking would be supported at the cost of having
udev in the ramdisk.

MfG
Goswin

PS: I've used / on nbd in the past. Fun.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqx6buz9@frosties.localdomain

Re: For those who care about their packages in Debian

[Marc Haber]

On Wed, 25 Aug 2010 13:42:34 +0100, Ian Jackson
 wrote:
>Perhaps the right answer is to simply ask people to upload
>non-release-related stuff to experimental rather than unstable.  That
>way one can do the itch-scratching right away;

... if apt would finally support wildcards in preferences file's
Package field.

>moving packages from
>experimental to unstable later is easy

Is it possible without rebuilding?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1oohz0-0004ss...@swivel.zugschlus.de

Bug#594360: ITP: dumpet -- dump information about bootable CDs and other similar formats

[Colin Watson]

Package: wnpp
Severity: wishlist
Owner: Colin Watson 


* Package name: dumpet
  Version : 2.0
  Upstream Author : Peter Jones 
* URL : https://fedorahosted.org/dumpet/
* License : GPL-2+
  Programming Lang: C
  Description : dump information about bootable CDs and other similar 
formats

A tool for debugging El Torito boot images.  This can dump the El Torito
structure in various readable output formats.

-- 
Colin Watson   [cjwat...@debian.org]



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100825154330.ga30...@riva.dynamic.greenend.org.uk

Bug#594366: ITP: krazy2 -- KDE source code checker

[José Manuel Santamaría Lema]

Package: wnpp
Severity: wishlist
Owner: José Manuel Santamaría Lema 
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: krazy2
Version: 0
Upstream Author: Allen Winter 
URL: http://www.englishbreakfastnetwork.org/
License: LGPL, MIT/X11 and others.
Description: KDE source code checker
 Krazy scans KDE source code looking for issues that should be fixed
 for reasons of policy, good coding practice, optimization, or any other
 good reason.  In typical use, Krazy simply counts up the issues
 and provides the line numbers where those issues occurred in each
 file processed.
 .
 This package provides the following programs:
  - krazy2 - checks one or various files given in command line
  - krazy2all - checks all supported files under the current directory
  - krazy2xml - a wrapper around krazy to generate results for EBN (see below)
 .
 These programs are being used by official KDE developers to find issues in 
their 
 software, in fact they have a web page (English Breakfast Network a.k.a. EBN)
 which displays the daily results of running these programs against their code,
 see:
 http://www.englishbreakfastnetwork.org/



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201008251815.01702.panfa...@gmail.com

Re: For those who care about their packages in Debian

[Ian Jackson]

Mike Hommey writes ("Re: For those who care about their packages in Debian"):
> On Wed, Aug 25, 2010 at 01:42:34PM +0100, Ian Jackson wrote:
> > Even better would be an option to write something in your .dsc which
> > would cause automatic transfer of your package into unstable when
> > testing is unfrozen.  Distro target of "experimental-unstable"
> > perhaps.  That way we could automate the "flood of new packages and
> > distro is totally broken" effect :-).
> 
> That would obviously require some automated way to propate from
> experimental to unstable, much like unstable->testing transition
> happens, when all deps are available in unstable, etc.

That would be fine.  Perhaps a different copy of the same code,
with all the aging parameters set low, and which only runs on packages
whose .changes said they wanted to be propagated.  But TBH since
everything gets dumped willy-nilly into unstable at unfreeze time
anyway, I doubt it will make much difference.

> IMHO, this would be better to be triggered on maintainer request
> and semi-manually, instead of a distro target.

My point is that it would be nice to be able to arrange _now_ that
this will happen _later_ so that you only have to interact once.  Not
having to constantly poke things and prod them along makes things run
a lot smoother.

Marc Haber writes ("Re: For those who care about their packages in Debian"):
> On Wed, 25 Aug 2010 13:42:34 +0100, Ian Jackson
>  wrote:
> >moving packages from experimental to unstable later [would be] easy
> 
> Is it possible without rebuilding?

I don't see any reason it would be impossible in principle.  The same
is done from unstable to testing, when testing is unfrozen.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19573.16293.951525.378...@chiark.greenend.org.uk

Re: Atlas proposal [and 1 more messages]

[Goswin von Brederlow]

Ian Jackson  writes:

> Goswin von Brederlow writes ("Re: Atlas proposal"):
>> I also have a package "local-archive" that depends on reprepro,
>> generates a local signing key on first install, adds that to the apt-get
>> keyring and adds a file:/// url in /etc/apt/sources.list.d/.
>
> I think this scheme is a very bad idea.  I don't think packages should
> be recursing into the packaging infrastructure this way.  And I think
> automatically adding different local repositories to the apt
> configuration is pretty horrid.

Calling 'dpkg -i' from postinst is impossible due to the locks against
recursion.

Going into background, waiting for dpkg/apt to finish and then calling
dpkg -i is horrible. I often do upgrades in multiple apt calls and then
either my or atlases dpkg -i call would suddenly fail with a lock error.
Unacceptable.

Just dumping the compiled files into /usr/lib/ I find quite unacceptable
too.

So what is left then? Build a deb and tell the admin to dpkg -i it
manually? That is quite horrible on upgrades since you then potentially
need to apt-get -f install to fix the depends and reverse depends. Imho
also unacceptable.


What I described is simple to implement, easy to use and debug and verry
comfortable for the user. The users prefered frontend
(dselect/apt/aptitude/synaptic/adpet/...) will sort out the upgrade to
the new version cleanly and no special invocations of some update script
or manual dpkg calls are required.

The only ugly part I see is dumping a file in /etc/apt/sources.list.d/
and adding the gpg key. You could ask the admin to do that manually but
I found it easier to have it done automatically for me.

>> Using a local archive instead of calling dpkg -i directly avoids the
>> locking issues. It also allows exporting the archive for a pool of
>> systems. No need to build libatlas3gf 200 times for a 200 node cluster.
>
> The build time problem is easily solved by the cluster admin using a
> ccache, if indeed we care.
>
> Having said that:
>
> Josselin Mouette writes ("Re: Atlas proposal"):
>> I beg any FTP master reading this to immediately reject any package
>> doing something as sick as what you just described.
>
> I don't think this is a very friendly way of putting it.  Invoking or
> mentioning escalation is not necessary in what was previously a
> reasonable and technical discussion.
>
> If you dislike Goswin's idea so much you should set out your
> criticisms of it.
>
> Ian.

Esspecially you should say WHY you think it is bad. How else will I
learn anything? It is like proofreading someones book and then only
saying: "You have a typo." That is not helping, that is just pissing
people off.

And please do tell us how to do it better. Even if it is the sickest
thing in the world doesn't mean it can't also the best solution.
Critizising is easy, being constructive is hard.

I think it is the best solution for having the updates compile and
install automatically in a clean way. Now PROVE ME WRONG please.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874oeibpct@frosties.localdomain

Re: Atlas proposal [and 1 more messages]

[Ian Jackson]

Goswin von Brederlow writes ("Re: Atlas proposal [and 1 more messages]"):
> Just dumping the compiled files into /usr/lib/ I find quite unacceptable
> too.

No, it is absolutely fine and it is what atlas-auto should do.  It is
a simple matter for its postinst and postrm to deal with these files
explicitly.

Plenty of other programs fiddle explicitly with files in /usr in their
maintainer scripts.  There is absolutely nothing wrong with that.
/usr/lib is not special in this respect.

> Esspecially you should say WHY you think it is bad. How else will I
> learn anything? It is like proofreading someones book and then only
> saying: "You have a typo." That is not helping, that is just pissing
> people off.

I was just asking Jossellin to be polite to you, and now I'm
disappointed to see that you seem to be being rude and shouty back.
Perhaps it's not deliberate, but writing in capitals like that really
comes across very badly.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19573.22250.855604.722...@chiark.greenend.org.uk

Re: list of packages that FTBFS on i386

[Cyril Brulebois]

Kamaraju S Kusumanchi  (25/08/2010):
> How do I obtain a list of packages that have FTBFS bugs filed on
> them and that are currently failing to build on i386 architecture?

https://buildd.debian.org/status/architecture.php?a=i386&suite=unstable

Click “Failed”. Usually, you get a “failing reason” which is a bug
number, which gets automatically transformed into the relevant bug on
the BTS. That should get you started.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: [poll] Ubuntu column on DDPO visible by default?

[Ana Guerrero]

On Tue, Aug 03, 2010 at 11:19:06AM -0400, Lucas Nussbaum wrote:
> On 01/08/10 at 17:00 -0400, Lucas Nussbaum wrote:
> > Hi,
> > 
> > There's an Ubuntu column on http://qa.debian.org/developer.php, but it
> > is hidden by default, so many people ignore it exists.
> > 
> > I propose to make it visible by default. Developers would still be able
> > to hide it by editing their options (and there's a cookie to register
> > that choice).
> > 
> > I've set up a doodle poll to see what people think. Please contribute on
> > http://www.doodle.com/5yqgqnrxhiha2nzm
> 
> Results: 15 votes, 10 for making it visible by default, 5 against, and
> nobody cared enough to start a flamewar on debian...@.
> 
> So I'm making it visible by default now.

uhm, I don't think a 2 days poll is long enough... I also have seen more
people disagreeing that agreeing in the thread in -qa, maybe it is better
to ask to a wider audience?

About the change, I think caring about the status in Ubuntu should be 
something you choose and not something that is thrown at you by default
whether you want it or not. Could you please revert this?

Ana


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100825215120.gb14...@ekaia.org

Re: [poll] Ubuntu column on DDPO visible by default?

[Lucas Nussbaum]

Hi,

On 25/08/10 at 23:51 +0200, Ana Guerrero wrote:
> On Tue, Aug 03, 2010 at 11:19:06AM -0400, Lucas Nussbaum wrote:
> > On 01/08/10 at 17:00 -0400, Lucas Nussbaum wrote:
> > > Hi,
> > > 
> > > There's an Ubuntu column on http://qa.debian.org/developer.php, but it
> > > is hidden by default, so many people ignore it exists.
> > > 
> > > I propose to make it visible by default. Developers would still be able
> > > to hide it by editing their options (and there's a cookie to register
> > > that choice).
> > > 
> > > I've set up a doodle poll to see what people think. Please contribute on
> > > http://www.doodle.com/5yqgqnrxhiha2nzm
> > 
> > Results: 15 votes, 10 for making it visible by default, 5 against, and
> > nobody cared enough to start a flamewar on debian...@.
> > 
> > So I'm making it visible by default now.
> 
> uhm, I don't think a 2 days poll is long enough... I also have seen more
> people disagreeing that agreeing in the thread in -qa, maybe it is better
> to ask to a wider audience?

Maybe (as often) only the ones disagreeing decided to participate in the
thread on -...@? Also, the thread has been silent since the end of
Debconf, so I'm quite surprised this come up now.

> About the change, I think caring about the status in Ubuntu should be 
> something you choose and not something that is thrown at you by default
> whether you want it or not. Could you please revert this?

I think that the poll made it clear that a large majority of people on
-qa@ were in favor of the change. With such a minor change (disabling it
permanently for you is three clicks away -- Display config - Hide -
Submit), I think that a short poll on -qa@ was enough.

But if you disagree and want to start that discussion again, feel free
to start a poll on reverting the change in a wider audience, and with
the duration you consider appropriate. (When the details are ready, I
would prefer if you asked me beforehand if I also consider the poll
setup appropriate, so we don't get into a "my poll is more correct than
yours" problem.)

- Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100825220854.ga27...@xanadu.blop.info

Re: [poll] Ubuntu column on DDPO visible by default?

[Ana Guerrero]

On Thu, Aug 26, 2010 at 12:08:54AM +0200, Lucas Nussbaum wrote:
> 
> Maybe (as often) only the ones disagreeing decided to participate in the
> thread on -...@? Also, the thread has been silent since the end of
> Debconf, so I'm quite surprised this come up now.
>

You sent the email in a very bad time, some people were (and still are) 
in holidays and for some people keeping up to date in reading email 
while DebConf is challenging :) 
Answering an email 3 weeks later is not late, sometimes you are busy in 
a given time and answering in a hurry is never a good idea.

> > About the change, I think caring about the status in Ubuntu should be 
> > something you choose and not something that is thrown at you by default
> > whether you want it or not. Could you please revert this?
> 
> I think that the poll made it clear that a large majority of people on
> -qa@ were in favor of the change. With such a minor change (disabling it
> permanently for you is three clicks away -- Display config - Hide -
> Submit), I think that a short poll on -qa@ was enough.
> 

Sorry, 20 voters does not look a big sample and 12 ok over 8 no-ok is not a 
large majority (60 %)

> But if you disagree and want to start that discussion again, feel free
> to start a poll on reverting the change in a wider audience, and with
> the duration you consider appropriate. (When the details are ready, I
> would prefer if you asked me beforehand if I also consider the poll
> setup appropriate, so we don't get into a "my poll is more correct than
> yours" problem.)

I don't think we should do a poll to decide this, we should discuss and
allow people to give arguments why they like the idea or not. You need to
give more than 2 days for that.

And please, do not say people has not complained in 3 weeks since you
made the change as an excuse, nobody complained neither about this
not being enabled by default in all the many months that information was 
there.

I remember people complained about the ubuntu column when it was enabled 
firstly and the agreed solution there was turning it off by default.

Ana


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100825223257.ga14...@pryan.ekaia.org

Re: Seeking fellow developers feedback for iceweasel in squeeze (transient homepage & upgrade notification)

[Adam Borowski]

On Wed, Aug 25, 2010 at 03:08:59PM +0200, Mike Hommey wrote:
> > - Improve or remove the restart popup that shows up when upgrading the
> >   package.

One of the issues: the notification is shown when the upgrade starts, not
when it's actually done.  This is especially bad when several dependant
packages get updated.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100825225157.ga26...@angband.pl

Re: list of packages that FTBFS on i386

[Kamaraju S Kusumanchi]

Cyril Brulebois wrote:

> Kamaraju S Kusumanchi  (25/08/2010):
>> How do I obtain a list of packages that have FTBFS bugs filed on
>> them and that are currently failing to build on i386 architecture?
> 
> https://buildd.debian.org/status/architecture.php?a=i386&suite=unstable
> 
> Click “Failed”. Usually, you get a “failing reason” which is a bug
> number, which gets automatically transformed into the relevant bug on
> the BTS. That should get you started.
> 

Thanks Cyril and Lucas. That is very helpful.

raju
-- 
Kamaraju S Kusumanchi
http://malayamaarutham.blogspot.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/i5470d$gv...@dough.gmane.org

unstable-proposed-updates (was: For those who care about their packages in Debian)

[Carsten Hey]

* Ian Jackson [2010-08-25 13:42 +0100]:
> Perhaps the right answer is to simply ask people to upload
> non-release-related stuff to experimental rather than unstable.  That
> way one can do the itch-scratching right away; moving packages from
> experimental to unstable later is easy ...
>
> Even better would be an option to write something in your .dsc which
> would cause automatic transfer of your package into unstable when
> testing is unfrozen.  Distro target of "experimental-unstable"
> perhaps.  That way we could automate the "flood of new packages and
> distro is totally broken" effect :-).

I thought about something like this a while ago and would have called it
'unstable-proposed-updates'.  Currently experimental is used for both,
experimental packages and packages the should go to unstable in future,
a new suite to split this would it make possible to differentiate
between really experimental and other packages.

Possible advantages of having unstable-proposed-updates:

 * During a freeze, people could continue to upload new versions without
   the need to use t-p-u if they need to get fixes to testing. For
   example, this would have prevented a broken libpam-mount from
   entering lenny during freeze.  A (semi?) automatic migration to
   unstable after the freeze (maybe in batches) would save the
   maintainers some work.  Maintainers could still use experimental
   instead for their packages if they don't like this automatism.

 * CUT could get updates through u-p-u instead of unstable during freeze
   (currently unstable often misses new upstream versions in that time
   and alternatively letting packages migrate from experimental wouldn't
   be the best idea because some of the packages could really be
   experimental).

 * Maybe it could also be helpful to coordinate transitions, the release
   team would then just move packages from u-p-u to unstable when they
   think it is the right time.  Additionally they could set triggers
   that would automatically move specific packages to u-p-u instead of
   unstable when they are uploaded.  The release team knows best if this
   would help them ;)


* Russ Allbery [2010-08-25 01:13 -0700]:
> Yves-Alexis Perez  writes:
> > Would it be possible (at one point) to “fix” it and stop using
> > unstable as t-p-u and experimental as unstable when freeze is in
> > action?
>
> We could try to get lots of people who normally use unstable to
> instead test testing plus t-p-u, but I'm not sure they'd be willing to
> do so.  I for example don't want to switch my unstable systems to
> testing plus t-p-u for a variety of reasons.

I think this point is important, people will not switch to the
distribution we think they should use in specific release phases. This
is also the reason why I don't think things like adding another
distribution between stable and testing or testing and unstable would
have the desired effect.  Instead we should ensure that what we have
(testing and unstable) contains what we want most of our non-stable
users to use and test.

If there would be a good reason to add t-p-o or u-p-o to their
sources.list, then I think some users would do so, but I expect this
still to be the minority.  One such reason to add u-p-o could be that
they want to use newer software than what is currently available in
unstable.


Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100825232007.ga20...@foghorn.stateful.de

Re: For those who care about their packages in Debian

[Chris]

On Wed, 25 Aug 2010 02:09:03 +0100
Ben Hutchings  wrote:

> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze.  The sooner squeeze is out, the sooner you can
> add stuff to the next release.
> 
> Ben.
> 

Greetings everyone,

I admit, I am still very new to this process.
If I can, I would be glad to help out during the Freeze process
if any kind soul would be willing to discuss this off list with me.

Again, I am limited but willing to do and learn.


-- 
Best regards,

Chris
1AB5FEF8


signature.asc
Description: PGP signature

Re: For those who care about their packages in Debian

[Ben Finney]

Chris  writes:

> I admit, I am still very new to this process.
> If I can, I would be glad to help out during the Freeze process
> if any kind soul would be willing to discuss this off list with me.

For the benefit of readers of debian-devel who don't read
debian-mentors:

I already replied to Chris in debian-mentors, where IMO his discussion
belongs.

-- 
 \   “Everything you read in newspapers is absolutely true, except |
  `\for that rare story of which you happen to have first-hand |
_o__) knowledge.” —Erwin Knoll |
Ben Finney


pgpeuDqclFgwY.pgp
Description: PGP signature

Re: Activating t-p-u by default (was: Re: For those who care about their packages in Debian)

[Paul Wise]

On Wed, Aug 25, 2010 at 6:38 PM, Christian PERRIER  wrote:
> Quoting Russ Allbery (r...@debian.org):
>
>> > Hmhm, out of curiosity, why is t-p-u “way riskier”.
>>
>> Mostly because there isn't any large pool of systems using t-p-u the way
>> there is for unstable, so the aging process where we get testing in
>> unstable before migrating the package never happens.  This means uploads
>
> I wonder whether we (in D-I) could add t-p-u to the list of proposed
> repositories when users install testing. We already propose security
> and volatile (defaulting to both added): the same mechanism could be
> made for t-p-u when users install testing.

Sounds like a good idea to me. When they reject t-p-u you could either
add it commented out or with pinning such that it is not selected by
default but when packages from it are selected then they are kept
upgraded within it until the packages migrate to testing itself. AFAIK
to achieve that you need pinning priorities > 500 and < 1000.

-- 
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
Archive: 
http://lists.debian.org/aanlktinbf2ktsg7ppwmv4cnz74wvhdj2vkfq3n9wf...@mail.gmail.com

Dicas de Segurança

[cat]

Recebi e estou repassando...
dicas valiosas de como evitar os roubos e assaltos, repassem para seus 
seguidores... 
assista o video em >>> 
http://www.youtube.com/watch?v=u3DLbvIOR4o&feature=player_embedded
Fiquem com Deus
Aline Ferraz
São Paulo/SP.

Re: [poll] Ubuntu column on DDPO visible by default?

[Lucas Nussbaum]

On 26/08/10 at 00:32 +0200, Ana Guerrero wrote:
> On Thu, Aug 26, 2010 at 12:08:54AM +0200, Lucas Nussbaum wrote:
> > > About the change, I think caring about the status in Ubuntu should be 
> > > something you choose and not something that is thrown at you by default
> > > whether you want it or not. Could you please revert this?
> > 
> > I think that the poll made it clear that a large majority of people on
> > -qa@ were in favor of the change. With such a minor change (disabling it
> > permanently for you is three clicks away -- Display config - Hide -
> > Submit), I think that a short poll on -qa@ was enough.
> > 
> 
> Sorry, 20 voters does not look a big sample and 12 ok over 8 no-ok is not a 
> large majority (60 %)

After I announced the results, someone started asking people to vote
anyway if they were against the result. Nobody asked those that were in
favor to continue voting. If you look at the results, the first 15 votes
are the results I announced on -...@.

> I remember people complained about the ubuntu column when it was enabled 
> firstly and the agreed solution there was turning it off by default.

You can't please everybody. Some people are happy with the change, some
people are against the change, and the people against the change agreed
that it should be turned off by default. However, according to the poll,
a large majority (10 for, 5 against, including an anonymous voter -- you
might want to find a way to fix that in your poll) apparently preferred
to have it enabled by default.

I don't see what a discussion on -devel@ would bring. We are unlikely to
come up with a better choice of solutions than what we already have
(keep it on by default, revert the change and make it disabled by
default).

- Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100826054207.ga29...@xanadu.blop.info