date:20110214

Le lundi 14 février 2011 à 00:12 +0100, Iustin Pop a écrit : 
 With my sysadmin hat on, compilation on servers is a *very* big no-no,
 so if mkdeb doesn't work or if it doesn't provide nice modules, then m-a
 should stay in.

Regardless, there should be a way to provide the modules without
installing a compiler on servers.

 I know that right now, when backporting stuff at work, we have to drop
 the DKMS stuff and write our own packaging since DKMS doesn't play
 nicely with multiple kernel versions, embedding the kernel *and* package
 version in the final module version, etc. Things might have changed
 recently, but last time I looked DKMS was only good for desktops, and
 not as a reliable package-building method.

Worse, it is not a reliable method *at all*. When you have several
kernel versions installed, DKMS will only build the modules for one of
them, so if you reboot to another kernel, you get a brick.

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


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

Re: MBF: switching away from homepage pseudo-header

Le dimanche 13 février 2011 à 17:57 +0100, Andreas Tille a écrit : 
 IMHO one upload per Debian release with a recent Standards-Version
 should be done for every package.  It shows that the maintainer is
 active and continues to be interested in the package.  Given that our
 release cycle is  1 year minimum this is a not too hard request.

Thanks for volunteering to help. It is appreciated.

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


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

Re: chromium-browser is taking over all URLs

Le samedi 12 février 2011 à 01:15 +0900, Norbert Preining a écrit : 
  I'd say it should probably be reported as a minor bug in gvfs-open, to
  respect gnome settings before falling back to mimeinfo.cache.
 
 I consider that not minor. If alphabetic order is what I am forced to
 live with, that is 60ies computing style.

There are defaults shipped in gnome-session, precisely to avoid that
kind of issue.

With glib 2.28, the x-scheme-handler/* stuff becomes the new priority.
It just means we have to update epiphany to include it and gnome-session
to set the defaults.

I don’t think it requires more drama than that.

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


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

Re: Make Unicode bugs release critical? (was: Re: RFA: all my packages)

Le vendredi 11 février 2011 à 19:33 +0100, Axel Beckert a écrit : 
 Kicking out good and unique software, only because of missing or
 incomplete UTF-8 support, will surely lower Debian's quality more than
 missing or broken UTF-8 support in very few packages. And it would
 make those users (and devs) angry who need that software independently
 of working UTF-8 support or not.

Kicking out software with incomplete UTF-8 support sounds unfair.

Kicking out software that doesn’t work at all in UTF-8 locales and
requires the user to set a broken locale, OTOH, sounds like a sanitary
emergency.

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


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

Re: Upcoming FTPMaster meeting

Le vendredi 11 février 2011 à 21:30 +, Mark Hymers a écrit : 
 On Thu, 10, Feb, 2011 at 09:27:14PM +0100, Josselin Mouette spoke thus..
  Would it be possible to add support for ddebs?
 
 I'll stick it on the agenda.  I assume the details at
 http://wiki.debian.org/AutomaticDebugPackages are the most up to date
 notes you know of?

Looks correct to me. There are existing patches for debhelper and others
lying around, so the only missing piece should be dak. You can ask pochu
for details.

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


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

Re: The future of m-a and dkms

2011-02-14 Thread Tzafrir Cohen

On Sun, Feb 13, 2011 at 06:00:10PM -0500, Michael Gilbert wrote:
 On Sun, 13 Feb 2011 23:52:22 +0100 Christoph Anton Mitterer wrote:
 
  On Sun, 2011-02-13 at 23:21 +0100, Patrick Matthäi wrote:
   since we have got a stable release with dkms now, I am asking myself, if
   it is still necessary to support module-assistant.
   dkms is IMHO the better system and maintaining two different systems for
   kernel modules is a bit bloated.
  With dkms, can you also create packages of the modules?
  
  At least I found it always very useful, to create modules with m-a, or
  via make-kpkg, and provide them via local archives to all my Debian
  boxes. Can save quite some compilation time, and one doesn't need kernel
  header + build packages etc. on all nodes.
 
 Yes, there is the mkdeb command-line option, but I suppose that
 doesn't get as much testing as it should.

Is there a way to ask it to build for more than one kernel version?

My other issue with dkms is that I have to provide an explicit list of
modules beforehand as part of the spec. In the case of DAHDI there are
three modules that are added as part of the patches. This means I can't
easily include it upstream.

m-a did not need any patching for the extra modules.

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


-- 
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/20110214094459.gw22...@pear.tzafrir.org.il

Re: The future of m-a and dkms

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

Am So den 13. Feb 2011 um 23:21 schrieb Patrick Matthäi:
 since we have got a stable release with dkms now, I am asking myself, if
 it is still necessary to support module-assistant.
 dkms is IMHO the better system and maintaining two different systems for
 kernel modules is a bit bloated.

Well, dkms might be a good system for workstations, but on servers where
you want to have reliable systems and security first you do not want
dkms ever.

With m-a it was and is possible to create nice debian packages for
custom modules which can be installed on all systems getting all the
same modules. With dkms that is not possible. More over you need to have
a full gcc suite on all servers where you have custom modules. That is
not acceptable.

 I think there should be a decission for wheezy, how we should continue
 with it.

Why do you want to throw away good software in favour of a bloody hack?

I think debian is a server distribution with security and reliability in
mind and not a bleeding edge workstation that need to compile all
modules itself and is not that important to fail in security and/or
reliability.

Regards
   Klaus

Ps. On all systems of mine I was forced to blacklist dkms via
preferences to not break my systems with custom kernel.
- -- 
Klaus Ethgenhttp://www.ethgen.ch/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen kl...@ethgen.de
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEVAwUBTVkPyZ+OKpjRpO3lAQo//Af+OmYUEljpIwESHLnRQ2Oq0aBBBx8vYvfF
V0TjV72R5oZpxyAy7PhGpp82YQGTrh28r1ms+kQlFsZfgJljidBD9fkvL/Uh2NTF
VSCfjEi10kclUsIDedsNQqtsKn7mJbuPzpmPu65yZDggOWzDfCkkYe25omlhkK+I
YDLv/c+VyNKOlFHgE/OiptEC1zqoxz0gosbasw1zGtVOfcyehW1sS9L5mqcyYX0L
fyCdQB18R2wy9oRxDr+D+VQdqQJKxCl1ADFyVLkyVomawxQtmJesXBFtnQO0rnmD
cLXIJWhjHwGY0fmNHipWd8iJf2slpqeZCeZBZho519k7bErDN0CgJw==
=NwPA
-END PGP SIGNATURE-


-- 
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/20110214111937.gb31...@ikki.ethgen.ch

Re: chromium-browser is taking over all URLs

2011-02-14 Thread Raphael Hertzog

Hi,

On Mon, 14 Feb 2011, Josselin Mouette wrote:
 Le samedi 12 février 2011 à 01:15 +0900, Norbert Preining a écrit : 
   I'd say it should probably be reported as a minor bug in gvfs-open, to
   respect gnome settings before falling back to mimeinfo.cache.
  
  I consider that not minor. If alphabetic order is what I am forced to
  live with, that is 60ies computing style.
 
 There are defaults shipped in gnome-session, precisely to avoid that
 kind of issue.
 
 With glib 2.28, the x-scheme-handler/* stuff becomes the new priority.
 It just means we have to update epiphany to include it and gnome-session
 to set the defaults.
 
 I don’t think it requires more drama than that.

How is one supposed to prioritize between the various browsers?

What version of Gnome does the right thing to match what glib expect?

From a user point of view, it's disturbing and this change will reach
testing if we don't finish is properly soon enough (or open an appropriate
RC bug on glib to avoid having it migrate before the other components are
in place).

Not a drama, but still something we should care about.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110214112656.ga15...@rivendell.home.ouaza.com

Re: chromium-browser is taking over all URLs

Le lundi 14 février 2011 à 12:26 +0100, Raphael Hertzog a écrit : 
  There are defaults shipped in gnome-session, precisely to avoid that
  kind of issue.
  
  With glib 2.28, the x-scheme-handler/* stuff becomes the new priority.
  It just means we have to update epiphany to include it and gnome-session
  to set the defaults.
  
  I don’t think it requires more drama than that.
 
 How is one supposed to prioritize between the various browsers?

There will be a default selected in gnome-session, that can be changed
by user action. Without a session-wide default (any session manager can
set one, of course) a random choice (possibly alphabetical) is used.

 What version of Gnome does the right thing to match what glib expect?

Maybe 2.32, but it won’t be uploaded anyway, so that will be 3.0 to have
the GUI to configure that default.

 From a user point of view, it's disturbing and this change will reach
 testing if we don't finish is properly soon enough (or open an appropriate
 RC bug on glib to avoid having it migrate before the other components are
 in place).

We are used to have much more terrible breakage in testing/unstable
right after a release. If our concerns are now bugs wrt. setting the
default browser, it must mean we are doing *great* :)

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


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

Upstart and sysvinit in packages - Policy needed

In data Saturday 12 February 2011 05:55:16, Joachim Breitner ha scritto:

 I included some patches to have nodm gracefully uses the upstart job.

 Since those patches permits to have both init scripts in the system, no
 matter if upstart or sysvinit is used, a little more effort is required
 to proper build this package.
 
 thanks for your patches. I applied them to the repo besides the patch
 0005-Exit-from-the-sysvinit-script-to-use-the-upstart-job.patch. Is that
 code taken from some existing package?

I took the idea from discussion on bug #591791 and updated to work also with 
current sysvinit, that does currently not likes the syntax --version.

I include again this patch to permits other people to follow the discussion 
there, but is just a matter of :

if [ -e /etc/init/${NAME}.conf ]  /sbin/telinit --version /dev/null 21 
| grep -qs upstart
then
exit 0
fi

inside the sysvinit init script.

 I feel like the semantics of both
 upstart jobs and init scripts in one package should be the same across
 packages, so I’d rather see a common solution for that.

Yes, probably something better and simpler than my lines above should emerge 
from the discussion.

 But I'm stuck as you are (in the git repo) because dh will refuse to add
 an init.d script if an upstart job is available.
 Any hints on how to neatly have both init script files on the binary
 package?

 Maybe you could raise the issue on d-devel?

I CCed the bug in the policy that seems to be the best match for the 
discussion, anyway I'll CC also d-devel to have some help.

Even if all agrees that my code above is right (a thing that I cannot imagine 
to be true in any universe), if it vital that a policy is given for that 
issue.

I think it would be interesting for wheezy to easely permit an Admin to choose 
an alternate init system and to permit to package maintainer to carefully 
provide init script tailored for a particular system of interest.

Debhelper seems to not permit to have both, e.g., an upstart and a sysvinit 
script available in the package, although with a trick like the above 
mentioned one, the could happily live together in perfect armony, side by side 
on my wheezy.

-- 
ESC:wq

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

From f5f51aadd12c3053ad1bc7fee2253a3a5062aa5f Mon Sep 17 00:00:00 2001
From: Marco Amadori amado...@vdavda.com
Date: Fri, 11 Feb 2011 15:45:27 +0100
Subject: [PATCH 5/6] Exit from the sysvinit script to use the upstart job.

---
 debian/changelog |3 ++-
 debian/nodm.init |6 ++
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index faa6817..c9711ab 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,8 +6,9 @@ nodm (0.7-2) UNRELEASED; urgency=low
 
   [ Marco Amadori ]
   * Update Standards-Version to 3.9.1 (no changes required).
+  * Exit from the sysvinit script to use the upstart job.
 
- -- Marco Amadori marco.amad...@vdavda.com  Fri, 11 Feb 2011 15:36:30 +0100
+ -- Marco Amadori marco.amad...@vdavda.com  Fri, 11 Feb 2011 15:45:07 +0100
 
 nodm (0.7-1.1) unstable; urgency=low
 
diff --git a/debian/nodm.init b/debian/nodm.init
index 1b8bb6e..15ca887 100644
--- a/debian/nodm.init
+++ b/debian/nodm.init
@@ -18,6 +18,12 @@ NAME=nodm
 PIDDIR=/var/run/
 PIDFILE=${PIDDIR}/${NAME}.pid
 
+if [ -e /etc/init/${NAME}.conf ]  /sbin/telinit --version /dev/null 21 | grep -qs upstart
+then
+	# An upstart job exists and upstart is in use, exit gracefully
+	exit 0
+fi
+
 NODM_ENABLED=no
 NODM_XINIT=/usr/bin/xinit
 NODM_FIRST_VT=7
-- 
1.7.2.3

Re: chromium-browser is taking over all URLs

2011-02-14 Thread Andrei Popescu

On Lu, 14 feb 11, 12:33:49, Josselin Mouette wrote:
  
  How is one supposed to prioritize between the various browsers?
 
 There will be a default selected in gnome-session, that can be changed
 by user action. Without a session-wide default (any session manager can
 set one, of course) a random choice (possibly alphabetical) is used.

Maybe x-www-browser would be a good default?

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: Sourceful uploads [Re: Upcoming FTPMaster meeting]

On 2011-02-13, Tollef Fog Heen tfh...@err.no wrote:
 ]] Philipp Kern 
| Actually those build failures are nowadays sent to the PTS for further
| distribution (the buildd keyword).  I don't know how many are subscribed
| to those notifications, though.  (After all, they're not automatically
| sent to the maintainer.)
 Would people be opposed to changing that?  I would be quite happy to get
 mails if my packages FTBFS on various architectures, and I believe I'm
 competent to at least usually see if something fails because of
 something obvious or if it looks like a chroot/buildd issue.

I guess there are (at least) two options:

a) Auto-mail the current maintainer as determined by ftp's Maintainers file.
   Pro: Very easy to setup.
   Drawback: You'd be unable to opt-out.  Furthermore I don't know what the
   process is to agree on additional mailing of maintainers.

b) Auto-subscribe all maintainers to the PTS.  Phase out direct mails to
   the maintainer and switch them over to PTS mailings.  I guess that would
   also apply to dak and debbugs mails.

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/slrnili735.p8.tr...@kelgar.0x539.de

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

On 2011-02-13, Felipe Sateler fsate...@debian.org wrote:
 AFAIK, that service also mails when the build was successful, leading to
 a lot of noise.

Eh no, it never did.

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/slrnili753.p8.tr...@kelgar.0x539.de

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

On 2011-02-14, Raphael Geissert geiss...@debian.org wrote:
 Philipp Kern wrote:
 Actually those build failures are nowadays sent to the PTS for further
 distribution (the buildd keyword).  I don't know how many are subscribed
 to those notifications, though.  (After all, they're not automatically
 sent to the maintainer.)
 Taking a look at the database it seems everyone in the summary tag was also 
 subscribed to buildd. Now that I think about it, I remember reading about 
 doing that when the tag was introduced.

Yeah, I recalled something like that.  I don't know if somebody did the numbers
of comparing set(Maintainers + Uploaders) to the set of subscribers to a
package.

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/slrnili78b.p8.tr...@kelgar.0x539.de

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

2011-02-14 Thread Lucas Nussbaum

On 14/02/11 at 12:13 +, Philipp Kern wrote:
 On 2011-02-13, Tollef Fog Heen tfh...@err.no wrote:
  ]] Philipp Kern 
 | Actually those build failures are nowadays sent to the PTS for further
 | distribution (the buildd keyword).  I don't know how many are subscribed
 | to those notifications, though.  (After all, they're not automatically
 | sent to the maintainer.)
  Would people be opposed to changing that?  I would be quite happy to get
  mails if my packages FTBFS on various architectures, and I believe I'm
  competent to at least usually see if something fails because of
  something obvious or if it looks like a chroot/buildd issue.
 
 I guess there are (at least) two options:
 
 a) Auto-mail the current maintainer as determined by ftp's Maintainers file.
Pro: Very easy to setup.
Drawback: You'd be unable to opt-out.  Furthermore I don't know what the
process is to agree on additional mailing of maintainers.
 
 b) Auto-subscribe all maintainers to the PTS.  Phase out direct mails to
the maintainer and switch them over to PTS mailings.  I guess that would
also apply to dak and debbugs mails.

I would very much prefer (b). Maybe it would also be a good time to
split the mail part off the PTS (I don't see any excellent reason to
have the mail handling and the web pages closely linked together).

- 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/20110214122744.ga10...@xanadu.blop.info

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

2011-02-14 Thread Charles Plessy

Le Sun, Feb 13, 2011 at 10:46:53PM -0600, Raphael Geissert a écrit :
 Charles Plessy wrote:
  
  I would be happy to get build logs as well, or at least a link to an URL
  where they are dowloadable withouth HTML processing.
 
 You can always | html2text -utf8

Or scp 
buildd.debian.org:/srv/buildd.debian.org/db/${letter}/${package}/${version}/*bz2
 …

  For the moment, I only found raw logs in /srv/buildd.debian.org/db on
  buildd.debian.org, but that directory is not served over HTTP, so this
  excludes non-DDs for raw retrieval. (I am also wondering where to find the
  cryptographic signatures, but this is orthogonal to this discussion).
 
 What signatures?

The signatures that certify that the logs are really the ones for the the
packages we distribute. I suppose that the closest to this is the .changes
files signed by the buildd admins.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110214124850.gg18...@merveille.plessy.net

Re: Upstart and sysvinit in packages - Policy needed

2011-02-14 Thread Petter Reinholdtsen

[Marco Amadori]
 I think it would be interesting for wheezy to easely permit an Admin
 to choose an alternate init system

Sound like a good idea, if it do not give the Debian project a lot of
unneeded work.

 and to permit to package maintainer to carefully provide init script
 tailored for a particular system of interest.

Personally, I believe it the last point is a bad idea.  Asking package
maintainers to provide boot setup for several boot systems is going to
leave some of these setups to slowly decay as only the one used by the
package maintainer will get proper testing.

I believe we need to come up with a way where most or all package
maintainers (perhaps those handling kernel events and early boot stuff
should be expected) only need to maintain one boot setup for their
package, and this boot setup should be used by all the different boot
systems.

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

Re: Make Unicode bugs release critical? (was: Re: RFA: all my packages)

2011-02-14 Thread Ian Jackson

Josselin Mouette writes (Re: Make Unicode bugs release critical? (was: Re: 
RFA: all my packages)):
 Kicking out software that doesn?t work at all in UTF-8 locales and
 requires the user to set a broken locale, OTOH, sounds like a sanitary
 emergency.

Excellent, I look forward to the removal of python.  I always hated
that language anyway.

$ LC_CTYPE=en_GB.utf-8 python -c 'print u\u00a3'
unicode pound sign
$

But

$ LC_CTYPE=en_GB.utf-8 python -c 'print u\u00a3' | cat 
Traceback (most recent call last):
  File string, line 1, in module
UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in
position 0: ordinal not in range(128)
$

Ian.


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

Re: Make Unicode bugs release critical? (was: Re: RFA: all my packages)

2011-02-14 Thread Jakub Wilk


* Ian Jackson ijack...@chiark.greenend.org.uk, 2011-02-14, 12:42:
Kicking out software that doesn?t work at all in UTF-8 locales and 
requires the user to set a broken locale, OTOH, sounds like a sanitary 
emergency.


Excellent, I look forward to the removal of python.  I always hated 
that language anyway.


$ LC_CTYPE=en_GB.utf-8 python -c 'print u\u00a3'
unicode pound sign
$

But

$ LC_CTYPE=en_GB.utf-8 python -c 'print u\u00a3' | cat
Traceback (most recent call last):
 File string, line 1, in module
UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in
position 0: ordinal not in range(128)
$


This is the expected behaviour. Incidentally, it has nothing to do with 
UTF-8. You'll get the same result if you use a locale with a legacy 
encoding.


--
Jakub Wilk


--
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/20110214131425.ga4...@jwilk.net

Re: chromium-browser is taking over all URLs

2011-02-14 Thread Raphael Hertzog

On Mon, 14 Feb 2011, Josselin Mouette wrote:
  How is one supposed to prioritize between the various browsers?
 
 There will be a default selected in gnome-session, that can be changed
 by user action. Without a session-wide default (any session manager can
 set one, of course) a random choice (possibly alphabetical) is used.

How is that default communicated? An environment variable? A gconf key?

(I'm looking for a work-around for myself that can be used immediately)
 
 Maybe 2.32, but it won’t be uploaded anyway, so that will be 3.0 to have
 the GUI to configure that default.

That means in several months. :(

  From a user point of view, it's disturbing and this change will reach
  testing if we don't finish is properly soon enough (or open an appropriate
  RC bug on glib to avoid having it migrate before the other components are
  in place).
 
 We are used to have much more terrible breakage in testing/unstable
 right after a release. If our concerns are now bugs wrt. setting the
 default browser, it must mean we are doing *great* :)

Well, if we want to be serious about Constantly Usable Testing (and I wish
we do) I believe we should care about such things because they are far from
being details from an end-user perspective.

Filed #613381 to block glib2.0.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110214132838.gb16...@rivendell.home.ouaza.com

Re: chromium-browser is taking over all URLs

2011-02-14 Thread Norbert Preining

On Mo, 14 Feb 2011, Josselin Mouette wrote:
 We are used to have much more terrible breakage in testing/unstable
 right after a release. If our concerns are now bugs wrt. setting the
 default browser, it must mean we are doing *great* :)

Aehmm, I have set the default browser in about 10 places and still gnome
ignores it?!?!

Are you joking? How many more places should I care for?

Best wishes

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live  Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

NANHORON (n. medical)
A tiny valve concealed in the inner ear which enables a deaf
grandmother to converse quite normally when she feels like it, but
which excludes completely anything that sounds like a request to help
with laying the table.
--- Douglas Adams, The Meaning of Liff


-- 
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/20110214133239.gd22...@gamma.logic.tuwien.ac.at

OT: Python (was: Make Unicode bugs release critical?)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

lets start a python rant. I love to hate this language. :-)

Am Mo den 14. Feb 2011 um 14:14 schrieb Jakub Wilk:
 $ LC_CTYPE=en_GB.utf-8 python -c 'print u\u00a3'
 unicode pound sign
[...]
 $ LC_CTYPE=en_GB.utf-8 python -c 'print u\u00a3' | cat
 Traceback (most recent call last):
  File string, line 1, in module
 UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in
 position 0: ordinal not in range(128)
 
 This is the expected behaviour. Incidentally, it has nothing to do
 with UTF-8. You'll get the same result if you use a locale with a
 legacy encoding.

I see. It is funny to see python lovers to blame other for the bugs in
the language.

~ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;'
~ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;' | cat

Both gives the same result, a '£' sign as expected.

 * Ian Jackson ijack...@chiark.greenend.org.uk, 2011-02-14, 12:42:
 Excellent, I look forward to the removal of python.  I always
 hated that language anyway.

I hate them more. :-)

Regards
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.ch/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen kl...@ethgen.de
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEVAwUBTVkwIJ+OKpjRpO3lAQr9qAf+I4UXXNKso2hhr6BEjgn/o0IOpbI6/jhe
YwSf5rysUlb924NvtdOc1VzLoOff/uUDXOpW0VICSJMZRfVLZvVvdwaysa+SJj/f
0UL0CnuHogtan5uV627JFQRI5/VpQ9LXRc7w6w0+Eh8d7Pm/FJYomI4fuGAM0jPo
n1mFCeHSP2PiSIJ85cKWCqxsDkC4EDrPvrqol2ZJfuW1bVqqViGWMIrQ8RXzQ8JD
eSBHY0qjOCoMz1W46C4ruk3SVkX6FGe/V9U6XUG9kcAYlfpMyfeHDQ207P1tuEUH
dmD9gFA8ZpUgxHSZY43ONBnJlFynubPv7bmWoic7sez6V8zab6TFqg==
=KrXl
-END PGP SIGNATURE-


-- 
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/20110214133736.gb6...@ikki.ethgen.ch

Re: OT: Python (was: Make Unicode bugs release critical?)

On 2011-02-14, Klaus Ethgen kl...@ethgen.de wrote:
 ~ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;'
 ~ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;' | cat
 Both gives the same result, a '£' sign as expected.

And what's the value in that demonstration?  Yes, you can treat UTF8 like a
bytestream.  And the thread was about the problems that can arise of this.

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/slrnilidf3.11r.tr...@kelgar.0x539.de

Re: OT: Python (was: Make Unicode bugs release critical?)

2011-02-14 Thread Lars Wirzenius

On ma, 2011-02-14 at 14:37 +0100, Klaus Ethgen wrote:
 lets start a python rant. I love to hate this language. :-)

Let's not.

Let's not rant about any languages, or tools, or desktop environments.
Let's be constructive on Debian mailing lists, shall we?

We have plenty of side-channels for rants, sarcasm, snide remarks,
passive-aggressiveness, and other forms of anti-social behavior, let's
use those instead.



-- 
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/1297692931.31960.13.camel@tacticus

Need jquery.fancybox

2011-02-14 Thread Bastien ROUCARIES

tags 611125 + help
thanks

Hi,

As a developper of imagemagick, i am correcting bug #611125, and i need to 
package jquery.fancybox 

However I have no experience in javascript and I need some help.

Please package  jquery.fancybox 

Thanks

Bastien


-- 
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/201102141502.16230.roucaries.bastien+imagemag...@gmail.com

Re: OT: Python (was: Make Unicode bugs release critical?)

2011-02-14 Thread Jakub Wilk


* Klaus Ethgen kl...@ethgen.de, 2011-02-14, 14:37:

~ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;'
~ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;' | cat


Let me try...

$ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;' | isutf8
stdin: line 1, char 1, byte offset 1: invalid UTF-8 code


But I don't blame Perl for that. It's documented behavior, so I can 
either live with that or use another language.


--
Jakub Wilk


--
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/20110214143302.ga6...@jwilk.net

Re: OT: Python (was: Make Unicode bugs release critical?)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mo den 14. Feb 2011 um 15:15 schrieb Lars Wirzenius:
 On ma, 2011-02-14 at 14:37 +0100, Klaus Ethgen wrote:
  lets start a python rant. I love to hate this language. :-)
 
 Let's not.

'Till here it is personal desire.

 Let's not rant about any languages, or tools, or desktop environments.
 Let's be constructive on Debian mailing lists, shall we?

You are true. I just couldn't resist if someone was trying to blame all
other than the one that has the bug.

Regards
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.ch/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen kl...@ethgen.de
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEVAwUBTVk9hZ+OKpjRpO3lAQoy7Qf9EV1erqhNsAgfJ1ubQiitzufbk5Wq4rA/
rVh+Tpn4SHTE3D5Sw20UIPrUYonaQD6z8gokOkIdvzvgzVOBj3vPioFnWZy368QK
DUXymUPal23q+iwwV8FYNqq7ggnwpnT0DX1PNCmMUHZl21ZkMjMJO2cuv21ycD6I
JGBvA0w+dOVb7YfI+HGMwAlyT2gEkT7nsg8nlvYUU+EgzCaXjC1tdPHfe3QAYsQh
Pd0QDqhxFvwVRB9SskSas1JnjUh5DKMI/USr7a/+jP6dWeVQHIRglIN5uNFCq8kW
70jM2XCdTeZcdFy1lOiJ07YCYW1gg0kKCN+DlyEFJmJUzYsfP+4KsQ==
=H8Sg
-END PGP SIGNATURE-


-- 
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/20110214143445.gd6...@ikki.ethgen.ch

Re: OT: Python (was: Make Unicode bugs release critical?)

2011-02-14 Thread Adam Borowski

On Mon, Feb 14, 2011 at 02:02:11PM +, Philipp Kern wrote:
 On 2011-02-14, Klaus Ethgen kl...@ethgen.de wrote:
  ~ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;'
  ~ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;' | cat
  Both gives the same result, a '£' sign as expected.
 
 And what's the value in that demonstration?  Yes, you can treat UTF8 like a
 bytestream.  And the thread was about the problems that can arise of this.

Er, and tell me where exactly it makes sense to allow one encoding but not
another for a bytestream?

It appears that Python has a nasty bug where it ignores the encoding if
isatty(stdout) returns 0.  So let's go fixing or reporting that rather than
arguing about it.

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


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

Re: The future of m-a and dkms

2011-02-14 Thread Ben Hutchings

On Mon, Feb 14, 2011 at 12:19:37PM +0100, Klaus Ethgen wrote:
 Hello,
 
 Am So den 13. Feb 2011 um 23:21 schrieb Patrick Matthäi:
  since we have got a stable release with dkms now, I am asking myself, if
  it is still necessary to support module-assistant.
  dkms is IMHO the better system and maintaining two different systems for
  kernel modules is a bit bloated.
 
 Well, dkms might be a good system for workstations, but on servers where
 you want to have reliable systems and security first you do not want
 dkms ever.

DKMS was developed by Dell originally to support servers (as they
did not sell any other systems running Linux until recently).

 With m-a it was and is possible to create nice debian packages for
 custom modules which can be installed on all systems getting all the
 same modules. With dkms that is not possible. More over you need to have
 a full gcc suite on all servers where you have custom modules. That is
 not acceptable.
[...]

This is not true.  You can use 'dkms mkdeb' to build module packages
elsewhere.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20110214144323.ge28...@decadent.org.uk

Re: Re: chromium-browser is taking over all URLs

2011-02-14 Thread Fabian Greffrath


There will be a default selected in gnome-session, that can be changed
by user action. Without a session-wide default (any session manager can
set one, of course) a random choice (possibly alphabetical) is used.


It seems the panel to set the preferred applications has been removed 
from future versions of the control center on purpose of the GNOME 
developers:


http://osdir.com/ml/fedora-development/2011-02/msg00116.html

 - Fabian


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

Re: Upstart and sysvinit in packages - Policy needed

2011-02-14 Thread Joachim Breitner

Hi,

Am Montag, den 14.02.2011, 13:57 +0100 schrieb Petter Reinholdtsen:
 I believe we need to come up with a way where most or all package
 maintainers (perhaps those handling kernel events and early boot stuff
 should be expected) only need to maintain one boot setup for their
 package, and this boot setup should be used by all the different boot
 systems. 

a way like metainit? http://wiki.debian.org/MetaInit

The project died some two or three years ago and anyone is welcome to
try to revive it.

Greetings,
Joachim

-- 
Joachim nomeata Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

2011-02-14 Thread gregor herrmann

On Mon, 14 Feb 2011 13:27:38 +0900, Charles Plessy wrote:

 I would be happy to get build logs as well, or at least a link to an URL
 where they are dowloadable withouth HTML processing.
 
 For the moment, I only found raw logs in /srv/buildd.debian.org/db on
 buildd.debian.org, but that directory is not served over HTTP, so this 
 excludes
 non-DDs for raw retrieval.

getbuildlog(1) from devscripts downloads (almost, if you ignore a
small header/footer) text-versions of build logs.

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin,  developer - http://www.debian.org/
 `. `'   Member of VIBE!AT  SPI, fellow of Free Software Foundation Europe
   `-NP: Bettina Wegner: Magdalena


signature.asc
Description: Digital signature

Re: OT: Python (was: Make Unicode bugs release critical?)

2011-02-14 Thread Ian Jackson

Jakub Wilk writes (Re: OT: Python (was: Make Unicode bugs release critical?)):
 * Klaus Ethgen kl...@ethgen.de, 2011-02-14, 14:37:
 ~ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;'
 ~ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;' | cat
 
 Let me try...
 
 $ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;' | isutf8
 stdin: line 1, char 1, byte offset 1: invalid UTF-8 code

WTF.  OK, Perl's out too.

We'll have to write everything in dash :-).

Ian.


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

Re: Make Unicode bugs release critical? (was: Re: RFA: all my packages)

Le lundi 14 février 2011 à 12:42 +, Ian Jackson a écrit : 
 Josselin Mouette writes (Re: Make Unicode bugs release critical? (was: Re: 
 RFA: all my packages)):
  Kicking out software that doesn?t work at all in UTF-8 locales and
  requires the user to set a broken locale, OTOH, sounds like a sanitary
  emergency.
 
 Excellent, I look forward to the removal of python.  I always hated
 that language anyway.

From your reply I look more forward to the removal of vm, since it broke
the Unicode in my original email.

 $ LC_CTYPE=en_GB.utf-8 python -c 'print u\u00a3' | cat 
 Traceback (most recent call last):
   File string, line 1, in module
 UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in
 position 0: ordinal not in range(128)
 $


You must specify the encoding of your data in your bitstreams. I agree
this is inconvenient (and one of the things I dislike in Python), but it
is: 
 1. completely independent of the locale (UTF8 or not) 
 2. easy to work with once you understand how encodings in Python
work 
 3. much better in Python 3.

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


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

Re: The future of m-a and dkms

2011-02-14 Thread The Fungi

On Mon, Feb 14, 2011 at 08:29:38AM +0100, Hendrik Sattler wrote:
[...]
 It's like having to install a package with pear because horde
 upgrade scripts once again requires a module that is not packaged
 in Debian (which was the case for Lenny and is also the case for
 Squeeze :-( ). Can those tools be integrated with e.g. aptitude?

At least for cases like the latter example, I find dh-make-perl a
lot better than letting CPAN run roughshod over my filesystem.
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }


-- 
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/20110214155102.gb1...@yuggoth.org

Re: Upstart and sysvinit in packages - Policy needed

2011-02-14 Thread Tollef Fog Heen

]] Petter Reinholdtsen 

| I believe we need to come up with a way where most or all package
| maintainers (perhaps those handling kernel events and early boot stuff
| should be expected) only need to maintain one boot setup for their
| package, and this boot setup should be used by all the different boot
| systems.

That would mean limiting each init system to the limitations of the most
limited init system, which would be a sad state of affairs.  Also, I
don't believe there's a 1:1 correspondence between the semantics of all
the different init systems, making this a very hard if not impossible
job.

-- 
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/87y65iel60@qurzaw.varnish-software.com

Re: chromium-browser is taking over all URLs

Le lundi 14 février 2011 à 14:28 +0100, Raphael Hertzog a écrit : 
 On Mon, 14 Feb 2011, Josselin Mouette wrote:
  There will be a default selected in gnome-session, that can be changed
  by user action. Without a session-wide default (any session manager can
  set one, of course) a random choice (possibly alphabetical) is used.
 
 How is that default communicated? An environment variable? A gconf key?

The defaults are set in /etc/gnome/defaults.list. This file is used in
GNOME session since there is a XDG_DATA_DIRS indirectly pointing to it
(set in a Xsession script).

  We are used to have much more terrible breakage in testing/unstable
  right after a release. If our concerns are now bugs wrt. setting the
  default browser, it must mean we are doing *great* :)
 
 Well, if we want to be serious about Constantly Usable Testing (and I wish
 we do) I believe we should care about such things because they are far from
 being details from an end-user perspective.

Fully agreed. One of my concerns with CUT is that once such a change
reaches testing without the other impacted packages, it can stay buggy
for weeks, even months.

 Filed #613381 to block glib2.0.

Good. We can probably let it migrate once epiphany and iceweasel have
been fixed; unless you want the configuration GUI, which means
gnome-control-center 3.x - and if you really want to tie glib2.0 with
it, I’ll let you deal with the RT fallback :)

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


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

Re: Make Unicode bugs release critical? (was: Re: RFA: all my packages)

2011-02-14 Thread Henrique de Moraes Holschuh

On Mon, 14 Feb 2011, Josselin Mouette wrote:
 You must specify the encoding of your data in your bitstreams. I agree
 this is inconvenient (and one of the things I dislike in Python), but it
 is: 
  1. completely independent of the locale (UTF8 or not) 
  2. easy to work with once you understand how encodings in Python
 work 
  3. much better in Python 3.

As long as python 3 is compiled to use UCS-4 as the internal
representation, you mean.  Are our packages set to use UCS-4?

-- 
  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/20110214160108.ga7...@khazad-dum.debian.net

Re: chromium-browser is taking over all URLs

2011-02-14 Thread Norbert Preining

On Mo, 14 Feb 2011, Josselin Mouette wrote:
  How is that default communicated? An environment variable? A gconf key?
 
 The defaults are set in /etc/gnome/defaults.list. This file is used in

And per user?

 Good. We can probably let it migrate once epiphany and iceweasel have
 been fixed; unless you want the configuration GUI, which means

I need *any UI to control that? Currently I use vim to remove the
entries from the desktop files of midori, epiphany, chromium, which 
is not the best approach.

Best wishes

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live  Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

BELPER
A knob of someone else's chewing gum which you unexpectedly find your
hand resting on under a deck's top, under the passenger seat of your
car or on somebody's thigh under their skirt.
--- Douglas Adams, The Meaning of Liff


-- 
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/20110214160308.ge1...@gamma.logic.tuwien.ac.at

Re: The future of m-a and dkms

2011-02-14 Thread Marc Haber

On Mon, 14 Feb 2011 14:43:23 +, Ben Hutchings
b...@decadent.org.uk wrote:
On Mon, Feb 14, 2011 at 12:19:37PM +0100, Klaus Ethgen wrote:
 Am So den 13. Feb 2011 um 23:21 schrieb Patrick Matthäi:
  since we have got a stable release with dkms now, I am asking myself, if
  it is still necessary to support module-assistant.
  dkms is IMHO the better system and maintaining two different systems for
  kernel modules is a bit bloated.
 
 Well, dkms might be a good system for workstations, but on servers where
 you want to have reliable systems and security first you do not want
 dkms ever.

DKMS was developed by Dell originally to support servers (as they
did not sell any other systems running Linux until recently).

We all know which strange ideas hardware vendors have with regard to
system administration.

This is not true.  You can use 'dkms mkdeb' to build module packages
elsewhere.

That would be an acceptable workaround. Is there any way to prevent
dkms from trying to build modules for the currently running kernel
when module sources are installed (which is bound to fail in my build
chroot)?

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/e1pp0us-0007cu...@swivel.zugschlus.de

Re: Upstart and sysvinit in packages - Policy needed

2011-02-14 Thread Olaf van der Spek

On Mon, Feb 14, 2011 at 3:38 PM, Tollef Fog Heen tfh...@err.no wrote:
 ]] Petter Reinholdtsen

 | I believe we need to come up with a way where most or all package
 | maintainers (perhaps those handling kernel events and early boot stuff
 | should be expected) only need to maintain one boot setup for their
 | package, and this boot setup should be used by all the different boot
 | systems.

 That would mean limiting each init system to the limitations of the most
 limited init system, which would be a sad state of affairs.  Also, I

Most isn't all. IMO there's way too much code duplication in current
init scripts. Most daemons are pretty standard and shouldn't need any
special code in their init script.


-- 
Olaf


--
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/aanlktimza__j14yxhh-7hq7kbkqg-vkvowceva2ef...@mail.gmail.com

Re: Upstart and sysvinit in packages - Policy needed

2011-02-14 Thread Henrique de Moraes Holschuh

On Mon, 14 Feb 2011, Tollef Fog Heen wrote:
 That would mean limiting each init system to the limitations of the most
 limited init system, which would be a sad state of affairs.  Also, I

Yes.  So, we also have to set where we want the low bar.

 don't believe there's a 1:1 correspondence between the semantics of all
 the different init systems, making this a very hard if not impossible
 job.

Basically, anything that is not capable of doing _at least_ all that sysv-rc
can do is still missing required features.

We must first get to the point where the sysv-rc/startpar combination IS the
most limited initsystem (removing or fixing anything that is actually more
limited than sysv-rc+startpar).

After that, we will be better able to see the way forward.

-- 
  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/20110214161412.gb7...@khazad-dum.debian.net

Re: The future of m-a and dkms

2011-02-14 Thread Marc Haber

On Mon, 14 Feb 2011 00:12:48 +0100, Iustin Pop ius...@debian.org
wrote:
With my sysadmin hat on, compilation on servers is a *very* big no-no,
so if mkdeb doesn't work or if it doesn't provide nice modules, then m-a
should stay in.

+1

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/e1pp0nu-00070t...@swivel.zugschlus.de

Re: chromium-browser is taking over all URLs

Le mardi 15 février 2011 à 01:03 +0900, Norbert Preining a écrit : 
  The defaults are set in /etc/gnome/defaults.list. This file is used in
 
 And per user?

.local/share/applications/defaults.list and mimeapps.list
The former sets defaults associations, the latter is necessary to add
associations that are not mentioned in the desktop files (like in this
case, iceweasel/epiphany).

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


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

Re: The future of m-a and dkms

2011-02-14 Thread Patrick Matthäi

Am 14.02.2011 17:04, schrieb Marc Haber:

On Mon, 14 Feb 2011 14:43:23 +, Ben Hutchings
b...@decadent.org.uk wrote:

On Mon, Feb 14, 2011 at 12:19:37PM +0100, Klaus Ethgen wrote:

Am So den 13. Feb 2011 um 23:21 schrieb Patrick Matthäi:

since we have got a stable release with dkms now, I am asking myself, if
it is still necessary to support module-assistant.
dkms is IMHO the better system and maintaining two different systems for
kernel modules is a bit bloated.

Well, dkms might be a good system for workstations, but on servers where
you want to have reliable systems and security first you do not want
dkms ever.

DKMS was developed by Dell originally to support servers (as they
did not sell any other systems running Linux until recently).

We all know which strange ideas hardware vendors have with regard to
system administration.

This is not true. You can use 'dkms mkdeb' to build module packages
elsewhere.

That would be an acceptable workaround. Is there any way to prevent
dkms from trying to build modules for the currently running kernel
when module sources are installed (which is bound to fail in my build
chroot)?

I don't think so, also the maintainer scripts execute the dkms build,
e.g. [0].

But this would be a serious goal for dkms and its implementation in the
maintainer scripts.

[0]:
http://svn.debian.org/wsvn/pkg-fglrx/fglrx-driver/trunk/debian/fglrx-modules-dkms.postinst

--
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/4d59562a.5060...@debian.org

Re: Make Unicode bugs release critical? (was: Re: RFA: all my packages)

2011-02-14 Thread brian m. carlson

On Mon, Feb 14, 2011 at 02:01:08PM -0200, Henrique de Moraes Holschuh wrote:
 As long as python 3 is compiled to use UCS-4 as the internal
 representation, you mean.  Are our packages set to use UCS-4?

At least for python 3.1, yes:

common_configure_args = \
--prefix=/usr \
--enable-ipv6 \
--with-dbmliborder=bdb \
--with-wide-unicode \
--with-computed-gotos \
--with-system-expat \

The --with-wide-unicode enables UCS-4.  With a very few exceptions, I
believe all the recent Debian python packages have been compiled this
way.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: OT: Python (was: Make Unicode bugs release critical?)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mo den 14. Feb 2011 um 16:24 schrieb Ian Jackson:
 Jakub Wilk writes (Re: OT: Python (was: Make Unicode bugs release 
 critical?)):
  * Klaus Ethgen kl...@ethgen.de, 2011-02-14, 14:37:
  ~ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;'
  ~ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;' | cat
  
  Let me try...
  
  $ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;' | isutf8
  stdin: line 1, char 1, byte offset 1: invalid UTF-8 code
 
 WTF.  OK, Perl's out too.

No, it is not. 00a3 is just not a utf-8 character, it is unicode. To get
a correct utf-8 character you need to print \x{c2a3} and then isutf8 is
happy.

 We'll have to write everything in dash :-).

lisp. :-)

But now we get complete out of topic.

Regards
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.ch/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen kl...@ethgen.de
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEVAwUBTVlWk5+OKpjRpO3lAQohXgf9FC839X5Pozj2LZUJKd+X9Bcy5F/q+zWg
cdPlFkRL2BSq05M4+V8anb6vP47JdMMJfgc1oszNWZkYOQkgZdTy1GdCVF9o0jpD
xSlA7MVBt7ijTtfOlodzZiO6PyXPx7vo6AJGUufwb4KxekLR6vKq9fzlTLvvD/mH
lPPbCuZrY90eWqRjFeLyXA6Cmx+cJG5jt8nAAOzBjWTuENNp+vTFx1Lad13que7T
AAXrQupjCpRwAxfN8cuYMMIAFw5FCOyTQNAZXaAeMV1UOslVVdXlffUDB6uqpNvC
JPPL9PhughLVWtSxsm74emFCVkBQ75xTGMJTbCUCfMmdwTj3mD7uLw==
=J1JB
-END PGP SIGNATURE-


-- 
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/20110214162139.gf6...@ikki.ethgen.ch

Re: Re: chromium-browser is taking over all URLs

Le lundi 14 février 2011 à 15:33 +0100, Fabian Greffrath a écrit : 
 It seems the panel to set the preferred applications has been removed 
 from future versions of the control center on purpose of the GNOME 
 developers:
 
 http://osdir.com/ml/fedora-development/2011-02/msg00116.html

The disappearance of this applet in git master is very concerning, but I
just received mention on IRC (thanks fredp) that the functionality will
be back soon.

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


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

Re: The future of m-a and dkms

2011-02-14 Thread Vsevolod Velichko

2011/2/14 Marc Haber mh+debian-de...@zugschlus.de:
 That would be an acceptable workaround. Is there any way to prevent
 dkms from trying to build modules for the currently running kernel
 when module sources are installed (which is bound to fail in my build
 chroot)?

As far as I can see, it wouldn't be a problem.
Patrick Matthäi just mentioned the very complicated way used in fglrx,
however I've once written debian package dealing with dkms [0] and the
following expression in .postinst was doing all the work:

if [ $1 = configure ]; then
/usr/lib/dkms/common.postinst $PACKAGE_NAME $CVERSION  $ARCH $2
/usr/sbin/update-initramfs -u
fi

As one can see in /usr/lib/dkms/common.postinst, it looks for kernels,
rebuilds everything and so on.
So I suppose it shouldn't be very hard work to make it behave the way you want.

[0] http://mentors.debian.net/debian/pool/main/h/hp-acpi-kill/


Best wishes and have a nice day,
Vsevolod Velichko


--
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/AANLkTinZz6=dqye-mw7jxxtsqesqc5zxkqbkvon1b...@mail.gmail.com

Re: Upstart and sysvinit in packages - Policy needed

2011-02-14 Thread Salvo Tomaselli

 a way like metainit? http://wiki.debian.org/MetaInit
 
 The project died some two or three years ago and anyone is welcome to
 try to revive it.
Mh it claims it would work only for simple scripts, not for any kind of 
scripts, so not all the packages could be converted.

Bye
-- 
Salvo Tomaselli


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

Re: Cross-check autobuilt binary pkg with maintainer-provided pkg

2011-02-14 Thread Peter Samuelson


[Joey Hess]
 File sizes won't 100% stable unfortunatly but the rest should be.

Well, depending on how often I upgrade, vs. how often the buildd does
(and for that matter, how long my package sits in a queue before it is
built), there can be dependency changes due to build-depends shlibs /
symbols updates.  Unfortunately, it probably isn't possible to tell
whether a dependency change is harmless or something the maintainer
should be notified about and a change that.

So there'll be some noise in the 'debdiff'.  To minimize the noise,
_always_ upgrade before building and uploading, and time your build to
be just after a mirror pulse.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.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/20110214163827.gc10...@p12n.org

Re: OT: Python (was: Make Unicode bugs release critical?)

2011-02-14 Thread Ian Jackson

Klaus Ethgen writes (Re: OT: Python (was: Make Unicode bugs release 
critical?)):
 No, it is not. 00a3 is just not a utf-8 character, it is unicode. To get
 a correct utf-8 character you need to print \x{c2a3} and then isutf8 is
 happy.

When LC_CTYPE=en_GB.utf-8, programs which attempt to print unicode
characters to stdout should use UTF-8.  That's what LC_TYPE means.

Ian.


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

GNOME 3 and panel applets

[Bcc: all maintainers of GNOME applets]

Hi,

as it was already mentioned for other reasons, GNOME 3 is just around
the corner, and there are some big changes ahead. DO NOT PANIC: the
current desktop with gnome-panel and metacity will remain as an
alternative. Anyone wanting to troll about how gnome-shell sucks is
invited to do so elsewhere, since the topic here is gnome-panel.

The panel remains, but it will be a GTK3 / D-Bus panel. In its current
state, it doesn’t support the good old GTK2 / bonobo applets, of which
we have a lot in the archive. Upstream confirmed they don’t have time to
support them for 3.0 unless someone steps up to do the job. 

If you develop, maintain or use one of those packages, and you don’t
want it to disappear, your options are now:

 1. Prepare to disable gnome-panel support (that’s for packages
which already have other options, such as using the notification
area). 
 2. If meaningful (it depends on the applet), switch to another
technology such as libappindicator or the notification area. 
 3. Port your applet to GTK3 and the new D-Bus API. The bindings for
Python and C# will probably not work either, so you might have
to start with them. 
 4. Step up and do the work to add support for bonobo applets in the
panel.

Option 4 is the only way to keep all applets with low maintenance in
Debian. It should be possible by developing a gateway D-Bus service that
loads a bonobo applet in a process separate from the panel and proxies
signals through it. If you are interested, please get in touch with
upstream. If no one is interested, a large portion of the following list
is going to leave the archive. 


David Villa Alises david.vi...@uclm.es
   ows

Sebastien Bacher seb...@debian.org
   lock-keys-applet
   mboxcheck-applet
   netspeed

Vincent Bernat ber...@debian.org
   xnee

Michael Biebl bi...@debian.org
   tracker
   vinagre (U)

Laurent Bigonville bi...@debian.org
   gnome-mag (U)

Salvatore Bonaccorso salvatore.bonacco...@gmail.com
   giplet

Joachim Breitner nome...@debian.org
   link-monitor-applet

Tzafrir Cohen tzaf...@debian.org
   hdate-applet (U)

LI Daobing lidaob...@debian.org
   lunar-applet

Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org
   deskbar-applet
   gnome-mag (U)
   gnome-main-menu (U)
   gnome-netstatus (U)
   gnome-utils
   hamster-applet (U)
   mousetweaks (U)
   netspeed (U)
   ontv (U)
   seahorse-plugins (U)
   tsclient
   vinagre (U)

Debian Hebrew Packaging Team debian-hebrew-pack...@lists.alioth.debian.org
   hdate-applet
   hspell-gui

Debian Xfce Maintainers pkg-xfce-de...@lists.alioth.debian.org
   xfce4-xfapplet-plugin

Barry deFreese bddeb...@comcast.net
   xnee (U)

Sebastian Dröge sl...@debian.org
   deskbar-applet (U)
   gnome-mag (U)
   gnome-netstatus (U)
   gnome-utils (U)
   hamster-applet (U)
   mousetweaks (U)
   ontv (U)
   seahorse-plugins (U)
   service-discovery-applet
   vinagre (U)

Diego Fernández Durán di...@goedi.net
   quick-lounge-applet

Baruch Even bar...@debian.org
   hdate-applet (U)
   hspell-gui (U)

Luca Falavigna dktrkr...@debian.org
   remmina-gnome

Anthony Fok f...@debian.org
   lunar-applet (U)

Pedro Fragoso em...@ubuntu.com
   hamster-applet

Filippo Giunchedi fili...@esaurito.net
   sensors-applet (U)

Rudy Godoy r...@kernel-panik.org
   xfce4-xfapplet-plugin (U)

Gustavo Iñiguez Goya g...@kutxa.homeunix.org
   gnome-inm-forecast

Fabian Greffrath fab...@debian-unofficial.org
   glunarclock (U)

Debian QA Group packa...@qa.debian.org
   ddccontrol
   gnome-pilot

Jeremy Guitton debo...@free.fr
   ontv

Guido Günther a...@sigxcpu.org
   window-picker-applet

Jerry Haltom was...@larvalstage.net
   gnome-netstatus

Clement 'nodens' Hermann clement.herm...@free.fr
   tsclient (U)

Raphaël Hertzog hert...@debian.org
   indicator-applet (U)

Simon Huggins hug...@earth.li
   xfce4-xfapplet-plugin (U)

Lior Kaplan kap...@debian.org
   hdate-applet (U)
   hspell-gui (U)

Philipp Kern pk...@debian.org
   timer-applet

Julian Andres Klode j...@debian.org
   gnome-main-menu

Kilian Krause kil...@debian.org
   tsclient (U)

Mario Lang ml...@debian.org
   gnome-mag (U)

John Lightsey light...@debian.org
   apt-watch

Martin Loschwitz madk...@debian.org
   xfce4-xfapplet-plugin (U)

Francois Marier franc...@debian.org
   verbiste
   workrave

Fladischer Michael fladischermich...@fladi.at
   panflute

Robert Millan rmh.deb...@aybabtu.com
   gnote

Loic Minier l...@dooz.org
   computertemp (U)
   gnome-mag (U)
   gnome-netstatus (U)
   gnome-utils (U)
   netspeed (U)
   service-discovery-applet (U)
   tsclient (U)

Emilio Pozuelo Monfort po...@debian.org
   deskbar-applet (U)
   gnome-main-menu (U)
   gnome-utils (U)
   hamster-applet (U)
   mousetweaks (U)
   ontv (U)
   seahorse-plugins
   vinagre

Sam Morris s...@robots.org.uk
   sensors-applet

Josselin Mouette j...@debian.org
   deskbar-applet (U)
   gnome-mag (U)
   gnome-netstatus

Re: GNOME 3 and panel applets

2011-02-14 Thread Luca Falavigna

Il 14/02/2011 18.17, Josselin Mouette ha scritto:
 Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org
tsclient

Removed from unstable.

 Luca Falavigna dktrkr...@debian.org
remmina-gnome

Will be removed as soon as remmina 0.9.3 hits wheezy.

-- 

  .''`.
 : :' :   Luca Falavigna dktrkr...@debian.org
 `. `'
   `-



signature.asc
Description: OpenPGP digital signature

Re: GNOME 3 and panel applets

2011-02-14 Thread Joachim Breitner

Hi,

thanks for the heads-up.

Am Montag, den 14.02.2011, 18:17 +0100 schrieb Josselin Mouette:
  3. Port your applet to GTK3 and the new D-Bus API. The bindings for
 Python and C# will probably not work either, so you might have
 to start with them. 

do you have some pointers to migration guides or similar?

Also, for link-monitor-applet, I need to find out whether gob2 needs to
be updated. But it seems that GTK-3 still uses GLib-2, so this might
work.

Thanks,
Joachim

-- 
Joachim nomeata Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: OT: Python (was: Make Unicode bugs release critical?)

2011-02-14 Thread Konstantin Khomoutov

On Mon, 14 Feb 2011 16:43:11 +
Ian Jackson ijack...@chiark.greenend.org.uk wrote:

 Klaus Ethgen writes (Re: OT: Python (was: Make Unicode bugs release
 critical?)):
  No, it is not. 00a3 is just not a utf-8 character, it is unicode.
  To get a correct utf-8 character you need to print \x{c2a3} and
  then isutf8 is happy.
 
 When LC_CTYPE=en_GB.utf-8, programs which attempt to print unicode
 characters to stdout should use UTF-8.  That's what LC_TYPE means.

By the way,

$ LC_CTYPE=en_GB.utf-8 echo 'puts \x00a3\n'|tclsh|isutf8
$
$ LC_CTYPE=en_GB.utf-8 echo 'puts \x00a3\n'|tclsh|xxd -p
c2a30a0a
$

But RMS told the world not to use Tcl.


-- 
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/20110214203601.715df57c.kos...@domain007.com

Re: Bug#591791: Upstart and sysvinit in packages - Policy needed

On Mon, Feb 14, 2011 at 11:17:20AM +0100, Marco Amadori wrote:
 In data Saturday 12 February 2011 05:55:16, Joachim Breitner ha scritto:

  I included some patches to have nodm gracefully uses the upstart job.

  Since those patches permits to have both init scripts in the system, no
  matter if upstart or sysvinit is used, a little more effort is required
  to proper build this package.

  thanks for your patches. I applied them to the repo besides the patch
  0005-Exit-from-the-sysvinit-script-to-use-the-upstart-job.patch. Is that
  code taken from some existing package?

 I took the idea from discussion on bug #591791 and updated to work also with 
 current sysvinit, that does currently not likes the syntax --version.

 I include again this patch to permits other people to follow the discussion 
 there, but is just a matter of :

 if [ -e /etc/init/${NAME}.conf ]  /sbin/telinit --version /dev/null 21 
 | grep -qs upstart
 then
   exit 0
 fi

 inside the sysvinit init script.

This does not appear to be consistent with
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791#42, in particular:

  If nothing else, an init script that returns success on 'start' without
  starting the service would be inconsistent with how we've expected all
  init scripts to work to date.  (It's not *quite* a policy violation, but
  near enough to.) And if you argue that nothing should ever call these init
  scripts because everything should use invoke-rc.d, then things using this
  upstart-aware interface will never see the return code anyway, right?

Oh, and if you redirect telinit stdout and stderr both to /dev/null, that
grep is always going to return false.


Also, I strongly counsel *against* shipping this, or any, upstart job in a
Debian package until this policy bug is *fixed*.  The conversation is
ongoing, and deploying such upstart jobs now realistically just runs the
(very high) risk that you'll have more work to do on your package later once
the policy interfaces are refined and implemented.


BTW, my goal is to provide this functionality in an lsb-style function; that
will preclude both the call to 'exit' here (with any return value) or
checking for ${NAME} in the code; anyway, a package should darn well know
whether it's set up to ship both an upstart job and an init script and not
need to query the filesystem to figure that out.


 Debhelper seems to not permit to have both, e.g., an upstart and a sysvinit 
 script available in the package, although with a trick like the above 
 mentioned one, the could happily live together in perfect armony, side by 
 side 
 on my wheezy.

Debhelper doesn't permit both because policy does not specify how this is
supposed to work.  I have already submitted a patch to debhelper (bug
#577040), which I have asked Joey to sit on until policy is finalized and
various other key packages have implemented the necessary support (namely,
sysvinit and lsb-base).

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


-- 
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/20110214180645.gd17...@virgil.dodds.net

Re: GNOME 3 and panel applets

2011-02-14 Thread Emilio Pozuelo Monfort

On 14/02/11 17:36, Joachim Breitner wrote:
 Also, for link-monitor-applet, I need to find out whether gob2 needs to
 be updated. But it seems that GTK-3 still uses GLib-2, so this might
 work.

There's no GLib 3.

Emilio


-- 
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/4d596bd3.6040...@debian.org

Re: Upstart and sysvinit in packages - Policy needed

2011-02-14 Thread Marco d'Itri

On Feb 14, Tollef Fog Heen tfh...@err.no wrote:

 That would mean limiting each init system to the limitations of the most
 limited init system, which would be a sad state of affairs.  Also, I
 don't believe there's a 1:1 correspondence between the semantics of all
 the different init systems, making this a very hard if not impossible
 job.
Agreed. If there is no or little improvement over sysv-rc then we can as
well save the time needed for such a big change.
I am even unsure that it's worth supporting more than one init package.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: GNOME 3 and panel applets

2011-02-14 Thread Loïc Minier

 Thanks for starting this effort!  Some comments below:

On Mon, Feb 14, 2011, Josselin Mouette wrote:
 Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org
deskbar-applet
gnome-mag (U)
gnome-main-menu (U)
gnome-netstatus (U)
gnome-utils
hamster-applet (U)
mousetweaks (U)
netspeed (U)
ontv (U)
seahorse-plugins (U)
tsclient
vinagre (U)

 * tsclient got RMed

 * deskbar-applet and gnome-main-menu are larger bodies of code, but I
   don't think they are relevant upstream anymore; probably hard to keep
   alive; RM?

 * I believe hamster-applet is still in wide use, albeit I don't use it
   myself; I would hope it gets adapted

 * vinagre is probably wide use as well.

 * Most of the others are probably half-relevant; not sure what's widely
   used in gnome-utils;  maybe gnome-mag is helpful for a11y for some
   people?  hard to tell

 Loic Minier l...@dooz.org
computertemp (U)
gnome-mag (U)
gnome-netstatus (U)
gnome-utils (U)
netspeed (U)
service-discovery-applet (U)
tsclient (U)

 The ones not listed above are not very important in my eyes and are
 candidates for RM as well

Thanks,
-- 
Loïc Minier


-- 
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/20110214184102.gf3...@bee.dooz.org

Re: Upcoming FTPMaster meeting

2011-02-14 Thread Luk Claes

On 02/14/2011 08:39 AM, Raphael Hertzog wrote:
 On Sat, 12 Feb 2011, Guillem Jover wrote:
 Hi!

 On Fri, 2011-02-11 at 11:33:10 +0800, Paul Wise wrote:
 On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings b...@decadent.org.uk wrote:
 Since there is no support for auto-building arch-independent binaries

 I would hope that throwing away developer built debs would also apply
 to arch-independent packages, IIRC that was part of the proposal.
 There was talk of a Build-Architecture field for Architecture: all
 stuff that can only be built on certain architectures (firmware,
 bootloaders etc where there is no cross-compiler available).

 Using Build-Architecture would be a workaround, it should not be
 needed once multiarch is in place and those packages are built for
 their respective architectures.
 
 While technically true, this can be discussed. I can imagine that you
 might not want to configure multiarch on your system just because you
 need some bootloaders files (e.g. syslinux-common in a CD build process).
 
 Using multi-arch to solve this problem means changing the package from
 arch: all to arch: i386 (or the specific arch set that you're interested
 in).

Build-Architecture would be used by the buildd network to see on which
buildds the package can be built, so I don't get the it's no problem
once it's built as that is a chicken-and-egg problem...

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/4d598224.9050...@debian.org

Re: GNOME 3 and panel applets

2011-02-14 Thread David Villa

On Mon, 14 Feb 2011 18:17:36 +0100
Josselin Mouette j...@debian.org osó decir:

 [Bcc: all maintainers of GNOME applets]
 
 Hi,
 
 ...
 
 If no one is interested, a large portion of the
 following list is going to leave the archive. 
 
 
 David Villa Alises david.vi...@uclm.es
ows

I am also the upstream author of this applet. It has poor maintenance
(sorry) but it meets the required functionality in my way. Probably I
will develop a new version for gnome3 from scratch (python bindings
required), so I do not foresee to adapt or modify it in its current
form.

Cheers


signature.asc
Description: PGP signature

Re: Upstart and sysvinit in packages - Policy needed

On Monday 14 February 2011 20:55:06 Tollef Fog Heen wrote:

 | I believe we need to come up with a way where most or all package
 | maintainers (perhaps those handling kernel events and early boot stuff
 | should be expected) only need to maintain one boot setup for their
 | package, and this boot setup should be used by all the different boot
 | systems.
 
 That would mean limiting each init system to the limitations of the most
 limited init system, which would be a sad state of affairs.  Also, I
 don't believe there's a 1:1 correspondence between the semantics of all
 the different init systems, making this a very hard if not impossible
 job.

I was about to replying exactly that, only not so well written :-)

In addiction to that, generally speaking, I was asking two things, one was if 
a policy could emerge to sort the init issues, the other point is regarding 
debhelper, maybe should I file a bug for the problem of debhelper hiding the 
sysvinit script if an upstart job is available?

I have some doubts because the two questions are related and it is not 
properly a bug, more a wanted design derived from an hint as it is now.

-- 
ESC:wq


-- 
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/201102142059.53736.marco.amad...@gmail.com

Re: Upstart and sysvinit in packages - Policy needed

On Monday 14 February 2011 21:00:09 Olaf van der Spek wrote:
 On Mon, Feb 14, 2011 at 3:38 PM, Tollef Fog Heen tfh...@err.no wrote:
  ]] Petter Reinholdtsen
  
  | I believe we need to come up with a way where most or all package
  | maintainers (perhaps those handling kernel events and early boot stuff
  | should be expected) only need to maintain one boot setup for their
  | package, and this boot setup should be used by all the different boot
  | systems.
  
  That would mean limiting each init system to the limitations of the most
  limited init system, which would be a sad state of affairs.  Also, I
 
 Most isn't all. IMO there's way too much code duplication in current
 init scripts. Most daemons are pretty standard and shouldn't need any
 special code in their init script.

The problem is that they may, not that they should have different initscripts 
for different init system.

The best of two worlds would be having a sane defaults for any initscript out 
there from a common source but that a package maintainer could choose to 
carefully write customized init script for the differents init systems.

-- 
ESC:wq


-- 
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/201102142102.11806.marco.amad...@gmail.com

Re: Bug#591791: Upstart and sysvinit in packages - Policy needed

On Monday 14 February 2011 21:07:57 Steve Langasek wrote:

  if [ -e /etc/init/${NAME}.conf ]  /sbin/telinit --version /dev/null
  21
  | grep -qs upstart
  then
  exit 0
  fi
  
  inside the sysvinit init script.
 
 This does not appear to be consistent with
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791#42, in particular:
 
   If nothing else, an init script that returns success on 'start' without
   starting the service would be inconsistent with how we've expected all
   init scripts to work to date.  (It's not *quite* a policy violation, but
   near enough to.) And if you argue that nothing should ever call these
 init scripts because everything should use invoke-rc.d, then things using
 this upstart-aware interface will never see the return code anyway, right?

I'm so sorry, in the hurry I put an exit 0 for the wrong psycological reasons, 
you are right.

 Oh, and if you redirect telinit stdout and stderr both to /dev/null, that
 grep is always going to return false.

This is a bad mistake for sure! I apologize to all for being so naïve and 
publishing a bad tested code (I tested an uncommitted previous release, then I 
improved and submitted without tests!!)

Again, I apologize.

 Also, I strongly counsel *against* shipping this, or any, upstart job in a
 Debian package until this policy bug is *fixed*.

This seems a good point, having that debhelper prefer upstart jobs over 
sysvinit when both are available.

  Debhelper seems to not permit to have both, e.g., an upstart and a
  sysvinit script available in the package, although with a trick like the
  above mentioned one, the could happily live together in perfect armony,
  side by side on my wheezy.
 
 Debhelper doesn't permit both because policy does not specify how this is
 supposed to work.  I have already submitted a patch to debhelper (bug
 #577040), which I have asked Joey to sit on until policy is finalized and
 various other key packages have implemented the necessary support (namely,
 sysvinit and lsb-base).

I hope that this discussion could help in clarifing this matter, probably the 
times are mature enough.

-- 
ESC:wq


--
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/201102142114.45270.marco.amad...@gmail.com

Re: GNOME 3 and panel applets

2011-02-14 Thread brian m. carlson

On Mon, Feb 14, 2011 at 06:17:36PM +0100, Josselin Mouette wrote:
 The panel remains, but it will be a GTK3 / D-Bus panel. In its current
 state, it doesn’t support the good old GTK2 / bonobo applets, of which
 we have a lot in the archive. Upstream confirmed they don’t have time to
 support them for 3.0 unless someone steps up to do the job. 

Will the existing GNOME 2 gnome-applets be ported to GNOME 3?  After
all, they are part of GNOME.  They're also not listed in your dd-list.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

New libgphoto2 in sid

2011-02-14 Thread David Paleino

Hello everybody,
I'm planning to upload libgphoto2 2.4.10.1 to sid.
There's a package currently in experimental, and I'm now asking maintainers of
dependant packages (BCCed) to check whether their package compiles and works
fine with it. A dd-list is attached.

Kindly,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


libgphoto2-2.depends
Description: Binary data


signature.asc
Description: PGP signature

Re: Upcoming FTPMaster meeting

Hi Joerg,

On Thu, Feb 03, 2011 at 10:05:27PM +0100, Joerg Jaspert wrote:

 Attached below is a tentative agenda. This is an unsorted list and we
 might not get to every point. We might also have missed any number of
 points, if so feel free to tell us about them.

One other item I'd like to submit for the ftp team's consideration is
multiarch support.  The plan for initial multiarch deployment calls for all
architectures to remain self-hosting, but it's not too early to start
thinking about how multiarch might be used in support of partial
architectures in the archive, or how this could solve the problem of arch:
all packages that can only be built on one architecture (which got a passing
mention up-thread).

And although for the most part the roll-out of multiarch is intended to be
backwards-compatible and a smooth transition, there are two small extensions
required to the package relationship fields in order to deploy a full
multiarch stack in the archive.  The archive software doesn't need to
*support* these extensions in the context of a self-hosting port, but
anything that parses deps or build-deps (dak?, sbuild, wanna-build) should
recognize these extensions and strip them off:

 - Depends: foo:any - an extension used to declare that foo of any
   architecture satisfies the dependency.  The archive and official
   autobuilders should treat this as equivalent to 'Depends: foo'.[1]

 - Build-Depends: foo:native - an extension used to declare that a
   build-dependency must be satisfied using the package for the build arch,
   not the host arch, when cross-compiling.  The archive and official
   autobuilders should treat this as equivalent to 'Build-Depends: foo'.[2]

I'm happy to file bug reports against the appropriate components if that's
the right thing to do here; I'm raising it on the list first because I'm not
sure whether dak is actually affected, and if so whether ftp.debian.org is
the right place to report the issue.

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

[1] https://wiki.ubuntu.com/MultiarchSpec [2] http://bugs.debian.org/558095


signature.asc
Description: Digital signature

Re: OT: Python

2011-02-14 Thread Russ Allbery

Ian Jackson ijack...@chiark.greenend.org.uk writes:
 Klaus Ethgen writes:

 No, it is not. 00a3 is just not a utf-8 character, it is unicode. To
 get a correct utf-8 character you need to print \x{c2a3} and then
 isutf8 is happy.

 When LC_CTYPE=en_GB.utf-8, programs which attempt to print unicode
 characters to stdout should use UTF-8.  That's what LC_TYPE means.

Perl is specifically documented to not do this for backward compatibility
reasons.  In Perl, which is the one I know best, you are required to
decode input and encode output if you want to have UTF-8 handling.

windlord:~ env LC_CTYPE=en_US.UTF-8 perl -e 'print \x{00a3}\n'
glyph for mangled Unicode character
windlord:~ env LC_CTYPE=en_US.UTF-8 perl -MEncode -e 'print encode(utf-8, 
\x{00a3}\n)'
proper Unicode pound sign

See perlunicode(1).  There are a variety of reasons for this that turn out
to be fairly good ones if you don't want to badly break a bunch of
existing Perl scripts that were dealing with, for example, binary data.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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

How to close a Ubuntu bug?

2011-02-14 Thread Erik Schanze (Debian)

Hi,

one of my packages (antiword) has an open bug in Ubuntu
https://bugs.launchpad.net/ubuntu/+source/antiword/+bug/237918
that was fixed for a while in Debian
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464490.

I'd like to help them and would close it, but did not found how.
(I'm not member of launchpad an I don't want to become one.)

Is there any mail interface like Debian has?


Thanks,

Erik


-- 
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/4d599f1e.60...@gmx.de

Re: Upcoming FTPMaster meeting

On 2011-02-14, Luk Claes l...@debian.org wrote:
 On 02/14/2011 08:39 AM, Raphael Hertzog wrote:
 On Sat, 12 Feb 2011, Guillem Jover wrote:
 On Fri, 2011-02-11 at 11:33:10 +0800, Paul Wise wrote:
 On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings b...@decadent.org.uk 
 wrote:
 Since there is no support for auto-building arch-independent binaries
 I would hope that throwing away developer built debs would also apply
 to arch-independent packages, IIRC that was part of the proposal.
 There was talk of a Build-Architecture field for Architecture: all
 stuff that can only be built on certain architectures (firmware,
 bootloaders etc where there is no cross-compiler available).
 Using Build-Architecture would be a workaround, it should not be
 needed once multiarch is in place and those packages are built for
 their respective architectures.
 While technically true, this can be discussed. I can imagine that you
 might not want to configure multiarch on your system just because you
 need some bootloaders files (e.g. syslinux-common in a CD build process).
 Using multi-arch to solve this problem means changing the package from
 arch: all to arch: i386 (or the specific arch set that you're interested
 in).
 Build-Architecture would be used by the buildd network to see on which
 buildds the package can be built, so I don't get the it's no problem
 once it's built as that is a chicken-and-egg problem...

To be fair Guillem did address this.  With multiarch you'd make it
arch:specific arch in that case and be able to install it on foreign archs.
(I.e. I could get my sparc BIOS through multiarch as it was built on sparc.)

You'd lose the notion of it being useful on other architectures (that's the
arch:all - arch:i386 Raphael's talking about), though.  But then packages
like qemu-system would just depend on openbios-sparc:sparc, no?  If you
don't need to deal with them directly that'd be pretty transparent.

Also you could gracefully deal with something like debian-installer-netboot-
images, which would in theory need building on every
architecture, building a different arch:all on each of them.  Multiarch would
result in the usual set of arch:any binaries.

But then so far multiarch didn't happen... ):

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/slrnilj8fu.1mr.tr...@kelgar.0x539.de

Re: Upcoming FTPMaster meeting

2011-02-14 Thread Roger Leigh

On Mon, Feb 14, 2011 at 01:08:51PM -0800, Steve Langasek wrote:
 And although for the most part the roll-out of multiarch is intended to be
 backwards-compatible and a smooth transition, there are two small extensions
 required to the package relationship fields in order to deploy a full
 multiarch stack in the archive.  The archive software doesn't need to
 *support* these extensions in the context of a self-hosting port, but
 anything that parses deps or build-deps (dak?, sbuild, wanna-build) should
 recognize these extensions and strip them off:
 
  - Depends: foo:any - an extension used to declare that foo of any
architecture satisfies the dependency.  The archive and official
autobuilders should treat this as equivalent to 'Depends: foo'.[1]

sbuild switched to using Dpkg::Deps for parsing dependencies; we would
ideally want an equivalent to Dpkg::Deps::reduce_arch() to do the
stripping (if reduce_arch wasn't the appropriate place to do it
already).  This saves us from reimplementing yet another parser, and
it getting outdated; we currently use it for stripping dependencies
not needed for the build's architecture.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: How to close a Ubuntu bug?

2011-02-14 Thread Scott Kitterman

Erik Schanze (Debian) schan...@gmx.de wrote:

Hi,

one of my packages (antiword) has an open bug in Ubuntu
https://bugs.launchpad.net/ubuntu/+source/antiword/+bug/237918
that was fixed for a while in Debian
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464490.

I'd like to help them and would close it, but did not found how.
(I'm not member of launchpad an I don't want to become one.)

Is there any mail interface like Debian has?

There is, but it still requires an account. I marked it fixed.

Scott K



-- 
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/4a5295cf-a15a-4c56-a91c-6a3904c55...@email.android.com

Re: Upstart and sysvinit in packages - Policy needed

2011-02-14 Thread Tollef Fog Heen

]] Henrique de Moraes Holschuh 

| On Mon, 14 Feb 2011, Tollef Fog Heen wrote:
|  That would mean limiting each init system to the limitations of the most
|  limited init system, which would be a sad state of affairs.  Also, I
| 
| Yes.  So, we also have to set where we want the low bar.

I'd rather prefer a solution where we either choose a single more
capable init system going forward or we say that any init script system
must support sysvinit scripts as well as having native jobs (be upstart
or systemd) being able to mask sysvinit jobs of the same name.  This
would allow for improvements without being kept back to the extent we
are today.

|  don't believe there's a 1:1 correspondence between the semantics of all
|  the different init systems, making this a very hard if not impossible
|  job.
| 
| Basically, anything that is not capable of doing _at least_ all that sysv-rc
| can do is still missing required features.

Agreed.  Do we know which, if any, are at that level?

| We must first get to the point where the sysv-rc/startpar combination IS the
| most limited initsystem (removing or fixing anything that is actually more
| limited than sysv-rc+startpar).

Must we?

I'd like to get rid of the solutions that no longer fit, but at the same
time, having to first remove whatever solutions exist today seems
unnecessary for deciding on the road forward.

-- 
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/87y65icmav@qurzaw.varnish-software.com

Re: Make Unicode bugs release critical?

2011-02-14 Thread Ron Johnson


On 02/14/2011 10:39 AM, Ian Jackson wrote:
[snip]


The fact that naive Python programs work (honouring LC_CTYPE as they
should) unless you pipe their output to something is clearly a bug.
The fact that it's a specification bug doesn't mean it's not a bug.



It doesn't seem to work for me.

$ python -V
Python 2.6.6

$ LC_CTYPE=en_GB.utf-8 python -c 'print u\u00a3'
Traceback (most recent call last):
  File string, line 1, in module
UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in 
position 0: ordinal not in range(128)


$ LC_CTYPE=en_GB.utf-8 python -c 'print u\uc2a3'
Traceback (most recent call last):
  File string, line 1, in module
UnicodeEncodeError: 'ascii' codec can't encode character u'\uc2a3' 
in position 0: ordinal not in range(128)


$ perl -v

This is perl, v5.10.1 (*) built for x86_64-linux-gnu-thread-multi
(with 51 registered patches, see perl -V for more detail)

$ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = en_GB.utf-8,
LANG = en_US.UTF-8
are supported and installed on your system.
perl: warning: Falling back to the standard locale (C).
£

$ locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=


--
The normal condition of mankind is tyranny and misery.
Milton Friedman


--
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/4d59a558.5020...@cox.net

Re: How to close a Ubuntu bug?

2011-02-14 Thread Paul Tagliamonte

On Mon, Feb 14, 2011 at 4:46 PM, Scott Kitterman deb...@kitterman.com wrote:
 Erik Schanze (Debian) schan...@gmx.de wrote:

Hi,

one of my packages (antiword) has an open bug in Ubuntu
https://bugs.launchpad.net/ubuntu/+source/antiword/+bug/237918
that was fixed for a while in Debian
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464490.

I'd like to help them and would close it, but did not found how.
(I'm not member of launchpad an I don't want to become one.)

Is there any mail interface like Debian has?

 There is, but it still requires an account. I marked it fixed.

 Scott K



 --
 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/4a5295cf-a15a-4c56-a91c-6a3904c55...@email.android.com



If you're preparing an upload, the changelog syntax is (LP: N).
Might come in handy later :)

Cheers,
Paul

-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq


-- 
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/AANLkTikNArnxvNt1kQOkaaXwsh6fpi=+3sthuqo7-...@mail.gmail.com

Re: Kernel

2011-02-14 Thread Darren Salt

I demand that Adrian von Bidder may or may not have written...

[snip]
 As Paul has said, there is a patch to include the Debian logo at boot. As
 far as I know, the kernel still displays the traditional penguin at boot if
 a framebuffer is used, but note that on recent systems framebuffer has been
 replaced by kms which is loaded a bit later in the boot process and doesn't
 display any logo (either tux or the swirl with the patch.)

KMS still uses framebuffers, but they're provided by different modules
(radeon instead of radeonfb, for example). You still get the penguin(s) if
the relevant module is built into the kernel image or (I assume) is loaded
early enough.

-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back!
| + Lobby friends, family, business, government.WE'RE KILLING THE PLANET.

The coast was clear.


-- 
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/51ab0c8f30%li...@youmustbejoking.demon.co.uk

Re: Make Unicode bugs release critical?

2011-02-14 Thread The Fungi

On Mon, Feb 14, 2011 at 03:57:44PM -0600, Ron Johnson wrote:
 It doesn't seem to work for me.
[...]
 $ LC_CTYPE=en_GB.utf-8 python -c 'print u\u00a3'
 Traceback (most recent call last):
   File string, line 1, in module
 UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in
 position 0: ordinal not in range(128)
[...]
 $ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;'
 perl: warning: Setting locale failed.
 perl: warning: Please check that your locale settings:
   LANGUAGE = (unset),
   LC_ALL = (unset),
   LC_CTYPE = en_GB.utf-8,
   LANG = en_US.UTF-8
 are supported and installed on your system.
 perl: warning: Falling back to the standard locale (C).
[...]

You probably don't have an en_GB.utf-8 locale (maybe you have
localepurge installed?). I bet en_US.utf-8 will net you different
results.
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }


-- 
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/20110214222615.gd1...@yuggoth.org

Bug#613450: ITP: kyotocabinet -- Kyoto Cabinet is an efficient database library like GDBM and NDBM.

2011-02-14 Thread Gabriel de Perthuis

Package: wnpp
Severity: wishlist
Owner: Gabriel de Perthuis g2p.code+deb...@gmail.com

* Package name: kyotocabinet
  Version : 1.2.43
  Upstream Author : Mikio Hirabayashi i...@fallabs.com
* URL : http://fallabs.com/kyotocabinet/
* License : GPL-3+
  Programming Lang: C++
  Description : Kyoto Cabinet is an efficient database library like GDBM 
and NDBM.

Kyoto Cabinet is a library of routines for managing a database. The database
is a simple data file containing records, each is a pair of a key and a
value. Every key and value is serial bytes with variable length. Both binary
data and character string can be used as a key and a value. Each key must be
unique within a database. There is neither concept of data tables nor data
types. Records are organized in hash table or B+ tree.

Kyoto Cabinet runs very fast. For example, elapsed time to store one million
records is 0.9 seconds for hash database, and 1.1 seconds for B+ tree
database. Moreover, the size of database is very small. For example,
overhead for a record is 16 bytes for hash database, and 4 bytes for B+ tree
database. Furthermore, scalability of Kyoto Cabinet is great. The database
size can be up to 8EB (9.22e18 bytes).

Kyoto Cabinet is written in the C++ language, and provided as API of C++, C,
Java, Python, Ruby, Perl, and Lua. Kyoto Cabinet is available on platforms
which have API conforming to C++03 with the TR1 library extensions. Kyoto
Cabinet is a free software licensed under the GNU General Public License. On
the other hand, a commercial license is also provided. If you use Kyoto
Cabinet within a proprietary software, the commercial license is required.



-- 
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/20110214221604.17893.72124.reportbug@localhost6.localdomain6

Bug#613452: ITP: kyototycoon -- Kyoto Tycoon is a network interface to the DBM Kyoto Cabinet.

2011-02-14 Thread Gabriel de Perthuis

Package: wnpp
Severity: wishlist
Owner: Gabriel de Perthuis g2p.code+deb...@gmail.com

* Package name: kyototycoon
  Version : 0.9.33
  Upstream Author : Mikio Hirabayashi i...@fallabs.com
* URL : http://fallabs.com/kyototycoon/
* License : GPL3+
  Programming Lang: C++
  Description : Kyoto Tycoon is a network interface to the DBM Kyoto 
Cabinet.

Kyoto Tycoon is a network interface to the DBM Kyoto Cabinet. The server
permits concurrent and remote connections to Kyoto Cabinet databases.

The network protocol between the server and clients is HTTP so that you can
write client applications and client libraries in almost all popular languages.
Both of RESTful-style interface by the GET, HEAD, PUT, DELETE methods and
RPC-style inteface by the POST method are supported. The server can handle more
than 10 thousand connections at the same time because it uses modern I/O event
notification facilities such as epoll and kqueue of underlying systems. The
server supports high availability mechanisms, which are hot backup, update
logging, and asynchronous replication. The server can embed Lua, a lightweight
script language so that you can define arbitrary operations of the database.

The server program of Kyoto Tycoon is written in the C++ language. It is
available on platforms which have API conforming to C++03 with the TR1 library
extensions. Kyoto Tycoon is a free software licensed under the GNU General
Public License.



-- 
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/20110214222026.16305.98289.reportbug@localhost6.localdomain6

Re: How to close a Ubuntu bug?

2011-02-14 Thread Micah Gersten

On 02/14/2011 04:03 PM, Paul Tagliamonte wrote:
 On Mon, Feb 14, 2011 at 4:46 PM, Scott Kitterman deb...@kitterman.com wrote:
 Erik Schanze (Debian) schan...@gmx.de wrote:

 Hi,

 one of my packages (antiword) has an open bug in Ubuntu
 https://bugs.launchpad.net/ubuntu/+source/antiword/+bug/237918
 that was fixed for a while in Debian
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464490.

 I'd like to help them and would close it, but did not found how.
 (I'm not member of launchpad an I don't want to become one.)

 Is there any mail interface like Debian has?
 There is, but it still requires an account. I marked it fixed.

 Scott K



 --
 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/4a5295cf-a15a-4c56-a91c-6a3904c55...@email.android.com


 If you're preparing an upload, the changelog syntax is (LP: N).
 Might come in handy later :)

 Cheers,
 Paul

Actually, it's LP: #NN
Micah


-- 
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/4d59b07d.4040...@ubuntu.com

Re: How to close a Ubuntu bug?

2011-02-14 Thread Kai Wasserbäch

Dear Scott,
Scott Kitterman schrieb am 14.02.2011 22:46:
 Erik Schanze (Debian) schan...@gmx.de wrote:
 Is there any mail interface like Debian has?
 
 There is, but it still requires an account. I marked it fixed.

can Ubuntu that at least open said interface up to Debian Developers using their
Debian address and sign the message with their key (as available from
keyring.debian.org)? Because this account requirement is really annoying. I
don't want an account on Launchpad but as long as I'm forced to see bug reports
on my PTS page (ok I could hide them with Element Hiding Helper or something) I
want an easy interface like mailto:cont...@bugs.debian.org, so I can at least
close or reassign bugs in case that is needed (an example where I'd like to have
reassign capabilities: I've one bug showing for Skanlite, that is certainly not
a bug in Skanlite but one in libksane (if it still exists at all, that ist),
upstream agrees with me on this).

Kind regards,
Kai Wasserbäch

P.S.: I understand that you are not Ubuntu and this is not your decision, but
maybe you could pass this on to the proper people. ;)



-- 

E-Mail: cu...@debian.org
IRC: Curan
Jabber: dri...@debianforum.de
URL: http://wiki.debian.org/C%C3%B9ran
GnuPG: 0xE1DE59D2  0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2



signature.asc
Description: OpenPGP digital signature

Wanted: system/volunteer to do whole-archive rebuild (×3) to test sbuild

2011-02-14 Thread Roger Leigh

Hi folks,

sbuild, which does the job of building binary packages on our buildds,
uses a built-in build-dependency resolver (internal) to work out
what packages need installing/removing in order to satisfy a package's
Build-Depends and Build-Conflicts.  Unfortunately, this has a number
of bugs, e.g. #403246, as well as serious maintainability issues which
make it less than desirable.  Last year, we introduced two new
resolvers, apt and aptitude which delegate the somewhat complex
build dependency resolving to the tools which are best at it.

Now that squeeze is out, it would be great if we could revisit the
discussion about which build dependency resolver we want to use on
our buildds.  The main concern here is that switching resolvers will
change exactly which packages are installed in some situations, mainly
in the case of packages depending on alternatives, which could lead to
different packages being installed, inconsistent selection of packages
being installed, or broken package builds.  The intenal resolver was
dumb: it just always chose the first dependency even if it was
unsatisfiable.  aptitude is far cleverer; apt somewhere in between,
though we've tweaked aptitude to behave as close to stupid as we can.

However, in order to understand the implications, we need concrete
data about exactly how they differ, and under what situations.  What
I would like to do is a rebuild of the squeeze archive (since it
won't change between builds) using each of the internal, apt and
aptitude resolvers.  Since sbuild records the complete set of
packages available immediate before the build starts, we can extract
this from the build logs, find any differences, and determine what
causes them, if and when they occur.

What is needed:
- a stable/testing/unstable system
- with a lot of disc space
- and a lot of spare CPU cycles
- sbuild 0.60.9-1 (to be uploaded soon; or pull from git)
  [with automatic update/upgrade disabled, and logging to alt log dir
   for each run]
- schroot
- LVM
- The builds will use a cleanly debootstrapped squeeze on an LVM LV,
  which can be freshly snapshotted for each build, as on buildds.
  This will make the comparisons between resolvers identical.

We don't need to store the built binaries, so they could be thrown; we
just need to store the build logs.  It might also be possible to skip
some of the archive; we only really need a representative sample to
do a realistic test, if time and disc space are issues.

If there are any project machines available that could do this, that
would be great!


Many thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

2011-02-14 Thread Charles Plessy

Le Mon, Feb 14, 2011 at 04:37:36PM +0100, gregor herrmann a écrit :
 On Mon, 14 Feb 2011 13:27:38 +0900, Charles Plessy wrote:
 
  I would be happy to get build logs as well, or at least a link to an URL
  where they are dowloadable withouth HTML processing.
  
  For the moment, I only found raw logs in /srv/buildd.debian.org/db on
  buildd.debian.org, but that directory is not served over HTTP, so this 
  excludes
  non-DDs for raw retrieval.
 
 getbuildlog(1) from devscripts downloads (almost, if you ignore a
 small header/footer) text-versions of build logs.

Hi Gregor,

it is exactly that header and footer that I was reffering to when I wrote
“withouth HTML processing”.

Would it be acceptable to serve the build logs as plain text files ? Would a
patch be welcome ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110215000905.gb3...@merveille.plessy.net

Re: Make Unicode bugs release critical?

2011-02-14 Thread Ron Johnson


On 02/14/2011 04:26 PM, The Fungi wrote:

On Mon, Feb 14, 2011 at 03:57:44PM -0600, Ron Johnson wrote:

It doesn't seem to work for me.

[...]

$ LC_CTYPE=en_GB.utf-8 python -c 'print u\u00a3'
Traceback (most recent call last):
   File string, line 1, inmodule
UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in
position 0: ordinal not in range(128)

[...]

$ LC_CTYPE=en_GB.utf-8 perl -e 'print \x{00a3}\n;'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = en_GB.utf-8,
LANG = en_US.UTF-8
 are supported and installed on your system.
perl: warning: Falling back to the standard locale (C).

[...]

You probably don't have an en_GB.utf-8 locale (maybe you have
localepurge installed?). I bet en_US.utf-8 will net you different
results.


That's it...

$ LC_CTYPE=en_US.utf-8 python -c 'print u\u00a3'
£

$ LC_CTYPE=en_US.utf-8 perl -e 'print \x{00a3}\n;'
£

No localepurge, but when initially building the system, I only 
installed one or two locales.


--
The normal condition of mankind is tyranny and misery.
Milton Friedman


--
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/4d59c47d.7060...@cox.net

Re: How to close a Ubuntu bug?

2011-02-14 Thread Scott Kitterman

Kai Wasserbäch cu...@debian.org wrote:

Dear Scott,
Scott Kitterman schrieb am 14.02.2011 22:46:
 Erik Schanze (Debian) schan...@gmx.de wrote:
 Is there any mail interface like Debian has?
 
 There is, but it still requires an account. I marked it fixed.

can Ubuntu that at least open said interface up to Debian Developers
using their
Debian address and sign the message with their key (as available from
keyring.debian.org)? Because this account requirement is really
annoying. I
don't want an account on Launchpad but as long as I'm forced to see bug
reports
on my PTS page (ok I could hide them with Element Hiding Helper or
something) I
want an easy interface like mailto:cont...@bugs.debian.org, so I can
at least
close or reassign bugs in case that is needed (an example where I'd
like to have
reassign capabilities: I've one bug showing for Skanlite, that is
certainly not
a bug in Skanlite but one in libksane (if it still exists at all, that
ist),
upstream agrees with me on this).

Kind regards,
Kai Wasserbäch

P.S.: I understand that you are not Ubuntu and this is not your
decision, but
maybe you could pass this on to the proper people. ;)

It's been brought up with Launchpad developers before. Doing so is technically 
feasible, but not implemented.

Scott K



-- 
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/bcedfb09-323a-4e40-b720-c198bf943...@email.android.com

Re: Make Unicode bugs release critical?

2011-02-14 Thread Adam Borowski

On Mon, Feb 14, 2011 at 06:10:37PM -0600, Ron Johnson wrote:
 On 02/14/2011 04:26 PM, The Fungi wrote:
 You probably don't have an en_GB.utf-8 locale (maybe you have
 localepurge installed?). I bet en_US.utf-8 will net you different
 results.
 
 That's it...
 
 No localepurge, but when initially building the system, I only
 installed one or two locales.

No one would expect an USian to use a GB locale.

The problem is, there is currently no way to request UTF-8 encoding without
specifying language.  It's a remnant of ancient locales where ISO-8859-1
didn't make sense for pl_PL nor ISO-8859-2 for fr_FR.

Also, iconv() functions are really inconvenient to use, it'd be much easier
to use regular wide char functions predictably.

In other words: can I has C.UTF-8 guaranteed?

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


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

Bug#613476: ITP: libjio -- library for journalled, transaction-oriented I/O

2011-02-14 Thread Jonathan Yu

Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libjio
  Version : 1.01
  Upstream Author : Jonathan Yu jaw...@cpan.org
* URL : http://blitiri.com.ar/p/libjio/
* License : BOLA
  Programming Lang: C
  Description : library for journalled, transaction-oriented I/O

libjio is a userspace library for journalled, transaction-oriented file
input/output operations. It provides a simple interface to perform common
file operations in a non-intrusive threadsafe and atomic way, with safe and
fast crash recovery.

The library guarantees file integrity even after unexpected crashes, never
leaving your files in an inconsistent state. On disk, the file you work on
is exactly like a regular one, but a special directory is created to store
in-flight transactions.



-- 
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/aanlktikhorknu1qpax3a80whvzn8fq1phq8f_tf8s...@mail.gmail.com

Re: Upcoming FTPMaster meeting

On Mon, Feb 14, 2011 at 09:52:32PM +, Roger Leigh wrote:
 On Mon, Feb 14, 2011 at 01:08:51PM -0800, Steve Langasek wrote:
  And although for the most part the roll-out of multiarch is intended to be
  backwards-compatible and a smooth transition, there are two small extensions
  required to the package relationship fields in order to deploy a full
  multiarch stack in the archive.  The archive software doesn't need to
  *support* these extensions in the context of a self-hosting port, but
  anything that parses deps or build-deps (dak?, sbuild, wanna-build) should
  recognize these extensions and strip them off:

   - Depends: foo:any - an extension used to declare that foo of any
 architecture satisfies the dependency.  The archive and official
 autobuilders should treat this as equivalent to 'Depends: foo'.[1]

 sbuild switched to using Dpkg::Deps for parsing dependencies; we would
 ideally want an equivalent to Dpkg::Deps::reduce_arch() to do the
 stripping (if reduce_arch wasn't the appropriate place to do it
 already).  This saves us from reimplementing yet another parser, and
 it getting outdated; we currently use it for stripping dependencies
 not needed for the build's architecture.

Does this need to be backported to the squeeze dpkg to be usable on the
buildds?  I assume it will.  (I'm making my list of features we're going to
want backported in apt/dpkg for buildds in relation to this, since we missed
the boat by a bit for squeeze.)

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


signature.asc
Description: Digital signature

Re: Wanted: system/volunteer to do whole-archive rebuild (×3) to test sbuild

2011-02-14 Thread Raphael Geissert

Roger Leigh wrote:
 However, in order to understand the implications, we need concrete
 data about exactly how they differ, and under what situations.  What
 I would like to do is a rebuild of the squeeze archive (since it
 won't change between builds) using each of the internal, apt and
 aptitude resolvers.  Since sbuild records the complete set of
 packages available immediate before the build starts, we can extract
 this from the build logs, find any differences, and determine what
 causes them, if and when they occur.

Am I missing something or your really don't need none of the following:

 What is needed:
[...]
 - with a lot of disc space
 - and a lot of spare CPU cycles
 - schroot
 - LVM
 - The builds will use a cleanly debootstrapped squeeze on an LVM LV,
   which can be freshly snapshotted for each build, as on buildds.
   This will make the comparisons between resolvers identical.

?
All you seem to want is the resolver's results, nothing else.
In fact, a simple, clean, chroot running apt-get --dry-run build-dep, and 
aptitude --simulate build-dep should do it.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/ijcpqp$g0f$1...@dough.gmane.org

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

2011-02-14 Thread Raphael Geissert

Charles Plessy wrote:

 Le Sun, Feb 13, 2011 at 10:46:53PM -0600, Raphael Geissert a écrit :
 What signatures?
 
 The signatures that certify that the logs are really the ones for the the
 packages we distribute. I suppose that the closest to this is the .changes
 files signed by the buildd admins.

There are no signatures for log files; only .changes files are signed by the 
buildd admins and the buildd signs the .dsc and ta-da.

Adding support for auto-signing on the buildd's no longer sounds so scary, 
right?

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/ijcpue$g0f$2...@dough.gmane.org

Re: Upcoming FTPMaster meeting

On 2011-02-15, Steve Langasek vor...@debian.org wrote:
 sbuild switched to using Dpkg::Deps for parsing dependencies; we would
 ideally want an equivalent to Dpkg::Deps::reduce_arch() to do the
 stripping (if reduce_arch wasn't the appropriate place to do it
 already).  This saves us from reimplementing yet another parser, and
 it getting outdated; we currently use it for stripping dependencies
 not needed for the build's architecture.
 Does this need to be backported to the squeeze dpkg to be usable on the
 buildds?  I assume it will.  (I'm making my list of features we're going to
 want backported in apt/dpkg for buildds in relation to this, since we missed
 the boat by a bit for squeeze.)

Uh.  As that'd involve the host dpkg, it likely should go into squeeze proper,
which is at the SRM's discretion.  I'm pretty sure that DSA won't like the idea
of using dpkg from -backports.  Same for apt.

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/slrnilk6g7.2i6.tr...@kelgar.0x539.de

Re: Upcoming FTPMaster meeting

On Tue, Feb 15, 2011 at 06:15:35AM +, Philipp Kern wrote:
 On 2011-02-15, Steve Langasek vor...@debian.org wrote:
  sbuild switched to using Dpkg::Deps for parsing dependencies; we would
  ideally want an equivalent to Dpkg::Deps::reduce_arch() to do the
  stripping (if reduce_arch wasn't the appropriate place to do it
  already).  This saves us from reimplementing yet another parser, and
  it getting outdated; we currently use it for stripping dependencies
  not needed for the build's architecture.
  Does this need to be backported to the squeeze dpkg to be usable on the
  buildds?  I assume it will.  (I'm making my list of features we're going to
  want backported in apt/dpkg for buildds in relation to this, since we missed
  the boat by a bit for squeeze.)

 Uh.  As that'd involve the host dpkg, it likely should go into squeeze proper,
 which is at the SRM's discretion.  I'm pretty sure that DSA won't like the 
 idea
 of using dpkg from -backports.  Same for apt.

I wasn't suggesting the use of -backports here, I was referring to
backported features in the general sense of the term.  Of course I'm not
taking it for granted that you would accept these packages into squeeze and
intended to ask you if this would be ok, once there were actual patches to
be considered.  But since you're here: would targeted patches to backport
support for :any/:native be ok for a stable update?  :-)

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


signature.asc
Description: Digital signature

Bug#613486: ITP: libgtextutils -- Gordon Text_utils library

2011-02-14 Thread Charles Plessy

Package: wnpp
Severity: wishlist
Owner: Charles Plessy ple...@debian.org

Hello everybody,

I will package some bioinformatics tools called FASTX-Toolkit, and they
require a separate library, gtextutils, which is used only by them. But
since it is distributed as a separate tarball, the simplest is still
to distribte it as a separate package. Here are the control and copyright
files. I did not have much to say in the description…

Source: libgtextutils
Section: science
Priority: optional
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
DM-Upload-Allowed: yes
Uploaders: Charles Plessy ple...@debian.org
Build-Depends: debhelper (= 8), autotools-dev
Standards-Version: 3.9.1
Vcs-Browser: http://git.debian.org/?p=debian-med/libgtextutils.git
Vcs-Git: git://git.debian.org/git/debian-med/libgtextutils.git
Homepage: http://hannonlab.cshl.edu/fastx_toolkit/

Package: libgtextutils-dev
Section: libdevel
Architecture: any
Depends: libgtextutils0 (= ${binary:Version}), ${misc:Depends}
Description: Gordon Text_utils library (development files)
 Development files for the Gordon Text_utils (gtextutils) library.

Package: libgtextutils0
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Gordon Text_utils library
 The Gordon Text_utils (gtextutils) library is a text utilities library used by
 the FASTX-Toolkit, a suite of programs for biological sequence analysis. 


Format: DEP-5
Source: http://hannonlab.cshl.edu/fastx_toolkit/libgtextutils-0.6.tar.bz2

Files: *
Copyright: © 2008,2009 Assaf Gordon (gor...@cshl.edu)
License: AGPLv3
  This program is free software: you can redistribute it and/or modify
  it under the terms of the GNU Affero General Public License as published 
by
  the Free Software Foundation, either version 3 of the License, or
  (at your option) any later version.
 .
  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU Affero General Public License for more details.
 .
  You should have received a copy of the GNU Affero General Public License
  along with this program.  If not, see http://www.gnu.org/licenses/

Files: src/gtextutils/natsort.h
Copyright: © 2000, 2004 by Martin Pool mbp sourcefrog net
 © 2009 Assaf Gordon (gor...@cshl.edu)
License: AGPLv3 and zlib

Files: src/gtextutils/strnatcmp.c src/gtextutils/strnatcmp.h
Copyright: © 2000, 2004 by Martin Pool mbp sourcefrog net
License: zlib
  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this software.
 .
  Permission is granted to anyone to use this software for any purpose,
  including commercial applications, and to alter it and redistribute it
  freely, subject to the following restrictions:
 .
  1. The origin of this software must not be misrepresented; you must not
 claim that you wrote the original software. If you use this software
 in a product, an acknowledgment in the product documentation would be
 appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
 misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.

Files: src/Makefile.am src/gtextutils/Makefile.am Makefile.am m4/Makefile.am 
doc/Makefile.am tests/Makefile.am
Copyright: © 2008 Assaf Gordon gor...@cshl.edu
License:
  This file is free software; as a special exception the author gives
  unlimited permission to copy and/or distribute it, with or without 
  modifications, as long as this notice is preserved.
 .  
  This program is distributed in the hope that it will be useful, but
  WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Files: src/gtextutils/inbuf1.hpp src/gtextutils/outbuf3.hpp
Copyright: © 1999 Nicolai M. Josuttis
 © 2009 Assaf Gordon (gor...@cshl.edu)
License: AGPLv3 and other

License: other
  Permission to copy, use, modify, sell and distribute this software
  is granted provided this copyright notice appears in all copies.
  This software is provided as is without express or implied
  warranty, and with no claim as to its suitability for any purpose.

License: AGPLv3
…



-- 
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/20110215063303.30629.5677.report...@anx178.gsc.riken.jp

Re: Upstart and sysvinit in packages - Policy needed

2011-02-14 Thread Joachim Breitner

Hi,

Am Montag, den 14.02.2011, 15:38 +0100 schrieb Tollef Fog Heen:
]] Petter Reinholdtsen

| I believe we need to come up with a way where most or all package
| maintainers (perhaps those handling kernel events and early boot stuff
| should be expected) only need to maintain one boot setup for their
| package, and this boot setup should be used by all the different boot
| systems.

That would mean limiting each init system to the limitations of the most
limited init system, which would be a sad state of affairs.

Not so sad, considering that a large portion of init scripts do hardly
need anything more and become more robust if they are not scripts any
more, but declarative descriptions.

For the rest (early boot stuff, display manager, complex daemons), we’ll
just continue writing having hand-written boot scripts.

(I really think that much more in Debian should be declarative and thus
consistent and robust, instead of repeatedly hand-written. What Michael
Vogt say about maintainer scripts equally applies to init scripts:

Another important problem to tackle is to make maintainer
scripts more declarative. I triaged a lot of upgrade bug reports
(mostly in ubuntu though) and a lot of them are caused by
maintainer script failures. Worse is that depending on the error
its really hard for the user to solve the problem. There is also
a lot of code duplication. Having a central place that contains
well tested code to do these jobs would be more robust. Triggers
help us a lot here already, but I think there is still more room
for improvement.
(http://raphaelhertzog.com/2011/01/21/people-behind-debian-michael-vogt-synaptic-apt-developer/)

But then, I should rather be quiet. I tried following this road and did
not manage to push it enough (though not because it wasn’t possible,
rather due to lack of time and motivation).

Greetings,
Joachim

--
Joachim Breitner
e-Mail: m...@joachim-breitner.de
Homepage: http://www.joachim-breitner.de
ICQ#: 74513189
Jabber-ID: nome...@joachim-breitner.de

--
Joachim nomeata Breitner
Debian Developer
nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata

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

Re: Upcoming FTPMaster meeting

2011-02-14 Thread Raphael Hertzog

On Mon, 14 Feb 2011, Philipp Kern wrote:
 You'd lose the notion of it being useful on other architectures (that's the
 arch:all - arch:i386 Raphael's talking about), though.  But then packages
 like qemu-system would just depend on openbios-sparc:sparc, no?  If you
 don't need to deal with them directly that'd be pretty transparent.

The current Multi-Arch spec doesn't allow for such explicit dependencies
(targeting a precise foreign architecture).

But you can have openbios-sparc:any and assuming openbios-sparc is only
available on sparc, the right package would be picked.

See http://wiki.ubuntu.com/MultiarchSpec

 But then so far multiarch didn't happen... ):

But it's really not far away this time.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110215070642.gd32...@rivendell.home.ouaza.com

Re: Upcoming FTPMaster meeting