headers
Steve McIntyre | 1 Feb 03:12
Favicon

Re: Proposed mass bug-filing/NMUing: perl 4 libraries

Dom wrote:
>I would like to try and ensure that wheezy releases without any packages
>which use the deprecated perl 4 libraries without depending on the
>separate libperl4-corelibs-perl package.
>
>You can see more details, and a list of packages, at
><http://wiki.debian.org/Teams/DebianPerlGroup/OpenTasks/Transitions/Perl4CoreLibs>
>and
><http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629472>
>
>I would like to file bugs against these packages, together with patches
>if possible, to fix the issues (I'm hoping that other members of the
>Debian Perl group might be able to help out with this, too).
>Severity: normal seems appropriate, at least initially.

...

>Steve McIntyre <93sam <at> debian.org>
>   nas

Fixed package in incoming now.

--

-- 
Steve McIntyre, Cambridge, UK.                                steve <at> einval.com
"You can't barbecue lettuce!" -- Ellie Crane
Permalink | Reply | 0 comments |
headers
Paul Wise | 1 Feb 03:33
Picon
Favicon
Gravatar

Re: lack of replacement for linux-vserver

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

--

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roberto C. Sanchez | 1 Feb 03:53
Favicon

Bug#658213: ITP: django-fixture-generator -- reusable django application to make writing fixtures not suck

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" <roberto <at> connexer.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

* Package name    : django-fixture-generator
  Version         : 0.2.0
  Upstream Author : Alex Gaynor <alex.gaynor <at> gmail.com>
* URL             : http://pypi.python.org/pypi/django-fixture-generator
* License         : BSD
  Programming Lang: Python
  Description     : reusable django application to make writing fixtures not suck

 By adding `fixture_generator'' to the `INSTALLED_APPS'' setting,
 creating a `fixture_gen.py'' file (see the included documentation for an
 example) in one of the apps, it is possible to quickly and easily
 generate fixtures.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJPKKj9AAoJECzXeF7dp7IPwsIQAKmc1b0tGtX3HjH50n4YbsGX
K/BZrjUSAg6cHkDknBhjD/WiiwqjU3hIIRWMPLRHyPOTNYtQyA/i6BqzDJoHs+Ow
fPuDmbxwxLXfPqU5Lv6Htd7YgdjdUQ883VraKgBaao8VwQN/TP5/g46xKbHliyRL
GsOmrnJQj3yik6DlA4MHg1H3vSzxOKvqTwa3Nz6l7KkLCQLQ00+j1FTwN+EeAe+0
OilOcfC4BydizWo1FKQdE57HZC5O14QoTfZhfd3AhYeKX9Ehip8htPkTlku3R6Yq
2gMaMAqEI/S1RlSZ2IWeNRmKqQc7kFyeSe9q1zyVX+Co3fiDjJVBytUsiqEmtl36
ToujTKIsXos/Yf7bdeUfFTCfn84z+3N+AcVncTNCuvA0Mjficrq/EOKKe015IyEx
(Continue reading)

Permalink | Reply | 0 comments |
headers
Josselin Mouette | 1 Feb 09:29
Picon
Favicon

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

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 <feel free to insert any word which fits>.

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
: :' :
`. `'
  `-
Permalink | Reply | 36 comments |
headers
Andreas Tille | 1 Feb 09:56
Picon

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

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 <feel free to insert any word which fits>.
> 
> 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
(Continue reading)

Permalink | Reply | 30 comments |
headers
Russ Allbery | 1 Feb 10:14
Picon
Favicon

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

Andreas Tille <andreas <at> an3as.eu> 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:
(Continue reading)

Permalink | Reply | 8 comments |
headers
Josselin Mouette | 1 Feb 10:35
Picon
Favicon

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

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
: :' :
`. `'
  `-
Permalink | Reply | 7 comments |
headers
Wouter Verhelst | 1 Feb 10:34
Picon
Favicon
Gravatar

Re: Bug#605090: Linux 3.2 in wheezy

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
Permalink | Reply | 32 comments |
headers
Yves-Alexis Perez | 1 Feb 10:51
Picon
Favicon

Re: Bug#605090: Linux 3.2 in wheezy

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
Permalink | Reply | 26 comments |
headers
Russ Allbery | 1 Feb 10:51
Picon
Favicon

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

Josselin Mouette <joss <at> debian.org> 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.
(Continue reading)

Permalink | Reply | 6 comments |

Gmane