Re: DebConf10 to take place in New York City, USA

[Mike Hommey]

On Wed, Feb 25, 2009 at 02:31:24PM -0500, Jimmy Kaplowitz wrote:
> Further, we're definitely going to be giving people invitation letters and
> other advice to make sure they present themselves in the best (accurate) light
> they can to the visa or border officials, as well as separate exaggeration 
> from
> fact with regard to border search and other privacy concerns so that people 
> can
> make rational decisions based on reality instead of sensationalism.

Sensationalism like
http://www.schneier.com/blog/archives/2008/08/us_government_p.html
http://www.schneier.com/blog/archives/2008/05/crossing_border.html
?

Mike


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

Using a CD Set to back to Debian Pool (e.g. for mirror)

[Daniel Dickinson]

For those mirroring debian on small space and who want to mirror both
CD images and the archive, the page (and related scripts) on the wiki,
that I have just posted at http://wiki.debian.org/CDToPool may be of
interest.

Basically, starting with either a mirror or cd set you can create pool
directory that can be used for a mirror but has the advantage that it
is backed by the loop mounted CD set so the CD set doesn't add much to
the amount of space taken by the mirror + cd mirror.

Hope you enjoy.

Regards,

Daniel

-- 
And that's my crabbing done for the day.  Got it out of the way early, 
now I have the rest of the afternoon to sniff fragrant tea-roses or 
strangle cute bunnies or something.   -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C  http://gnupg.org


signature.asc
Description: PGP signature

Re: Proposal to improve package configuration upgrades

[Harald Braumann]

On Wed, 25 Feb 2009 17:32:08 +0100
Dominique Dumont  wrote:

> Harald Braumann  writes:
> 
> > I don't really know Config::Model. But the main problem I have with
> > the current system is, that I only see diffs between the currently
> > installed version and the new package version. 
> 
> With ucf, you see a diff between current file (i.e. installed version
> with your modifications) and the new package version. 

That I also see without ucf.

> > No what I really would like to see is the diff between the last
> > version I've merged and the new package version. 
> 
> I fail to see the differences (no pun intented) between "the last
> version I've merged" and the current file ...

I mean the last maintainer version I merged into the installed version,
not the result of the last merge. 

> > So changes can easily be seen (changes in defaults, new/removed
> > parameters or just white-space changes?) and merging would work
> > without a conflict in most cases. 
> 
> With Config::Model:
> - you would not see white space or any other formatting difference
> - your customized values would be merged into the new package file
>   (more accurately, loaded in Config::Model configuration tree using
>   the new package *model*). Thus you would see the delta between your
>   new file and the new default value. See this example of a screenshot
>   [1] where the config values different from "default" are shown with
>   a green arrow

But there are 3 possible situations here:
1. value has been changed between the last and the new maintainer
version
2. value was modified locally
3. both of the above 

In case 1 the modification could be merged silently, in case 2 the
modification should be left alone and in case 3 I'd have to decide what
to do. Config::Model on its own couldn't tell the difference.

> - yes, merging would work mostly without conflict 

> 
> > Similar to like SCMs work.
> 
> The main difference between a SCM and Config::Model is that a SCM
> works purely at text level without knowledge of the semantic of the
> file under control. OTOH, Config::Model uses the semantic knowledge
> provided by the model to perform the upgrade.

You could apply the way merges work in an SCM to structured
information.

> > Config::Model could be useful in addition, but would it support
> > such a work-flow?
> 
> Provided I've understood correctly your work-flow, I'd say mostly
> yes...

Having the diff between the last and the new maintainer version is not
an alternative to Config::Model. The former can tell me what has
changed in what way and the latter can present this information
enriched with its semantic knowledge of the changes. Both are things I
find useful. So my question is, if Config::Model can also deal with the
additional information of what has changed how, so the two things could
be combined?

Cheers,
harry


signature.asc
Description: PGP signature

Re: Proposal to improve package configuration upgrades

[Harald Braumann]

On Wed, 25 Feb 2009 12:08:00 -0600
Manoj Srivastava  wrote:

> Well. If the maintainer so desires, ucf does have this to say:
> ,[  Manual page ucf(1) ]
> | --three-way

I thought I remembered seeing smth. like this. 


> Seems like this is what is desired; 

Yes, this is exactly what is desired.

> however, the reason this
> is not on by default is that some configuration files can be huge,
> and ucf did not want to stash away _all_ the configuration files
> handled by it into /var.  The exectation was that most developers
> with smallish configuration files would use --three-way, but that
> expectation was unfounded.

Could this be made configurable locally? So the maintainer could still
set whatever default he finds useful but it could be overridden by the
admin? So everyone is happy.

Cheers,
harry


signature.asc
Description: PGP signature

Re: Accelerated video cards and non-free firmware

[Harald Braumann]

On Wed, 25 Feb 2009 16:28:39 -0500
Daniel Dickinson  wrote:

> Hi,
> 
> I'm looking at getting a video card, and I want to know what video
> card that has 3D acceleration to get.  Normally I'd ask on -users but
> as the subject says I want to know what video cards will still have
> acceleration when the non-free firmware is removed from the kernel,
> which is supposed to happen for squeeze.
> 
> I had heard that the ATI cards, which would normally be my first
> choice, have non-free firmware in the driver, which may be removed.
> Is this true, and if so what accelerated cards will have have
> acceleration once non-free firmware is removed.

Development of open source drivers is moving quite fast these days. So
I would expect decent 3D acceleration in open source drivers at the
time Squeeze is release. Best to ask on x...@lists.freedesktop.org.

Cheers,
harry


signature.asc
Description: PGP signature

Re: Proposal to improve package configuration upgrades

[Stefano Zacchiroli]

On Wed, Feb 25, 2009 at 06:03:03PM +0100, Dominique Dumont wrote:
> Stefano Zacchiroli  writes:
> > Actually, this is something I've been pondering about for a
> > while. Having /etc under some VCS (as many of us, I presume, already
> > have by the means of etckeeper and similar tools), diff file merging
> > can be seriously improved.
> 
> I tend to disagree.

Well, it depends on how dpkg currently handles merges. My impression
(as a user, never looked at the actual code) is that it not even tries
to merge, it simply discovers that the local file is not pristine and
then asks the user. On the contrary, every VCS I'm aware of at least
_tries_ a merge, "succeeding" when changes do not affect the same
patch hunk.

Of course that would mean that dpkg should be made aware of the
difference between the last pristine configuration file installed on
the machine, and the configuration file the package being installed is
shipping.

Also, there is of course no guaranteed that no conflicting changes
lead to a configuration file semantically sound, but AFAIU you have no
guarantee of that with Config::Model either. They are both about
syntax only.

> >From a user point of view, you will get the same diff output whether a
> SCM performs the diff or ucf performs the diff.
> 
> So your proposal will probably not help my mother-in-law to upgrade
> the packages on her system ;-)

I disagree. It will not help your mother-in-law once she is faced with
the diff, but it will decrease dramatically the number of times she
will be faced with that. ... so maybe we should strive for both?

Cheers.

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


signature.asc
Description: Digital signature

LXDE doesnt support Debian Menu

[Daniel Dickinson]

Is that a violation of a must directive and therefore a bug that will
need fixing ASAP?  AIUI packages that have a GUI are required to have
debian menu, but I'm not sure if the window manager / desktop has the
same requirement.

-- 
And that's my crabbing done for the day.  Got it out of the way early, 
now I have the rest of the afternoon to sniff fragrant tea-roses or 
strangle cute bunnies or something.   -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C  http://gnupg.org


signature.asc
Description: PGP signature

Re: LXDE doesnt support Debian Menu

[Paul Wise]

On Thu, Feb 26, 2009 at 6:36 PM, Daniel Dickinson  wrote:

> Is that a violation of a must directive and therefore a bug that will
> need fixing ASAP?  AIUI packages that have a GUI are required to have
> debian menu, but I'm not sure if the window manager / desktop has the
> same requirement.

The Debian GNOME desktop by default does not include the 'Debian' menu.

There doesn't appear to be any requirement for window
managers/desktops to support it:

http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.4

IMO it is time to merge the Debian and FDO menus anyway.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: LXDE doesnt support Debian Menu

[Sune Vuorela]

On 2009-02-26, Daniel Dickinson  wrote:
> --Sig_/b/o0j06x1Maj8m.BfPK65gn
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: quoted-printable
>
> Is that a violation of a must directive and therefore a bug that will
> need fixing ASAP?  AIUI packages that have a GUI are required to have
> debian menu, but I'm not sure if the window manager / desktop has the
> same requirement.

I am considering starting a discussion within the KDE team to stop
supporting the Debian Menu.

It becomes more and more useless - and it is also very ugly, as the menu
itself specifies icons that are nonexistant in all icon themes.

/Sune


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

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

[Joerg Schilling]

Ben Hutchings  wrote:

> On Wed, 2009-02-25 at 09:28 +0100, Joerg Schilling wrote:
> > >xcdroast is looking for cdrecord, which does no longer exist in Debian 
> > >Sid (apparently). And wodim does no longer provide a symlink as cdrecord 
> > >or something (apparently).
> > 
> > >So: xcdroast does no longer work. Who is to blame (Bug entry): xcdroats 
> > >or wodim?
> > 
> > You need to blame the people who are responsible for removing cdrecord
> > and who started to include a fork (wodim) that cannot be legally 
> > distributed.
>
> You're the one who distributes a legally dubious mixture of code covered
> by GPLv2 and CDDL.

There is no "dubious" mixture. even the FSF admits that GPLd code may use
CDDLd libraries from other projects (as done inside cdrtools which is a 
collection of sevreral independent projects). The original software had a 
full in depth legal review from the Sun legal department and Sun-legal did
not find any problem. Distributions that are interested in shipping working 
legal software ship the original software.

The fork distributed by Debian may however be called dubious:

-   The fork is in conflict with the Copyright law and thus may not be 
legally distributed.

-   The fork is in conflict with the GPL and thus may not be legally
distributed.

-   The fork is full of bugs that have been introduced by the person who
initiated the fork and for this reason did not get the permission
to use the original name. Note that it is not even allowed to ship
symlinks with the original names as this makes users believe that
they use the original software.

If you like to blame a specific person for the current problems, you need to 
blame the person who started the "fork" based on very a outdated version, who
ripped off the working DVD support code, who introduced dozens of new bugs and
who stopped working on the fork on May 6th 2007, leaving the fork 
unmaintained. An interesting aspect of this person is that he started to 
advertize for Nerolinux after May 6th 2007. It seems that he never was 
interested in supporting FROSS but in causing harm for FROSS.

If you look at the bug tracking systems of the Linux distributors that
ship the illegal fork, you see a total of aprox. 100 bugs (many of them are 
showstopper bugs) that are specific to the fork. Upgrading to recent 
original software from:

ftp://ftp.berlios.de/pub/cdrecord/alpha/

fixes all bugs from the bug-tracking systems that are not caused by packaging,
bugs in the Linux kernel or bugs in the Linux variant of hald.


What is the reason for shipping software that is undistributable and that
disgusts the Debian users because it is full of unneeded bugs?

If Debian is interested in being a FROSS oriented distro that listenes to the
demands of their users, it seems to be obvious to admit that following the 
person who introduced the fork was a mistake. He is longer active at Debian, 
it should be simple to write a note on that this person caused harm to the
credibility of Debian and to this way correct a previous mistake.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


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

Re: Should 32-bit apps work with a 64-bit kernel?

[Roger Leigh]

On Wed, Feb 25, 2009 at 06:20:50PM -0800, Steve Langasek wrote:
> On Wed, Feb 25, 2009 at 10:52:30PM +, Roger Leigh wrote:
> 
> > Personally, I would prefer the glibc headers to just set the LFS
> > macros to the 64 bit versions by default, so that rather than
> > taking extra steps to enable LFS, LFS would be the default and you
> > would then need to take extra steps to disable it.
> 
> > i.e. just default _FILE_OFFSET_BITS to 64 rather than 32.
> 
> > If someone really, really, wanted 32 bit file offsets, they could
> > just set it back to 32 again.
> 
> There are libraries in existence that (unfortunately) expose libc types that
> are sensitive to _FILE_OFFSET_BITS as part of their ABIs.  Making a change
> like this without first identifying and handling those libraries would cause
> a mess.

Agreed.  If we can identify all libraries (perhaps with a simple grep over
the lintian lab?) containing these types, and make sure LFS is enabled in
all of them, it should then be possible to switch once all dependencies
are rebuilt.  I guess this would need the library packages renaming due to
altering the ABI.


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: LXDE doesnt support Debian Menu

[Andreas Tille]

On Thu, 26 Feb 2009, Sune Vuorela wrote:


I am considering starting a discussion within the KDE team to stop
supporting the Debian Menu.

It becomes more and more useless - and it is also very ugly, as the menu
itself specifies icons that are nonexistant in all icon themes.


This discussion comes up once or twice per year.  In most cases it is
triggered by users of freedesktop.org based environments.  They fail to
see the fact that there are other environments which do not support
freedesktop.org standards and in this case Debian menu makes
perfectly sense.

If there are missing icons you should rather file a bug report against
the package that specifies these.

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: LXDE doesnt support Debian Menu

[José Luis Redrejo Rodríguez]

2009/2/26 Andreas Tille 

> On Thu, 26 Feb 2009, Sune Vuorela wrote:
>
>  I am considering starting a discussion within the KDE team to stop
>> supporting the Debian Menu.
>>
>> It becomes more and more useless - and it is also very ugly, as the menu
>> itself specifies icons that are nonexistant in all icon themes.
>>
>
> This discussion comes up once or twice per year.  In most cases it is
> triggered by users of freedesktop.org based environments.  They fail to
> see the fact that there are other environments which do not support
> freedesktop.org standards and in this case Debian menu makes
> perfectly sense.
>


Right, but that's a good reason to do what Sune is considering: removing
Debian Menu support in KDE, Gnome, etc.
I don't think removing Debian menu is a good idea, as many people are still
using it, but when you're using a freedesktop.org environment, this menu is
really ugly, useless and duplicating entries. So, I think this menu should
disappear for these desktops users, and  stay for the rest of the users
(obviously, keeping the packaging policies that are associated with it).

Regards
José L.

Re: LXDE doesnt support Debian Menu

[Tzafrir Cohen]

On Thu, Feb 26, 2009 at 10:14:34AM +, Sune Vuorela wrote:
> On 2009-02-26, Daniel Dickinson  wrote:
> > --Sig_/b/o0j06x1Maj8m.BfPK65gn
> > Content-Type: text/plain; charset=US-ASCII
> > Content-Transfer-Encoding: quoted-printable
> >
> > Is that a violation of a must directive and therefore a bug that will
> > need fixing ASAP?  AIUI packages that have a GUI are required to have
> > debian menu, but I'm not sure if the window manager / desktop has the
> > same requirement.
> 
> I am considering starting a discussion within the KDE team to stop
> supporting the Debian Menu.
> 
> It becomes more and more useless - and it is also very ugly, as the menu
> itself specifies icons that are nonexistant in all icon themes.

Yeah. Our menus are great.

I've recently installed most KDE apps on a Etch-upgraded-to-Lenny system
with a default GNOME desktop.

The "Settings" top menu is now mostly unusable, as it is one long list that
includes both KDE and GNOME settings.

A few other menus are long and cluttered. This is unlike the menus in my
IceWM.

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


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

Re: LXDE doesnt support Debian Menu

[David Paleino]

On Thu, 26 Feb 2009 12:12:25 +0100, José Luis Redrejo Rodríguez wrote:

> 2009/2/26 Andreas Tille 
> 
> > On Thu, 26 Feb 2009, Sune Vuorela wrote:
> >
> >  I am considering starting a discussion within the KDE team to stop
> >> supporting the Debian Menu.
> >>
> >> It becomes more and more useless - and it is also very ugly, as the menu
> >> itself specifies icons that are nonexistant in all icon themes.
> >
> > This discussion comes up once or twice per year.  In most cases it is
> > triggered by users of freedesktop.org based environments.  They fail to
> > see the fact that there are other environments which do not support
> > freedesktop.org standards and in this case Debian menu makes
> > perfectly sense.
> 
> Right, but that's a good reason to do what Sune is considering: removing
> Debian Menu support in KDE, Gnome, etc.

What about making all environments out there support the freedesktop.org
standard instead?

David

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


signature.asc
Description: PGP signature

Bug#517206: ITP: libgd-svg-perl -- Seamlessly enable SVG output from scripts written using GD

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy 

Hello everybody,

Here is another Perl library that is needed for the Generic Genome Browser 
(version 2).
I will inject the package soon in the pkg-perl repository.

Have a nice day,

-- Charles Plessy

Source: libgd-svg-perl
Section: perl
Priority: optional
Build-Depends: debhelper (>= 7)
Build-Depends-Indep: libgd-gd2-perl, libsvg-perl, perl (>= 5.6.0-12)
Maintainer: Debian Perl Group 
Uploaders: Charles Plessy 
Standards-Version: 3.8.0
Vcs-Svn: svn://svn.debian.org/pkg-perl/trunk/libgd-svg-perl/
Vcs-Browser: http://svn.debian.org/viewsvn/pkg-perl/trunk/libgd-svg-perl/
Homepage: http://search.cpan.org/dist/GD-SVG/

Package: libgd-svg-perl
Architecture: all
Depends: ${misc:Depends}, ${perl:Depends}, libgd-gd2-perl, libsvg-perl
Description: Seamlessly enable SVG output from scripts written using GD
 GD::SVG painlessly enables scripts that utilize GD to export scalable vector
 graphics (SVG). It accomplishes this task by wrapping SVG.pm with GD-styled
 method calls. To enable this functionality, one need only change the "use GD"
 call to "use GD::SVG" (and initial "new" method calls).


Format-Specification:
http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=196
Upstream-Maintainer: Todd Harris 
Upstream-Source: 
http://search.cpan.org/CPAN/authors/id/T/TW/TWH/GD-SVG-0.32.tar.gz
Upstream-Name: GD-SVG

Files: *
Copyright: © 2003–2008, Todd Harris ,
   © 2003–2008, the Cold Spring Harbor Laboratory
License: Artistic | GPL-1+
 This library is free software; you can redistribute it and/or modify
 it under the same terms as Perl itself.

Files: debian/*
Copyright: © 2009, Charles Plessy 
License: Artistic | GPL-1+

License: Artistic
This program is free software; you can redistribute it and/or modify
it under the terms of the Artistic License, which comes with Perl.
On Debian GNU/Linux systems, the complete text of the Artistic License
can be found in `/usr/share/common-licenses/Artistic'

License: GPL-1+
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 1, or (at your option)
any later version.
On Debian GNU/Linux systems, the complete text of the GNU General
Public License can be found in `/usr/share/common-licenses/GPL'



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

Re: LXDE doesnt support Debian Menu

[Josselin Mouette]

Le jeudi 26 février 2009 à 11:12 +, Tzafrir Cohen a écrit :
> The "Settings" top menu is now mostly unusable, as it is one long list that
> includes both KDE and GNOME settings.

And it will, as long as the KDE maintainers don’t fix their
broken .desktop entries to add the missing OnlyShowIn entries.

http://bugs.debian.org/478286

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: LXDE doesnt support Debian Menu

[Andreas Tille]

On Thu, 26 Feb 2009, David Paleino wrote:


What about making all environments out there support the freedesktop.org
standard instead?


The situation is different.  It is not that all environments support
Debian menu but many of them invented their own menu system.  The Debian
Menu system just provides scripts to translate a common (Debian invented)
format to support each specific menu system.  So the correct formulation
of your suggestion is: "What about porting all these scripts to use
freedesktop.org format input and at the same time fix all packages that
only have a menu but no desktop file."

You will never manage to "force" upstream authors of different environments
to support freedesktop.org standard because you have no handle to force
anybody in Free Software.

Kind regards

Andreas.

--
http://fam-tille.de


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

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

[Alexander Reichle-Schmehl]

Hi!

Ben Hutchings schrieb:
> On Wed, 2009-02-25 at 09:28 +0100, Joerg Schilling wrote:
>>> [..] cdrecord [..]
>>> [..] wodim [..]

Please, not again.  The arguments have been exchanged ad invinitum a couple
of times already. So if there is nothing new to bring up, please don't
restart the discussion.


Best regards,
  Alexander


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

Re: LXDE doesnt support Debian Menu

[David Paleino]

On Thu, 26 Feb 2009 12:36:07 +0100 (CET), Andreas Tille wrote:

> On Thu, 26 Feb 2009, David Paleino wrote:
> 
> > What about making all environments out there support the freedesktop.org
> > standard instead?
> 
> The situation is different.  It is not that all environments support
> Debian menu but many of them invented their own menu system.  The Debian
> Menu system just provides scripts to translate a common (Debian invented)
> format to support each specific menu system.

Ok.

> So the correct formulation of your suggestion is: "What about porting all
> these scripts to use freedesktop.org format input

Then we can drop "menu" files, in favour of .desktop ones.

> and at the same time fix all packages that only have a menu but no desktop
> file."

This could easily be added as a lintian check, I believe.

> You will never manage to "force" upstream authors of different environments
> to support freedesktop.org standard because you have no handle to force
> anybody in Free Software.

Sure you can't, but standards exist for this reason. And sane upstreams would
certainly adhere to standards.

Ciao,
David

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


signature.asc
Description: PGP signature

Re: LXDE doesnt support Debian Menu

[Charles Plessy]

Le Thu, Feb 26, 2009 at 12:02:29PM +0100, Andreas Tille a écrit :
> On Thu, 26 Feb 2009, Sune Vuorela wrote:
>
>> I am considering starting a discussion within the KDE team to stop
>> supporting the Debian Menu.
>>
>> It becomes more and more useless - and it is also very ugly, as the menu
>> itself specifies icons that are nonexistant in all icon themes.
>
> This discussion comes up once or twice per year.

Hi all,

forgive me for repeating always the same thing once or twice a year ;)

I think that the Debian Menu should use the fd.o Destkop menu entry format.
This would already unify a lot both systems, and simplify packages as we could
then contribute many .desktop files upstream and move them out of the Debian
part of our source packages.

The formats are not as dissimilar as one can think at first:
http://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries
  
I am unable to help for the programatic part, but I do volunteer to give a
significant part of my Debian time to help the transition.

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

Re: Proposal to improve package configuration upgrades

[Dominique Dumont]

Stefano Zacchiroli  writes:
> Well, it depends on how dpkg currently handles merges. My impression
> (as a user, never looked at the actual code) is that it not even tries
> to merge, it simply discovers that the local file is not pristine and
> then asks the user. On the contrary, every VCS I'm aware of at least
> _tries_ a merge, "succeeding" when changes do not affect the same
> patch hunk.

Agreed.

> Also, there is of course no guaranteed that no conflicting changes
> lead to a configuration file semantically sound,

That's the main problem I see with VCS like merge. The main problem is
that the merge result *should* be reviewed by the user. Will the user
always have the skills to spot the places where the merge was wrong ?

> but AFAIU you have no guarantee of that with Config::Model
> either. They are both about syntax only.

No Config::Model is all about checking the *semantic* of a
configuration file. So you will have the guarantee that the resulting
file is correct from the application point of view.

>> >From a user point of view, you will get the same diff output whether a
>> SCM performs the diff or ucf performs the diff.
>> 
>> So your proposal will probably not help my mother-in-law to upgrade
>> the packages on her system ;-)
>
> I disagree. It will not help your mother-in-law once she is faced with
> the diff, but it will decrease dramatically the number of times she
> will be faced with that. ... so maybe we should strive for both?

There's may be cases where the merge completes automatically but the
end result is wrong. That would be really bad.

All the best

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

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

[Brett Parker]

On 26 Feb 11:27, Joerg Schilling wrote:
> - The fork is in conflict with the Copyright law and thus may not be 
>   legally distributed.

Err, it's a fork of the GPL2 code, before you went insane and relicenced
half of it to CDDL and added random "Don't change this" invariant
sections - how do you see it conflicting with Copyright law?

> - The fork is in conflict with the GPL and thus may not be legally
>   distributed.

Errr, in what way?

> - The fork is full of bugs that have been introduced by the person who
>   initiated the fork and for this reason did not get the permission
>   to use the original name. Note that it is not even allowed to ship
>   symlinks with the original names as this makes users believe that
>   they use the original software.

As someone that uses wodim quite a bit, I've not noticed it to be "full
of bugs", so I'd suggest that you're spreading FUD and hoping that no
one notices.

> If you like to blame a specific person for the current problems, you need to 
> blame the person who started the "fork" based on very a outdated version, who
> ripped off the working DVD support code, who introduced dozens of new bugs and
> who stopped working on the fork on May 6th 2007, leaving the fork 
> unmaintained. An interesting aspect of this person is that he started to 
> advertize for Nerolinux after May 6th 2007. It seems that he never was 
> interested in supporting FROSS but in causing harm for FROSS.

Very outdated version because of the licencing issues introduced by you
stopping a fork at any later version...

> If you look at the bug tracking systems of the Linux distributors that
> ship the illegal fork, you see a total of aprox. 100 bugs (many of them are 
> showstopper bugs) that are specific to the fork. Upgrading to recent 
> original software from:
> 
> ftp://ftp.berlios.de/pub/cdrecord/alpha/

The fact that says 'alpha' of course inspires us all with confidence.

> fixes all bugs from the bug-tracking systems that are not caused by packaging,
> bugs in the Linux kernel or bugs in the Linux variant of hald.

So, it doesn't fix all the bugs, then. So, that's completely irrelevant,
you still have bugs. Well done.

> What is the reason for shipping software that is undistributable and that
> disgusts the Debian users because it is full of unneeded bugs?

Err, being a long term Debian user, I'd like to know where you get the
impression that it "disgusts Debian users" - you appear to be confusing
yourself with a Debian users. As I understand it, you wouldn't use a
Debian system if it was the last system available on earth, and so you
don't qualify as a user. Sorry.

> If Debian is interested in being a FROSS oriented distro that listenes to the
> demands of their users, it seems to be obvious to admit that following the 
> person who introduced the fork was a mistake. He is longer active at Debian, 
> it should be simple to write a note on that this person caused harm to the
> credibility of Debian and to this way correct a previous mistake.

Errr. Right. I think you are mistaken. Now, according to you nothing has
changed since May 2007, I can see - clearly - from
http://www.cdrkit.org/ that the last release was actually 2008/10/26,
I'd suggest that's neither 2007, or May. On the other hand, maybe I'm
incapable of parsing dates or actually looking things up.

Ho hum,
-- 
Brett Parker
Everything in this mail is my opinion. So there.


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

ucf --three-way (was: Proposal to improve package configuration upgrades)

[Dominique Dumont]

Manoj Srivastava  writes:

> Well. If the maintainer so desires, ucf does have this to say:
> ,[  Manual page ucf(1) ]
> | --three-way
[ ... ]

> Seems like this is what is desired; however, the reason this is
>  not on by default is that some configuration files can be huge, and ucf
>  did not want to stash away _all_ the configuration files handled by it
>  into /var.  The exectation was that most developers with smallish
>  configuration files would use --three-way, but that expectation was
>  unfounded.

I understand. Thanks for the man page snippet.

At the risk of drifting away from Config::Model, couldn't ucf propose
by default the three-way merge if the configurations files are
"smallish" ? (with the option for the maintainer to specify --two-way)

By "smallish", I mean below a defined number of lines (say 1000 lines).

All the best

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

Re: handling group membership in and outside d-i

[Ben Hutchings]

On Thu, 2009-02-26 at 08:31 +0100, Peter Palfrader wrote:
> On Wed, 25 Feb 2009, Roger Leigh wrote:
> 
> > HAL is just querying the group database directly.  Any process can of
> > course do this.  But it's asking a different question, namely:
> > what groups is this user a member of in the group database.
> 
> This is of course broken.  It breaks granting console users access to
> the netdev or powerdev groups through pam_groups, which is really really
> annoying when you get your users from say ldap.

But that's broken to start with, since you can't revoke group membership
when the user logs out.

Ben.




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

Re: LXDE doesnt support Debian Menu

[Matthew Johnson]

On Thu Feb 26 12:57, David Paleino wrote:
> > You will never manage to "force" upstream authors of different environments
> > to support freedesktop.org standard because you have no handle to force
> > anybody in Free Software.
> 
> Sure you can't, but standards exist for this reason. And sane upstreams would
> certainly adhere to standards.

Since when are all upstreams sane?

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

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

[Josselin Mouette]

Le jeudi 26 février 2009 à 12:58 +0100, Alexander Reichle-Schmehl a
écrit :
> Please, not again.  The arguments have been exchanged ad invinitum a couple
> of times already. So if there is nothing new to bring up, please don't
> restart the discussion.

Why? It’s quite funny to discuss with Joerg Schilling. I prefer to do it
in private, but it is good to have some of the discussions in public: I
believe it strengthens the project by giving developers a common target,
instead of hurting each other in internal fights.

Cheers,
-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Should 32-bit apps work with a 64-bit kernel?

[Mark Brown]

On Thu, Feb 26, 2009 at 10:48:35AM +, Roger Leigh wrote:

> Agreed.  If we can identify all libraries (perhaps with a simple grep over
> the lintian lab?) containing these types, and make sure LFS is enabled in
> all of them, it should then be possible to switch once all dependencies
> are rebuilt.  I guess this would need the library packages renaming due to
> altering the ABI.

Some of these libraries provide ABIs which support both LFS and non-LFS
versions - we'd also need to check for those and make sure they can
handle being built with LFS defined by default.

I do worry that we may end up causing compatibility issues here by
surprsing people with changed defaults.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: Proposal to improve package configuration upgrades

[Dominique Dumont]

Manoj Srivastava  writes:

>  /etc/kernel-pkg.conf, for example, is in Perl. You may define
>  functions, variables, closures (given enough make-kpkg-fu) and have it
>  all work.

Agreed. But this is valid for power user that would not really need
the safe merge capability provided by Config::Model.

>  I dare you to try one for sendmail.cf. (and yes,  often don't
>  use the new fangled m4 stuff)

A complete model of sendmail.cf would also be required only for power
users like you. 

For the "mother-in-law use case", it would be more useful to validate
that upgrades will work correctly for "Config::Model enabled"
packages. Later on, the more packages use Config::Model, the easier
will be the system maintenance of "most common" users.

All the best

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

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

[Giacomo A. Catenazzi]

Josselin Mouette wrote:

Le jeudi 26 février 2009 à 12:58 +0100, Alexander Reichle-Schmehl a
écrit :

Please, not again.  The arguments have been exchanged ad invinitum a couple
of times already. So if there is nothing new to bring up, please don't
restart the discussion.


Why? It’s quite funny to discuss with Joerg Schilling. I prefer to do it
in private, but it is good to have some of the discussions in public: I
believe it strengthens the project by giving developers a common target,
instead of hurting each other in internal fights.


But hit hurts me, and I think also Debian in general.

ciao
cate


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

Bug#517229: ITP: libghc6-extensible-exceptions -- Extensible exceptions for the Glasgow Haskell Compiler

[Marco Túlio Gontijo e Silva]

Package: wnpp
Severity: wishlist
Owner: "Marco Túlio Gontijo e Silva" 


* Package name: libghc6-extensible-exceptions
  Version : 0.1.1.0
  Upstream Author : Haskell Libraries Maintainers 
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/extensible-exceptions
* License : BSD3
  Programming Lang: Haskell
  Description : Extensible exceptions for the Glasgow Haskell Compiler

 This package provides a library for the Haskell programming language.
 See http://www.haskell.org/ for more information on Haskell.
 .
 This package provides extensible exceptions for both new and old versions of
 GHC (i.e., < 6.10).

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



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

Bug#172318: marked as done (apt: Automatic appends to sources.list via webpages.)

[Debian Bug Tracking System]

Your message dated Thu, 26 Feb 2009 15:22:32 +0100
with message-id <200902261522.38235.hol...@layer-acht.org>
and subject line wontfix
has caused the Debian Bug report #172318,
regarding apt: Automatic appends to sources.list via webpages.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
172318: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=172318
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: apt
Version: 0.5.4
Severity: wishlist

It would be nice if there were a way for a webpage to have a link which,
when clicked, makes the user be asked if it is ok to append a line
to the sources.list file and to install a package. Users can download
and install a debian package just by clicking on it, but they will not
get upgrades automaticly if they do that (unless, somehow, the package
is in a repository already).

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux gamegirl 2.4.19-k7 #1 Sun Oct 6 20:29:56 EST 2002 i686
Locale: LANG=sv_SE, LC_CTYPE=sv_SE

Versions of packages apt depends on:
ii  libc6 2.2.5-11.2 GNU C Library: Shared libraries an
ii  libstdc++2.10-glibc2.21:2.95.4-7 The GNU stdc++ library


--- End Message ---
--- Begin Message ---
Hi,

this bug is probably wontfix, it's not a good idea to modify the sources.list 
like this.

However, there is a package, aptlinex, which allows you to install packages 
from a webpage. 

I'm cc:ing the packages maintainer, _maybe_ he might want to support a feature 
like this, where special URLs open a local application to modify 
sources.lists. (Then please reopen and reassign.)


regards,
Holger


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

Processed: reassign

[Debian Bug Tracking System]

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

> reassign 512401 metacity
Bug#512401: general: Java, Tk and Tkinter applications broken in Metacity 
window manager
Bug reassigned from package `general' to `metacity'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: LXDE doesnt support Debian Menu

[Darren Salt]

I demand that José Luis Redrejo Rodríguez may or may not have written...

[snip]
> I don't think removing Debian menu is a good idea, as many people are still
> using it, but when you're using a freedesktop.org environment, this menu is
> really ugly, useless and duplicating entries.

There are some of us who prefer the Debian menu over the freedesktop.org one;
in my case, it's down to the layout of one (used to it) _and_ content missing
from the other.

[snip]
-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES.

We don't really understand it, so we'll give it to the programmers.


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

Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

[Holger Levsen]

retitle 508644 Sorting out mail-transport-agent mess
thanks

Hi,

I'd like to close/reassign this bug... :-)

A better description of what this bug is about can actually be read in 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474999 and the solution 
would be to file bugs against those 8 packages (listed in #508644) which 
depend on mail-transfer-agent instead of on "exim4 | mail-transfer-agent".

But as this would hardcode exim4 as the default MTA for Debian in a number of 
packages, some better solutions have been proposed in
http://lists.debian.org/debian-devel/2008/05/msg00381.html with the best 
choice appearantly being  <87ve1faria@frosties.localdomain> which 
proposes that exim4 should provide default-mta, packages needing an MTA 
should depend on default-mta | mail-transfer-agent and the other MTAs should 
provide mail-transfer-agent. Then, if we want to change the default, we just 
need to touch two packages.

As per policy I'd like to gather consensus on this before mass filing bugs.


regards,
Holger


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

Processed: mass bugfiling (against 8 packages) and/or new package default-mta

[Debian Bug Tracking System]

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

> retitle 508644 Sorting out mail-transport-agent mess
Bug#508644: general: installing mdadm pulls in citadel-server as depedency
Changed Bug title to `Sorting out mail-transport-agent mess' from `general: 
installing mdadm pulls in citadel-server as depedency'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: LXDE doesnt support Debian Menu

[David Paleino]

On Thu, 26 Feb 2009 13:13:31 +, Matthew Johnson wrote:

> On Thu Feb 26 12:57, David Paleino wrote:
> > > You will never manage to "force" upstream authors of different
> > > environments to support freedesktop.org standard because you have no
> > > handle to force anybody in Free Software.
> > 
> > Sure you can't, but standards exist for this reason. And sane upstreams
> > would certainly adhere to standards.
> 
> Since when are all upstreams sane?

I admit that's my secret dream *g* :)

David

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


signature.asc
Description: PGP signature

https://esta.cbp.dhs.gov/ (Re: DebConf10 to take place in New York City, USA)

[Osamu Aoki]

FYI:

Although people from many countries (Japan, Europe, ...) are not
required to have visa, US now requires to fill some web form in advance.
PLEASE do not forget to do Travel Authorization:

 https://esta.cbp.dhs.gov/

Also ...

On Thu, Feb 26, 2009 at 09:08:50AM +0100, Mike Hommey wrote:
> On Wed, Feb 25, 2009 at 02:31:24PM -0500, Jimmy Kaplowitz wrote:
> > Further, we're definitely going to be giving people invitation letters and
> > other advice to make sure they present themselves in the best (accurate) 
> > light
> > they can to the visa or border officials, as well as separate exaggeration 
> > from
> > fact with regard to border search and other privacy concerns so that people 
> > can
> > make rational decisions based on reality instead of sensationalism.

I (non-US citizen) have crossed US border many times without any trouble
as a foreign resident and as a US resident.  I never had a problem.  So
this is just informational and nothing against US.

> Sensationalism like
> http://www.schneier.com/blog/archives/2008/08/us_government_p.html
> http://www.schneier.com/blog/archives/2008/05/crossing_border.html

Do not discount it.

I also have heard these stories of US government taking PC at the border
from my US acquaintances last year.  It happened on his friend coming
back to US from Asian business trip working for a big US company.  I got
an impression that it was somewhat selective for the country that person
have visited.  (not race or citizenship or employment association)  Just
an unfortunate incident.

I guess things like this happens these days and we just live with it in
calm.  I suggest to secure Debian GPG secret key or any other
important things in your PC when crossing any border not just US border.

Osamu


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

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

[Joerg Schilling]

Brett Parker  wrote:

> On 26 Feb 11:27, Joerg Schilling wrote:
> > -   The fork is in conflict with the Copyright law and thus may not be 
> > legally distributed.
>
> Err, it's a fork of the GPL2 code, before you went insane and relicenced
> half of it to CDDL and added random "Don't change this" invariant
> sections - how do you see it conflicting with Copyright law?

Before Eduard Bloch made insane modifications, the code was GPLv2 and legal.
Now the cude is undistributable because of modifications in the fork
that are incompatible with the Copyright law.
 
See my bug report from December 2006.

> > -   The fork is in conflict with the GPL and thus may not be legally
> > distributed.
>
> Errr, in what way?

See my bug report from December 2006.

>
> > -   The fork is full of bugs that have been introduced by the person who
> > initiated the fork and for this reason did not get the permission
> > to use the original name. Note that it is not even allowed to ship
> > symlinks with the original names as this makes users believe that
> > they use the original software.
>
> As someone that uses wodim quite a bit, I've not noticed it to be "full
> of bugs", so I'd suggest that you're spreading FUD and hoping that no
> one notices.

It seems that you are spreding FUD. Everybody who is interested in working
CD/DVD creating uses the original software. There are nearly 100 Bug Reports 
against the fork in the bug tracking systems from Debian, Ubuntu and Redhat, 
none of the reports applies to the original software.


> > If you like to blame a specific person for the current problems, you need 
> > to 
> > blame the person who started the "fork" based on very a outdated version, 
> > who
> > ripped off the working DVD support code, who introduced dozens of new bugs 
> > and
> > who stopped working on the fork on May 6th 2007, leaving the fork 
> > unmaintained. An interesting aspect of this person is that he started to 
> > advertize for Nerolinux after May 6th 2007. It seems that he never was 
> > interested in supporting FROSS but in causing harm for FROSS.
>
> Very outdated version because of the licencing issues introduced by you
> stopping a fork at any later version...

The original software did not introduce licensing issues. Please do not spread 
FUD. The original code had a full legal review by the Sun legal department.
The fork however is undistributable because some people ignored the rules from
GPL and Copyright law.



> > If you look at the bug tracking systems of the Linux distributors that
> > ship the illegal fork, you see a total of aprox. 100 bugs (many of them are 
> > showstopper bugs) that are specific to the fork. Upgrading to recent 
> > original software from:
> > 
> > ftp://ftp.berlios.de/pub/cdrecord/alpha/
>
> The fact that says 'alpha' of course inspires us all with confidence.

The quality of the original software is much better than the quality of the 
fork.

The minimal requirements for a "stable release" is that the software does not
have known bugs at release time. Using this rule, there never has been _any_
release from the fork while at the same time there have been 50 stable releases
from the orignal software.

> > fixes all bugs from the bug-tracking systems that are not caused by 
> > packaging,
> > bugs in the Linux kernel or bugs in the Linux variant of hald.
>
> So, it doesn't fix all the bugs, then. So, that's completely irrelevant,
> you still have bugs. Well done.

It is not my duty to "fix" Linux kernel bugs or hald bugs if there is not
even a way to work around these bugs. But believe me that _all_ well known 
bugs from the fork disappear if you install the original software from an 
unmodified source.


> > What is the reason for shipping software that is undistributable and that
> > disgusts the Debian users because it is full of unneeded bugs?
>
> Err, being a long term Debian user, I'd like to know where you get the
> impression that it "disgusts Debian users" - you appear to be confusing
> yourself with a Debian users. As I understand it, you wouldn't use a
> Debian system if it was the last system available on earth, and so you
> don't qualify as a user. Sorry.

Don't you read the bug reports? You seem to have missed the contact to the 
debian users.



> > If Debian is interested in being a FROSS oriented distro that listenes to 
> > the
> > demands of their users, it seems to be obvious to admit that following the 
> > person who introduced the fork was a mistake. He is longer active at 
> > Debian, 
> > it should be simple to write a note on that this person caused harm to the
> > credibility of Debian and to this way correct a previous mistake.
>
> Errr. Right. I think you are mistaken. Now, according to you nothing has
> changed since May 2007, I can see - clearly - from
> http://www.cdrkit.org/ that the last release was actually 2008/10/26,
> I'd suggest that's neither 2007, or May. On the other hand, maybe I'm
> incapable

Processed: reassign

[Debian Bug Tracking System]

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

> reassign 482921 glibc
Bug#482921: please provide libc6-hppa64 and libc6-hppa64-dev packages
Bug reassigned from package `general' to `glibc'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Bug#482921: reassign

[Holger Levsen]

reassign 482921 glibc
thanks


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

Re: Proposal to improve package configuration upgrades

[Stefano Zacchiroli]

On Thu, Feb 26, 2009 at 01:25:33PM +0100, Dominique Dumont wrote:
> > Also, there is of course no guaranteed that no conflicting changes
> > lead to a configuration file semantically sound,
> That's the main problem I see with VCS like merge. The main problem is
> that the merge result *should* be reviewed by the user. Will the user
> always have the skills to spot the places where the merge was wrong ?

I can agree, at least in theory. But as we all known, due to how
source code tends to work, in 90% of the cases automatic merges do the
right thing. Well, of course I cannot prove that number, but my
personal feelings is that with a "high confidence" automatic merges do
the right thing.

> > but AFAIU you have no guarantee of that with Config::Model
> > either. They are both about syntax only.
> 
> No Config::Model is all about checking the *semantic* of a
> configuration file. So you will have the guarantee that the
> resulting file is correct from the application point of view.

You know, in the general case it is an undecidable problem, so I
seriously doubt Config::Model can be the silver bullet. Possibly you
can get a good coverage of most of the files we have under /etc which
have a trivial structure (hence the questions raised by other people:
how many of those files in a typical installation you can cover?). But
then we are back at the issue of a 80-20 problem, and I see the VCS
solution as more flexible and more readily available. But again, it
looks to me that the two approaches can coexist.

... now it is only the two of us which needs to stop talking and start
proposing patches as needed :-)

Cheers.

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


signature.asc
Description: Digital signature

Re: Is the FHS dead ?

[Giacomo A. Catenazzi]

Russ Allbery wrote:

Luke L  writes:


Something to think about: Shouldn't SQL databases and web servers, and
file servers, be under /srv/? /srv/www, /srv/mysql, /srv/smb, etc.?


The current FHS reserves /srv's namespace for the local administrator.  My
guess is that people won't want to go back on that promise and start
allocating namespace in the standard.


I don't agree.

for mysql: no binary file compatibility with other sql server, so /var/lib/
is still the right location.

for www: since a lot of time, http supports virtual domain, and it is a common
practice. So putting something in /srv/www could not be what a sysadmin expect.

so I see only /srv/ftp (maybe few others) protocol that could use a standardized
/srv.

BTW, I prefer, for security:
- no package put things into public accessible places. sysadmin should choose
  what and where to put such things.
  [1]
- no anonymous ftp by default

So there is no more need to discuss how Debian should allocate /srv/.

ciao
cate


[1] IMHO also MTA should not allow incoming mail, until sysadmin set
explicitly what domain to "accept" (I don't trust to domain set at Debian
installation time, and I don't want spammer to try the default domains).
(Note: "postmaster" doesn't need domain, but I think until MTA is full
configured, we could ignore such point of RFC).




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

Re: Is the FHS dead ?

[Paul Wise]

On Fri, Feb 27, 2009 at 12:44 AM, Giacomo A. Catenazzi  wrote:
> Russ Allbery wrote:
>>
>> Luke L  writes:
>>
>>> Something to think about: Shouldn't SQL databases and web servers, and
>>> file servers, be under /srv/? /srv/www, /srv/mysql, /srv/smb, etc.?
>>
>> The current FHS reserves /srv's namespace for the local administrator.  My
>> guess is that people won't want to go back on that promise and start
>> allocating namespace in the standard.
>
> I don't agree.
...
> so I see only /srv/ftp (maybe few others) protocol that could use a
> standardized
> /srv.

I think you misunderstood, Russ is saying that /sys is the sysadmin's
domain and nothing should be installed there by Debian packages.

That isn't incompatible with Luke's opinion that databases should be
stored in /srv rather than /var/lib/. I agree with that and think the
sysadmin should decide where they want to store system data (inc
databases, websites, ftp upload directories, cvs repositories, etc).

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Proposal to improve package configuration upgrades

[Dominique Dumont]

Harald Braumann  writes:

>> I fail to see the differences (no pun intented) between "the last
>> version I've merged" and the current file ...
>
> I mean the last maintainer version I merged into the installed version,
> not the result of the last merge. 

ok

> But there are 3 possible situations here:
> 1. value has been changed between the last and the new maintainer
> version
> 2. value was modified locally
> 3. both of the above 
>
> In case 1 the modification could be merged silently, in case 2 the
> modification should be left alone and in case 3 I'd have to decide what
> to do. Config::Model on its own couldn't tell the difference.

Currently a maintainer set some value in a package config file to
reflect his decisions or debian policy or whatever. 

With Config::Model such decision would not be encoded in the delivered
config file but in the model of the configuration file. This would be
specified in the configuration model as a default value.

Here's what will happen during an upgrade:

a. Config::Model will dump customized value somewhere (dump values
  which are different from maintainer's model version N. i.e. this
  will keep track of values from case 2 and 3 *if* they are different
  from the default value specified in the old model version N ).

b. application model is upgraded from N to N+1 (case: 1 and 3: some
  default config values are changed)

c. Config::Model performs the merge:
  * case 1: no customized value stored in step a. Config::Model will
write the default value (specified in the new model version N+1)
in the config file
  * case 2: customized value stored in step a. is loaded, checked and
will be written in configuration file
  * case 3: just like case 2 

I hope this replies to your concerns. If not feel free to ask more
questions.

>> - yes, merging would work mostly without conflict 
>
>> 
>> > Similar to like SCMs work.
>> 
>> The main difference between a SCM and Config::Model is that a SCM
>> works purely at text level without knowledge of the semantic of the
>> file under control. OTOH, Config::Model uses the semantic knowledge
>> provided by the model to perform the upgrade.
>
> You could apply the way merges work in an SCM to structured
> information.

More often than not, the order of the configuration data is not
important. For SCM merge, this order *is* important. 

> Having the diff between the last and the new maintainer version is not
> an alternative to Config::Model. The former can tell me what has
> changed in what way and the latter can present this information
> enriched with its semantic knowledge of the changes. Both are things I
> find useful. So my question is, if Config::Model can also deal with the
> additional information of what has changed how, so the two things could
> be combined?

Config::Model can only show the diff between the current state
(current file or file + modifications) and the default values from the
configuration model. There's no notion of history or diff with
previous version of a configuration file. Well, not yet. I'll have to
think about this...

All the best

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

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

[Joerg Schilling]

**
If you are using a coding other than 7-Bit ASCII or ISO-8859-1, you need to 
properly declare your transfer encoding. Please fix your mail client!
**

Josselin Mouette  wrote:

> Le jeudi 26 février 2009 à 13:55 +0100, Joerg Schilling a écrit :
> > Josselin Mouette  wrote:
> > 
> > > Le jeudi 26 février 2009 à 12:57 +0100, Joerg Schilling a écrit :
> > > > If Debian likes to get sued...
> > >
> > > Nobody likes it, but since you keep claiming around and around that what
> > > we are doing is illegal, maybe it is time to see on what grounds you are
> > > saying that.
> > 
> > The fork _is_ illegal and it is bad to see that Debian did hide the related 
> > bug 
> > report I made in December 2006.
>
> I???ll teach you something then: trying to intimidate people by making
> legal threats without ground is illegal in many countries. Either you
> prove they have ground (and you???ll have to go to court for that), or you
> stop making such threats *right now*.

A good point: Debian currently spreads several unproven claims about the 
original software. It would help a lot of these claims were removed.


> > The original software on the other side is legal.
>
> Of course, since you are the author you can do whatever you want with
> it. However, the restrictions you impose on redistribution don???t allow
> us to distribute it as we want to.

This is wrong: I don't impose any restriction that makes the original code
undistributable. The fork however includes modifications that are incompatible 
with the requirements from the Copyright law and the GPL.
 
> > I am not sure what software you are referring to. 
> > If you are _really_ sure about this, then I recommend you to fix the bugs 
> > in 
> > your software. I get however lots of reports from various users who 
> > successfully
> > replaced the non-working fork by the working original software.
>
> I seriously doubt they can use any serious and modern frontend with the
> version you are currently distributing.

If you see problems with any frontend, you should make a bug report. The 
original software works as documented. If there is any frontend does not work, 
it 
has been broken and needs to be fixed.

BTW: 
-   K3b preferres the original cdrtools because they work correctly.

-   Xcdroast also works correctly if you use the original software.

There are many reports from people who replaced the fork by unmodified original 
software in order to finally be able to write CDs and DVDs.


> > > especially because of the lack of UTF-8 support. After all, Unicode is
> > > only a 18-year old standard, so I understand it is a bit too much to ask
> > > for its support.
> > 
> > So why is there no UTF-8 support in the fork, you even have a related bug 
> > report in the debian bug tracking?
>
> This report is clearly bogus. The reason why UTF-8 is not listed is that
> it is the charset that is selected when no option is specified.
>
> Several frontends to genisoimage/wodim *only* work with UTF-8 filenames.
> If they were serious issues with it, believe me, we???d know it.

You are uninformed and it does not make sense to continue the discussion 
unless you first inform yourself:

-   The fork introduced a non-working fake "implementation" for UTF-8 and
for this reason, there is a related bug report in the debian bug 
tracking system.

-   The original software implements a fully working UTF-8 support

> > wodim still has a lot more bugs than the outdated original it was based on.
>
> Show them. Come on.

I encourage you to read the Debian bug tracking system!

None of the bugs listed in the debian bug tracking system applies to the 
original software.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


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

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

[Josselin Mouette]

Please don’t forward private replies to a public mailing list: this is
very rude behavior.

Le jeudi 26 février 2009 à 17:08 +0100, Joerg Schilling a écrit :
> **
> If you are using a coding other than 7-Bit ASCII or ISO-8859-1, you need to 
> properly declare your transfer encoding. Please fix your mail client!
> **

The email you are replying to declares:

Content-Type: multipart/signed; micalg=pgp-sha1; 
protocol="application/pgp-signature"; boundary="=-QLLn2OxCNRVAvKDPZ8Na"
[snip]
--=-QLLn2OxCNRVAvKDPZ8Na
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

See? “charset=UTF-8”. I’m using a mail client that understands encodings
that have been developed less than 20 years ago.

> > Of course, since you are the author you can do whatever you want with
> > it. However, the restrictions you impose on redistribution don???t allow
> > us to distribute it as we want to.
> 
> This is wrong: I don't impose any restriction that makes the original code
> undistributable. The fork however includes modifications that are 
> incompatible 
> with the requirements from the Copyright law and the GPL.

Repeating yourself over and over again is not going to make your claims
true.
 
> > I seriously doubt they can use any serious and modern frontend with the
> > version you are currently distributing.
> 
> If you see problems with any frontend, you should make a bug report. The 
> original software works as documented. If there is any frontend does not 
> work, it 
> has been broken and needs to be fixed.

Indeed, the frontends have all been fixed, by calling wodim instead of
cdrecord. And now they work as expected.

> There are many reports from people who replaced the fork by unmodified 
> original 
> software in order to finally be able to write CDs and DVDs.

Please forward us such reports of people doing that successfully within
Debian; this looks like a lot of fun. Not forgetting that distributing
such solutions would violate the licensing of several of the frontends.

> > > wodim still has a lot more bugs than the outdated original it was based 
> > > on.
> >
> > Show them. Come on.
> 
> I encourage you to read the Debian bug tracking system!

Sorry, but simple reports are not convincing without analysis. Please
show where the bugs come from, and explain why they don’t apply to
cdrecord.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message	numériquement signée

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

[Brett Parker]

On 26 Feb 15:47, Joerg Schilling wrote:
> Brett Parker  wrote:
> 
> > On 26 Feb 11:27, Joerg Schilling wrote:
> > > - The fork is in conflict with the Copyright law and thus may not be 
> > >   legally distributed.
> >
> > Err, it's a fork of the GPL2 code, before you went insane and relicenced
> > half of it to CDDL and added random "Don't change this" invariant
> > sections - how do you see it conflicting with Copyright law?
> 
> Before Eduard Bloch made insane modifications, the code was GPLv2 and legal.
> Now the cude is undistributable because of modifications in the fork
> that are incompatible with the Copyright law.
>  
> See my bug report from December 2006.

Is this the one that doesn't actually give any details but does just
randomly say the above? i.e. insubstantiated claims, and further
spreading of FUD?

> > > - The fork is in conflict with the GPL and thus may not be legally
> > >   distributed.
> >
> > Errr, in what way?
> 
> See my bug report from December 2006.

See above.

> >
> > > - The fork is full of bugs that have been introduced by the person who
> > >   initiated the fork and for this reason did not get the permission
> > >   to use the original name. Note that it is not even allowed to ship
> > >   symlinks with the original names as this makes users believe that
> > >   they use the original software.
> >
> > As someone that uses wodim quite a bit, I've not noticed it to be "full
> > of bugs", so I'd suggest that you're spreading FUD and hoping that no
> > one notices.
> 
> It seems that you are spreding FUD. Everybody who is interested in working
> CD/DVD creating uses the original software. There are nearly 100 Bug Reports 
> against the fork in the bug tracking systems from Debian, Ubuntu and Redhat, 
> none of the reports applies to the original software.

Interesting - so, in your (somewhat naive) opinion - the *only* cd
burning software worth mentioning is your very own pet project... weird
that you would be so biased on that isn't it?

Does this mean that you're also blissfully unaware of the cdskin and
libburn projects? Apparently not everyone that is interesting in working
CD/DVD creation wants to use your software - apparently not everyone in
the world agrees with your view point. Now, kindly drop the FUD
spreading that your software is the only working software in the world
(there are plenty, for example, of free CD/DVD creation tools for the
Windows operating system, I suppose you'll claim all of those are using
your code? Yeah. Right.).

I'm very interested in *working* CD/DVD creation, and I've been very
happy with cdrkit - if you're telling me that the CDs/DVDs that I have
created (and used) with wodim don't work, then I'm *amazed*!

> > > If you like to blame a specific person for the current problems, you need 
> > > to 
> > > blame the person who started the "fork" based on very a outdated version, 
> > > who
> > > ripped off the working DVD support code, who introduced dozens of new 
> > > bugs and
> > > who stopped working on the fork on May 6th 2007, leaving the fork 
> > > unmaintained. An interesting aspect of this person is that he started to 
> > > advertize for Nerolinux after May 6th 2007. It seems that he never was 
> > > interested in supporting FROSS but in causing harm for FROSS.
> >
> > Very outdated version because of the licencing issues introduced by you
> > stopping a fork at any later version...
> 
> The original software did not introduce licensing issues. Please do not 
> spread 
> FUD. The original code had a full legal review by the Sun legal department.
> The fork however is undistributable because some people ignored the rules from
> GPL and Copyright law.

Which rules? The author ignored the GPL by adding invariant sections,
certainly. Well done.

> > > If you look at the bug tracking systems of the Linux distributors that
> > > ship the illegal fork, you see a total of aprox. 100 bugs (many of them 
> > > are 
> > > showstopper bugs) that are specific to the fork. Upgrading to recent 
> > > original software from:
> > > 
> > > ftp://ftp.berlios.de/pub/cdrecord/alpha/
> >
> > The fact that says 'alpha' of course inspires us all with confidence.
> 
> The quality of the original software is much better than the quality of the 
> fork.

That is, of course, purely your opinion.

> The minimal requirements for a "stable release" is that the software does not
> have known bugs at release time. Using this rule, there never has been _any_
> release from the fork while at the same time there have been 50 stable 
> releases
> from the orignal software.

Ahh - but unknown bugs are fine... and I'd suggest that if you've done
50 releases since then, then you've had plenty of unknown bugs on the
way - using this metric, I don't believe that you've ever made a stable
release.

> > > fixes all bugs from the bug-tracking systems that are not caused by 
> > > packaging,
> > > bugs in the Linux kernel or bugs in the Linux variant of hald.
> >
> > So,

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

[Joerg Schilling]

Josselin Mouette  wrote:

> Please don???t forward private replies to a public mailing list: this is
> very rude behavior.

Well, this is an open discussion and I see no reason not to share your rude 
replies with others.


> Le jeudi 26 février 2009 à 17:08 +0100, Joerg Schilling a écrit :
> > **
> > If you are using a coding other than 7-Bit ASCII or ISO-8859-1, you need to 
> > properly declare your transfer encoding. Please fix your mail client!
> > **
>
> The email you are replying to declares:
>
> Content-Type: multipart/signed; micalg=pgp-sha1; 
> protocol="application/pgp-signature"; boundary="=-QLLn2OxCNRVAvKDPZ8Na"
> [snip]
> --=-QLLn2OxCNRVAvKDPZ8Na
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable

This is not true, your mail does not contain the content encoding type line you 
claim.

My mail (the one you did reply to) on the other side is correct:

...
In-Reply-To: <1235654190.5228.47.ca...@shizuru>
User-Agent: nail 11.22 3/20/05
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: joerg.schill...@fokus.fraunhofer.de

So please fix your mailer

> > If you see problems with any frontend, you should make a bug report. The 
> > original software works as documented. If there is any frontend does not 
> > work, it 
> > has been broken and needs to be fixed.
>
> Indeed, the frontends have all been fixed, by calling wodim instead of
> cdrecord. And now they work as expected.

If you believe that breaking a frontend is a godd idea, then you should
not be a maintainer.


> > There are many reports from people who replaced the fork by unmodified 
> > original 
> > software in order to finally be able to write CDs and DVDs.
>
> Please forward us such reports of people doing that successfully within
> Debian; this looks like a lot of fun. Not forgetting that distributing
> such solutions would violate the licensing of several of the frontends.

Please read the Debian bugtracking system for at least 70% of the typical well 
known bugs in the fork...Note that you may need to check _all_ entries even 
those declared as "closed" as many of them never have been fixed in the code.


> > > > wodim still has a lot more bugs than the outdated original it was based 
> > > > on.
> > >
> > > Show them. Come on.
> > 
> > I encourage you to read the Debian bug tracking system!
>
> Sorry, but simple reports are not convincing without analysis. Please
> show where the bugs come from, and explain why they don???t apply to
> cdrecord.

I recommend you to read the Debian bug tracking system. If you do not 
understand the reports and their background, you do not seem have the 
needed skills for a dicussion on the problems.

The bug reports in the Debian bug tracking system do not apply to cdrtools
because they either have been introduced by Eduard Bloch and thus never have 
been in the original software or because they have been fixed years ago in the
original software but obviously not in the fork.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


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

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

[Josselin Mouette]

Le jeudi 26 février 2009 à 17:59 +0100, Joerg Schilling a écrit :
> > The email you are replying to declares:
> >
> > Content-Type: multipart/signed; micalg=pgp-sha1; 
> > protocol="application/pgp-signature"; boundary="=-QLLn2OxCNRVAvKDPZ8Na"
> > [snip]
> > --=-QLLn2OxCNRVAvKDPZ8Na
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: quoted-printable
> 
> This is not true, your mail does not contain the content encoding type line 
> you 
> claim.

Are you actually contesting the contents of a PGP-signed email ?

Now *that* is very interesting.

> So please fix your mailer

There is nothing broken in my mailer; it conforms to RFC 1847 (Security
Multiparts for MIME). Yours does not.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Proposal to improve package configuration upgrades

[sean finney]

hiya zack,

On Thu, Feb 26, 2009 at 09:14:23AM +0100, Stefano Zacchiroli wrote:
> Well, it depends on how dpkg currently handles merges. My impression
> (as a user, never looked at the actual code) is that it not even tries
> to merge, it simply discovers that the local file is not pristine and
> then asks the user. On the contrary, every VCS I'm aware of at least
> _tries_ a merge, "succeeding" when changes do not affect the same
> patch hunk.

it can't do a merge currently, because it doesn't have the common
ancestor available to do a 3-way diff.  

> Of course that would mean that dpkg should be made aware of the
> difference between the last pristine configuration file installed on
> the machine, and the configuration file the package being installed is
> shipping.

if you go about a year back or so in the dpkg-mailing lists/bts (or
look in the debian wiki, there's references there somewhere) you'll see
some stuff i proposed--including a working patch.  unfortunately this
never seemed to amount to much and didn't keep the interest of the relevant
dpkg maintainer. 


sean

-- 


signature.asc
Description: Digital signature

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

[Kai Wasserbäch]

[WARNING: THIS MESSAGE IS PGP/MIME SIGNED, DON'T BLAME MY MUA ;)]

The only thing I remember is an ancient (2006) discussion on heise online (and
probably elsewhere too) [0] (German only, sorry) about this topic and all this
has been brought forward and not backed up by any proofs. Back then the last
reply was not to reply... could we please skip to that part. It's just not worth
the effort.

@all the DDs/DMs and all other contributors: please don't feed the troll. ;)

Thanks,
Kai

[0] http://www.heise.de/open/news/foren/forum-104357/msg-11172557/read/


Joerg Schilling schrieb:
>> xcdroast is looking for cdrecord, which does no longer exist in Debian 
>> Sid (apparently). And wodim does no longer provide a symlink as cdrecord 
>> or something (apparently).
> 
>> So: xcdroast does no longer work. Who is to blame (Bug entry): xcdroats 
>> or wodim?
> 
> You need to blame the people who are responsible for removing cdrecord
> and who started to include a fork (wodim) that cannot be legally distributed.
> 
> Just add cdrecord from:
> 
> ftp://ftp.berlios.de/pub/cdrecord/alpha/
> 
> and you get a legal and working system.
> 
> Jörg



-- 

Kai Wasserbäch (Kai Wasserbaech)

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



signature.asc
Description: OpenPGP digital signature

Re: DebConf10 to take place in New York City, USA

[dan]

On Thursday 26 February 2009 08:08:50 Mike Hommey wrote:
> On Wed, Feb 25, 2009 at 02:31:24PM -0500, Jimmy Kaplowitz wrote:
> > Further, we're definitely going to be giving people invitation
> > letters and other advice to make sure they present themselves in
> > the best (accurate) light they can to the visa or border officials,
> > as well as separate exaggeration from fact with regard to border
> > search and other privacy concerns so that people can make rational
> > decisions based on reality instead of sensationalism.
>
> Sensationalism like
> http://www.schneier.com/blog/archives/2008/08/us_government_p.html
> http://www.schneier.com/blog/archives/2008/05/crossing_border.html
> ?
Mr. Hommey,
I doubt Mr. Kaplowitz has the power to do anything much about the issues 
you use someone elses blog to bring into the conversation,  no doubt you 
have more clout to shape the french governments policies.
I would like to share this with you though. Ten years ago I married an 
English lady and moved to the UK. I didn't bring my computers with me as 
i planned to buy some when I settled, I did however bring disks, linux 
cd's, etc. Immigration here insisted on knowing where my computers were 
so that that they could inspect them...whether I had shipped them ahead 
or they were coming later.  It took hours and hours. I found the whole 
matter very comical on one one hand and very sad on the other. This was 
some ten years ago and pre 9/11. My point is, in case you missed it, is 
that the United States is not the only country in the world who has such 
policies in place. If you doubt my point, stick your laptop in a 
backback and come over to the UK.

I've used Debian for about ten years now, always been proud to say I 
used it. In the course of the past few years though, the bickering on 
the lists (particularly the political cheap shot like you just took) 
have really worn on me. As I said, I'm just a normal user. Nobody 
important, I mainly just read the list, help out at my local lug with 
Debian installs and recommend Debian to everyone that asks about linux.
Your post though is pretty much the straw that broke the camels back. I 
want to read and talk about linux and Debian.
Until DD's like you learn to leave the political sht at the door and 
just discuss issues relevant to Debian, I'm off to another distrobution. 
And don't worry, I won't let the door hit me in the ass on the way out.





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

Upcoming Section changes in the archive

[Joerg Jaspert]

Hello world,

As Lenny is finally released, and we are early in the cycle for squeeze,
now is the best time to do some long-needed changes to our archive.
Much of what we are currently doing is not visible to you as a user of
this archive, but the action we talk about now is:

We plan on changing the current sections in the archive. With the rapid
growth of archive, many of them have become too big to be useful anymore.

While we acknowledge that something like debtags will make a better
long-term solution, we do not think that it is ready yet to completly
replace sections (e.g. because it isn't assured that all packages have
tags). This is why we chose to go ahead and adjust what we have,
instead of hoping that debtags can mature enough in time for squeeze.

We plan on finally removing the already deprecated section base.
Earlier in Debian's lifetime our installer used the base section to
mark packages important for the base system. This is no longer needed,
debian-installer has much better ways to do the same thing, hence it
can go away.

We also plan on adding a number of new sections. At the bottom of this
mail we provide a listing of which packages will initially be put into
those new sections. If you think one of your packages should be put
into one of the new sections but it won't be seen by the matches we
list, please tell override-cha...@debian.org, and it will be moved.

NOTE:
This is not yet done, but will be done soon. We will send a mail to
d-d-a when we made the changes.

There is NO upload required to move a package to a new section.
DO NOT UPLOAD YOUR PACKAGE FOR A SECTION CHANGE ONLY.
It is enough if you change your debian/control file in the next regular
upload, after we announced the new sections exist.


The new sections are:

ruby Everything about ruby, an interpreted object oriented
 language.
java Everything about Java
videoVideo viewers, editors, recording, streaming
fontsFont packages
gnustep  The Gnustep environment
xfce The XFCE Desktop, fast and lightweight Desktop
 Environment.
httpdWebservers and their modules
localisationsLanguage packs
debugDebug packages
lisp Everything about Lisp
vcs  Version control systems
haskell  Everything about haskell
zope Zope/Plone Framework
database Databases
kernel   Kernel and Kernel modules

The initial set of packages moved into the new sections will be found
using the following matches:

ruby
ruby-*
*-ruby
lib*-ruby1.[89]
irb*
jruby*
racc
rake
rant
rbbr
rcov
*eruby*
rails
rubilicious
soap4r
redcloth
rubyfilter
rubyluabridge
java
java*
sun-java*
*-java
openjdk-*
kaffe*
cacao*
jikes*
default-jdk*
ecj*
fastjar
gcj*
libgcj*
gij*
ikvm
jclassinfo
jflex
jlex
jlint
junit*
nice
maven*
ant
ant-*
tomcat*
jetty*
video
aatv
aview
avifile-*
cfourcc
dov4l
dvb*
dvd*
dvgrab
dvr
elisa*
fbtv
flvtool*
*ffmpeg*
freevo
*-mediaplayer
*mplayer*
*xine*
gnash*
gqcam
hasciicam
kino
ktoon
klash
kvdr
libdv-bin
me-tv
mkvtoolnix*
motion
ogle*
openmovieeditor
pia
pyvnc2swf
recordmydesktop
scantv
smpeg*
streamer
swfdec*
swfmill
thoggen
tvtime
v4l*
vamps
vdr*
vlc*
wmtv
xawtv*
fonts
ttf*
cmap*
xfonts*
font*
cm-*
culmus*
dvi2ps-fontdata-*
gsfonts*
 

Re: Upcoming Section changes in the archive

[Adeodato Simó]

* Joerg Jaspert [Thu, 26 Feb 2009 21:07:35 +0100]:

> database
> libmysql*
> libdb4*

I'm not sure these (and possibly *some* of the other lib* packages
included in the listing) should be moved out of Section: libs. I can see
how having a database section to browse can be useful, but I don't think
support libraries have a place there, since they're something that's
going to be installed because of dependencies, and not intentionally.

Thoughts?

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
 Listening to: Luke Vibert - Synthax


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

Re: Forthcoming changes in kernel-package

[Theodore Tso]

On Fri, Feb 20, 2009 at 12:56:30PM -0600, Manoj Srivastava wrote:
> > BTW, I have a set of patches you might want to consider.  I'll file
> > them in BTS if you're currently making make-kpkg.
> 
> Please. I have been thinking about the request you made for
>  debugging symbols being packaged, and now I do have some time to play
>  with building kernels again, I would like to see that in Squeeze.

Sorry for the delay; I've sent you the private patches I've been using
for make-kpkg.  Some of them are quite hackish, and some of they you
may have fixed in other ways, so I won't feel bad at all if you need
to significantly rework them before you can merge them into your
master sources.

The BTS bug numbers are #517290, #517291, #517292, and #517293.

Best regards,

- Ted


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

Re: Proposal to improve package configuration upgrades

[Stefano Zacchiroli]

On Thu, Feb 26, 2009 at 07:07:30PM +0100, sean finney wrote:
> On Thu, Feb 26, 2009 at 09:14:23AM +0100, Stefano Zacchiroli wrote:
> > Well, it depends on how dpkg currently handles merges. My impression
> > (as a user, never looked at the actual code) is that it not even tries
> > to merge, it simply discovers that the local file is not pristine and
> > then asks the user. On the contrary, every VCS I'm aware of at least
> > _tries_ a merge, "succeeding" when changes do not affect the same
> > patch hunk.
> 
> it can't do a merge currently, because it doesn't have the common
> ancestor available to do a 3-way diff.  

Yes, that's clear. In fact my idea (actually, more of a flux of
thoughts) was to externalize that information, as in:

- dpkg discovers a change (and it can do that using plain old
  checksums as it currently does)
- it checks whether there is an hook registered to do that
- if so, it invokes it by passing (API totally approximated) the
  path of the current conffile, the version of the package owning it
  which is being removed, the path of the new file
- it is now up to the hook to be able to retrieve the old file, which
  a VCS in someway can be able to do [*]

then you have different ways for the hook to return, such as:
- 0: yay, everything merged -> continue without bothering the user
- 1: don't know what to do (e.g., I cannot retrieve the old file)
 -> fallback to the current behavior or try some other hook
- 2: merge failure -> offer the change to revert and fallback, or
 maybe to examine the conflict as we usually do with VCSs


[*] Now that you make me think about it however, it would be perfectly
plausible to request dpkg to store under /var/lib/dpkg/info/ all
pristine copies of configuration files, instead of only their
checksums (I doubt the space consumption would be significant). If
that is acceptable, you can pass the hook the actual path to the
old pristine conffile without requesting the hook to be able to
retrieve it. YMMV.

> > Of course that would mean that dpkg should be made aware of the
> > difference between the last pristine configuration file installed
> > on the machine, and the configuration file the package being
> > installed is shipping.
> 
> if you go about a year back or so in the dpkg-mailing lists/bts (or
> look in the debian wiki, there's references there somewhere) you'll
> see some stuff i proposed--including a working patch.  unfortunately
> this never seemed to amount to much and didn't keep the interest of
> the relevant dpkg maintainer.

Can you please give some tiny teeny details about what strategy did
you implement? In this thread, and from your mail, I don't get yet
which approach you could possibly have taken ..., but thanks for the
heads up!

Cheers.

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


signature.asc
Description: Digital signature

Re: Upcoming Section changes in the archive

[Frans Pop]

Joerg Jaspert wrote:
> We plan on changing the current sections in the archive. With the rapid
> growth of archive, many of them have become too big to be useful
> anymore. 

Great.

> The new sections are:
[...]
> localisationsLanguage packs

I'd prefer "localization".

- We use en_US in general -> "ize"
- Having the section name plural seems inconsistent with other sections.

> video
[...]
> dvd*

I wonder if packages like dvd+rw-tools*, dvdisaster or dvdrtools really 
belong in this category. Not all that's DVD is video related.
For example, dvd+rw-tools contains growisofs, which is used to create 
Debian CDs...

> httpd

Add boa.

> vcs

What about packages like libcvs-perl or libgit-ruby? Do they stay with the 
language or move to this new category?

Cheers,
FJP


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

Re: Upcoming Section changes in the archive

[Stefano Zacchiroli]

On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote:
> The new sections are:

Not like it is *that* important, but we now have more than 100
OCaml-related source packages in the archive, most of which are
libraries for OCaml development.

I don't if that warrants an "ocaml" section, which is your call, but
if it does, well, ... heads up :-)

The regex over binary package names would be "lib.*-ocaml.*",
currently matching 160 binary packages in the APT database on my
laptop (unstable + experimental).

Cheers.

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


signature.asc
Description: Digital signature

Re: Upcoming Section changes in the archive

[Michal Čihař]

Hi

Dne Thu, 26 Feb 2009 21:07:35 +0100
Joerg Jaspert  napsal(a):

> database Databases
[...]
> database
> postgresql*
> pg*
> sqlite*
> mysql*
> libmysql*
> db4.*
> libdb4*
> firebird*
> sql-*   
> qdbm*

I think this needs a bit detailed specification. Is this going to be
for servers or also libraries? In latter case definitely something is
missing, eg. libdbi.*, libgdbm.*.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: Upcoming Section changes in the archive

[Andreas Rottmann]

Joerg Jaspert  writes:

> The new sections are:
[...]
> lisp Everything about Lisp
[...]
>
Is this just about Common Lisp, or other Lisp dialects as well? I'm
mainly referring to Scheme here, as it is another Lisp dialect in
(relatively) widespread use (the third one being Emacs-Lisp).

Regards, Rotty


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

Re: Upcoming Section changes in the archive

[Rene Engelhard]

Hi,

Joerg Jaspert wrote:
> java Everything about Java
{...}
> gcj*

*gcj, too probably.

> database
> postgresql*
> pg*
> sqlite*
> mysql*
> libmysql*

That also hits database libs. Which makes me wonder what the best for
libhsqldb-java is. databases or java? :)

(hsqldb-server probably should be in databases)

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73


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

Re: Upcoming Section changes in the archive

[Bernd Zeimetz]

Stefano Zacchiroli wrote:
> On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote:
>> The new sections are:
> 
> Not like it is *that* important, but we now have more than 100
> OCaml-related source packages in the archive, most of which are
> libraries for OCaml development.
> 
> I don't if that warrants an "ocaml" section, which is your call, but
> if it does, well, ... heads up :-)


b...@think:~$ apt-cache search liblua | wc -l
84

So I guess we should have a lua section, too?
liblua.* would fit into that section at least.

Cheers,

Bernd

-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


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

Re: Upcoming Section changes in the archive

[Daniel Moerner]

On Thu, Feb 26, 2009 at 12:07 PM, Joerg Jaspert  wrote:
> lisp            (no, not in brackets)
>                cl-*
>                *-lisp
>                *-el

Two things:

First, if by Lisp you mean everything related to Lisp, then this
should probably also include scheme*, not just Common Lisp packages.
Scheme will require more manual work because many Scheme interpreters
have bizarre names.

Second, as far as I can tell, Sections can be set for either binaries
or source packages in debian/control. There are some source packages
that distribute *-el binaries (scheme48, which I just adopted, for
instance). I trust that this move will only move the binary packages
and not drag along the source and other binaries it produces?
(Obviously this is not problem for scheme48, but it might pop up for
other packages.)This may be an ignorant question but IANADD.

Regards,
Daniel Moerner

-- 
Daniel Moerner 


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

Re: DebConf10 to take place in New York City, USA

[Russell Coker]

On Fri, 27 Feb 2009, dan  wrote:
> > > search and other privacy concerns so that people can make rational
> > > decisions based on reality instead of sensationalism.
> >
> > Sensationalism like
> > http://www.schneier.com/blog/archives/2008/08/us_government_p.html
> > http://www.schneier.com/blog/archives/2008/05/crossing_border.html
> > ?
>
> I would like to share this with you though. Ten years ago I married an
> English lady and moved to the UK. I didn't bring my computers with me as
> i planned to buy some when I settled, I did however bring disks, linux
> cd's, etc. Immigration here insisted on knowing where my computers were
> so that that they could inspect them...whether I had shipped them ahead
> or they were coming later.  It took hours and hours. I found the whole
> matter very comical on one one hand and very sad on the other. This was
> some ten years ago and pre 9/11. My point is, in case you missed it, is
> that the United States is not the only country in the world who has such
> policies in place. If you doubt my point, stick your laptop in a
> backback and come over to the UK.

I have entered the UK by plane several times before 911 and many times 
afterwards.  I have entered the UK via the chunnel many more times.  On every 
occasion I had at least one laptop, sometimes I had multiple laptops, a PDA, 
or even a Cobalt Qube.  I always had enough computer gear to stand out from 
the crowd.  On no occasion did the UK border security people pay any 
particular attention to such devices.

While it is well known that the UK have laws and policies that permit them to 
search laptops etc, my experience suggests that such searches are performed 
in only a small minority of cases.  They have however vacuumed my pockets for 
traces of drugs which I think is grossly wrong.  If for example I had 
received as change some money with drug traces then I could have had some 
problems.  IMHO any quantity of drugs that is too small to get high should 
not be illegal (as a separate issue I think that the war on drugs is entirely 
bad and should be stopped).

My experience on entering the US (which I did many times before and after 911) 
was that they sometimes want me to turn my laptop on but never to get past 
the boot screen.  They have never wanted to seize or search computer gear.

I conclude that both the UK and the US search computers quite rarely.  That 
said, it would really suck to be subject to the type of search that Bruce 
describes.

> I've used Debian for about ten years now, always been proud to say I
> used it. In the course of the past few years though, the bickering on
> the lists (particularly the political cheap shot like you just took)
> have really worn on me. As I said, I'm just a normal user. Nobody
> important, I mainly just read the list, help out at my local lug with
> Debian installs and recommend Debian to everyone that asks about linux.
> Your post though is pretty much the straw that broke the camels back. I
> want to read and talk about linux and Debian.
> Until DD's like you learn to leave the political sht at the door and
> just discuss issues relevant to Debian, I'm off to another distrobution.
> And don't worry, I won't let the door hit me in the ass on the way out.

It's not political shit, it's a fair warning about a government policy that 
could disadvantage some DDs while travelling to an official Debian event.

I agree that it would be off-topic for debian-user.  As you describe yourself 
as a user you might find that list to be more suitable to your needs.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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

Re: Upcoming Section changes in the archive

[Frank Lin PIAT]

On Thu, 2009-02-26 at 21:07 +0100, Joerg Jaspert wrote:
> The new sections are:
[..]
> videoVideo viewers, editors, recording, streaming

What about renaming sound as audio? (if we introduce the video one, )

Since the (perl|python|ruby|...) sections should contains libraries,
modules, engines but not end-users applications, should they be renamed?
(perl-lib, or something better)

Some sections are hardly used and could be removed, especially
"news" (~35 pkg). Also "shells" has only 25 pkg.

Franklin


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

Re: Upcoming Section changes in the archive

[Joerg Jaspert]

> Not like it is *that* important, but we now have more than 100
> OCaml-related source packages in the archive, most of which are
> libraries for OCaml development.

> I don't if that warrants an "ocaml" section, which is your call, but
> if it does, well, ... heads up :-)

Get me a short description for it.

> The regex over binary package names would be "lib.*-ocaml.*",
> currently matching 160 binary packages in the APT database on my
> laptop (unstable + experimental).

ocaml   

   
ocaml-* 

   
lib*ocaml*  

   

-- 
bye, Joerg
* maxx hat weasel seine erste packung suse gebracht, der hat mich dafür
  später zu debian gebracht
 .oO( und jetzt ist der DD.  jeder macht mal fehler.. )
 du hast 2 gemacht du warst auch noch advocate :P


pgpRksqsQFy7c.pgp
Description: PGP signature

Re: Upcoming Section changes in the archive

[Samuel Thibault]

Joerg Jaspert, le Thu 26 Feb 2009 21:07:35 +0100, a écrit :
> We plan on changing the current sections in the archive. With the rapid
> growth of archive, many of them have become too big to be useful anymore.
> 
>[...]
> 
> The new sections are:
> 
> ruby Everything about ruby, an interpreted object oriented
>  language.
> java Everything about Java
> videoVideo viewers, editors, recording, streaming
> fontsFont packages
> gnustep  The Gnustep environment
> xfce The XFCE Desktop, fast and lightweight Desktop
>  Environment.
> httpdWebservers and their modules
> localisationsLanguage packs
> debugDebug packages
> lisp Everything about Lisp
> vcs  Version control systems
> haskell  Everything about haskell
> zope Zope/Plone Framework
> database Databases
> kernel   Kernel and Kernel modules

Maybe it could be interesting to open an accessibility section?

Samuel


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

Re: Upcoming Section changes in the archive

[Joerg Jaspert]

On 11673 March 1977, Adeodato Simó wrote:
> * Joerg Jaspert [Thu, 26 Feb 2009 21:07:35 +0100]:
>
>> database
>> libmysql*
>> libdb4*
> I'm not sure these (and possibly *some* of the other lib* packages
> included in the listing) should be moved out of Section: libs. I can see
> how having a database section to browse can be useful, but I don't think
> support libraries have a place there, since they're something that's
> going to be installed because of dependencies, and not intentionally.

> Thoughts?

Hrmyes. This is a preliminary list of matches only anyway, not the final
holy grail, so we will adjust it wherever neccessary before finally
doing the work. :)

For libmysql* and libdb4* I agree insofar as that are really packages no
user (usually) installs by hand, but gets pulled in as a
dependency. Removed from list.

-- 
bye, Joerg
 since anyone who can get along with elmo must *surely* be part of
 the cabal.
 vorlon: Not true.  I've gotten along with elmo from time to time.
We're just both ashamed of it.


pgpNLkw9L1Uw5.pgp
Description: PGP signature

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

[John Goerzen]

Joerg Schilling wrote:

> 
> The fork distributed by Debian may however be called dubious:
> 
> - The fork is in conflict with the Copyright law and thus may not be 
>   legally distributed.

If your code was Free Software, then it is perfectly legal for Debian to
do what it does.

If your code wasn't Free Software, then we wouldn't be using it in the
first place.

ISTR that your code WAS free, but now isn't.

So please do not tell us to adopt your source tree for main because a
fork is illegal.  The cognitive dissonance in that statement is amazing.

-- John


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

Re: Upcoming Section changes in the archive

[Joerg Jaspert]

On 11673 March 1977, Frans Pop wrote:

>> localisationsLanguage packs
> I'd prefer "localization".

> - We use en_US in general -> "ize"

Well, I dont really care. Fine, adjusted.

> - Having the section name plural seems inconsistent with other
> sections.

Dito.

>> video
> [...]
>> dvd*
> I wonder if packages like dvd+rw-tools*, dvdisaster or dvdrtools really 
> belong in this category. Not all that's DVD is video related.
> For example, dvd+rw-tools contains growisofs, which is used to create 
> Debian CDs...

Yeah. This will need close(r) inspection when moving packages.

>> httpd
> Add boa.

Done

>> vcs
> What about packages like libcvs-perl or libgit-ruby? Do they stay with the 
> language or move to this new category?

Language.

I intended to add some "section order" to the mail too, but then dropped
this for now. But will come back with that. Basically meaning that, if
your package would fit multiple sections, the higher one would
win. Something like "[language specific section] >> interpreters" and
similar.

-- 
bye, Joerg
 Sesse: I doubt that many people will switch network


pgp0kQeiQbnLg.pgp
Description: PGP signature

Re: Upcoming Section changes in the archive

[Joerg Jaspert]

>> database Databases
> [...]
>> database
>> postgresql*
>> pg*
>> sqlite*
>> mysql*
>> libmysql*
>> db4.*
>> libdb4*
>> firebird*
>> sql-*   
>> qdbm*
> I think this needs a bit detailed specification. Is this going to be
> for servers or also libraries? In latter case definitely something is
> missing, eg. libdbi.*, libgdbm.*.

Currently its mainly servers and modules/"plugins" for them.

-- 
bye, Joerg
Endianess is the dispute on which end to open an egg at.


pgpiQ013IuJhq.pgp
Description: PGP signature

Re: Upcoming Section changes in the archive

[Joerg Jaspert]

>> lisp Everything about Lisp
> Is this just about Common Lisp, or other Lisp dialects as well? I'm
> mainly referring to Scheme here, as it is another Lisp dialect in
> (relatively) widespread use (the third one being Emacs-Lisp).

Its lisp. Not one special part of it, just lisp. So other dialects as
well, if someone gets me a list of packages (or matches) for it.

-- 
bye, Joerg
Some NM:
>A developer contacts you and asks you to met for a keysign. What is
>your response and why?
Do you like beer? When do we meet? [...]


pgp4GaPWqCTTN.pgp
Description: PGP signature

Re: Upcoming Section changes in the archive

[Stefano Zacchiroli]

On Thu, Feb 26, 2009 at 11:48:18PM +0100, Joerg Jaspert wrote:
> > I don't if that warrants an "ocaml" section, which is your call, but
> > if it does, well, ... heads up :-)
> 
> Get me a short description for it.

"Compiler, libraries, and tools for OCaml: a static typed ML language
implementation supporting functional, imperative, and object-oriented
programming styles".

> > The regex over binary package names would be "lib.*-ocaml.*",
> > currently matching 160 binary packages in the APT database on my
> > laptop (unstable + experimental).
> 
> ocaml
> ocaml-*
> lib*ocaml*

Yup, of course I forgot the first pattern in the former post.
Actually, you can add also "*-ocaml" which would match also
"dh-ocaml", our debhelper-like tools for OCaml-related packages.

Cheers.

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


signature.asc
Description: Digital signature

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

[Joerg Schilling]

John Goerzen  wrote:

> Joerg Schilling wrote:
>
> > 
> > The fork distributed by Debian may however be called dubious:
> > 
> > -   The fork is in conflict with the Copyright law and thus may not be 
> > legally distributed.
>
> If your code was Free Software, then it is perfectly legal for Debian to
> do what it does.

It seems that you first need to learn what Free Software means and what 
constraints the License and the Copyright law enforce. A Free software license
allows you to do many things, it does definitely not allow you what Debian did.

> If your code wasn't Free Software, then we wouldn't be using it in the
> first place.

> ISTR that your code WAS free, but now isn't.

The code that was taken by Debian for the fork WAS free but now it is no longer
because Debian did apply changes that are forbidden by law.

As you don't know what grants and what duties you have when dealing with free 
software, please try to inform yourself. You may get into trouble if you change
things that are forbidden by law.

Let me quote the license person from the board of directors from the OpenSource 
initiave:

No OpenSource license gives you all grants you need to change anything  
in the  source. If the authors or Copyright holders of a software like,
they may always sue you. If you like to avoid being sued, play nicely
with the Copyright holders.

Eduard Bloch made a big mistake, he started a deffamation campaign against 
cdrtools and Debian made the mistake to support Eduard Bloch.

I don't know whether you are able to change the named mistake, but please note
that I am the copyright holder for the vast majority of the cdrtools code. I am 
licensing the code and I am able to sue people for Copyright violations on the 
code, Debian is not. If Debian claims they might be sued because of so called 
license problems in the original software, this is just FUD. I am not 
interested to sue people as long as there is a chance to have a solution that 
does not need a court. If Debian however continues to attack me, Debian should
be aware that at some point I am forced to sue people for violating GPL and 
Copyright law with the fork.

So let me ask: Is Debian willing to "play nicely" with me in the future or is
Debian interested in continuing the attacks?

In case you don't know: My main interest is to make sure that the software I 
write remains free and I am doing whaterver I need to ensure this. The license 
change in cdrtools is a _reaction_ on the attacks from Eduard Bloch. So whom 
does Debian support? Is it Eduard Bloch who is the initiator of the attacks or 
is Debian interested rather in Free Software?

I am writing Free Software since 1982, this is much longer than Debian exists.
I support Freedom and if Debian is against Freedom, I cannot support Debian.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


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

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

[Darren Salt]

I demand that Brett Parker may or may not have written...

> On 26 Feb 15:47, Joerg Schilling wrote:
>> Brett Parker  wrote:
>>> On 26 Feb 11:27, Joerg Schilling wrote:
 -  The fork is in conflict with the Copyright law and thus may not be 
legally distributed.
>>> Err, it's a fork of the GPL2 code, before you went insane and relicenced
>>> half of it to CDDL and added random "Don't change this" invariant
>>> sections - how do you see it conflicting with Copyright law?
>> Before Eduard Bloch made insane modifications, the code was GPLv2 and
>> legal. Now the cude is undistributable because of modifications in the
>> fork that are incompatible with the Copyright law.
>> See my bug report from December 2006.

> Is this the one that doesn't actually give any details but does just
> randomly say the above? i.e. insubstantiated claims, and further spreading
> of FUD?

Indeed it is he. He makes for an interesting diversion for a few days (if the
posting rate isn't too high) before it tails off into the same old "wodim is
full of bugs and is illegal! cdrecord is perfect! Use it and gain the
Blessing of St. Joerg!"[1] rant, at which point we all switch off and ignore
him.


[snip]
>> It seems that you are spreding FUD. Everybody who is interested in
>> working CD/DVD creating uses the original software. There are nearly 100
>> Bug Reports against the fork in the bug tracking systems from Debian,
>> Ubuntu and Redhat, none of the reports applies to the original software.

(... idly wonders how many of those 100 are duplicates, but can't be bothered
to check...)

> Interesting - so, in your (somewhat naive) opinion - the *only* cd burning
> software worth mentioning is your very own pet project... weird that you
> would be so biased on that isn't it?

> Does this mean that you're also blissfully unaware of the cdskin and
> libburn projects?

... yes, this thread is following the usual track. I fully expect any
response from St. Joerg to say something like

"But they're not cdrecord; they are not The Original Software. All ye who use
them commit the gravest of sins; and all thy CDs and all thy DVDs shall all
be defective; and ye shall burn forever in the Light of the Perfect Laser
which the Eye of Schilling issueth and the Software of Schilling
controlleth."

[snip]
>> It is not my duty to "fix" Linux kernel bugs or hald bugs if there is not
>> even a way to work around these bugs. But believe me that _all_ well known

>> bugs from the fork disappear if you install the original software from an 
>> unmodified source.

> But it is your duty to claim that anything other than your software is a
> grave travesty and continue spreading unfounded claims? And I have to
> *believe* you that they're all fixed? Maybe it's just that no body files
> bug reports with you...

I wouldn't be surprised to find that he reads the bug trackers of Debian, Red
Hat, Ubuntu etc. then goes off and does some bug fixing.

[snip]
>> Please explain me why there are so many showstopper bugs in the Debian 
>> bugtracking system that are unfixed since 2+ years?

> I'm interested in where you're finding the showstopping bugs - looking at
> the bug reports page for wodim, I can see 9 Important bugs - that's not a
> whole lot of bugs, really. And most of them can probably be closed now that
> lenny has been released and a newer version of cdrkit is in it.

That's easy. It's a bug in wodim, therefore it's a showstopper. :-)

>> If you are interested in your users, you should upgrade from the 
>> undistributable fork to the legal original source as soon as possible.

> Err, the fork is perfectly distributable.

He repeats it in the hope that somebody will believe him. It happens
occasionally (I've seen it), and my opinion is that the one so gulled by him
is, for want of a better word, uninformed. [2]

[snip]
>> What I read here and from other prople in private mail shows that there
>> is mainly missing information at the side of the people who currently
>> work for Debian. I good starter would be if you and others try to inform
>> yourself based on neutral information

Did that.

>> instead of the attacks from this person.

The attacks continued.

"You are uninformed."

"Inform yourself."

"cdrecord is the master of all. All other software *must* *be*
*exterminated*. Go forth, my informed ones, seek it out and destroy it.
EXTERMINATE! EXTERMINATE! *EXTERMINATE!*" [3]

[snip]
>> The third step would be to fetch the latest original source from:
>> ftp://ftp.berlios.de/pub/cdrecord/alpha/

> No, that wouldn't be a third step - and as you appear to just be trying
> to get google juice for that URL by repeatedly pasting it in to a public
> archived mailing list, you may end up losing out.

Hmm, so I shouldn't quote ftp://ftp.berlios.de/pub/cdrecord/alpha/? Why not?
I like quoting ftp://ftp.berlios.de/pub/cdrecord/alpha/. (Muhahaha.)

[snip]
> "Thanks",

.

(Now where did I put that popcorn...)


[1] I might be exaggerating. Slightly. Just a smidg

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

[Darren Salt]

I demand that John Goerzen may or may not have written...

[snip rebuttal of "fork is not legally distributable"]
> So please do not tell us to adopt your source tree for main because a
> fork is illegal.  The cognitive dissonance in that statement is amazing.

I've just worked it out. He's an Electric Monk.

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Travel less. Share transport more.   PRODUCE LESS CARBON DIOXIDE.

I am Eliza of Borg. How does assimilation make you feel?


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

Re: Upcoming Section changes in the archive

[Josselin Mouette]

Le jeudi 26 février 2009 à 21:07 +0100, Joerg Jaspert a écrit :
> ruby Everything about ruby, an interpreted object oriented
>  language.
> java Everything about Java

How about a "cli" section about everything related to Mono and the
Common Language Infrastructure (aka .NET) ? That makes quite a number of
packages now.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Upcoming Section changes in the archive

[Holger Levsen]

Hi Jög,

On Donnerstag, 26. Februar 2009, Joerg Jaspert wrote:
> As Lenny is finally released, and we are early in the cycle for squeeze,
> now is the best time to do some long-needed changes to our archive.
[...]

Cool, nice!

> The new sections are:

I think an r section would be useful, there are already 131 (binary packages) 
in lenny and around thousand around the corner, I've heard :)

> video

mplayer*
vswitch*


regards,
Holger


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

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

[John Goerzen]

Joerg Schilling wrote:
> John Goerzen  wrote:
> 
>> Joerg Schilling wrote:
>>
>>> The fork distributed by Debian may however be called dubious:
>>>
>>> -   The fork is in conflict with the Copyright law and thus may not be 
>>> legally distributed.
>> If your code was Free Software, then it is perfectly legal for Debian to
>> do what it does.
> 
> It seems that you first need to learn what Free Software means and what 
> constraints the License and the Copyright law enforce. A Free software license
> allows you to do many things, it does definitely not allow you what Debian 
> did.
> 
>> If your code wasn't Free Software, then we wouldn't be using it in the
>> first place.
> 
>> ISTR that your code WAS free, but now isn't.
> 
> The code that was taken by Debian for the fork WAS free but now it is no 
> longer
> because Debian did apply changes that are forbidden by law.

When will you enumerate these?

Until you do, I can't see your arguments being taken seriously by anyone.

By enumerate, I mean at the line-by-line level in the source.

I found the rest of your message similarly vague; you said people made
mistakes, that Debian attacked you.  URLs please?

-- John


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

Re: Upcoming Section changes in the archive

[Luciano Bello]

El Jue 26 Feb 2009, Joerg Jaspert escribió:
> ruby                     Everything about ruby, an interpreted object oriented
>                          language.
> java                     Everything about Java

Have sense to inaugurate a section with all the R modules? Nowadays many of 
them are in "math".

$ apt-cache search r- | grep "^r-" | wc -   l
133

luciano


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

Re: LXDE doesnt support Debian Menu

[Bernd Zeimetz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andreas Tille wrote:

> This discussion comes up once or twice per year.  In most cases it is
> triggered by users of freedesktop.org based environments.  They fail to
> see the fact that there are other environments which do not support
> freedesktop.org standards and in this case Debian menu makes
> perfectly sense.

Then the best way is to fix these environments to use freedesktop.org standards,
or to create a "debian" compatible menu for them out of the informations
provided via *.desktop and similar files. I can't see the sense in spenting time
to write a .dekstop file for an application *and* a menu file. That's just a
waste of time. Nothing against supporting old-fashioned environments, but please
use methonds from 2009 to do so.

Thanks,

Bernd

- --
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmnMsAACgkQBnqtBMk7/3l1gQCgtmWE0GJz/M+CE58eToGeeH67
k3sAnRZb4CG+ReXU7oSngc1aB5o8X+M0
=Ti4M
-END PGP SIGNATURE-


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

Re: Upcoming Section changes in the archive

[Edward Betts]

How about:

webfeed - RSS/Atom feed readers, aggregator and utilities

akregator
blam
canto
cl-rss
claws-mail-feeds-reader
dcoprss
evolution-rss
feed2imap
firefox-sagefirefox-sage
kitty
liferea*
magpierss
miro*
newsbeuter
nrss
olive
php-xml-rss
planet
python-feedparser
python-feedvalidator
python-pyrss2gen
rawdog
rss2email
rsskit.framework
rssreader.app
rsstail
snownews
yarssr
yocto-reader

-- 
Edward.


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

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

[Josselin Mouette]

Le jeudi 26 février 2009 à 16:34 -0600, John Goerzen a écrit :
> So please do not tell us to adopt your source tree for main because a
> fork is illegal.  The cognitive dissonance in that statement is amazing.

For someone who can invent contents of PGP-signed emails, inventing
legal breaches is like breathing.

-- 
Joerg Schilling fact #17: cdrecord has no bugs. If you think you found a
bug in cdrecord, this is actually a bug in your eyes.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Upcoming Section changes in the archive

[Aaron M. Ucko]

Joerg Jaspert  writes:

> Its lisp. Not one special part of it, just lisp. So other dialects as
> well, if someone gets me a list of packages (or matches) for it.

As I mentioned directly to override-change before encountering this
message, I'd argue that my goo package is a (somewhat exotic)
candidate.  In general, here's a first cut at a full list, including
it and your initial proposals:

albert
cl-*
clisp*
cmucl*
common-lisp-controller
drscheme
elib
elk
gambc
gauche*
gcl*
goo
guile-*
lush*
mzscheme
oaklisp
plt-scheme
sawfish-lisp-source
sbcl*
scm
scheme2c
scheme48
scsh*
sigscheme
slib
slime
stalin
tinyscheme
xml-to-sexp
*-el
*-elisp
*-lisp

Thanks!

BTW, while compiling that list, I also ran across a couple more
httpds: araneida and hunchentoot.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu


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

Re: Upcoming Section changes in the archive

[Kelly Clowers]

On Thu, Feb 26, 2009 at 15:50, Josselin Mouette  wrote:
> Le jeudi 26 février 2009 à 21:07 +0100, Joerg Jaspert a écrit :
>> ruby                     Everything about ruby, an interpreted object 
>> oriented
>>                          language.
>> java                     Everything about Java
>
> How about a "cli" section about everything related to Mono and the
> Common Language Infrastructure (aka .NET) ? That makes quite a number of
> packages now.

Am I the only one that gets confused by the name "cli"? I always
think "command line interface" first and mono/.net second.


Cheers,
Kelly Clowers


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

Re: Upcoming Section changes in the archive

[Aaron M. Ucko]

Joerg Jaspert  writes:

> Its lisp. Not one special part of it, just lisp. So other dialects as
> well, if someone gets me a list of packages (or matches) for it.

One more: ikarus (which I initially overlooked because it's only
available on i386 :-/).

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu


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

Re: Upcoming Section changes in the archive

[Josselin Mouette]

Le jeudi 26 février 2009 à 17:08 -0800, Kelly Clowers a écrit :
> On Thu, Feb 26, 2009 at 15:50, Josselin Mouette  wrote:
> > Le jeudi 26 février 2009 à 21:07 +0100, Joerg Jaspert a écrit :
> >> ruby Everything about ruby, an interpreted object 
> >> oriented
> >>  language.
> >> java Everything about Java
> >
> > How about a "cli" section about everything related to Mono and the
> > Common Language Infrastructure (aka .NET) ? That makes quite a number of
> > packages now.
> 
> Am I the only one that gets confused by the name "cli"? I always
> think "command line interface" first and mono/.net second.

I don’t like the name either, but can you think of a better one? We
could use “mono”, but it’s the implementation name.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Upcoming Section changes in the archive

[Sam Morris]

On Fri, 27 Feb 2009 02:13:48 +0100, Josselin Mouette wrote:

> Le jeudi 26 février 2009 à 17:08 -0800, Kelly Clowers a écrit :
>> On Thu, Feb 26, 2009 at 15:50, Josselin Mouette 
>> wrote:
>> > Le jeudi 26 février 2009 à 21:07 +0100, Joerg Jaspert a écrit :
>> >> ruby Everything about ruby, an interpreted
>> >> object oriented
>> >>  language.
>> >> java Everything about Java
>> >
>> > How about a "cli" section about everything related to Mono and the
>> > Common Language Infrastructure (aka .NET) ? That makes quite a number
>> > of packages now.
>> 
>> Am I the only one that gets confused by the name "cli"? I always think
>> "command line interface" first and mono/.net second.
> 
> I don’t like the name either, but can you think of a better one? We
> could use “mono”, but it’s the implementation name.

'clr' (common language runtime)? It's the acronym that MS uses quite a 
bit.

Or 'msclr'? 'dotnetclr'?

-- 
Sam Morris
https://robots.org.uk/
 
PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


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

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

[Darren Salt]

I demand that John Goerzen may or may not have written...

> Joerg Schilling wrote:
[snip]
>> The code that was taken by Debian for the fork WAS free but now it is no
>> longer because Debian did apply changes that are forbidden by law.

> When will you enumerate these?

What, and leave him without an argument? Can't have that.

[snip]
-- 
| Darren Salt| linux or ds at  | again representing | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | myself, not Debian | Army
| + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES.

Look under the sofa cushion; you will be surprised at what you find.


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

Re: Upcoming Section changes in the archive

[Daniel Moerner]

On Thu, Feb 26, 2009 at 5:02 PM, Aaron M. Ucko  wrote:
> Joerg Jaspert  writes:
>
>> Its lisp. Not one special part of it, just lisp. So other dialects as
>> well, if someone gets me a list of packages (or matches) for it.
>
> As I mentioned directly to override-change before encountering this
> message, I'd argue that my goo package is a (somewhat exotic)
> candidate.  In general, here's a first cut at a full list, including
> it and your initial proposals:
>

There is one more currently in Debian:

chicken-bin

There is also one sitting in NEW (a secondary priority):

ypsilon

scheme9 has an ITP against it as well...


mzscheme and drscheme are just plt-scheme transitional packages by now


This will certainly make it easier to centralize all the different
Scheme interpreters. (And this reminds me...someone should package
r6rs-doc)

-- 
Daniel Moerner 


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

Re: Upcoming Section changes in the archive

[Enrico Zini]

On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote:

> While we acknowledge that something like debtags will make a better
> long-term solution, we do not think that it is ready yet to completly
> replace sections (e.g. because it isn't assured that all packages have
> tags). This is why we chose to go ahead and adjust what we have,
> instead of hoping that debtags can mature enough in time for squeeze.

There are other issues that make debtags not quite suitable to replace
sections: for example, the workflow is different.  Sections are chosen
by maintainers and ftp-masters, while tags are chosen by a mix of
people.  With the number of tags in the vocabulary approacing 600, we
just can't ask maintainer, ftp-masters, noone really, to know all of
them, and to know how and when to use them properly.


> The new sections are:
> ruby Everything about ruby, an interpreted object oriented
>  language.
> java Everything about Java
> videoVideo viewers, editors, recording, streaming
> fontsFont packages
> gnustep  The Gnustep environment
> xfce The XFCE Desktop, fast and lightweight Desktop
>  Environment.
> httpdWebservers and their modules
> localisationsLanguage packs
> debugDebug packages
> lisp Everything about Lisp
> vcs  Version control systems
> haskell  Everything about haskell
> zope Zope/Plone Framework
> database Databases
> kernel   Kernel and Kernel modules

I would like to consider this an opportunity to use sections to encode
something that fits with their workflow, that is: can we use sections to
carry information that only the maintainer and ftp-master can fill in,
or information for which it's safe and good that maintainer and
ftp-masters have the last say?

I noticed that most of the replies to this message are a run to add
one's favourite section to the list.  Are you sure that you want to go
in that direction?  Where would it lead except to having a poorer
version of debtags?

Some of the current sections *are* useful.  'libs' is useful.  'oldlibs'
is *very* useful, and I'd like to make a Debian QA tag "depends on a
library with section 'oldlibs'", once I find a nice algorithm to compute
the set of packages for it.  I'm happy that 'locali[sz]ations' and
'debug' are added.

All of these section group packages with very specific semanthics: a
package manager can hide 'libs' and 'oldlibs', can provide a special way
to install 'debug' packages corresponding to normal packages currently
installed.  Can offer a list of 'localisation' options for currently
installed packages.  Can warn when trying to install a package that
depends on an 'oldlibs' library, or if given a choice between an
'oldlibs' dependency and another one, pick the other one.  'oldlibs'
could be renamed to 'deprecated', come to think of it, and include
packages that are not libraries but that are still around until we
manage to get rid of them.

'text' is useless, and probably 'video' is going to be useless as well.
Debtags is what you would use for that information.  Putting java
libraries into 'java' instead of 'libs' would just make it harder for a
package manager to hide libraries.  Debtags will work for that,
so no big deal, but at the moment 'libs' is nice because it allows me to
auto-tag packages from that section, based on reliable information
provided by the maintainers.

Let's find more semantically sound sections.  For example, a section
"fringe", that the maintainer can use to signal that the package is
being used, but only by few people or in specific environments or
fields.  We could give specific suggestions on how to consider such
packages, for example we could suggest not to openly expose to the
internet a 'fringe' server, even if it has no open security bugs.  Or
given the choice between a 'fringe' dependency and another one, prefer
the other one.

How about a section for packages that are not maintained upstream
anymore?

Another one could be a 'data' section for "$FOO-data" packages, like
game data, that are always pulled in as dependencies and do not make
sense alone.  Another thing with a clear semanthic, and that for example
package managers could comfortably hide.

I hope I didn't take a tangent that is too weird to make sense.  But
given the premise that sections are useless, rather than just make them
more diversely useless, I'd prefer to twist them a bit into something
else.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini 


signature.asc
Description: Digital signature

Re: LXDE doesnt support Debian Menu

[Russ Allbery]

David Paleino  writes:
> On Thu, 26 Feb 2009 12:36:07 +0100 (CET), Andreas Tille wrote:

>> and at the same time fix all packages that only have a menu but no
>> desktop file."

> This could easily be added as a lintian check, I believe.

FWIW, the reason why Lintian doesn't have such a check is because of
previous rants on debian-devel about how horrible the menu entries are and
how they don't want that stuff in the freedesktop.org menu.

What I think we really need here is some clear proposal that specifies:

* What programs should get a menu entry?
* What categorization of menu entries should be used?
* How do check programs correctly verify the menu files in the package?
* How do systems that don't use freedesktop.org build menus?

If we're going to follow the freedesktop.org standard, that would be
great, but it should be permissible to then mass-file bugs on packages
that provide .desktop files and don't follow the standard (which, I'll
warn, is a lot of them).  Right now, there's quite a lot of mess in the
.desktop files, categories that aren't listed in the standard, and so
forth.

I personally would be quite happy to see elimination of the menu *file
format* in favor of .desktop files on the grounds that the fewer
Debian-specific things we invent, the better.  However, the *capability*
of the menu system for non-freedesktop.org environments needs to be
preserved somehow.  If we can do that by converting freedesktop.org
.desktop files to the existing menu methods, I think that's a fine
solution, but the .desktop files will need to support roughly the same set
of features.

I think this is an entirely doable project, but I also think it's a lot of
work, and a lot of the work is in putting together a clear proposal and
getting consensus.  Right now, my impression is that no one is really
doing that and instead just implementing what they feel looks best in
their environment with the applications that they get bug reports about,
which is resulting in a lot of chaos and inconsistency.

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


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

Re: Upcoming Section changes in the archive

[Darren Salt]

I demand that Frans Pop may or may not have written...

> Joerg Jaspert wrote:
>> We plan on changing the current sections in the archive. With the rapid
>> growth of archive, many of them have become too big to be useful anymore.

> Great.

>> The new sections are:
> [...]
>> localisationsLanguage packs

> I'd prefer "localization".

Whereas I'd prefer "localisation"...

> - We use en_US in general -> "ize"

... unless you're localising for en_US. OTOH, given that that section is for
localisation, "localization" is probably right, being localised...

("-ize" isn't actually wrong here, but it looks too American to us so we use
"-ise" even where it *is* wrong; thus it ends up becoming right.)

[snip]
> What about packages like libcvs-perl or libgit-ruby? Do they stay with the 
> language or move to this new category?

ISTM that they should stay with the language, but I can see why they might be
moved. There's a good argument there for having them belong to two sections,
but that's why debtags exists.

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   http://www.youmustbejoking.demon.co.uk/progs.packages.html>

Resist the insidious influence of the evil American corruption of English!


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

Re: Upcoming Section changes in the archive

[Darren Salt]

I demand that Joerg Jaspert may or may not have written...

[snip]
> The initial set of packages moved into the new sections will be found
> using the following matches:
[snip]
> video
[snip]
> *xine*

Slightly over-broad, unless you want to move library packages too (but I see
that that's mentioned in other follow-ups).

You also want totem* and kaffeine*.

*-dbg packages could go in their own section(s) (debug, or libdebug &
appdebug?); otherwise, I think that they should remain with (the bulk of) the
packages for which they provide debug data.

[snip]
-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Output less CO2 => avoid boiling weather. TIME IS RUNNING OUT *FAST*.

I detect bikeshedding in progress.


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

Re: Upcoming Section changes in the archive

[Aaron M. Ucko]

Daniel Moerner  writes:

> chicken-bin

Ah, yes, I meant to list that but forgot; good catch.

> mzscheme and drscheme are just plt-scheme transitional packages by now

True; in that case, perhaps they should go to oldlibs until they
retire altogether.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu


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

Bug#517346: ITP: openmeeg -- library and tools for solving EEG and MEG forward and inverse problems

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 


* Package name: openmeeg
  Version : 1.0.0
  Upstream Author : OpenMEEG Team 
* URL : http://www-sop.inria.fr/odyssee/software/OpenMEEG/
* License : CeCILL-B
  Programming Lang: C++
  Description : library and tools for solving EEG and MEG forward and 
inverse problems

 Provides state-of-the art tools for processing EEG and MEG data.
 .
 The forward problem is implemented using the symmetric Boundary
 Element method [Kybic et al, 2005], providing excellent accuracy,
 particularly for superficial cortical sources.  The source
 localization procedures implemented in OpenMEEG are based on a
 distributed source model, with three different types of
 regularization: the Minimum Norm, and the L2 and L1
 norms of the surface gradient of the sources [Adde et al, 2005].

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



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

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Sam Hartman]

> "Sam" == Sam Hartman  writes:

Sam> OK, so I think we're all set.  The plan now is to

Sam> 1) Build twice, once into build and once into build-krb4.  We
Sam> only pull libkrb4.so out of build-krb4.  2) 

This works at least.


Sam> 3) Make libkrb53 depend on all the libraries it now contains
Sam> and libkadm55 depend on the libraries it contains.


Sam> 4) Set up symbols and shlibs files to point everyone at
Sam> libkrb53 and libkadm55 as appropriate.


It turns out this fails impressively.  The problem is that the library
packages depend on each other.  So, for example, libk5crypto3 is
needed by libkrb5-3.  If I make the shlibs file for libk5crypto3 point
to libkrb53 instead of libk5crypto3, then libkrb5-3 depends on
libkrb53.  But libkrb53 depends on libkrb5-3 because that is the point
of libkrb53 in the new layout.

I probably could hack something that would work: use symbols files
that point at the split library packages internally and just before
the debs are constructed run a sed script on symbols and shlibs.


However as you'll recall the only reason we didn't point the shlibs at
the new packages initially is to make things easy for unstable
packages that get rebuilt while the new krb5 is waiting to migrate to
testing.

My proposal now is to upload with urgency medium.  There are no code
changes , I have high confidence that I can shake out any packaging
bugs in five days, and that provides a good compromise in my mind at
least between not blocking other people too much and having a simple
enough transition strategy that I can have high confidence I
understand it and that it will work.

If that sounds too problematic then I can investigate the option of
symbols files with alternatives (I.E. libk5crypto3|libkrb53 in the
symbols file.




 and In addition, either versioned replaces
don't work as well for downgrades as unversioned replaces, or replaces
on unpacked but not configured packages don't work as well as replaces
on installed packages.

I'll use unversioned replaces if the user experience is better,
versioned replaces otherwise.  (I had used unversioned replaces in
experimental, but was trying versioned in my current work).



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

Re: Upcoming Section changes in the archive

[Felipe Augusto van de Wiel (faw)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26-02-2009 23:10, Darren Salt wrote:
> I demand that Frans Pop may or may not have written...
>> Joerg Jaspert wrote:
[...]
>>> The new sections are:
>>> localisationsLanguage packs

>> I'd prefer "localization".

> Whereas I'd prefer "localisation"...

What about using 'l10n'?  It tends to be well know these days, and
would avoid the s|z problem. :-)  And considering the goal outlined by Joerg
(not meant for packages like doc-debian-* but for language packs!), using
'language-packs' would probably be fine.


Kind regards,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmnf8AACgkQCjAO0JDlykaBTQCgmbVQYiCDVBAoMaid+lVYeR5D
y0QAn3CjbC/7pX7DVYJkZfsKoANQpu7z
=XsI3
-END PGP SIGNATURE-


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

YouBundle Invitation

[YouBundle]

Hi ,

You have been invited by John penmark (johnpenmark) to join YouBundle. You can 
follow the link below to join - you will automatically join johnpenmark's fan 
list, and you will also become a fan of johnpenmark and be able to follow their 
bundling progress!

Click to register:

http://www.youbundle.com/registration.php?ic=0aeb574475a940cb65510193b94d1e84

Thanks, YouBundle.


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