Re: Introducing http.debian.net, Debian's mirrors redirector

[Philipp Kern]

shirish,

am Fri, Jun 22, 2012 at 09:33:34AM +0530 hast du folgendes geschrieben:
> Another thing which is puzzling is that stable inRelease is ignored. I
> dunno if this was before  and I'm realizing it now or it's due to the
> use of mirror redirector or something else. I do recall stable
> inRelease doing well. Anyways, this is what I'm a bit concerned about
> as well.

there should be no InRelease for stable. It's not needed given that stable
basically doesn't change and didn't support two signatures at some point.

So that's ok and fine.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: build-time testing of pure arch:all packages

[Stefano Zacchiroli]

On Fri, Jun 22, 2012 at 12:29:48AM -0400, Yaroslav Halchenko wrote:
> I was thinking about a bit more automated way... ideally (in the long
> run) even that FTBFS (e.g. due to failed tests or some other arch
> specific quirks) would forbid automatic migration  to wheezy etc --
> kinda full blown benefits from the Debian infrastructure  without
> much of work from my side ;)

Did you check if the QA rebuilds try to, or could be asked to, build
arch:all packages? If so, it'd be a good start to routinely do
archive-wide rebuilds of arch:all packages as we routinely do rebuilds
of arch:any packages.

(Cc:-ing Lucas, for his great work on QA rebuilds.)

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Announce: script to automatically restart services after update of dependencies

[Goswin von Brederlow]

Ben Hutchings  writes:

> On Thu, Jun 21, 2012 at 11:16:51AM +0200, Goswin von Brederlow wrote:
>> Ben Hutchings  writes:
>> 
>> > On Tue, 2012-06-19 at 15:29 +0300, Eugene V. Lyubimkin wrote:
>> >> Hello,
>> >> 
>> >> On 2012-06-19 13:59, Tomas Pospisek wrote:
>> >> > This implies that an "apt-get install library" needs to trigger that
>> >> > restart.
>> >> > Which means that apt-get needs to depend on restart-services. So either
>> >> > restart-services and checkrestart should go into the apt package, or apt
>> >> > needs
>> >> > to depend on/recommend debian-goodies, which would currently pull in
>> >> > python,
>> >> > perl, curl, dialog and their respective dependencies.
>> >> > 
>> >> > The later may be a technically working solution, but from a conceptual 
>> >> > and
>> >> > a
>> >> > KISS point of view doesn't make sense to me.
>> >> > 
>> >> > Is my conclusion correct so far?
>> >> > 
>> >> > So if we want a "clean" solution, then checkrestart/restart-services 
>> >> > would
>> >> > need
>> >> > to move into apt and get rid of the non-essential dependencies (get
>> >> > rewritten in
>> >> > shell or C).
>> >> 
>> >> I believe this is a wrong layer for proposed functionality -- apt-get
>> >> (libapt) is not the only high-level package manager for Debian.
>> >>
>> >> If I were you, I'd look into dpkg file triggers instead. Triggers will
>> >> by the way automatically solve the problem that you don't restart
>> >> a service 5 times if 5 libraries were upgraded.
>> >
>> > But we still need one trigger per service?  I don't think that's a good
>> > idea.
>> >
>> > Ben.
>> 
>> Do you? Why not a trigger that calls checkrestart?
>  
> I was thinking we would need a file trigger per service, which is
> activated automatically (requires changing all service packages);
> or an explicit trigger, which is activated by each library postinst
> (requires changing all library packages).
>
> Are you suggesting a file trigger on /lib and /usr/lib?  It seems
> inefficient as I think the triggered postinst would have to check
> *all* libraries, but I suppose it would work.  And presumably this is
> no worse than what checkrestart does now.
>
> Ben.

Yes, a single file trigger for /lib and /usr/lib. Unfortunately dpkg
does not tell the trigger what files have changed so indeed it would have
to check all libraries if you go that way.

If we go with an opt-in model then I would have services drop a file in
/usr/share/checkrestart/ listing the binaries (or pidfiles) that need to
be checked, look up the pid of any running instance and then check if it
has any deleted libraries in use.

This could also be part of the LSB header of init scripts or a comment
in the upstart/systemd config instead of
/usr/share/checkrestart/.


Another idea would be to extend start-stop-daemon (upsstart / systemd)
to have a new option --respawn. This would do two things: 1) monitor the
child and restart a service that dies unexpectadly. 2) register the
daemon for checkrestart.  In that case start-stop-daemon would come with
an dpkg trigger to check and do the restarts.

This would be an opt-in though. Using checkrestart + blacklist would be
opt-out and would give more imediate results.

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/87ipejloxp.fsf@frosties.localnet

Re: Is it possible to run autopkgtest without a virtual machine ?

[Charles Plessy]

Le Fri, Jun 22, 2012 at 01:24:43PM +0900, Charles Plessy a écrit :
> 
> adt-run needs a virtual machine.  I know that some developers have
> some workarounds, but couldn't autopkgtest also support running tests on the 
> local
> system ?  This would be tremendously useful when the tests can be contained in
> the binary packages, as it would make it very easy for our users and ourselves
> to test the packages.

Thanks to Michael's hint, I found that the following command will work locally.

sudo adt-run --no-built-binaries foo.dsc --- adt-virt-null

(See https://lists.debian.org/debian-devel/2012/06/msg00501.html )

I guess that the next step is to let autopkgtest run as a user
(http://bugs.debian.org/648148), make it easier to invoke (adt-virt-null is not
mentionned in the manual page, and even with --no-built-binaries it still tries
to download some stuff or create a GPG key), and give it a more user-friendly
output.

For people with free time, that would probably be high-impact contribution.  I
will add more autopkgtest to my packages, and would love to be able to tell to
our users a simple command to test if the package is working on their system.

Have a nice week-end,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20120622084616.ga30...@falafel.plessy.net

Re: build-time testing of pure arch:all packages

[Goswin von Brederlow]

Stefano Zacchiroli  writes:

> On Fri, Jun 22, 2012 at 12:29:48AM -0400, Yaroslav Halchenko wrote:
>> I was thinking about a bit more automated way... ideally (in the long
>> run) even that FTBFS (e.g. due to failed tests or some other arch
>> specific quirks) would forbid automatic migration  to wheezy etc --
>> kinda full blown benefits from the Debian infrastructure  without
>> much of work from my side ;)

You can do this in a not so nice way like this:

1) if you have no Architecture: any package then add a
-test-logs package.
2) build-arch depends on build-indep (i.e. always compile the arch:all
   stuff)
3) in build-arch run the tests and include the log in the
   Architecture:any package

This adds a stupid dummy package to the archive that nobody but you need
or fattens up an existing one with a logfile nobody but you need. That
is the not so nice part. But it would do what you want now.

Note: Consider carefully if it wouldn't make more sense to help build a
real automatic testing infrastructure (which could reuse idle
buildd). How urgently do you need those tests to be run?

> Did you check if the QA rebuilds try to, or could be asked to, build
> arch:all packages? If so, it'd be a good start to routinely do
> archive-wide rebuilds of arch:all packages as we routinely do rebuilds
> of arch:any packages.
>
> (Cc:-ing Lucas, for his great work on QA rebuilds.)

Are archive wide rebuilds done on anythiong but i386/amd64?

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/87bokblo6o.fsf@frosties.localnet

Re: Is it possible to run autopkgtest without a virtual machine ?

[Goswin von Brederlow]

Charles Plessy  writes:

> Dear all,
>
> I think that the idea behind autopkgtest (DEP 8) is very interesting, and 
> could
> eventually replace build-time regression tests.  To train myself, I tried to
> implement simple tests for the tabix package.
>
> However, adt-run needs a virtual machine.  I know that some developers have
> some workarounds, but couldn't autopkgtest also support running tests on the 
> local
> system ?  This would be tremendously useful when the tests can be contained in
> the binary packages, as it would make it very easy for our users and ourselves
> to test the packages.
>
> Have a nice day,

I think test should be run in a container (or VM) but never the local
system itself. The absolute minimum would be a chroot but a container
would give better control over things like networking.

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/877guzlnxv.fsf@frosties.localnet

The future (or non-future) of ia32-libs

[Goswin von Brederlow]

Hi,

two weeks ago we hit a huge milestone with multiarch and wine:i386
became installable on amd64. Last week we hit another milestone so that
ia32-libs became mostly installable (it might still want to remove some
amd64 packages in the process depending on what you have installed).

As a consequence I've already uploaded an ia32-libs transitional package
[1], currently in NEW, that will allow ia32-libs users to easily switch
to multiarch. The transitional package can be removed when nothing
depends on it anymore and ends the nightmare of ia32-libs for good.

But the work is not done yet. There are still some bugs left to fix for
the full multiarch experience:

#677741 ia32-libs: Multiarch issues
---
#677735 freeglut: Please add multiarch support
#675797 sane-utils: should be Multi-Arch: foreign
#651475 isdnutils: support Multi-Arch
#677733 xcb-util-renderutil: Please add multiarch support

And then there is also ia32-libs-gtk [2], which is not yet installable as
multiarch:

#677762 ia32-libs-gtk: Multiarch issues
---
#677787 gtk2-engines-xfce: Please add multiarch support
#677788 lesstif2: Please add multiarch support
#650777 libgnomecanvas: Please mark libgnomecanvas-common Multi-Arch: foreign
#676914 libsasl2-2: binNMU broke multi-arch installability
#650787 libglade2: Please transition libglade2 for multiarch
#676918 libsasl2-2:amd64: Package is MA-same, but changelog differs between 
architectures after binNMU
#641614 libidl: please convert to multiarch
#641615 orbit2: Please convert to multiarch
#677786 libwmf: Please add multiarch support
#68 libbonobo: Please add multiarch support
#69 at-spi: Please add multiarch support

Any help NMUing (if not already in delayed) those package would be
apreciated. If we can get those bugs fixed in the next week then 99% of
the multiarch needs for amd64 will be covered.

If you do test those packages and find other bugs then please report
them set them as blocking the respective meta bug (#677741 or #677762).
Those bugs should also be usertagged with:

  user: multiarch-de...@lists.alioth.debian.org
  usertags: multiarch

That way they count towards the multiarch release goal [3] and show up
on the QA page of the relevant package as blocking that goal.



Dear Release Team,

ia32-libs now builds 2 transitional packages: ia32-libs:amd64 and
ia32-libs-i386:i386. The former depends on the later and the later
depends on all the 32bit libraries that ia32-libs used to contain. This
means that the dependencies of ia32-libs:amd64 are not fullfillable in
amd64 and the package will need some big hammer to get it past britney
into testing, as previosuly discussed.

Upgrading from squeeze to wheezy also needs 3 steps and should be
documented in the release notes. This applies to ia32-libs,
ia32-libs-gtk, wine, any other 32bit stuff for amd64 that switches to
multiarch.

Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
Step 2: dpkg --add-architecture i386 && apt-get update
Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)

Help from some native english speaker to write something for the release
notes would be welcome.

MfG
Goswin

[1] 
http://mentors.debian.net/debian/pool/main/i/ia32-libs/ia32-libs_20120616.dsc
[2] 
http://mentors.debian.net/debian/pool/main/i/ia32-libs-gtk/ia32-libs-gtk_20120616.dsc
[3] http://wiki.debian.org/ReleaseGoals/MultiArch


-- 
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/87395nlmgb.fsf@frosties.localnet

Re: The future (or non-future) of ia32-libs

[Marco d'Itri]

On Jun 22, Goswin von Brederlow  wrote:

> Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
> Step 2: dpkg --add-architecture i386 && apt-get update
> Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)
Maybe this is easier?

1: upgrade dpkg and apt
2: dpkg --add-architecture i386 && apt-get update
3: dist-upgrade as usual

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: build-time testing of pure arch:all packages

[Lucas Nussbaum]

Hi,

On 22/06/12 at 09:37 +0200, Stefano Zacchiroli wrote:
> On Fri, Jun 22, 2012 at 12:29:48AM -0400, Yaroslav Halchenko wrote:
> > I was thinking about a bit more automated way... ideally (in the long
> > run) even that FTBFS (e.g. due to failed tests or some other arch
> > specific quirks) would forbid automatic migration  to wheezy etc --
> > kinda full blown benefits from the Debian infrastructure  without
> > much of work from my side ;)
> 
> Did you check if the QA rebuilds try to, or could be asked to, build
> arch:all packages? If so, it'd be a good start to routinely do
> archive-wide rebuilds of arch:all packages as we routinely do rebuilds
> of arch:any packages.
> 
> (Cc:-ing Lucas, for his great work on QA rebuilds.)

In my archive rebuilds, I rebuild arch:all packages and file bugs when
they fail to build (see the large amount of bugs filed against perl
modules due to test suites failures).

Those rebuilds happen once or twice a month on average.

  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/20120622111957.ga32...@xanadu.blop.info

Re: build-time testing of pure arch:all packages

[Lucas Nussbaum]

On 22/06/12 at 10:56 +0200, Goswin von Brederlow wrote:
> Are archive wide rebuilds done on anythiong but i386/amd64?

A long time ago, I played with archive rebuilds inside qemu for mips or
mipsel. It is probably doable, but needs someone to do the work.

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/20120622112121.gb32...@xanadu.blop.info

Bug#678519: general: after about 1 month of uptime, routing of IPv6 packets is no longer possible, and IPv4 routing becomes slow and unpredictable. Rebooting brings all functionality back, and back to

[Rudy Zijlstra]

Package: general
Severity: important
Tags: ipv6

let system run with IPv4 & IPv6 routing for about 1 month
> IPv6 routing will start to fail
> IPv4 routing becomes slow and unpredictable

no obvious causes visible in the system. top and friends do not show a cpu hog

a reboot will bring the system back to normal behaviour. 

-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/20120622115937.1905.22529.report...@janus.office.romunt.nl

Bug#678519: general: after about 1 month of uptime, routing of IPv6 packets is no longer possible, and IPv4 routing becomes slow and unpredictable. Rebooting brings all functionality back, and back to

[Roberto C . Sánchez]

On Fri, Jun 22, 2012 at 01:59:37PM +0200, Rudy Zijlstra wrote:
> Package: general
> Severity: important
> Tags: ipv6
> 
> let system run with IPv4 & IPv6 routing for about 1 month
> > IPv6 routing will start to fail
> > IPv4 routing becomes slow and unpredictable
> 
> no obvious causes visible in the system. top and friends do not show a cpu hog
> 
> a reboot will bring the system back to normal behaviour. 
> 
Could this be something to do with connection tracking?

Regards,

-Roberto
-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: The future (or non-future) of ia32-libs

[Thomas Goirand]

On 06/22/2012 05:34 PM, Goswin von Brederlow wrote:
> Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
> Step 2: dpkg --add-architecture i386 && apt-get update
> Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)
>   
May I suggest that upon upgrade, we have a debconf message telling
about it? We could add this in base-files or any essential package,
probably one with some debconf messages already in would be a better
pick. Instructions would show, IF ia32-libs old version is currently
installed
AND the --add-architecture i386 hasn't bee done.

I know we have release notes, but some don't know about them or would
simply not read them. A debconf message seem really appropriate IMO.
Something along with:

> It appears that you have an old version of ia32-libs installed in your
> system. Debian now supports multi-arch, and the new version of
> ia32-libs (a transitional package) uses and needs this new feature.
> .
> In order to upgrade the version of ia32-libs in your system, you will
> need to do:
>dpkg --add-architecture i386
>apt-get update
>apt-get dist-upgrade
>
> Until you do this, upgrades of ia32-libs and packages depending on
> it (wine, other examples, etc.) will not be possible. More information
> about this available at: https://wiki.debian.org/

I'm ok to contribute a small patch doing this.
Thoughts? Any English guy to propose a better wording?

Cheers,

Thomas


-- 
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/4fe473df.8000...@debian.org

Bug#678519: general: after about 1 month of uptime, routing of IPv6 packets is no longer possible, and IPv4 routing becomes slow and unpredictable. Rebooting brings all functionality back, and back to

[Rudy Zijlstra]

On 22-06-12 15:04, Roberto C. Sánchez wrote:

On Fri, Jun 22, 2012 at 01:59:37PM +0200, Rudy Zijlstra wrote:

Package: general
Severity: important
Tags: ipv6

let system run with IPv4&  IPv6 routing for about 1 month

IPv6 routing will start to fail
IPv4 routing becomes slow and unpredictable

no obvious causes visible in the system. top and friends do not show a cpu hog

a reboot will bring the system back to normal behaviour.


Could this be something to do with connection tracking?

Regards,

-Roberto
Both IPv4 and IPv6 are impacted, which have separate iptables. IPv6 
routing gets fully blocked, IPv4 goes slow and unpredictable.


How could i check any relation to connection tracking?

cheers,


Rudy



--
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/4fe46f3c.9040...@grumpydevil.homelinux.org

Re: The future (or non-future) of ia32-libs

[Roger Leigh]

On Fri, Jun 22, 2012 at 09:32:15PM +0800, Thomas Goirand wrote:
> On 06/22/2012 05:34 PM, Goswin von Brederlow wrote:
> > Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
> > Step 2: dpkg --add-architecture i386 && apt-get update
> > Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)
> >   
> May I suggest that upon upgrade, we have a debconf message telling
> about it? We could add this in base-files or any essential package,
> probably one with some debconf messages already in would be a better
> pick. Instructions would show, IF ia32-libs old version is currently
> installed
> AND the --add-architecture i386 hasn't bee done.
> 
> I know we have release notes, but some don't know about them or would
> simply not read them. A debconf message seem really appropriate IMO.

Could we not introduce the concept of an "upgrade script" into
apt-get which could be downloaded when you run "apt-get update" and
then run during a dist-upgrade?  This could handle automation of
any "housekeeping" during the upgrade which would otherwise require
manual work detailed in the release notes.

For example, if the ia32-libs package is installed, this could
automatically update dpkg and apt-get, then automatically add the
architecture and update prior to continuing with the upgrade.  It
could also handle any additional work which needs doing before and
after the upgrade of the whole distribution, or any particular
package.  i.e. handling any work which the package maintainer
scripts can't safely or sensibly handle.

Doesn't the Ubuntu updater tool do something like this already when
it does a full upgrade between releases?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120622143137.gf9...@codelibre.net

Re: The future (or non-future) of ia32-libs

[Adam D. Barratt]

On 22.06.2012 15:31, Roger Leigh wrote:

On Fri, Jun 22, 2012 at 09:32:15PM +0800, Thomas Goirand wrote:

On 06/22/2012 05:34 PM, Goswin von Brederlow wrote:
> Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
> Step 2: dpkg --add-architecture i386 && apt-get update
> Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)

[...]
I know we have release notes, but some don't know about them or 
would

simply not read them. A debconf message seem really appropriate IMO.


Could we not introduce the concept of an "upgrade script" into
apt-get which could be downloaded when you run "apt-get update" and
then run during a dist-upgrade?  This could handle automation of
any "housekeeping" during the upgrade which would otherwise require
manual work detailed in the release notes.


As a theoretical future enhancement, possibly.  That won't help for 
squeeze to wheezy upgrades though, as squeeze's apt would need to 
include support for it.


Regards,

Adam


--
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/c0411bd3da03f0beef873e944da54...@mail.adsl.funky-badger.org

Re: build-time testing of pure arch:all packages

[Yaroslav Halchenko]

On Fri, 22 Jun 2012, Goswin von Brederlow wrote:
> >> I was thinking about a bit more automated way... ideally (in the long
> >> run) even that FTBFS (e.g. due to failed tests or some other arch
> >> specific quirks) would forbid automatic migration  to wheezy etc --
> >> kinda full blown benefits from the Debian infrastructure  without
> >> much of work from my side ;)

> You can do this in a not so nice way like this:

> 1) if you have no Architecture: any package then add a
> -test-logs package.
> 2) build-arch depends on build-indep (i.e. always compile the arch:all
>stuff)
> 3) in build-arch run the tests and include the log in the
>Architecture:any package

> This adds a stupid dummy package to the archive that nobody but you need
> or fattens up an existing one with a logfile nobody but you need. That
> is the not so nice part. But it would do what you want now.

Thank you Goswin for detailing my evil non-archive-friendly option ;-)

> Note: Consider carefully if it wouldn't make more sense to help build a
> real automatic testing infrastructure (which could reuse idle
> buildd). How urgently do you need those tests to be run?

Thanks for asking -- there is no urgency per se.  One of the issues in
nibabel was triggered by nipy build (failure is still there [1]) so we
exercised it and upstream has it already fixed (release/upload will
follow shortly).   But my email came out of wondering how many of other
arch:all packages we have in the archive without such a build-time
QA, thus possibly broken on exotic ports.

[1] https://buildd.debian.org/status/package.php?p=nipy

> > archive-wide rebuilds of arch:all packages as we routinely do rebuilds
> > of arch:any packages.
> > (Cc:-ing Lucas, for his great work on QA rebuilds.)
> Are archive wide rebuilds done on anythiong but i386/amd64?

IMHO if archive-wide rebuild could be carried on at least one
representative big-endian architecture (e.g. sparc) -- it might already
be quite useful. 

Do we also have some time share on one of the top3 HPC boxes [2] +
Lucas#2 to take care about it?  ;-)

[2] http://en.wikipedia.org/wiki/TOP500

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


-- 
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/20120622151951.gf5...@onerussian.com

Re: Report from the Bug Squashing Party in Salzburg

[Philip Ashmore]

On 22/06/12 07:12, Thomas Goirand wrote:

On 06/21/2012 10:39 PM, Jon Dowland wrote:

Fair enough - but let's not lob hand grenades at people who might find it
useful. Let them get on with it if they want to.


Sorry, but it's fair enough to "lob hand grenades" at people suggesting
non open source solutions, useful or not. Feel free to get on them if you
wish, but please do not suggest it inside Debian.

Thomas

Huh.
So physically travelling to a potentially distant location for a bug 
squash is the Debian way?


Anyway, I'd like to see something like http://www.bigbluebutton.org/ but 
with multiple participants, be it Google+ or something else that can do 
that.


I know that one useful aspect of IRC is the ability to archive and 
review the session, so it should have that feature too.


I must admit I have something in mind for the future that will fit this 
requirement, so anything out there that comes close is of interest to me.


Regards,
Philip Ashmore


--
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/4fe4a49d.5040...@philipashmore.com

Re: Summary: Moving /tmp to tmpfs makes it useless

[Andrei POPESCU]

On Mi, 20 iun 12, 15:18:55, Stephan Seitz wrote:
> 
> Fine let’s talk. Why can’t we find a compromise? Additional to our
> disk /tmp we create a /ramtmp (so the name suggests that this tmp is
> a ramdisk) with tmpfs. This should be doable in time for Wheezy. The
> release notes should mention it. And those who wish can patch their
> programs to use the ramdisk if they think their program uses only
> small temporary files. In this way, we get some data and experience.
> And we have both worlds. /tmp on disk for even large temporary files
> and /ramtmp as fast ramdisk.

Why not use /run instead?

Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: The future (or non-future) of ia32-libs

[Luk Claes]

On 06/22/2012 04:31 PM, Roger Leigh wrote:
> On Fri, Jun 22, 2012 at 09:32:15PM +0800, Thomas Goirand wrote:
>> On 06/22/2012 05:34 PM, Goswin von Brederlow wrote:
>>> Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
>>> Step 2: dpkg --add-architecture i386 && apt-get update
>>> Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)
>>>   
>> May I suggest that upon upgrade, we have a debconf message telling
>> about it? We could add this in base-files or any essential package,
>> probably one with some debconf messages already in would be a better
>> pick. Instructions would show, IF ia32-libs old version is currently
>> installed
>> AND the --add-architecture i386 hasn't bee done.
>>
>> I know we have release notes, but some don't know about them or would
>> simply not read them. A debconf message seem really appropriate IMO.
> 
> Could we not introduce the concept of an "upgrade script" into
> apt-get which could be downloaded when you run "apt-get update" and
> then run during a dist-upgrade?  This could handle automation of
> any "housekeeping" during the upgrade which would otherwise require
> manual work detailed in the release notes.

Hmm, I'm not a fan of upgrade scripts at all. Either it's easy enough to
automate in maintainerscripts or it should get careful review for the
context in which it will be applied IMHO (which means the sysadmin can
run the shipped script manually).

> For example, if the ia32-libs package is installed, this could
> automatically update dpkg and apt-get, then automatically add the
> architecture and update prior to continuing with the upgrade.  It
> could also handle any additional work which needs doing before and
> after the upgrade of the whole distribution, or any particular
> package.  i.e. handling any work which the package maintainer
> scripts can't safely or sensibly handle.

Shipping scripts to do that would be a first step that makes much more
sense than having it automated at this stage IMHO.

> Doesn't the Ubuntu updater tool do something like this already when
> it does a full upgrade between releases?

There were quite some bugs with that tool AFAIR. Does it also cover
things that are not supported by Canonical? How does the development and
testing of the tool work?

Cheers

Luk


-- 
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/4fe4ad46.7000...@debian.org

Re: Introducing http.debian.net, Debian's mirrors redirector

[Darren Baginski]

On 21 Jun 2012 Raphael Geissert wrote:

> After several iterations to solve problems related to Debian's mirrors
> network, I am happy to announce a fully-functional solution that
> solves many
> of the shortcomings of previous iterations:
> http://http.debian.net

Is there other developer involved in development?
Mind to share data how many 'redirect' were served?
Why do you think redirects is a good idea at all?
Am I understand code properly and you spawn perl cgi script per each
file requested ?



-- 
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/1340387682.19149.2.camel@ph-01.local

Re: The future (or non-future) of ia32-libs

[Bernd Zeimetz]

On 06/22/2012 07:37 PM, Luk Claes wrote:
> On 06/22/2012 04:31 PM, Roger Leigh wrote:
>> On Fri, Jun 22, 2012 at 09:32:15PM +0800, Thomas Goirand wrote:
>> Doesn't the Ubuntu updater tool do something like this already when
>> it does a full upgrade between releases?
> 
> There were quite some bugs with that tool AFAIR. Does it also cover
> things that are not supported by Canonical? How does the development and
> testing of the tool work?

I think we can do better than having to rely on a weird tool to fix the issues
we produced by not doing a proper QA.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/4fe4b5f6.8000...@bzed.de

Re: The future (or non-future) of ia32-libs

[Goswin von Brederlow]

Thomas Goirand  writes:

> On 06/22/2012 05:34 PM, Goswin von Brederlow wrote:
>> Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
>> Step 2: dpkg --add-architecture i386 && apt-get update
>> Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)
>>   
> May I suggest that upon upgrade, we have a debconf message telling
> about it? We could add this in base-files or any essential package,
> probably one with some debconf messages already in would be a better
> pick. Instructions would show, IF ia32-libs old version is currently
> installed
> AND the --add-architecture i386 hasn't bee done.
>
> I know we have release notes, but some don't know about them or would
> simply not read them. A debconf message seem really appropriate IMO.
> Something along with:

Problem is that frontends will complain about ia32-libs being not
upgradable and might suggest removing it instead of keeping it back way
before that. At the time base-file is upgraded ia32-libs and all other
32bit stuff might already have been removed.

>> It appears that you have an old version of ia32-libs installed in your
>> system. Debian now supports multi-arch, and the new version of
>> ia32-libs (a transitional package) uses and needs this new feature.
>> .
>> In order to upgrade the version of ia32-libs in your system, you will
>> need to do:
>>dpkg --add-architecture i386
>>apt-get update
>>apt-get dist-upgrade
>>
>> Until you do this, upgrades of ia32-libs and packages depending on
>> it (wine, other examples, etc.) will not be possible. More information
>> about this available at: https://wiki.debian.org/
>
> I'm ok to contribute a small patch doing this.
> Thoughts? Any English guy to propose a better wording?
>
> Cheers,
>
> Thomas

I don't think that would be of much help but feel free to try it out
with some real squeeze -> wheezy upgrades and see if you see the message
before ia32-libs get removed.

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/87bokbus6c.fsf@frosties.localnet

Re: build-time testing of pure arch:all packages

[Goswin von Brederlow]

Yaroslav Halchenko  writes:

> On Fri, 22 Jun 2012, Goswin von Brederlow wrote:
>> > archive-wide rebuilds of arch:all packages as we routinely do rebuilds
>> > of arch:any packages.
>> > (Cc:-ing Lucas, for his great work on QA rebuilds.)
>> Are archive wide rebuilds done on anythiong but i386/amd64?
>
> IMHO if archive-wide rebuild could be carried on at least one
> representative big-endian architecture (e.g. sparc) -- it might already
> be quite useful. 
>
> Do we also have some time share on one of the top3 HPC boxes [2] +
> Lucas#2 to take care about it?  ;-)
>
> [2] http://en.wikipedia.org/wiki/TOP500

My boss recently came back from a conference and he brought back a flyer
about 2U arm server with up to 192 cores and 192 GB ram (on 12 planes a
4 quad core cpus and 4x 4GB ram each) with 10 Gbit networking.

I wonder: How long would an archive wide build take with 192 armel
buildds?

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/877guzurwh.fsf@frosties.localnet

Re: The future (or non-future) of ia32-libs

[Goswin von Brederlow]

m...@linux.it (Marco d'Itri) writes:

> On Jun 22, Goswin von Brederlow  wrote:
>
>> Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
>> Step 2: dpkg --add-architecture i386 && apt-get update
>> Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)
> Maybe this is easier?
>
> 1: upgrade dpkg and apt
> 2: dpkg --add-architecture i386 && apt-get update
> 3: dist-upgrade as usual
>
> -- 
> ciao,
> Marco

Sure, that would be enough for the 1. step.

There are a few more packages that need to be updated by hand for other
reasons. Anything between dpkg+apt and everything but ia32-libs will be
fine for me.

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/87395nurtn.fsf@frosties.localnet

Re: Report from the Bug Squashing Party in Salzburg

[Neil Williams]

On Fri, 22 Jun 2012 18:00:13 +0100
Philip Ashmore  wrote:

> On 22/06/12 07:12, Thomas Goirand wrote:
> > On 06/21/2012 10:39 PM, Jon Dowland wrote:
> >> Fair enough - but let's not lob hand grenades at people who might find it
> >> useful. Let them get on with it if they want to.
> >>
> > Sorry, but it's fair enough to "lob hand grenades" at people suggesting
> > non open source solutions, useful or not. Feel free to get on them if you
> > wish, but please do not suggest it inside Debian.
> >
> > Thomas

> So physically travelling to a potentially distant location for a bug 
> squash is the Debian way?

Yes, it's a lot more fun to work alongside others and you get to have
some beer with new friends, your patches benefit from direct
contributions of others around the same table and there is always room
for more social involvement between people in Debian. We all spend too
long alone with just a laptop for company.

Bug squashing parties are *social* events where bugs happen to get
fixed.

If everything was to be done only remotely there would be no bug
squashing parties at all. There might be lots of bugs fixed but that
isn't a party.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpL06EOk5LUj.pgp
Description: PGP signature

Re: Report from the Bug Squashing Party in Salzburg

[Lars Wirzenius]

On Fri, Jun 22, 2012 at 07:25:51PM +0100, Neil Williams wrote:
> Bug squashing parties are *social* events where bugs happen to get
> fixed.

http://wiki.debian.org/BSPMarathonWheezy should be useful for anyone
who thinks we're making people travel too long for these things. Host
a BSP! Even if it's just you and one other, it's a success if you make
any progress on any bug at all. Or even if you only have a good time.

-- 
I wrote a book: http://gtdfh.branchable.com/


signature.asc
Description: Digital signature

Re: The future (or non-future) of ia32-libs

[Goswin von Brederlow]

Luk Claes  writes:

> On 06/22/2012 04:31 PM, Roger Leigh wrote:
>> On Fri, Jun 22, 2012 at 09:32:15PM +0800, Thomas Goirand wrote:
>>> On 06/22/2012 05:34 PM, Goswin von Brederlow wrote:
 Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
 Step 2: dpkg --add-architecture i386 && apt-get update
 Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)
   
>>> May I suggest that upon upgrade, we have a debconf message telling
>>> about it? We could add this in base-files or any essential package,
>>> probably one with some debconf messages already in would be a better
>>> pick. Instructions would show, IF ia32-libs old version is currently
>>> installed
>>> AND the --add-architecture i386 hasn't bee done.
>>>
>>> I know we have release notes, but some don't know about them or would
>>> simply not read them. A debconf message seem really appropriate IMO.
>> 
>> Could we not introduce the concept of an "upgrade script" into
>> apt-get which could be downloaded when you run "apt-get update" and
>> then run during a dist-upgrade?  This could handle automation of
>> any "housekeeping" during the upgrade which would otherwise require
>> manual work detailed in the release notes.
>
> Hmm, I'm not a fan of upgrade scripts at all. Either it's easy enough to
> automate in maintainerscripts or it should get careful review for the
> context in which it will be applied IMHO (which means the sysadmin can
> run the shipped script manually).

Maybe you shouldn't think of this as a script. Rather think of it as
hints for apt/aptitude to do a dist-upgrade in multiple steps. As you
say the maintainer scripts should do the right thing already. So it is
just a matter of splitting up the package list into smaller chunks so the
upgrade process doesn't explode with a few extra actions inbetween
steps.

For ia32-libs the extra action would be "dpkg --add-architecture
i386". For the kernel/udev the action might be "reboot". Little things
like that. :)))

In general the upgrade "script" could consist of lists of white/black
lists of package to be processed in each step and debconf messages being
displayed between steps prompting the user to do certain things before
continuing.

Each time dist-upgrade-by-script is run apt-get would skip all the steps
that produce no change and continue from the first one that does (in
case it was aborted or reboot was needed).

Just an idea. Not that I think this could be done before the freeze.

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/87y5nftcsr.fsf@frosties.localnet

Re: build-time testing of pure arch:all packages

[Dmitrijs Ledkovs]

On 22/06/12 19:23, Goswin von Brederlow wrote:
> Yaroslav Halchenko  writes:
> 
>> On Fri, 22 Jun 2012, Goswin von Brederlow wrote:
 archive-wide rebuilds of arch:all packages as we routinely do rebuilds
 of arch:any packages.
 (Cc:-ing Lucas, for his great work on QA rebuilds.)
>>> Are archive wide rebuilds done on anythiong but i386/amd64?
>>
>> IMHO if archive-wide rebuild could be carried on at least one
>> representative big-endian architecture (e.g. sparc) -- it might already
>> be quite useful. 
>>
>> Do we also have some time share on one of the top3 HPC boxes [2] +
>> Lucas#2 to take care about it?  ;-)
>>
>> [2] http://en.wikipedia.org/wiki/TOP500
> 
> My boss recently came back from a conference and he brought back a flyer
> about 2U arm server with up to 192 cores and 192 GB ram (on 12 planes a
> 4 quad core cpus and 4x 4GB ram each) with 10 Gbit networking.
> 
> I wonder: How long would an archive wide build take with 192 armel
> buildds?
> 

1 day, 5 hours, 48 minutes, 54.3 seconds

libreoffice build in ubuntu amrhf

https://launchpad.net/ubuntu/+source/libreoffice/1:3.5.3-0ubuntu1/+build/3458035

Regards,

Dmitrijs.

-- 
Regards,
Dmitrijs.


-- 
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/4fe4bbcf.2030...@debian.org

Re: The future (or non-future) of ia32-libs

[Yves-Alexis Perez]

On ven., 2012-06-22 at 11:34 +0200, Goswin von Brederlow wrote:
> #677787 gtk2-engines-xfce: Please add multiarch support

Note that this one (as investigated in the bug report by Goswin and me)
is a bit spurious. For multi-arch Gtk+ apps, a multi-arch engine
matching the theme used by the end user is needed. So, in fact *each
engine* should be multi-archified (Gtk2 and Gtk3).

But, in fact, only the most used engines might really be candidate. I
didn't really had time to check gtk2-engines-xfce (so patches are
welcome) but I think it should not be too hard (not sure if I'll have
time before the freeze though). Same goes for gtk2-engines-murrine.

Regards,
-- 
Yves-Alexis


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

Re: Introducing http.debian.net, Debian's mirrors redirector

[Dmitry E. Oboukhov]

> Hi,

> After several iterations to solve problems related to Debian's mirrors
> network, I am happy to announce a fully-functional solution that solves many
> of the shortcomings of previous iterations: http://http.debian.net

> http.debian.net works as the key component of a content distribution
> network. For a given requested file, it uses several factors to choose one or
> multiple mirrors that can serve the request. Those factors include the
> freshness of the mirror, the network and geographic location, etc.

> How can you use it?
> An entry in /etc/apt/sources.list for stable would look like:

> deb http://http.debian.net/debian stable main

> It supports backports mirrors and others. Except CD image mirrors, they are
> *not* supported.

> More details, comparison to other approaches, and more information can be
> found at:
> http://http.debian.net/

> Oh, and, please help package and maintain mirrorbrain, which would allow a
> similar service to be provided for CD images.

> Thanks for reading.

> P.S. contrary to wheezy, http.debian.net's development will not freeze. It
> is under continuous development, and more users and developers are welcome!


I've tried to use the service. 2/3 requests - 501 error.
unusable.

:(
-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: The future (or non-future) of ia32-libs

[Goswin von Brederlow]

"Adam D. Barratt"  writes:

> On 22.06.2012 15:31, Roger Leigh wrote:
>> On Fri, Jun 22, 2012 at 09:32:15PM +0800, Thomas Goirand wrote:
>>> On 06/22/2012 05:34 PM, Goswin von Brederlow wrote:
>>> > Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
>>> > Step 2: dpkg --add-architecture i386 && apt-get update
>>> > Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)
> [...]
>>> I know we have release notes, but some don't know about them or
>>> would
>>> simply not read them. A debconf message seem really appropriate IMO.
>>
>> Could we not introduce the concept of an "upgrade script" into
>> apt-get which could be downloaded when you run "apt-get update" and
>> then run during a dist-upgrade?  This could handle automation of
>> any "housekeeping" during the upgrade which would otherwise require
>> manual work detailed in the release notes.
>
> As a theoretical future enhancement, possibly.  That won't help for
> squeeze to wheezy upgrades though, as squeeze's apt would need to
> include support for it.
>
> Regards,
>
> Adam

I actualy have an idea for this special case that should be quick to
implement and could help many users.

Packages with cross architecture dependencies set "X-Needs-Architecture:
[, ...]" in debian/control. Apt-get and aptitude (and maybe dpkg)
can then be patched to give a helpfull error message if the user tries
to install the package without multiarch. They can also hold back the
package until multiarch is enabled (as opposed to suggesting to remove
them as first choice) and even suggest enabling multiarch (wheezy
versions only).

The helpfull error messages and holding back packages would have to be
ported to stable apt/aptitude to be any use for upgrades. And only
people updating to the latest stable point release would benefit from
it.

In the long run though it would be helpfull for everyone. Trying to
install an armel cross compiler on amd64 could automatically detect that
this would require activating armel and suggest to do that now. And so
on. Post wheezy detecting this case could be extended to "Depends:
libfoo:arch".

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/87pq8rtc78.fsf@frosties.localnet

Bug#678572: ITP: foremancli -- commandline search interface to Foreman

[Ulrich Dangel]

Package: wnpp
Severity: wishlist
Owner: Ulrich Dangel 

* Package name: foremancli
  Version : 1.0
  Upstream Author : Brian Gupta 
* URL : http://theforeman.org/projects/foreman/wiki/Foremancli
* License : GPL-2+
  Programming Lang: ruby
  Description : commandline search interface to Foreman

This is a commandline tool for searching node information stored in a
Foreman server.

foremancli can be used to search and access all the stored information n
a Foreman server and present the data in text, json or yaml formats.

Foreman is a server application that can be used to provision bare etal,
virtual and cloud servers, and integrates with the Puppet configuration
management system to provide full life cycle managements of one's
server infrastructure.



-- 
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/20120622192026.2217.10293.reportbug@shiny

Re: Summary: Moving /tmp to tmpfs makes it useless

[Henrique de Moraes Holschuh]

On Fri, 22 Jun 2012, Andrei POPESCU wrote:
> On Mi, 20 iun 12, 15:18:55, Stephan Seitz wrote:
> > Fine let’s talk. Why can’t we find a compromise? Additional to our
> > disk /tmp we create a /ramtmp (so the name suggests that this tmp is
> > a ramdisk) with tmpfs. This should be doable in time for Wheezy. The
> > release notes should mention it. And those who wish can patch their
> > programs to use the ramdisk if they think their program uses only
> > small temporary files. In this way, we get some data and experience.
> > And we have both worlds. /tmp on disk for even large temporary files
> > and /ramtmp as fast ramdisk.
> 
> Why not use /run instead?

Feel free to add a *mountpoint* at /run/tmp and provide a second tmpfs
there[1].  But if you do that, we'd have /tmp, /run/tmp, and /var/tmp so to
me it just looks like a mess...

Well, /var/tmp is always disk-backed and it is supposed to last across
reboots, and files there should last for a while before any automated
cleaning.  It is written nowhere that you can leave large files in there,
though, but it is not supposed to be too space-constrained.

/run/tmp might be defined from the get go to be tmpfs, and not some place
you should expect to be able to abuse (i.e. can't be automatically used to
unpack large amounts of crap, host the tile cache of a pixel editor or the
browser's cache, etc).  What good would it do, I don't know: you'd need to
set TMPDIR=/run/tmp to use it anyway, so might as well just do it to /tmp...

[1] Should you fill /run or cause a filename colision, very bad things
can happen.  You don't use /var/lock and /var/run as a general dumping
ground for random crap, and the same rule applies to /run.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20120622192819.gc32...@khazad-dum.debian.net

Re: proprietary solutions just work (Re: Report from the Bug Squashing Party in Salzburg

[darkestkhan]

On Thu, Jun 21, 2012 at 1:28 PM, Holger Levsen  wrote:
> On Donnerstag, 21. Juni 2012, Bernd Zeimetz wrote:
>> It is *easy* to use. It works out of the box. I don't need to tell
>> people how to use it and what to install. It works with various other
>> devices. And so on. I do not believe that your question was serious
>> anyway.
>
> Windows is *easy* to use. Windows works out of the box. I don't need to tell
> people how to use Windows and what to install. Windows works with various
> other devices. And so on. I do not believe that your question was serious
> anyway.
>
> SCNR.
>

Are you sure about this? On at least two occasions I had experienced how it
doesn't work out of the box - once when installing it (everything went
well up to
the point of copying files to hdd - Windows 7 couldn't detect drivers
for DVD and
as such installation couldn't proceed), and now when my brother is starting his
PC while I'm connected to net (it wrongly assumes that I'm router).
I really don't see how it is "works out of the box".

-- 
darkestkhan
--
Feel free to CC me.
jid: darkestk...@gmail.com
May The Source be with You.


-- 
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/cacrpbmiotucamikrrc0r3puzktpwv7t0p47a-w-yci94kgn...@mail.gmail.com

Bug#678519: general: after about 1 month of uptime, routing of IPv6 packets is no longer possible, and IPv4 routing becomes slow and unpredictable. Rebooting brings all functionality back, and back to

[Henrique de Moraes Holschuh]

On Fri, 22 Jun 2012, Rudy Zijlstra wrote:
> let system run with IPv4 & IPv6 routing for about 1 month
> > IPv6 routing will start to fail
> > IPv4 routing becomes slow and unpredictable
> 
> no obvious causes visible in the system. top and friends do not show a cpu hog
> 
> a reboot will bring the system back to normal behaviour. 

Please use (as root) "ip neigh show", and "ip route list cache" to try to
track down any weird differences between the box when it is behaving
normally, and the box when wedged.  You may want to compare it to a healthy
box on the same network segment.

You can also try to see if "ip route flush cache" and "ip neigh flush" can
unwedge the system.  After a flush, "ip neigh show" and "ip route list
cache" should return very few, if any, entries.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



-- 
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/20120622193831.gd32...@khazad-dum.debian.net

Re: Report from the Bug Squashing Party in Salzburg

[Holger Levsen]

Hi,

On Freitag, 22. Juni 2012, Neil Williams wrote:
> Bug squashing parties are *social* events where bugs happen to get
> fixed.

soon there will be a 14 day BSP, in Central America, in Managua :-D
You'll be able to participate remotly, mostly via IRC ;)


cheers,
Holger


-- 
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/201206230004.11452.hol...@layer-acht.org

Re: Report from the Bug Squashing Party in Salzburg

[Philip Ashmore]

On 22/06/12 23:04, Holger Levsen wrote:

Hi,

On Freitag, 22. Juni 2012, Neil Williams wrote:

Bug squashing parties are *social* events where bugs happen to get
fixed.


soon there will be a 14 day BSP, in Central America, in Managua :-D
You'll be able to participate remotly, mostly via IRC ;)


cheers,
Holger

I never said I didn't enjoy a social event - don't get me wrong.
But for those who can't make it, what about 
http://www.bigbluebutton.org/ or http://plus.google.com/ too?


It could even hook up several such events around the globe!

Philip


--
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/4fe4f6ec.4000...@philipashmore.com

MIA ping Jürgen Rinas (sinfo)

[Dmitrijs Ledkovs]

Dear all,

sinfo package is not RC, but it hasn't been updated in a while.

Jürgen Rinas or Gaudenz Steinlin do you intend to continue maintaining it?

-- 
Regards,
Dmitrijs.


-- 
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/4fe52739.2090...@debian.org

[DEP 8] Re: Is it possible to run autopkgtest without a virtual machine ?

[Charles Plessy]

Le Fri, Jun 22, 2012 at 11:02:04AM +0200, Goswin von Brederlow a écrit :
> 
> I think test should be run in a container (or VM) but never the local
> system itself. The absolute minimum would be a chroot but a container
> would give better control over things like networking.

Hello Goswin

For networking, how about a "needs-networking" restriction ?

For protecting the user from side effects of runnign the tests, there is the
Restrictions field where one can declare that tests can break the system.
Perhaps a milder restriction could be added, for tests that can disturb the
system (such as restarting services, etc.), so that other tests can be
considered safe for local execution.  A large number of regression tests that I
know are completely safe, like checking that 2 + 2 returns 4, with of course
the limitation that running them exposes to the same possible bugs as for using
the program in other contexts.

I think that it would be a great feature to be able to run such tests locally
with a simple command that can take advantage of autopkgtest.  This means also
shipping them in a binary package, but we have already such packages containing
exactly the test data that is needed.

Have a nice day

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20120623032924.gb15...@falafel.plessy.net

[DEP 8] About the Restrictions and Features field.

[Charles Plessy]

Dear Ian, Iustin and Stefano,

reading DEP 8's appendix, I wonder about the necessity to keep separate
Restrictions and Features fields.  For instance, the no-build-needed Feature
could also be a needs-build restriction.  Perhaps the specification can
be simplified by dropping the Features field ?

Have a nice week-end,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20120623033354.gc15...@falafel.plessy.net

Re: The future (or non-future) of ia32-libs

[Ben Hutchings]

On Fri, 2012-06-22 at 19:37 +0200, Luk Claes wrote:
> On 06/22/2012 04:31 PM, Roger Leigh wrote:
> > On Fri, Jun 22, 2012 at 09:32:15PM +0800, Thomas Goirand wrote:
> >> On 06/22/2012 05:34 PM, Goswin von Brederlow wrote:
> >>> Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
> >>> Step 2: dpkg --add-architecture i386 && apt-get update
> >>> Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)
> >>>   
> >> May I suggest that upon upgrade, we have a debconf message telling
> >> about it? We could add this in base-files or any essential package,
> >> probably one with some debconf messages already in would be a better
> >> pick. Instructions would show, IF ia32-libs old version is currently
> >> installed
> >> AND the --add-architecture i386 hasn't bee done.
> >>
> >> I know we have release notes, but some don't know about them or would
> >> simply not read them. A debconf message seem really appropriate IMO.
> > 
> > Could we not introduce the concept of an "upgrade script" into
> > apt-get which could be downloaded when you run "apt-get update" and
> > then run during a dist-upgrade?  This could handle automation of
> > any "housekeeping" during the upgrade which would otherwise require
> > manual work detailed in the release notes.
> 
> Hmm, I'm not a fan of upgrade scripts at all. Either it's easy enough to
> automate in maintainerscripts or it should get careful review for the
> context in which it will be applied IMHO (which means the sysadmin can
> run the shipped script manually).
[...]

You can't use a maintainer script to automate, for example, installation
of another package dependent on hardware configuration.  All you can do
is show a note/error prompting the user to do that.  Which is rather
sad.

Ben.

-- 
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.


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

Re: The future (or non-future) of ia32-libs

[Thomas Goirand]

On 06/23/2012 02:18 AM, Goswin von Brederlow wrote:
> Problem is that frontends will complain about ia32-libs being not
> upgradable and might suggest removing it instead of keeping it back way
> before that. At the time base-file is upgraded ia32-libs and all other
> 32bit stuff might already have been removed.

Well, you wrote it would be held back, so I reacted upon the information
you gave...

What mechanism would remove it? Is there any break / conflict somewhere
that would do that?

Thomas


-- 
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/4fe56011.70...@debian.org

Re: The future (or non-future) of ia32-libs

[Thomas Goirand]

On 06/23/2012 02:48 AM, Goswin von Brederlow wrote:
> The helpfull error messages and holding back packages would have to be
> ported to stable apt/aptitude to be any use for upgrades. And only
> people updating to the latest stable point release would benefit from
> it.
>   
Unfortunately, we never require that our users upgrade to the latest
point release before upgrading to stable+1. So it would be nice to
have this feature in a stable update, but this can't be a definitive
solution.

Thomas


-- 
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/4fe560ce.5070...@debian.org

Re: The future (or non-future) of ia32-libs

[Russ Allbery]

Thomas Goirand  writes:
> On 06/23/2012 02:48 AM, Goswin von Brederlow wrote:

>> The helpfull error messages and holding back packages would have to be
>> ported to stable apt/aptitude to be any use for upgrades. And only
>> people updating to the latest stable point release would benefit from
>> it.

> Unfortunately, we never require that our users upgrade to the latest
> point release before upgrading to stable+1. So it would be nice to have
> this feature in a stable update, but this can't be a definitive
> solution.

We've frequently required users to upgrade specific packages to newer
versions prior to the general dist-upgrade to resolve various issues, such
as for the udev transition.

-- 
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/87lijemtnr@windlord.stanford.edu