Key signing

[Nicolas]

Hi all,

I search for a Debian Member to sign my gpg key.
I work in Paris. I live in Seine-et-Marne (77).

Thanks in advance.

Nicolas

Re: Key signing

[Nicolas]

Thanks.
I have a look at that list but I think strange to "spam" people for
requiring a signing key. No ? Is it the right process ?

Nicolas

2009/12/8 Simon Paillard 

> Hi,
>
> On Tue, Dec 08, 2009 at 09:57:56PM +0100, Nicolas wrote:
> > I search for a Debian Member to sign my gpg key.
> > I work in Paris. I live in Seine-et-Marne (77).
> (France)
>
> You should have a look at https://nm.debian.org/gpg_offer.php
>
> http://lists.debian.org/debian-devel-french/ and #debian-devel-fr might
> help as well.
>
> --
> Simon Paillard
>

Re: Bug#561868: ITP: piwigo -- photo gallery software for the web

[Nicolas]

Hi,

thanks for your interest in piwigo.

> That's a quite interesting package because I intend to implement such
gallery software soonish.  Could you please do some comparison against
ansel1 which is just inside Debian.  I'd be interested how both compare
to have some help for the decision which one to use.

To be honest, I didn't know about ansel before you ask for comparaison. I
search for that application. I saw screenshot and features and it looks good
but I didn't find a simple way to install it. Maybe I forgot something.
I'm not sure I'm the right person to do an honest compaison because I'm
involved in piwigo development ! But I can say one thing. I think piwigo is
simple : simple to install and very intuitive to use. We embrassed KISS
concept.

Regards,
Nicolas

2009/12/21 Andreas Tille 

> On Sun, Dec 20, 2009 at 11:14:22PM +0100, Nicolas Roudaire wrote:
> >
> > * Package name: piwigo
> >   Version : 2.0.7
> >   Upstream Author : Pierrick LE GALL 
> > * URL : http://piwigo.org/
> > * License : GPL
> >   Programming Lang: PHP
> >   Description : photo gallery software for the web
> >
> > Piwigo is a photo gallery software for the web, built by an active
> community
> >  of users and developers. Extensions make Piwigo easily customizable.
> >
> >  Features:
> >   - localization in english, french, german, spanish, italian,
> nederlands, portuguese, ...
> >   - tags
> >   - permissions on photos and categories
> >   - virtual category allowing picture to be in multiple categories
> >   - meaningful URLs
> >   - user comments and rating
> >   - use of iptc and exif metadatas
> >   - notification of news by email or RSS feed
> >   - best rated, most view pictures
> >   - web api allowing requests or administration from other applications.
>
> That's a quite interesting package because I intend to implement such
> gallery software soonish.  Could you please do some comparison against
> ansel1 which is just inside Debian.  I'd be interested how both compare
> to have some help for the decision which one to use.
>
> 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
>
>

Help to fix installation problem with dotclear

[Nicolas]

Hi all,

I try to fix a problem in installation of dotclear package but there's
seems to be a problem with apache configuration files :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709960

I can reproduce piuparts warnings but didn't find a solution.

If anyone understand the problem and know how to fix it, it will be
glad. If you have any question, don't hesitate.
Thanks in advance.

Regards,
Nicolas

p.s: I'm not sure it's the right list but...


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

Re: Help to fix installation problem with dotclear

[Nicolas]

Hi Vincent,

I was almost sure you will say that. :-)
Anyway thank for the idea and I will give it a try.

Regards,
Nicolas

2013/7/7 Vincent Danjean :
> Le 06/07/2013 12:04, Nicolas a écrit :
>> Hi all,
>>
>> I try to fix a problem in installation of dotclear package but there's
>> seems to be a problem with apache configuration files :
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709960
>>
>> I can reproduce piuparts warnings but didn't find a solution.
>>
>> If anyone understand the problem and know how to fix it, it will be
>> glad. If you have any question, don't hesitate.
>
> I did not look in details but one way to solve this kind of problems
> is to switch to ucf to manage these files. So they wont be conffile
> anymore (they will only be configuration files created/managed with
> ucf)
>
>   Regards,
> Vincent
>
>> Thanks in advance.
>>
>> Regards,
>> Nicolas
>>
>> p.s: I'm not sure it's the right list but...
>>
>>
>
>
> --
> Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
> GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
> Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
> APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main
>
>
> --
> 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/51d9cae1.4060...@free.fr
>


--
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/CALYYOOBfQX738W58GdkMJvZjJ=2w4fgwgbuoxg5m7jmhv27...@mail.gmail.com

Notice with dbconfig-common

[Nicolas]

Hi all,

I tried to update a package (dotclear) that use dbconfig-common to manage
database stuff. The package installation failed when I tried to install the
package with postgreSQL. It's a notice for postgreSQL but an error for
dbconfig-common script.

The message is :  NOTICE: CREATE TABLE / PRIMARY KEY will create an
implicit index ...

I understand the message but I don't know how to fix it. For postgreSQL
point of view it doesn't seems to be a problem and tables are created.

Thanks in advance for any help.

Regards,
Nicolas

Re: Non-source Javascript files in upstream source

[Nicolas]

Hi all,

I'm a bit disapointed. I don't know what to do. I try to fix following bug
: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744317
Two files are pointed to have no upstream source. Theses files are html
template files used by a javascript engine. If I understood, the problem is
that theses files seems to be minified. The real problem is that it cannot
works if theses are not in that format. How can it be fixed ?

Regards,
Nicolas


2014-04-27 16:15 GMT+02:00 Russ Allbery :

> Ben Finney  writes:
>
> > Okay. Is it accurate to say, then, that you and I agree these files are
> > distributed as part of the Debian source package, and thereby part of
> > Debian?
>
> Mu.  I find this definition of the problem reductionist and overly
> simplistic and think there are various shades of grey in what "part of
> Debian" means.
>
> --
> Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/87lhuquacl@windlord.stanford.edu
>
>

Re: Non-source Javascript files in upstream source

[Nicolas]

>
> Jo Nicolas,
>
> You could generate the minified javascript from normal javascript files.
>
>
I know that but non minified files don't work. It gives errors "Uncaught
SyntaxError: Unexpected token ILLEGAL"

SwiftMailer new upstream release

[Nicolas]

Hi all,

I'm looking for a sponsor for the package swiftmailer that is already in
debian. Upstream delivered a new release. There's no major changes in
debian packaging. I can build the package and lintian did not complain
about errors.

I know it's not the right list (preferred m.d.o) but I hope here a
developer can help me and upload it for me.

The package :
SwiftMailer
   - licence : MIT
   - version : 5.1.0
   - project url : http://swiftmailer.org/
   The package is maintain on alioth :
   - Vcs-Git: git://anonscm.debian.org/collab-maint/swift.git
   - Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/swift.git

Thanks in advance for takin attention to my message.

Regards,
Nicolas

Bug#1073934: ITP: golang-github-makenowjust-heredoc -- Convert strings to here documents in Go (v2) (library)

[Nicolas Schier]

Package: wnpp
Severity: wishlist
Owner: Nicolas Schier 

* Package name: golang-github-makenowjust-heredoc
  Version : 2.0.1-1
  Upstream Author : TSUYUSATO Kitsune
* URL : https://github.com/MakeNowJust/heredoc
* License : MIT
  Programming Lang: Go
  Description : Convert strings to here documents in Go (v2) (library)
   Here documents allow text files or other data to be embedded in source
   files.  The heredoc library implements the whitespace filtering and line
   break preservation since Go does not have any syntax allowing here
   documents natively.
   .
   This package contains version 2.x of heredoc.

heredoc/v2 package is a build-dependency for glab v1.42.0.

Bug#1077531: ITP: prometheus-phpfpm-exporter -- Prometheus exporter for PHP-FPM.

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: prometheus-phpfpm-exporter
  Version : 0.6.0-1
  Upstream Author : Pedro Gomes
* URL : https://github.com/Lusitaniae/phpfpm_exporter
* License : Apache-2.0
  Programming Lang: Go
  Description : Prometheus exporter for PHP-FPM.

 Prometheus Exporter for the PHP-FPM status page.
 .
 Metrics are scrapped via unix socket and made available on port 9253.
 .
 This exporter also provides a way for embedding the output of arbitrary
 PHP scripts into its metrics page, analogous to the node exporter's
 textfile collector. Scripts that are specified with the --phpfpm.script-
 collector-paths flag will be run through PHP-FPM. Any metrics printed by
 the PHP script will be merged into the metrics provided by this
 exported. An example use case includes printing metrics for PHP's
 opcache.

I like this exporter because it is able to monitor multiple PHP-FPM pools
at once by simply using the "--phpfpm.socket-directories" option.

I currently pushed this package on my own repo on Salsa as I don't have
access to the Go Packaging Team group yet:
<https://salsa.debian.org/n-peugnet/prometheus-phpfpm-exporter>

This is the first package that I create for Debian. If I understood
correctly, I will need to find a sponsor to be able to upload it.

Bug#1077533: ITP: golang-github-tomasen-fcgi-client -- go fastcgi client with fcgi params support

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: golang-github-tomasen-fcgi-client
  Version : 0.0~git20180423.2bb3d81-1
  Upstream Author : Shen Sheng
* URL : https://github.com/tomasen/fcgi_client
* License : BSD-3-clause
  Programming Lang: Go
  Description : go fastcgi client  with fcgi params support

 Go fastcgi client with fcgi params support

This is a dependency of prometheus-phpfpm-exporter (#1077531) that I
intend to package.
It is currently pushed on my own repo as I don't have yet access to the
Go Packaging Team group:
<https://salsa.debian.org/n-peugnet/golang-github-tomasen-fcgi-client>

Re: lintian.debian.org off ?

[Nicolas Peugnet]

Hi all,

Pierre-Elliott Bécue  on Wed, 27 Sep 2023 14:19:20:

Otto Kekäläinen  wrote on 27/09/2023 at 06:35:07+0200:


Hi!

Thanks for the context - so there is no need technical incompatibility
at play, but mostly a matter of having resources and time to do it.
..

Regarding the 301 redirection I'll see with the interested parties (DSA
and Lintian maintainers) if this option is fine with everyone.


I could easily write Ansible code to maintain a simple Nginx server,
with 302 redirects https://lintian.debian.org/tags/(.*)/?$ ->
https://udd.debian.org/lintian-tag.cgi?tag=$1, use same Ansible style
as salsa.debian.org is maintained on
(https://salsa.debian.org/salsa/salsa-ansible), and also donate a tiny
virtual machine for Debian project if needed. Is there some special
bureaucracy on top of that work to do to be able to contribute with
this?


Don't worry, the server still exists, it's just down, and reputting the
DNS takes little to no time.

Regarding apache config, I'm fine with doing it. It's a matter of
checking with everyone that we want to do that as the plan was nuking
the server from orbit.

Providing debian.org infrastructure requires to be a member of the
Debian System Administrators (DSA) team, which in turn requires to be a
Debian Developer, so, sadly, you can't really help on that part.

That being said, thank you for offering your time.


I sent the following email in reply to Bug#1042428 but I didn't see it 
was archived, so I repost it here:



As I just recently started making Debian packages, I clicked multiple times on links 
to <https://lintian.debian.org> that led me to a dead end, for instance from 
mentors.debian.org, or on the hyperlinks that lintian itself produce in the terminal 
output. It was not a very pleasant experience, especially for a newbie.

In my opinion, redirecting lintian.debian.org to the UDD links posted above is 
not a good option, because as I understand it, they only were intended to show 
the extended explanation for each tag. Having the list of all the affected 
packages in this page it not helpful, and it makes the pages very slow to load 
(and to produce).

So instead I thought that it would be quite easy to generate a static website 
that would be very fast to generate once, and then to serve and load. So I made 
my own implementation that generates a website that could be directly uploaded 
to lintian.debian.org, as it follows strictly the previous URL structure (I 
also added the manual of lintian as I also stumbled on links to it).

For now I hosted it on my server so you can see the result there:

  <https://static.club1.fr/nicolas/lintian/>

For instance the link above translates to:

  <https://static.club1.fr/nicolas/lintian/tags/superfluous-file-pattern.html>

And here are the sources:

  <https://github.com/n-peugnet/lintian-ssg>

It is not meant to replace the corresponding UDD link, in fact I added a link 
to it in the page of each tag, to see all the affected packages. But I think it 
is better to first arrive on a very fast to load page that simply explains the 
tag, and then be able to follow a link to see the list of affected packages.

Please telle me what you think about it and if you think it can be uploaded to lintian.debian.org? 


In the meantime I added some features and hosted it on its own domain to 
make the custom 404 page work correctly: <https://lintian.club1.fr/>. 
So, do you think it could be used to make the lintian.debian.org website 
back up?


P.S. I'm not subscribed to this list, so please CC me.

Regards
--
Nicolas Peugnet

Re: lintian.debian.org off ?

[Nicolas Peugnet]

On 09/08/2024 8:43 AM, Lucas Nussbaum wrote:

On 07/08/24 at 19:05 +0200, Nicolas Peugnet wrote:

[...]

I sent the following email in reply to Bug#1042428 but I didn't see it was
archived, so I repost it here:


As I just recently started making Debian packages, I clicked multiple times on links 
to <https://lintian.debian.org> that led me to a dead end, for instance from 
mentors.debian.org, or on the hyperlinks that lintian itself produce in the terminal 
output. It was not a very pleasant experience, especially for a newbie.

In my opinion, redirecting lintian.debian.org to the UDD links posted above is 
not a good option, because as I understand it, they only were intended to show 
the extended explanation for each tag. Having the list of all the affected 
packages in this page it not helpful, and it makes the pages very slow to load 
(and to produce).

So instead I thought that it would be quite easy to generate a static website 
that would be very fast to generate once, and then to serve and load. So I made 
my own implementation that generates a website that could be directly uploaded 
to lintian.debian.org, as it follows strictly the previous URL structure (I 
also added the manual of lintian as I also stumbled on links to it).

For now I hosted it on my server so you can see the result there:

   <https://static.club1.fr/nicolas/lintian/>

For instance the link above translates to:

   <https://static.club1.fr/nicolas/lintian/tags/superfluous-file-pattern.html>

And here are the sources:

   <https://github.com/n-peugnet/lintian-ssg>

It is not meant to replace the corresponding UDD link, in fact I added a link 
to it in the page of each tag, to see all the affected packages. But I think it 
is better to first arrive on a very fast to load page that simply explains the 
tag, and then be able to follow a link to see the list of affected packages.

Please telle me what you think about it and if you think it can be
uploaded to lintian.debian.org?


In the meantime I added some features and hosted it on its own domain to
make the custom 404 page work correctly: <https://lintian.club1.fr/>. So, do
you think it could be used to make the lintian.debian.org website back up?

P.S. I'm not subscribed to this list, so please CC me.


Hi,

If there is interest in providing a page that only list the tag
description (without the affected packages), it would be easier to add
it to the existing UDD page (with an additional parameter for example)
than to create a separate service.


As I said, The reason I made this is because it was very frustrating to 
click on links to lintian.debian.org as a newbie. Each time, I expected 
to see more information about the tag to help me understand what it 
exactly meant and how to fix it.
Currently these links lead to nowhere. I think this should be fixed as 
it adds a lot of friction for newcomers.


You proposed to fix it by adding the description of the tag on UDD, but 
I don't think this is an optimal solution.


1. The page is very slow to load, around 6 to 10 seconds. This is a 
problem both for the user, and for the server that need to generate the 
page dynamically.
2. The long list of affected packages it costly to render client side so 
it is not very inclusive for people with low end devices.
3. The lists of affected packages is not helpful at all in the context 
of clicking on a lintian.debian.org link, simply expecting to get more 
information on the tag.


For all these reasons I think a static website is a lot more suited than 
a dynamic website. So I disagree that "it would be easier to add it to 
the existing UDD page", as it is fundamentally a dynamic website. 
Moreover, the static site generator is already done, it takes 3 seconds 
to generate the whole static website (2.7 of them being lintian 
execution itself).
Maybe what you meant by "easier" was "easier to maintain", and I think 
maintenance will indeed be very important. Currently, the generator is 
under 1000 lines of Go code with a single dependency (outside of the 
stdlib). I think it would be very easy for anyone to take over the 
project if I become unable to maintain it.
And being a static site, it will be extremely easy to host and will 
require almost no resources, so hosting maintenance will also be very low.



However I haven't seen any interest from DSA in setting a redirect from
lintian.debian.org to somewhere else. As I wrote in #1042428, if
lintian.d.o was served by ullmann and managed by the uddadm group, I
would be willing to manage those redirects.


I don't suggest making any redirection of lintian.debian.org to 
anywhere. What I am suggesting is uploading a static website back to 
lintian.debian.org itself, to fix all the existing broken links out there.
As I already said, the page of each tag includes a link to UDD for 
people interested in the list of all affected packages.


Regards
--
Nicolas Peugnet

Re: lintian.debian.org off ?

[Nicolas Peugnet]

On 08/08/2024 8:40 PM, Bastien Roucariès wrote:

Le mercredi 7 août 2024, 17:05:01 UTC Nicolas Peugnet a écrit :

Hi all,

Pierre-Elliott Bécue  on Wed, 27 Sep 2023 14:19:20:

Otto Kekäläinen  wrote on 27/09/2023 at 06:35:07+0200:


Hi!

Thanks for the context - so there is no need technical incompatibility
at play, but mostly a matter of having resources and time to do it.
..

Regarding the 301 redirection I'll see with the interested parties (DSA
and Lintian maintainers) if this option is fine with everyone.


I could easily write Ansible code to maintain a simple Nginx server,
with 302 redirects https://lintian.debian.org/tags/(.*)/?$ ->
https://udd.debian.org/lintian-tag.cgi?tag=$1, use same Ansible style
as salsa.debian.org is maintained on
(https://salsa.debian.org/salsa/salsa-ansible), and also donate a tiny
virtual machine for Debian project if needed. Is there some special
bureaucracy on top of that work to do to be able to contribute with
this?


Don't worry, the server still exists, it's just down, and reputting the
DNS takes little to no time.

Regarding apache config, I'm fine with doing it. It's a matter of
checking with everyone that we want to do that as the plan was nuking
the server from orbit.

Providing debian.org infrastructure requires to be a member of the
Debian System Administrators (DSA) team, which in turn requires to be a
Debian Developer, so, sadly, you can't really help on that part.

That being said, thank you for offering your time.


I sent the following email in reply to Bug#1042428 but I didn't see it
was archived, so I repost it here:


As I just recently started making Debian packages, I clicked multiple times on links 
to <https://lintian.debian.org> that led me to a dead end, for instance from 
mentors.debian.org, or on the hyperlinks that lintian itself produce in the terminal 
output. It was not a very pleasant experience, especially for a newbie.

In my opinion, redirecting lintian.debian.org to the UDD links posted above is 
not a good option, because as I understand it, they only were intended to show 
the extended explanation for each tag. Having the list of all the affected 
packages in this page it not helpful, and it makes the pages very slow to load 
(and to produce).

So instead I thought that it would be quite easy to generate a static website 
that would be very fast to generate once, and then to serve and load. So I made 
my own implementation that generates a website that could be directly uploaded 
to lintian.debian.org, as it follows strictly the previous URL structure (I 
also added the manual of lintian as I also stumbled on links to it).

For now I hosted it on my server so you can see the result there:

   <https://static.club1.fr/nicolas/lintian/>

For instance the link above translates to:

   <https://static.club1.fr/nicolas/lintian/tags/superfluous-file-pattern.html>

And here are the sources:

   <https://github.com/n-peugnet/lintian-ssg>

It is not meant to replace the corresponding UDD link, in fact I added a link 
to it in the page of each tag, to see all the affected packages. But I think it 
is better to first arrive on a very fast to load page that simply explains the 
tag, and then be able to follow a link to see the list of affected packages.


What will be wonderfull is to retrieve number of package affected and do a svg 
graph along time... Using a static script

nicolas did you contact the the infrasture team ?


Not yet, I wanted to request feedback on my proposal beforehand.
I just added debian-ad...@lists.debian.org in CC, I hope it was the 
right thing to do.



Please telle me what you think about it and if you think it can be uploaded to 
lintian.debian.org?


In the meantime I added some features and hosted it on its own domain to
make the custom 404 page work correctly: <https://lintian.club1.fr/>.
So, do you think it could be used to make the lintian.debian.org website
back up?

P.S. I'm not subscribed to this list, so please CC me.

Regards

--
Nicolas Peugnet

Re: lintian.debian.org off ?

[Nicolas Peugnet]

Hi,

On 02/09/2024 03:57, Louis-Philippe Véronneau wrote:

Thanks for the work you did trying to fix this issue.

Apparently I'm a Lintian maintainer now. I had a quick look at Lintian 
and lintian.debian.org is referenced in multiple places.


It seems like actually fixing lintian.debian.org will be faster and more 
productive than going wack-a-mole and trying to retcon it ever existing.


IF I were to do the job of getting DSA to spin a VM and point 
lintian.debian.org to it, I'd have to be confident you'll be maintaining 
the code you wrote in the future.


Please be honest :) I don't mind it at all if you tell me: "yeah, that 
was only a proof of concep", or "I'm motivated now, but I don't know if 
I'll still be in 3 years".


I definitely built it with maintenance in mind. I am willing to maintain 
this code for as long as possible, but I cannot guarantee that I will be 
able to do it forever!
I will be responsive if contacted by email or if an issue is created on 
the GitHub repository.


I also took the time to setup a CI with most of the code properly 
tested. This should allow to minimize future breakages when modifying 
the code.


If you aren't interested in maintaining that codebase for the next few 
years, I'll just steal some of your templates and rewrite everything in 
Python :P


One problem I forsee is that if that machine is hosted by DSA, we won't 
be able to call lintian directly, as everything will need to be 
installed from Debian packages and that machine will be running Debian 
Stable.


A way to fix this issue would be to point the static generator to a 
.json file instead.


Yes this would only imply very minor changes to the program. The 
question now would be where should be this file located and how/when/by 
whom would it be updated?


Another option I imagined would be to generate the website on another 
machine/VM that would run on testing/unstable and then rsync it to the 
production machine (which is what I am currently doing).


Anyways, don't hesitate to contact me if you have other specific needs 
to simplify the deployment of this website.


Thank you for your interest and time.
--
Nicolas Peugnet

Re: lintian.debian.org off ?

[Nicolas Peugnet]

On 03/09/2024 18:31, Louis-Philippe Véronneau wrote:

On 2024-09-02 10:45, Nicolas Peugnet wrote:

Hi,

On 02/09/2024 03:57, Louis-Philippe Véronneau wrote:

Thanks for the work you did trying to fix this issue.

Apparently I'm a Lintian maintainer now. I had a quick look at 
Lintian and lintian.debian.org is referenced in multiple places.


It seems like actually fixing lintian.debian.org will be faster and 
more productive than going wack-a-mole and trying to retcon it ever 
existing.


IF I were to do the job of getting DSA to spin a VM and point 
lintian.debian.org to it, I'd have to be confident you'll be 
maintaining the code you wrote in the future.


Please be honest :) I don't mind it at all if you tell me: "yeah, 
that was only a proof of concep", or "I'm motivated now, but I don't 
know if I'll still be in 3 years".


I definitely built it with maintenance in mind. I am willing to 
maintain this code for as long as possible, but I cannot guarantee 
that I will be able to do it forever!
I will be responsive if contacted by email or if an issue is created 
on the GitHub repository


I also took the time to setup a CI with most of the code properly 
tested. This should allow to minimize future breakages when modifying 
the code.


Great news! As proposed by Otto, one thing we could do would be to move 
the codebase to https://salsa.debian.org/lintian/lintian-ssg


If you're OK with this, I'll create an empty project and give you 
permissions on it.


I'm Ok with this, my username on salsa is @n-peugnet.

If you aren't interested in maintaining that codebase for the next 
few years, I'll just steal some of your templates and rewrite 
everything in Python :P


One problem I forsee is that if that machine is hosted by DSA, we 
won't be able to call lintian directly, as everything will need to be 
installed from Debian packages and that machine will be running 
Debian Stable.


A way to fix this issue would be to point the static generator to a 
.json file instead.


Yes this would only imply very minor changes to the program. The 
question now would be where should be this file located and 
how/when/by whom would it be updated?


Another option I imagined would be to generate the website on another 
machine/VM that would run on testing/unstable and then rsync it to the 
production machine (which is what I am currently doing).


Anyways, don't hesitate to contact me if you have other specific needs 
to simplify the deployment of this website.


Thank you for your interest and time.


I have a few other ideas, but I'll wait to see what issue tracker you 
want to keep :)


I am also OK with using the issue tracker of salsa.


FYI, I opened an RT ticket asking DSA for a VM to host all of this.


Thank you very much for this!
--
Nicolas Peugnet

Re: lintian.debian.org off ?

[Nicolas Peugnet]

On 03/09/2024 8:05 PM, Lucas Nussbaum wrote:

On 03/09/24 at 12:31 -0400, Louis-Philippe Véronneau wrote:

FYI, I opened an RT ticket asking DSA for a VM to host all of this.


Hi,

I still don't understand the long term strategy here.

UDD provides the same information. I recently did the work so that it is
properly indexed by search engines, see for example
https://www.google.com/search?q=archive-liberty-mismatch
(it will probably take some time to get indexed by other search engines)

What is the point in duplicating efforts?


I simply don't think they serve the same purpose. UDD lists the affected 
packages, which could be interested to some, but not to the persons that 
follow (currently broken) links to lintian.debian.org, as these links 
are present where one just want to see the explanation of the tag 
(mostly mentors.debian.org and lintian's CLI output).


IMO it is a lot more interesting to arrive on a simple and lightweight 
page that simply show the explanation.


The reasons I made another program was that:

1. Seeing that nothing was done for almost 1 year to fix this problem, I 
thought it was not going to be fixed anytime soon, and I didn't want to 
just complain about it, so I decided to make it myself
2. I don't know anything about ruby or perl, so I was not going to 
contribute to UDD
3. As the scope is a lot more contrained, it could be a Static Site 
Generator to make the pages fast to load


I see that by proposing something I motivated you to update UDD, this is 
good, but I still think it is interesting to leave them as separated 
projects. UDD is more appropriated to display statistics about affected 
packages, liantian.debian.org could then be a lightweight front page 
that simply shows the explanation.


Also I still think my proposition has advantages over the current state 
of the UDD tag pages. For example, I made sure that the URLs of the 
generated website match the existing links to lintian.debian.org and 
pages for renamed tags are generated to make sure old links are still 
valid. I added proper markup rendering of the explanation and a 
Debianish theme. And finally I added Lintian's manual (as there are 
links to that as well).


You could of course implement all that in UDD, but I am proposing a 
solution that is already done. Where would be the duplication of efforts 
then?

--
Nicolas Peugnet

Bug#1081737: ITP: lintian-ssg -- Static Site Generator for Lintian tags' explanations

[Nicolas Peugnet]

Package: wnpp
Severity: wishlist
Owner: Nicolas Peugnet 

* Package name: lintian-ssg
  Version : 1.0.0
  Upstream Author : Nicolas Peugnet
* URL : https://salsa.debian.org/lintian/lintian-ssg
* License : GPL-3.0
  Programming Lang: Go
  Description : Static Site Generator for Lintian tags' explanations

 A very simple static site generator that builds a Web version of
 Lintian tags' explanations,  based on the output of "lintian-
 explain-tags --format=json".

This package will be maintained with the Debian Lintian Maintainers team.

Bug#278442: RFH: athcool -- Enable powersaving mode for Athlon/Duron processors

[Nicolas Boullis]

Package: wnpp
Severity: normal

I request assistance with maintaining the athcool package.

The package description is:
 athcool is a small utility for enabling/disabling Powersaving mode
 for AMD Athlon/Duron processors.
 .
 By enabling Powersaving mode you can lower power consumption and
 CPU temperature when the CPU is idle.
 .
 Powersaving works only if your kernel supports ACPI (APM does not
 work), because athcool does only (un)set the "Disconnect enable when
 STPGNT detected" bits in the Chipset's Northbridge. To really save
 power, the STPGNT signal has to be sent when the CPU is idling. This
 is done by the ACPI subsystem when C2 state entered.
 .
 !!!WARNING!!!
 Depending on your motherboard and/or hardware components, enabling
 Athlon powersaving mode sometimes causes:
 .
  * noisy or distorted sound playback,
  * a slowdown in harddisk performance,
  * system locks or instability,
  * massive corruption of the filesystem (observed at least once).
 .
 If you met those problems, you should not use athcool. Please use
 athcool AT YOUR OWN RISK.
 .
 If athcool works fine for you, and you want it to run automatically
 on startup, please read the /usr/share/doc/athcool/README.Debian
 file.

Unfortunately, I only own one athlon-based system, which means I'm 
unable to test athcool on most supported systems. Hence, I'd like some 
volunteers to test athcool on as many different systems as possible, and 
to try to reproduce the bugs that are reported. If you own an 
athlon-based computer and want to help me with athcool, please send me 
an e-mail and tell me what kind of motherboard/CPU you own.

FYI, I currently need someone with a VIA KT600 or KT400 chipset to try 
to reproduce bug #276757 on both kind of systems.


Thanks in advance,

Nicolas Boullis

Bug#281759: general: Cannot 'eject' a CDROM as normal user

[Nicolas Boullis]

Hi,

On Wed, Nov 17, 2004 at 06:05:47PM +0100, Leszek Koltunski wrote:
> 
> So, the question is: why is /dev/hdc owned by 'disk' in Sarge? Does it
> have to be so for some reason? If not, I'd suggest to change that to
> 'cdrom' as it seems to help with ejecting...

I guess it is simply not owned by cdrom because /dev/hdc might as well 
be a hard drive (in which case giving read/write permission to users 
would be stupid ans unsecure).

On the other hand, if you were using a 2.6 kernel with udev, /dev/hdc 
would be owned by group cdrom (assuming it is a CD/DVD drive).


Regards,

Nicolas

removing in postrm rc*.d symlinks that I did not create

[Nicolas Boullis]

Hi folks,

A package of mine installs an init script. But as the corresponding 
programs plays with the motherboard's chipset configuration, it is quite 
prone to break the system. So I chose not to install rc*.d symlinks by 
default.

To make life easier for users, i explain in a README file how to set up 
those links and how to remove them with apdate-rc.d. Hence, when a user 
is convinced this program does not break his system, he can easily set 
up the links for automatic startup.

But a user felt concerned that, in the future, he may remove the package 
and forget to delete the links. Then I thought I could remove the links 
in postrm on purge, considering they are part of the package's 
configuration (their absence being the default configuration).

I built the package, but lintian complains:
E: athcool: postrm-contains-additional-updaterc.d-calls /etc/init.d/athcool
N:
N:   The postrm de-registers an /etc/init.d script which has not been
N:   registered in the postinst script before.

I lintian right here? Should I ignore this error? Any other suggestion 
to answer my user's concerns?


Thanks in advance for any feedback,

Nicolas

Re: removing in postrm rc*.d symlinks that I did not create

[Nicolas Boullis]

Hi,

On Wed, Dec 15, 2004 at 04:33:49PM -0800, Russ Allbery wrote:
> 
> A technique that I've used in packages with this issue is to install the
> rc*.d symlinks by default, but also have the init script check a file in
> /etc/default to see whether or not to actually start at boot.  If you
> install a default /etc/default file that says not to start, you accomplish
> the same thing, don't have this problem, and make it just as easy for
> users to enable the package.

Thanks for your suggestion.
I already thought about it, but I fnind it quite confusing when I cannot 
run /etc/init.d/foobar by hand as soon as it is not enabled on startup.


Cheers,

Nicolas

Re: removing in postrm rc*.d symlinks that I did not create

[Nicolas Boullis]

Hi,

On Wed, Dec 15, 2004 at 08:47:43PM -0600, John Hasler wrote:
> Your script should check $PRERUNLEVEL.  It will be N if you are booting.

That's a nice idea, but do you know how fine it would behave with 
things like file-rc?


Nicolas

Re: removing in postrm rc*.d symlinks that I did not create

[Nicolas Boullis]

Hi,

On Thu, Dec 16, 2004 at 09:32:08AM +0100, Javier Fernández-Sanguino Peña wrote:
> 
> Well, you could have a message saying that you need to enable foo and a
> 'force-start' action that started it regardless of what's in /etc/default.

That might be a solution. Users would certainly be less confused, but 
some scripts they would have written would still be...


> Moreover, the script could check if it's being called on startup (it's name 
> is 'S') and heed the default value and start anyway if called from the 
> command line.

I think such a solution was suggested in an ancient thread, and it was 
concluded that it would not work with file-rc...


> There are plenty of ways to avoid that confusion.

There certainly are some workarounds, but my initial question is still 
unanswered: is it ok to remove the links if I did not create them but 
told the user how to create them?


Nicolas

Re: removing in postrm rc*.d symlinks that I did not create

[Nicolas Boullis]

On Thu, Dec 16, 2004 at 12:53:27AM -0500, sean finney wrote:
> On Thu, Dec 16, 2004 at 12:34:21AM +0100, Nicolas Boullis wrote:
> > But a user felt concerned that, in the future, he may remove the package 
> > and forget to delete the links. Then I thought I could remove the links 
> > in postrm on purge, considering they are part of the package's 
> > configuration (their absence being the default configuration).
> 
> if the package is removed, the init script should just exit with 0
> status.  removing the links during purge would also be appropriate.

So you think lintian is wrong to complain?


> you could also install the links by default, but have some other
> variable in /etc/default/$package control whether or not it actually
> starts (i think somebody else has mentioned this too).

Yes, I know such solutions but don't like them much. But if "my" 
solution is proved to be wrong, I'll implement such a workaround...


Nicolas

Re: removing in postrm rc*.d symlinks that I did not create

[Nicolas Boullis]

Hi,

On Thu, Dec 16, 2004 at 09:13:43AM +0100, Adrian von Bidder wrote:
> On Thursday 16 December 2004 00.34, Nicolas Boullis wrote:
> [de-installing run-level links that weren't installed]
> 
> How about installing links as /etc/rc?.d/K??foo - so the links are there and 
> are properly manageable, but the init script will only be called as 'K??foo 
> stop'

Unfortunately, athcool is not a deamon but a program that modifies some 
low-level configuration. Hence, running "/etc/init.d/athcool stop" 
actually does something (and might break the system) as badly as 
"/etc/init.d/athcool start"...

I like the idea, but I'm afraid it's not appropriate for athcool, at 
least without reworking the init script...


Cheers,

Nicolas

DD needing a sponsor to upload

[Nicolas Boullis]

Hi,

As I moved recently, I currently have no decent Internet connectivity. 
Hence, I'm quite unable to keep an unstable system up-to-date, si I 
can't build packages to upload. Several packages of mine are in need of 
an upload, especially libcdio and vcdimager. I have uploaded the source 
packages to my debian homepage on http://people.debian.org/~nboullis. 
Could someone please build the binary packages and upload for me?
(As far as I know source-only uploads are not allowed, and anyway, I 
can't be sure it'll work fine with an up-to-date sid; I only tested with 
a one month old sarge.)


Thanks in advance,

Nicolas Boullis


PS: please CC your replies to me (MFT set accordingly) as I currently 
can't track d-d.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DD needing a sponsor to upload

[Nicolas Boullis]

Hi,

On Sun, Feb 06, 2005 at 08:53:52PM +1100, Anibal Monsalve Salazar wrote:
> Changes:
>  vcdimager (0.7.21-1) unstable; urgency=low
>  .
>* New upstream release.
>* Rebuild against libcdio3 and libiso9600-3.
>* Hack ltmain.sh to build programs with rpath as .libs/lt/foobar rather
>  than .libs/lt-foobar.
>* Regenerate the manpages accordingly.
> 
> Does the new vcdimager version fix the RC bug #290685?

You're quite right, I somehow forgot the Closes: parts in the 
changelog... I just reuploaded the source package. Would you build and 
upload for me?


Cheers,

Nicolas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

self-depending packages

[Nicolas Boullis]

Hi,

Trying to upgrade a woody system to sarge, I experienced problems 
upgrading libgtk2.0-0, and discovered that this packages was 
self-depending. Afetr forcing the upgrade with "dpkg -i --force-depends", 
everything went smoothly. So I filed a bug against libgtk2.0-0.
Then I discovered that I could upgrade this package from woody to sarge 
with no trouble in a clean pbuilder chroot. So the problem might me more 
complex.

However, from this bug report began a discussion with Loic Minier about 
self-dependencies and circular dependencies.

Readibg policy 7.2, I see:
"
Depends
This declares an absolute dependency. A package will not be 
configured unless all of the packages listed in its Depends field 
have been correctly configured.
"

My understanding is that a self-depending package must be configured 
before it can be configured, which makes it unconfigurable, and hence 
uninstallable. And I think the same reasoning can be applied to 
circular dependencies. But Loic disagrees.

What is the opinion of others? Shouldn't policy be more explicit about 
circular (and self) dependencies?


Moreover, I just wrote a small python script that looks for 
self-dependencies in sarge, and found those packages:
libtabe2
libtextwrap1
gnustep-back
libbonoboui2-0
libgail-common
libbonobo2
libgtk2.0-0

Should a bug be filed against those packages?


Cheers,

Nicolas


PS: please CC your replies to me, as I am currently quite unable to 
track debian-devel. (MFT set accordingly)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Spliting packages between pkg and pkg-data

[Nicolas Boullis]

On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote:
> Hello Debian developers,
> 
> When doing research about circular-deps, I looked at a lot of packages
> that are split between a binary package and a data package. This is a
> good thing since this reduce the total siez of the archive, however
> there are simple rules that should be followed:
> 
> 3) Keep the files that 'signal' executables in the same package than the
>executable (e.g. menu file, program manpage).

Why? I agree that it menu files and manpages are generally not that 
large, but what would it break to have them in pkg-data?
(I would consider it strange to have such files out of the main pkg 
package, but it looks policy-compliant as far as I can see...)


Nicolas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Spliting packages between pkg and pkg-data

[Nicolas Boullis]

Hi,

On Sun, Nov 20, 2005 at 12:39:24PM -0800, Russ Allbery wrote:
> Nicolas Boullis <[EMAIL PROTECTED]> writes:
> > On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote:
> 
> >> 3) Keep the files that 'signal' executables in the same package than the
> >>executable (e.g. menu file, program manpage).
> 
> > Why? I agree that it menu files and manpages are generally not that 
> > large, but what would it break to have them in pkg-data?
> > (I would consider it strange to have such files out of the main pkg 
> > package, but it looks policy-compliant as far as I can see...)
> 
> Well, one practical concern is that it makes it harder for other utilities
> like lintian to analyze the package properly.

Well, that's an argument I don't like. Those are tools that help us 
check our packages are correct, but I don't think it is reasonable to 
modify otherwise correct package only to make such tools happy. For the 
same reason, I'm not happy with setting lintian overrides, as I consider 
it bloats the packages for no good reason (although the "bloat" is very 
limited").


Cheers,

Nicolas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Advices for an su transition

[Nicolas François]

Hello,

On Sun, Nov 06, 2005 at 11:14:39PM +0100, Nicolas François wrote:
> 
> We would now like to get rid of this bug. What do you recommend:
>  * keep a Debian specific implementation and tag this bug wontfix
>  * reapply the patch to fix this bug, and report bugs on the packages that
>uses this "feature"

I've not seen a strong opposition to the second choice.


We now need some advices to perform this transition.

Junichi proposed to keep the current behavior when an environment variable
is set (I would prefer something different from POSIXLY_CORRECT). The
support for this environment variable could then be dropped after Etch.

The change will have to be announced (here and in NEWS) and documented.
(Basically, -c's argument is a command executed in the shell, other
arguments given after '--' are provided to the shell, not to the command)


Another step is to find which packages won't work with this change, get
them fixed and upload a new login which conflicts with their previous
versions.

I think such softwares won't run with upstream's su (i.e. at least Redhat
and Gentoo), GNU's su (coreutils), FreeBSD's su (and OpenSolaris' su).
So I hope only Debian specific packages or Debian maintainers' scripts
will be affected.

At this time we are aware of:
 * pbuilder (not true anymore)
 * dchroot
   dchroot synopsis is: dchroot [OPTION...] [COMMAND]
   it passes its arguments to su. -c is not provided.
   COMMAND needs to be a single argument.

There are no dependencies on login, so I don't see anything else than a
grep on the 2 letters "su" (\ may help).

IIRC people from debian-audit have some tools to perform such grep on the
source package with some heuristics to extract and patch the sources
(dpatch, cdbs, ...), and ignore the documentation files (e.g. "su" is a
common word in spanish).
I have no idea of the size of such grep output.


Does anybody have another idea?

Kind Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Advices for an su transition

[Nicolas François]

On Sun, Nov 20, 2005 at 06:22:16PM -0600, Bill Allombert wrote:
> 
> Actually looks here: 
> 
> The full data is available on merkel.debian.org in ~ballombe/menu/supackages.

Thanks a lot!

At least all these maintainer scripts seems OK.

I can probably check all the native packages now.

Best Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Experimental or unstable.

[Nicolas François]

On Thu, Jan 05, 2006 at 02:03:37PM +, Simon Huggins wrote:
> On Thu, Jan 05, 2006 at 02:44:38PM +0100, Adeodato Simó wrote:
> > * Marc Haber [Thu, 05 Jan 2006 14:40:45 +0100]:
> > > Experience with adduser shows that no-one besides the maintainers
> > > themselves and their closest environment uses experimental packages.
> >   More evidence:
> > http://www.perrier.eu.org/weblog/2005/09/30#experimental-useless
> 
> See this worries me a bit.
> 
> I'd love for Debian users to test some more cutting edge versions of
> packages (partly so upstream gets more testers, partly so I can see the
> bits I hate about the new versions and try to get them fixed) but I
> don't want them in testing now until they are properly released as a
> stable series.  In fact, I don't really want them in unstable if it
> means that in order to fix bugs which appear in testing I have to revert
> to the stable set of packages in order to get them in.

How Debian users can know there is a new version in experimental?
There are some messages in debian-devel, or blogs on planet, but not all
users or developers are reading them.

Is there a command that can display the list of packages I'm using with a
version on experimental higher than the current version on unstable?

(I'm willing to test some experimental packages, but on a case by case
basis, not by pinning up experimental)

Best Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Experimental or unstable.

[Nicolas François]

On Thu, Jan 05, 2006 at 01:13:05PM -0500, Travis Crump wrote:
> > Is there a command that can display the list of packages I'm using with a
> > version on experimental higher than the current version on unstable?
> 
> `aptitude -t experimental`

That's neat!

> I love aptitude :)

I love it even more since a few seconds.

Thanks,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#353051: ITP: pootle -- Web-based translation and translation management tool

[Nicolas François]

Package: wnpp
Severity: wishlist
Owner: "Nicolas François" <[EMAIL PROTECTED]>


* Package name: pootle
  Version : 0.6.3.20060126
  Upstream Author : David Fraser, translate.org.za
* URL : http://sourceforge.net/projects/translate
* License : GPL
  Description : Web-based translation and translation management tool

 Pootle provides a rich set of features for managing a translation
 project.  It integrates components of the Translate Toolkit to provide
 error checkers for translation messages and the ability to download files
 in a number of formats: PO, XLIFF, CSV.  Pootle can also provide compiled
 PO files for download. You can use it to assign work to translators in
 your team, and you can define goals to help focus the efforts of your
 translation.  Pootle can run without a Web server or be proxied through
 your existing Apache server.  The Translate Toolkit is a set of software
 and documentation designed to help make the lives of localizers both more
 productive and less frustrating.
 .
 Homepage: http://translate.sourceforge.net/


Note: a pootle package existed and was recently renamed translate-toolkit.
I will (first) package 0.6.3.20060126, because it matches the current
translate-toolkit package (0.8.rc6-1).

-- 
Nekral

Announcing changes in su

[Nicolas François]

Hello,

Introduction

As reported in #276419, su in the login Debian package doesn't permit to
specify options to the invoked shell and doesn't respect quoted arguments.
We plan to revert this behavior and follow su's documentation and other
implementations.


Short details
=
Packages passing a command in argument to su must use su's -c option
and must quote the command if it contains a space.
For example:
  su - root -c "ls -l /"

The following commands won't work anymore:
  su - root -c ls -l /
  su - root "ls -l /"
  su - root ls -l /

There will be no problems for backports. -c can be used and arguments
quoted, with the past and future versions.

Needed adaptations
==
We tried to find the packages that will be affected by this transition.
We did not audit the full archive, but focused on [1]:
 * maintainer scripts [2]
 * packages with an init.d script (based on a sid Contents-i386)
 * packages with an cron script (based on a sid Contents-i386)
 * native packages (on sid i386)
(In general, archives embedded in source packages were not checked)

Package needing changes
---
Micah Anderson <[EMAIL PROTECTED]>
backupninja-0.9.2/handlers/pgsql
backupninja-0.9.2/handlers/mysql
backupninja-0.9.2/examples/example.rdiff
Raphael Bossek <[EMAIL PROTECTED]>
python-4suite-0.99cvs20051115/debian/python-4suite-server.init.d
Phil Brooke <[EMAIL PROTECTED]>
yiff-2.14.2/build_and_install
Arnaud Kyheng <[EMAIL PROTECTED]>
gnunet-0.7.0b/contrib/init_gnunet_ubuntu
Brian May <[EMAIL PROTECTED]>
amavisd-new-2.3.3/debian/amavisd-new.cron.daily
Peter Palfrader <[EMAIL PROTECTED]>
echolot-2.1.8/debian/echolot.init
Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]>
samhain-2.0.10a/init/samhain.start.in

To be checked
-
Roderick Schertler <[EMAIL PROTECTED]>
debget-1.5/debget
(It should be OK. According to the code, it works with GNU su)

maybe
-
Stefan Hornburg (Racke) <[EMAIL PROTECTED]>
courier-0.52.1/courier.lpspec(.in)? (maybe not used on Debian)
courier-0.52.1/courier.spec(.in)? (maybe not used on Debian)
Kenneth J. Pronovici <[EMAIL PROTECTED]>
cedar-backup2-2.7.2/CedarBackup2/peer.py (depends on executeCommand)
Arnaud Quette <[EMAIL PROTECTED]>
nut-2.0.2/scripts/HP-UX/nut-drvctl.sh (maybe not used on Debian)
nut-2.0.2/scripts/HP-UX/nut-upsd.sh (maybe not used on Debian)
Taku YASUI <[EMAIL PROTECTED]>
murasaki-0.8.11/scripts/printer (su $USER -c $CMD, $CMD may have a 
space)
Debian Webmin maintainers <[EMAIL PROTECTED]>
usermin-1.160/cron/config-aix (maybe not used on Debian)
usermin-1.160/web-lib-funcs.pl
usermin-1.160/shell/index.cgi
usermin-1.160/fetchmail/check.pl
usermin-1.160/commands/run.cgi
usermin-1.160/postgresql/postgresql-lib.pl
webmin-1.230/web-lib-funcs.pl
webmin-1.230/cron/config-aix
webmin-1.230/custom/run.cgi

In comments or documentation

Clint Adams <[EMAIL PROTECTED]>
bricolage-1.8.8/bin/bric_ftpd
Joel Aelwyn <[EMAIL PROTECTED]>
debpool-0.2.2/debian/README.User
Debian Qt/KDE Maintainers 
kdenetwork-3.5.0/kopete/protocols/meanwhile/README
Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
cyrus21-imapd-2.1.18/debian/cyrus21-common.postinst
Robert Jordens <[EMAIL PROTECTED]>
remstats-1.0.13a/INSTALL
remstats-1.0.13a/docs/book.tex (and other formats)
remstats-1.0.13a/docs/install-user.pod
remstats-1.0.13a/docs/install.pod
remstats-1.0.13a/docs/install.txt
Matthias Klose <[EMAIL PROTECTED]>
sqlrelay-0.36.4/doc/gettingstarted/interbase.html
Guus Sliepen <[EMAIL PROTECTED]>
dhis-client-5.3/README
Craig Small <[EMAIL PROTECTED]>
lprng-3.8.28/DOCS/LPRng-Reference.html
lprng-3.8.28/DOCS/LPRng-Reference.sgml
lprng-3.8.28/DOCS/LPRng-Reference-Multipart/x9198.htm
Jonas Smedegaard <[EMAIL PROTECTED]>
pop-before-smtp-1.36/contrib/README.rootless-install

Transition plan
===
A package will be first available for testing on experimental.
If you know that your package uses su, it would be nice if you could test
it with the login package (which will be uploaded) on experimental.

The SU_NO_SHELL_ARGS environment variable will restore the previous
behavior. The support for this variable should be dropped after Etch.

login will conflict with the package of the first category. When fixed,
these packages do not need a versionned dependency on login.


Recommandation
==
You should follow the following synopsis for your su commands.
(This will give you more chance to be portable and to work on
POSIXLY_CORRECT environments)

su [options] [-] [username [args]]

[args] are arguments passed to the shell

Specifically:
 * It is preferable to provide -c in [args] rather than in [options].
 *

How to find really old source of the shadow package

[Nicolas François]

Hello,

I'm looking for really old sources of the shadow package.
With http://snapshot.debian.net, the latest I can find is 2902-12
(2002/06/04).

Does anybody know where I can find older sources?

TIA,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

dhcp-client package in sarge

[Nicolas Kreft]

Hi List!


Is it for a special reason that the default dhcp-client
in sarge is ancient (version 2.0pl5)?

This client does not follow the RFC correctly. When
it does a dhcpdiscover and the interface has been
previously configured with some ip address it is still
using that ip for the dhcpdiscover. This causes the
dhcp server (3.0.2) on my network to abandon that ip address.

The 3.x series has been released nearly 4 years ago,
why not make it the default?



regards,
Nicolas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation

[Nicolas Schoonbroodt]

So...(sorry for English)
lot of conversation about my plugin on your mailling list.

And also a bug report on sourceforge, related to your remark.
My message will be not complete (because it's 4.50 am here and that I
must be at school at 8am)

First of all, you speak of tex2im depandency. This is not needed since
version 0.3. Now I make the next system calls :
(yep, it's not a good way, for example if /tmp doesn't exist for example)
FILE_SOMETHING represent /tmp/gaimTeX.something

chdir("/tmp")
system("latex -interaction=nonstopmode " FILE_TEX)
system("dvips -o" FILE_PS " -E " FILE_DVI)
system("convert " FILE_PS " " FILE_PNG)

and finaly a I do a
system("rm -rf /tmp/GaimTeX.*") somewhere

If you can tell me where you find the tex2im depandancy (README,
INSTALL, ...) It can help me for remove it in the next version.

Now, about the security problem...

Yes, I know it's possible to have some problems with latex call. But If
someone send
$$\input{/etc/passwd}$$
he will see (at best) the local /etc/passwd file, and the receiver, the
local /etc/passwd. So not the same.

And in reality, he well see nothing. One of the (the principal?) author
of kopeteTeX (which is compatible, for respond to one of the first
question)(the develloper is Olivier Goffart) as given me an advice, that
was to blacklist some command.

I have blacklisted the same command than kopetetex, that is :
> #define NB_BLACKLIST (42)
> #define BLACKLIST 
> {"\\def","\\let","\\futurelet","\\newcommand","\\renewcomment","\\else","\\fi","\\write","\\input","\\include","\\chardef","\\catcode","\\makeatletter","\\noexpand","\\toksdef","\\every","\\errhelp","\\errorstopmode","\\scrollmode","\\nonstopmode","\\batchmode","\\read","\\csname","\\newhelp","\\relax","\\afterground","\\afterassignment","\\expandafter","\\noexpand","\\special","\\command","\\loop","\\repeat","\\toks","\\output","\\line","\\mathcode","\\name","\\item","\\section","\\mbox","\\DeclareRobustCommand"}

So (in normal case) all of this command will not be "authorised"
(in fact, if you send a message like :
normal text \input in normal text $$equation$$ normal text $$equation $$
(or with the blacklisted command in the $$equation part$$) the message
_will not_ be transform using latex compiler. (with the is_blacklisted
function)

If some other command have to be blacklisted, I hear you.

If you have any suggestion with security problem (for example error in
my code, or latex hack to "eviter" (french word, don't know in English)
this security), you can continue the discussion here, I will read it.

Also other bug can be posted on sourceforge, for example.

Nicolas Schoonbroodt


signature.asc
Description: OpenPGP digital signature

Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation

[Nicolas Schoonbroodt]

Bill Allombert wrote:
> When I spoke of security nightmare, this was exactly what I had in mind.
> You will never find a blacklist of command that prevent abuse, and the
> current certainly does not. For example \usepackage and \documentclass
> are not blacklisted so the attacker can load add-on packages that can
> add potentially dangerous commands.
I think no. My plugin insert \begin{document} before and \end{document}
after LaTeX code. And I have try to compile some files with more than
one document environement, that just compile the first document,
ignoring all after he first \end{document}. Because we have to put
\usepackage between \documentclass and \begin{document}. So we can't add
a package (but I'm not a LaTeX guru, if you can do that, I hear to you)
>
> I could not make sense of the criterium used for blacklisting,
> e.g. why blacklisting \mbox ? Why blacklisting \section but not
> \subsection ? why blacklisting \newcommand but not \newenvironment ?
I've copy pas blacklist from kopeteTeX Kopete's plugin... so... he's in
debian stable, and the way to make image is the same, ...
(http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=kopete&version=stable&arch=i386
)
I think mbox is blacklisted, because gaim can render text alone,
section/subsection I don't know, \newcommand make new commands, and
newenvironnement make new environnement. The difference between the two
is that newenvironnement has to use existing commands (I think), so if
it use dangerous command, they have to be blacklisted.

One more time, I suppose your very better than me in security domain (I
have no special skills in computer science, I'm just a student not in
computer domain, who can write a little code)

>
> You can try the whitelist approach, but LaTeX was not written with this
> security requirement in mind so this is still potentially unsafe.
Yep, it's possible. I didn't write this to be "the most secure plugin to
write math" but just to have an easy way to explain some math/physik
things to friends. If he didn't go in "official" linux distribution,
that's not a problem. People who want such a thing can find it and
install it alone, with own risk.

Cheers

PS : sorry Bill Allombert, I just see that I have posted this to you not
to the mailling list


signature.asc
Description: OpenPGP digital signature

Videos of the internationalization meeting in Extremadura

[Nicolas François]

Hello,

The first Debian Internationalization meeting took place from September
7th 2006 to September 9th 2006 in Casar de Caceres, Extremadura,
Spain.

This mail follows the announcement of the final report:
http://lists.debian.org/debian-devel-announce/2006/09/msg00012.html

The meeting was recorded and the videos are now available on:
http://meetings-archive.debian.net/pub/debian-meetings/2006/i18n-extremadura/

Kind Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: db.debian.org (and related infrastructure) updates

[Nicolas Boullis]

Hi,

On Sat, Dec 30, 2006 at 04:31:12PM +0100, Joerg Jaspert wrote:
>  - the birthDate field isn't currently available via the mail daemon,
>this will be fixed soon.

What about gender? How is it specified?
with a ldapsearch, I can find 1, 2 and 9...


Cheers,

Nicolas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: System users and valid shells...

[Nicolas François]

On Wed, May 03, 2006 at 01:48:33PM +0200, Javier Fernández-Sanguino Peña wrote:
> 
> In any case, you could use noshell (already available in Debian) or nologin
> (see #298782) instead of /bin/false.

nologin is now distributed with login.
I've closed the ITP.

Kind Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#375412: ITP: vdr-plugin-dxr3 -- Plugin to vdr to use a DXR3/Hollywood+ MPEG decoder as primary interface

[Nicolas Boullis]

Package: wnpp
Severity: wishlist
Owner: Nicolas Boullis <[EMAIL PROTECTED]>

* Package name: vdr-plugin-dxr3
  Version : 0.2.6
  Upstream Author : Kai Moeller <[EMAIL PROTECTED]>,
Stefan Schluenss <[EMAIL PROTECTED]>,
Christian Gmeiner ,
...and numerous others, see CONTRIBUTORS.
* URL : http://sourceforge.net/projects/dxr3plugin/
* License : GPL
  Programming Lang: C++
  Description : Plugin to vdr to use a DXR3/Hollywood+ MPEG decoder as 
primary interface

 This plugin for vdr allows using a DXR3/Hollywood+ MPEG 
 decoder card as primary interface.


This package will be maintained within the "Debian VDR Team <[EMAIL 
PROTECTED]>".

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental'), (500, 
'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.1-irma
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#378167: ITP: sudoku -- console based sudoku

[Nicolas François]

Package: wnpp
Severity: wishlist
Owner: "Nicolas François" <[EMAIL PROTECTED]>


* Package name: sudoku
  Version : 1.0.1
  Upstream Author : Michael Kennett
* URL : http://www.laurasia.com.au/sudoku/
* License : Public Domain
  Programming Lang: C
  Description : console based sudoku

 This sudoku puzzle generator/solver features:
  * character based (curses) interface;
  * cross-platform (Minix, Unix, Windows) with full source code (ANSI C);
  * generates hints upon request;
  * classification of board difficulty (very easy, easy, medium, hard or
fiendish);
  * generation of new boards;
  * easy entry of boards published in newspapers, internet, etc...;
  * multiple output formats (text,csv,html,postscript).
 .
 Homepage: http://www.laurasia.com.au/sudoku/


There are already some other sudoku puzzle packaged in Debian.
This one do not requires an X environment.

I will need a sponsor to have it uploaded.

Kind Regards,
-- 
Nekral

Re: Bug#378167: ITP: sudoku -- console based sudoku

[Nicolas François]

On Fri, Jul 14, 2006 at 05:34:16PM +0200, Nacho Barrientos Arias wrote:
> Nicolas François <[EMAIL PROTECTED]> wrote:
> 
> > Package: wnpp
> > Severity: wishlist
> > Owner: "Nicolas François" <[EMAIL PROTECTED]>
> > 
> > 
> > * Package name: sudoku
> 
> Isn't this package name too general? I know that the upstream name is
> this but, can't be (this name) improved to became an official Debian
> package?
> 
> Not more than a suggestion,

I would have prefered a suggestion ;)

Would sudokurse be better?
Should the binary be renamed too?

Kind Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Braille devices

[Nicolas Pitre]

enote, people used to their good old DOS TSR for their
braille/speech hardware could have a look at DOSgate
(http://www.cs.unibo.it/~zinie/dosgate/).  It lets you access the Linux
console transparently through a dosemu session using your DOS adaptation
tools.  This might be an alternative to the lack of native Linux support
for some hardware... or lack of good enough Linux screen reader package
for one's taste.


Nicolas

Re: Braille devices (the problem was DOSemu)

[Nicolas Pitre]

On Sun, 20 Aug 2000, VZW AUDIO/BRAILLE wrote:

> Hi all,
> In my specific case where I wasn't able to run a Alva ABT280, this was the
> hardware problem + this should be the solution:
> - the problem: the DB9 connector on the rear panel didn't have the function
> of serial connection for the device; so the only way for the ABT280 was
> the parallel port. (No spex from factory, as Nicolas Pitre explained).
> But Dosgate, see http://www.cs.unibo.it/~zinie/dosgate uses DOSemu, and
> DOSEMU IS NOT IMPLEMENTED FOR PARALLEL PORT.

Please read carefully the documentation for dosemu!

You can configure it so dosemu (and the Linux kernel) lets DOS
applications access the parallel port hardware directly.  I used an Alva
ABT340 over the parallel port that way in the past.


Nicolas

Re: Packages file under version control

[Nicolas Kratz]

On Tue, Jun 03, 2003 at 10:04:16AM +0200, David Weinehall wrote:
> No.  Fetching Packages.gz over modem is a pain in the arse.  Having it
> only rsync the changes would be so nice.

Try apt-rsync.

http://home.worldonline.cz/~cz210552/

HTH,
Nick

-- 
x--x
|  What your soldier wants -- really, really wants --  |
|is no-one shooting back at him.   |
| (Terry Pratchett, alt.fan.pratchett) |
|--|
| Nicolas Kratz <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> |
x--x


pgpDWyn6wMvbp.pgp
Description: PGP signature

Re: About NM and Next Release

[Nicolas Bertolissio]

Le jeudi  7 août 2003, Goswin von Brederlow écrit :
> Chris Cheney <[EMAIL PROTECTED]> writes:
[...]
> > Also, it seems like most DD's don't maintain many packages anyway. Yes
> > there are other things that a DD can do other than just maintain
> > packages, like help with web translations, boot floppies, etc. But nearly
[...]
> And for translations, doesn't the automatic translation mechanism
> (that sends you package descriptions to translate) only for for DDs?
> Not sure though since I know I can't be trusted to translate stuff.
[...]

Are you talking about the DDTS? you don't need to be a DD to translate
and proofread translations. Just send mails to the server (and use ddtc
and acheck if you want to make your job easier).

Translating and proofreading, wml, po and others, do not require you to
be a DD, at least, not for the French team, and it works very well like
this.


Nicolas Bertolissio
-- 

Re: About NM and Next Release

[Nicolas Bertolissio]

Le jeudi  7 août 2003, Goswin von Brederlow écrit :
> WE NMs WANT FEEDBACK. Someone please tell the DAM already to activate
YOU, not 'we', YOU are impatient, YOU are cannot wait any more,
I am waiting for DAM approval, so I just wait...


Nicolas Bertolissio
-- 

Re: About NM and Next Release

[Nicolas Bertolissio]

Le jeudi  7 août 2003, Jamin W. Collins écrit :
[...]
> Are you saying that you do not want, and would not welcome,
> feedback on your application?
No,

> I'm not asking whether you would clamor
> for updates, but whether receiving them would be a problem for you?
No, but I don't need any, I just have to wait, as written on the web
page...


Nicolas
-- 

Hungarian DDTP on the Xth B'day

[Nicolas Bertolissio]

Hi all,

The main goal of this party was to translate Debian package descriptions.
Unfortunately Gluck, where the ddts server is, was down quite a long
time and installing a local server was not so easy as it was the first
time I did this.  The local server was up only a few minutes before Gluck
come back.

Anyway, this experience let me find a bug in the server and so was quite
interresting.


I would like to thanks everyone at Budapest for the good time I spend
there for the Debian 10th birthday last week-end.


Regards


Nicolas Bertolissio
-- 


pgpFYJzwywa09.pgp
Description: PGP signature

Bug#208522: ITP: sneps -- Semantic Network Processsing System

[Nicolas Sabouret]

Package: wnpp
Severity: wishlist

* Package name: sneps
  Version : 2.6.0
  Upstream Author : Stuart C. Shapiro <[EMAIL PROTECTED]>
* URL or Web page : http://www.cse.buffalo.edu/sneps/
* License : GPL
  Description : Semantic Network Processsing System

Re: /etc/shells management

[Nicolas François]

On Mon, Sep 08, 2003 at 03:48:37AM -0500, Branden Robinson wrote:
> I do continue to think that:
> 
> if [ -n "$var" ]
> 
> is more readable than
> 
> if [ "${var+set}" = "set" ]

both are not equivalent:
  the first one test if var is empty or unset
  the second one test if var is unset

with bash:
  $ a="1"  ; [ -n "$a" ] && echo "a is not empty"
  a is not empty
  $ a=""; [ -n "$a" ] && echo "a is not empty"
  $ unset a ; [ -n "$a" ] && echo "a is not empty"
 and:
  $ unset a ; [ "${a+set}" = "set" ] && echo "a is set"
  $ a=""; [ "${a+set}" = "set" ] && echo "a is set"
  a is set
  $ a="1"   ; [ "${a+set}" = "set" ] && echo "a is set"
  a is set

IMO, [ -n "$var" ] is equivalent to [ "${var:+set} = "set" ].

The first form seems to be more readable and less error prone :)

PS: what is the simplest way to test if a variable is set?
-- 
Nekral

Re: Building kernel modules for stock kernels is a hell of a job!

[Nicolas Boullis]

Hi,

On Mon, Sep 29, 2003 at 01:43:05PM -0400, David Z Maze wrote:

> I don't consider it a bug.  I do think the kdist and kdist_image
> targets should reinvoke make under $(ROOT_CMD), though, just to be
> sure.  The i2c-source debian/rules file has:
> 
> kdist_image:
> $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules binary-modules
> $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean
> 
> kdist:
> $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules binary-modules
> dpkg-genchanges -b -e"$(KMAINT) <$(KEMAIL)>" -u"$(KSRC)/.." > 
> $(CHFILE)
> debsign -e"$(KMAINT) <$(KEMAIL)>" $(CHFILE)
> $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean
> 
> kdist_clean:
> $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean

Are those $(MFLAGS) really useful?
I thought they were not because $(MAKE) also had the flags, but I'm not 
sure anymore...


Regards,

Nicolas

Re: Building kernel modules for stock kernels is a hell of a job!

[Nicolas Boullis]

Hi,

On Tue, Sep 30, 2003 at 12:27:29AM +0200, Eduard Bloch wrote:

> > > kdist_clean:
> > > $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean
> > 
> > Are those $(MFLAGS) really useful?
> > I thought they were not because $(MAKE) also had the flags, but I'm not 
> > sure anymore...
> 
> MFLAGS are the flags that make got on the commandline. The calls above
> copy the make call with options.

Well, I just checked the gnu make manual (section 5.6.3) and, if I 
understand it correctly, it says that using $(MFLAGS) is now useless 
thanks to the $(MAKEFLAGS) variable...


Is there something wrong with my inderstanding of this manual? Or is 
this a gnu-only feature, that we should not depend on?


Regards,

Nicolas

A new way to specify versionned dependencies may be needed

[Nicolas Boullis]

Hi,

One package of mine needs to conflict with a few consecutive versions 
of a package. Let's say that the package foo introduced a feature that 
conflicts with my package in version A and removed it in version B.

So I'd like my package to conflict with versions A to B of foo. I tried 
to specify it with "Conflicts: foo (>> A), foo (<< B)" but, as I feared, 
it does not work since it now conflicts both with all versions >> A and 
with all versions << B (as A << B, that means all versions).

Is there a way to specify such a conflict? Listing all the versions 
would work, but that's not really convenient... Any suggestion is 
welcome.

Hence, I think a new way to specify versionned relationship between 
packages might be useful. For example, the conflict I need might be 
written as "Conflicts: foo (>> A, << B)". Is such a feature planned for 
the future? It's certainly too late to have something for sarge, so it 
certainly won't be implemented before sarge+1, and we won't be able to 
use it before sarge+2.

Currently, there's no need for such a feature for positive dependencies 
(Depends, Recommends and Suggests), because there is a workaround:
"Depends: foo (>> A), foo (<< B)" works for "Depends: foo (>> A, << B)",
but it only works because only one version of foo can be installed at a 
time. If versionned provides are ever implemented, it may become 
possible to have several versions of a package at a time, thus breaking 
this workaround.


Any comment?

Nicolas

Re: A new way to specify versionned dependencies may be needed

[Nicolas Boullis]

Hi,

On Fri, Oct 03, 2003 at 09:19:39AM +0200, Dagfinn Ilmari Mannsåker wrote:

> > So I'd like my package to conflict with versions A to B of foo. I tried 
> > to specify it with "Conflicts: foo (>> A), foo (<< B)" but, as I feared, 
> > it does not work since it now conflicts both with all versions >> A and 
> > with all versions << B (as A << B, that means all versions).
> 
> How about "Depends: foo (<< A) | foo (>> B)"?

No, my package does not depend in any way on foo. Depending on foo only 
to prevent a few specific versions of foo to be installed would be evil, 
AFAICS...

> > Currently, there's no need for such a feature for positive dependencies 
> > (Depends, Recommends and Suggests), because there is a workaround:
> > "Depends: foo (>> A), foo (<< B)" works for "Depends: foo (>> A, << B)",
> > but it only works because only one version of foo can be installed at a 
> > time. If versionned provides are ever implemented, it may become 
> > possible to have several versions of a package at a time, thus breaking 
> > this workaround.
> 
> The above will also break if versioned provides are implemented.

Which "The abobe"? Your "Depends: foo (<< A) | foo (>> B)"? Or my 
"Depends: foo (>> A, << B)"? I can't see why mine would be broken. Did I 
miss something?


Regards,

Nicolas

Re: A new way to specify versionned dependencies may be needed

[Nicolas Boullis]

(Sorry Daniel for first sending this e-mail to you only by mistake.)

Hi,

On Fri, Oct 03, 2003 at 04:06:42PM -0400, Daniel Jacobowitz wrote:
> On Fri, Oct 03, 2003 at 09:55:09PM +0200, Nicolas Boullis wrote:
> > Hi,
> > 
> > On Fri, Oct 03, 2003 at 09:19:39AM +0200, Dagfinn Ilmari Mannsåker wrote:
> > 
> > > > So I'd like my package to conflict with versions A to B of foo. I tried 
> > > > to specify it with "Conflicts: foo (>> A), foo (<< B)" but, as I 
> > > > feared, 
> > > > it does not work since it now conflicts both with all versions >> A and 
> > > > with all versions << B (as A << B, that means all versions).
> > > 
> > > How about "Depends: foo (<< A) | foo (>> B)"?
> > 
> > No, my package does not depend in any way on foo. Depending on foo only 
> > to prevent a few specific versions of foo to be installed would be evil, 
> > AFAICS...
> 
> The best extant solution to this is just to Conflicts: foo (<= B). 
> Forcing an upgrade isn't such a bad thing...

Well, that depends. For example, if testing as a version << A of foo, 
and we are getting close to a release, conflicting with that version for 
no good reason would be somewhat broken. (That's roughly the current 
situation with foo=dvb-dev, A=1.0.0, B=1.0.1 and my 
package=em8300-headers.)

Moreover, that does not answer to my real question: is there a good 
reason not to implement such an extended syntax for versionned 
relationships. If there is no good reason, I might try to implement such 
a thing and provide it to the maintainers of dpkg...


Regards,

Nicolas

Re: mass bug filing on packages that are blocking use of cdebconf

[Nicolas Duboc]

On Tue, Aug 02, 2005 at 06:46:20PM -0400, Joey Hess wrote:
> I intend to eventually file bugs on packages in Debian which depend on
> debconf without an alternate of debconf-2.0, as all of these make it
> impossible to install cdebconf, which we would eventually like to
> replace debconf.
> 
[...]

> Nicolas Duboc <[EMAIL PROTECTED]>
>spamprobe

  Fixed in latest upload (1.2a-1).

  Thanks,

-- 
Nicolas Duboc <[EMAIL PROTECTED]>


pgpdwtMM3deHF.pgp
Description: PGP signature

Re: Bug#330239: ITP: hibernate -- a powerful, ultra-high performance object/relational persistence and query service for Java

[Nicolas Weyland]

On Mon, 26 Sep 2005 17:35:14 -0400
Charles Fry <[EMAIL PROTECTED]> wrote:


> * Package name: hibernate
>   Version : 3.0.5

[EMAIL PROTECTED]:~$ apt-cache search hibernate
hibernate - activates your computer's suspend functionality

There's already a package called hibernate, chose another one
please.

regards, nicolas

-- 
Nicolas Weyland  ,,,
[EMAIL PROTECTED]  /'^'\
http://ufoalien.bug.ch ( o o ) 
---oOOO--(_)--OOOo-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Accepted grep 2.5.1.ds2-1 (source i386 sparc)

[Nicolas François]

Hello,

On Tue, Sep 27, 2005 at 11:12:07AM +1000, Aníbal Monsalve Salazar wrote:
> On Mon, Sep 26, 2005 at 08:04:24PM +0200, Adeodato Simó wrote:
> >found 181378 2.5.1.ds2-1
> >thanks
> >
> >* Anibal Monsalve Salazar [Mon, 26 Sep 2005 05:47:06 -0700]:
> >
> >>   * Removed 64-egf-speedup.patch, 65-dfa-optional.patch,
> >> 66-match_icase.patch and 67-w.patch from debian/patches,
> >> closes: #329876.
> >
> >  Those patches fixed a bug (and two merged) that had been opened for 2
> >  and a half years. I think it'd be useful if you tried to contact the
> >  authors of the patches, and try to fix them instead of removing them?
> 
> Sure, the grep maintainers decided to pull out them and will go
> trough the patches again.


I wondered if I introduced this issue while porting the Fedora patches to
Debian, so I tried Fedora's grep...which has the same issue.

You can reproduce it with this simple command:
echo foobar | grep -Fw ""

This was introduced by the patch I named '64-egf-speedup.patch'

You can fix it by changing the 'while (1)' by 'while (len)' (or by
embedding this while loop in a 'if (len){...}', I don't know if there is a
real difference, and what is the best way).
Tim Waugh, who wrote the original patches, may have a better understanding
of the grep's code.

The testsuite still pass with this patch.


BTW, I don't know if you received a mail I sent to [EMAIL PROTECTED],
which indicated that the additional patches (which I submitted because
they helped passing the testsuite) were fixing: #209194 #218873 #226397
#238167

If you plan to re-introduce these patches, please tell me. While checking
for this issue (#329876), I've seen that there was one issue fixed in a
Fedora update, related to this patch:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161700
I can update 64-egf-speedup.patch if you want.

Kind Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

lintian: postinst-does-not-load-confmodule

[Nicolas Boullis]

Hi,

I was about to upload a new release of one of my packages, but lintian 
complains that "postinst-does-not-load-confmodule". Running lintian with 
-i, I can get more information:

N:   Even if your postinst does not involve debconf, you currently need to
N:   make sure it loads one of the debconf libraries. This will be changed
N:   in the future.

I can't understand why I should load anything related to debconf, if I 
don't use debconf in postinst. (I use debconf in preinst and config, 
where I load it with ". /usr/share/debconf/confmodule".)

What am I missing?


Cheers,

Nicolas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#334060: ITP: python-jtoolkit -- web application framework

[Nicolas François]

Package: wnpp
Severity: wishlist
Owner: "Nicolas François" <[EMAIL PROTECTED]>


* Package name: python-jtoolkit
  Version : 0.7
  Upstream Author : David Fraser, Nick Hurley and Shayan Raghavjee of St James 
Software
* URL : http://sourceforge.net/projects/jtoolkit/
* License : GPL
  Description : web application framework

 jToolkit is a Python web application framework built on modpython and
 Apache.  It can also run in standalone mode using its own builtin HTTP
 server.
 .
 It is aimed at dynamically generated pages rather than mostly-static
 pages (for which there are templating solutions).  Pages can be produced
 using a variety of widgets or a new templating system.  It handles
 sessions and database connections.


I intend to package it in order to enable a possible Pootle binary package
(the source package already packaged by Matthias Klose (pootle), but the
Pootle server is not packaged yet).

Kind Regards,
-- 
Nekral

Shall Debian's su conform to other implementations

[Nicolas François]

Hi,

In #276419, the bug submitter complained that when a command and some
arguments were passed to su, all these arguments were concatenated, and
provided to the shell -c option.

This behavior differs from su on other systems [0].
This also forbid to pass arguments to the shell [1].

As these behaviors where not documented in the man page, in the code or in
the changelog, we uploded 4.0.3-36 to fix this bug.

Unfortunately, this broke pbuilder (see #317264), and other Debian
packages (e.g. dchroot). So this patch was (at least temporarily) removed,
and the current behavior documented.


We would now like to get rid of this bug. What do you recommend:
 * keep a Debian specific implementation and tag this bug wontfix
 * reapply the patch to fix this bug, and report bugs on the packages that
   uses this "feature"



[0] On other systems su's -c arguments must be quoted:
su - -c "ls -l /tmp"
and:
su -- - "$LOGNAME" ls -l /tmp
probably only works on Debian.

[1] For example:
su -- - "$LOGNAME" -x
Could exec("/bin/sh", ["-x"])

Kind Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: cvs loginfo configuration for alioth?

[Nicolas François]

Hi!

On Wed, Nov 09, 2005 at 10:30:38PM +0900, Junichi Uekawa wrote:
> Hi,
> 
> I'm looking for a 'loginfo' file configuration that works 
> for alioth.
> I thought I have found a solution few days ago, but when 
> I came back, it no longer seems to work correctly:

I think there is a cron job that restores the config files regularly.

Maybe this is to avoid somebody from changing SystemAuth or other values.
(e.g. can you check if the CVSROOT/config files still contains
UseNewInfoFmtStrings=yes) (The real CVSROOT/config file, not the one
source controlled you can get with a checkout).

Can anybody confirm.

My current solution is just to train my eyes to forget these warnings.

Kind Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#473274: ITP: python-levenshtein -- Python extension computing string distances and similarities

[Nicolas François]

Package: wnpp
Severity: wishlist
Owner: "Nicolas François" <[EMAIL PROTECTED]>


* Package name: python-levenshtein
  Version : 0.10.1
  Upstream Author : David Necas (Yeti) <[EMAIL PROTECTED]>
* URL : http://prdownloads.sourceforge.net/translate
* License : GPL-2+
  Programming Lang: C, Python
  Description : Python extension computing string distances and similarities

Levenshtein computes Levenshtein distances, similarity ratios, generalized
medians and set medians of Strings and Unicodes.  Because it's implemented
in C, it's much faster than corresponding Python library functions and
methods.



python-levenshtein is recommended by the translate-toolkit (and Pootle) to
improve performance for fuzzy matching.

Best Regards,
-- 
Nekral

Re: Bug#459403: libuuid1: missing depends on non-essential package passwd

[Nicolas François]

Hi,

I've made some cleanup of the passwd and login dependencies, and
remembered this discussion.

The main change is the move of libpam-modules from Depends to Pre-Depends
for login (which is Essential).
This moves libpam-modules to a virtual Essential package, which is the
reason of this mail (but as mentioned in the earlier thread, I don't think
this may be an issue).

On Mon, Jan 07, 2008 at 01:16:59AM -0800, Steve Langasek wrote:
> But let's have a look:
> 
> Package: passwd
> Version: 1:4.0.18.2-1
> Depends: libc6 (>= 2.6.1-1), libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.15), 
> login (>= 970502-1), libpam-modules (>= 0.72-5), debianutils (>= 2.15.2)
[...]
> login is also Essential: yes, so is only in the list because it's a
> versioned dep; but it's a versioned dep on a version older than oldstable,
> so we can probably prune that dep from passwd to make the essential set just
> a little less tangled.  Anyway, nothing in essential currently depends on
> passwd so we know there's no problematic loop here.

I've removed the versioned dependency of passwd on login (and hence the
dependency)

> debianutils is likewise essential, and the versioned dep is likewise
> satisfied by the version in stable (though not in oldstable).  Again the dep
> could probably be pruned.

I've kept this one.

> That leaves libpam-modules being pulled in, which is not currently essential
> or a pre-dep of any other essential packages.  This is not a spurious
> dependency on the part of passwd; actually, I'm left wondering why login has
> it as a Depends instead of as a Pre-Depends, since the stock login PAM
> config isn't going to work very well without those modules, so login seems
> to be failing the requirement to be minimally functional while unpacked but
> not configured.

I've moved the login's dependency on libpam-modules to a Pre-Depends.
Without libpam-modules, login and su will always reject the request.

Best Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)

[nicolas vigier]

On Thu, 15 May 2008, Steinar H. Gunderson wrote:

> On Wed, May 14, 2008 at 06:22:37PM -0500, Steve Greenland wrote:
> >> Therefore, anyone who had a DSA key has had it compromised...
> > Shouldn't that be "anyone who had a DSA key *created by the flawed
> > version of openssl* has had it compromised..."? Or are you asserting
> > something stronger?
> 
> No. Any key who had a single DSA signature created by the flawed version of
> OpenSSL should be considered compromised. DSA requires a secret, random
> number as part of the signature process; if someone figures it out, or you
> use the same number twice, the entire secret key falls.

If I understand correctly, it means that if you use a good key with a
flawed openssl to connect to an other host using that key, then that
key can be considered compromised.

But what about using a good key on a host with a good openssl, to
connect to a server which use a bad openssl ?

regards,
Nicolas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: what about an special QA package priority?

[Nicolas François]

Hi,

On Tue, May 20, 2008 at 05:21:07PM -0300, Luciano Bello wrote:
> Hi list,
> I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to 
> manage a hard meticulous QA process in all packages. In the other hand, there 
> are packages more critical than others, which are more delicate to security.
> Sometimes, those packages have different priorities in the policy meaning. 
> Maybe we can implement this as an Optional header in the control.
> The point is: if we can create critical QA category for delicate packages in 
> the security sense we can have mandatory QA requirement.

It will be hard to define this list of "delicate" packages.
For example, I'm not sure I would have put openssl in the list a few weeks
ago.
I would have first think about setuid/setgid programs, servers, with high
popcon packages first.

> For example:
>  - It should be checked with debugging tools (like valgrind :P)

It's not always needed.
It may show some bad practices, but having a command line utility which
allocate some resources (memory, syslog, files, PAM, ...) and does not
free them directly (i.e. it relies on system to do the cleanup on exit) is
not an issue.

If you want to improve quality, you can also recommend using checkers
(splint, security checkers), code metrics tools (e.g. pmccabe), unit tests

It might be good to recommend these tools (including valgrind), and to
provide some web services to provide the reports of these tools (IIRC,
there is already some servers with rats reports; for other checkers,
formalizing some debian/rules rules could help to to start the checkers).
But I don't think it will be possible to have them mandatory.

>  - It should maintained by a team

We will only be able to advertise that these packages need comaintainers.
Or is there a defined response for the "delicate" packages with no
teams/comaintainers.

>  - It should a public VCS
>  - Its patches should be sign-off by reviewers (Raphael Hertzog (hertzog@) 
> proposed something like this)

ACK for both.

> You can extend or reduce this list. We can discuss about the implementation. 
> But I mainly want to know your opinion.

I really appreciate the idea, but it might be hard to implement.

-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Policy 3.8.3.0 released: localized manpages

[Nicolas François]

On Mon, Aug 17, 2009 at 09:53:34AM -0700, Russ Allbery wrote:
> Yves-Alexis Perez  writes:
> > On lun, 2009-08-17 at 13:01 +1000, Ben Finney wrote:
> 
> >> So surely the best way to tell if a translated page is out of date is
> >> to compare these dates in the two documents, no?
> 
> > And I guess it should be easy to make a lintian test for that?
> 
> I suspect that this is going to not be as accurate as we might hope, but
> it is at least fairly easy to check and there's a simple fix for false
> positives (updating the .TH date), so it seems reasonable to me.
> 
> Note that a lot of man pages don't have a date on the .TH line.  It's not
> required.

Also note that translated manpages may have a translated date.

But I agree that if both the English and a translated manpages have a date
in the format -MM-DD, and the date of the translated manpages has an
older date, lintian could warn.


Best Regards,
-- 
Nekral


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

Re: Recommendations for man pages in Debian (was: Debian Policy 3.8.3.0 released: localized manpages)

[Nicolas François]

On Tue, Aug 18, 2009 at 08:13:20PM +1000, Ben Finney wrote:
> Roger Leigh  writes:
> 
> > I, for example, use the date format '+%d %b %Y' (01 Aug 2009). The
> > manual pages are human readable documentation. I think that nicely
> > readable dates should be preferred here.
> 
> This seems to falsely imply a necessary conflict between “nicely
> readable dates” and “ISO 8601 date representations”. The fact that
> they're simple and unambiguous, and to many readers interpretable
> without further explanation, I think makes them a good candidate for
> “nicely readable”.

This kind of conflict can be solved if the goal for ISO 8601 date
representations was to compare dates:
$ LC_ALL=C date -d'01 Aug 2009'
Sat Aug  1 00:00:00 CEST 2009
$ LC_ALL=C date -d'2009-08-01'
Sat Aug  1 00:00:00 CEST 2009

i.e. we can move from "ISO 8601 date representations" to "Is interpreted
correctly by `date -d''`"

However:
$ date -d'1er août 2009'
date: date invalide `1er août 2009'

Best Regards,
-- 
Nekral


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

Re: Bug#533265: apt or aptitude update at the beginning of a Lenny upgrade

[Nicolas François]

Hello,

(Adding debian-devel for additional comments, and previous contributors to
the topic)

As mentioned in #533265, the advice to update apt and aptitude at the
beginning of an upgrade may fail.

With a standard Etch install (i.e. only "standard" is selected in tasksel),
apt-utils and aptitude are removed after running:
apt-get install apt
(see attached log)

This may cause issues later (at least the following step
"aptitude install aptitude" will not work as is).

This has the benefit of a much smaller upgrade befor the "Minimal system
upgrade" step.

Updating apt was added after #489132

I propose to only recommend updating aptitude (this will update apt
anyway), and add a note for the users who prefer to use apt-get rather
than aptitude.

I think it will be clearer to only recommend only one upgrade path
(aptitude) and give some hint when some steps may fail (e.g. recommend to
try apt-get if aptitude fails to deal with some dependency chains).
Also the rest of the release notes mostly follow the aptitude upgrade
path.


The attached patch is my proposal for the release notes.
(I removed the note regarding libselinux1, because it is not related to the
topic, and also libselinux1 was required in Etch, so this was probably a
remaining of the Etch release notes)

Do you agree with this patch, or are there other reasons which makes
"apt-get install apt" the preferred upgrade path?

Best Regards,
-- 
Nekral
etch-rn:~# apt-get install apt
Reading package lists... 0%
Reading package lists... 100%
Reading package lists... Done
Building dependency tree... 0%
Building dependency tree... 0%
Building dependency tree... 50%
Building dependency tree... 50%
Building dependency tree... Done
The following extra packages will be installed:
  cpp cpp-4.3 dbus defoma esound-common fontconfig fontconfig-config
  gcc-4.3-base gconf2 gconf2-common gksu gnome-apt gnome-keyring
  gnome-mime-data libart-2.0-2 libatk1.0-0 libaudiofile0 libavahi-client3
  libavahi-common-data libavahi-common3 libavahi-glib1 libbonobo2-0
  libbonobo2-common libbonoboui2-0 libbonoboui2-common libc6 libc6-i686
  libcairo2 libcups2 libdatrie0 libdbus-1-3 libdbus-glib-1-2 libdirectfb-1.0-0
  libesd0 libexpat1 libfam0 libfontconfig1 libfreetype6 libgail-common
  libgail18 libgconf2-4 libgcrypt11 libgksu2-0 libglade2-0 libglib2.0-0
  libgmp3c2 libgnome-keyring0 libgnome2-0 libgnome2-common libgnomecanvas2-0
  libgnomecanvas2-common libgnomeui-0 libgnomeui-common libgnomevfs2-0
  libgnomevfs2-common libgnutls26 libgtk2.0-0 libgtk2.0-common libgtop2-7
  libgtop2-common libhal-storage1 libhal1 libice6 libidl0 libjpeg62
  libkeyutils1 libkrb53 libldap-2.4-2 libmpfr1ldbl libncurses5 liborbit2
  libpam0g libpango1.0-0 libpango1.0-common libpcre3 libpixman-1-0 libpng12-0
  libselinux1 libsm6 libstartup-notification0 libstdc++6 libsysfs2
  libthai-data libthai0 libtiff4 libts-0.0-0 libvte-common libvte9 libx11-6
  libx11-data libxau6 libxcb-render-util0 libxcb-render0 libxcb-xlib0 libxcb1
  libxcomposite1 libxcursor1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxft2
  libxi6 libxinerama1 libxml2 libxmuu1 libxrandr2 libxrender1 locales lsb-base
  psmisc shared-mime-info sudo ttf-dejavu ttf-dejavu-core ttf-dejavu-extra
  tzdata x11-common xauth zlib1g
Suggested packages:
  dpkg-dev apt-doc bzip2 lzma python-apt cpp-doc gcc-4.3-locales defoma-doc
  dfontmgr psfontmgr x-ttcidfont-conf libbonobo2-bin glibc-doc cups-common
  esound libfreetype6-dev rng-tools desktop-base gnome-icon-theme
  libgnomevfs2-bin gnutls-bin librsvg2-common krb5-doc krb5-user libpam-doc
  ttf-kochi-gothic ttf-kochi-mincho ttf-thryomanes ttf-baekmuk
  ttf-arphic-gbsn00lp ttf-arphic-bsmi00lp ttf-arphic-gkai00mp
  ttf-arphic-bkai00mp
Recommended packages:
  dbus-x11 libft-perl gdeb libpam-gnome-keyring libatk1.0-data esound-clients
  fam libglib2.0-data libgnomevfs2-extra gnome-mount hicolor-icon-theme
  libgtk2.0-bin libgpm2 xml-core
The following packages will be REMOVED:
  apt-utils aptitude tasksel tasksel-data
The following NEW packages will be installed:
  cpp cpp-4.3 dbus defoma esound-common fontconfig fontconfig-config
  gcc-4.3-base gconf2 gconf2-common gksu gnome-apt gnome-keyring
  gnome-mime-data libart-2.0-2 libatk1.0-0 libaudiofile0 libavahi-client3
  libavahi-common-data libavahi-common3 libavahi-glib1 libbonobo2-0
  libbonobo2-common libbonoboui2-0 libbonoboui2-common libcairo2 libcups2
  libdatrie0 libdbus-1-3 libdbus-glib-1-2 libdirectfb-1.0-0 libesd0 libexpat1
  libfam0 libfontconfig1 libfreetype6 libgail-common libgail18 libgconf2-4
  libgksu2-0 libglade2-0 libglib2.0-0 libgmp3c2 libgnome-keyring0 libgnome2-0
  libgnome2-common libgnomecanvas2-0 libgnomecanvas2-common libgnomeui-0
  libgnomeui-common libgnomevfs2-0 libgnomevfs2-common libgnutls26 libgtk2.0-0
  libgtk2.0-common libgtop2-7 libgtop2-common libhal-storage1 libhal1 libice6
  libidl0 libjpeg62 libkeyutils1 libldap-2.4-2 libmpfr1ldbl liborbit2
  libpango1.0-0 libpango1.0-common libpixman-1-0 libpng12-0 l

Permissions of /var/mail/$USER

[Nicolas François]

Hello,

When an user is created, useradd creates a /var/mail/$USER mailbox with
the mode 0660 (owned by $USER:mail).

I heard this causes some issues for dovecot, and a solution could be to
move to mode 0600.

I would like to change shadow in that direction, with a configure option to
restore the previous behavior.



On Debian, the policy allows this, but I would like to communicate this
change in case some people know of possible breakages.

Here is an extract from the Debian policy:

 Mailboxes are generally either mode 600 and owned by  or mode
 660 and owned by `:mail'[3].  The local system administrator may
 choose a different permission scheme; packages should not make
 assumptions about the permission and ownership of mailboxes unless
 required (such as when creating a new mailbox).  A MUA may remove a
 mailbox (unless it has nonstandard permissions) in which case the MTA
 or another MUA must recreate it if needed.

 [...]

[3]  There are two traditional permission schemes for mail spools: mode 600
 with all mail delivery done by processes running as the destination
 user, or mode 660 and owned by group mail with mail delivery done by a
 process running as a system user in group mail.  Historically, Debian
 required mode 660 mail spools to enable the latter model, but that
 model has become increasingly uncommon and the principle of least
 privilege indicates that mail systems that use the first model should
 use permissions of 600.  If delivery to programs is permitted, it's
 easier to keep the mail system secure if the delivery agent runs as
 the destination user.  Debian Policy therefore permits either scheme.



Other distributions could use the configure option, but let me know if this
would also break anything.

Thanks in advance,
-- 
Nekral


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

Re: Permissions of /var/mail/$USER

[Nicolas François]

Hello,

On Sun, Oct 11, 2009 at 12:45:20PM +0200, Bjørn Mork wrote:
> Nicolas François  writes:
> 
> > When an user is created, useradd creates a /var/mail/$USER mailbox with
> > the mode 0660 (owned by $USER:mail).
> >
> > I heard this causes some issues for dovecot, and a solution could be to
> > move to mode 0600.
> 
> Where did you hear this?

It was a request on IRC

> Exactly what did you hear?

IIRC, it was a problem for the support of shared mailboxes.
Index files are created whose permissions mimic the mailbox' permissions.
The 'mail' group ownership would require dovecot to be in the mail group.

I assume that this could be solved internally by dovecot, but it would be
easier (and safer) to move to a 0600 policy.

> Is this documented in a bug report?
> 
> Maybe some reference(s) to the bug report(s) would make it easier for
> the rest of us to understand the issues? 
> 
> 
> > Here is an extract from the Debian policy:
> >
> >  Mailboxes are generally either mode 600 and owned by  or mode
> >  660 and owned by `:mail'[3].  The local system administrator may
> >  choose a different permission scheme; packages should not make
> >  assumptions about the permission and ownership of mailboxes unless
> >  required (such as when creating a new mailbox). 
> 
> Anyway, doesn't this make any dovecot issue a policy violation?  Or am I
> misunderstanding the "packages should not make assumptions about the
> permission and ownership of mailboxes" part?

It would be a violation of a "should".
This "should" is also followed by "unless required", which is vague enough
to include any technical reason dovecot may have.

Best Regards,
-- 
Nekral


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

Bug#555682: ITP: libgmpada -- Ada binding to the GNU MultiPrecision library

[Nicolas Boulenguez]

Package: wnpp
Severity: wishlist
Owner: Nicolas Boulenguez 

* Package name: libgmpada
  Version : 20091109
  Upstream Author : Nicolas Boulenguez 
* URL : http://mtn-host.prjek.net/projects/libgmpada
* License : GPL
  Programming Lang: Ada
  Description : Ada binding to the GNU MultiPrecision library

GMPAda allows programmers to use the GNU MultiPrecision library
within the Ada language.

It allows computing with integers and floating point numbers whose
length is only limited by the computer's memory. Two bindings are
provided: one directly calls the C functions, while the other is less
performant but encapsulates safe memory allocation.  The library is
more useful as sources than as a shared binary since optimization
often matters.



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

Bug#561044: ITP: newlib-arm -- newlib C library (ARM)

[Nicolas Dandrimont]

Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont 

* Package name: newlib-arm
  Version : 1.17.0
  Upstream Author : Jeff Johnston  and others
* URL : http://sourceware.org/newlib/
* License : collection of libs under BSD, GPL, LGPL and other licenses
  Programming Lang: C
  Description : newlib C library (ARM)

Newlib is a C library intended for use on embedded systems. It is a
conglomeration of several library parts, all under free software
licenses that make them easily usable on embedded products.

This package contains the newlib library built for ARM targets.

---

This package will be built using the newlib-source package.

I chose to split it out of the newlib source package to avoid
cluttering it, but the packages could be merged.



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

Bug#561045: ITP: binutils-arm -- The GNU assembler, linker and binary utilities for ARM targets

[Nicolas Dandrimont]

Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont 

* Package name: binutils-arm
  Version : 2.20
  Upstream Author : Numerous Authors (see CVS below)
* URL : http://sourceware.org/binutils/
* License : GPL and LGPL
  Programming Lang: C
  Description : The GNU assembler, linker and binary utilities for ARM 
targets

The programs in this package are used to manipulate binary and object
files that may have been created for the ARM architecture.  This
package is primarily for ARM developers and cross-compilers and is
not needed by normal users or developers.

---

This package is the first step towards a full cross-compilation
toolchain for the arm-none-eabi target.

It will be built using the binutils-source package, in a manner
analogous than what is done with binutils-avr.



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

Bug#561043: ITP: gdb-arm -- The GNU debugger for ARM targets

[Nicolas Dandrimont]

Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont 

* Package name: gdb-arm
  Version : 7.0
  Upstream Author : Numerous (see gdb package)
* URL : http://www.gnu.org/software/gdb/
* License : GPL
  Programming Lang: C
  Description : The GNU debugger for ARM targets

GDB is a source-level debugger, capable of breaking programs at any
specific line, displaying variable values, and determining where
errors occurred. Currently, it works for C, C++, Fortran Modula 2 and
Java programs. A must-have for any serious programmer.

This package has been built for the arm-none-eabi target.  It is
intended for ARM developers and cross-compilers and is not needed by
normal users or developers.

---

I'm not really sure how I will package gdb for arm cleanly, as there
is no gdb-source package available.

The gdb-avr and gdb-m68hc1x packages bundle the DFSG-cleaned
gdb-6.4.90 source. This doesn't feel quite right to me, but it seems
to be the way to go.



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

Bug#561046: ITP: gcc-arm -- The GNU C Compiler (cross-compiler for ARM targets)

[Nicolas Dandrimont]

Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont 

* Package name: gcc-arm
  Version : 4.4.2
  Upstream Author : Numerous (see gcc-4.4-source package)
* URL : http://gcc.gnu.org/
* License : GPL3 (+ exception for runtime library)
  Programming Lang: C
  Description : The GNU C Compiler (cross-compiler for ARM targets)

This is the GNU C compiler, a fairly portable optimizing compiler
which supports multiple languages.
 
This package includes support for C and C++ on arm-none-eabi targets.

---

This package will be built using the gcc-4.4-source package, in a
manner analogous to what is done for gcc-avr.

It will Build-Depend on newlib-arm so as to be able to build the C++
compiler. This makes a loop-Build-Dependency, but as newlib-arm will
be an Arch-independent package it shouldn't pose a bootstrap problem.



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

Bug#561868: ITP: piwigo -- photo gallery software for the web

[Nicolas Roudaire]

Package: wnpp
Severity: wishlist
Owner: Nicolas Roudaire 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


* Package name: piwigo
  Version : 2.0.7
  Upstream Author : Pierrick LE GALL 
* URL : http://piwigo.org/
* License : GPL
  Programming Lang: PHP
  Description : photo gallery software for the web

Piwigo is a photo gallery software for the web, built by an active community
 of users and developers. Extensions make Piwigo easily customizable.

 Features:
  - localization in english, french, german, spanish, italian, nederlands, 
portuguese, ...
  - tags
  - permissions on photos and categories
  - virtual category allowing picture to be in multiple categories
  - meaningful URLs
  - user comments and rating
  - use of iptc and exif metadatas
  - notification of news by email or RSS feed
  - best rated, most view pictures
  - web api allowing requests or administration from other applications.


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

iQEcBAEBCAAGBQJLLqG3AAoJEJ8MyOh0TdIzJkUH/3exiVKYQiN6ThJ8AhFS4U7T
sBgPDdZl4UmEdse5oBH+NKhzBlWvtRnlrbhbX4zmDl9u0Bvtq7d6H0ftvD2TWDnG
MimPwTxHUi+FurkGyI7jbWf0liD+Rmf7ecr18B5D5Ds6/Y30xvMNxM581m9vFwwj
8uv8jHNsnbMcOBBfJpUJ7bqIF+w0X2OoRJDdkTAavLuOIQLkjVVC0gw5fDT8RhMA
+2LjxxAMqTS6XijMeZxn1u1M0YmddCDi3d39u8tIf2QaO5aVuNnTwiFAk1U2vttR
MmFsxfdN65mZqsck0ckMk5ZhdN1Oi7cMTliW3TfOD4LudlIAvkH6rPVQgZfGV3I=
=stcq
-END PGP SIGNATURE-



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

Re: dselect memory use

[Nicolas François]

On Thu, Feb 08, 2007 at 10:04:14AM +1100, Russell Coker wrote:
> 
> Is it possible to reduce the memory use of dselect?

There are some patches by Michel Lespinasse on:
http://bugs.debian.org/395140

Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Please help me make athcool compatible with dependency-based init systems (was: Release Update: freeze, architecture requalification)

[Nicolas Boullis]

Hi,

Disclaimer: I've been pretty busy recently, not giving my Debian 
packages the care and love they deserve. That's why I'm now asking for 
help, somewhat late...

On Sat, Jul 19, 2008 at 03:35:35PM +0200, Luk Claes wrote:
> 
> * Prepare init.d-Scripts for dependency-based init systems
> 
> Wider testing of dependency-based init systems has lead to some new bugs
> for this goal, but the current state looks quite well. We are confident
> that we will have full support for dep-based init system in lenny.

One of my packages, namely athcool installs an init script that is not 
yet compatible with dependency-based init systems. For some reason, it 
was not detected by automatic systems such as lintian, and no bug was 
filed against it, and no-one cared about it yet.

Athcool installs an init script but does not install links to run it on 
boot, and that might be the reason why lintian did not notice about it. 
(No startup link is installed because athcool causes bad stability 
issues on some systems. If one tests it and experiences such problems, 
the system is back to a normal state after a reboot.) Someone who is 
satisfied with athcool can run update-rc.d (as documented in 
/usr/share/doc/athcool/README.Debian) to enable startup links.

I'd like to reproduce a similar behaviour with the headers for 
dependency-based init systems, but I know close to nothing about such 
systems. I read the corresponding section of the LSB, but it did not 
help me much. I guess I could set Default-Start and Default-Stop empty. 
But then I have no idea how I would document the enablement of startup 
links by the user. Since those keywords are called "Default", I guess 
there is a way to override them, but how? Or I think one might change 
the Default-Start and Default-Stop keyworks, but then who would they ask 
the system to take the change into account?

Any help is welcome, especially as a patch or a NMU, but please don't 
forget the documentation issue.


Thanks in advance,

Nicolas


PS: I have no time to read d-devel; please CC replies to me.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please help me make athcool compatible with dependency-based init systems (was: Release Update: freeze, architecture requalification)

[Nicolas Boullis]

Hi,

As a follow-up to myself, and as suggested by Kel Modderman, please also 
CC replies to the developer list for initscripts-ng. (Full message kept 
for those people.)


On Mon, Jul 21, 2008 at 11:33:10PM +0200, Nicolas Boullis wrote:
> Hi,
> 
> Disclaimer: I've been pretty busy recently, not giving my Debian 
> packages the care and love they deserve. That's why I'm now asking for 
> help, somewhat late...
> 
> On Sat, Jul 19, 2008 at 03:35:35PM +0200, Luk Claes wrote:
> > 
> > * Prepare init.d-Scripts for dependency-based init systems
> > 
> > Wider testing of dependency-based init systems has lead to some new bugs
> > for this goal, but the current state looks quite well. We are confident
> > that we will have full support for dep-based init system in lenny.
> 
> One of my packages, namely athcool installs an init script that is not 
> yet compatible with dependency-based init systems. For some reason, it 
> was not detected by automatic systems such as lintian, and no bug was 
> filed against it, and no-one cared about it yet.
> 
> Athcool installs an init script but does not install links to run it on 
> boot, and that might be the reason why lintian did not notice about it. 
> (No startup link is installed because athcool causes bad stability 
> issues on some systems. If one tests it and experiences such problems, 
> the system is back to a normal state after a reboot.) Someone who is 
> satisfied with athcool can run update-rc.d (as documented in 
> /usr/share/doc/athcool/README.Debian) to enable startup links.
> 
> I'd like to reproduce a similar behaviour with the headers for 
> dependency-based init systems, but I know close to nothing about such 
> systems. I read the corresponding section of the LSB, but it did not 
> help me much. I guess I could set Default-Start and Default-Stop empty. 
> But then I have no idea how I would document the enablement of startup 
> links by the user. Since those keywords are called "Default", I guess 
> there is a way to override them, but how? Or I think one might change 
> the Default-Start and Default-Stop keyworks, but then who would they ask 
> the system to take the change into account?
> 
> Any help is welcome, especially as a patch or a NMU, but please don't 
> forget the documentation issue.
> 
> 
> Thanks in advance,
> 
> Nicolas
> 
> 
> PS: I have no time to read d-devel; please CC replies to me.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please help me make athcool compatible with dependency-based init systems

[Nicolas Boullis]

Hi Kel,

On Wed, Jul 23, 2008 at 11:55:04PM +1000, Kel Modderman wrote:
> Hi Nicolas,
> 
> Just add the LSB header with correct information like:
> 
> ### BEGIN INIT INFO
> # Provides:  athcool
> # Required-Start:$remote_fs
> # Required-Stop: $remote_fs
> # Default-Start: 2 3 4 5
> # Default-Stop:
> # Description:   enable powersaving mode for Athlon/Duron processors
> ### END INIT INFO
> 
> Your package does not call update-rc.d in postinst, courtesy of
> "dh_installinit -n", therefore no links get created even on insserv system.
> 
> There is no need to modify README.Debian instructions, as insserv package
> provides an update-rc.d wrapper. When the admin follows the existing
> instructions of "update-rc.d athcool start 20 2 3 4 5 ." you will get runlevel
> links, just that the sequence number 20 is ignored and a more precise sequence
> number is calculated by insserv.

Thanks for your answer.
Sorry for asking a potentially stupid question, but how does the 
"Default-Start" keyword affect the bahvior of the system?


Cheers,

Nicolas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please help me make athcool compatible with dependency-based init systems

[Nicolas Boullis]

Hi,

On Wed, Jul 23, 2008 at 11:36:01PM +0300, Teodor wrote:
> On Wed, Jul 23, 2008 at 10:52 PM, Nicolas Boullis <[EMAIL PROTECTED]> wrote:
> > Sorry for asking a potentially stupid question, but how does the
> > "Default-Start" keyword affect the bahvior of the system?
> 
> Refer to http://wiki.debian.org/LSBInitScripts for details. Maybe this
> page should be updated for LSB 3.2?

Well... I already read LSB, but there's nothing about how it really 
interacts with the system. What does "default" mean here?
Does it affect update-rc.d?
Is it used when insserv is enabled?

I'd rather be sure that no-one will get startup links unwillingly, so 
I'd like to understand how it really affects things...
(For example: one installs athcool, does not create startup links and 
then installs and enables insserv...)


Cheers,

Nicolas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#493308: ITP: libconfig-model -- Perl Module to describe and edit configuration data

[Nicolas Valcarcel]

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

--- Please fill out the fields below. ---

   Package name: libconfig-model
Version: 0.624
Upstream Author: Dominique Dumont <[EMAIL PROTECTED]>
URL: http://search.cpan.org/dist/Config-Model/
License: LGPL
Description: Perl Module to describe and edit configuration data

Config::Model enables a project developer to provide an interactive
configuration editor (graphical, curses based or plain terminal) to
his users. For this he must:
- describe the structure and constraint of his project's configuration
- if the configuration data is not stored in INI file or in Perl data
  file, he must provide some code to read and write configuration from
  configuration files.

With the elements above, Config::Model will generate interactive
configuration editors (with integrated help and data validation).
These editors can be graphical (with Config::Model::TkUI), curses
based (with Config::Model::CursesUI) or based on ReadLine.


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

Re: Bug#495196: ITP: libperl-minimumversion-perl -- find a minimum required version of perl for Perl code

[Nicolas François]

Hello,

On Fri, Aug 15, 2008 at 11:29:15AM +0200, Vincent Danjean wrote:
>   Description : find a minimum required version of perl for Perl code
> 
>  Perl::MinimumVersion takes Perl source code and calculates the minimum
>  version of perl required to be able to run it. Because it is based on
>  PPI, it can do this without having to actually load the code.
>  .
>  Currently it tests both the syntax of your code, and the use of explicit
>  version dependencies such as "require 5.005".
>  .
>  Future plans are to also add support for tracing module dependencies.

You should avoid the comments (last 2 paragraphs) on the status of the
package, in particular the "future plans".

-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Little endian /usr/share/locale/* files in epiphany-browser-data

[Nicolas François]

Hello,

> >  I see two main issues:
> >  - the endianess of files in the archive is actually random
> >  - I would expect the most common endianess to be the little endian one
> >since maintainers mostly upload packages for amd64/i386; this means
> >that the slow big endian arches usually get to pay the hit
> 
> Is it worth changing though? It seems like excess pedantry to me.

I made a test with 1 simple strings (test1, test2, ...) on ppc (ibook
G4 1.2GHz) and i386 (Intel(R) Core(TM)2 Duo CPU E6550  @ 2.33GHz):

ppc, with the mo file generated on ppc:
User time: from 3.384s to 3.404s

ppc, with the mo file generated on i386:
User time: from 3.396s to 3.424s


i386, with the mo file generated on i386:
User time: from 0.024s to 0.028s

i386, with the mo file generated on ppc:
User time: from 0.024s to 0.028s


My protocol is there:
http://alioth.debian.org/~nekral-guest/test-gettext-endianness.tar.gz

Unless there is something wrong in this protocol (I did not checked where
the time is lost when the file cannot be mmaped directly, or if the
modeled usage is realistic), I would not try to save 0.02s every time my
browser gettextize 1 strings. (The msgunfmt / msgfmt conversion took
40 times more).

Best Regards,
-- 
Nekral


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

Re: Bug#450432: ... and even more bugs like this?

[Nicolas François]

On Tue, Nov 13, 2007 at 01:44:23AM +0600, Ivan Shmakov wrote:
>   Last week I've reported a bug in ifconfig(8) (as of net-tools
>   1.60-17.)  The problem is in that the ifconfig.8 contains the
>   following:
> 
> --cut--
> .B ifconfig eth0:0 down
> . Note: for every scope (i.e. same net with address/netmask combination) all
> aliases are deleted, if you delete the first (primary).
> --cut--

You may also want to check lines starting by a single quote (').

Good luck,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: help with install-info usage count

[Nicolas François]

Hello Norbert,

2007/12/19, Norbert Preining <[EMAIL PROTECTED]>:
> Hi all!
>
> In the process of merging dpkg install-info and GNU install-info we are
> now at the point that I would like to generate a list of packages
> using install-info together with the way HOW they call it. Options would
> be
> - via dh_installinfo generated code
> - via manual code: which arguments
>
> What is the best way to create such a list? I cannot install *all*
> packages of sid on my computer and grep for it in postinst scripts.

I have such list, I will send it to you tonight.

The list was computed based on the extraction of binary packages from
(IIRC) the i386  mirror.
It does not distinguish manual code from dh_installinfo generated code.

Best Regards,
-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Producing multiple -dbg packages using CDBS

[Nicolas CANIART]

Hi,

  I would like to know if someone could point me out the way one can
produce more than one -dbg package using CDBS ? (a package doing that
or some doc)
  The changelog says it is possible as of version 0.4.38, but does not
provides any hints on how. And having a look at the CDBS debhelper.mk
file was no that inspiring. I found a trick the does the work, but its
just a trick.

Thanks in advance,
Nicolas.

-- 
Nicolas CANIART  | PhD. Student
LaBRI, Domaine Universitaire | Room :  378
351, Cours de la Libération  | Phone : +33 (0)540 003 511
F-33405 Talence CEDEX| e-mail: [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: Producing multiple -dbg packages using CDBS

[Nicolas CANIART]

On Tue, Jan 01, 2008 at 11:27:10AM +0100, Andreas Metzler wrote:
> Nicolas CANIART <[EMAIL PROTECTED]> wrote:
> >  I would like to know if someone could point me out the way one can
> > produce more than one -dbg package using CDBS ? (a package doing that
> > or some doc)
> >  The changelog says it is possible as of version 0.4.38, but does not
> > provides any hints on how.
> 
> [...]
> /usr/share/doc/cdbs/cdbs-doc.html
> To control more finely which debug symbols go where, in particular if you want
> to build more than one debug package, there are variables
> DEB_DBG_PACKAGE_package that specify the debug package target for each
> individual binary package. An example usage would be:
> 
> DEB_DBG_PACKAGE_libfoo4 = libfoo-dbg
> DEB_DBG_PACKAGE_foo-bin = foo-bin-dbg
> [...]
> 
> cu andreas
> -- 
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
> 
> 

All right, I should try to avoid thinking the docs available on the
net are more accurate than the one installed on my computer (thanks to
DDs hard work); shame on me.

My apologies for wasting your time and thank you for the answer.
It worked like a charm, of course.

-- 
Nicolas CANIART  | PhD. Student
LaBRI, Domaine Universitaire | Room :  378
351, Cours de la Libération  | Phone : +33 (0)540 003 511
F-33405 Talence CEDEX| e-mail: [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#570505: ITP: ploader -- Application to upload your pictures to your Piwigo gallery

[Nicolas Roudaire]

Package: wnpp
Severity: wishlist
Owner: Nicolas Roudaire 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


* Package name: ploader
  Version : 1.0.0
  Upstream Author : Pierrick LE GALL 
* URL : http://piwigo.org/
* License : GPL
  Programming Lang: Perl
  Description : Application to upload your pictures to your Piwigo gallery

 Piwigo is an opensource web application to manage and share a pictures 
 collection.
 With pLoader, you can easily upload pictures to your Piwigo gallery, and do
 some management tasks, without having to use the web interface. 
 .
 Features:
  - easy editing of photo properties (title, description, privacy, tags)
  - ability to specify photo upload size and orientation.
  - large image preview.
  - drag-and-drop support from other applications.
  - create categories

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

iQEcBAEBCAAGBQJLfnm4AAoJEJ8MyOh0TdIzOAoIAIMLl2nKkXhFaMmpnxOv/kMp
6/mMGlnMV4B5vhv/dB1LWKALJvqXCS8RdKm0wJUUDk5y4RIc46MkoB7+/rZvwK+n
nAF6uDmpfJg8YMQqUGo0JV8EzVEwALinR1UbuulFCgkKL+G15oIANVG4whTApwzU
EOZ4vgWJ58SE/UZBxp8mt26WHupwK2qMqz24HX2F3fT0fPO+sB19ZrCUhxulZS0y
TKfy1Mv4wA1yWic/abDYkJZQhvBJKfNaMok7f3AOetIgHiU9BjmEBKFPJKn5laQW
7qa3s3wk0ckPxrS/eGbGiZCd9iWzFlI+9OQiz/OBXs6tpkjR99aDAs8R9s/D3Yk=
=/3q1
-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/20100219114501.6918.93867.report...@localhost

Bug#572919: ITP: totem-plugin-arte -- This totem plugin allows you to watch streams from arte.tv

[Nicolas Delvaux]

Package: wnpp
Severity: wishlist
Owner: Nicolas Delvaux 

* Package name: totem-plugin-arte
  Version : 0.8.1
  Upstream Author : Simon Wenner 
* URL : http://gitorious.org/totem-plugin-arte
* License : GPL v2+
  Programming Lang: Vala
  Description : This totem plugin allows you to watch streams from arte.tv

This Totem plugin allows you to watch video streams from the Franco-German
TV Channel Arte.

Sadly, this service is only available for IPs within Austria, France, Germany,
Belgium and Switzerland.

The package is nearly ready.



-- 
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/20100307171502.14116.71037.report...@nicolas-laptop

Re: Bug#547079: login: Should set the iutf8 tty c_iflag if the locale is utf8

[Nicolas François]

tags #539354 help
thanks

Hello,

As I have no clue about TTY setup, let see if I can get some other
opinions on debian-devel.

The question raised on http://bugs.debian.org/547079 is who shall be
responsible for setting up the user's tty (e.g. regarding UTF-8 handling).

Some defaults are in the kernel.
getty makes some changes, login also, and the end user may also do so in a
user profile script.

The kernel, getty, or login do not really know if the user wants a UTF-8
locale, so my preference would be to move the setup of the iutf8 tty
c_iflag to the user's configuration.  For example the user could use
unicode_start / unicode_stop.

(This also has the advantage for me not to require any change in login)


The bug discusses also these alternatives:
 2 iutf8 tty c_iflag forced by getty (maybe based on an option in inittab)
   (currently getty always drop this flag)
 3 iutf8 tty c_iflag forced by login
   (I did not really understand how login shall guess when this shall be
   done, maybe an option in /etc/login.defs)
 4 iutf8 tty c_iflag forced by a PAM module

Do you have any opinion on how this should be done?

Thanks in advance,
-- 
Nekral

On Thu, Sep 17, 2009 at 08:35:16PM -0400, Mike Frysinger wrote:
> On Thursday 17 September 2009 19:59:14 Samuel Thibault wrote:
> > Mike Frysinger, le Thu 17 Sep 2009 19:30:02 -0400, a écrit :
> > > > > login/pam are there to do authentication only, not screw with the
> > > > > terminal.
> > > >
> > > > Login already does screw with the terminal in setup_tty(),
> > >
> > > presumably enough to prevent echoing of the password, but that's about it
> > > (for obvious security reasons).
> > 
> > Have you looked at the code before saying that?
> > 
> > /*
> >  * Add your favorite terminal modes here ...
> >  */
> > termio.c_lflag |= ISIG | ICANON | ECHO | ECHOE;
> > termio.c_iflag |= ICRNL;
> > 
> > etc...
> 
> looks like a lot of stuff login shouldnt be doing, but historically has been 
> so no one complained because "it worked".  extending poor behavior because 
> it's already there isnt really a good line of reasoning.
> 
> > > i dont have a fedora box myself, but from talking to a friend, things
> > > "just work" in the default setup. or at least it defaults everything
> > > to unicode.
> > 
> > Did he check whether stty -a properly shows iutf8?  Things work very
> > fine even without it, one of the very few effects of iutf8 left cleared
> > is the bug I mentioned in my report: canonical mode's treatment of
> > backspace.  People rarely notice it.
> 
> i didnt ask him "hey does your keyboard work", i asked him what his settings 
> were after he logged in.  so of course i validated the stty output.
> 
> i'm not suggesting everything is great and nothing needs to be changed.  i'm 
> saying that login/pam is not really part of the solution.
> -mike



-- 
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/20100323140951.ga9...@nekral.nekral.homelinux.net

Re: Bug#547079: login: Should set the iutf8 tty c_iflag if the locale is utf8

[Nicolas François]

Hi Samuel,

On Tue, Mar 23, 2010 at 05:18:42PM +0100, Samuel Thibault wrote:
> 
> See my concern in the bug report:
> 
> “My concern is that getty used to not keep any flag at all.  Keeping
> _some_ flags contrary to none is not just a "fix", it's a change of
> behavior.  Think for instance about a situation where a user clears
> the tty's iutf8.  The next user to log in will have a bogus terminal
> since getty would leave it cleared and nothing else will set it.  This
> is the same for all the flags, getty could just keep the kernel's
> current state, but it doesn't. [...] Letting a user break another user's
> environment is wrong”

Is it an issue to set the utf8 flag too often?
(does it break something?, does it affect performances?)

Also, can you elaborate on your solution. Who would configure what and how?

Best Regards,
-- 
Nekral


-- 
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/20100323225929.ge5...@nekral.nekral.homelinux.net