Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Josselin Mouette]

Le mardi 31 janvier 2012 à 21:51 +0100, Andreas Tille a écrit : 
> I agree that an automatic solution would be prefered.  However, as long
> as such someone does not stand up and write such a program removing
> existing solutions is .

The point is, no one will write such a program until we remove support
for the old system entirely. To break such a chicken/egg circle, we
needed either to write the program ourselves, or to simply drop support
for the obsolete mime system. Guess what: I’m not writing a tool, lest
maintain it, for a technology that I don’t use.

And since, after seven months, nothing happened, it means no one is
interested enough, although some one-liners doing half of the job have
been circulating.

kthxbye,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Andreas Tille]

Hi Josselin,

On Wed, Feb 01, 2012 at 09:29:46AM +0100, Josselin Mouette wrote:
> Le mardi 31 janvier 2012 à 21:51 +0100, Andreas Tille a écrit : 
> > I agree that an automatic solution would be prefered.  However, as long
> > as such someone does not stand up and write such a program removing
> > existing solutions is .
> 
> The point is, no one will write such a program until we remove support
> for the old system entirely.

I confirm that I got your point even if I do not agree.

> To break such a chicken/egg circle, we
> needed either to write the program ourselves, or to simply drop support
> for the obsolete mime system.

Somehow I missed an announcement that mime is obsolete and not supported
in Debian any more.  Did I missed something (URLs)?  I insist in my
opinion that it is not correct to break an old but used (=established)
system intentionally to force others writing workarounds.  (Cyril, it is
not about this specific bug - it is about the general principle.)

> Guess what: I’m not writing a tool, lest
> maintain it, for a technology that I don’t use.

OK, that's fair.
 
> And since, after seven months, nothing happened, it means no one is
> interested enough, although some one-liners doing half of the job have
> been circulating.

Well, from my perspective I was bored the first time when xpdf came up
when I was expecting evince.  After purging xpdf I learned that see does
not find any pdf viewer.  Sorry if I did not realised any discussion
seven monthes ago noch any one-line helpers.

So were can I read about which one-liner should be added to what package
to fix the problem you decided to force upon others. 

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
Archive: http://lists.debian.org/20120201085621.gc32...@an3as.eu

Re: Breaking programs because a not yet implemented solution exists in theory

[Russ Allbery]

Andreas Tille  writes:

> Well, from my perspective I was bored the first time when xpdf came up
> when I was expecting evince.  After purging xpdf I learned that see does
> not find any pdf viewer.  Sorry if I did not realised any discussion
> seven monthes ago noch any one-line helpers.

> So were can I read about which one-liner should be added to what package
> to fix the problem you decided to force upon others. 

So, I don't have a one-line script, but I generally agree with Josselin
that maintaining the same information in two places is a bad idea.  The
basic idea of what needs to be done is to convert the information in the
desktop files into the equivalent of a /usr/lib/mime/packages file.

For example, /usr/share/applications/xpdf.desktop has:

[Desktop Entry]
Name=xpdf
GenericName=PDF viewer
Comment=View PDF files
Exec=xpdf
Icon=xpdf
Terminal=false
Type=Application
MimeType=application/pdf;
Categories=Viewer;Graphics;

/usr/lib/mime/packages/xpdf has:

application/pdf; /usr/bin/xpdf %s; test=test "$DISPLAY" != ""; 
description=Portable Document Format; nametemplate=%s.pdf; priority=6
application/x-pdf; /usr/bin/xpdf %s; test=test "$DISPLAY" != ""; 
description=Portable Document Format; nametemplate=%s.pdf; priority=6

Obviously, the first field comes straight from MimeType (and, in general,
from the list of values in MimeType).  I think one has to make the
assumption that one can add %s after Exec in order to load a file, since
the desktop entry doesn't have an equivalent of the command.  The test is
the same for any application that says Terminal=false.

The description and nametemplate don't come from the same place.  Those
come from /usr/share/mime/application/pdf.xml, and are the same for all
application/pdf entries.

The priority is a more interesting problem.  I'm not sure how the desktop
specification assigns priorities when multiple applications can handle the
same MIME type.

This doesn't look like a trivial tool, but it looks possible to write.
What I'd do is teach update-mime how to handle desktop files as well and
then add a trigger for changes in /usr/share/applications.

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


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

Re: Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez  
> wrote:
> > So I think it's perfectly clear that nor Debian nor Grsecurity are
> > really interested in Debian shipping a Grsecurity kernel.
> 
> Well, I don't think its fair to say "Debian" is not interested in
> shipping a Grsecurity kernel. I think its more accurate to say that the
> current configuration of the Debian kernel team doesn't find the time to
> deal with it... but I'm not sure that speaks for all of Debian.

Well, in this case, that's mostly the same. I'm sure there are people in
Debian which are interested (even outside of me). But here, the kernel
team has the final word (well, or the tech ctte, but I really don't see
the point of that).
> 
[…]

> 
> > Anyway, I'll keep updating the current setup for interested people, but
> > without any interest from either party, that definitely looks like a
> > dead end.
> 
> What is stopping you from creating another package, that provides the
> kernel with grsecurity patches applied? Don't bother the kernel team
> with it, and just maintain it yourself in the archive? Its free software
> afterall. 
> 

Honestly, having multiple linux source package in the archive doesn't
really sound like a good idea. I don't really think the kernel team
would appreciate, I'm pretty sure ftpmasters would disagree, and as a
member of the security team, It's definitely something I would object.

Regards,
-- 
Yves-Alexis


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

Re: Breaking programs because a not yet implemented solution exists in theory

[Josselin Mouette]

Le mercredi 01 février 2012 à 01:14 -0800, Russ Allbery a écrit : 
> The description and nametemplate don't come from the same place.  Those
> come from /usr/share/mime/application/pdf.xml, and are the same for all
> application/pdf entries.

That, and also you have to take into account aliases (different MIME
types characterizing the same file type) and subclasses (for example ODT
is a subclass of ZIP, yet you want to prioritize OOo if it is installed
to open it).

> The priority is a more interesting problem.  I'm not sure how the desktop
> specification assigns priorities when multiple applications can handle the
> same MIME type.

Yes, that’s where things become interesting. The freedesktop
specification handles defaults, instead of priorities. In Debian, we
take advantage of this to provide per-environment defaults. This way,
you can prioritize GNOME applications over KDE ones when running GNOME,
and vice versa. I don’t know if it’s possible to match that with the
mailcap system.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Re: Bug#605090: Linux 3.2 in wheezy

[Wouter Verhelst]

On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > What is stopping you from creating another package, that provides the
> > kernel with grsecurity patches applied? Don't bother the kernel team
> > with it, and just maintain it yourself in the archive? Its free software
> > afterall. 
> > 
> 
> Honestly, having multiple linux source package in the archive doesn't
> really sound like a good idea. I don't really think the kernel team
> would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> member of the security team, It's definitely something I would object.

Well, that's what we have the 'linux-source' packages for: to allow
other packages to build-depend on them.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120201093428.gb31...@grep.be

Re: Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
> On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > > What is stopping you from creating another package, that provides the
> > > kernel with grsecurity patches applied? Don't bother the kernel team
> > > with it, and just maintain it yourself in the archive? Its free software
> > > afterall. 
> > > 
> > 
> > Honestly, having multiple linux source package in the archive doesn't
> > really sound like a good idea. I don't really think the kernel team
> > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> > member of the security team, It's definitely something I would object.
> 
> Well, that's what we have the 'linux-source' packages for: to allow
> other packages to build-depend on them.
> 

Hmhm, that might be a good idea indeed. I need to investigate and try
that a bit.

Ben, what would kernel team think of that?

Regards,
-- 
Yves-Alexis


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

Re: Breaking programs because a not yet implemented solution exists in theory

[Russ Allbery]

Josselin Mouette  writes:
> Le mercredi 01 février 2012 à 01:14 -0800, Russ Allbery a écrit : 

>> The description and nametemplate don't come from the same place.  Those
>> come from /usr/share/mime/application/pdf.xml, and are the same for all
>> application/pdf entries.

> That, and also you have to take into account aliases (different MIME
> types characterizing the same file type) and subclasses (for example ODT
> is a subclass of ZIP, yet you want to prioritize OOo if it is installed
> to open it).

Actually, I don't think you have to take any of that into account when
translating to mailcap, since it doesn't have this concept.  It has a
mapping of MIME types to applications, and that's it.  If you don't have a
mapping for that particular MIME type, the only other option you have is a
wildcard, and only text/* is really meaningful.  So I think you can just
ignore this property; mailcap just doesn't have any way of opening ODT
files with a ZIP viewer when OOo isn't installed.

It's been a long time since I've done mailcap, though.

> Yes, that’s where things become interesting. The freedesktop
> specification handles defaults, instead of priorities. In Debian, we
> take advantage of this to provide per-environment defaults. This way,
> you can prioritize GNOME applications over KDE ones when running GNOME,
> and vice versa. I don’t know if it’s possible to match that with the
> mailcap system.

It isn't.  You get a system list and a user list, and that's all you get.
So there's no way to switch based on other system properties.

Well, you can use test to eliminate an application from consideration
entirely, but I don't think that fits for this.

That probably means that there's just no way to translate priority, and
you're going to have to guess or just take applications at random if
multiple applications with a desktop file manage the same MIME type.  I
suppose you could apply a heuristic like using the application that has
the fewest MIME types it handles; I'm not sure if that's the right
approach.

The main place that mailcap is richer than the desktop file that I can see
is that mailcap allows you to express the exact command line (including
putting %s at different places if needed) and lets you specify different
commands for viewing, editing, and printing.  For example:

message/rfc822; mutt -Rf '%s'; edit=mutt -f '%s'; needsterminal

I don't know if there's any way to do that with desktop files.

Also, I don't think there's a desktop equivalent of copiousoutput.

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


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

Re: Bulding cross-toolchains in the archive

[Marcin Juszkiewicz]

W dniu 31.01.2012 19:28, Wookey pisze:

+++ DrEagle [2012-01-25 14:58 +0100]:



What we need to accomplish is having a package to upload which will
build cross-toolchains. The significant change from buildcross is that
instead of using dpkg-cross to generate a libc6-dev-armel-cross package,
it should just build-depend on libc6-dev:armel
similarly for linux-libc-headers-dev:armel



This could be done as one package which builds binutils-  and
gcc-. In that case you could use the ubuntu package
armel-cross-toolchain-base-  as inspiration, but that can be
significantly simplified as there is no need to do the 3-stage
bootstrap, or build eglibc or linux-headers.


armel-cross-toolchain-base + gcc-4.[456]-armel-cross were made (by me) 
as a way to get automated builds of cross compiler with use of buildd 
machines. Once we will get cross-arch build dependencies I will convert 
them to binutils- + gcc-4.x- which will use 
binutils-source, gcc-4.x-source and libc6-dev: as build 
dependencies.



Or it could be done as a package that builds binutils-, and
another that builds gcc-

This would be proper way. binutils- is easy to do (basically 
armel-cross-toolchain-base limited to $(stamp)/final-binutils step), 
gcc- already exists in Ubuntu as gcc-4.[456]-armel-cross package.



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

essential and transitivly-essential

[Bernhard R. Link]

* Steve Langasek  [120131 20:53]:
> Well, I would argue that packages in the essential set shouldn't be adding
> new dependencies without some discussion and review on debian-devel first.
> That's not technically required by policy, but pulling new packages into the
> transitively-essential package set has the same sort of potentially
> disruptive effect on upgrades that adding pre-depends does.

It's also a pity that it is not that easy to see which packages are in
this set. Given that transitively-essential means:

- the package must be unpackaged manually
- it must work without any preinst or postinst script being run
  (at least good enough for dpkg and all the other essential and
   transitivily essential's packages preinst and postinst).
- it is unpacked twice in a deboostrap (once manually, then with
   dpkg)

Thus it would be nice if that would more explicitly marked and could
also be reduced a bit.

My proposal is still:

- Add a new priority "essential" for the "must always be available"
  (so this is what in a bootstrap is unpackaged manually).
  Require that Priority essential packages only depend on Priority
  essential, so this is the new transitively-essential set.
- Reduce "Essential: yes" with "Priority: required" to mean only
  that cannot be removed easily. So things like mount or initscripts
  must not be unpacked twice and available in every buildd chroot.
- Reduce the set of "does not need depended on" to "Essential: yes"
  and "Priority: essential".

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120201100344.ga2...@server.brlink.eu

Bug#658234: ITP: meterec -- minimalistic multi track recoder

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: meterec
  Version : 0.8
  Upstream Author : Fabric Lebas 
* URL : http://meterec.sourceforge.net/
* License : GPL
  Programming Lang: C
  Description : minimalistic multi track recoder

 meterec works as a basic multi track tape recoder. The aim of meterec
 is to minimise the interactions of the users with the computer and allow
 them to focus on their instrumental performance. For this reason meterec
 features are minimal. One of the main "limitation" is that meterec can
 only restart from time 0:00:00.00: if you srew one take, start it over
 again! rather than learning how to use a specific software to correct
 what you screw, meterec forces to learn and master your instrument.



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

Re: lack of replacement for linux-vserver

[Yves-Alexis Perez]

On mer., 2012-02-01 at 10:33 +0800, Paul Wise wrote:
> On Wed, Feb 1, 2012 at 5:37 AM, Ben Hutchings wrote:
> 
> > Just to be clear, 'that work' is not just a matter of forwarding
> > messages back and forward between the Debian BTS and the Linux-VServer
> > developers.  Unless the VServer project continues to support whichever
> > version we use in a stable release (3.2 in this case) then Debian
> > users are likely to run into different bugs that they won't want to
> > deal with.  There will also be integration issues to be resolved when
> > fixes from the stable/longterm branch conflict with the VServer
> > changes.  This requires real understanding of Linux and VServer
> > internals (see #618485 for an example of what happens without that).
> 
> Data point; there is a VServer patch for 3.2 (marked as experimental though):
> 
> http://vserver.13thfloor.at/Experimental/patch-3.2.2-vs2.3.2.6.diff
> 
> It was also claimed on IRC that when using the Debian template for lxc
> (see below) that the security issues mentioned in the Linux 3.2 thread
> do not apply.
> 
> lxc-create -t debian
> /usr/lib/lxc/templates/lxc-debian

Note that the template “only” drops CAP_MAC_ADMIN, CAP_MAC_OVERRIDE,
CAP_SYS_ADMIN and CAP_SYS_MODULE. Are we really sure this is enough?
http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg00977.html 
thread gives some pointer, but it seems that in the end they advise to drop 
quite some more caps than just those.

Regards,
-- 
Yves-Alexis


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

Re: Bug#658234: ITP: meterec -- minimalistic multi track recoder

[Jonas Smedegaard]

On 12-02-01 at 11:18am, Alessio Treglia wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Alessio Treglia 
> 
> * Package name: meterec
>   Version : 0.8
>   Upstream Author : Fabric Lebas 
> * URL : http://meterec.sourceforge.net/
> * License : GPL
>   Programming Lang: C
>   Description : minimalistic multi track recoder
> 
>  meterec works as a basic multi track tape recoder. The aim of meterec
>  is to minimise the interactions of the users with the computer and allow
>  them to focus on their instrumental performance. For this reason meterec
>  features are minimal. One of the main "limitation" is that meterec can
>  only restart from time 0:00:00.00: if you srew one take, start it over
>  again! rather than learning how to use a specific software to correct
>  what you screw, meterec forces to learn and master your instrument.

recoder → recorder

limitation → limitations

srew → screw

Also, I suspect some (other than me) will feel offended by the use of 
"screw" in a package description, so you might consider replacing with 
"lose" or "fail" or similar.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Bug#658234: ITP: meterec -- minimalistic multi track recoder

[Alessio Treglia]

Fixed in git, thanks!


-- 
Alessio Treglia          | www.alessiotreglia.com
Debian Developer         | ales...@debian.org
Ubuntu Core Developer    | quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


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

Re: essential and transitivly-essential

[Colin Watson]

On Wed, Feb 01, 2012 at 11:03:44AM +0100, Bernhard R. Link wrote:
> It's also a pity that it is not that easy to see which packages are in
> this set. Given that transitively-essential means:
> 
> - the package must be unpackaged manually
> - it must work without any preinst or postinst script being run
>   (at least good enough for dpkg and all the other essential and
>transitivily essential's packages preinst and postinst).

Only their preinsts; dependencies will still be configured in time for
postinsts, as long as they aren't circular.

> - Add a new priority "essential" for the "must always be available"
>   (so this is what in a bootstrap is unpackaged manually).
>   Require that Priority essential packages only depend on Priority
>   essential, so this is the new transitively-essential set.
> - Reduce "Essential: yes" with "Priority: required" to mean only
>   that cannot be removed easily. So things like mount or initscripts
>   must not be unpacked twice and available in every buildd chroot.

I'm afraid weakening the constraints on "Priority: required" packages
would break debootstrap's --foreign/--second-stage system.  For that to
work (at least without emulation), 'debootstrap --foreign' needs to be
able to unpack enough packages that you can actually boot the target
system and run '/debootstrap/debootstrap --second-stage'.  In practice
this means "Priority: required", and so, in order to support this,
packages like mount and initscripts need to be able to cope with the
model where they're unpacked before any packages are configured anyway.
Given that, it doesn't really hurt us to do single-architecture
bootstraps that way as well.  I appreciate that this might be a harder
sell if it didn't already work, but given that it does, we'd need a
pretty strong reason to break it.

In any case, I don't know that this would justify the time spent on it.
It's true that it would eliminate the occasional bug, but in practice
things that are "Priority: required" do tend to act pretty carefully; I
think I can recall one case ever where I encountered a package that
failed to cope with debootstrap's unpack régime, and IIRC it was
something that was being pulled in via --include rather than actually
something in required.  It's not that such things don't merit review -
they do, and I agree with Steve that some discussion is worthwhile - but
I don't think there's a lot to be gained by redefining things so that we
can reduce the current set, given that it wouldn't actually reduce the
size of debootstrap's output on user systems.  Do you have a specific
case where this would have made a difference?

I also think that the jargon term "essential" is often misunderstood as
it is, and changing the system to apply it to two things rather than one
would confuse the situation further; not to mention that Priority has to
be manually maintained by ftpmaster, while the transitively-essential
set is subject to change (debootstrap actually only takes "Priority:
required" as a starting point, even though it's usually accurate).

If we were going to do something like this for single-architecture
bootstraps, I'd prefer to do it by changing debootstrap to resolve the
transitively-essential set by itself; that is, take all "Essential: yes"
packages and expand their dependencies, and treat that set the way we
currently treat "Priority: required".  Then required and important would
still have their distinct semantics in policy, but debootstrap could
install them in one go in what's currently its second stage (or just
required + apt with --variant=minbase, or whatever, or something even
smaller with --variant=buildd, or whatever).  You could experiment with
that kind of thing without having to change the archive structure at
all.  However, you'd still have to remember to take the
foreign-bootstrap case into account.

Finally, I think it would be a good idea to document the special
restrictions on "Priority: required" packages in policy.  I don't think
it currently specifies these accurately, so they're largely encoded in
the heads of the small number of people who've had to deal with this.

> - Reduce the set of "does not need depended on" to "Essential: yes"
>   and "Priority: essential".

"Does not need to be depended on" is already only "Essential: yes", even
if buildds don't always catch every violation of this.  procps is the
usual case I see people forgetting about.

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


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

Re: lack of replacement for linux-vserver

[Bernd Zeimetz]

On 01/31/2012 10:37 PM, Ben Hutchings wrote:
[...]
> If anyone wishes to volunteer to maintain VServer in Debian - you are
> very welcome, but please start by addressing the bugs filed against
> them in squeeze and reviewing the existing conflicts.  If you can
> prove yourself by doing that, then you may convince me and the rest of
> the kernel team that you can maintain it in wheezy as well.
> Otherwise, no chance.
> 
> The above all applies to OpenVZ as well, and what I've suggested to is
> that the interested developers maintain an APT repository of kernel
> packages for Debian using whichever version the OpenVZ project is
> prepared to support.  Maybe the Linux-VServer project can do that too.

I've tried to convince the linux-vserver developers on various ocassions
on irc to work together with a person of their choice from Debian to
maintain the patch for stable releases. But they are not willing to
support Debian as they neither use Debian nor have any interest in
supporting the Debian kernel.

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


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

Bug#658253: ITP: pylast -- Python interface to Last.fm and other compatible services

[Simon Chopin]

Package: wnpp
Severity: wishlist
Owner: Simon Chopin 

* Package name: pylast
  Version : 0.5.11
  Upstream Author : Amr Hassan 
* URL : http://code.google.com/p/pylast/
* License : Apache-2.0
  Programming Lang: Python
  Description : Python interface to Last.fm and other compatible services

Last.fm is a service providing a way to keep a record of what the users listen
to and offering music recommendations based on that record.

This interface allows access to all the data exposed by the Last.fm API as
well as to the scrobbling functionality.

This module is the main dependency of the beets plugin "lastgenre",
which is already shipped within the Debian package.

I intend to maintain this package under the umbrella of the Debian
Python Module Team.

Cheers,

Simon



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

Re: essential and transitivly-essential

[Bernhard R. Link]

* Colin Watson  [120201 12:32]:
> On Wed, Feb 01, 2012 at 11:03:44AM +0100, Bernhard R. Link wrote:
> > It's also a pity that it is not that easy to see which packages are in
> > this set. Given that transitively-essential means:
> >
> > - the package must be unpackaged manually
> > - it must work without any preinst or postinst script being run
> >   (at least good enough for dpkg and all the other essential and
> >transitivily essential's packages preinst and postinst).
>
> Only their preinsts; dependencies will still be configured in time for
> postinsts, as long as they aren't circular.

Only direct dependencies. If some package does not Depend on an
essential package (as it is supposed to not do) the the package's
postinst can be run before the dependencies of that other essential
package's postinst is run. Any functionality of the essential
package provided by it's dependency must thus already be available
AFAIUI.

> > - Add a new priority "essential" for the "must always be available"
> >   (so this is what in a bootstrap is unpackaged manually).
> >   Require that Priority essential packages only depend on Priority
> >   essential, so this is the new transitively-essential set.
> > - Reduce "Essential: yes" with "Priority: required" to mean only
> >   that cannot be removed easily. So things like mount or initscripts
> >   must not be unpacked twice and available in every buildd chroot.
>
> I'm afraid weakening the constraints on "Priority: required" packages
> would break debootstrap's --foreign/--second-stage system.  For that to
> work (at least without emulation), 'debootstrap --foreign' needs to be
> able to unpack enough packages that you can actually boot the target
> system and run '/debootstrap/debootstrap --second-stage'.

Does debootstrap's first stage ever ends in an actually bootable
system? (after all, at least boot loaders are definitely missing,
initrds are missing, ...).

The only way I know this running is with chrooting in the
prepared directory from some other Linux system or a rescue
system. And in that case most of this should just work the
same (some packaged would be unpacked the first time and not
the second, but...).
The only thing I see with a quick glance is mounting
/proc. But that could equally well done from outside.

> In any case, I don't know that this would justify the time spent on it.
> It's true that it would eliminate the occasional bug, but in practice
> things that are "Priority: required" do tend to act pretty carefully; I
> think I can recall one case ever where I encountered a package that
> failed to cope with debootstrap's unpack régime

Additionally such bugs are hard to find as having only debootstrap
and cdebootstrap may do stuff in the same order most of the time thus
hiding it.

> but
> I don't think there's a lot to be gained by redefining things so that we
> can reduce the current set, given that it wouldn't actually reduce the
> size of debootstrap's output on user systems.  Do you have a specific
> case where this would have made a difference?

The case I'm stumbling over this regulary is small buildd chroots.
With some older hardware maintaining chroots can be quite daunting.
Reducing the set of packages needed in one can easily be the
difference between a viable and a unusable solution.

(I've also experimented with locally testing builds on other
architectures by some minimal qemu tricks and usually this bloat
the the induced brittleness of bootstrap phase stopped me).

> I also think that the jargon term "essential" is often misunderstood as
> it is, and changing the system to apply it to two things rather than one
> would confuse the situation further;

That's an valid point. But that is only about the naming.

> not to mention that Priority has to
> be manually maintained by ftpmaster, while the transitively-essential
> set is subject to change (debootstrap actually only takes "Priority:
> required" as a starting point, even though it's usually accurate).

That together with some check to reject packages in that set depending
on packages not yet in that check would give a good way to review
such changes, though, and avoid anything happening in that regard
by mistake.

> If we were going to do something like this for single-architecture
> bootstraps, I'd prefer to do it by changing debootstrap to resolve the
> transitively-essential set by itself; that is, take all "Essential: yes"
> packages and expand their dependencies, and treat that set the way we
> currently treat "Priority: required".

My point also is that Essential currently means two things:
"Needed so that other packages can be installed" and
"should not be easily removed by the user".

Thus I'd like to see Essential split in a part to be in every
chroot and taking special treatment and a set of packages not
to be removed easily but still possible to remove where not
needed (like mount, initscripts, ...).

> > - Reduce the set of "does not need depended on" to "Essential: ye

Re: Bug#605090: Linux 3.2 in wheezy

[Ben Hutchings]

On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
> On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
> > On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> > > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > > > What is stopping you from creating another package, that provides the
> > > > kernel with grsecurity patches applied? Don't bother the kernel team
> > > > with it, and just maintain it yourself in the archive? Its free software
> > > > afterall. 
> > > > 
> > > 
> > > Honestly, having multiple linux source package in the archive doesn't
> > > really sound like a good idea. I don't really think the kernel team
> > > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> > > member of the security team, It's definitely something I would object.
> > 
> > Well, that's what we have the 'linux-source' packages for: to allow
> > other packages to build-depend on them.
> > 
> 
> Hmhm, that might be a good idea indeed. I need to investigate and try
> that a bit.
> 
> Ben, what would kernel team think of that?

I don't speak for the whole team, but I don't see that it solves any
problem.  You would have to Build-Depend on exact versions of
linux-source, so that you know your external patches will apply.  Then
you would have to rebase the patches every time linux-2.6 is updated,
making sure (without much help from upstream) that you don't introduce a
subtle security problem.

Ben.

-- 
Ben Hutchings
Lowery's Law:
 If it jams, force it. If it breaks, it needed replacing anyway.


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

Re: Breaking programs because a not yet implemented solution exists in theory

[Andreas Tille]

Hi,

On Wed, Feb 01, 2012 at 01:51:17AM -0800, Russ Allbery wrote:
> Josselin Mouette  writes:
> ...

I confirm that I agree that we should prevent duplication of data which
was stated in previous mails.
 
> The main place that mailcap is richer than the desktop file that I can see
> is that mailcap allows you to express the exact command line (including
> putting %s at different places if needed) and lets you specify different
> commands for viewing, editing, and printing.  For example:
> 
> message/rfc822; mutt -Rf '%s'; edit=mutt -f '%s'; needsterminal
> 
> I don't know if there's any way to do that with desktop files.
> 
> Also, I don't think there's a desktop equivalent of copiousoutput.

Assuming that Russ did not overlooked something this means that mailcap
entries can not generatet from desktop files.  So the one-liners
mentioned by Josselin which might solve 50% of the task could not easily
enhanced to two-liners doing 100% which do all the work.  In other words
we dropped support for a technique that is used by several programs and
it seems a replacement is either hard to do or not possible at all.

I personally would cope with this by installing a local package carrying
the mailcap entries I need.  However that can hardly be a solution for
our users.  As a general solution I would see two ways:

  1. Stop droping *.mime files from packages and reinjecting them.
  2. Create a general mailcap entry collection package which works
 around maintainers unwilling to support mailcap.

I'd prefer 1. because I see no point in just droping what worked in the
past and has no visible chance to break something heavily.  Please
correct me if I'm wrong.

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
Archive: http://lists.debian.org/20120201150318.ga10...@an3as.eu

Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status

[Charles Plessy]

Le Fri, Jan 20, 2012 at 09:12:16AM +, Lars Wirzenius a écrit :
> 
> You're not the DEP5 driver

Hi Lars and everybody,

I am driving this DEP and re-listed myself at a driver to mark that fact.

To summarise:

 - The original idea, from Sam Hocevar, was posted on this list on August 4,
   2007.

 - A draft was written collaboratively on the wiki until March 2009, in
   which I had my share of contributions.

 - I do not remember who was the first to suggest to make a DEP out of it, but
   please note revision 294: I am the one to propose it in the wiki page.

 - The DEP was started in private, motivated in part by Ubuntu's agenda.  It
   was a terrible mistake for me to accept this, as it resulting in purging
   and demotivating most of the original contributors.  Nevertheless, I did
   a large—or perhaps the largest—share of that work in that phase.

 - The DEP continued in public, and the only moment where I gave up driving
   this project was when you stepped in.  It made tremendous progresses under
   your direction; unfortunately you stepped down in the last mile.  I dare 
saying
   that I contributed a lot.  Among other things did the conversion to DocBook
   which has let the DEP enter in the debian-policy package, and made sure that
   the DEP's license short names are compatible with SPDX.

 - In a further phase, I organised the work through the BTS.  Consensus
   was reached and the DEP was updated accordingly.  I also coordinated
   the publication of the DEP on www.debian.org.  At the next upload
   of the debian-policy package, the DEP will be on line at its canonical
   URL:  http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

 - In this final phase, I am making sure that there is no objection anymore to
   the release.  And I will not let the momentum slip for one more year.

More importantly than the procedural details: I have followed the work
from its beginning, made sure that no contribution was ignored, and that
most questions were answered.  To the best of my free time, I made sure
that past discussions were not forgotten and taken into account when
the same questions were asked over and over the years.

This is what I expect from a driver: being the memory of the project, keeping
momentum, and making consensus on the final document.  I am driving this DEP.
One can argue forever on this, but please let me suggest that the best way
to close the debate is to finish that work.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Breaking programs because a not yet implemented solution exists in theory

[Michael Biebl]

On 01.02.2012 16:03, Andreas Tille wrote:
> Hi,
> 
> On Wed, Feb 01, 2012 at 01:51:17AM -0800, Russ Allbery wrote:

>> The main place that mailcap is richer than the desktop file that I can see
>> is that mailcap allows you to express the exact command line (including
>> putting %s at different places if needed) and lets you specify different
>> commands for viewing, editing, and printing.  For example:
>>
>> message/rfc822; mutt -Rf '%s'; edit=mutt -f '%s'; needsterminal
>>
>> I don't know if there's any way to do that with desktop files.
>>
>> Also, I don't think there's a desktop equivalent of copiousoutput.
> 
> Assuming that Russ did not overlooked something this means that mailcap
> entries can not generatet from desktop files.  So the one-liners
> mentioned by Josselin which might solve 50% of the task could not easily
> enhanced to two-liners doing 100% which do all the work.  In other words
> we dropped support for a technique that is used by several programs and
> it seems a replacement is either hard to do or not possible at all.

Tools like mutt, which need the extended mailcap syntax, can certainly
continue to ship a mime file.

If a package ships both a desktop and a mime file, the conversion-tool
could simply skip the automatic generation of the mailcap entries under
the assumption that the manually written ones take precedence.


Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

DEP-5 and files with white spaces

[Benjamin Drung]

Hi,

DEP-5 is nice, but how can I specify a license for a file with white
spaces? For example you want to specify that the file "foo/file one.bar"
is licensed under ISC, but "foo/file_one.bar" is licensed under GPL. How
can you do that?

I would like to write following:

File: "foo/file one.bar"
License: ISC

File: foo/file_one.bar
License: GPL

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On mer., 2012-02-01 at 14:32 +, Ben Hutchings wrote:
> On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
> > On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
> > > On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> > > > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > > > > What is stopping you from creating another package, that provides the
> > > > > kernel with grsecurity patches applied? Don't bother the kernel team
> > > > > with it, and just maintain it yourself in the archive? Its free 
> > > > > software
> > > > > afterall. 
> > > > > 
> > > > 
> > > > Honestly, having multiple linux source package in the archive doesn't
> > > > really sound like a good idea. I don't really think the kernel team
> > > > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> > > > member of the security team, It's definitely something I would object.
> > > 
> > > Well, that's what we have the 'linux-source' packages for: to allow
> > > other packages to build-depend on them.
> > > 
> > 
> > Hmhm, that might be a good idea indeed. I need to investigate and try
> > that a bit.
> > 
> > Ben, what would kernel team think of that?
> 
> I don't speak for the whole team, but I don't see that it solves any
> problem.  You would have to Build-Depend on exact versions of
> linux-source, so that you know your external patches will apply.  Then
> you would have to rebase the patches every time linux-2.6 is updated,
> making sure (without much help from upstream) that you don't introduce a
> subtle security problem.
> 
Well, that's already what I do and intended to do (and that's clear from
the beginning of the bug report).

Wrt not introducing subtle security problems, what I mostly do is remove
the security backports from the grsec patch which are already applied to
Debian kernel, so this part is fairly straightforward.

Now indeed when doing the job for Squeeze kernel it's a bit less
straightforward because of the huge amount of driver backports, but from
my own experience, the conflicts are still mostly about changed context
lines.

Regards,
-- 
Yves-Alexis


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

Re: Bug#605090: Linux 3.2 in wheezy

[Ben Hutchings]

On Wed, Feb 01, 2012 at 06:41:43PM +0100, Yves-Alexis Perez wrote:
> On mer., 2012-02-01 at 14:32 +, Ben Hutchings wrote:
> > On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
> > > On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
> > > > On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> > > > > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > > > > > What is stopping you from creating another package, that provides 
> > > > > > the
> > > > > > kernel with grsecurity patches applied? Don't bother the kernel team
> > > > > > with it, and just maintain it yourself in the archive? Its free 
> > > > > > software
> > > > > > afterall. 
> > > > > > 
> > > > > 
> > > > > Honestly, having multiple linux source package in the archive doesn't
> > > > > really sound like a good idea. I don't really think the kernel team
> > > > > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> > > > > member of the security team, It's definitely something I would object.
> > > > 
> > > > Well, that's what we have the 'linux-source' packages for: to allow
> > > > other packages to build-depend on them.
> > > > 
> > > 
> > > Hmhm, that might be a good idea indeed. I need to investigate and try
> > > that a bit.
> > > 
> > > Ben, what would kernel team think of that?
> > 
> > I don't speak for the whole team, but I don't see that it solves any
> > problem.  You would have to Build-Depend on exact versions of
> > linux-source, so that you know your external patches will apply.  Then
> > you would have to rebase the patches every time linux-2.6 is updated,
> > making sure (without much help from upstream) that you don't introduce a
> > subtle security problem.
> > 
> Well, that's already what I do and intended to do (and that's clear from
> the beginning of the bug report).
> 
> Wrt not introducing subtle security problems, what I mostly do is remove
> the security backports from the grsec patch which are already applied to
> Debian kernel, so this part is fairly straightforward.
> 
> Now indeed when doing the job for Squeeze kernel it's a bit less
> straightforward because of the huge amount of driver backports, but from
> my own experience, the conflicts are still mostly about changed context
> lines.

But your upstream disagrees on that point.

Ben.

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


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

Re: Bug#605090: Linux 3.2 in wheezy

[dann frazier]

On Wed, Feb 01, 2012 at 02:32:19PM +, Ben Hutchings wrote:
> On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
> > On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
> > > On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> > > > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > > > > What is stopping you from creating another package, that provides the
> > > > > kernel with grsecurity patches applied? Don't bother the kernel team
> > > > > with it, and just maintain it yourself in the archive? Its free 
> > > > > software
> > > > > afterall. 
> > > > > 
> > > > 
> > > > Honestly, having multiple linux source package in the archive doesn't
> > > > really sound like a good idea. I don't really think the kernel team
> > > > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> > > > member of the security team, It's definitely something I would object.
> > > 
> > > Well, that's what we have the 'linux-source' packages for: to allow
> > > other packages to build-depend on them.
> > > 
> > 
> > Hmhm, that might be a good idea indeed. I need to investigate and try
> > that a bit.
> > 
> > Ben, what would kernel team think of that?
> 
> I don't speak for the whole team,

and nor do I..

> but I don't see that it solves any
> problem.  You would have to Build-Depend on exact versions of
> linux-source, so that you know your external patches will apply.  Then
> you would have to rebase the patches every time linux-2.6 is updated,
> making sure (without much help from upstream) that you don't introduce a
> subtle security problem.

Whilte it may help the kernel team to not have to worry about problems
in the grsec flavor when preparing uploads, preventing delays for the
non-grsec images. But, that just pushes the coordination down a ways -
for stable updates we would need to add the grsec build into the
pipeline, and there'd be delays in grsec security updates that go in
via linux-2.6. Not nak'ing the idea, but it does extend some critical
paths.


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

Re: Linux 3.2 in wheezy

[Moritz Naumann]

So there are obvious issues with LXC as a container solution for Linux, such as
lacking actual containment (for the root user), which defeat sits purpose in
production environments as a linux-vserver or OpenVZ replacement. 

However, a low profile container/virtualization solution is needed, and I know
there is quite some demand for it: both some larger scale organisations and
several smaller/non-profit organisations I am acquainted with use either OpenVZ
or linux-vserver and some of them will be in trouble if there is no equivalent
and not at least a rough migration path. 

I can very much understand the kernel maintainers' wish to get rid of apparent
legacy patchsets, and (from this perspective) it is somewhat frustrating that
linux-vserver / openvz never made it into Linux proper. Surely lxc seemed like a
more suitable design for 3.0+, but where it stands now is not different enough
to where it stood some years ago to make it a usable replacement now, or to
allow for high hopes that it will be a good vserver replacement when wheezy
turns stable.

Right now, (not just) my hopes are that linux-vserver + openvz (or at least one
of them) will continue to be available in wheezy for as long as no other
comparable options are available. And that more comparable options with a modern
design AND sufficient feature set will become available.

Moritz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20120201t201629-...@post.gmane.org

Bug#658287: ITP: pbs -- Python subprocess wrapper

[Luca Falavigna]

Package: wnpp
Severity: wishlist
Owner: Luca Falavigna 

* Package name: pbs
  Version : 0.7
  Upstream Author : Andrew Moffat
* URL : https://github.com/amoffat/pbs
* License : MIT
  Programming Lang: Python
  Description : Python subprocess wrapper

PBS is a unique subprocess wrapper that maps your system programs to Python
functions dynamically. PBS helps you write shell scripts in Python by giving
you the good features of Bash (easy command calling, easy piping) with all the
power and flexibility of Python.



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

Bug#658292: general: can't configure Xorg in a new wheezy instalation

[xavi]

Package: general
Severity: important

Dear Maintainer,
What led up to the situation?
New instalation, I enter in Gnome3 and don't show correctly the desktop (can't 
read text nor icons)

What exactly did you do (or not do) that was effective (or ineffective)?
I tried to find xorg.config but don't exist.
I tried (from tty2) 'gdm3 stop' and 'Xorg -configure', but can't configure. 

What was the outcome of this action?
can't configure

What outcome did you expect instead?
a new xorg.config file



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.1.0-1-486
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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

Bug#658292: more info

[Xavier Paniello]

trynewconfiguration are the messages in terminal
Xorg.0.log is the log of 'Xorg -configure'

trynewconfiguration
Description: Binary data
[  3394.918] 
X.Org X Server 1.11.3.901 (1.11.4 RC 1)
Release Date: 2012-01-06
[  3394.918] X Protocol Version 11, Revision 0
[  3394.918] Build Operating System: Linux 2.6.32-5-amd64 i686 Debian
[  3394.918] Current Operating System: Linux wheezy 3.1.0-1-486 #1 Tue Jan 10 04:55:10 UTC 2012 i686
[  3394.918] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.1.0-1-486 root=UUID=30dee264-fd0e-4a11-81e5-12d5f9ed263b ro quiet
[  3394.918] Build Date: 19 January 2012  10:32:06AM
[  3394.918] xorg-server 2:1.11.3.901-2 (Cyril Brulebois ) 
[  3394.918] Current version of pixman: 0.24.2
[  3394.918] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[  3394.918] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  3394.919] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Feb  1 22:33:37 2012
[  3394.919] (II) Loader magic: 0xb77b6580
[  3394.919] (II) Module ABI versions:
[  3394.919] 	X.Org ANSI C Emulation: 0.4
[  3394.919] 	X.Org Video Driver: 11.0
[  3394.919] 	X.Org XInput driver : 13.0
[  3394.919] 	X.Org Server Extension : 6.0
[  3394.921] (--) PCI: (0:0:9:0) 109e:036e:1851:1850 rev 17, Mem @ 0xd700/4096
[  3394.921] (--) PCI:*(0:1:0:0) 10de:0322:1682:1280 rev 161, Mem @ 0xd500/16777216, 0xd800/134217728, BIOS @ 0x/131072
[  3394.922] List of video drivers:
[  3394.922] 	voodoo
[  3394.922] 	chips
[  3394.922] 	openchrome
[  3394.922] 	ztv
[  3394.922] 	ati
[  3394.922] 	ark
[  3394.922] 	i128
[  3394.922] 	savage
[  3394.922] 	s3
[  3394.922] 	intel
[  3394.922] 	r128
[  3394.923] 	vmwlegacy
[  3394.923] 	s3virge
[  3394.923] 	trident
[  3394.923] 	nouveau
[  3394.923] 	sisusb
[  3394.923] 	tdfx
[  3394.923] 	rendition
[  3394.923] 	mach64
[  3394.923] 	siliconmotion
[  3394.923] 	apm
[  3394.923] 	mga
[  3394.923] 	vmware
[  3394.923] 	tseng
[  3394.923] 	neomagic
[  3394.923] 	sis
[  3394.923] 	geode
[  3394.923] 	radeon
[  3394.923] 	i740
[  3394.923] 	cirrus
[  3394.923] 	fbdev
[  3394.923] 	vesa
[  3394.923] (II) LoadModule: "voodoo"
[  3394.924] (II) Loading /usr/lib/xorg/modules/drivers/voodoo_drv.so
[  3394.924] (II) Module voodoo: vendor="X.Org Foundation"
[  3394.924] 	compiled for 1.11.0, module version = 1.1.0
[  3394.924] 	Module class: X.Org Video Driver
[  3394.924] 	ABI class: X.Org Video Driver, version 11.0
[  3394.924] (II) LoadModule: "chips"
[  3394.925] (II) Loading /usr/lib/xorg/modules/drivers/chips_drv.so
[  3394.925] (II) Module chips: vendor="X.Org Foundation"
[  3394.925] 	compiled for 1.11.0, module version = 1.2.4
[  3394.925] 	Module class: X.Org Video Driver
[  3394.925] 	ABI class: X.Org Video Driver, version 11.0
[  3394.925] (II) LoadModule: "openchrome"
[  3394.925] (II) Loading /usr/lib/xorg/modules/drivers/openchrome_drv.so
[  3394.926] (II) Module openchrome: vendor="http://openchrome.org/";
[  3394.926] 	compiled for 1.11.0, module version = 0.2.904
[  3394.926] 	Module class: X.Org Video Driver
[  3394.926] 	ABI class: X.Org Video Driver, version 11.0
[  3394.926] (II) LoadModule: "ztv"
[  3394.927] (II) Loading /usr/lib/xorg/modules/drivers/ztv_drv.so
[  3394.927] (II) Module ztv: vendor="X.Org Foundation"
[  3394.927] 	compiled for 1.11.2.902, module version = 0.0.1
[  3394.927] 	ABI class: X.Org Video Driver, version 11.0
[  3394.927] (II) LoadModule: "ati"
[  3394.927] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[  3394.927] (II) Module ati: vendor="X.Org Foundation"
[  3394.927] 	compiled for 1.11.2.902, module version = 6.14.3
[  3394.928] 	Module class: X.Org Video Driver
[  3394.928] 	ABI class: X.Org Video Driver, version 11.0
[  3394.928] (II) LoadModule: "ark"
[  3394.928] (II) Loading /usr/lib/xorg/modules/drivers/ark_drv.so
[  3394.928] (II) Module ark: vendor="X.Org Foundation"
[  3394.928] 	compiled for 1.11.0, module version = 0.7.3
[  3394.928] 	Module class: X.Org Video Driver
[  3394.928] 	ABI class: X.Org Video Driver, version 11.0
[  3394.928] (II) LoadModule: "i128"
[  3394.929] (II) Loading /usr/lib/xorg/modules/drivers/i128_drv.so
[  3394.929] (II) Module i128: vendor="X.Org Foundation"
[  3394.929] 	compiled for 1.11.0, module version = 1.3.4
[  3394.929] 	Module class: X.Org Video Driver
[  3394.929] 	ABI class: X.Org Video Driver, version 11.0
[  3394.929] (II) LoadModule: "savage"
[  3394.930] (II) Loading /usr/lib/xorg/modules/drivers/savage_drv.so
[  3394.930] (II) Module savage: vendor="X.Org Foundation"
[  3394.930] 	compiled for 1.11.1.901, module version = 2.3.3
[  3394.930] 	Module class: X.Org Video Driver
[  3394.930] 	ABI class: X.Org Video Driver, version 11.0
[  3394.930] (II) LoadModule: "s3"
[  3394.931] (II) Loading /usr/lib/xorg/modules/drivers/s3_drv.so
[  3394.931] (II) Modu

Bug#658292: marked as done (general: can't configure Xorg in a new wheezy instalation)

[Debian Bug Tracking System]

Your message dated Wed, 1 Feb 2012 16:04:50 -0600
with message-id <20120201220449.GA29599@burratino>
and subject line Re: general: can't configure Xorg in a new wheezy instalation
has caused the Debian Bug report #658292,
regarding general: can't configure Xorg in a new wheezy instalation
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.)


-- 
658292: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658292
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: important

Dear Maintainer,
What led up to the situation?
New instalation, I enter in Gnome3 and don't show correctly the desktop (can't 
read text nor icons)

What exactly did you do (or not do) that was effective (or ineffective)?
I tried to find xorg.config but don't exist.
I tried (from tty2) 'gdm3 stop' and 'Xorg -configure', but can't configure. 

What was the outcome of this action?
can't configure

What outcome did you expect instead?
a new xorg.config file



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.1.0-1-486
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

xavi wrote:

> New instalation, I enter in Gnome3 and don't show correctly the
> desktop (can't read text nor icons)

This report does not seem to describe a widespread problem affecting
many packages in the archive, so "general" was not the right package
for it.  When there is no clear choice for what package to file a bug
against, good answers can be:

 - installation-reports, if this is a report of a new install failing
 - upgrade-reports, if the bug arose due to an upgrade
 - whatever the kind people on debian-u...@lists.debian.org say

No big deal.  I'm closing this report because there is not enough
information for a person to act on.

I would suggest booting with the "text" kernel parameter[1], which
will prevent gdm3 from starting, and trying to start X by running
"startx" from the command line.  The xinit package needs to be
installed for this to work.  If it works, please file a report against
gnome with

reportbug gnome

If it doesn't, please file a report against X with

reportbug xorg

which should automatically attach some relevant info.

Sorry for the trouble and hope that helps,
Jonathan

[1] In the grub2 menu at boot time, press "e" to see details about the
boot process.  Move to the line starting with "linux" and containing
"quiet", and add "text" as a new word at the end of the line.  Then
boot by pressing ctrl+x.

--- End Message ---

Re: Breaking programs because a not yet implemented solution exists in theory

[Russ Allbery]

Michael Biebl  writes:
> On 01.02.2012 16:03, Andreas Tille wrote:

>> Assuming that Russ did not overlooked something this means that mailcap
>> entries can not generatet from desktop files.  So the one-liners
>> mentioned by Josselin which might solve 50% of the task could not
>> easily enhanced to two-liners doing 100% which do all the work.  In
>> other words we dropped support for a technique that is used by several
>> programs and it seems a replacement is either hard to do or not
>> possible at all.

> Tools like mutt, which need the extended mailcap syntax, can certainly
> continue to ship a mime file.

> If a package ships both a desktop and a mime file, the conversion-tool
> could simply skip the automatic generation of the mailcap entries under
> the assumption that the manually written ones take precedence.

Yeah, that's basically the sort of design that I was thinking of.

The programs on my system that use the extended mailcap syntax are all
ones that aren't very invested in using *.desktop files right now anyway.
Things like copiousoutput are useful for commands that don't really fall
into the core area intended to be addressed by *.desktop.

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


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

Re: DEP-5 and files with white spaces

[Russ Allbery]

Benjamin Drung  writes:

> DEP-5 is nice, but how can I specify a license for a file with white
> spaces? For example you want to specify that the file "foo/file one.bar"
> is licensed under ISC, but "foo/file_one.bar" is licensed under GPL. How
> can you do that?

No, that distinction isn't representable.  There was some earlier
discussion about that, and the conclusion reached was that it was a rare
case that wasn't worth making the syntax more complicated (after various
more complicated syntaxes were tossed around without making anyone very
happy).

The general way to specify information for a file name that contains
whitespace is to use wildcards to match the whitespace, which means that
you can't disambiguate from other files that only differ in the places
where whitespace is present.

Out of curiosity, have you run across a case where this matters, or were
you asking because it's a theoretical hole?  It's definitely a theoretical
hole, but one of the reasons why we didn't spend more time on it was that
everyone was dubious that the case would arise in a real-world situation.

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


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

Bug#658300: ITP: libdigidoc -- C++ library for processing DDOC digital signatures (deprecated)

[Guido Tabbernuk]

Package: wnpp
Severity: wishlist
Owner: Guido Tabbernuk 


* Package name: libdigidoc
  Version : 2.7.0
  Upstream Author : Kalev Lember  & others
* URL : http://code.google.com/p/esteid/
* License : LGPL 2.1
  Programming Lang: C++
  Description : C++ library for processing DDOC digital signatures 
(deprecated)

libDigiDoc is a library implementing a subset of the XAdES digital
signature standard on top of an Estonian-specific DDOC container format.
It allows one to create, sign, verify and modify DigiDoc XML containers.
.
This library was initially developed more than 10 years ago, back
when there was no adequate standard XML library to implement these
features. Nowadays, it only remains in use by libdigidocpp to provide a 
bug-for-bug backward-compatibility with older DigiDoc software that is
widely deployed and essential for accessing public services in Estonia.
.
For any other purpose, this library shall be considered as deprecated
and is best avoided whenever developing new DigiDoc software.
.
This package provides the shared libraries.

*

This package is one of 6 packages created by the Estonian government 
to support national ID cards on Free Software operating systems.

This particular package is one of the core libraries used to access
and manipulate the data on the ID cards.

The whole suite is comprised of the following source packages:

smartcardpp
libdigidoc
libdigidocpp
qesteidutil
qdigidoc
esteid-browser-plugin



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

Bug#658302: ITP: libdigidocpp -- C++ library for processing BDOC digital signatures

[Guido Tabbernuk]

Package: wnpp
Severity: wishlist
Owner: Guido Tabbernuk 


* Package name: libdigidocpp
  Version : 0.3.0
  Upstream Author : Kalev Lember  & others
* URL : http://code.google.com/p/esteid/
* License : LGPL 2.1
  Programming Lang: C++
  Description : C++ library for processing BDOC digital signatures

BDoc C++ lib is library for creating and validating BDOC-1.0 documents.
Older Digidoc formats (DIGIDOC-XML) are not supported. Difference between
DDoc, EDoc and BDoc are described in. BDoc signatures should be XAdES
compliant, but some XAdES signatures may be uncompliant with BDoc. Currently
BDoc-1.0 BES and TM profiles are supported.
.
Signatures can be given using EstEID Card (id-kaart) and RSA certificates
with private keys.
.
This package provides the runtime libraries.

*

This package is one of 6 packages created by the Estonian government 
to support national ID cards on Free Software operating systems.

This particular package is one of the core libraries used to access
and manipulate the data on the ID cards.

The whole suite is comprised of the following source packages:

smartcardpp
libdigidoc
libdigidocpp
qesteidutil
qdigidoc
esteid-browser-plugin



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

Re: DEP-5 and files with white spaces

[Jakub Wilk]

* Russ Allbery , 2012-02-01, 14:20:
DEP-5 is nice, but how can I specify a license for a file with white 
spaces? For example you want to specify that the file "foo/file 
one.bar" is licensed under ISC, but "foo/file_one.bar" is licensed 
under GPL. How can you do that?


No, that distinction isn't representable.


This one is representable. You can take advantage of the fact the "the 
last paragraph that matches a particular file applies to it":


| Files: foo/file?one.bar
| License: ISC
|
| Files: foo/file_one.bar
| License: GPL

That said, you _can_ construct even more contrived examples which are 
unrepresentable, e.g. by replacing "_" with a tab.


The general way to specify information for a file name that contains 
whitespace is to use wildcards to match the whitespace,


That works only if you can stand ugliness of such Files fields.

--
Jakub Wilk


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

Re: Linux 3.2 in wheezy

[Thomas Goirand]

On 02/02/2012 03:37 AM, Moritz Naumann wrote:
> So there are obvious issues with LXC as a container solution for Linux, such 
> as
> lacking actual containment (for the root user), which defeat sits purpose in
> production environments as a linux-vserver or OpenVZ replacement. 
>
> However, a low profile container/virtualization solution is needed, and I know
> there is quite some demand for it: both some larger scale organisations and
> several smaller/non-profit organisations I am acquainted with use either 
> OpenVZ
> or linux-vserver and some of them will be in trouble if there is no equivalent
> and not at least a rough migration path.
>   

I know that containers and virtualization isn't the same, but since
kernel 3.0
we have Xen included upstream, and KVM since a lot longer.

> Right now, (not just) my hopes are that linux-vserver + openvz (or at least 
> one
> of them) will continue to be available in wheezy for as long as no other
> comparable options are available.
>   

Unless someone wants to work on it and make it happen, it wont...
(sorry for stating the obvious)

Thomas


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

Bug#658303: ITP: qesteidutil -- Estonian ID card management utility

[Guido Tabbernuk]

Package: wnpp
Severity: wishlist
Owner: Guido Tabbernuk 


* Package name: qesteidutil
  Version : 0.3.1
  Upstream Author : Kalev Lember  & others
* URL : http://code.google.com/p/esteid/
* License : LGPL 2.1
  Programming Lang: C++
  Description : Estonian ID card management utility

QEsteidUtil is a user-friendly application for managing Estonian ID Cards.
It can be used to change and unlock PIN codes, examine the personal 
information stored on the card, extract and view the certificates, set 
up mobile ID and configure a personal @eesti.ee e-mail address.

*

This package is one of 6 packages created by the Estonian government 
to support national ID cards on Free Software operating systems.

The whole suite is comprised of the following source packages:

smartcardpp
libdigidoc
libdigidocpp
qesteidutil
qdigidoc
esteid-browser-plugin



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

Re: DEP-5 and files with white spaces

[Russ Allbery]

Jakub Wilk  writes:

> This one is representable. You can take advantage of the fact the "the
> last paragraph that matches a particular file applies to it":

> | Files: foo/file?one.bar
> | License: ISC
> |
> | Files: foo/file_one.bar
> | License: GPL

Oh, hey, yes, good point.

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


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

Bug#658304: ITP: qdigidoc -- QT-based Digidoc client

[Guido Tabbernuk]

Package: wnpp
Severity: wishlist
Owner: Guido Tabbernuk 


* Package name: qdigidoc
  Version : 0.4.0
  Upstream Author : Kalev Lember  & others
* URL : http://code.google.com/p/esteid/
* License : LGPL 2.1
  Programming Lang: C++
  Description : QT-based Digidoc client

QDigiDoc is an application for digitally signing and encrypting documents in
BDoc, DDoc, and CDoc container formats. These file formats are widespread in
Estonia where they are used for storing legally binding digital signatures.

*

This package is one of 6 packages created by the Estonian government 
to support national ID cards on Free Software operating systems.

The whole suite is comprised of the following source packages:

smartcardpp
libdigidoc
libdigidocpp
qesteidutil
qdigidoc
esteid-browser-plugin



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

Re: DEP-5 and files with white spaces

[Benjamin Drung]

Am Mittwoch, den 01.02.2012, 14:20 -0800 schrieb Russ Allbery:
> Benjamin Drung  writes:
> 
> > DEP-5 is nice, but how can I specify a license for a file with white
> > spaces? For example you want to specify that the file "foo/file one.bar"
> > is licensed under ISC, but "foo/file_one.bar" is licensed under GPL. How
> > can you do that?
> 
> No, that distinction isn't representable.  There was some earlier
> discussion about that, and the conclusion reached was that it was a rare
> case that wasn't worth making the syntax more complicated (after various
> more complicated syntaxes were tossed around without making anyone very
> happy).

Is it to complex to have a syntax that is similar to what the shell
does? Two solutions pop into my mind. Please let me know, why these are
not use. You can point me to previous discussions.

Idea 1: Use a escape sequence for specifying a whitespace (e.g. "\ " for
a space).

Idea 2: Allow quotation marks.

> The general way to specify information for a file name that contains
> whitespace is to use wildcards to match the whitespace, which means that
> you can't disambiguate from other files that only differ in the places
> where whitespace is present.

I don't like the idea of abusing a wildcard if the files could be
specified more precisely.

> Out of curiosity, have you run across a case where this matters, or were
> you asking because it's a theoretical hole?  It's definitely a theoretical
> hole, but one of the reasons why we didn't spend more time on it was that
> everyone was dubious that the case would arise in a real-world situation.

I haven't run across an actual case. This case just popped into my mind
and I wondered how to cover this case.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: Breaking programs because a not yet implemented solution exists in theory

[Andreas Tille]

On Wed, Feb 01, 2012 at 05:03:17PM +0100, Michael Biebl wrote:
> 
> Tools like mutt, which need the extended mailcap syntax, can certainly
> continue to ship a mime file.
> 
> If a package ships both a desktop and a mime file, the conversion-tool
> could simply skip the automatic generation of the mailcap entries under
> the assumption that the manually written ones take precedence.

Could somebody please answer my implicite question why the mime files
are removed before such a conversion tool exists and thus shamelessly
are breaking applications that depend from it.

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
Archive: http://lists.debian.org/20120201224515.gj10...@an3as.eu

Re: DEP-5 and files with white spaces

[Benjamin Drung]

Am Mittwoch, den 01.02.2012, 23:31 +0100 schrieb Jakub Wilk:
> * Russ Allbery , 2012-02-01, 14:20:
> >>DEP-5 is nice, but how can I specify a license for a file with white 
> >>spaces? For example you want to specify that the file "foo/file 
> >>one.bar" is licensed under ISC, but "foo/file_one.bar" is licensed 
> >>under GPL. How can you do that?
> >
> >No, that distinction isn't representable.
> 
> This one is representable. You can take advantage of the fact the "the 
> last paragraph that matches a particular file applies to it":
> 
> | Files: foo/file?one.bar
> | License: ISC
> |
> | Files: foo/file_one.bar
> | License: GPL
> 
> That said, you _can_ construct even more contrived examples which are 
> unrepresentable, e.g. by replacing "_" with a tab.
> 
> >The general way to specify information for a file name that contains 
> >whitespace is to use wildcards to match the whitespace,
> 
> That works only if you can stand ugliness of such Files fields.

True words.

For example, the eclipse source package has files with spaces in it
using ? instead of spaces does look ugly.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: DEP-5 and files with white spaces

[Russ Allbery]

Benjamin Drung  writes:

> Is it to complex to have a syntax that is similar to what the shell
> does? Two solutions pop into my mind. Please let me know, why these are
> not use. You can point me to previous discussions.

> Idea 1: Use a escape sequence for specifying a whitespace (e.g. "\ " for
> a space).

> Idea 2: Allow quotation marks.

Yeah, both of those were among the other syntax proposals that were
suggested, and I think one of them was in the document at one point.
Using backslash is probably the easiest, although it does make parsing the
files harder.

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


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

Re: Breaking programs because a not yet implemented solution exists in theory

[Russ Allbery]

Andreas Tille  writes:

> Could somebody please answer my implicite question why the mime files
> are removed before such a conversion tool exists and thus shamelessly
> are breaking applications that depend from it.

Josselin did answer your question.  To paraphrase my understanding of the
answer: because he (they, probably, but he only spoke for himself) doesn't
want to maintain those files because they duplicate information stored in
another system that he considers superior for the purposes of what he's
doing, their lack doesn't what he views as his primary target audience,
and by removing them he forces people who care about the mailcap support
to do the work of deriving that information from desktop files if they
care enough to keep the system working.

I can understand not liking this answer, but you did get an answer.

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


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

Re: DEP-5 and files with white spaces

[Benjamin Drung]

Am Mittwoch, den 01.02.2012, 14:49 -0800 schrieb Russ Allbery:
> Benjamin Drung  writes:
> 
> > Is it to complex to have a syntax that is similar to what the shell
> > does? Two solutions pop into my mind. Please let me know, why these are
> > not use. You can point me to previous discussions.
> 
> > Idea 1: Use a escape sequence for specifying a whitespace (e.g. "\ " for
> > a space).
> 
> > Idea 2: Allow quotation marks.
> 
> Yeah, both of those were among the other syntax proposals that were
> suggested, and I think one of them was in the document at one point.
> Using backslash is probably the easiest, although it does make parsing the
> files harder.

IMHO allowing both would be the optimum. A real parser would have
problems with both, but a simplistic "parser" that just split the string
by spaces would have a problem.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: DEP-5 and files with white spaces

[Russ Allbery]

Benjamin Drung  writes:
> Am Mittwoch, den 01.02.2012, 14:49 -0800 schrieb Russ Allbery:

>> Yeah, both of those were among the other syntax proposals that were
>> suggested, and I think one of them was in the document at one point.
>> Using backslash is probably the easiest, although it does make parsing
>> the files harder.

> IMHO allowing both would be the optimum. A real parser would have
> problems with both, but a simplistic "parser" that just split the string
> by spaces would have a problem.

Yeah, that was, as I understand it, the motivation (to allow really simple
parsers).

I don't know if it's worth revisiting this.  I can't say that I
particularly liked the outcome we arrived at, but theoretical holes in
standards bother me a lot (possibly more than they should).

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


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

Bug#658308: ITP: python-pbs -- Execute shell commands as python functions

[Nick Moffitt]

Package: wnpp
Severity: wishlist
Owner: Nick Moffitt 


  Package name: python-pbs
  Version : 0.7
  Upstream Author : Andrew Moffat 
  URL : http://www.example.org/
  License : MIT/X
  Programming Lang: Python
  Description : Execute shell commands as python functions

 PBS is a unique subprocess wrapper that maps your system programs to
 Python functions dynamically. PBS helps you write shell scripts in
 Python by giving you the good features of Bash (easy command calling,
 easy piping) with all the power and flexibility of Python.
 .
 >>> from pbs import ifconfig
 >>> print ifconfig("eth0")
 .
 PBS is not a collection of system commands implemented in Python.

I've uploaded a first crack at packaging to 
http://mentors.debian.net/package/pbs



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

Re: DEP-5 and files with white spaces

[Benjamin Drung]

Am Mittwoch, den 01.02.2012, 14:56 -0800 schrieb Russ Allbery:
> Benjamin Drung  writes:
> > Am Mittwoch, den 01.02.2012, 14:49 -0800 schrieb Russ Allbery:
> 
> >> Yeah, both of those were among the other syntax proposals that were
> >> suggested, and I think one of them was in the document at one point.
> >> Using backslash is probably the easiest, although it does make parsing
> >> the files harder.
> 
> > IMHO allowing both would be the optimum. A real parser would have
> > problems with both, but a simplistic "parser" that just split the string
> > by spaces would have a problem.
> 
> Yeah, that was, as I understand it, the motivation (to allow really simple
> parsers).

What is more important: A "good looking" copyright file or being
parsable by a dead simple, stupid parser? The proposed changes would
make the parser overly complex. 

> I don't know if it's worth revisiting this.  I can't say that I
> particularly liked the outcome we arrived at, but theoretical holes in
> standards bother me a lot (possibly more than they should).

I would call a theoretical hole a design bug.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Bug#658309: ITP: esteid-browser-plugin -- Estonian ID card browser plugin

[Guido Tabbernuk]

Package: wnpp
Severity: wishlist
Owner: Guido Tabbernuk 


* Package name: esteid-browser-plugin
  Version : 1.3.2
  Upstream Author : Kalev Lember  & others
* URL : http://code.google.com/p/esteid/
* License : LGPL 2.1 and/or BSD
  Programming Lang: C++
  Description : Estonian ID card browser plugin

EstEID browser plugin is a cross-browser plugin that accesses
Estonian national ID card features via JavaScript.
.
This package provides the plugin for NPAPI-compatible browsers
such as Chromium, Epiphany and Firefox.
.
The plugin is used by web pages to sign legally-binding documents
using the digital certificate that is accessed via PIN2.
.
In order to protect the user's privacy, only web pages that 
appear in a "whitelist" can access the card. For unlisted pages,
a yellow notification bar appears.
.
The plugin also implements a compatibility mode to support 
existing web pages that utilize the legacy signature API.

*

This package is one of 6 packages created by the Estonian government 
to support national ID cards on Free Software operating systems.

The whole suite is comprised of the following source packages:

smartcardpp
libdigidoc
libdigidocpp
qesteidutil
qdigidoc
esteid-browser-plugin



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

Re: DEP-5 and files with white spaces

[Charles Plessy]

Le Wed, Feb 01, 2012 at 11:44:36PM +0100, Benjamin Drung a écrit :
> 
> Is it to complex to have a syntax that is similar to what the shell
> does? Two solutions pop into my mind. Please let me know, why these are
> not use. You can point me to previous discussions.

Hi Benjamin,

You can refer to the following threads


1) DEP 5 and directory/file names with spaces
   (http://lists.debian.org/debian-devel/2009/06/msg00155.html)

My summary is that the participants were quite divided on whether separating
the list of files by spaces or by commas.  Space-separation took advantage, as
the resulting list can be pasted directly in a shell.  The escaping syntax was
glob(7) at the time, but it allows patterns that the shell will not expand, so
the two wildcards * and ? were proposed.  My personal feeling is that more
complete syntax, like allowing shell quotes, did not make it because no
participant had patience or energy left for moving this forward.  But ‘shell
pastability’ is I think the conclusion.


2) DEP-5: an example parser, choice of syntax for Files:
   (http://lists.debian.org/debian-devel/2009/09/msg00558.html)

Discussion on the original syntax based on the find command, where I reminded
the thread above; no objection.


3) DEP-5: file globbing
   (http://lists.debian.org/debian-project/2010/08/msg00154.html)

Discussion about exclusion patterns.


4) DEP-5: Files field and filename patterns
   (http://lists.debian.org/debian-project/2010/08/msg00289.html)
   (http://lists.debian.org/debian-project/2010/09/msg00029.html)

The simple globbing with * and ? was finally chosen.  It was noted that because
it is a lowest common denominator, it leaves the room for expansion later.


5)  Re: DEP5: CANDIDATE and ready for use in squeeze+1
   (http://lists.debian.org/debian-devel/2011/01/msg00235.html)

In this thread, you questionned how to escape files with
a space in their names, and did not object to the answer from Lars.


The current syntax has been used for years, and while it can be perfected, I do
not think that such extension is in the scope of the version 1.0 that we are
preparing.  What I propose, if you think it is worth, is to open a bug, to
track that request for the next revision. 

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Bug#605090: Linux 3.2 in wheezy

[Russell Coker]

On Thu, 2 Feb 2012, dann frazier  wrote:
> Whilte it may help the kernel team to not have to worry about problems
> in the grsec flavor when preparing uploads, preventing delays for the
> non-grsec images. But, that just pushes the coordination down a ways -
> for stable updates we would need to add the grsec build into the
> pipeline, and there'd be delays in grsec security updates that go in
> via linux-2.6. Not nak'ing the idea, but it does extend some critical
> paths.

The current approach of having a kernel patch package seems to work well.  It 
removes the need for involvement of the kernel and security teams (presumably 
security changes to the kernel will usually not require changes to the 
grsecurity patch) and allows the users to easily build their own kernels.

If a user has a choice between using Spender's Debian package and a kernel-
patch package to build their own kernel then I think that they should be able 
to do whatever they want.

Spender suggested that people who want GRSecurity on Debian would be better 
off using a .deb he provides and working on user-space hardening.

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


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

Re: Linux 3.2 in wheezy

[Russell Coker]

On Thu, 2 Feb 2012, Moritz Naumann  
wrote:
> So there are obvious issues with LXC as a container solution for Linux,
> such as lacking actual containment (for the root user), which defeat sits
> purpose in production environments as a linux-vserver or OpenVZ
> replacement.
> 
> However, a low profile container/virtualization solution is needed, and I
> know there is quite some demand for it: both some larger scale
> organisations and several smaller/non-profit organisations I am acquainted
> with use either OpenVZ or linux-vserver and some of them will be in
> trouble if there is no equivalent and not at least a rough migration path.

Are there many users who need root containment but who won't have the 
resources to run Xen or KVM when the support for Squeeze ends?

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


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

Re: Bug#657949: Cannot install libhdf5-mpi-dev and libnetcdf-dev

[Steve M. Robbins]

Hi,

I'd like to contribute towards a solution for this.  I'm forwarding to
debian-devel to get some others' ideas.


On Wed, Feb 01, 2012 at 09:57:39AM +0100, Sylvestre Ledru wrote:
> Le mardi 31 janvier 2012 à 21:56 -0600, Steve M. Robbins a écrit :

> > Naively, I don't understand why netcdf can't offer multiple variants,
> > just as hdf5 does.  Or, at least, one package libnetcdf-mpi-dev that
> > links with the "default" MPI implementation.
> I am not involved in the netcdf. You should report a bug on this
> package.

I'm prepared to do so, but I'd first like to get agreement that
netcdf is where the problem lies.  Netcdf maintainers, please
chime in!


On Wed, Feb 01, 2012 at 05:44:49PM +0100, Francesco P. Lovergine wrote:
> On Tue, Jan 31, 2012 at 04:41:06PM +0100, Sylvestre Ledru wrote:
> > Even if I am not happy about this change, it is expected.
> > libnetcdf-dev depends on libnetcdf7 which depends on libhdf5-7.
> > libhdf5-openmpi-7 conflicts with libhdf5-7.
> > 
> > Before I had the silly idea to become a hdf5 maintainer, I reported this
> > bug myself #591346.
> > For now, I haven't find the right solution to tackle this issue ... 
> > Suggestions are welcome.
> > 
> 
> The solution is having upstream adopting a sane naming scheme for mpi-enabled
> flavor libraries instead of using always the same names for all.

Francesco, please clarify: are you speaking of the hdf5 upstream or
the netcdf upstream?  (Both?)  

What problem are you trying to solve with that: co-installable -dev
packages or just coinstallable lib packages?


> Unfortunately they were still not available for that at the time of
> my last poking.  Diverging from upstream is not a good idea, so we
> still have to live in a non perfect world...

I think we can no longer live in the status quo (see all the blockers
of #631019), so something has to give.  Even if it is painful, perhaps
Debian could pioneer something and pass patches back to upstream?

Thoughts?

-Steve



signature.asc
Description: Digital signature

Re: Linux 3.2 in wheezy

[Marco d'Itri]

On Feb 02, Russell Coker  wrote:

> Are there many users who need root containment but who won't have the 
> resources to run Xen or KVM when the support for Squeeze ends?
Are there many users who like to waste resources (mostly RAM, here) for
no good reason?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Wookey]

+++ Andreas Tille [2012-02-01 09:56 +0100]:
> Hi Josselin,
> 
> > To break such a chicken/egg circle, we
> > needed either to write the program ourselves, or to simply drop support
> > for the obsolete mime system.
> 
> Somehow I missed an announcement that mime is obsolete and not supported
> in Debian any more.

Me too - this is the first I've heard of it

> > And since, after seven months, nothing happened, it means no one is
> > interested enough, although some one-liners doing half of the job have
> > been circulating.
> 
> Well, from my perspective I was bored the first time when xpdf came up
> when I was expecting evince.  

Same here. I recently noticed that I got epdfview instead of evince -
but they are much of a muchness, so I put this down to testing
randomness, or probably this new pdf reader 'stealing' the
application/pdf config. I've always been rather confused about the
interactions between the different application/filetype config systems
(and mc has it's own too) and irritating breakage is not exactly
unheard-of.

It wasn't at all obvious that the actual reason was a conspiracy to
remove mime file support from evince. Now that I know about it, I'm
not very impressed. Andreas has already expressed this annoyance so I
won't say it again.

As a packager I've been adding mime info recently to my packages so
that they work properly everywhere. I thought that's what packaging
(in Debian at least) was about.

I'm happy if someone can write an automagic tool for maintainers that
aren't going to support mime files any longer. But us mutt+mc types
really do still use this functionality every day. It doesn't look
obsolete to me, even if it has been superceded on the desktop. (And it
would be nice as a packager not to have to write this info down twice
in different approximately-equivalent formats). 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120202021414.gd6...@dream.aleph1.co.uk

Re: Bug#605090: Linux 3.2 in wheezy

[Kees de Jong]

Perhaps you should contact Julien Tinnes of http://kernelsec.cr0.org/ 
He has been too busy to work on the kernels lately but maybe he wants to
help.





On do, 2012-02-02 at 12:18 +1100, Russell Coker wrote:

> On Thu, 2 Feb 2012, dann frazier  wrote:
> > Whilte it may help the kernel team to not have to worry about problems
> > in the grsec flavor when preparing uploads, preventing delays for the
> > non-grsec images. But, that just pushes the coordination down a ways -
> > for stable updates we would need to add the grsec build into the
> > pipeline, and there'd be delays in grsec security updates that go in
> > via linux-2.6. Not nak'ing the idea, but it does extend some critical
> > paths.
> 
> The current approach of having a kernel patch package seems to work well.  It 
> removes the need for involvement of the kernel and security teams (presumably 
> security changes to the kernel will usually not require changes to the 
> grsecurity patch) and allows the users to easily build their own kernels.
> 
> If a user has a choice between using Spender's Debian package and a kernel-
> patch package to build their own kernel then I think that they should be able 
> to do whatever they want.
> 
> Spender suggested that people who want GRSecurity on Debian would be better 
> off using a .deb he provides and working on user-space hardening.
> 
> -- 
> My Main Blog http://etbe.coker.com.au/
> My Documents Bloghttp://doc.coker.com.au/
> 
> 


-- 
Met vriendelijke groet,
Kees de Jong



De informatie opgenomen in dit bericht kan vertrouwelijk
zijn en is uitsluitend bestemd voor de
geadresseerde(n). 
Indien u dit bericht onterecht ontvangt, wordt u
verzocht de inhoud niet te gebruiken en de afzender
direct te informeren door het bericht te retourneren.
--
The information contained in this message may be
confidential and is intended to be exclusively for the
addressee(s). 
Should you receive this message unintentionally, please
do not use the contents herein and notify the sender
immediately by return e-mail. 











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

Re: Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

> On do, 2012-02-02 at 12:18 +1100, Russell Coker wrote: 
> > On Thu, 2 Feb 2012, dann frazier  wrote:
> > > Whilte it may help the kernel team to not have to worry about problems
> > > in the grsec flavor when preparing uploads, preventing delays for the
> > > non-grsec images. But, that just pushes the coordination down a ways -
> > > for stable updates we would need to add the grsec build into the
> > > pipeline, and there'd be delays in grsec security updates that go in
> > > via linux-2.6. Not nak'ing the idea, but it does extend some critical
> > > paths.
> > 
> > The current approach of having a kernel patch package seems to work well.  
> > It 
> > removes the need for involvement of the kernel and security teams 
> > (presumably 
> > security changes to the kernel will usually not require changes to the 
> > grsecurity patch) and allows the users to easily build their own kernels.
> > 
> > If a user has a choice between using Spender's Debian package and a kernel-
> > patch package to build their own kernel then I think that they should be 
> > able 
> > to do whatever they want.
> > 
> > Spender suggested that people who want GRSecurity on Debian would be better 
> > off using a .deb he provides and working on user-space hardening.
> > 

(please don't top-post)
If people on the CC: list want to be dropped, please ask :)

On jeu., 2012-02-02 at 07:18 +0100, Kees de Jong wrote:
> Perhaps you should contact Julien Tinnes of http://kernelsec.cr0.org/ 
> He has been too busy to work on the kernels lately but maybe he wants
to help.
> 
> 

Well Julien was aware of my initiative and, afaict, he didn't really
have time for that, nor was interested in the porting part.

And as I said before, I'm not interested in shipping just a patch in
Debian. If users want to patch the kernel, configure it and built it, I
think they're better off getting the latest patch from grsecurity.net
and kernel from kernel.org. The point was in shipping a binary package
with a default setup secure enough, and a way to tune the features
through sysctl.

Regards,
-- 
Yves-Alexis


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

Re: Breaking programs because a not yet implemented solution exists in theory

[Andreas Tille]

On Wed, Feb 01, 2012 at 02:52:22PM -0800, Russ Allbery wrote:
> Josselin did answer your question.  To paraphrase my understanding of the
> answer: because he (they, probably, but he only spoke for himself) doesn't
> want to maintain those files because they duplicate information stored in
> another system that he considers superior for the purposes of what he's
> doing, their lack doesn't what he views as his primary target audience,
> and by removing them he forces people who care about the mailcap support
> to do the work of deriving that information from desktop files if they
> care enough to keep the system working.

OK, but in this case I think #658139 (and probably friends?) is
incorrectly handled.  It should not be wishlist + wontfix because
packages are actually broken.  If Josselin and others are regarding this
as sombody else's problem the bug should be rather reassigned to
somebody else's package - in this case perhaps general comes to mind
because it affects several packages.  Josselin was expecting the
"general void" to solve the problem and thus the bug should rather go
there (by keeping important severity).

Alternatively it also could be reassigned to mime-support because other
broken packages are basically relying on this one.  However simply
hiding a problem by decreasing severity is a strange way to handle
something and assuming it would force somebody else to work.

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
Archive: http://lists.debian.org/20120202072622.gc31...@an3as.eu

Re: Linux 3.2 in wheezy

[Jonathan Carter (highvoltage)]

Hi Russell

On 02/02/2012 03:21, Russell Coker wrote:

However, a low profile container/virtualization solution is needed, and I
know there is quite some demand for it: both some larger scale
organisations and several smaller/non-profit organisations I am acquainted
with use either OpenVZ or linux-vserver and some of them will be in
trouble if there is no equivalent and not at least a rough migration path.


Are there many users who need root containment but who won't have the
resources to run Xen or KVM when the support for Squeeze ends?


Just to give you a use case, the company I work for has a bunch of 
clients where we run more than 400 VZ's per server. Those servers are 
already packed with RAM and are using most of it and even swapping. 
Switching to KVM/Xen would probably kill those machines :)


We're really dependent on contextualization so we considered the following:
 * LXC
 * Using VZ on CentOS
 * Getting the 2.6.32 VZ kernel from the openvz project and check if 
that works with our current user space


LXC kind of works but has it's issues. We really want to move to it.

I'm personally strongly against CentOS (they had months without security 
updates last year, I find the quality of rpm packaging poor compared to 
those found in Debian) and I don't think it's a good idea to have yet 
another system to support.


We tried the 2.6.32 VZ kernel on squeeze / wheezy / lucid / precise - 
and it works. We have a PPA[1] for our experimental packages too. We 
might run into bugs with some userspace things needing a newer kernel, 
but we haven't found anything yet. The big downside is also that we rely 
on the VZ project to release security updates and we have to be vigilant 
to update regularly.


All the work that the above is causing (and to an extent the risk) makes 
me quite eager to move to LXC. If distributions like Debian and Ubuntu 
could continue supporting it it would be a different story, but it 
sounds like OpenVZ is a borderline hostile upstream who isn't interested 
in working with anyone, and that makes me want to move away even more.


-Jonathan

[1] https://launchpad.net/~revolution-linux/+archive/openvz


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