Re: "Blacklists" in BTS (stopping the trolls and bug machines)

[Ondřej Surý]

On Sat, May 25, 2013 at 8:02 PM, Russ Allbery  wrote:

> Ben Hutchings  writes:
> > On Sat, 2013-05-25 at 10:41 +0200, Ondřej Surý wrote:
>
> >> I have no big problem pointing fingers on d-d.
> >>
> >> Example 1: Dan Jacobson 
>
> > Often writes poor bug reports, but is not abusive.
>
> And his bug reports have gotten better and better over the years.


I am horrified what his bugreports were before the years, if those I have
just shown are "better" :).


> He
> still files all upstream bugs with Debian, but I can't throw stones there;
> I tend to do the same thing myself, since Debian has such a nice and
> consistent bug reporting interface and upstream's usually... isn't.  :)
>
> He files lots and lots of minor/wishlist bugs, but that isn't abuse.  He's
> one of the few people who regularly files bugs when he finds unclear or
> confusing documentation, and while that results in a lot of small bugs
> (and a lot of bugs that are really upstream bugs), I think that's also a
> valuable *type* of bug that frequently doesn't get enough attention.
>

I think I have never said the word "abuse", just "tiresome". The "I see a
warning from ucf, let's fill a bug on php5-common" finally overflew my cup
of patience (what is the correct english idiom for this?).

I have an idea – maybe we could have a pseudo-package called
"please-improve" (or whatever name we pick), where people can reassign
bugreports which they feel they are unable to handle. This pseudo-bug would
be monitored by some virtuous people[*] better in handling poor bugreports
and they would work with submitter to improve the bug report, and then
reassign it back.

This might be similar to what I have seen in Launchpad – there's a bugsquad
team that can handle all bugreports in just any package[1][2].

* - if we can find such people somewhere, but I am quite sure there are
some :).

1. https://wiki.ubuntu.com/HelpingWithBugs
2. https://launchpad.net/~bugsquad

O.
-- 
Ondřej Surý 

Re: systemd .service file conversion

[Игорь Пашев]

2013/5/27 brian m. carlson :
> At the risk of adding another level of indirection, we could add a
> meta-init format that can generate an appropriate file for any of these.


http://xkcd.com/927/


-- 
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/call-q8xqutu4eznaxhg-amfzklwfn7xjcas3w33mv6wevbd...@mail.gmail.com

Re: optimizing PNGs

[Mathieu Malaterre]

On Sun, May 26, 2013 at 8:10 PM, Aron Xu  wrote:
> On Mon, May 27, 2013 at 1:42 AM, Mathieu Malaterre  wrote:
>> On Sun, May 26, 2013 at 5:56 PM, Adam Borowski  wrote:
>>> A while ago, someone raised the possibility of recompressing PNG files.
>>> Unlike xz, this would save space not only on mirrors but also on live
>>> installed systems.  PNGs are nearly incompressible so this is mostly
>>> independent from xz.
>>>
>>> At least by number, there's a lot of PNG images:
>> [...]
>>>   5 ns3-doc
>>
>> This one is slightly different and should be treated differently IMHO.
>> See `Subject: Ridiculously large packages`[1] on debian-cd, which got
>> solved using SVG output when generating doxygen documentation. See for
>> example:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557238
>>
>> 2cts
>> [1] https://lists.debian.org/debian-cd/2009/11/msg00039.html
>>
>
> Can you give a more detailed pointer to `got solved using SVG output
> when generating doxygen documentation`? ns3-doc currently runs optipng
> against all generated PNG files during the arch:all package
> generation, which costs quite some time to finish even on a quite fast
> server but reduces the size for about 300MiB.

vtk-doc in suqeeze used to be a lot bigger when the output was PNGs file:

http://comments.gmane.org/gmane.text.doxygen.general/8232

"Installed Size 855,380 kB"

Which is now (in squeeze using SVGs output):

http://packages.debian.org/squeeze/vtk-doc

"Installed Size 393,136.0 kB"

Doxygen will use SVG for graph (collaboration, inheritance), SVG is
AFAIK one of the best possible representation for such information.
The remainings PNGs are formulas (latex). It would be nice if doxygen
would use mathml...

2cts


-- 
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/ca+7wuszmvuuodrtq5txklrbt7+obv0u+pq-umgjdw0g4jqw...@mail.gmail.com

Re: optimizing PNGs

[Mathieu Malaterre]

On Sun, May 26, 2013 at 8:20 PM, Adam Borowski  wrote:
> On Sun, May 26, 2013 at 07:42:49PM +0200, Mathieu Malaterre wrote:
>> On Sun, May 26, 2013 at 5:56 PM, Adam Borowski  wrote:
>> > A while ago, someone raised the possibility of recompressing PNG files.
>> > Unlike xz, this would save space not only on mirrors but also on live
>> > installed systems.  PNGs are nearly incompressible so this is mostly
>> > independent from xz.
>> >
>> > At least by number, there's a lot of PNG images:
>> [...]
>> >   5 ns3-doc
>>
>> This one is slightly different and should be treated differently IMHO.
>> See `Subject: Ridiculously large packages`[1] on debian-cd, which got
>> solved using SVG output when generating doxygen documentation.
>
> Formats other than PNG might be more appropriate, yes.
>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557238
>
> This one (vtk-doc) doesn't compress PNGs, but reduces their quality in a
> lossy way to 256 colours.  And in this case, using optipng+advpng would
> reduce the files by more than a half (comparing sizes of .tar.xz).

True there are remainings PNGs in vtk-docs, as explained before, those
are latex equation.
I believe it would be even nicer when doxygen would support better
latex support and would generate something other than a poor-man
solution of PNGs for equations.

2cts


-- 
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/CA+7wUszQxvSF_t0Ef7Jr2sUC0w9ek=3vj9nercfwgswtrsw...@mail.gmail.com

Re: systemd .service file conversion

[Ondřej Surý]

On Sun, May 26, 2013 at 10:29 PM, Helmut Grohne  wrote:

> I find it depressing to see four init/rc systems, of which three are
>  mutually incompatible in every single possible aspect.
>

Just my two cents.

I would be quite happy to write service files for two (systemd, upstart) or
three (systemd, upstart, openrc) of those in all my packages[*], if it
stops the endless flamewar here. I would also be happy to have the
requirement to support two (or three) of them in the Debian policy.

I know that we would still need to pick-up default, but that might be a
slightly easier task than to decide the only supported init system.

* - That's just *6* out of my 70+ package, but I doubt that anybody has too
much packages with init script to handle (and if that's the case he should
have co-maintainers).

O.
-- 
Ondřej Surý 

Re: "Blacklists" in BTS (stopping the trolls and bug machines)

[Helmut Grohne]

On Mon, May 27, 2013 at 09:04:53AM +0200, Ond??ej Surý wrote:
> I have an idea ??? maybe we could have a pseudo-package called
> "please-improve" (or whatever name we pick), where people can reassign
> bugreports which they feel they are unable to handle. This pseudo-bug would
> be monitored by some virtuous people[*] better in handling poor bugreports
> and they would work with submitter to improve the bug report, and then
> reassign it back.

The downside of this approach is that you lose track of the affected
component and version information (or at least this information is no
longer mechanically queryable if it is present at all). So instead maybe
tags could be used to convey this information. Indeed there are already
some tags that that partly address your needs. For instance, "moreinfo"
is to mark bugs that lack important information and "help" is a signal
that you are not going to fix it. To get a cleaner view on your bugs,
you can then use usercategories to sort bugs with tags moreinfo and help
to the end of your report page. For more information see
http://www.debian.org/Bugs/server-request#user

Hope this helps

Helmut


-- 
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/20130527080454.ga22...@alf.mars

Re: systemd .service file conversion

[Lucas Nussbaum]

Hi,

On 27/05/13 at 09:13 +0200, Ondřej Surý wrote:
> On Sun, May 26, 2013 at 10:29 PM, Helmut Grohne  wrote:
> 
> > I find it depressing to see four init/rc systems, of which three are
> >  mutually incompatible in every single possible aspect.
> >
> 
> Just my two cents.
> 
> I would be quite happy to write service files for two (systemd, upstart) or
> three (systemd, upstart, openrc) of those in all my packages[*], if it
> stops the endless flamewar here. I would also be happy to have the
> requirement to support two (or three) of them in the Debian policy.
> 
> I know that we would still need to pick-up default, but that might be a
> slightly easier task than to decide the only supported init system.
> 
> * - That's just *6* out of my 70+ package, but I doubt that anybody has too
> much packages with init script to handle (and if that's the case he should
> have co-maintainers).

The point has been made (in [1]) that the problem of supporting several
init implementations is not really with packages providing services, but
with packages strongly tied with the init system.

[1] https://lists.debian.org/debian-devel/2013/05/msg01275.html

However, I would very much welcome a more detailed justification of that
point.

Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130527075128.ga16...@xanadu.blop.info

Re: "Blacklists" in BTS (stopping the trolls and bug machines)

[Vincent Lefevre]

On 2013-05-27 09:04:53 +0200, Ondřej Surý wrote:
> I think I have never said the word "abuse", just "tiresome". The "I see a
> warning from ucf, let's fill a bug on php5-common" finally overflew my cup
> of patience (what is the correct english idiom for this?).

If you think you are distracted by some bug reports, end users
are also distracted by debug messages (which are not clearly
debug messages) in the terminal.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130527081956.ga6...@xvii.vinc17.org

Re: optimizing PNGs

[Helmut Grohne]

Was there any reason for the additional CCs? I saw no Mail-Followup-To
or request for CC, so I dropped them.

On Mon, May 27, 2013 at 09:22:20AM +0200, Mathieu Malaterre wrote:
> Doxygen will use SVG for graph (collaboration, inheritance), SVG is
> AFAIK one of the best possible representation for such information.
> The remainings PNGs are formulas (latex). It would be nice if doxygen
> would use mathml...

I'd like to add some bits from the doxygen point of view. Documentation
packages created using doxygen currently have a number of issues with
respect to size. Some of them are to be addressed soon(TM).

 * Packages shipping .md5 and .map files. Even though these files are
   small, there can be very many of them adding up to the installation
   size for filesystems with large block sizes. These files are used for
   incremental recreation of the documentation, so they are completely
   useless in a binary package. A future version of the doxygen package
   will include a dh_doxygen to aid in getting rid of these files.

 * The use of PNGs for graphs and formulas is unfortunate as has been
   pointed out already. The use of SVG for graphs improves this
   situation. As for formulas, there is support for mathjax. It needs to
   be enabled explicitly with USE_MATHJAX. I do not see mathml as the
   option of choice yet, because it is way harder to implement (unless
   you write the mathml directly in \htmlonly tags).

 * The embedding of jquery and files from doxygen is another story with
   wider implications, but this is rather a small constant per package,
   so the reduction in size is negligible.

Helmut


-- 
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/20130527082656.gb22...@alf.mars

Re: "Blacklists" in BTS (stopping the trolls and bug machines)

[Bastien ROUCARIES]

On Mon, May 27, 2013 at 10:04 AM, Helmut Grohne  wrote:
> On Mon, May 27, 2013 at 09:04:53AM +0200, Ond??ej Surı wrote:
>> I have an idea ??? maybe we could have a pseudo-package called
>> "please-improve" (or whatever name we pick), where people can reassign
>> bugreports which they feel they are unable to handle. This pseudo-bug would
>> be monitored by some virtuous people[*] better in handling poor bugreports
>> and they would work with submitter to improve the bug report, and then
>> reassign it back.
>
> The downside of this approach is that you lose track of the affected
> component and version information (or at least this information is no
> longer mechanically queryable if it is present at all). So instead maybe
> tags could be used to convey this information. Indeed there are already
> some tags that that partly address your needs. For instance, "moreinfo"
> is to mark bugs that lack important information and "help" is a signal
> that you are not going to fix it. To get a cleaner view on your bugs,
> you can then use usercategories to sort bugs with tags moreinfo and help
> to the end of your report page. For more information see
> http://www.debian.org/Bugs/server-request#user

Maybe using affects bug-improve is the way to go.

Bastien
>
> Hope this helps
>
> Helmut
>
>
> --
> 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/20130527080454.ga22...@alf.mars
>


--
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/CAE2SPAbhpTm=8jy0gpedafacjboeq6qjpocxtr4qre5n8v_...@mail.gmail.com

Re: optimizing PNGs

[Mathieu Malaterre]

On Mon, May 27, 2013 at 10:26 AM, Helmut Grohne  wrote:
> Was there any reason for the additional CCs? I saw no Mail-Followup-To
> or request for CC, so I dropped them.
>
> On Mon, May 27, 2013 at 09:22:20AM +0200, Mathieu Malaterre wrote:
>> Doxygen will use SVG for graph (collaboration, inheritance), SVG is
>> AFAIK one of the best possible representation for such information.
>> The remainings PNGs are formulas (latex). It would be nice if doxygen
>> would use mathml...
>
> I'd like to add some bits from the doxygen point of view. Documentation
> packages created using doxygen currently have a number of issues with
> respect to size. Some of them are to be addressed soon(TM).
>
>  * Packages shipping .md5 and .map files. Even though these files are
>small, there can be very many of them adding up to the installation
>size for filesystems with large block sizes. These files are used for
>incremental recreation of the documentation, so they are completely
>useless in a binary package. A future version of the doxygen package
>will include a dh_doxygen to aid in getting rid of these files.

Just for clarity, I believe you mean .md5. .map files are very useful
(HTML usemap attribute), see:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704443


-- 
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/ca+7wuszrapuwkmpnz5gs_rg2s5b1rpntlhjwpa0hy_zpc6x...@mail.gmail.com

Re: [Pkg-virtualbox-devel] virtualbox moved to contrib

[Frank Mehnert]

Hi,

On Saturday 18 May 2013 22:03:08 Felix Geyer wrote:
> On 18.05.2013 20:04, Antonio Terceiro wrote:
> >> However, Watcom is needed only for 16-bit code, and VirtualBox has an
> >> EFI mode.  Would it be possible to restrict it to EFI only in main,
> >> unless the BIOS from contrib is loaded?
> > 
> > If that's possible, I would ask the virtualbox maintainer(s) to please
> > consider this alternative so that we can have virtualbox back in main.
> 
> There are a few problems with this:
> 
> - The EFI images aren't currently built from source as well. However it
> should be possible to do so (see [1]).
> - I'm not sure how well VirtualBox is able to boot common operating system
> with EFI. I (and probably upstream) are already looking forward to heaps
> of "$OS doesn't boot" bug reports.

EFI in VirtualBox has definitely not the same level of stability as the
normal BIOS. I would strongly discourage from publishing an EFI-only
VirtualBox package.

> - It would require even more patching of VirtualBox to default to EFI and
>   display a proper error message when you try to boot a VM in BIOS mode and
>   it's not available.
> - The VirtualBox maintainers (= me at the moment) don't even have time to
>   properly maintain the VirtualBox package as it is. So someone else would
>   have to join pkg-virtualbox and do the work.

Kind regards,

Frank
-- 
Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany

Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher


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

Re: "Blacklists" in BTS (stopping the trolls and bug machines)

[Ondřej Surý]

On Mon, May 27, 2013 at 10:04 AM, Helmut Grohne  wrote:

> On Mon, May 27, 2013 at 09:04:53AM +0200, Ond??ej Surı wrote:
> > I have an idea ??? maybe we could have a pseudo-package called
> > "please-improve" (or whatever name we pick), where people can reassign
> > bugreports which they feel they are unable to handle. This pseudo-bug
> would
> > be monitored by some virtuous people[*] better in handling poor
> bugreports
> > and they would work with submitter to improve the bug report, and then
> > reassign it back.
>
> The downside of this approach is that you lose track of the affected
> component and version information (or at least this information is no
> longer mechanically queryable if it is present at all). So instead maybe
> tags could be used to convey this information. Indeed there are already
> some tags that that partly address your needs. For instance, "moreinfo"
> is to mark bugs that lack important information and "help" is a signal
> that you are not going to fix it. To get a cleaner view on your bugs,
> you can then use usercategories to sort bugs with tags moreinfo and help
> to the end of your report page. For more information see
> http://www.debian.org/Bugs/server-request#user


That's useless since simple tagging as +moreinfo help would just mean that
nobody would take care of those bugs, and they would linger the
indefinitely. I could just close the bugs and the effect would be same.

I like the idea from Bastien:

affects  bug-improve

or even better

reassign  bug-improve
affects  

But we still need the bugsquash team to be formed.

O.
-- 
Ondřej Surý 

Re: "Blacklists" in BTS (stopping the trolls and bug machines)

[Ondřej Surý]

On Mon, May 27, 2013 at 10:19 AM, Vincent Lefevre 
wrote:
>
> On 2013-05-27 09:04:53 +0200, Ondřej Surý wrote:
> > I think I have never said the word "abuse", just "tiresome". The "I see
a
> > warning from ucf, let's fill a bug on php5-common" finally overflew my
cup
> > of patience (what is the correct english idiom for this?).
>
> If you think you are distracted by some bug reports, end users
> are also distracted by debug messages (which are not clearly
> debug messages) in the terminal.


You are most welcome to come, join the packaging team(s) and help triage
those or any other bugs. (And I do mean it for real and not as sarcasm.)

BTW there's around 2000 open bugs marked as moreinfo, the oldest is dated
Sun, 29 Mar 1998 21:03:03 UTC.

O.
--
Ondřej Surý 

Re: "Blacklists" in BTS (stopping the trolls and bug machines)

[Timo Juhani Lindfors]

Ondřej Surý  writes:
> affects  bug-improve

I'd put such pseudo packages to a separate namespace. Some package
might, while unlikely, be called "bug-improve" in the future.


--
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/844ndog2yx@sauna.l.org

Re: systemd .service file conversion

[Ondřej Surý]

Well,

each init system has it's proponents, so they can provide support (in form
of patches) for those tightly-tied package.

E.g. adopt an approach similar to our archs, setup some criteria[*] for
supporting the init system and either it can keep up and fullfil the
criteria or it won't and we drop the support for that particular init
system.

I guess both systemd and upstart would be able to fill the criteria just
fine. If anybody wants OpenRC, then fine, but provide the support, time and
energy to meet the criteria.

* - this needs to be defined, but I imagine something like this:
- 95% of native init configs in Packages with Priority: standard
- 60% of native init scripts in Packages with Priority: optional
- support for udev/dbus/whatever/...

O.


On Mon, May 27, 2013 at 9:51 AM, Lucas Nussbaum  wrote:

> Hi,
>
> On 27/05/13 at 09:13 +0200, Ondřej Surý wrote:
> > On Sun, May 26, 2013 at 10:29 PM, Helmut Grohne 
> wrote:
> >
> > > I find it depressing to see four init/rc systems, of which three are
> > >  mutually incompatible in every single possible aspect.
> > >
> >
> > Just my two cents.
> >
> > I would be quite happy to write service files for two (systemd, upstart)
> or
> > three (systemd, upstart, openrc) of those in all my packages[*], if it
> > stops the endless flamewar here. I would also be happy to have the
> > requirement to support two (or three) of them in the Debian policy.
> >
> > I know that we would still need to pick-up default, but that might be a
> > slightly easier task than to decide the only supported init system.
> >
> > * - That's just *6* out of my 70+ package, but I doubt that anybody has
> too
> > much packages with init script to handle (and if that's the case he
> should
> > have co-maintainers).
>
> The point has been made (in [1]) that the problem of supporting several
> init implementations is not really with packages providing services, but
> with packages strongly tied with the init system.
>
> [1] https://lists.debian.org/debian-devel/2013/05/msg01275.html
>
> However, I would very much welcome a more detailed justification of that
> point.
>
> Lucas
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/20130527075128.ga16...@xanadu.blop.info
>
>


-- 
Ondřej Surý 

Re: optimizing PNGs

[Helmut Grohne]

On Mon, May 27, 2013 at 10:35:48AM +0200, Mathieu Malaterre wrote:
> On Mon, May 27, 2013 at 10:26 AM, Helmut Grohne  wrote:
> >  * Packages shipping .md5 and .map files. Even though these files are
> >small, there can be very many of them adding up to the installation
> >size for filesystems with large block sizes. These files are used for
> >incremental recreation of the documentation, so they are completely
> >useless in a binary package. A future version of the doxygen package
> >will include a dh_doxygen to aid in getting rid of these files.
> 
> Just for clarity, I believe you mean .md5. .map files are very useful
> (HTML usemap attribute), see:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704443

You are correct here. Thanks for pointing out.

While digging into this, I also discovered that there are a number of
duplicate files, that could be reduced using hard links[1] without much
effort. For example, in case of activiz.net-doc[2] 2% of the files can
be replaced by hard links. For vtk-doc[3] this amounts to 13% of the
files. Other large documentation packages are likely affected in a
similar way. The files typically affected are .svg and .map files. Even
though this certainly hits small files, this can reduce the installation
size measurably (for some filesystems).

Helmut

[1] http://wiki.debian.org/dedup.debian.net#Within_a_single_binary_package
rdfind also support -makehardlinks true
[2] http://dedup.debian.net/binary/activiz.net-doc
[3] http://dedup.debian.net/binary/vtk-doc


-- 
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/20130527101927.ga10...@alf.mars

Re: [Pkg-virtualbox-devel] virtualbox moved to contrib

[Holger Levsen]

Hi,

On Montag, 27. Mai 2013, Frank Mehnert wrote:
> EFI in VirtualBox has definitely not the same level of stability as the
> normal BIOS. I would strongly discourage from publishing an EFI-only
> VirtualBox package.

so making it the default and moving virtualbox back to main would give this 
instability issues more exposure and thus hopefully more bugfixing?

A virtualbox which relies on non-free components is definitly also not so 
useful.


cheers,
Holger


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

Re: [Pkg-virtualbox-devel] virtualbox moved to contrib

[Frank Mehnert]

On Monday 27 May 2013 12:45:27 Holger Levsen wrote:
> On Montag, 27. Mai 2013, Frank Mehnert wrote:
> > EFI in VirtualBox has definitely not the same level of stability as the
> > normal BIOS. I would strongly discourage from publishing an EFI-only
> > VirtualBox package.
> 
> so making it the default and moving virtualbox back to main would give this
> instability issues more exposure and thus hopefully more bugfixing?
> 
> A virtualbox which relies on non-free components is definitly also not so
> useful.

Just read the discussion. I wouldn't argue again and again.

Kind regards,

Frank
-- 
Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany

Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher


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

Re: [Pkg-virtualbox-devel] virtualbox moved to contrib

[Wouter Verhelst]

On 27-05-13 13:30, Frank Mehnert wrote:
> On Monday 27 May 2013 12:45:27 Holger Levsen wrote:
>> On Montag, 27. Mai 2013, Frank Mehnert wrote:
>>> EFI in VirtualBox has definitely not the same level of stability as the
>>> normal BIOS. I would strongly discourage from publishing an EFI-only
>>> VirtualBox package.
>>
>> so making it the default and moving virtualbox back to main would give this
>> instability issues more exposure and thus hopefully more bugfixing?
>>
>> A virtualbox which relies on non-free components is definitly also not so
>> useful.
> 
> Just read the discussion. I wouldn't argue again and again.

Pointers to said discussion would be helpful.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/51a34926.3080...@debian.org

Re: Debian development and release: always releasable (essay)

[Andreas Tille]

Hi,

On Sun, May 26, 2013 at 03:10:07PM +0200, Holger Levsen wrote:
> Hi,
> 
> On Samstag, 25. Mai 2013, Petter Reinholdtsen wrote:
> > Actually, I believe there is.  The Debian Edu blend contain the
> > education-main-server task and metapackage, which include a Kerberos
> > KDC.  It also contain the LDAP server as KDC backend storage and
> > user/group/etc lookup.
> 
> there is also the Debian-LAN which is described as "The goal of Debian-LAN is 
> to make setting up a local network with centralized user and machine 
> management, intranet, etc. as easy as possible in Debian."
> 
> see ://lists.debian.org/20120408083121.GB9680@flashgordon

If I where Andreas Mundt I would try to do this inside the Debian
Enterprise effort.  While there is barely any traffic on this list you
just need to start with such an effort somehow and IMHO the topic does
fit.

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/20130527121417.gc16...@an3as.eu

Re: Is there an active Debian mactel team?

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 23/05/2013 09:42, Thibaut Paumard a écrit :
> 
> Dear all,
> 
> Despite all the efforts from many people, it's still quite
> difficult to get a fully functional Debian system on certain Apple
> hardware.
> 
> I have been looking for a team I could join to discuss and improve
> the situation, but I could not find one. There are pages on the
> wiki, there is a debian-mactel channel on OFTC, but no alioth
> project and no mailing list. Is there something I missed?

Hi,

Apperently, I did not miss anything. I therefore created a project on
Alioth ("Debian Mactel", UNIX name pkg-mactel):

 https://alioth.debian.org/projects/pkg-mactel/

I hereby invite anyone interested in joining this project.

Kind regards, Thibaut.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJRo0qGAAoJEJOUU0jg3ChA/6QQAMlbiWZAQSe/4IXwQgim1lQ9
p2jdEqE0xtB3bfokfIjt/1pgm1esN6ZfEC78W90C7b1llEZEdUAo0PevDl+eLpHS
1u/oj+pRCx41b4yFO8ZQGUW7utD1piC+Ko5uFRoZSORU5kIl5xpQb7Y/4TkKywqB
jfUC/kWZ15OlI/jbtHEC7FWVulFc8HZ6Y9hsD3mHbPy8T7BlTiq7HR+RIon51kyt
qwXnkKpLSbG4Cx20LWdZgyZSmVbbddViVaYaZzH3k4lueYsqHWNlpvw4h1pvtRtY
gLCm0Q8bsE3AO4Txn5zdzKWIjh4isPfxZESTRc0KKMxhcjG1eO1Vnt9uPoh4cLWu
2fWnaMR1vImU1GATSHFqz3177Sy4zSEHyQst4E+It9VYzSxSCdxxBGMo7u7PTE7i
xMIzTl048mJsOQ2SR1CLZLL5hw0aFU7HK0+NBCycGn/zsvcGnYncBp7DNAFd7+/T
J/L/6SfXxSOumzGX3WJKFz2D0z+hqKwbDTT8ZFq5M43vVustuoeyjuSLINGfvsc+
kpGgjOrXQtQARjOguYRaQEJaCm531UoA/5mnOz74qJjivf3xHsv/FDhEhYPdy0PH
ZAfOQ1cP6vl0FRNvEI6Z5mnx/i+DZNq94dffM69j492YOv/rxfnT9yfEn6zCvVVd
4qjEWrQSdsVyKi/TBS4v
=OSoT
-END PGP SIGNATURE-


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

Re: optimizing PNGs

[Paul Wise]

On Mon, May 27, 2013 at 6:19 PM, Helmut Grohne wrote:

> While digging into this, I also discovered that there are a number of
> duplicate files, that could be reduced using hard links[1] without much
> effort. For example, in case of activiz.net-doc[2] 2% of the files can
> be replaced by hard links. For vtk-doc[3] this amounts to 13% of the
> files. Other large documentation packages are likely affected in a
> similar way. The files typically affected are .svg and .map files. Even
> though this certainly hits small files, this can reduce the installation
> size measurably (for some filesystems).

In megaglest we replace duplicate files with symlinks using these commands:

# Replace duplicate files with symlinks
rdfind -outputname /dev/null -makesymlinks true debian/megaglest-data/
# Fix those symlinks to make them relative
symlinks -r -s -c debian/megaglest-data/


-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: [Pkg-virtualbox-devel] virtualbox moved to contrib

[Paul Wise]

On Mon, May 27, 2013 at 7:53 PM, Wouter Verhelst wrote:

> Pointers to said discussion would be helpful.

http://bugs.debian.org/691148

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#710013: ITP: libgrip -- multitouch gesture library for GTK

[Stephen M. Webb]

Package: wnpp
Severity: wishlist
Owner: "Stephen M. Webb" 

* Package name: libgrip
  Version : 0.3.6
  Upstream Author : Canonical Ltd.
* URL : https://launchpad.net/libgrip
* License : LGPL v2.1, LGPL v3
  Programming Lang: C
  Description : multitouch gesture library for GTK

This is a GTK extension library that provides a multi-touch gesture API.  It is 
currently used by optional extensions to
eog and evince.


-- 
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/51a365ad.8070...@bregmasoft.ca

Re: "Blacklists" in BTS (stopping the trolls and bug machines)

[Bas Wijnen]

On Mon, May 27, 2013 at 09:04:53AM +0200, Ondřej Surý wrote:
> On Sat, May 25, 2013 at 8:02 PM, Russ Allbery  wrote:
> > He still files all upstream bugs with Debian, but I can't throw stones
> > there;

I do not think this is wrong.  In fact, one of the reasons I like Debian, is
that I can report bugs in a uniform way and the maintainer will (well, should
at least) take care of handling communication with upstream where appropriate.

If it would be inappropriate to file upstream bugs with Debian, reportbug
should be changed to complain if you try to add the upstream tag.  It doesn't,
and in my opinion it shouldn't.  Forwarding stuff upstream is actually part of
your task as a package maintainer.

> > I tend to do the same thing myself, since Debian has such a nice and
> > consistent bug reporting interface and upstream's usually... isn't.  :)

That too. :-)  And in many cases they require you to subscribe to a mailinglist
while you only want to see replies to your own report, not follow the
development of the program.  This requirement is acceptable for the maintainer
of the Debian package, but not for someone who thinks "this can be better,
perhaps they didn't think about it".

> > He files lots and lots of minor/wishlist bugs, but that isn't abuse.  He's
> > one of the few people who regularly files bugs when he finds unclear or
> > confusing documentation, and while that results in a lot of small bugs
> > (and a lot of bugs that are really upstream bugs), I think that's also a
> > valuable *type* of bug that frequently doesn't get enough attention.

I agree.  On a completely different level, those bugs are also often quite easy
to fix (taking mostly time, not much skill), and therefore can be used to
attract new developers to a project.

> The "I see a warning from ucf, let's fill a bug on php5-common" finally
> overflew my cup of patience.

Especially with simple wishlist bugs, the submitter doesn't want to dig deep
into the package to see what the problem really is.  In a case like this, the
maintainer should reassign the bug to the package that causes it, just like
they should forward it upstream if appropriate.  This is a similar action,
which as I wrote I consider part of the task of a package maintainer.

> This might be similar to what I have seen in Launchpad – there's a bugsquad
> team that can handle all bugreports in just any package[1][2].

We have a pretty good NMU system, which lets any DD handle bugs in any package.
There's nothing wrong with preparing an NMU for a wishlist bug.  So we already
have that team.  Perhaps the QA team is even closer to what you mean, but they
always say that any DD is in the QA team, so there isn't really a difference.
;-)  But as you write, most people will not fix (or ask for more info on)
wishlist bugs in other people's packages.

On Mon, May 27, 2013 at 11:46:05AM +0200, Ondřej Surý wrote:
> > If you think you are distracted by some bug reports, end users
> > are also distracted by debug messages (which are not clearly
> > debug messages) in the terminal.

And speaking for me personally, even if they are clearly debug messages, I
still consider it a bug that they were enabled for a release.  I don't think
I've ever reported such a thing, but I might do that.  It's one of those things
which is trivial to fix when you're preparing a release anyway, and makes the
package a tiny bit better if done right.

> BTW there's around 2000 open bugs marked as moreinfo, the oldest is dated
> Sun, 29 Mar 1998 21:03:03 UTC.

For moreinfo bugs, you are not considered a bad maintainer if you send a "I
will close this if you don't reply"-response after some time and then do that
after some more waiting.  (Where "some time" and "some more" << 15 years.)

Thanks,
Bas


-- 
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/20130527142105.ga11...@fmf.nl

Accurate diagnostics

[Ben Hutchings]

On Mon, 2013-05-27 at 10:19 +0200, Vincent Lefevre wrote:
> On 2013-05-27 09:04:53 +0200, Ondřej Surý wrote:
> > I think I have never said the word "abuse", just "tiresome". The "I see a
> > warning from ucf, let's fill a bug on php5-common" finally overflew my cup
> > of patience (what is the correct english idiom for this?).
> 
> If you think you are distracted by some bug reports, end users
> are also distracted by debug messages (which are not clearly
> debug messages) in the terminal.

Worse are warnings that always appear because either an application
really is doing something wrong (many Gtk apps trigger such warnings) or
the warning condition is wrong.  The typical response to a report of
such a bug will be 'oh, that's harmless', but then if a user ignored
warnings for some time before reporting a bug the reponse will be 'why
did you ignore that?!'

We should be careful to give accurate diagnostic messages; otherwise we
will train users to ignore them.  And that can certainly lead to data
loss.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.


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

Re: systemd .service file conversion

[brian m. carlson]

On Mon, May 27, 2013 at 08:38:44AM +0200, Helmut Grohne wrote:
> On Sun, May 26, 2013 at 10:27:53PM +, brian m. carlson wrote:
> > At the risk of adding another level of indirection, we could add a
> > meta-init format that can generate an appropriate file for any of these.
> 
> Are you aware of http://wiki.debian.org/MetaInit (packages metainit and
> dh-metainit)? That work was started like eight years ago. Unfortunately
> it didn't take off yet. The only package using it is infon.

I was not.

> > A meta-init format would make everyone equally happy (or miserable,
> > depending on your point of view), which may be the best way to solve the
> > problem.  I fear that consolidation of interfaces is unlikely to occur.
> 
> As far as I can tell Debian simply lacks the resources to do that. Maybe
> Joachim Breitner can shed some light on this?

I'm happy to work on this if need be.

> Unless some consolidation of interfaces is going to happen, Debian will
> simply be unable to support multiple init systems natively.

Yes, it sounds like the issue is less of the init scripts themselves,
and more how to interact with the init systems (the interfaces).
Forcing everybody to use the same init system is going to make a lot of
people very unhappy, as we've seen.

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


signature.asc
Description: Digital signature

Re: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon

[Daniel Walrond]

On Wed, May 22, 2013 at 02:16:34PM -0700, Russ Allbery wrote:
> Daniel Walrond  writes:
> 
> > As per policy 10.9 - Permissions and owners[0], opensmtpd requires
> > some system users for running non-root-privileged processes. I propose
> > to user the following dynamic accounts; opensmtpd, opensmtpq, opensmtpf.
> 
> We currently have no good policy about how to name system users, but
> despite that I personally would recommend against using simple
> alphanumeric usernames like those.  (They are longer than eight
> characters, which avoids some local namespaces, but not all.)
> 
> There are two conventions that other packages have used to make it less
> likely that system accounts will conflict with local usernames:
> 
> * Append "Debian-" to the username, as in Debian-opensmtpd
> * Append an underscore, as in _opensmtpd
> 
> I personally mildly prefer the latter just because it's simple, although
> it isn't as informative or robust against any namespace issue.  Note that
> you will have to pass --force-badname to adduser to let you use an
> underscore in the name.

The upstream package defaults to _smtpd since all the daemons in OpenBSD
start with a "_". It seems like a good convention to avoid local
namespace clashes, although I haven't seen any package within Debian
using it. The regex in a default install is ^[a-z][-a-z0-9_]*\$, so I
think it's best to stick within that.

Thanks for the input, I'll stick with opensmtpd.


Dan


-- 
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/20130527174221.ga3...@sumdoave.com

FW: problem with amixer

[Juan Diego Tortul Batistuta]

Hi I have no sound, have a problem with amixer in (Debian 7 Gnome);

in booting the error is:

amixer : amixer hw : 0 : load error : invalid argument


hardware:

user@debian:~$ cat /proc/asound/modules
 0 snd_hda_intel

user@debian:~$ cat /proc/asound/cards
 0 [NVidia ]: HDA-Intel - HDA NVidia
  HDA NVidia at 0xfe024000 irq 22

user@debian:~$ lshw -C MULTIMEDIA
WARNING: you should run this program as super-user.
  *-multimedia UNCLAIMED  
   description: Audio device
   product: MCP61 High Definition Audio
   vendor: NVIDIA Corporation
   physical id: 5
   bus info: pci@:00:05.0
   version: a2
   width: 32 bits
   clock: 66MHz
   capabilities: cap_list
   configuration: latency=0 maxlatency=5 mingnt=2
   resources: memory:fe024000-fe027fff
WARNING: output may be incomplete or inaccurate, you should run this program as 
super-user.


user@debian:~$ lspci -k
00:00.0 RAM memory: NVIDIA Corporation MCP61 Host Bridge (rev a1)
Subsystem: Giga-byte Technology Device 5001
00:01.0 ISA bridge: NVIDIA Corporation MCP61 LPC Bridge (rev a2)
Subsystem: Giga-byte Technology Device 0c11
00:01.1 SMBus: NVIDIA Corporation MCP61 SMBus (rev a2)
Subsystem: Giga-byte Technology Device 0c11
Kernel driver in use: nForce2_smbus
00:01.2 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a2)
Subsystem: Giga-byte Technology Device 0c11
00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a3)
Subsystem: Giga-byte Technology Device 5004
Kernel driver in use: ohci_hcd
00:02.1 USB controller: NVIDIA Corporation MCP61 USB 2.0 Controller (rev a3)
Subsystem: Giga-byte Technology Device 5004
Kernel driver in use: ehci_hcd
00:04.0 PCI bridge: NVIDIA Corporation MCP61 PCI bridge (rev a1)
00:05.0 Audio device: NVIDIA Corporation MCP61 High Definition Audio (rev a2)
Subsystem: Giga-byte Technology Device a002
Kernel driver in use: snd_hda_intel
00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2)
Subsystem: Giga-byte Technology Device e000
Kernel driver in use: forcedeth
00:08.0 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2)
Subsystem: Giga-byte Technology Device b002
Kernel driver in use: sata_nv
00:08.1 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2)
Subsystem: Giga-byte Technology Device b002
Kernel driver in use: sata_nv
00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce 7025 / 
nForce 630a] (rev a2)
Subsystem: Giga-byte Technology Device d000
Kernel driver in use: nouveau
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor 
HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address 
Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM 
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor 
Miscellaneous Control
Kernel driver in use: k10temp
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link 
Control


  

Re: "Blacklists" in BTS (stopping the trolls and bug machines)

[Paul Gevers]

Hi

>> BTW there's around 2000 open bugs marked as moreinfo, the oldest is dated
>> Sun, 29 Mar 1998 21:03:03 UTC.
> 
> For moreinfo bugs, you are not considered a bad maintainer if you send a "I
> will close this if you don't reply"-response after some time and then do that
> after some more waiting.  (Where "some time" and "some more" << 15 years.)

And for everybody that hasn't learned it yet (I just recently did),
replying to a bug does NOT send an e-mail to the original reporter. I
now have several moreinfo bugs, that have in fact not requested more
info to the right person. Maybe that is the case for more people.

Paul



signature.asc
Description: OpenPGP digital signature

Re: optimizing PNGs

[Russ Allbery]

Helmut Grohne  writes:

> I'd like to add some bits from the doxygen point of view. Documentation
> packages created using doxygen currently have a number of issues with
> respect to size. Some of them are to be addressed soon(TM).

>  * Packages shipping .md5 and .map files. Even though these files are
>small, there can be very many of them adding up to the installation
>size for filesystems with large block sizes. These files are used for
>incremental recreation of the documentation, so they are completely
>useless in a binary package. A future version of the doxygen package
>will include a dh_doxygen to aid in getting rid of these files.

Yes, yes, please!  That would make my life so much better for several of
my packages.

>  * The embedding of jquery and files from doxygen is another story with
>wider implications, but this is rather a small constant per package,
>so the reduction in size is negligible.

I've been replacing the copy of jquery with a symlink to the one shipped
in Debian and adding a dependency on that package, and some quick testing
didn't turn up anything that broke.  If that strategy works, maybe
dh_doxygen can do that as well?

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

Re: Accepted wdm 1.28-13+deb7u1 (source i386)

[Alexander Benjik]

Unsubscribe
--
Diese Nachricht wurde von meinem Android Mobiltelefon versandt.



Agustin Martin Domingo  schrieb:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 23 May 2013 20:45:46 +0200
Source: wdm
Binary: wdm
Architecture: source i386
Version: 1.28-13+deb7u1
Distribution: stable
Urgency: low
Maintainer: Debian QA Group 
Changed-By: Agustin Martin Domingo 
Description:
wdm - WINGs Display Manager - an xdm replacement with a WindowMaker loo
Closes: 707231
Changes:
wdm (1.28-13+deb7u1) stable; urgency=low
.
* QA upload.
* wdm.pam: Ignore pam_selinux.so failures when the module does not
exist (e.g. on architectures without SE Linux support like
non-linux) instead of requiring it. Thanks Laurent Bigonville for
bug report and proposed change (Closes: #707231).
Checksums-Sha1:
5b4a8cb3f8df4cc511432017ebddf81a7dcf9a35 1472 wdm_1.28-13+deb7u1.dsc
f900cd2c211023b0323c0fe1ec5d17d10adfe055 68692 wdm_1.28-13+deb7u1.debian.tar.gz
c0f58dae3a4a23d97a9aee23a81ead3b4152f0d3 338442 wdm_1.28-13+deb7u1_i386.deb
Checksums-Sha256:
33e3bff58eb3ef8b40e893ff17e080d87e8c662ba67d2a42231b1aa7a92bf2c9 1472 
wdm_1.28-13+deb7u1.dsc
a6d96b55861a3ef754076602cfbefa2c28a6861ffc2df9a51fe600e84413b6db 68692 
wdm_1.28-13+deb7u1.debian.tar.gz
1708e624d95824900eaad31043733fa56c39d652848b4847edbca52b82c7f665 338442 
wdm_1.28-13+deb7u1_i386.deb
Files:
d22d56f3e79b53d8c82f5c1ed25b11b9 1472 x11 optional wdm_1.28-13+deb7u1.dsc
8059a44f03f796981aea07a158c84b00 68692 x11 optional 
wdm_1.28-13+deb7u1.debian.tar.gz
42e977d07ab3936a266e6667a205713d 338442 x11 optional wdm_1.28-13+deb7u1_i386.deb

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

iD8DBQFRnmVmTShHqj72DpwRAuVqAKCeDG1a3qfa5yA4Oiq0VM+67U8cgACfcG6Z
COxmsosSu5pRFm9K0W6ehFs=
=5IHI
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to debian-changes-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ugmir-0005s7...@franck.debian.org

Re: systemd .service file conversion

[Russ Allbery]

Игорь Пашев  writes:
> 2013/5/27 brian m. carlson :

>> At the risk of adding another level of indirection, we could add a
>> meta-init format that can generate an appropriate file for any of
>> these.

> http://xkcd.com/927/

Also:

"All problems in computer science can be solved by another level of
indirection" -- David Wheeler

"...except for the problem of too many layers of indirection." -- Kevlin
Henney

which I suspect is what prompted Brian's phrasing in the original
message.  :)

-- 
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/8738t846ry@windlord.stanford.edu

Re: systemd .service file conversion

[Russ Allbery]

Ondřej Surý  writes:

> I would be quite happy to write service files for two (systemd, upstart)
> or three (systemd, upstart, openrc) of those in all my packages[*], if
> it stops the endless flamewar here. I would also be happy to have the
> requirement to support two (or three) of them in the Debian policy.

+1

However, there is a legitimate concern that I'm not likely to personally
test more than one, maybe two, of the service files, since I'm probably
going to find that I have a personal favorite and end up using that on
most or all of my systems.

In general, whichever one we pick as the installation default is probably
going to get the most testing.  This isn't a problem for things like MTAs,
which are fairly self-contained; Postfix is quite well-supported in Debian
despite having Exim as the default.  But for init systems, where the
support is spread over a large number of packages, the situation is
trickier.

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

Re: Bug#666490: O: svgalib -- console SVGA display libraries

[Moritz Mühlenhoff]

On Mon, May 13, 2013 at 07:30:20PM +0200, Stephen Kitt wrote:
> Hi,
> 
> On Sun, Apr 01, 2012 at 02:59:24AM +0100, Ben Hutchings wrote:
> > Thanks for your work, but isn't it time we quietly got rid of this
> > library?  Video memory and mode setting should be managed by the kernel,
> > not by applications.  It's bad enough that we had the X server doing
> > this for years (and still do on some hardware).

I agree.
 
> I've looked into this; svgalib's reverse dependencies are:
> * bochs (bochs-svga)
> * gnuboy (gnuboy-svga)
> * lcdproc (no svgalib-specific package)
> * links2 (no svgalib-specific package)
> * mplayer (no svgalib-specific package)
> * qcam (no svgalib-specific package)
> * spectemu (spectemu-svga)
> * synaesthesia (no svgalib-specific package)
> * thrust (no svgalib-specific package)
> * tmview (dvisvga)
> * zgv (no svgalib-specific package)
> 
> Apart from mplayer and zgv, all of these rebuild fine without
> libsvga1-dev; they can use X and some can use fb (I can provide
> patches of course and NMU where necessary). mplayer FTBFS anyway
> because of changes in liblivemedia (#708140). zgv only builds a
> svgalib-based binary; it can in theory be built with SDL instead but
> that fails. All the svgalib-specific packages have low popcon scores.

I'll file bugs soon and coordinate the removal.

Cheers,
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/20130527182957.GA6134@pisco.westfalen.local

Forming a Debian bugsquad team (Was: "Blacklists" in BTS (stopping the trolls and bug machines))

[Ondřej Surý]

If we are to form the Debian bugsquad team similar to Ubuntu bugsquad team,
the main two questions would be:

1. As a Debian Developer/Maintainer would you be thankful for other people
to come and help with bugs in your package.
2. Can we find enough volunteers to form such team?

The idea would be to have a team of pasionate people who would constantly
try to improve Debian as a whole and they would help the maintainers to
triage bugs.

The criteria for choosing bugs to help with might be:
1. the 'help' tag
2. the 'moreinfo' tag
3. the age of the bug
4. bugs without an answer
5. special user-tag, f.e. 'bugsq...@lists.alioth.debian.org'

--

On Mon, May 27, 2013 at 4:21 PM, Bas Wijnen  wrote:

> On Mon, May 27, 2013 at 09:04:53AM +0200, Ondřej Surý wrote:
> > On Sat, May 25, 2013 at 8:02 PM, Russ Allbery  wrote:
> > > He still files all upstream bugs with Debian, but I can't throw stones
> > > there;
>

I think it's ok to fill upstream bugs in Debian BTS, but I almost always
reply with "here's the upstream bugzilla, please be so kind and fill the
bug there, it will be much more efficient".


> > > He files lots and lots of minor/wishlist bugs, but that isn't abuse.
>  He's
> > > one of the few people who regularly files bugs when he finds unclear or
> > > confusing documentation, and while that results in a lot of small bugs
> > > (and a lot of bugs that are really upstream bugs), I think that's also
> a
> > > valuable *type* of bug that frequently doesn't get enough attention.
>
> I agree.  On a completely different level, those bugs are also often quite
> easy
> to fix (taking mostly time, not much skill), and therefore can be used to
> attract new developers to a project.


Where are these developers you are talking about? Shove them to PHP BTS to
triage the bugs.


>  > The "I see a warning from ucf, let's fill a bug on php5-common" finally
> > overflew my cup of patience.
>
> Especially with simple wishlist bugs, the submitter doesn't want to dig
> deep
> into the package to see what the problem really is.  In a case like this,
> the
> maintainer should reassign the bug to the package that causes it, just like
> they should forward it upstream if appropriate.  This is a similar action,
> which as I wrote I consider part of the task of a package maintainer.


Some packages are easier to maintain, some are much harder. So it might be
easier for you to say than f.e. for me with php, rails, bdb and some other
packages in my unfortunate portfolio. How many security bugs did you have
in your packages in squeeze? Please understand that our perspectives and
experiences with Debian package maintenance might wildly differ.

> This might be similar to what I have seen in Launchpad – there's a
> bugsquad
> > team that can handle all bugreports in just any package[1][2].
>
> We have a pretty good NMU system, which lets any DD handle bugs in any
> package.
> There's nothing wrong with preparing an NMU for a wishlist bug.  So we
> already
> have that team.


No, we don't have that team. Most if not all people will NMU only for
things they care about. I did a lot of NMUs when I planned Berkeley DB
transition.


> Perhaps the QA team is even closer to what you mean, but they
> always say that any DD is in the QA team, so there isn't really a
> difference.
>

No, the QA team is not even close.


> But as you write, most people will not fix (or ask for more info on)
> wishlist bugs in other people's packages.


I am talking about group of people which would help triage the bugs on
regular basis, and would help maintainers who cannot find more active
maintainers to the team even though the RFH bug is open for more than a
year. (And I am thankful for every little contribution I receive)


> On Mon, May 27, 2013 at 11:46:05AM +0200, Ondřej Surý wrote:
> > > If you think you are distracted by some bug reports, end users
> > > are also distracted by debug messages (which are not clearly
> > > debug messages) in the terminal.
>
> And speaking for me personally, even if they are clearly debug messages, I
> still consider it a bug that they were enabled for a release.  I don't
> think
> I've ever reported such a thing, but I might do that.  It's one of those
> things
> which is trivial to fix when you're preparing a release anyway, and makes
> the
> package a tiny bit better if done right.


I sent the original email asking on advice how to make my job somehow
easier, because sometimes it's too much and I want to prevent  my burnout
and burntout of some other fellow Debian Developers.

Do you understand that your email saying "don't complain, it's your job"
isn't very helpful?

O.
-- 
Ondřej Surý 

Re: Forming a Debian bugsquad team (Was: "Blacklists" in BTS (stopping the trolls and bug machines))

[Arno Töll]

Hi,

On 27.05.2013 21:01, Ondřej Surý wrote:
> 1. As a Debian Developer/Maintainer would you be thankful for other people
> to come and help with bugs in your package.

I very much doubt, there is a maintainer in Debian who discourages other
people to triage bugs of their own packages. So yes, I suppose this is
highly appreciated.

> 2. Can we find enough volunteers to form such team?

That's the actual question. You know, if people would like it to deal
with certain bugs (and bug reporters) we would not need find someone
else doing it on your behalf.

Having that said, there are more jobs that team could take over, like
handling bugs against "general", or against in-existing packages.

Yet I don't think that would be a highly appealing job, but I'm more
than happy if others would like to do it.

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: using upstart in Debian

[Nikolaus Rath]

Wouter Verhelst  writes:
> On 26-05-13 15:11, Holger Levsen wrote:
>> Hi,
>> 
>> On Samstag, 25. Mai 2013, Nikolaus Rath wrote:
>>> For example: after some intense studying, I now fully understand why
>>> declaring a new upstart job C that depends on existing jobs A and B
>>> ("start on job-a-did-its-thing AND job-b-did-its-thing") may prevent the
>>> start of job A (cf
>>> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/964207). However, I
>>> still consider it confusing and at least questionable design that adding a
>>> new job can prevent an existing job from starting even though they do not
>>> conflict in any way.
>> 
>> WHAT?!? if that's true then I for sure know what I won't let near my 
>> systems! 
>> That's rather horrible. Thanks for the info!
>
> Reading the bug, what Nikolaus fails to mention is that the way the
> event handling happens, this really becomes a _circular_ dependency
> unless the --no-wait option is specified (IIUC)

The hang is because of a loop, yes, but this loop doesn't exist in the
actual dependencies:

gdm depends on mountall (via mounted event) and dbus
dbus depends on mountall

There should be no problem at all to satisfy these dependencies and boot
the system. However, due to the event-based way upstart is designed, it
doesn't work like that: if mountall emits its events without --no-wait,
then the emitting the mounted event will "latch" and only return once
gdm is started. gdm, however, still waits for dbus, and the boot hangs.

The only way to avoid this (at least at the time I reported the bug),
would have been to recompile mountall to emit events with --no-wait (but
I'm not sure what other unintended consequences that would have had).

As I said, there isn't a bug anywhere here. Once you understand what's
going on, this all makes sense. But I don't consider this a very good
design.


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
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/874ndontbu@vostro.rath.org

Re: "Blacklists" in BTS (stopping the trolls and bug machines)

[Christian PERRIER]

Quoting Ondřej Surý (ond...@sury.org):

> You are most welcome to come, join the packaging team(s) and help triage
> those or any other bugs. (And I do mean it for real and not as sarcasm.)
> 
> BTW there's around 2000 open bugs marked as moreinfo, the oldest is dated
> Sun, 29 Mar 1998 21:03:03 UTC.


While I could still manage to deal with bugs in the samba package,
bugs that were tagged "moreinfo" more than a few years ago have been
unilateraly closed by /me over time.

Being somehow "aggressive" with bug reports doesn't hurt. Indeed it
benefits the project as a whole, because it tends to keep opened only
those bugs that have a small chance to see someone working on them in
a foreseeable future.




signature.asc
Description: Digital signature

Re: systemd .service file conversion

[Ondřej Surý]

On Mon, May 27, 2013 at 8:30 PM, Russ Allbery  wrote:

> Ondřej Surý  writes:
>
> > I would be quite happy to write service files for two (systemd, upstart)
> > or three (systemd, upstart, openrc) of those in all my packages[*], if
> > it stops the endless flamewar here. I would also be happy to have the
> > requirement to support two (or three) of them in the Debian policy.
>
> +1
>
> However, there is a legitimate concern that I'm not likely to personally
> test more than one, maybe two, of the service files, since I'm probably
> going to find that I have a personal favorite and end up using that on
> most or all of my systems.
>

That's true, but see my second email in reply to Lucas. Each init system
has it's proponents and it would be their job to help with testing. And I
would happily accept any patch which would help me with testing (I still
have to check the autopkg testing.)

So whatever we pick I guess we:

1. get enough feedback from Ubuntu people to ensure quality upstart jobs

2. kFreeBSD folks would provide OpenRC support (same as Hurd people
providing the MAX_PATHLEN patches)

3. people passionate about systemd (Gnome folks, etc...) would provide
support for service files

We can revise the plan after during the jessie development, if it doesn't
work we will just drop support for the non-functional init system (or just
make it non-RC)

O.
-- 
Ondřej Surý 

Re: Forming a Debian bugsquad team (Was: "Blacklists" in BTS (stopping the trolls and bug machines))

[Holger Levsen]

Hi,

On Montag, 27. Mai 2013, Arno Töll wrote:
> Having that said, there are more jobs that team could take over, like
> handling bugs against "general", or against in-existing packages.

while in general (no pun intended) your idea is quite right, note that 
currently http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=general lists no 
bug which merrely needs bug triaging. whats missing (to fix these bugs) is 
sometimes consenus and always code.


cheers,
Holger




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

Re: Forming a Debian bugsquad team (Was: "Blacklists" in BTS (stopping the trolls and bug machines))

[Miguel Figueiredo]

Em 27-05-2013 20:01, Ondřej Surý escreveu:

If we are to form the Debian bugsquad team similar to Ubuntu bugsquad
team, the main two questions would be:

1. As a Debian Developer/Maintainer would you be thankful for other
people to come and help with bugs in your package.


on l10n the approach is to first contact the maintainer and tell what's 
going to happen if it's ok with him/her.


I find it very fair and nice.


2. Can we find enough volunteers to form such team?


Sure.

[...]
--
Melhores cumprimentos/Best regards,

Miguel Figueiredo


--
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/51a3b97d.20...@debianpt.org

Bug#710045: RFP: node-redis-commander -- Redis web-based management tool

[Cristian Greco]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: node-redis-commander
Version: 0.1.1
Upstream Author: Joe Ferner 
URL: https://github.com/nearinfinity/redis-commander
License: [unknown, see later]
Description: Redis web-based management tool

A node.js web application used to view, edit, and manage a Redis
Database: Main features are:
- Config Information
- Tree View
- View Key Values
- Edit Values
- Redis CLI
- Tab Completion
- API Popup

Unfortunately, there is no license file nor license statements in the
source code files, so anyone willing to package this module must ask
the author to clarify the license.

Thanks,
--
Cristian Greco
GPG key ID: 0xCF4D32E4


signature.asc
Description: PGP signature

Debian systemd survey results

[Michael Stapelberg]

Hi,

Thanks for participating, everyone!

find the results at:
http://people.debian.org/~stapelberg/2013/05/27/systemd-survey-results.html

Another discussion is really not necessary at this point. Quote from the
page:

I know this is a controversial topic. Please don’t start yet another
systemd discussion on debian-devel. We, the systemd Debian
maintainers, will try to come up with good answers to all listed
concerns and communicate them in a friendly and concise way
soon. Furthermore, we have recognized the need for more
documentation/information about how things are supposed to work with
regards to the transition (and systemd in general) and will address
that, too.

-- 
Best regards,
Michael


--
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/x6k3mk42pw@midna.zekjur.net

Re: systemd .service file conversion

[Josselin Mouette]

Le lundi 27 mai 2013 à 09:13 +0200, Ondřej Surý a écrit : 
> I would be quite happy to write service files for two (systemd,
> upstart) or three (systemd, upstart, openrc) of those in all my
> packages[*], if it stops the endless flamewar here. I would also be
> happy to have the requirement to support two (or three) of them in the
> Debian policy.

This kind of madness is precisely described here:
http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html

By supporting several init systems, each with their own combination of
bugs, each combination of services using the init systems with their own
combination of bugs *depending on the init system*, you are just going
to make it impossible to maintain packages depending on these services. 
-- 
 .''`.  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/1369684595.30759.2.camel@tomoyo

Re: systemd .service file conversion

[Vincent Bernat]

 ❦ 27 mai 2013 08:38 CEST, Helmut Grohne  :

>> At the risk of adding another level of indirection, we could add a
>> meta-init format that can generate an appropriate file for any of these.
>
> Are you aware of http://wiki.debian.org/MetaInit (packages metainit and
> dh-metainit)? That work was started like eight years ago. Unfortunately
> it didn't take off yet. The only package using it is infon.

It's unfortunate that MetaInit predates systemd and upstart by several
years, but it seems better to stick with either upstart and systemd
configuration format as an universal one. This would also allows to
leverage work done by upstream since those job/unit descriptions are not
distribution-dependant.
-- 
panic("Lucy in the sky");
2.2.16 /usr/src/linux/arch/sparc64/kernel/starfire.c


pgpKu709XB9AR.pgp
Description: PGP signature

Re: Forming a Debian bugsquad team

[Bas Wijnen]

On Mon, May 27, 2013 at 09:01:40PM +0200, Ondřej Surý wrote:
> The idea would be to have a team of pasionate people who would constantly
> try to improve Debian as a whole and they would help the maintainers to
> triage bugs.
...
> > Perhaps the QA team is even closer to what you mean, but they
> > always say that any DD is in the QA team, so there isn't really a
> > difference.
> 
> No, the QA team is not even close.

I don't see how the purpose of the QA team differs from your proposal.  If you
mean "the QA team can't find enough people to do all the work they would like
to do", then I agree.  But setting up a different team with exactly the same
purpose under a new name isn't going to solve that problem.

> On Mon, May 27, 2013 at 4:21 PM, Bas Wijnen  wrote:
> > I agree.  On a completely different level, those bugs are also often quite
> > easy to fix (taking mostly time, not much skill), and therefore can be used
> > to attract new developers to a project.
> 
> Where are these developers you are talking about? Shove them to PHP BTS to
> triage the bugs.

I don't have them, of course.  My point was that if someone is interested in
helping, they will want to do a simple task to become familiar with the code.
You cannot use the bugs to generate the people, but you can use them to keep
them from running away.

> >  > The "I see a warning from ucf, let's fill a bug on php5-common" finally
> > > overflew my cup of patience.
> >
> > Especially with simple wishlist bugs, the submitter doesn't want to dig
> > deep into the package to see what the problem really is.  In a case like
> > this, the maintainer should reassign the bug to the package that causes it,
> > just like they should forward it upstream if appropriate.  This is a
> > similar action, which as I wrote I consider part of the task of a package
> > maintainer.
> 
> Some packages are easier to maintain, some are much harder.

Sure.  But instead of saying "ask upstream", you can say forward the report
upstream yourself.  It's probably not more work for you, but it would be more
work for the submitter, because they would have to create an account on the
bugzilla and learn how it works (which is hopefully not hard, but still work).

> So it might be easier for you to say than f.e. for me with php, rails, bdb
> and some other packages in my unfortunate portfolio. How many security bugs
> did you have in your packages in squeeze? Please understand that our
> perspectives and experiences with Debian package maintenance might wildly
> differ.

Oh, I understand that.  But we're talking about ideals here (well, at least I
am).  I think a package maintainer _should_ be the proper place to report any
issue with the package (packaging-related or not).  I know that some upstreams
are particularly hostile if you say that you're using a package (Blender for
example).  They say Debian does it all wrong, and people should download and
install directly from them (which is a very bad idea, of course).  For such an
upstream, I don't want to report my bugs there.  I want to report to the
package maintainer who can fight with them.  But I don't know in advance if
upstream will be like that.  And again, a uniform bug reporting interface for
all bugs is a great feature, which I want our users to have.

For this reason, I argue that maintainers should not complain about bug
submitters when the bugs are in upstream's code.  I didn't say (or mean) that
maintainers can't complain.

> I am talking about group of people which would help triage the bugs on
> regular basis, and would help maintainers who cannot find more active
> maintainers to the team even though the RFH bug is open for more than a
> year. (And I am thankful for every little contribution I receive)

Again, I do not see how this is not 100% the goal of the QA team.

> I sent the original email asking on advice how to make my job somehow
> easier, because sometimes it's too much and I want to prevent  my burnout
> and burntout of some other fellow Debian Developers.
> 
> Do you understand that your email saying "don't complain, it's your job"
> isn't very helpful?

Sorry about that, that wasn't the take-home message I intended.

I wasn't trying to say you should work harder even if you see a burnout coming.
It totally acceptable to be unable to fully maintain a package, if you ask for
help (and you do that).  If no help comes, then apparently this is not
important enough for Debian.  That's unfortunate, but don't let it kill you.
The result will be a badly maintained package (possibly with too many open bugs
or late responses to bug submitters).  Of course that's not good, but in some
cases we just can't do better.  If you don't want to take responsibility for
such a package, and there is no way to fix the problem without a burnout
(which, by the way, will not fix it either), then you should orphan the
package.  Your health is more important than what you do for Debian.

So no, I'm not saying you shouldn't complai

Re: Debian development and release: always releasable (essay)

[Andreas B. Mundt]

Hi all,

On Mon, May 27, 2013 at 02:14:17PM +0200, Andreas Tille wrote:
> On Sun, May 26, 2013 at 03:10:07PM +0200, Holger Levsen wrote:
> > On Samstag, 25. Mai 2013, Petter Reinholdtsen wrote:
> > > Actually, I believe there is.  The Debian Edu blend contain the
> > > education-main-server task and metapackage, which include a Kerberos
> > > KDC.  It also contain the LDAP server as KDC backend storage and
> > > user/group/etc lookup.
> >
> > there is also the Debian-LAN which is described as "The goal of Debian-LAN 
> > is
> > to make setting up a local network with centralized user and machine
> > management, intranet, etc. as easy as possible in Debian."
> >
> > see ://lists.debian.org/20120408083121.GB9680@flashgordon
>
> If I where Andreas Mundt I would try to do this inside the Debian
> Enterprise effort.  While there is barely any traffic on this list you
> just need to start with such an effort somehow and IMHO the topic does
> fit.

First, many thanks to Holger for mentioning the Debian-LAN project
here and thereby pointing me to the ongoing discussion. I try to
follow -devel as time permits, but I'm not subscribed, please keep me
in cc.

@Andreas:  I announced Debian-LAN on several lists, including
debian-enterprice [1], and debian-news mentioned it too [2].  It's
planned to send another announcement message as soon as the latest
additions to the debian-lan-config package are well tested and
uploaded to wheezy-backports.  A DebConf talk is under way.  In other
words:  Anybody is invited to make use of and/or contribute to the
Debian-LAN project.  I would be rather astonished if there are already
efforts in Debian Enterprise currently working on the same issue.  If
this is the case, we should of course not do the work twice.

But back to the topic.  I appreciate the ideas outlined by Lars and
Russ very much, and I would love to see debian-lan helping to make
them reality.

The Debian-LAN system provides a basic Debian Desktop installation in
combination with a full-featured server providing a Kerberos KDC with
kerberized services: ssh, NFSv4, apache, LDAP, exim, dovecot, ...

FAI provides a very structured and extremely flexible way to compose
the system. For any service (== FAI class), the implementation is
straight forward: Packages, preseedings, and if unavoidable extra
files and/or 'manual' configuration tweaks.  All this in combination
with the thorough logging included in FAI proved to be a valuable
concept:  It's almost always clear what's gone wrong and causes
problems.

Since I started to work on the Debian-LAN project at DebConf11, it
turned out with every implementation of a new service/feature that
using FAI is a very good approach.

I am not familiar with jenkins, but I cannot imagine a problem running
automatic test as Holger already does with a slightly adapted
Debian-LAN system.  The goal of Debian-LAN is to provide a Debian
local area network out-of-the box, this covers exactly all relevant
tests that a stable Debian should pass.

If Debian-LAN can be part of such automatic testing it would be really
great!

Best regards,

 Andi



[1] https://lists.debian.org/debian-enterprise/2012/04/msg0.html
[2] https://lists.debian.org/debian-news/2012/msg00015.html


-- 
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/20130527220655.GA438@fuzi

Bug#710057: ITP: require-kernel.js -- Reference implementation of a CommonJS module loader for a browser environment

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: require-kernel.js
  Version : 1.0.6
  Upstream Author : Chad Weider 
* URL : https://github.com/cweider/require-kernel
* License : Expat
  Programming Lang: Javascript
  Description : Reference implementation of a CommonJS module loader for a 
browser environment

 With this Javascript library you can add CommonJS module support to
 your browser environment. It defines a kernel that provides a
 CommonJS compliant require() function. Modules can either be loaded
 synchronously or asynchronously.


-- 
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/20130527221114.17133.17433.report...@minobo.das-netzwerkteam.de

piuparts 0.52 (was Re: bits from the piuparts maintainers: the first million is the hardest)

[Holger Levsen]

Hi,

On Donnerstag, 23. Mai 2013, Holger Levsen wrote:
> adequate
> 
> sid-nodoc will also be the first suite to be completly tested with
> adequate [4] which from piuparts 0.52 will be automatically run if it's
> installed. http://piuparts.debian.org/sid/inadequate_issue.html shows
> some example reports.

FYI: piuparts 0.52 is available in sid now.

BTW, would someone appreciate wheezy-backports of piuparts?


cheers,
Holger


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

Bug#710060: ITP: pyflot -- interface from Python to libjs-flot

[Andrew Starr-Bochicchio]

Package: wnpp
Severity: wishlist
Owner: "Andrew Starr-Bochicchio" 

* Package name: pyflot
  Version : 0.1
  Upstream Andre da Palma
* URL : http://github.com/andrefsp/pyflot
* License : MIT
  Programming Lang: Python
  Description : interface from Python to libjs-flot

PyFlot makes it easy to generate flot graphs. Its primary goal is to allow one
to specify data inputs and options in a Python application and generate the
appropriate JSON. Common uses of this are rendering into a template as flot()
arguments or as the payload of an XHR response. PyFlot takes care of all the
annoying details of converting types to match up with how flot expects them.


-- 
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/20130527231332.6190.80525.reportbug@asb-laptop

Re: FW: problem with amixer

[Paul Wise]

On Tue, May 28, 2013 at 1:24 AM, Juan Diego Tortul Batistuta wrote:

> Hi I have no sound, have a problem with amixer in (Debian 7 Gnome);
>
> in booting the error is:
>
> amixer : amixer hw : 0 : load error : invalid argument

Please contact our user support channels for help:

http://www.debian.org/support
http://lists.debian.org/debian-user/
http://forums.debian.net/
http://ask.debian.net/
irc://irc.oftc.net/debian

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6fuqws+qgiosc4pa+0pjnskrzu9sfg9tczkof+2091...@mail.gmail.com

Re: using upstart in Debian

[Steve Langasek]

On Mon, May 27, 2013 at 11:58:13AM -0700, Nikolaus Rath wrote:
> The only way to avoid this (at least at the time I reported the bug),
> would have been to recompile mountall to emit events with --no-wait (but
> I'm not sure what other unintended consequences that would have had).

Lots of them.  There are various actions one wants to take as soon as a
filesystem is mounted, and before anything else is allowed to use the
filesystem - tmp cleaning, for instance, or populating heirarchies on /run.
Jobs starting on such 'mounted' events *must* block until they're finished,
so that you don't have one part of the system racing to use /tmp while
another part is still cleaning it.  This is the primary purpose for which
these 'mounted' events are made available.

> As I said, there isn't a bug anywhere here. Once you understand what's
> going on, this all makes sense. But I don't consider this a very good
> design.

Well, I don't think it's a bad design that third-party jobs can see and use
upstart events that were created primarily for internal consumption; if
anything, the problem is in documenting these in a way that doesn't make it
clear that they are not a general-purpose interface for services and should
not be used except in special cases.

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


signature.asc
Description: Digital signature

MBF: transition from texi2html to texinfo

[Ryan Kavanagh]

In coordination with Norbert Preining, I propose a MBF against all
packages depending on or build-depending on texi2html, asking them to
transition from the `texi2html' utility to the `makeinfo' utility from
the texinfo package, with the end goal of being able to remove the
texi2html package from the archive. This is because:

 1) texi2html is dead upstream since 2011 and has been superseeded by
 Texinfo, as documented on the texi2html front page[0].

 2) texi2html is currently orphaned in Debian since 2013-01-13[1] (I
 currently have it ITA'd).

 3) transitioning from texi2html to makeinfo can be done with minimal
 effort, see e.g., this patch against bc[2], and now seems to be the
 opportune time to perform such a transition.

There are 94 reverse-build-dependencies and 2 reverse-dependencies
according to the `reverse-depends' tool. I am prepared to file the bugs
against the affected packages, to prepare a lintian check warning
against the use of texi2html, to prepare a wiki page documenting how to
transition from texi2html to makeinfo, and to start submitting patches.
See attached for a dd-list of affected packages.

Depending on how pressing people think this issue is, the bugs can have
severity wishlist, minor, or normal—I'm leaning towards minor, please
let me know if you have a strong opinion otherwise. The proposed bug
text is as follows:

-- BEGIN --
Dear maintainer,

[ This is an automated bug report, submitted as part of the mass bug
  filing discussed at TODO-ADD-URL-TO-DEVEL-THREAD-HERE ]

The texi2html package on which your package depends or build-depends is
destined to be removed from the archive in the near future. Please
update your package to use the `makeinfo' utility from the texinfo
package instead. More details may be found at
http://wiki.debian.org/Texi2htmlTransition .

Thanks for considering,
Best wishes.
-- END --

Best wishes,
Ryan

[0] http://www.nongnu.org/texi2html/
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698081
[2] 
http://anonscm.debian.org/gitweb/?p=collab-maint/bc.git;a=commitdiff;h=8f6f51467bcb6487579f5372697863bcfb14018a#patch2

-- 
|_)|_/  Ryan Kavanagh   | Debian Developer
| \| \  http://ryanak.ca/   | GPG Key 4A11C97A


signature.asc
Description: Digital signature

default MTA

[Marco d'Itri]

Now that we are done with systemd for the time being, can we have the 
flame war about replacing Exim with Postfix as the default MTA?

Are there any objections other than "but I like it this way!"?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: libtiff borken - cannot build anymore?

[Russ Allbery]

Jay Berkenbilt  writes:
> Russ Allbery  wrote:
>> Jay Berkenbilt  writes:
>>> Ondřej Surý  wrote:

 This results in:

 E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/annotate
 /usr/lib/x86_64-linux-gnu/libtiff5-alt

>>> Yes, I'm afraid that's unavoidable.  This issue is mentioned in the
>>> README.Debian file.  This works by installing the .so file in a
>>> non-standard location so that it can coexist with libtiff4, and
>>> linking in that way with libtool the rpath to be embedded.  Once the
>>> tiff transition is completed and the packages are rebuilt, this
>>> problem will go away.

>> This shouldn't be required, since the two libtiff shared libraries can
>> both go into /usr/lib (since they have different SONAMEs).  The only
>> thing that can't go into /usr/lib and has to go somewhere else is the
>> *.so symlink, which doesn't require an rpath setting, only a -L flag
>> during linking.

> The .so files (there are two libraries), static libraries, and .la files
> are already the only files in a non-standard location.  Basically only
> the files whose names clash are in non-standard locations.  (Tiff still
> can't remove its .la file yet, or at least it couldn't though I can't
> remember the exact details of when it's okay to remove the .la
> fileit has a lot of reverse dependencies  It's the only package
> I maintain that still installs .la files.)

Ah, I see.  I took a look, and indeed, it's the *.la file that causes the
problem, and only for other packages linked with libtool.

Obviously removing the *.la file would be ideal, but if the *.la file is
referenced in any other *.la files of other libraries that depend in
libtiff, you can't remove it without breaking builds.  However, you can
fix the *.la file so that it won't introduce this problem, I think.  I
believe you should be able to edit the *.la file after the build and
change:

libdir='/usr/lib/i386-linux-gnu/libtiff5-alt'

to:

libdir='/usr/lib/i386-linux-gnu'

I don't think this will interfere with the build, and it should suppress
the rpath.

>> See the krb5-multidev and heimdal-multidev packages for how this is
>> done.

> I'll give them a look and see if I can tell what they're doing
> differently.

These don't use libtool, which is the immediate difference.

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

Re: MBF: transition from texi2html to texinfo

[Paul Wise]

On Tue, May 28, 2013 at 8:28 AM, Ryan Kavanagh wrote:

> In coordination with Norbert Preining, I propose a MBF against all
> packages depending on or build-depending on texi2html, asking them to
> transition from the `texi2html' utility to the `makeinfo' utility from
> the texinfo package, with the end goal of being able to remove the
> texi2html package from the archive. This is because:
> ...
> There are 94 reverse-build-dependencies and 2 reverse-dependencies
> according to the `reverse-depends' tool. I am prepared to file the bugs
> against the affected packages, to prepare a lintian check warning
> against the use of texi2html, to prepare a wiki page documenting how to
> transition from texi2html to makeinfo, and to start submitting patches.
> See attached for a dd-list of affected packages.

There are a lot of texi2html uses, 877 pages worth in Debian sid:

http://codesearch.debian.net/search?q=texi2html&skip=877

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: using upstart in Debian

[Nikolaus Rath]

Steve Langasek  writes:
> On Mon, May 27, 2013 at 11:58:13AM -0700, Nikolaus Rath wrote:
>> As I said, there isn't a bug anywhere here. Once you understand what's
>> going on, this all makes sense. But I don't consider this a very good
>> design.
>
> Well, I don't think it's a bad design that third-party jobs can see and use
> upstart events that were created primarily for internal consumption; if
> anything, the problem is in documenting these in a way that doesn't make it
> clear that they are not a general-purpose interface for services and should
> not be used except in special cases.


But exactly the same can happen between other jobs as well, it's not
specific to mountall or the mounted event. In my opinion the problem is
not that third-party jobs can see upstart internal events, but the way
that upstart has defined events in the first place. To me, this leads to
confusing semantics all over the place.

To give a different example, if I look at something like "start on
event1 and event2" then the first thing that comes to my mind is "so
this job is only going to start if these two events happen to occur
simultanously by some coincidence?"[1]. As I understand, Upstart is
handling this by giving lengths a duration. But the duration is defined
by how other jobs combine this event with others, yet affects the
program that tries to emit the event.

For this reason, the systemd way of declaring jobs seems much more
natural to me. I don't want my X server to start when dbus is available
the the home directory is mounted (as upstart forces me to think), I
want dbus to be started and the home directories mounted when I request
an X session. If I am not mistaken, only systemd allows me to express
the later .


Best,

   -Nikolaus

[1] Don't get me wrong, the upstart documentation does a good job of
explaining this. My point is not that it's not well documented, but
that it is counterintuitive.

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
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/87a9nf260a@vostro.rath.org

Eliminating mail-transport-agent from standard

[Josh Triplett]

In addition to determining the MTA pulled in by default for packages
which require mail-transport-agent in order to function (the provider of
default-mta), I'd like to propose as a release goal that we not have any
MTA in standard anymore.  I've actually worked towards this goal for a
while now, and made a fair bit of progress; this mail documents the
remaining work required, most of which is simple dependency/priority
changes and patch application.

Only one package in standard or above currently Depends on a
mail-transport-agent:

- bsd-mailx: should have the same priority as an MTA (optional).

Two packages in standard or above Recommends bsd-mailx (indirectly via
the mailx virtual package):

- exim4-base: moved to optional as part of this goal.

- logrotate; could just Suggests mailx (or use sendmail directly and
  Suggests an MTA).

Four packages in standard or above Recommends mail-transport-agent:

- cron: I've already filed bugs on cron (and anacron) with patches to
  support sending cronjob output to syslog, so that it will not
  disappear into /dev/null without an MTA installed.

- at: I'd argue for this becoming priority optional, though it wouldn't
  be particularly hard to write a patch like the one for cron instead.

- procmail: should have the same priority as an MTA (optional)

- mutt: can easily Suggests a mail-transport-agent, since it supports
  IMAP and SMTP, leaving aside more exotic configurations like
  getmail/fetchmail.  (That leaves aside the question of whether mutt
  should be standard or optional, but I think either way it should only
  Suggests an MTA.)

With the above changes made, all providers of mail-transport-agent could
become priority optional or lower, including the provider of
default-mta.

(To the extent this affects the selection of default-mta, I'd suggest
that it might argue in favor of making default-mta one that only
supports smarthosts and does not queue locally, leaving the choice of
what MTA to run on a mail server up to the end user, but that question
matters a lot less to me than removing MTAs from standard.)

- Josh Triplett


-- 
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/20130528032733.GA30967@leaf

Re: Status of OpenRC in Debian

[Thomas Goirand]

On 05/24/2013 04:23 PM, Thomas Goirand wrote:
> On 05/24/2013 02:19 PM, Svante Signell wrote:
>> What is the status of packaging OpenRC for Debian? Is there a group
>> doing that, is help needed?
> 
> Ok, if you ask...
> 
> Currently, the package can build and install, at least on Linux flavors
> of Debian.
> 
> Once installed, it will unfortunately not understand the LSB headers of
> the scripts in /etc/init.d. I tried replacing the init script provided
> by the source package of sysvrc by the one shipped with OpenRC (they are
> called "runscript), and it worked very well. For fun, I replaced the LSB
> headers of essential boot init.d scripts (I tried with udev and ssh),
> and it just worked out of the box. I had "rc-status" working, together
> with the cgroups support (which is nice, right?).
> 
> Though that's not practical: we need a full drop-in replacement without
> touching the existing init.d scripts, and we don't even want to touch
> the LSB headers at all (that should be left as a decision).
> 
> But the good news is that there is already a perl script to transform
> the LSB headers into an OpenRC header. There is even 2 versions: one in
> perl, and one in Python. It is well possible that it will be
> reimplemented in C, to avoid any kind of dependencies.
> 
> One of the problem also is that OpenRC doesn't understand the concept of
> X-Start-Before: (it only has the concept of Required-Start /
> Required-Stop). So something will have to be done so that we have
> support for that.
> 
> So the work to be done will be:
> - Hook into update-rc.d, somehow either understand or convert the LSB
> headers of existing script, or convert them on-the-fly (maybe in another
> directory, like /etc/init.d/openrc or something similar).
> - Add code so that it can support X-Start-Before
> - Add a bit of configuration so that it can build on kFreeBSD
> - A tinny bit of adaptation so that the OpenRC ebegin / eend calls are
> replaced by the usual lsb-base calls (I didn't look at it much, but that
> shouldn't be hard, really), so that we get the nicer usual Debian boot
> script prints.
> 
> I just tried to build it in kFreeBSD (on a virtualbox VM), and
> unfortunately, it suffers from the usual problems in this arch: it needs
> a bit of adaptation, because it doesn't detect the arch correctly. It
> should really be only configuring and not programming (eg, write the
> mk/kFreeBSD.mk files, etc.), and not code, since there are already some
> build for OpenRC working in many *BSD unix (FreeBSD, NetBSD...).
> 
> I'm not really sure if there's more work to be done, but I think that
> should be it. Probably heroxbd or Roger (hereby CC:) can tell their
> opinion on what's left to implement. If that is it, then that's not so
> much, IMO, and that's not so hard either (the hardest part, IMO, is the
> X-Start-Before support, which is the only part which requires a bit of
> thinking and algorithm, though since we already have implementation in
> sysvrc, it should be fairly easy to have a look how it is done...).
> 
> We currently have a Google Summer of Code project to cover the above,
> for which I am a mentor. Roger Leigh & heroxbd (who is a Gentoo
> developer, and upstream for OpenRC) are co-mentors. I have good hopes
> that by September we will have all of the above implemented (this
> depends how good the GSoC student will be, and it is my understanding
> that I can't, for the moment, disclose (yet) who we have chosen among
> the 6 candidates).
> 
> For those who want to see an example of what a runscript looks like,
> here's 2 examples, taken from the source of OpenRC on our Alioth Git (in
> collab maint):
> 
> ~/sources/debian_packaging/openrc/openrc# more init.d/swap-blk.in
> #!@PREFIX@/sbin/runscript
> # Copyright (c) 2007-2008 Roy Marples 
> # Released under the 2-clause BSD license.
> 
> depend()
> {
>   before fsck
>   keyword -jail -prefix
> }
> 
> start()
> {
>   ebegin "Activating block swap devices"
>   swapctl -A -t blk >/dev/null
>   eend 0 # If swapon has nothing todo it errors, so always return 0
> }
> 
> stop()
> {
>   ebegin "Deactivating block swap devices"
>   swapctl -U -t blk >/dev/null
>   eend 0
> }
> ~/sources/debian_packaging/openrc/openrc# more init.d/rarpd.in
> #!@PREFIX@/sbin/runscript
> # Copyright (c) 2007-2008 Roy Marples 
> # Released under the 2-clause BSD license.
> 
> command=/usr/sbin/rarpd
> command_args="-f $rarpd_args"
> pidfile=/var/run/rarpd.pid
> name="Reverse ARP Daemon"
> required_files=/etc/ethers
> 
> if [ -z "$rarpd_interface" ]; then
>   command_args="$command_args -a"
> else
>   command_args="$command_args $rarpd_interface"
> fi
> command_background=YES
> 
> depend()
> {
>   need localmount
>   after bootmisc
>   need net
> }
> 
> These are 2 random examples taken from the source, they might not be the
> best. Feel free to have a look yourself (in the init.d folder of the
> sources on the Git on Alioth: see below). There a

Re: MBF: transition from texi2html to texinfo

[Sébastien Villemot]

Le lundi 27 mai 2013 à 20:28 -0400, Ryan Kavanagh a écrit :
> In coordination with Norbert Preining, I propose a MBF against all
> packages depending on or build-depending on texi2html, asking them to
> transition from the `texi2html' utility to the `makeinfo' utility from
> the texinfo package, with the end goal of being able to remove the
> texi2html package from the archive. This is because:
> 
>  1) texi2html is dead upstream since 2011 and has been superseeded by
>  Texinfo, as documented on the texi2html front page[0].
> 
>  2) texi2html is currently orphaned in Debian since 2013-01-13[1] (I
>  currently have it ITA'd).
> 
>  3) transitioning from texi2html to makeinfo can be done with minimal
>  effort, see e.g., this patch against bc[2], and now seems to be the
>  opportune time to perform such a transition.

AFAIK, makeinfo is not able to render @math blocks as images (formatted
with LaTeX), while texi2html does. The output of math formulas with
makeinfo --html is very ugly, since it basically dumps the Texi/LaTeX
source of the formula in the HTML.

Unless I am missing something (like a makeinfo option/flag), it means
that makeinfo is not a complete replacement of texi2html, and I would
therefore prefer to keep texi2html around (until makeinfo grows the
missing feature). I use the ability to have nice math formulas in HTML
in one of my scientific packages.

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://www.dynare.org/sebastien
  `-  GPG Key: 4096R/381A7594



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