Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Tollef Fog Heen]

]]  (Marco d'Itri)

| Removing the Essential flag from sysvinit would allow interested admins
| to install upstart on their systems if they want to benefit from its
| features. I am not sure how much useful it would be to also switch to
| upstart by default in this scenario, I welcome other opinions.

I just filed an ITP on systemd and am planning on making it installable
alongside with sysvinit, switchable with init=/sbin/systemd when
booting.  Eventually, I guess either using alternatives for /sbin/init
or dpkg-divert-ing it away from sysvinit might be the way to go.  Either
way, whether sysvinit is Essential or not is a bit irrelevant to whether
people can experiment with other init systems.

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


-- 
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/87k4rdvcbv@qurzaw.linpro.no

Re: bindv6only again

[Jean-Christophe Dubacq]

On 09/05/2010 01:45, Clint Adams wrote:
> On Sun, May 09, 2010 at 12:16:10AM +0200, Jean-Christophe Dubacq wrote:
>> What if it is just installed from the tarball?
> 
> Then that person is still using buggy, non-free software.

Which should not prevent this person from running it, especially when
all other distributions allow that.
-- 
Jean-Christophe Dubacq


-- 
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/4be64851.5040...@free.fr

Processed: reassign 580794 to src:linux-2.6

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 580794 src:linux-2.6
Bug #580794 [general] general: CD-rom drive is unable to read from any dvd(s) 
after wake up from suspend/hibernation
Bug reassigned from package 'general' to 'src:linux-2.6'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
580794: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580794
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.127337336611434.transcr...@bugs.debian.org

Re: bindv6only again

[Kazuo Oishi]

Vincent Danjean  writes:
> And I see in these threads lots of things broken (including sun java that
> it used/required for lots of software not necessarily packaged in Debian)
> and no visible gains for users.
>
> I do not understand what is the purpose to say we will wait before taking
> a decision. Either, we switched back to the previous (POSIX) setup (my
> preference) or we stick with this setup but actively work to correct
> the bugs in applications. I would find very strange if we release sqeeze
> with a broken sun's java (even if it is non-free) and no good replacement.

I agree with Vincent.

I still think that default value of net.ipv6.bindv6only should revert to
old default value 0.

I think that programs depending bindv6only=1 is more buggy.  (Depending
bindv6only=0 is less buggy.)

We should revert net.ipv6.bindv6only value to 0, and then fix programs
which depending bindv6only value (either 0 or 1).

-- 
Kazuo Oishi


-- 
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/87eihlu989@molech.giraffy.jp

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Marco d'Itri]

On May 07, Julien Cristau  wrote:

> >  - a decision to drop kfreebsd as a release architecture
> Since 1 and 2 aren't happening, I think we should consider going with
> the third option.
Me too, I believe that the people interested in kfreebsd-* have had more
than enough time to provide the compatibility framework and we cannot
hold back Debian forever for the benefit of a toy port.

OTOH, it is not obvious to me anymore that Debian should commit to
Upstart now that systemd has appeared and it has many compelling
features. I believe we should consider systemd's merits and wait and see
how it will work in the next Fedora release and if SUSE will really
adopt it.
This still does not preclude switching from sysvinit to Upstart, it only
means that maintainers should not convert their init scripts to Upstart
jobs (and it would also allow releasing the kfreebsd-* ports).

Removing the Essential flag from sysvinit would allow interested admins
to install upstart on their systems if they want to benefit from its
features. I am not sure how much useful it would be to also switch to
upstart by default in this scenario, I welcome other opinions.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: bindv6only again

[Sylvestre Ledru]

Le samedi 08 mai 2010 à 19:25 +0200, Marco d'Itri a écrit :
> On May 05, Vincent Danjean  wrote:
> 
> > the bugs in applications. I would find very strange if we release sqeeze
> > with a broken sun's java (even if it is non-free) and no good replacement.
> Me too, but I still hope that it could be fixed.
> Maybe the maintainer could provide some of his toughts...
The bug on Sun bugtracker [1] has been opened in October 2005 and it has
a low priority. There is no sign of reactivity from Sun/Oracle on this
issue.

The current package of the non-free SDK is not built from source.

Sylvestre
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6342561



-- 
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/1273363720.5246.11401.ca...@zlarin

Re: bindv6only again

[Clint Adams]

On Sun, May 09, 2010 at 12:16:10AM +0200, Jean-Christophe Dubacq wrote:
> What if it is just installed from the tarball?

Then that person is still using buggy, non-free software.


-- 
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/20100508234524.ga9...@scru.org

Re: Dual init scripts (or two init scripts in one package)

[Vincent Danjean]

On 08/05/2010 14:27, Roberto C. Sánchez wrote:
> So, currently the shorewall package ships debian/shorewall.init, which
> is accompanied by the following debian/rules entry:
> 
> dh_installinit --no-start -u"start 40 S . stop 89 0 6 ."
> 
> If I read the dh_installinit manpage correctly, then I can ship:
> 
> debian/shorewall.shorewall-prenet.init
> debian/shorewall.shorewall-postnet.init
> 
> Then in debian/rules I would have:
> 
> dh_installinit --no-start --name=shorewall-prenet -u"start 35 S . stop 89 0 6 
> ."
> dh_installinit --no-start --name=shorewall-postnet -u"start 40 S . stop 89 0 
> 6 ."
> 
> The idea is to have one init script that runs before S40networking and
> another that runs after.  Does this seem right?

Do you really need to rename shorewall to shorewall-postnet in /etc/init.d ?
It would unnecessary break admin script to restart the firewall (and you
will have to manage a complex pre/postinst to handle cases where the admin
changed this conffile).

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


-- 
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/4be5e749.2040...@free.fr

Re: bindv6only again

[Jean-Christophe Dubacq]

On 08/05/2010 20:33, Petter Reinholdtsen wrote:
> 
> [Niels Thykier]
>> I do not think the maintainers can do anything about sun-java6 other
>> than ask users to modify the netbase config file. To the best of my
>> knowledge there is no source code available for sun-java6.
> 
> It could add a file in /etc/sysctl.d/ to override the current
> /etc/sysctl.d/bindv6only.conf setting, and disable
> "net.ipv6.bindv6only = 1" when sun-java6 is installed. :)
> 
> Happy hacking,
What if it is just installed from the tarball?

-- 
Jean-Christophe Dubacq


-- 
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/4be5e2aa.8090...@free.fr

Re: Dual init scripts (or two init scripts in one package)

[Ron Johnson]

On 05/07/2010 09:35 PM, Russ Allbery wrote:

Roberto C. Sánchez  writes:


Greetings.  I am curious as to how the scenario described in the below
message would work in Debian.  That is, can one package install two init
scripts?


Sure.  A package can install as many init scripts as it wants and needs.



What about putting it's startup script in /etc/network/if-up.d/?  Or 
am I misinterpreting it's purpose?


--
Dissent is patriotic, remember?


--
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/4be5dbe4.60...@cox.net

Bug#580815: ITP: python-django-threadedcomments -- simple yet flexible threaded commenting system for Django

[Bernhard Reiter]

Package: wnpp
Severity: wishlist
Owner: Bernhard Reiter 

  Package name: python-django-threadedcomments
  Version : 0.5.2
  Upstream Author : Eric Florenzano 
  URL : http://github.com/ericflo/django-threadedcomments
  License : BSD
  Programming Lang: Python
  Description : simple yet flexible threaded commenting system for Django

What it means to say that they are *threaded* is that commenters can
reply not only to the original item, but to other comments as well. It becomes
near-trivial to create a system similar to what Reddit or Digg have in their 
comments sections.



-- 
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/20100508211733.30131.53968.report...@localhost.localdomain

Bug#580814: ITP: systemd -- system and session manager

[Tollef Fog Heen]

Package: wnpp
Owner: Tollef Fog Heen 
Severity: wishlist

* Package name: systemd
  Version : 0
  Upstream Author : Lennart Pottering
* URL or Web page : http://www.freedesktop.org/wiki/Software/systemd
* Code: http://cgit.freedesktop.org/systemd/
* License : GPLv2+
  Description : system and session manager

systemd is a replacement for sysvinit.  It is dependency-based and able
to read the LSB init script headers in addition to parsing rcN.d links
as hints.

it also provides process supervision using cgroups and the ability to
not only depend on other init script being started, but also
availability of a given mount point or dbus service.

systemd is currently linux-only as it relies on technologies like
cgroups, libudev, epoll and signalfd.

I am planning on providing corresponding startup scripts and be
coinstallable with sysvinit, switchable with a flag to the kernel.

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



-- 
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/87ocgquma6@qurzaw.linpro.no

Processed (with 1 errors): Re: Bug#580794: general: CD-rom drive is unable to read from any dvd(s) after wake up from suspend/hibernation

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 580794 linux-2.6
Unknown command or malformed arguments to command.

> severity 580794 normal
Bug #580794 [general] general: CD-rom drive is unable to read from any dvd(s) 
after wake up from suspend/hibernation
Severity set to 'normal' from 'important'

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
580794: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580794
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.127334998832080.transcr...@bugs.debian.org

Nicht im Haus bis 2010-05-28

[marco . fisch]

Ich werde ab  07.05.2010 nicht im Büro sein. Ich kehre zurück am
28.05.2010.

Bin im Urlaub! Ab 2010-05-31 stehe ich Ihnen gerne wieder zur Verfügung.
Mit freundlichen Grüßen

Marco Fisch


--
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/of8aaa1190.133aaf92-onc125771d.006e3ea3-c125771d.006e3...@n-ergie.de

Re: [OSRM] Planning for final Etch point release and archiving of oldstable?

[Adam D. Barratt]

On Sat, May 8, 2010 18:06, Frans Pop wrote:
> I would have expected a final point release for Etch to have happened by
> now (since security support was ended back in February). My personal
> interest is of course the D-I updates included for that release.

Regrettably, sorting out etch hasn't had the priority we'd have liked for
a little while.

However, we have been making progress recently.  We now have copies of all
the packages from DSAs (with one exception where the .orig tarball used
for the security update differs from that in the main archive) and have
been working on trying to build the few remaining packages where for some
reason the security update failed to build on an architecture supported by
the package.

I think we're more or less at the point where we should admit defeat with
the couple of packages that still fail; we then just need to organise the
actual release.

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/8935ac7d1f083dfedd1c0b76b4b5219d.squir...@adsl.funkybadger.org

Re: bindv6only again

[Petter Reinholdtsen]

[Niels Thykier]
> I do not think the maintainers can do anything about sun-java6 other
> than ask users to modify the netbase config file. To the best of my
> knowledge there is no source code available for sun-java6.

It could add a file in /etc/sysctl.d/ to override the current
/etc/sysctl.d/bindv6only.conf setting, and disable
"net.ipv6.bindv6only = 1" when sun-java6 is installed. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
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/2fl632yckfe@login2.uio.no

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Petter Reinholdtsen]

[Kai Wasserbäch]
> as one of the testers just a short reply: on several desktops and
> some basic servers insserv in conjunction with
> "CONCURRENCY=makefile" works well. I didn't have an unbootable
> system so far.

Thank you.  Note that I do not expect an unbootable system.  The worst
I expect are some services failing to start at boot, for example
because they are unable to connect to some other service or because a
file/socket/something isn't available at the right time during boot.
To fail completely to boot, the common packages would have to have
serious problems, and I am very confident that this is not the case.

> As far as speed goes: I didn't measure the speed but it feels
> faster. ;)

Good to hear. :)

If the consensus is that we should switch the default to
CONCURRENCY=makefile, I guess it might still be time to do it. :)

After all, any bugs detected would be easy to work around, by editing
the dependency information in the files in /etc/init.d/.  Any sysadmin
finding a problem could fix it locally while waiting for the fix to
show up.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
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/2flbpcqckmw@login2.uio.no

Re: bindv6only again

[Niels Thykier]

Marco d'Itri wrote:
> On May 05, Vincent Danjean  wrote:
> 
>> the bugs in applications. I would find very strange if we release sqeeze
>> with a broken sun's java (even if it is non-free) and no good replacement.
> Me too, but I still hope that it could be fixed.
> Maybe the maintainer could provide some of his toughts...
> 

I do not think the maintainers can do anything about sun-java6 other
than ask users to modify the netbase config file. To the best of my
knowledge there is no source code available for sun-java6.

On a related note Vicent; if the person testing the issue has not
already done it, could you convince him/her to file a bug against the
plugin?

~Niels




signature.asc
Description: OpenPGP digital signature

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Kai Wasserbäch]

Hello Petter,
Petter Reinholdtsen schrieb am 08.05.2010 19:07:
> Perhaps we should do a poll to collect
> information on how testers experience their boot with
> CONCURRENCY=makefile, [...]

as one of the testers just a short reply: on several desktops and some basic
servers insserv in conjunction with "CONCURRENCY=makefile" works well. I didn't
have an unbootable system so far.
As far as speed goes: I didn't measure the speed but it feels faster. ;)

Kind regards,
Kai Wasserbäch



-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: deb...@carbon-project.org
Jabber (debianforum.de): Drizzt
URL: http://wiki.debian.org/C%C3%B9ran
GnuPG: 0xE1DE59D2  0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2
(http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2&fingerprint=on&hash=on&op=vindex)



signature.asc
Description: OpenPGP digital signature

Re: bindv6only again

[Marco d'Itri]

On May 05, Vincent Danjean  wrote:

> the bugs in applications. I would find very strange if we release sqeeze
> with a broken sun's java (even if it is non-free) and no good replacement.
Me too, but I still hope that it could be fixed.
Maybe the maintainer could provide some of his toughts...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#580794: general: CD-rom drive is unable to read from any dvd(s) after wake up from suspend/hibernation

[michalxo]

Package: general
Severity: important
Tags: sid

My cdrom drive is unable to read dvds/cds after suspend/hibernation. Only thing
which helps is reboot. In ubuntu I had similar error, so it may be something
with kernel..  :-/ (2.6.32-3 and 32-5)

Thanks



-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores)



-- 
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/20100508165220.17043.9826.report...@calypso.sks3.muni.cz

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Petter Reinholdtsen]

[Stefano Zacchiroli]
> Fair enough. IMO you've done quite a lot of communication on the matter
> (at least to us developers) and I've personally been testing
> CONCURRENCY=makefile in response to your repeated call for testers. At
> this point, I doubt you can get significantly more testers without
> changing the default concurrency level. All in all, it seems to be just
> a matter of *when* doing that change to gather more feedback.

Perhaps you are right.  Perhaps we should do a poll to collect
information on how testers experience their boot with
CONCURRENCY=makefile, to make it easier to switch with some confidence
that it would work for most users. :)

> I understand that you've considered doing it now and that you've decided
> not to (probably in accordance with the release team), which is fairly
> understandable. It is just a pity to give up the chance to actually
> understand how far are we from correct and complete dependency
> declarations. Oh well, I guess it's just life.

Well, it has not really been discussed with the release team, and the
decision depend a lot of when Squeeze freezes, so it is hard to know
what to decide. :)

Perhaps we should switch the default in unstable to
CONCURRENCY=makefile for a while, and if it causes a lot of problems
we can switch it back to sequential boot.  At the moment I believe we
need to increase the amount of testing a lot to get the remaining bugs
located and fixed, and that is hard to do without actually doing the
switch.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
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/2flhbmicof3@login2.uio.no

[OSRM] Planning for final Etch point release and archiving of oldstable?

[Frans Pop]

Hi,

I would have expected a final point release for Etch to have happened by 
now (since security support was ended back in February). My personal 
interest is of course the D-I updates included for that release.

Could the (oldstable) release team please clarify the status and planning?

TIA,
FJP


-- 
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/201005081906.38828.elen...@planet.nl

Re: perl: 64-bit integers and long doubles

[Florian Lohoff]

On Sat, May 08, 2010 at 03:44:03PM +, Philipp Kern wrote:
> On 2010-05-08, Frans Pop  wrote:
> > archkernel  userland
> > --  --  
> > alpha   32  32
> 
> Isn't alpha the first 64bit of all?
> 
> > mips/mipsel 32  32
> 
> I think that's 32/64, 32; at least for mipsel.

Userspace for mips and mipsel is 32bit (o32 abi) and the kernel is
32/64 depending on the machine type. This has nothing to do with the
endianess - we should have 64 bit swarm little and big endian kernels.

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


signature.asc
Description: Digital signature

Re: Dual init scripts (or two init scripts in one package)

[Russ Allbery]

Roberto C. Sánchez  writes:

> So, currently the shorewall package ships debian/shorewall.init, which
> is accompanied by the following debian/rules entry:

> dh_installinit --no-start -u"start 40 S . stop 89 0 6 ."

> If I read the dh_installinit manpage correctly, then I can ship:

> debian/shorewall.shorewall-prenet.init
> debian/shorewall.shorewall-postnet.init

> Then in debian/rules I would have:

> dh_installinit --no-start --name=shorewall-prenet -u"start 35 S . stop 89 0 6 
> ."
> dh_installinit --no-start --name=shorewall-postnet -u"start 40 S . stop 89 0 
> 6 ."

> The idea is to have one init script that runs before S40networking and
> another that runs after.  Does this seem right?

Yup, that looks right to me, although of course these days the LSB headers
in the scripts are more important (thankfully) than the defaults given to
dh_installinit.

I think that -- is now preferred over -u for passing extra parameters
along through the debhelper script, although of course both work.

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

Re: perl: 64-bit integers and long doubles

[Frans Pop]

On Saturday 08 May 2010, Julien Cristau wrote:
> alpha is all 64.

Shows that alpha is the arch I'm least familiar with...

> and sparc kernel is 64.

This I should have gotten right :-(

Thanks.


-- 
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/201005081806.52852.elen...@planet.nl

Re: perl: 64-bit integers and long doubles

[Philipp Kern]

On 2010-05-08, Frans Pop  wrote:
> arch  kernel  userland
> ----  
> alpha 32  32

Isn't alpha the first 64bit of all?

> mips/mipsel   32  32

I think that's 32/64, 32; at least for mipsel.

> sparc 32  32

Certainly 64, 32 here.

> s390  64  32

64/31 *grin*, at least if talking about memory addresses.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhub1m3.akb.tr...@kelgar.0x539.de

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Luk Claes]

On 05/08/2010 11:47 AM, Julien Cristau wrote:

On Fri, May  7, 2010 at 19:27:54 +0200, Stefano Zacchiroli wrote:


(Beside the nitpick on "we want" vs "we possibly want") I'd argue that
it's because we want a faster boot from our users ASAP.


As far as I'm concerned, "faster boot" is irrelevant.  Using an init
daemon that actually does its job of supervising services, and lets us
get rid of most of the stupidity and boilerplate of init scripts, otoh,
is overdue.


I think supervising services and faster boot are nice. Faster boot is 
nice for end users as well as for servers. The latter mainly because it 
gives more time for actual response time in case of an intervention that 
needs down time.


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/4be583d3.8080...@debian.org

Re: perl: 64-bit integers and long doubles

[Julien Cristau]

On Sat, May  8, 2010 at 17:15:50 +0200, Frans Pop wrote:

> Niko Tyni wrote:
> > Can anybody list our "pure" 32-bit architectures off-hand
> > or suggest a simple test?
> 
> AFAIK for Squeeze the arches are as follows, but please anybody correct me 
> where incorrect.
> 
> arch  kernel  userland
> ----  
> i386  32/64   32
> amd64 64  64
> alpha 32  32

alpha is all 64.

> armel 32  32
> hppa  32/64   32
> ia64  64  64
> mips/mipsel   32  32
> powerpc   32/64   32
> sparc 32  32

and sparc kernel is 64.

> s390  64  32
> 
> kfreebsd-i386 32/64   32
> kfreebsd-amd6464  64
> hurd-i386 32  32
> 
> hurd-i386 does not seem to have a 64-bit kernel option.
> 
Cheers,
Julien


signature.asc
Description: Digital signature

Re: perl: 64-bit integers and long doubles

[Frans Pop]

Niko Tyni wrote:
> Can anybody list our "pure" 32-bit architectures off-hand
> or suggest a simple test?

AFAIK for Squeeze the arches are as follows, but please anybody correct me 
where incorrect.

archkernel  userland
--  --  
i38632/64   32
amd64   64  64
alpha   32  32
armel   32  32
hppa32/64   32
ia6464  64
mips/mipsel 32  32
powerpc 32/64   32
sparc   32  32
s39064  32

kfreebsd-i386   32/64   32
kfreebsd-amd64  64  64
hurd-i386   32  32

hurd-i386 does not seem to have a 64-bit kernel option.

Cheers,
FJP


-- 
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/201005081715.51168.elen...@planet.nl

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Bernd Zeimetz]

On 05/07/2010 09:59 AM, Mike Hommey wrote:
> On Fri, May 07, 2010 at 09:47:36AM +0200, Josselin Mouette wrote:
>> Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
>>> These days, the init.d script dependencies in Squeeze are quite
>>> complete, so complete that it is actually possible to run all the
>>> init.d scripts in parallell based on these dependencies.  If you want
>>> to test your Squeeze system, make sure dependency based boot
>>> sequencing is enabled, and add this line to /etc/default/rcS:
>>>
>>>   CONCURRENCY=makefile
>>
>> Seems to work fine for me. However the gain isn’t really important,
>> given that the critical path includes fsck and networking.
> 
> And kernel+initramfs. That's more than half the boot time (without
> even CONCURRENCY=makefile) here.

Exactly.
I gain much more from moving the start of $many_daemons behind the start of kdm
on my desktop. The speed difference with/without CONCURRENCY=makefile is not
really noticeable for me.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   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/4be56d63.6020...@bzed.de

Re: Dual init scripts (or two init scripts in one package)

[Roberto C . Sánchez]

On Fri, May 07, 2010 at 07:35:02PM -0700, Russ Allbery wrote:
> Roberto C. Sánchez  writes:
> 
> > Greetings.  I am curious as to how the scenario described in the below
> > message would work in Debian.  That is, can one package install two init
> > scripts?
> 
> Sure.  A package can install as many init scripts as it wants and needs.
> 
So, currently the shorewall package ships debian/shorewall.init, which
is accompanied by the following debian/rules entry:

dh_installinit --no-start -u"start 40 S . stop 89 0 6 ."

If I read the dh_installinit manpage correctly, then I can ship:

debian/shorewall.shorewall-prenet.init
debian/shorewall.shorewall-postnet.init

Then in debian/rules I would have:

dh_installinit --no-start --name=shorewall-prenet -u"start 35 S . stop 89 0 6 ."
dh_installinit --no-start --name=shorewall-postnet -u"start 40 S . stop 89 0 6 
."

The idea is to have one init script that runs before S40networking and
another that runs after.  Does this seem right?

I will still have to figure out the right start and stop values, but I
just want to make sure I generally have the mechanics right.

Regards,

-Roberto

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


signature.asc
Description: Digital signature

ITP: focuswriter -- a fullscreen, distraction-free word processor

[Tang Ke]

Package: wnpp
Severity: wishlist
Owner: Tang Ke 

* Package name: focuswriter
   Version: 1.2.1
   Upstream Authors: Graeme Gott 
* URL:http://gottcode.org/focuswriter/
* License: GPL3
   Programming Lang: C++
   Description: a fullscreen, distraction-free word processor   

 This program is designed to immerse you as much as possible in your 
 work. The program autosaves your progress, and reloads the last files 
 you had open to make it easy to jump back in during your next writing 
 session, and has many other features that make it such that only one 
 thing matters: your writing.

-- 
Tang Ke (Application develop of software department)
Tel：0086-512-52308628 Fax：0086-512-52308688
Phone:18962393077
E-mail:ta...@lemote.com  msn：ta...@lemote.com, mumut...@gmail.com
Web: http://www.lemote.com 
JiangSu ZhongKe Lemote Technology Co.,Ltd
MengLan Industry Park,YuShan,ChangShu City,JiangSu,China

<>

Re: perl: 64-bit integers and long doubles

[Niko Tyni]

On Tue, May 04, 2010 at 05:29:03PM +0200, Florian Weimer wrote:
> * Niko Tyni:
> 
> > The benefits are obviously improved numeric range and precision. The
> > downside is presumably increased memory usage. I have no measurement
> > data on this; suggestions on suitable tests would be welcome.
> 
> I have run into several incompatibilities between i386 and amd64 due
> to different Perl integer sizes, so I'm definitely in favor of 64-bit
> integers.
> 
> I'm not sure if long doubles are a win.  The rest of the world runs on
> 64 bit floating point numbers, so this would introduce additional
> incompatibilities.

I wasn't initially going for long doubles, but several upstream
developers recommended that they be enabled together.

 http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-04/msg00773.html 
 http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-04/msg00895.html

Given that we've already run into a dozen or so incompatibilities
with just the CPAN modules, -Duselongdouble seems to be a pretty
rare thing to do. I'm inclined to revert this setting.

On Wed, May 05, 2010 at 01:50:30PM +1000, Brendan O'Dea wrote:
> On 4 May 2010 22:54, Niko Tyni  wrote:

> > It would be possible to choose these settings separately for each 
> > architecture.
> > Should I exclude the 'smaller' architectures (armel, mips*?)
> 
> You could ask debian-...@lists.debian.org and the other ports lists,
> but it seems reasonable to include 64bit support only on those
> architectures where there is native 64 bit support in the chipset.

Good point. Can anybody list our "pure" 32-bit architectures off-hand
or suggest a simple test? Checking the instruction set for each one
is a bit on the laborous side...

Ideally, I'd like to have a concrete plan to send to the ports lists
and just ask for any objections.
-- 
Niko Tyni   nt...@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/20100508102808.ga9...@madeleine.local.invalid

ITP: connectagram -- a word unscrambling game

[Tang Ke]

Package: wnpp
Severity: wishlist
Owner: Tang Ke 

* Package name: connectagram
   Version: 1.0.1
   Upstream Authors: Graeme Gott 
* URL:http://gottcode.org/connectagram/
* License: GPL3
   Programming Lang: C++
   Description: a word unscrambling game

 The board consists of several scrambled words that are joined together.
 You can choose the length of the words, the amount of words, and the 
 pattern that the words are arranged in. The game provides a hint option
 for times when you are stuck.


-- 
Tang Ke (Application develop of software department)
Tel：0086-512-52308628 Fax：0086-512-52308688
Phone:18962393077
E-mail:ta...@lemote.com  msn：ta...@lemote.com, mumut...@gmail.com
Web: http://www.lemote.com 
JiangSu ZhongKe Lemote Technology Co.,Ltd
MengLan Industry Park,YuShan,ChangShu City,JiangSu,China

<>

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Stefano Zacchiroli]

On Fri, May 07, 2010 at 10:06:52AM +0200, Petter Reinholdtsen wrote:
> All of this is based on my belief that there are very few people
> testing with CONCURRENCY=makefile.  If a lot of people are using it
> successfully, it is less likely that there are many race conditions
> and edge cases left to fix, and enabling it for Squeeze would be a
> more safe option.
>
> Working with the boot system tend to make me very careful when
> introducing changes, as a wrong upload can render a lot of machines
> unable to boot. :)

Fair enough. IMO you've done quite a lot of communication on the matter
(at least to us developers) and I've personally been testing
CONCURRENCY=makefile in response to your repeated call for testers. At
this point, I doubt you can get significantly more testers without
changing the default concurrency level. All in all, it seems to be just
a matter of *when* doing that change to gather more feedback.

I understand that you've considered doing it now and that you've decided
not to (probably in accordance with the release team), which is fairly
understandable. It is just a pity to give up the chance to actually
understand how far are we from correct and complete dependency
declarations. Oh well, I guess it's just life.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Stefano Zacchiroli]

On Sat, May 08, 2010 at 11:37:10AM +0200, Marc Haber wrote:
> So it is the classical desktop vs. server situation. For my Debian
> servers, that get booted at most once a month, I don't give a damn
> about a faster boot.
> 
> I _do_ care, however, about not having migrations in the boot process
> which has the potential of breaking a system reboot, possibly making
> it necessary to obtain a means to access the console in case of
> breakage.

Sure, but I don't think that the server argument should be use to imply
that no changes, that benefit some of our users, are allowed at all.
Ideally, you shouldn't care about boot performance improvements, as long
as they do not introduce new (critical) bugs for your usage scenario.
Whether this is possible or not in the specific case at hand is what
we're all trying to understand in this thread.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Julien Cristau]

On Fri, May  7, 2010 at 19:27:54 +0200, Stefano Zacchiroli wrote:

> (Beside the nitpick on "we want" vs "we possibly want") I'd argue that
> it's because we want a faster boot from our users ASAP.
> 
As far as I'm concerned, "faster boot" is irrelevant.  Using an init
daemon that actually does its job of supervising services, and lets us
get rid of most of the stupidity and boilerplate of init scripts, otoh,
is overdue.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Marc Haber]

On Fri, 7 May 2010 19:27:54 +0200, Stefano Zacchiroli
 wrote:
>On Fri, May 07, 2010 at 06:15:24PM +0200, Marc Haber wrote:
>> On Fri, 7 May 2010 09:26:18 +0200, Stefano Zacchiroli  
>> wrote:
>> >The init.d world has changed quite a bit in recent years and might
>> >change even more in the next, it is possible that for Squeeze+1 we'll
>> >want to be elsewhere than at CONCURRENCY=makefile.
>> 
>> If we want to be elsewhere for squeeze+1, why do we need to do a
>> critical migration twice?
>
>(Beside the nitpick on "we want" vs "we possibly want") I'd argue that
>it's because we want a faster boot from our users ASAP.

So it is the classical desktop vs. server situation. For my Debian
servers, that get booted at most once a month, I don't give a damn
about a faster boot.

I _do_ care, however, about not having migrations in the boot process
which has the potential of breaking a system reboot, possibly making
it necessary to obtain a means to access the console in case of
breakage.

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/e1oagt8-0006uo...@swivel.zugschlus.de