How to check why a package is in contrib

[Bastien ROUCARIES]

Hi,

I was trying to check why a package was in contrib (jabref), and I could not 
find a means to do that automatically. 

Could we add an automatic mechanism based on package description, for getting 
the reason, like for instance, why-contrib: reason

It will ease the move to main in case of for instance a nonfree build lib that 
go to main :)

Bastien


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

Cmap file are now free: List of package to move to main

[Bastien ROUCARIES]

Hi, 

According to Paul Wise:

>The Adobe CMap resources are now free software and licensed under the
>BSD license. More information about this can be found here:
>>http://bonedaddy.net/pabs3/log/2009/09/24/adobe-data-freed/
>http://lists.debian.org/debian-legal/2009/09/msg00039.html

The following package that depends on cmap (according to licence file) may be 
moved to main:
cmap-adobe-cns1 
cmap-adobe-gb1 
cmap-adobe-japan1
cmap-adobe-korea1 
poppler-data
gs-cjk-resource
xpdf-japanese
xpdf-chinese-simplified
xpdf-chinese-traditional
xpdf-korean
libpdfbox-java
libpdfbox-java-doc (could be done now BTW)
jabref

I plan to open bug to the previous package and create a general bug for this 
issue. Each package bug will block the general bug.

Regards

Bastien


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

Bug#548195: Move cmap and cmap depend package to main

[Bastien ROUCARIES]

Package: general
Severity: wishlist

The Adobe CMap resources are now free software and licensed under the
BSD license. More information about this can be found here:

http://bonedaddy.net/pabs3/log/2009/09/24/adobe-data-freed/
http://lists.debian.org/debian-legal/2009/09/msg00039.html

This a meta bug. Please correct each blocking bug, then close it

Bastien



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

Re: Cmap file are now free: List of package to move to main

[Bastien ROUCARIES]

Le jeudi 24 septembre 2009 11:46:54, Bastien ROUCARIES a écrit :
> Hi,
> 
> According to Paul Wise:
> >The Adobe CMap resources are now free software and licensed under the
> >
> >BSD license. More information about this can be found here:
> >>http://bonedaddy.net/pabs3/log/2009/09/24/adobe-data-freed/
> >
> >http://lists.debian.org/debian-legal/2009/09/msg00039.html
> 
> The following package that depends on cmap (according to licence file) may
>  be moved to main:
> cmap-adobe-cns1
> cmap-adobe-gb1
> cmap-adobe-japan1
> cmap-adobe-korea1
> poppler-data
> gs-cjk-resource
> xpdf-japanese
> xpdf-chinese-simplified
> xpdf-chinese-traditional
> xpdf-korean
> libpdfbox-java
> libpdfbox-java-doc (could be done now BTW)
> jabref
> 
> I plan to open bug to the previous package and create a general bug for
>  this issue. Each package bug will block the general bug.

Done general bug is #548195

Regards

Bastien


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

Re: Orphaning my packages...

[Bastien ROUCARIES]

Le mardi 29 septembre 2009 03:04:25, Kevin B. McCarty a écrit :
> Hi all,
> 
> I unfortunately don't have the free time at the moment to do much for
> the Debian Project, so I'm orphaning my packages.
> 
> If anyone wants to stake a claim to any of the following, please go
> ahead and say so, otherwise I'll file the orphaning bugs within a couple
> days.  (Follow-ups set to debian-devel.)
> 
> Cernlib-related (Cernlib is a huge, mostly obsolete set of physics
> libraries and tools) packages.  These all have corresponding wnpp ITO
> bugs that can be changed to ITA / closed as desired.  Note, Francois
> Niedercorn (in CC) has first dibs on these if he wants them.  Francois,
> if you still do, please reply to debian-devel.
> 
> cernlib - #508413
> cfortran - #508500
I am not a debian developer but i could comaintain cfortran


Bastien
> geant321 - #508496
> mclibs - #508498
> mn-fit - #508501
> paw - #508495
> 
> Other packages:
> 
> feynmf
> viewglob
> 
> 
> best regards,
> 


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

Re: RFC: RelaxNG and XML schema schemes packaged for Debian

[Bastien ROUCARIES]

Le jeudi 12 novembre 2009 14:18:51, Daniel Leidert a écrit :
> Am Mittwoch, den 11.11.2009, 22:57 +0100 schrieb Samuel Thibault:
> > Daniel Leidert, le Wed 11 Nov 2009 17:36:05 +0100, a écrit :
> > > A question: I'm currently working with relaxNG and found, that we
> > > (Debian) AFAIK don't have the schemes for RNG [1] or XSD [2] packaged.
> >
> > I don't know very much about relaxNG, but I guess you could be
> > interested in the isorelax and jing packages.  Don't hesitate to help
> > maintaining them :)
> 
> We were already talking about this when jing-trang was in NEW; you
> remember :) ? But I currently maintain around 50 source packages. So I
> would like to see some new maintainers interested in XML to step in. The
> XML/SGML group is currently pretty small.

I have an interest in xml. I could join after my phd defence (aka after 
november the 27th).

Bastien


> Regards, Daniel
> 


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

Bug#508585: Please provide an easy and official way to get debug symbols for all arch

[Bastien ROUCARIES]

Package: general
Severity: normal

hello,

In case of bug on rare arch it is quite difficult for the maintener to get 
debug trace. 
A generic stuff like http://debug.debian.net/ will help to solve hard diagnose 
bug like the  #508443 and avoid to create -dbg package like in #508582:
apt-cache search dbg |grep "\-dbg" | wc -l
773
Therefore please find a way to generalize http://debug.debian.net/ and get dbg 
package compiled on the arch, and offer a deb-debug like deb-source deposit.
Using a deb-debug method will allow simple user to download the debug symbol 
without the need to contact the administrator. I even dream of a 
apt-get dbg-depend package that will download all the debug symbols, including 
library linked against my binary.

Keep in mind that maintener time and user time are precious, and a quick 
backstack is often an invaluable information.

Regards

Bastien


--- System information. ---
Architecture: amd64
Kernel:   Linux 2.6.26-1-amd64

Debian Release: lenny/sid
  990 testing security.debian.org 
  990 testing debian.ens-cachan.fr 
   99 unstabledebian.ens-cachan.fr 
  500 lenny   kde4.debian.net 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
| 



-- 

"ROUCARIES Bastien"
   roucaries.bast...@gmail.com
---
DO NOT WRITE TO roucaries.bastien+blackh...@gmail.com OR BE BLACKLISTED



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

Re: For those who care about pam-ssh: RFC

[Bastien ROUCARIES]

On Wed, Dec 17, 2008 at 12:57 AM, Steve McIntyre  wrote:
> Luca wrote:
>>2008/12/16 Luca Niccoli :
>>
>>> I can't really see what I'm doing wrong...
>>
>>Maybe I have a clue:
>>
>>++file_filter(const struct dirent *dir)
>>++{
>>++  return (DT_REG == (DT_REG & dir->d_type)) ||
>>++ (DT_LNK == (DT_LNK & dir->d_type)) ;
>>++}
>>
>>But I use XFS, which seems to have some problems with d_type [1]
>>I'm not really sure this is the source of the problem, but I thought
>>it was worth giving a try...

Reading the man page of readdir you should alway test for DT_UNKNOWN,
and fallback to stat
if DT_UNKNOWN is set. And you should guard this test by #ifdef
_DIRENT_HAVE_D_TYPE

Moreover if you read getdents manpage, you will read that d_type is
only filled since 2.6.4! In all the case I think we need to open a bug
for getdents manpage it does not specify that d_type is DT_UNKNOW
before 2.6.4 (backward compatibilty). I will fill a bug report.

Perhaps filling a bug to manpage will be appropriate because wording
is not clear.

Please beware that they are issue with link and directory. Like for instance in
http://mail.kde.org/pipermail/kdelibs-bugs/2008-March/001006.html

d_type is an optimization not a thing that alway work.

Bastien


> I don't know about the exact state today, but at least in the past
> many filesystems have not filled in d_type in readdir() calls. If you
> want to see the type of a filesystem object safely and portably,
> you'll need to call stat() or similar on each file.
>
> --
> Steve McIntyre, Cambridge, UK.st...@einval.com
>  Mature Sporty Personal
>  More Innovation More Adult
>  A Man in Dandism
>  Powered Midship Specialty
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


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

Re: For those who care about pam-ssh: RFC

[Bastien ROUCARIES]

On Wed, Dec 17, 2008 at 2:11 AM, Bastien ROUCARIES
 wrote:
> On Wed, Dec 17, 2008 at 12:57 AM, Steve McIntyre  wrote:
>> Luca wrote:
>>>2008/12/16 Luca Niccoli :
>>>
>>>> I can't really see what I'm doing wrong...
>>>
>>>Maybe I have a clue:
>>>
>>>++file_filter(const struct dirent *dir)
>>>++{
>>>++  return (DT_REG == (DT_REG & dir->d_type)) ||
>>>++ (DT_LNK == (DT_LNK & dir->d_type)) ;
>>>++}
>>>
>>>But I use XFS, which seems to have some problems with d_type [1]
>>>I'm not really sure this is the source of the problem, but I thought
>>>it was worth giving a try...
>
> Reading the man page of readdir you should alway test for DT_UNKNOWN,
> and fallback to stat
> if DT_UNKNOWN is set. And you should guard this test by #ifdef
> _DIRENT_HAVE_D_TYPE

> Moreover if you read getdents manpage, you will read that d_type is
> only filled since 2.6.4! In all the case I think we need to open a bug
> for getdents manpage it does not specify that d_type is DT_UNKNOW
> before 2.6.4 (backward compatibilty). I will fill a bug report.

I should add that man page specify that DT_UNKNOW should be handled
see  http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html

> Perhaps filling a bug to manpage will be appropriate because wording
> is not clear.
>
> Please beware that they are issue with link and directory. Like for instance 
> in
> http://mail.kde.org/pipermail/kdelibs-bugs/2008-March/001006.html
>
> d_type is an optimization not a thing that alway work.
>
> Bastien
>
>
>> I don't know about the exact state today, but at least in the past
>> many filesystems have not filled in d_type in readdir() calls. If you
>> want to see the type of a filesystem object safely and portably,
>> you'll need to call stat() or similar on each file.
>>
>> --
>> Steve McIntyre, Cambridge, UK.
>> st...@einval.com
>>  Mature Sporty Personal
>>  More Innovation More Adult
>>  A Man in Dandism
>>  Powered Midship Specialty
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>>
>>
>


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

Re: Bug#509063: ITP: libproxy -- automatic proxy configuration management library

[Bastien ROUCARIES]

On Thu, Dec 18, 2008 at 12:35 PM, Bjørn Mork  wrote:
> Florian Weimer  writes:

> I would very much like this library to become the *only* WPAD
> implementation anywhere.  Hopefully eventually with some ability to
> define local policies, where the default Debian policy could be very
> strict.  E.g. "Never trust DNS for WPAD", or "Never use WPAD at all".

I tend to agree, we have not forbidden root to do rm -arf .
It is the same, it is a policy problem. With current libproxy, could root
 forbid the use of WPAD, even if user ask it?

Regards

Bastien


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

Re: Bug#509063: ITP: libproxy -- automatic proxy configuration management library

[Bastien ROUCARIES]

On Thu, Dec 18, 2008 at 6:13 PM, Michael Banck  wrote:
> On Thu, Dec 18, 2008 at 12:51:34PM +0100, Bastien ROUCARIES wrote:
>> On Thu, Dec 18, 2008 at 12:35 PM, Bjørn Mork  wrote:
>> > Florian Weimer  writes:
>>
>> > I would very much like this library to become the *only* WPAD
>> > implementation anywhere.  Hopefully eventually with some ability to
>> > define local policies, where the default Debian policy could be very
>> > strict.  E.g. "Never trust DNS for WPAD", or "Never use WPAD at all".
>>
>> I tend to agree, we have not forbidden root to do rm -arf .
>> It is the same, it is a policy problem. With current libproxy, could root
>>  forbid the use of WPAD, even if user ask it?
>
> Dan Winship, one of the libproxy authors, replied:
>
> |- The fact that it's broken doesn't change the fact that lots of
> |  sites use it
> |
> |- It's already implemented by other programs in the distro anyway
> |  (notably Firefox)
> |
> |- Its use in libproxy can be disabled system-wide by the
> |  administrator
> |
> |I think in current libproxy WPAD is enabled by default though. We should
> |make sure that's changed.

I will be interesting also to add a link or copy verbatim (with author
permission) in README.Debian, the poisson pill
of this protocol, see for instance
http://www.mercenary.net/blog/index.php?/archives/42-HOWTO-WPAD.html
and some explanation about (in)security of wpad.

Regards

Bastien


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

Help needed for #377468

[Bastien ROUCARIES]

Hi!

I would like to ask for some help for the bug #377468, if possible,
please. Particularly from a mozilla-plugin wizard.

The problem is that djvulibre in upstream is not linked against a particular 
libXt 
in order to adapt against different libXt version depending of the browser used.
The question raised by the upsteam is the case of the browser itself already 
uses libXt, and links to
a different version of the library than the plugin. 

This bug is easily demonstrable using the command [1]:
$ ldd -d -r /usr/lib/netscape/plugins-libc6/nsdejavu.so  

But this behavior is quite fragile and could break [2] and I personally think 
that on debian browser and plugin 
will use the same version of library.

Does my assertion is always valid? Can I enforce linking against libXt at build 
time? 

BTW should we contact other plugin developper about bug like this and should we 
document this issue?

Regards

Bastien
-- 

"ROUCARIÈS Bastien"
   roucaries.bastien+deb...@gmail.com
---
DO NOT WRITE TO roucaries.bastien+blackh...@gmail.com OR BE BLACKLISTED


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

Re: Bug#509063: ITP: libproxy -- automatic proxy configuration management library

[Bastien ROUCARIES]

On Sun, Dec 21, 2008 at 9:30 PM, Emilio Pozuelo Monfort
 wrote:
> Hi Florian,
>
> Thanks for your concerns. I appreciate it.
>
> Florian Weimer wrote:
>> Not enabling WPAD with DNS devolution goes a long way towards dealing
>> with this mess.
>
> Would you be fine if libproxy disabled WPAD by default? I think libproxy's
> developers are willing to do that, according to [1].

Could you please explain how documentation is done, particularly
inherence of configuration stuff.
Could you give an exemple how can admin could forbid for all the user
to use WPAD? Or could you give some pointer.
Upstream documentation is quite sparse :-(

Regards

Bastien


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

[libmagick9] Help needed defoma

[Bastien ROUCARIES]

Tags: help

Hi,

Imagemagick does use a static list of police. This could lead to problem and 
user have already send bug report.
Could be possible to help us implementing a defoma script for imagemagick?

Regards

Bastien


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

Re: Bug#509063: ITP: libproxy -- automatic proxy configuration management library

[Bastien ROUCARIES]

On Thu, Jan 8, 2009 at 12:46 AM, Emilio Pozuelo Monfort
 wrote:
> Hi Florian, and sorry for the long delay.
>
> Florian Weimer wrote:
>> Well, it's not my package, so you don't have to listen to me.  I'm
>> also not speaking for the security team.
>
> Oh, should you have said that before, I'd have ignored all your comments :P
>
>> But I appreciate your
>> efforts to address my concerns.
>
> And I appreciate you raising your concerns. I don't want to bring anything to
> Debian if it has serious security issues. Specially if it's a library that is
> going to be used by lots of projects (including GNOME).
>
>>>From a PR point of view[1], I strongly suggest to disable it by
>> default, and implement only the partial form which is present in
>> Iceweasel (just look up "wpad.", and no DNS devolution).
>
> I've talked with upstream and he's told me he would accept any patch that
> disables any portion of the code that may have security implications, 
> providing
> there's an option to enable it (at build time). He also prefers those portions
> of code to be disabled by default, so we're good.

Instead of disable code could be made dependant of /etc/ configuration
file. It is policy, you could install telnetd even if it is insecure
in your local machine.

A global configuration file will be nice. And if root want to shoot
himself in is foot and allow user to do it why not.

Regards

Bastien


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

Re: Help bts-link be a more effective tool

[Bastien ROUCARIES]

On Sat, Jan 17, 2009 at 8:36 PM, Sandro Tosi  wrote:
> Hello,

> If you feel something is missing, should be fixed or enhanced, let
> us[4] know; of course, patches are welcome ;) (git repo at [5]).

I really useful stuff will be to use user tag in order to crossref
another distrib bugzilla. For instance some bug are fixed on redhat
like #506180 but not upstream.
It will allow to automatize retrieval of information.

Regards

Bastien


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

Re: Help bts-link be a more effective tool

[Bastien ROUCARIES]

On Mon, Jan 19, 2009 at 7:12 AM, Christian Perrier  wrote:
> Quoting Bastien ROUCARIES (roucaries.bast...@gmail.com):
>> On Sat, Jan 17, 2009 at 8:36 PM, Sandro Tosi  wrote:
>> > Hello,
>>
>> > If you feel something is missing, should be fixed or enhanced, let
>> > us[4] know; of course, patches are welcome ;) (git repo at [5]).
>>
>> I really useful stuff will be to use user tag in order to crossref
>> another distrib bugzilla. For instance some bug are fixed on redhat
>> like #506180 but not upstream.
>> It will allow to automatize retrieval of information.
>
>
> Apparently, Launchpad has something like this, which is, for instance,
> used to reference bugs also reported in Debian. We found this fairly
> useful, recently, for Samba.

Yes it is useful :)

> However, such feature should probably be included in the BTS itself
> (new tag or something).

Yes it will need I suppose cooperation from BTS itself but in a second
time. We need only two user tags by foreign distrib:
bts-link-foreign-xref-$distrib set to the foregin bugzilla entry
bts-link-foreign-status-$distrib  magically set by bts-link

In a second time BTS interface could provide link near the forwarded
link with status in other distrib (with a nice icon describing status)

We will need also a means to put in the package describtion link to
other distrib bugzilla, and we ease to remove duplicate entry :)

Regards

Bastien

PS: do not trim cc please


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

Re: Tracing bugs between distro's bugtrackers - Was: Re: Help bts-link be a more effective tool

[Bastien ROUCARIES]

On Mon, Jan 19, 2009 at 10:36 AM, Olivier Berger
 wrote:
> Hi.
>
> Le dimanche 18 janvier 2009 à 19:54 +0100, Bastien ROUCARIES a écrit :
>> On Sat, Jan 17, 2009 at 8:36 PM, Sandro Tosi  wrote:
>> > Hello,
>>
>> > If you feel something is missing, should be fixed or enhanced, let
>> > us[4] know; of course, patches are welcome ;) (git repo at [5]).
>>
>> I really useful stuff will be to use user tag in order to crossref
>> another distrib bugzilla. For instance some bug are fixed on redhat
>> like #506180 but not upstream.
>> It will allow to automatize retrieval of information.
>>
>
> FYI, that's the kind of features we're working on in the HELIOS project
> (more details here :
> https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web ).
>
> We're thinking about helping navigate and manage bugs by allowing the
> navigation between various distros and upstream bugtrackers... I hope
> our efforts will benefit Debian through bts-link and other tools, of
> course.
>
> We're still just started and busy with lots of things, and nothing
> concrete do demonstrate so far.
>
> We're currently trying to evaluate work that has been conducted by
> others in the Nepomuk project to find if ontologies and RDF are
> interesting to allow the representation of such meta-data about bugs and
> links between bugs in standard format.
>
> Of course the use of debbugs (user)tags is very interesting (compared to
> what exist in other bugtrackers) to store such elements, but we're
> thinking about devising something that would scale to the vast majority
> of bugtrackers used by the free software communities... so we probably
> need to think about an external store, and hence RDF standard format and
> such.

Yes and it could work with minimal modification of bts-link:
We need only two user tags by foreign distrib:
bts-link-foreign-xref-$distrib set to the foregin bugzilla entry
bts-link-foreign-status-$distrib  magically set by bts-link

If you go to fosdem, a working example of such a tool will be really useful :)
After we could try to standardize this kind of stuff, but we need an example :)

Regards

Bastien


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

Re: Tracing bugs between distro's bugtrackers - Was: Re: Help bts-link be a more effective tool

[Bastien ROUCARIES]

On Mon, Jan 19, 2009 at 10:46 AM, Olivier Berger
 wrote:
> Le lundi 19 janvier 2009 à 07:12 +0100, Christian Perrier a écrit :
>> Quoting Bastien ROUCARIES (roucaries.bast...@gmail.com):
>> >
>> > I really useful stuff will be to use user tag in order to crossref
>> > another distrib bugzilla. For instance some bug are fixed on redhat
>> > like #506180 but not upstream.
>> > It will allow to automatize retrieval of information.
>>
>>
>> Apparently, Launchpad has something like this, which is, for instance,
>> used to reference bugs also reported in Debian. We found this fairly
>> useful, recently, for Samba.
>>
>
> Any idea if they have some common interchange format for their
> bugs ? ... there looked like ideas about RDF export in the REST
> interface of launchpad... but that was not operational last tieme I've
> checked :(
>
> I'd be curious to see how such links between launchpad and debbugs would
> be represented, then.

See previous proposal :)

>>
>> However, such feature should probably be included in the BTS itself
>> (new tag or something).
>>
>
> And :
>> FYI, that's the kind of features we're working on in the HELIOS
>> project
>> (more details here :
>> https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web ).
>>
>
> [...]
>
>> We're currently trying to evaluate work that has been conducted by
>> others in the Nepomuk project to find if ontologies and RDF are
>> interesting to allow the representation of such meta-data about bugs
>> and
>> links between bugs in standard format.
>>
>
> Oh, I forgot to mention, that we're more or less planing to work with
> Mandriva people (who worked for that Nepomuk-related bug store
> prototype) in Helios... so I hope we'll be able to provide more links
> between Mandriva bugs and Debian bugs (and upstream bugs).

Mandriva use bugzilla and therefore bts-link will retrieve this kind of bug :)

> There would be some need for inter-distro work here, maybe... any ideas
> on where to discuss that much welcome ;)

Yes I agree, but I believe that it will need less than fifty line of
code in bts-link :)
So it will take more time to discuss than to code :)

Regards

Bastien


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

Re: Help bts-link be a more effective tool

[Bastien ROUCARIES]

On Mon, Jan 19, 2009 at 10:50 AM, Bastien ROUCARIES
 wrote:
>ll need I suppose cooperation from BTS itself but in a second
> time. We need only two user tags by foreign distrib:
> bts-link-foreign-xref-$distrib set to the foregin bugzilla entry
> bts-link-foreign-status-$distrib  magically set by bts-link
>
> In a second time BTS interface could provide link near the forwarded
> link with status in other distrib (with a nice icon describing status)
>
> We will need also a means to put in the package describtion link to
> other distrib bugzilla, and we ease to remove duplicate entry :)

I downloaded git source but I have some problem. How can I test some
stuff on BTS? I does not include a sandbox package (see bug
435...@bugs.debian.org)

How can we test improvement?

Regards

Bastien


> PS: do not trim cc please
>


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

Bug#512916: ITP: [auto07p] -- a software for continuation and bifurcation problems in ordinary differential equations

[Bastien ROUCARIES]

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

   Package name: auto07p
Version:  0.6
Upstream Author: Eusebius Doedel
URL: http://indy.cs.concordia.ca/auto/
License: BSD with some part GPL
Description: AUTO is a software for continuation and bifurcation problems 
in ordinary differential equations.
   AUTO can do a limited bifurcation analysis of algebraic systems of the form 
f(u,p) = 0,f,u in Rn
and of systems of ordinary differential equations of the form 
u'(t) = f(u(t),p),f,u in Rn
subject to initial conditions, boundary conditions, and integral 
constraints. Here p denotes one or more parameters. AUTO can also 
do certain continuation and evolution computations for parabolic PDEs. 
It also includes the software HOMCONT for the bifurcation analysis of 
homoclinic orbits. AUTO 
is quite fast and can benefit from multiple processors; therefore it is 
applicable to rather large systems of differential equations.

-- 

"ROUCARIÈS Bastien"
roucaries.bastien+deb...@gmail.com
---
DO NOT WRITE TO roucaries.bastien+blackh...@gmail.com OR BE BLACKLISTED



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

MIA Ryuichi arafune?

[Bastien ROUCARIES]

It seems Ryuichi is MIA. 
See for instance http://www.webservertalk.com/archive97-2007-1-1765203.html

Ryuichi are you reading this? What's your status regarding Debian? 
Particularly what is your status regarding bug 432185 (gnuplot-mode)?

Thank you very much,
-- 

"ROUCARIES Bastien"
 [EMAIL PROTECTED]
---

-


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

Re: Cmap file are now free: List of package to move to main

[Bastien ROUCARIES]

On Thu, Sep 24, 2009 at 10:46 AM, Bastien ROUCARIES
 wrote:
> Hi,
>
> According to Paul Wise:
>
>>The Adobe CMap resources are now free software and licensed under the
>>BSD license. More information about this can be found here:
>>>http://bonedaddy.net/pabs3/log/2009/09/24/adobe-data-freed/
>>http://lists.debian.org/debian-legal/2009/09/msg00039.html
>
> The following package that depends on cmap (according to licence file) may be
> moved to main:
> cmap-adobe-cns1
> cmap-adobe-gb1
> cmap-adobe-japan1
> cmap-adobe-korea1
> poppler-data
> gs-cjk-resource
> xpdf-japanese
> xpdf-chinese-simplified
> xpdf-chinese-traditional
> xpdf-korean
> libpdfbox-java
> libpdfbox-java-doc (could be done now BTW)
> jabref
>
Only the xpdf* package  are remaining. CC Hamish Moffatt

Regards

Bastien


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

Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support

[Bastien ROUCARIES]

On Tue, Jan 19, 2010 at 10:48 AM, Samuel Thibault  wrote:
> Martin Koegler, le Tue 19 Jan 2010 09:27:07 +0100, a écrit :
>> Samuel Thibault  wrote:
>> > Marc Leeman, le Sun 17 Jan 2010 22:16:17 +0100, a écrit :
>> > > * Package name    : pthsem
>> >
[..]
>
> The problem is that people know pth, but they don't know pthsem (yet).
> It will be a long time before people discover that there is a new
> interesting pthsem package that basically does the same as pth with
> quite a few extra features, is not dead etc.  Why not just replacing the
> existing pth package with pthsem to avoid that delay?

Why not creating a dummy package pth with only compat mode ? This
package will be transationnal and will provide a depend to pthsem

Regards

Bastien


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

Re: Cmap file are now free: List of package to move to main

[Bastien ROUCARIES]

Remainder:
On Mon, Jan 4, 2010 at 11:36 AM, Bastien ROUCARIES
 wrote:

>>>The Adobe CMap resources are now free software and licensed under the
>>>BSD license. More information about this can be found here:
>>>>http://bonedaddy.net/pabs3/log/2009/09/24/adobe-data-freed/
>>>http://lists.debian.org/debian-legal/2009/09/msg00039.html
>>
>> The following package that depends on cmap (according to licence file) may be
>> moved to main:
>> cmap-adobe-cns1
>> cmap-adobe-gb1
>> cmap-adobe-japan1
>> cmap-adobe-korea1
>> poppler-data
>> gs-cjk-resource
>> xpdf-japanese
>> xpdf-chinese-simplified
>> xpdf-chinese-traditional
>> xpdf-korean
>> libpdfbox-java
>> libpdfbox-java-doc (could be done now BTW)
>> jabref
>>
> Only the xpdf* package  are remaining. CC Hamish Moffatt

I have send this mail two months ago and no answer, therefore I
resend. Please add cmap to main.

Bastien


--
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/195c7a901003010119o460ddab9i2076c37dc3f12...@mail.gmail.com

Re: Bug#545782: imagemagick-dbg: missing README.Debian to explain how programs are used

[Bastien ROUCARIES]

Any progress on this bug ?

On Sun, Dec 27, 2009 at 8:26 PM, Nelson A. de Oliveira
 wrote:
> Hi!
>
> On Sun, Dec 27, 2009 at 10:14 AM, Jari Aalto  wrote:
>> Repoening, this doesn't address the original bug report titled "missing
>> README.Debian to explain how programs are used". Please provide
>> instructions how to use those files with gdb in order to examine
>> problems with imagemagick problems.
>>
>> There could be even a use case how to start debugging some of the
>> programs, like "convert".
>
> The problem here is that we have a lot of -dbg packages on Debian, all
> of them containing binaries under /usr/lib/debug/
> Do we need the same README file on all of them? We will have more than
> a thousand equal READMEs on the archive, explaining the same thing.
> I don't think that a file explaining how to use them with gdb belongs
> to imagemagick-dbg (nor any other -dbg packages).
>
> My view is that, if necessary, the package maintainer is responsible
> in helping the user to get a backtrace (by pointing how to use gdb,
> install the -dbg package, etc).
> Or at least an explanation in the gdb package only.
>
> CCing debian-devel to see if we can get better opinions and solutions for 
> this.
>
> Best regards,
> Nelson
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


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

RE : Re: Cmap file are now free: List of package to move to main

[Bastien ROUCARIES]

the bug report are already made.

Le 6 mars 2010 12:06, "Yves-Alexis Perez"  a écrit :

On lun., 2010-03-01 at 10:19 +0100, Bastien ROUCARIES wrote:
>
> I have send this mail two months a...
Maybe you just need to report bugs against concerned packages so the
maintainer changes the section.

Cheers,
--
Yves-Alexis

Re: Suggestions to fix #433462 (add free space info to reportbug)

[Bastien ROUCARIES]

On Tue, Mar 16, 2010 at 12:12 AM, Sandro Tosi  wrote:
> Hi all,
> in bug #433462 there is a request to add free space information in
> reportbug standard info appended to bug report.
>
> It's a valid request, that I want to fulfill, but there are some
> aspects I'd like to discuss.
>
> First of all, with your package maintainers hat on, what kind of
> information you'd like? only the value of free MB in the disk? total
> size, free size? also percentage? I think that from a bug report
> point-of-view, only the free megabytes value would do.
>
> That said, what to report? Simply taking the output of "df -h" and
> attaching to reportbug template it's not what I like: there could be
> more partitions/disks not interesting for the report/system in that
> output, and I don't want to include them.
>
> So I thought: "Easy, just take the information for / and add them".
> Well, not really. There are situation where /usr, /var, /etc and/or
> many more directories are in separate partitions, and it might be
> interesting to include those information too (if not with /). But, how
> further should I go? Just take / and /usr, /var, /etc if-not-in-/ and
> add them? what if /var has subdirs like /var/log /var/tmp /var/lib
> splitted in different partition? what if /usr has /usr/bin and
> /usr/share on a NFS filer?
>
> So, just to recap:
>
> - what free space information you'd like? (I'd propose only the count
> of free MB)
> - what directory to show in the report? (I'd propose /, /var, /usr,
> /etc if the latter 3 not in / but not going recursively under them)
>
> Thanks for your attention,
> Sandro
>
> PS: please keep the bug in CC, so that there will he history of the
> discussion there too.

Do not forget quota please

Bastien


-- 
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/195c7a901003161047g698e0d91o9e8fc207d16ff...@mail.gmail.com

Re: Suggestions to fix #433462 (add free space info to reportbug)

[Bastien ROUCARIES]

On Thu, Mar 18, 2010 at 8:32 AM, Yves-Alexis Perez  wrote:
> On mer., 2010-03-17 at 17:26 +0100, Goswin von Brederlow wrote:
>> On the other hand including free space information will be difficult to
>> handle properly and possibly expose information the user considers
>> private.
>
> But places where packages are supposed to write aren't that private.
> Usually /home (but if people mount one fs per user there might be
> privacy issues), /tmp (not really private), /var (either). Packages
> install/upgrades will write in /usr and /etc and few other folders
> (/boot..) which aren't really private either.
>
> Real issues will appear for stuff using “named” mount point in /srv
> (or /home as said above).
>>
>>
>> But if you do go ahead with this consider this:
>>
>> The bugreport gives the following argument: "I suspect that a lot of my
>> packages would fail in mysterious ways if the root partition was full."
>> How will his software behave with the root partition being mounted
>> read-only? Listing the free space on root or /usr would be completly
>> meaningless if they are read-only and writing to them would be a
>> critical bug anyway.
>
> One thing which could be done too is to run the df, detect if there are
> full fs, and if there are, ask for the user if she wants to include the
> result.

Add also quota information if available


--
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/195c7a901003180212p56c3616aj72306e8d62750...@mail.gmail.com

Re: Naming policy for Perl modules (mass bug filing)

[Bastien ROUCARIES]

2010/3/23 Ansgar Burchardt :
> Hi,
>
> the Debian Perl Policy asks for packages for the Foo::Bar module to be
> named libfoo-bar-perl [1].  Some packages do not adhere to this scheme:
>
>  opalmod               → libopal-perl
>  gnuift-perl           → libgnuift-perl
>  perl-mapscript        → libmapscript-perl
>  perl-tk               → libtk-perl
>  speedy-cgi-perl       → libspeedy-cgi-perl
>  exactimage-perl       → libexactimage-perl
>  perl-ifeffit          → libifeffit-perl
>  rplay-perl            → librplay-perl
>  nfqueue-bindings-perl → libnfqueue-perl
>  perlmagick            → libimage-magick-perl

In this case perlmagick is the upstream name, but we could create an
empty package  libimage-magick-perl that will depend on  perlmagick ,
or the reverse if needed, but thename perlmagick should be kept due to
upstream naming [1].

[1] http://www.imagemagick.org/script/perl-magick.php

Bastien


--
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/195c7a901003230147u22d479abxa7889a98e9e63...@mail.gmail.com

Re: Libreadline6 is GPLv3: incompatible with GPLv2-only software

[Bastien ROUCARIES]

On Wed, Apr 28, 2010 at 8:09 PM, James Y Knight  wrote:
>
> On Apr 28, 2010, at 11:32 AM, James Y Knight wrote:
>>
>> After checking a scattering of random packages, I happened across one 
>> example of this already in Debian testing: socat. It is GPLv2-only, and is 
>> linked against GPLv3 libreadline6 in testing. (filed bug 579494).
>
> One further note: Fedora seems to have already run across this issue and 
> fixed their socat package to build against compat-readline5-devel:
> http://article.gmane.org/gmane.linux.redhat.fedora.package.announce/34983
>
> I guess it's probably easier to check these sorts of things in Fedora since 
> RPM has a license field in the metadata.
>

Why not using http://www.thrysoee.dk/editline/ already included in
debian and that seems to be source compatible.

Bastien


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

Re: UPG and the default umask

[Bastien ROUCARIES]

On Mon, May 17, 2010 at 10:22 AM, Christoph Anton Mitterer
 wrote:
> On Sun, 16 May 2010 18:18:14 -0400, Felipe Sateler 
> wrote:
>> Is there a reason to support non-UPG systems?
> Not to force users to use anything that they don't want?
>
>
> btw: While I stopped at some point commenting that issue, when I realised
> that general security concerns were simply ignored,... I've seen that there
> were plans to automatically detect whether a user could have "secure" UPG,
> right?
>
> May I suggest the following:
> Either:
> 1) Debian should make this decision fully configurable (whether to use UPG
> and which umask _system wide_ (!) or not). Of course it is already
> configurable, but I mean something like configuration during installer
> phase, or via debconf at some package where this fits to.
> At that/those places, when choosing UPG, only the supposedly "secure"
> default umasks could be presented and the user could be taught about the
> pros and cons of UPGs.
>
> Or:
> 2) It should be easy to prevent the now ongoing changes (switching default
> umask and so on), and for new installations, easy to go back to the old
> way.
> 3) If you make such automatic checks whether a user can have UPGs
> "securely", I guess you should take care that these checks are
> "dynamically", as a user may change his groups.
>
>
> btw2: Has there been a final decision whether this UPG-stuff is also
> enabled for system users? Especially things like the users from postgresql,
> or other daemons?

See below libpam umask could be used for this task and extended if needed.

>
> btw3: As this change seems to be decided, wouldn't it make sense to change
> the UMASK value in login.defs and the currently documentation that tells
> some secure values:
> # 022 is the "historical" value in Debian for UMASK when it was used
> # 027, or even 077, could be considered better for privacy
> # There is no One True Answer here : each sysadmin must make up his/her
> # mind.
> #UMASK          022
>
> to the "new" ones with the insecure ones:
> # 022 is the "historical" value in Debian for UMASK when it was used
> # 002 is the new default for use with user private groups.
> # There is no One True Answer here : each sysadmin must make up his/her
> # mind.
> #UMASK          002
>

Using libpam umask will be simplier:
Put this to /etc/pam.d/common-session file:
session optional pam_umask.so umask=022

Only one place and documented.

Bastien


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

Re: UPG and the default umask

[Bastien ROUCARIES]

On Mon, May 17, 2010 at 12:26 PM, Harald Braumann  wrote:
> On Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila wrote:
>
>> Will be done in base-files 5.4.
>
> I think that this change was done prematurely. There is still the
> issue of a Debian system running in a non-UPG environment. And so far
> I haven't seen a resolution for this point in the discussion.

I believe the pam umask module is the way to go according to
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_umask.html

 [opition] usergroups

If the user is not root, and the user ID is equal to the group ID,
and the username is the same as primary group name, the umask group
bits are set to be the same as owner bits (examples: 022 -> 002, 077
-> 007).

Regards

Bastien

>
> Cheers,
> harry
>
>
> --
> 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/20100517102642.gd4...@sbs288.lan
>
>


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

Re: UPG and the default umask

[Bastien ROUCARIES]

On Mon, May 17, 2010 at 2:22 PM, Santiago Vila  wrote:
> On Mon, 17 May 2010, Timo Juhani Lindfors wrote:
>
>> Santiago Vila  writes:
>> > In either case, if we plan to set default umask in /etc/login.defs or
>>
>> /etc/login.defs is not read when I login to openssh server and it has
>> "UseLogin" set to false. If I enable UseLogin then X11 forwarding
>> stops working [1]. To me it seems that login.defs can not be the only
>> place where umask is set.
>
> Ok, what about PAM?
>
> I would *really* like to drop umask setting from /etc/profile and rely on
> something of lower level, be it login.defs, PAM or whatever.
>
> What would be the steps required to be able to drop umask from /etc/profile?

See
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_umask.html

Put this to /etc/pam.d/common-session file:
session optional pam_umask.so umask=002

And it will work

Regards

Bastien

>
> --
> 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/alpine.deb.1.10.1005171419450.12...@kolmogorov.unex.es
>
>


-- 
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/aanlktin1p37y8zke5yt8c8jkoz-fcee9y47jeqnbk...@mail.gmail.com

Re: UPG and the default umask

[Bastien ROUCARIES]

On Mon, May 17, 2010 at 3:34 PM, Marvin Renich  wrote:
> * Reinhard Tartler  [100517 08:56]:
>> Let's have a look at the source. Note that options->usergroups is set
>> iff the option "usergroups" is used.
>>
>> ,[modules/pam_umask/pam_umask.c]
>> | /* Set the process nice, ulimit, and umask from the
>> |    password file entry.  */
>> | static void
>> | setup_limits_from_gecos (pam_handle_t *pamh, options_t *options,
>> |                      struct passwd *pw)
>> | {
>> |   char *cp;
>> |
>> |   if (options->usergroups)
>> |     {
>> |       /* if not root, and UID == GID, and username is the same as
>> |      primary group name, set umask group bits to be the same as
>> |      owner bits (examples: 022 -> 002, 077 -> 007).  */
>> |       if (pw->pw_uid != 0 && pw->pw_uid == pw->pw_gid)
>> |     {
>> |       struct group *grp = pam_modutil_getgrgid (pamh, pw->pw_gid);
>> |       if (grp && (strcmp (pw->pw_name, grp->gr_name) == 0))
>> |         {
>> |           mode_t oldmask = umask (0777);
>> |           umask ((oldmask & ~070) | ((oldmask >> 3) & 070));
>> |         }
>> |         }
>> |     }
>> `

Another bug is the code does not check if they are only one user on the group.

Regards

Bastien


--
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/aanlktiljeb7l0vnlvyz-q3kij4fvrmxldjpkkz6v3...@mail.gmail.com

Re: UPG and the default umask

[Bastien ROUCARIES]

On Tue, May 18, 2010 at 3:12 PM, Harald Braumann  wrote:
> On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote:
>> On 2010-05-18, Christoph Anton Mitterer  wrote:
>> > Not to speak about, that UPG is anyway a questionable abuse of the
>> > user/group concept.
>> >
>> > Neither to speak about the fact, that in the 17 years debian exists
>> > now,... no majority missed that "feature" (apparently).
>>
>> So you present that as universal facts as if you've booked the truth
>> (possibly a bad translation of a German saying).
>>
>> I think that feature is useful for all those who don't want to mess
>> with ACLs.  If you are not allowed to use ACLs and don't have UPG
>> with sane umasks collaboration is painful (see e.g. Debian infrastrure
>> with all users being in group Debian and default umask 0022 which
>> leads to wrong permissions in setgid directories, with ACLs being
>> disallowed).  So indeed I got a script which does newgrp and
>> setting the umask for me which I run whenever I want to do release
>> tasks.  But it would be more sane if the user wouldn't have to
>> care about that.
>
> Let me quote from the comments in /etc/login.defs:
>
> # 022 is the "historical" value in Debian for UMASK when it was used
> # 027, or even 077, could be considered better for privacy
> # There is no One True Answer here : each sysadmin must make up his/her
> # mind.
>
> And that's exactly the problem: there is no one-size-fits-all
> for the umask. Yes, for collaboration in a setgid directory you'd have
> to use 002 and thanks to UPG this is possible without compromising
> security. But I consider this just a special case. There are
> cases where Debian runs in a non-UPG environment, where you can't use
> that umask. And I don't think that's uncommon. Think of a mixed
> environment with Windows, where you might have a samba domain in LDAP. And
> last time I checked, the smbldap-tools didn't support UPG.

Could you fill a bug report against smbldap-tools ?


> So whatever value is used as the default, half of the users will have
> to change it anyway, to fit their needs. And in such a case, where
> there is no single optimal value, I'd rather have the most
> conservative as default.
>
> If the umask is 022 and you create a setgid
> directory and forget to change the umask, you will quickly realise
> that things are not working as expected and fix it. If the umask is
> 002 and you add your Debian system to a non-UPG environment and forget
> to change the umask, things will still work perfectly but you put all
> your files at risk and might not even realise it until it is too
> late.

Why not add a security dialog and assistant for installing and
upgrading the system?
It will ease the transition and fit allt the need, documenting
drawbacks and advantages of each scheme ?

And offer a sensible default choice (and skip button) for desktop user ?

Regards

Bastien

> Cheers,
> harry
>
>


--
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/aanlktin92rw-krk1jajy6knyqm6z-mzt4hd8wzchf...@mail.gmail.com

Re: UPG and the default umask

[Bastien ROUCARIES]

reopen 315089
thanks

On Mon, May 17, 2010 at 11:05 PM, Marvin Renich  wrote:
> * Aaron Toponce  [100517 13:05]:
>> On 05/17/2010 10:49 AM, Harald Braumann wrote:
>> > from pam_umask's description of the usergroups option:
>> >
>> > If the user is not root, and the user ID is equal to the group ID, *and*
>> > the username is the same as primary group name, the umask group bits
>> > are set to be the same as owner bits (examples: 022 -> 002, 077 ->
>> > 007).
>> >
>> > So if there is a mismatch of *either*, name or ID, then pam_umasks
>> > detects a non-UPG system, while it might very well be all UPG.
>>
>> A bug in pam_umask.so that needs to be addressed (which I believe we've
>> already started addressing in this thread).
>
> Bug #581984.

Closed by maintener and reopened, if we use libpam for umask it could
be even raised to RC critical, so please correct this behavior, report
upstream. I agree that it could be misleading for other distro in this
case, please add a newoption like useupg.

Thanks

Bastien


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

Re: UPG and the default umask

[Bastien ROUCARIES]

On Tue, May 18, 2010 at 4:16 PM, Harald Braumann  wrote:
> On Tue, May 18, 2010 at 03:40:06PM +0200, Bastien ROUCARIES wrote:
>> On Tue, May 18, 2010 at 3:12 PM, Harald Braumann  wrote:
>> > On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote:
>> >> On 2010-05-18, Christoph Anton Mitterer  wrote:
>> >> > Not to speak about, that UPG is anyway a questionable abuse of the
>> >> > user/group concept.
>> >> >
>> >> > Neither to speak about the fact, that in the 17 years debian exists
>> >> > now,... no majority missed that "feature" (apparently).
>> >>
>> >> So you present that as universal facts as if you've booked the truth
>> >> (possibly a bad translation of a German saying).
>> >>
>> >> I think that feature is useful for all those who don't want to mess
>> >> with ACLs.  If you are not allowed to use ACLs and don't have UPG
>> >> with sane umasks collaboration is painful (see e.g. Debian infrastrure
>> >> with all users being in group Debian and default umask 0022 which
>> >> leads to wrong permissions in setgid directories, with ACLs being
>> >> disallowed).  So indeed I got a script which does newgrp and
>> >> setting the umask for me which I run whenever I want to do release
>> >> tasks.  But it would be more sane if the user wouldn't have to
>> >> care about that.
>> >
>> > Let me quote from the comments in /etc/login.defs:
>> >
>> > # 022 is the "historical" value in Debian for UMASK when it was used
>> > # 027, or even 077, could be considered better for privacy
>> > # There is no One True Answer here : each sysadmin must make up his/her
>> > # mind.
>> >
>> > And that's exactly the problem: there is no one-size-fits-all
>> > for the umask. Yes, for collaboration in a setgid directory you'd have
>> > to use 002 and thanks to UPG this is possible without compromising
>> > security. But I consider this just a special case. There are
>> > cases where Debian runs in a non-UPG environment, where you can't use
>> > that umask. And I don't think that's uncommon. Think of a mixed
>> > environment with Windows, where you might have a samba domain in LDAP. And
>> > last time I checked, the smbldap-tools didn't support UPG.
>>
>> Could you fill a bug report against smbldap-tools ?
>
> There is already an upstream bug [0], but even if it get's
> implemented, that wouldn't magically change all systems out there
> running non-UPG
>
>>
>>
>> > So whatever value is used as the default, half of the users will have
>> > to change it anyway, to fit their needs. And in such a case, where
>> > there is no single optimal value, I'd rather have the most
>> > conservative as default.
>> >
>> > If the umask is 022 and you create a setgid
>> > directory and forget to change the umask, you will quickly realise
>> > that things are not working as expected and fix it. If the umask is
>> > 002 and you add your Debian system to a non-UPG environment and forget
>> > to change the umask, things will still work perfectly but you put all
>> > your files at risk and might not even realise it until it is too
>> > late.
>>
>> Why not add a security dialog and assistant for installing and
>> upgrading the system?
>> It will ease the transition and fit allt the need, documenting
>> drawbacks and advantages of each scheme ?
>
> A umask of 022 is the right choice for most people and at least
> doesn't put the others at risk. Everyone, who knows what a setgid
> directory is and how it works, will also know, that there are certain
> requirements on the umask. And the others really don't care, as long
> as their security is not compromised.
>
> There is really no need to force everyone to make a useless decision,
> just for the sake of a change to make life of a specific minority easier.
>
> Cheers,
> harry
>
> [0] http://gna.org/support/?2040

Reported as #582388

Thanks


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

Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling

[Bastien ROUCARIES]

On Wed, Jul 21, 2010 at 1:42 PM, Steffen Möller  wrote:
> This should probably then move to Debian-Project?
>
> On 07/21/2010 11:31 AM, Andreas Tille wrote:
>> On Wed, Jul 21, 2010 at 05:34:27PM +0900, Charles Plessy wrote:
>>
>>
>>> I think that what we need is Debian Blends that include official backports.
>>> This, no other distribution proposes yet.
>>>
>> IMHO this is worth another thread how to make Debian more attractive for
>> users ...
>>
> The computing world have become such complex, that we are all mere users
> somewhere. So yes, we should think more about our users.
>

Support of debian is excellent but we are less user friendly than
ubuntu. For isntance the bug sytem could be made simplier for joe
simpler user, using an http interface than reportbug-ng (what should
be installed by default for your desktop user) or even mail. I think
having a simple bug report form and wizard  will really help your
user.

Increasing your quality also, will improve your user base.

Last but not least improving the unbuntu to debian package transfert
and therefore the project http://wiki.debian.org/Utnubu
(i plan to package google gears BTW)

Thank you


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

Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling

[Bastien ROUCARIES]

On Thu, Jul 22, 2010 at 11:35 AM, Josselin Mouette  wrote:
> Le jeudi 22 juillet 2010 à 11:08 +0200, Bastien ROUCARIES a écrit :
>> Support of debian is excellent but we are less user friendly than
>> ubuntu. For isntance the bug sytem could be made simplier for joe
>> simpler user, using an http interface than reportbug-ng (what should
>> be installed by default for your desktop user) or even mail. I think
>> having a simple bug report form and wizard  will really help your
>> user.
>
> We already have too many bug reports. What good would it do to have
> more?

The problem is joe simple user find one package that does not work,
it seatrch on the web how to report bug, does not find, does not
report it, and switch to unbuntu. BTW I check unbuntu bug number and
even if the quality is lower they are often really helpful.
Particularly, the core dump automatic generated bug report, with
backtrace automacally created from debug repositionnery that really
help maintener even is joe simple user is clueless (and for medium
level user it improve the bug reporting and allow to trace hard to
reproduce bug)

Bastien


--
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/aanlktik1esoxaauzpk-etsyadnyymkyycdqxl0j2y...@mail.gmail.com

Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling

[Bastien ROUCARIES]

On Thu, Jul 22, 2010 at 2:26 PM, Russ Allbery  wrote:
> Bastien ROUCARIES  writes:
>
>> Support of debian is excellent but we are less user friendly than
>> ubuntu. For isntance the bug sytem could be made simplier for joe
>> simpler user, using an http interface than reportbug-ng (what should be
>> installed by default for your desktop user) or even mail. I think having
>> a simple bug report form and wizard will really help your user.
>
> Having followed the Ubuntu bugs for many of my packages for several years
> now, I think Debian's bug system is considerably more user-friendly than
> Launchpad.  It may not be as *pretty*, and it's not as easy to submit a
> bug, but when you submit a bug to Debian, the chances are fairly good that
> someone will look at it and reply with a detailed understanding of both
> your bug and the package (at least unless you're reporting a bug to one of
> the packages that notoriously gets more bugs than anyone could ever deal
> with, usually about other software, like the kernel or the desktop
> metapackages).  Debian's BTS is more friendly in that old-fashioned sense
> that involves interacting with people.  :)

Yes for expert not for joe simple user. I do not argue to change your
bug report system by mail that is wonderfull but add an http klayer
will be really nice (think also to entreprise user behind proxy with
only webmail available)


> In Launchpad, for anything in universe, the typical experience is that
> your bug goes into a black hole until a month or two later someone sends
> you some form letter about it.

Not for my package imagemagick autogerated coredump with backtrace are
really really help full and allow to see for instance that bugs in not
in my package but in libtiff or in srvg
>
>> Increasing your quality also, will improve your user base.
>
> I don't think doing what Launchpad does would improve Debian's quality.  I
> suspect it would actually make it worse by hiding issues under piles of
> semi-autogenerated bug reports with no information and consuming developer
> time with triage that isn't improving packages.

Mark bug report gerated by web user using a special tag and allow only
maintener like me that optin to get automated bug report. In my case
it will increase the quality.

Bastien


--
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/aanlktikbljayj0eu2sobtcyc-mb8hhj1lrfdufqtb...@mail.gmail.com

Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling

[Bastien ROUCARIES]

On Thu, Jul 22, 2010 at 2:39 PM, Russell Coker  wrote:
> On Thu, 22 Jul 2010, Russ Allbery  wrote:
>> In Launchpad, for anything in universe, the typical experience is that
>> your bug goes into a black hole until a month or two later someone sends
>> you some form letter about it.
>
> That's why I stopped reporting bugs against Fedora years ago, they kept being
> automatically closed a couple of releases later.  I would report a bug in RHEL
> and have it not deemed suitable for an update to the current release (which
> was fair), I would report it against Fedora and then it would be closed
> automatically.
>
> The Red Hat bug tracking system is less efficient for me than the Debian one.
> The ratio of bug reports that they receive to the number of bugs that they can
> fix is obviously worse than that of Debian.  So the end result is that people
> like me are deterred from filing bug reports and people with less ability to
> correctly diagnose problems find it easier.

> It seems to me that the Debian bug tracking system is better than that of Red
> Hat.  I don't recall anything about the Ubuntu bug tracker so I can't comment
> on that.
>
> In recent times I haven't bothered trying to report bugs against other
> distributions.  When I find a bug in some other distribution I develop a work-
> around for it there and then try to reproduce it in Debian.  If I can
> reproduce it in Debian then I file a Debian bug report.
>
> --
I agree it will be nice also like forwarded to cross reference bug in
other distro bugzilla and automatically detect whan other distro have
cooked a patch instead to found it manually.

Bastien


--
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/aanlktimvse0ajli1cn7awjslsz2wymq-gdzrui2h-...@mail.gmail.com

Re: teaching users how to submit good bug reports

[Bastien ROUCARIES]

On Thu, Jul 22, 2010 at 4:28 PM, Ian Jackson
 wrote:
> Stefano Zacchiroli writes ("teaching users how to submit good bug reports"):
>>    So, point 2: are we *advertising* reportbug enough to our users?
>>    In particular, I'm thinking about advertising in "push mode" rather
>>    then in "pull mode".
>
> This approach, trying to make it easier to report bugs, supposes that
> most (or even a substantial fraction) of the bugs in deployed Debian
> systems, as experienced by users, are there because no-one has yet
> reported that bug.
>
> I don't think that's true at all.  Looking at the bugs which are
> outstanding in Debian in general, and my own experience, it seems to
> me that the main reason for the presence of most bugs is lack of
> available effort for fixing them.  The obvious conclusion is that if
> we increase the number of bugs submitted we will divert effort from
> bug fixing to triage.
>
> I think that people who want Debian to deal better with bug reports
> from a wider audience should work on improving the available triage
> effort (both in quantity and quality!), and the available fixing
> effort.
>
> When popular and high-profile end-user-oriented packages have low
> numbers of outstanding bugs, it will be time to think about how we can
> get more reports so that we can further improve the quality.
>
Automated backtrace ala unbuntu will really ease the debian maintener job.

bastien


--
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/aanlktinkwxvwq6qk3wt-xsb_l1qjoriztenhopw2s...@mail.gmail.com

Re: teaching users how to submit good bug reports

[Bastien ROUCARIES]

On Thu, Jul 22, 2010 at 5:35 PM, Andreas Tille  wrote:
> On Thu, Jul 22, 2010 at 04:05:17PM +0200, Stefano Zacchiroli wrote:
>>    So, point 2: are we *advertising* reportbug enough to our users?
>>    In particular, I'm thinking about advertising in "push mode" rather
>>    then in "pull mode".
>
> No, we obviosely do not.  When staffing bothes in the past I regularly
> asked people to report their problem and they had no idea how to do
> (because they did not know reportbug) even if long term Debian users.  I
> think I suggested in the past (shame on my provided no patch) to
> advertise reportbug in the installation process somehow.
>
> Kind regards

Why not a tool a la kerneloops for debian ? If a process coredump,
save the dump (core pipe is in the kernel) popup something in the
taskbar and ask user if to run reportbug ng ?

Bastien

>


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

Re: teaching users how to submit good bug reports

[Bastien ROUCARIES]

On Thu, Jul 22, 2010 at 6:11 PM, Norbert Preining  wrote:
> On Do, 22 Jul 2010, Bjørn Mork wrote:
>> If you are still unable to find and use reportbug, then I doubt that you
>> are able to identify a bug and much less provide the information
>> required to actually fix it.
>
> Agreed upon that. Typical example are Ubuntu bugs. I am subscribed to
> the bug reports of my packages in Ubuntu, and it is a long time that
> I stopped reading these completely useless "It does not work" bug
> reports ... sad as it is.

Yes ia gree for some kind of bug, but for coredump and signal abort
bug, unbuntu is really really useful.

Bastien


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

Re: teaching users how to submit good bug reports

[Bastien ROUCARIES]

On Fri, Jul 23, 2010 at 1:55 AM, Don Armstrong  wrote:
> On Fri, 23 Jul 2010, Brian May wrote:
>> On 23 July 2010 00:05, Stefano Zacchiroli  wrote:
>> > 1) I've been teaching him how to use reportbug [...]
>>
>> Recently I have found reportbug and other bts tools rather annoying
>> because of their requirement to to get a working email setup[1] on
>> the computer first.
>
> All reportbug requires is that you can connect to bugs.debian.org:587.
> You don't need anything else to be working at all.
>

Unfortunatly a lot of entreprise does not allow anything else port 80! I

Bastien


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

RE : Re: teaching users how to submit good bug reports

[Bastien ROUCARIES]

Using libproxy could help here.

(Sorry for top post android)

Bastien

Le 25 juil. 2010 14:11, "Don Armstrong"  a écrit :

On Sun, 25 Jul 2010, Marc Haber wrote:

> From where does reportbug obtain that information? How does it cope
> with corporate installations...
Let's not make perfect the enemy of the good; there are all kinds of
setups where you can make arbitrary communication with the outside
world very difficult. reportbug can handle more and more of them, but
it's impossible for it to handle them all.


Don Armstrong

--
The state must declare the child to be the most precious treasure of
the people. As long as the government is perceived as working for the
benefit of the children, the people will happily endure almost any
curtailment of liberty and almost any deprivation.
 -- Adolf Hitler _Mein Kampf_ p403


http://www.donarmstrong.com http://rzlab.ucr.edu


-- 

To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trou...
Archive:
http://lists.debian.org/20100725121037.gn29...@teltox.donarmstrong.com

Re: why are there /bin and /usr/bin...

[Bastien ROUCARIES]

> A better test might be to do this without /usr mounted.
>
> MfG
>        Goswin

Could we do automated testing using:
- creating a new mount namespace
- a bind mount of /usr on a empty directory ?

A second option will be to modify fakeroot in order to avoid the
/usr/binding and run some test like --version

Thanks

Bastien


--
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/aanlktinsxcw6vwo8zw72ys1rfdlgr+xmazxf-w1tu...@mail.gmail.com

QEMU HPPA image

[Bastien ROUCARIES]

Hi,

In order to chase a bug (#592712) on hppa, i try to run qemu on hppa.

I begin to try to download a qemu image on
http://people.debian.org/~aurel32/qemu but i could not found a qemu
image.

Do you know where to download such an image ? I will be handy to add
to usual place.

I will try tomorrow to build one if not found before.

Bastien


-- 
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/aanlktim354+z7atjdbnfj8zzsyp-avlmcw3kcoi0h...@mail.gmail.com

Re: QEMU HPPA image

[Bastien ROUCARIES]

On Fri, Aug 13, 2010 at 9:28 AM, Aurelien Jarno  wrote:
> On Fri, Aug 13, 2010 at 10:55:45AM +0800, Paul Wise wrote:
>> On Fri, Aug 13, 2010 at 1:06 AM, Aurelien Jarno  wrote:
>>
>> > QEMU doesn't emulate HPPA, that's why you can't find such an image.
>>
>> Looks like there is/was work in progress to do so though:
>>
>> http://hppaqemu.sourceforge.net/
>> http://sourceforge.net/projects/hppaqemu/
>> http://repo.or.cz/w/qemu/hppa.git
>>
>> Seems like it needs folk to clean it up and get it merged though.
>
> and finished.
Do not having a means to run hppa on developper machine is a serious
limitation of this port.

Bastien


-- 
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/aanlktin+vumdx_iy61b14osy-uxteajg3hdxx9-xw...@mail.gmail.com

Re: libexplain: need access to debian alpha machine

[Bastien ROUCARIES]

On Tue, Aug 17, 2010 at 5:46 AM, Paul Wise  wrote:
> On Mon, Aug 16, 2010 at 6:05 PM, Peter Miller  
> wrote:
>
>> I'm trying to get my libexplain project [1] to build on Debian alpha.
>> I don't actually have access to an alpha machine, so my feedback loop is
>> via the Debian build farm [2]... one fix per release.
>>
>> This isn't completely satisfactory.  Can anyone suggest a dev machine I
>> can ssh to, and do the edit-build-test loop more efficiently?
>
> There is one alpha porterbox available:
>
> http://db.debian.org/machines.cgi?host=albeniz
>
> It is listed as public rather than developer only so as a non-DD you
> would probably be able to get access. Please contact the Debian
> sysadmins about it.

BTW for new debian port could we ask to have a qemu port functionnal ?
HPPA and alpha are not emulated and it is a real pain to debug this
kind of stuff, particularly if you are often offline like me.

Bastien


--
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/aanlkti=m9ag01c5eyb_zga4+eyr81boxsq1o1e2wi...@mail.gmail.com

Re: Atlas proposal

[Bastien ROUCARIES]

> I agree on this.  What we still don't agree on is whether you can build
> an optimized package at all, since Atlas will optimize it for the
> machine where it got built, and the optimizations it does will
> potentially make performance worse on another machine...
>
> Samuel
>

How does atlas cope with cgroup and cpuset ? In some hpc environnement
some user have a restricted number of node, wheras other have the full
machine. And this kind of stuff is getting more and more common. So
the hand compilation of atlas is not a solution. Atlas should use run
time switching optimisation.

Bastien


--
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/aanlktim7a0w1fweucua2akyhgcazm5owu=zrfsqey...@mail.gmail.com

Re: conflicting with a package that has a binary with the same name ?

[Bastien ROUCARIES]

On Sat, Aug 21, 2010 at 3:10 PM, Jérémy Lal  wrote:
> On 21/08/2010 15:00, Julien Cristau wrote:
>> On Sat, Aug 21, 2010 at 14:23:19 +0200, Jérémy Lal wrote:
>>
>>> But nodejs is getting more popular, and renaming its binary to nodejs
>>> will probably upset many users. Is it legitimate to keep /usr/bin/node,
>>> and Conflict: node ?
>>>
>> No, it's not.  Best would be to convince your upstream to use a less
>> generic name.
>
> I've tried once, without success, and now that's too late,
> given the number of people and modules already using nodejs on other 
> platforms.
>
> BTW is /usr/bin/node and /usr/sbin/node really considered a conflict ?
> i certainly see it as troublesome.

You could use the alternative system.

ANd ask also upstream to x25 to change their binaries to x25node

Bastien

> Jérémy.
>
>
> --
> 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/4c6fd049.9020...@melix.org
>
>


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

Re: ITP: yade -- Platform for discrete element modeling.

[Bastien ROUCARIES]

On Sun, Jan 2, 2011 at 2:58 PM, Anton Gladky  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Anton Gladky 
>
>
> * Package name    : yade
>  Version         : 0.60
>  Upstream Author : Yade developers 
> * URL             : https://launchpad.net/yade
> * License         : GPL
>  Programming Lang: C++
>  Description     : Platform for discrete element modeling.
>
> Yet Another Dynamic Engine.
>
> Extensible open-source framework for discrete numerical models,
> focused on Discrete Element Method.
> The computation parts are written in c++ using flexible object model,
> allowing independent implementation of new algorithms and interfaces.
> Python is used for rapid and concise scene construction,
> simulation control, postprocessing and debugging.

Could you describe discrete element ?

Thanks

bastien


--
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/aanlktimzskauvg-p7tp+yyvzwfypokmhhpoctbr_o...@mail.gmail.com

Re: Safe File Update (atomic)

[Bastien ROUCARIES]

On Thu, Jan 6, 2011 at 12:39 PM, Olaf van der Spek  wrote:
> On Thu, Jan 6, 2011 at 5:01 AM, Ted Ts'o  wrote:
>> On Thu, Jan 06, 2011 at 12:57:07AM +, Ian Jackson wrote:
>>> Ted Ts'o writes ("Re: Safe File Update (atomic)"):
>>> > Then I invite you to implement it, and start discovering all of the
>>> > corner cases for yourself.  :-)  As I predicted, you're not going to
>>> > believe me when I tell you it's too hard.
>>>
>>> How about you reimplement all of Unix userland, first, so that it
>>> doesn't have what you apparently think is a bug!
>>
>> I think you are forgetting the open source way, which is you scratch
>> your own itch.
>
> Most of the time one is writing software because it's useful for
> oneselves and others. Not because writing software itself is so much
> fun. It's about the result.
> So focus should be on what those users need/want.
>
>> The the main programs I use where I'd care about this (e.g., emacs)
>> got this right two decades ago; I even remember being around during
>> the MIT Project Athena days, almost 25 years ago, when we needed to
>> add error checking to the fsync() call because Transarc's AFS didn't
>> actually try to send the file you were saving to the file server until
>> the fsync() or the close() call, and so if you got an over-quota
>> error, it was reflected back at fsync() time, and not at the write()
>> system call which was what emacs had been expecting and checking.
>> (All of which is POSIX compliant, so the bug was clearly with emacs;
>> it was fixed, and we moved on.)

Could you point to the code snippet ? I could be worth to add to
gnulib for instance

Another point is to create some fuse filesytem for testing error
condition on filesystem. For instance a filesystem that create EIO
error randomly or EFULL, it will improve the quality of our software.
I have written such a filesystem, I will surelly post it in a few day
(hopefully)

Bastien


--
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/aanlktin5v_cuuetf3j1p1_mtkv3oq2+sk9vstn453...@mail.gmail.com

Qt3 removal rational

[Bastien ROUCARIES]

I comaintain upstream qucs a simulator of electronics circuit and the
only free one able to simulate radio frequency circuit.

In the scientific field a lot of software depend of qt3. And a lot of
uptream lack ressource to port to qt4. At my workplace (university) we
are using a lot this kind of software for in house use.

We are not ready to scitch to qt4, and I am willing to ask more
explanation about removal of qt lib.

I have also seen that it exist some projet to package trinity for
debian, that could offer an alternative and some delay.
What is the status of inclusion under debian?

Bastien


-- 
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/aanlktinaogrdzn7wo293nx_npk6suve1ftx-q7gc9...@mail.gmail.com

Need jquery.fancybox

[Bastien ROUCARIES]

tags 611125 + help
thanks

Hi,

As a developper of imagemagick, i am correcting bug #611125, and i need to 
package jquery.fancybox 

However I have no experience in javascript and I need some help.

Please package  jquery.fancybox 

Thanks

Bastien


-- 
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/201102141502.16230.roucaries.bastien+imagemag...@gmail.com

Bug#613525: ITP: [PACKAGE] -- metakit

[Bastien ROUCARIES]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Package name: metakit
Version:  2.4.9.7 
Upstream Author:  Jean-Claude Wippler  j...@equi4.com
URL: http://equi4.com/metakit/index.html
License: MIT
Description: Metakit is an efficient embedded database library with a small 
footprint. It fills the gap between flat-file, relational, 
object-oriented, and tree-structured databases, supporting relational joins, 
serialization, nested structures, and instant schema 
evolution. There is a C++ API, a Python binding called Mk4py, and a Tcl binding 
called Mk4tcl. You can manipulate and exchange 
data between any of these.

Data files are portable. The library has been used on Unix, Windows, Macintosh, 
VMS, and others, spanning a range of 16- to 64-bit 
architectures, from PDA's to S390's.

Metakit is in use in various commercial projects and products on millions of 
desktops.

I need a sponsor and plan to release it in order to fix some boring akregator 
bugs. Plan to use existing ubuntu package




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

Adopt a removed package: how to ?

[Bastien ROUCARIES]

Hi,

I plan to adopt a removed from archive package (see #183373). 

How can I do ?

I have marked myself as ITA of 183373. It is the right way ?

I plan to download previous debian package, the new source and to do some 
adaptation.

Should I use the process of a new package or an adopted package ?

bastien


-- 
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/201102151457.08908.roucaries.bast...@gmail.com

Disable ZeroConf: how to ?

[Bastien ROUCARIES]

hi,

More and more packages depend on avahi aka zeroconf. I have found some 
information on http://wiki.debian.org/ZeroConf 

Because I work in a untrusted work place and home network (public networks, 
wifi...) I whish to purge zeroconf functionnality.

however a lot of package depends (or recommend) instead of suggest avahi-daemon 
and thus I could not purge this piece of software 
that I believe insecure in my context.

Does avahi could be disable (using kernel level firewalling is not from my 
point of view a solution) ?

And more specifically from an administrator point of view does avahi could 
library could be made purgeable and no more than suggest 
dependencies (I am willing to fill a mass bug report because purging avahi will 
purge gnome and kde ...) ?

And moreover could you give a clear answer about the security risk on untrusted 
network ? 

Thanks

Bastien


-- 
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/201103021825.32204.roucaries.bast...@gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Wed, Mar 2, 2011 at 11:51 PM, Ben Hutchings  wrote:
> On Wed, 2011-03-02 at 23:09 +0100, Julien BLACHE wrote:
>> Bastien ROUCARIES  wrote:
>>
>> Hi,
>>
>> > Because I work in a untrusted work place and home network (public
>> > networks, wifi...) I whish to purge zeroconf functionnality.
>>
>> Looks like you want a firewall. Just sayin'.
>
> A firewall is mitigation against insecure applications and
> configurations.  The availability of firewalls does not excuse us from
> making applications and their default configurations secure.

I perfectly agree...

Bastien

> Ben.
>
> --
> Ben Hutchings
> Once a job is fouled up, anything done to improve it makes it worse.
>


--
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/AANLkTi=cr_5gigbqxkoynpwkvumdfaciyp7_s5yse...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Wed, Mar 2, 2011 at 11:54 PM, Klaus Ethgen  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Mi den  2. Mär 2011 um 18:25 schrieb Bastien ROUCARIES:
>> More and more packages depend on avahi aka zeroconf. I have found some 
>> information on http://wiki.debian.org/ZeroConf
>>
>> Because I work in a untrusted work place and home network (public networks, 
>> wifi...) I whish to purge zeroconf functionnality.
>
> I fighted this bunch of functionality since long ago. The whole zerconf
> stuff is only useful in secure and clear defined environments. But there
> you don't need it anyway.
>
> With zeroconf there is some thinks that play together and has to be
> killed:
> - - avahi (-daemon) -- as you find by yourself -- and the packages
>  zeroconf, libnss-mdns, avahi-autoipd, avahi-daemon.
> - - The package slpd
> - - The linklocal route (169.254.0.0)

Ok so this package should be marked as suggest only ? Will fill bug,
if needed as a whislist level.

>> Does avahi could be disable (using kernel level firewalling is not from my 
>> point of view a solution) ?
>
> See above.
>
>> And more specifically from an administrator point of view does avahi could 
>> library could be made purgeable and no more than suggest
>> dependencies (I am willing to fill a mass bug report because purging avahi 
>> will purge gnome and kde ...) ?
>
> Well, as I do not use gnome nor kde I am not concerned from this
> dependencies.
>
>> And moreover could you give a clear answer about the security risk on 
>> untrusted network ?
>
> That is difficult. It depends on the environment. If you have a clear
> and secure environment, zeroconf is not that insecure. But in all other
> environments you do not want to have it.

Ok so a telnet equivalent from a security point of view...

Regards

Bastien

> Regards
>   Klaus


--
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/AANLkTimVgZuWM-btAmjJeT1+goPrqtUR2PY2yBG=4...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Wed, Mar 2, 2011 at 10:24 PM, Josselin Mouette  wrote:
> Le mercredi 02 mars 2011 à 18:25 +0100, Bastien ROUCARIES a écrit :
>> And more specifically from an administrator point of view does avahi
>> could library could be made purgeable and no more than suggest
>> dependencies (I am willing to fill a mass bug report because purging
>> avahi will purge gnome and kde ...) ?
>
> As Philipp pointed out, only gnome depends on it, and that’s not
> gnome-desktop-environment. You can use the latter if you want only the
> official GNOME desktop.


Not true anymore see below:
gnome-desktop-environment
 Depends: gnome-user-share
   Depends: libapache2-mod-dnssd
 Depends: avahi-daemon
 Recommends: telepathy-salut
   Depends: avahi-daemon

>> And moreover could you give a clear answer about the security risk on
>> untrusted network ?
>
> I’d say Avahi is mostly as insecure as the services that use it for
> advertising.

Yes I have just read the draft RFC and it document some pitfall in
insecure network:
http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-08
In an environment where the participants are mutually antagonistic
   and unwilling to cooperate, other mechanisms are appropriate, like
   manually administered DNS.

   In an environment where there is a group of cooperating participants,
   but there may be other antagonistic participants on the same physical
   link, the cooperating participants need to use IPSEC signatures
   and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS
   messages from trusted participants (which they process as usual) from
   mDNS messages from untrusted participants (which they silently
   discard).

   When DNS queries for *global* DNS names are sent to the mDNS
   multicast address (during network outages which disrupt communication
   with the greater Internet) it is *especially* important to use
   DNSSEC, because the user may have the impression that he or she is
   communicating with some authentic host, when in fact he or she is
   really communicating with some local host that is merely masquerading
   as that name. This is less critical for names ending with ".local.",
   because the user should be aware that those names have only local
   significance and no global authority is implied.

   Most computer users neglect to type the trailing dot at the end of a
   fully qualified domain name, making it a relative domain name (e.g.
   "www.example.com"). In the event of network outage, attempts to
   positively resolve the name as entered will fail, resulting in
   application of the search list, including ".local.", if present.
   A malicious host could masquerade as "www.example.com." by answering
   the resulting Multicast DNS query for "www.example.com.local."
   To avoid this, a host MUST NOT append the search suffix
   ".local.", if present, to any relative (partially qualified)
   host name containing two or more labels. Appending ".local." to
   single-label relative host names is acceptable, since the user
   should have no expectation that a single-label host name will
   resolve as-is.


--
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/aanlktinaxgo2-sd9fsnqhpnoi2e4lod+ebrtg+ro_...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 11:02 AM, Klaus Ethgen  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> Am Do den  3. Mär 2011 um  3:35 schrieb Chow Loong Jin:
>> > A system has not to listen for any unused and unneeded services ever. A
>> > firewall is to control services you _need_.
>> >
>> > All that zeroconf stuff is absolutely not needed and wanted. (By the
>> > most users, I suppose.)
> [...]
>> Actually I absolutely love the .local resolution functionality on a
>> network (it works much better than the NetBIOS crap that can never find 
>> another
>> machine on a network when you want it). That, and Pidgin's Bonjour support
>> interfaces with iChat over zeroconf, allowing you to chat with users (and
>> exchange files, perhaps?) across a network without needing to set up a
>> centralized chatting system.
>
> The thoughts of that makes me shiver! Trusting untreatable sources on a
> network for configuring local stuff is worse ever. Either you have a
> trustable network then it gets configured in a clean way and by intend.
> Or you have a untrusted network you do not want to use ever or only such
> fare that you can oversee it.

I agree and moreover because Chow Loong Jin use .local instead of
.local. it could be resolved to whatever the hell to universe...

>> I think those two functionalities are pretty useful to the end-user.
>
> Well, they might be for a mac or windows user that is not care about
> security at all. But it is horror for a debian user who care at least a
> bit about security.
>
> And even if you not care about, then that functionality should be
> explicit configured and not per default.
>
> And even worse, debian is often used on server platforms where you never
> ever want to have any such magically configured services.

I agree, this sould be disable by default or at least asked to run at
config time with a no default, and only be authorized to resolve if
you use a fqdn and not a relative domain name...
And with mdns...

>> Rather than blabbering about potential security issues stemming from
>> avahi-daemon being installed and enabled on a system, how about actually 
>> finding
>> one and reporting it?
>
> Oh, they are not potential. Trusting on untrusted stuff for doing any on
> your machine raises the vector for intrusion to hell.
>
> Ah, and to give a example of the past. No one ever did think about that
> mssql is vulnerable due to a comfort feature until in 2001/2002 the
> mssql-slammer (or how the worm was called) took down mayor parts of the
> net. Zeroconf and avahi plays in the same category.
>
>> gnome-user-share does not share stuff by default as far as I can tell, and
>> padevchooser only uses avahi-daemon for discovering extra Pulseaudio sinks on
>> the network (it doesn't advertise its own sinks by default).
>
> Uh, you mean, that anybody can listen to your music or your teamspeak
> session or your voip session with your girlfriend due zeroconf found a
> audio sink in the network and did reconfigure your system to use it?
>
>> An avahi-enabled system that advertises no services is pretty much as secure 
>> as
>> the avahi-disabled system.
>
> That is not true. For two reasons:
> 1. It is one more daemon that is not needed and can have bugs. (And even
>   more it lowers the sensibility about unusual processes on your
>   system)
> 2. It even configure parts of your system from untrusted information
>   from the network.

I agree, and it is only the daemon part the depend on client part is
even more scarry...

We trust a lot untrusted source...


> --
> 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/20110303100247.ga20...@ikki.ethgen.ch
>
>


--
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/AANLkTi=FVSy4PW0=t1duvgbh5fhu71kzbnfmcro64...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 11:25 AM, Tollef Fog Heen  wrote:
> ]] Klaus Ethgen
>
> Hi,
>
> | The thoughts of that makes me shiver! Trusting untreatable sources on a
> | network for configuring local stuff is worse ever.
>
> Then just don't use it?  Nobody is forcing you to.
>
> | > I think those two functionalities are pretty useful to the end-user.
> |
> | Well, they might be for a mac or windows user that is not care about
> | security at all. But it is horror for a debian user who care at least a
> | bit about security.
> |
> | And even if you not care about, then that functionality should be
> | explicit configured and not per default.
>
> That makes it much less useful.  On the other hand, it's not like your
> system will suddenly go around connecting to random services just
> because it sees them announced.
>
> | And even worse, debian is often used on server platforms where you never
> | ever want to have any such magically configured services.
>
> Oh, I quite like services to announce themselves so I can just do ssh
> foo.local.

The balance about using FQDN like you do and not foo.local that will
resolve to hell

> Not everything gets set up in DNS and ssh caches the host
> key so doing a mitm attack after the initial handshake is prevented.
> It's not like it'll magically be pulled in on servers or anybody is
> suggesting making it part of the base system.

It is pulled when I use gnome on my server...

> | Ah, and to give a example of the past. No one ever did think about that
> | mssql is vulnerable due to a comfort feature until in 2001/2002 the
> | mssql-slammer (or how the worm was called) took down mayor parts of the
> | net. Zeroconf and avahi plays in the same category.
>
> Except zeroconf isn't routed so to be able to exploit it you need to be
> on the same physical segment?
>
> | > gnome-user-share does not share stuff by default as far as I can tell, and
> | > padevchooser only uses avahi-daemon for discovering extra Pulseaudio 
> sinks on
> | > the network (it doesn't advertise its own sinks by default).
> |
> | Uh, you mean, that anybody can listen to your music or your teamspeak
> | session or your voip session with your girlfriend due zeroconf found a
> | audio sink in the network and did reconfigure your system to use it?
>
> That they are discovered does not mean they are used, just that they are
> available.  If you have found any bugs where network sinks are used
> automatically please file bugs about that.
>
> Really, if you want to disable avahi, please feel free to do so on your
> systems.  Or use a firewall, or both.  Debian has a fair balance of
> functionality, security and convenience out of the box, if you disagree
> with the current balance, feel free to invest the work into making it
> possible to harden Debian further.

But how to disable was not documented and that is the problem...
Moreover current configuration that allow to use local link that are
not FQDN is a little bit insecure

Bastien

> Regards,
> --
> Tollef Fog Heen
> UNIX is user friendly, it's just picky about who its friends are
>
>
> --
> 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/87sjv4jybg@qurzaw.varnish-software.com
>
>


--
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/AANLkTinfcvL7j6s-KLNMHABRcQS4kO0=pQNE=ujoo...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 12:22 PM, Lars Wirzenius  wrote:
> On to, 2011-03-03 at 11:54 +0100, Klaus Ethgen wrote:
>> Am Do den  3. Mär 2011 um 11:25 schrieb Tollef Fog Heen:
>> > Then just don't use it?  Nobody is forcing you to.
>> [...]
>> > | And even if you not care about, then that functionality should be
>> > | explicit configured and not per default.
>> >
>> > That makes it much less useful.  On the other hand, it's not like your
>> > system will suddenly go around connecting to random services just
>> > because it sees them announced.
>>
>> So you contradict yourself within two paragraphs. It makes it less
>> useful to enable it only on manual intervention (say, it should be
>> enabled automatic) but on the other hand you say that nobody is forcing
>> me (or others) to use it. How do that plays together?
>
> I don't see a contradiction between "nobody is forced to use zeroconf"
> and "zeroconf is less useful if it has to be enabled manually". The fact
> that zeroconf is enabled by default on the GNOME desktop does not make
> it mandatory for everyone to use. (Yes, it would be nice if there were
> an easy way to disable it.)
>
> However, could we please end the FUDfest? This thread seems to be quite
> unconstructive, with unspecific claims of security problems, unwarranted
> slurs on users based on their operating system, and accusations on
> Debian developer's attitudes. If there is an actual problem, explain
> what it is, and suggest a solution.

main security problem is resolver,
$host -v www.local
www.local
www.local.mydomain.com

see security issue in draft paper also in case
http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-08

more important:
phpmyadmin package have created a link in /etc/avahi/services without
any question. Everybody know in my network that I have a phpadmin
service running on my server. I will ASAP create a bug report with a
security tag.

Bastien


--
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/aanlktikezvy0etuvdfw0mpubagwga5dhjxvm-q2_v...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 12:33 PM, Sujit Karatparambil
 wrote:
>> However, could we please end the FUDfest? This thread seems to be quite
>> unconstructive, with unspecific claims of security problems, unwarranted
>> slurs on users based on their operating system, and accusations on
>> Debian developer's attitudes. If there is an actual problem, explain
>
> I totally agree, it is certainly not wise to accuse/allege/propgate fud.
> I also think it is much better to look for articles on the internet that
> might help you better understand. As with opensource it is very difficult
> to maintain a document for a long period of time. But certainly usefull
> as pointer to usefull information into the manpages. Though I am not an
> expert of ZeroConf but found a usefull article into zeroconf. I am much more
> an Avahi fan than an ZeroConf fan.
>
> http://www.practicallynetworked.com/sharing/configure_and_use_avahi_and_linux.htm

some package announce their existance to the world without any admin decision!
It is not a fud  and a security hole!
>phpmyadmin package have created a link in /etc/avahi/services without
>any question. Everybody know in my network that I have a phpadmin
>service running on my server. I will ASAP create a bug report with a
> security tag.
>


-- 
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/AANLkTinkQ=q8wx45zbodt7wquwx2oqjx_y5w-x-aj...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 1:31 PM, Olaf van der Spek  wrote:
> On Thu, Mar 3, 2011 at 1:16 PM, Lars Wirzenius  wrote:
>> On to, 2011-03-03 at 12:47 +0100, Bastien ROUCARIES wrote:
>>> some package announce their existance to the world without any admin 
>>> decision!
>>> It is not a fud  and a security hole!
>>
>> That's a vague generality... which packages? You mentioned phpmyadmin.
>> What are the actual problems that results from this announcement? What
>> bad things happen from it? Can the fact that you have phpmyadmin become
>> known to an attacker via port scanning, or similar techniques? If so,
>> does it matter if phpmyadmin also announces things via avahi? What do
>> you suggest as a solution? Would a blanket policy of having all services
>> to default to not announce themselves? What would the problems from such
>> a policy be?
>>
>> (I don't know much about this stuff, and I don't particularly care, but
>> it'd be nice if we could turn the discussion into a constructive one.)
>
> Windows has the concept of home / private and public networks. On
> public networks, sharing gets disabled.
> Such a concept would be good for this situation as well. Let the user
> indicate what type of network he is on and what type of services
> should be opened to that network.

The last bug is not about this, it is I have a phpmyadmin running as
www user and I announce I run it.

Not really good to give the path to phpmyadmin (that is running by
admin decission)

Bastien

> Olaf
>
>
> --
> 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/aanlktintbslqb6ertkoab3ulxsx+wwjjemxk-lxe9...@mail.gmail.com
>
>


--
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/AANLkTimNDs4CcgJvYxqr_jMcDHAKrpF7DxY=cm3nl...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 2:35 PM, Mike Hommey  wrote:
> On Thu, Mar 03, 2011 at 01:43:19PM +0100, Bastien ROUCARIES wrote:
>> On Thu, Mar 3, 2011 at 1:31 PM, Olaf van der Spek  
>> wrote:
>> > On Thu, Mar 3, 2011 at 1:16 PM, Lars Wirzenius  wrote:
>> >> On to, 2011-03-03 at 12:47 +0100, Bastien ROUCARIES wrote:
>> >>> some package announce their existance to the world without any admin 
>> >>> decision!
>> >>> It is not a fud  and a security hole!
>> >>
>> >> That's a vague generality... which packages? You mentioned phpmyadmin.
>> >> What are the actual problems that results from this announcement? What
>> >> bad things happen from it? Can the fact that you have phpmyadmin become
>> >> known to an attacker via port scanning, or similar techniques? If so,
>> >> does it matter if phpmyadmin also announces things via avahi? What do
>> >> you suggest as a solution? Would a blanket policy of having all services
>> >> to default to not announce themselves? What would the problems from such
>> >> a policy be?
>> >>
>> >> (I don't know much about this stuff, and I don't particularly care, but
>> >> it'd be nice if we could turn the discussion into a constructive one.)
>> >
>> > Windows has the concept of home / private and public networks. On
>> > public networks, sharing gets disabled.
>> > Such a concept would be good for this situation as well. Let the user
>> > indicate what type of network he is on and what type of services
>> > should be opened to that network.
>>
>> The last bug is not about this, it is I have a phpmyadmin running as
>> www user and I announce I run it.
>>
>> Not really good to give the path to phpmyadmin (that is running by
>> admin decission)
>
> Zeroconf announce doesn't make it less secure, it makes it slightly more
> discoverable, but not significantly so.

I disagree, on the second part, I allow faster discovery of attack
target, and made script kiddies less detectable...

> Conversely, believing that not announcing through zeroconf is more
> secure is probably good for your self confidence but doesn't change
> anything about actual security of your system.

It will ease the work of script kiddy.

> Script kiddies will actually scan a network, find web servers, and
> test a bunch of urls, in which the default phpmyadmin path most
> probably appears.
>
> And if your phpmyadmin is exploited, it won't be because of zeroconf,
> it will be because of your weak password, of a security issue in
> phpmyadmin, or something else.

For sure but I really dislike to help script kiddies, we do not return
full version of some software for this reason and do not announce
software available and location of administrative stuff slow down
exploit

Bastien


--
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/aanlktimanzrpnegioqeccjtdo4qsxswpywk-s1897...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 3:33 PM, Stig Sandbeck Mathisen  wrote:
> Bastien ROUCARIES  writes:
>
>> some package announce their existance to the world without any admin
>> decision
>
> It should be a site policy.

And set to no by default or a least well documented

>> It is not a fud and a security hole!
>
> I disagree.

Giving information on my system without admin concent is an
information leak, and thus tag security...

Bastien

>
> --
> Stig Sandbeck Mathisen 
>
>
> --
> 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/7xmxlcs288@fsck.linpro.no
>
>


-- 
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/aanlktikxwcprjgx3i33hsvmbj+m9c5p8t6rybq-3w...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

Le vendredi 4 mars 2011 10:31:30, Wouter Verhelst a écrit :
> On Thu, Mar 03, 2011 at 11:02:47AM +0100, Klaus Ethgen wrote:
> > Hi,

> > And even worse, debian is often used on server platforms where you never
> > ever want to have any such magically configured services.
> 
> Since avahi isn't a dependency of anything you'd want to install on a
> server -- I personally have never installed gnome on a server, for
> instance -- it usually isn't.
> 
> [...]

Except in a workstation place.

In a uni we use your workstation during the days for teaching and the night for 
grid computing. And we care both about security 
and about using gnome.

Bastien


--
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/201103041929.37908.roucaries.bast...@gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

Le vendredi 4 mars 2011 13:23:32, Ben Hutchings a écrit :
> On Fri, 2011-03-04 at 08:15 +0100, Tollef Fog Heen wrote:
> > ]] Ben Hutchings
> > 
> > Hi,
> > 
> > | On Thu, Mar 03, 2011 at 05:20:37PM +0100, Tollef Fog Heen wrote:
> > | > To the extent this is a bug, it's a bug in the resolver that it does
> > | > not treat names with dots in them as absolute, but relative.  I know
> > | > this is how it's been done in the past, but perhaps changing that to
> > | > treating names with as absolute would be a better solution.
> > | 
> > | echo >>resolv.conf options ndots:15
> > 
> > Thanks for the suggestion, but this does not seem to do what I want, I
> > think?
> > 
> >   ndots:n
> >   
> > sets a threshold for the number of dots which must appear in a name
> > given to res_query(3) (see resolver(3)) before an initial absolute
> > query will be made.  The default for n is 1, meaning that if there
> > are any dots in a name, the name will be tried first as an absolute
> > name before any search list elements are appended to it.  The value
> > for this option is silently capped to 15.
> > 
> > I'd like it to not append the search list if there are dots at all.
> 
> You could stop being lazy and type the dot on the end too. ;-)
> 
> > so doing «getent hosts foo.bar» will only generate a query for
> > «foo.bar.», not for «foo.bar.$searchpath.»
> 
> I misparsed your question because I assumed you were addressing the
> 
> issue that Bastien pointed out in the message you replied to:
> > main security problem is resolver,
> > $host -v www.local
> > www.local
> > www.local.mydomain.com
> 
> And I believe that the 'ndots' option does address that issue - to an
> extent.  You still need DNSSEC or application-layer security to verify
> the answer, regardless of the presence of mDNS.

Not completly, it is a global default. I will prefer that mdns will be always 
solve as absolute name but want to use default for 
dns

BTW ndots seems broken at least in my installation and 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/401202

Bastien

Bastien


--
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/201103042056.31423.roucaries.bast...@gmail.com

Bug#617339: ITP: [PACKAGE] -- xfstests torture test for xfs and other filesystem

[Bastien ROUCARIES]

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


Package name: xfstests
Version: git20110223
Upstream Author:  Alex Elder x...@oss.sgi.com
URL: GPL
Description: xfstests is a torture test suite for filesystem bugs. It is useful 
in order to debug problem on linux filesystem. It 
could be run on xfs, udf, nfs, ext2, ext3, ext4, reiserfs, gfs2 and  btrfs 
filesystem.



-- 
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/201103080957.42455.roucaries.bast...@gmail.com

-Wl,--no-allow-shlib-undefined fail with undefined reference to `_dl_argv@GLIBC_PRIVATE'

[Bastien ROUCARIES]

Trying to paackage cernlib I get on amd64

gfortran -shared  .libs/aintgb.o .libs/alosb.o .libs/andb.o .libs/andntb.o 
.libs/binvec.o .libs/cntob.o .libs/cntzb.o .libs/copyb.o .libs/cprsb.o 
.libs/dalosb.o .libs/dcopyb.o .libs/ddotb.o .libs/dgthrb.o .libs/dmod3b.o \ 
.libs/dotb.o .libs/drangb.o .libs/dscalb.o .libs/dscttb.o .libs/dsxpyb.o 
.libs/dsxyb.o .libs/dvsetb.o .libs/dvxpyb.o .libs/dxypwzb.o .libs/dylosb.o 
.libs/dyloxb.o .libs/gthrb.o .libs/idlosb.o .libs/intgb.o .libs/iylosb.o 
.libs/iyloxb.o \ 
.libs/nandb.o .libs/norb.o .libs/notb.o .libs/oneb.o .libs/orb.o .libs/ornotb.o 
.libs/rangb.o .libs/rjctb.o .libs/scalb.o .libs/scttb.o .libs/smod3b.o 
.libs/sxpyb.o .libs/sxyb.o .libs/vsetb.o .libs/vxpyb.o .libs/xorb.o 
.libs/xypwzb.o \ 
.libs/ylosb.o .libs/yloxb.o .libs/zerob.o-Wl,--no-undefined 
-Wl,--no-allow-shlib-undefined   -Wl,-soname -Wl,libcernbvsl.so.0 -o 
.libs/libcernbvsl.so.0.0.0 
//lib/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE'
//lib/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE'
//lib/libc.so.6: undefined reference to `__tls_get_addr@GLIBC_2.3'
//lib/libc.so.6: undefined reference to `_rtld_global@GLIBC_PRIVATE'
//lib/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE'
collect2: ld returned 1 exit status

Do not know where to search, seems a potential to FTBS so cc:debian-devel

Bastien


-- 
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/201103091304.45373.roucaries.bastien+deb...@gmail.com

Re: -dbg packages; are they actually useful?

[Bastien ROUCARIES]

On Wed, Mar 4, 2009 at 12:11 AM, Don Armstrong  wrote:
> On Tue, 03 Mar 2009, Steve McIntyre wrote:
>> I've got to wondering: are the large -dbg packages actually really
>> useful to anybody?
>>
>> Thoughts?

See  #508585 and http://debug.debian.net/

It will be really nice to have this stuff generalized for squeeze.

> I think they are useful, but probably not for the vast majority of
> users. [I've used them on a few dozen occasions.]
> What I really wish for is the ability to have a relatively centralized
> location where the symbols from every single package ended up that was
> separate from the normal mirrors.

See http://debug.debian.net/

> The above, coupled with a coredump submission site which would accept
> coredumps and automatically generate backtraces for them (or a script
> that downloaded the -dbg packages, unpacked them and backtraced the
> coredump) would be a great help in debugging some of the relatively
> rare segfaults. [We could probably even hook up a coredump handler to
> such a script.]

Like unbuntu system. it is really really helpful.

> There was some talk that Ubuntu was going to implement such a thing at
> the Prague UDS, but I've no clue if it ever came to fruition.

It is implemented in ubuntu, and lauchpad receive automatic report.

> Don Armstron
>
> --

Bastien


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

Re: -dbg packages; are they actually useful?

[Bastien ROUCARIES]

On Wed, Mar 4, 2009 at 7:12 AM, Christian Perrier  wrote:
> Quoting Steve Langasek (vor...@debian.org):
>
>> symbols.  If there's a will to get that done in Debian now, I will
>> definitely be happy to ditch the samba-dbg package for one.
>
>
> I support my co-maintainer on that..:-)
>
> One should note that samba-dbg is sometimes used and already allowed
> tracking down some segfault bugs, which are pretty common with samba
> packages as smbd panics trigger a mail to root that recommends sending
> a bug report...if the panic is reproducible in some way.
>
> But, indeed, learning about the system that's in Ubuntu is great.
>
> By coincidence, this is time for GSOC proposals. Wouldn't be something
> like "implement a backtrace anaylysing system similar to Ubuntu's"
> something that could be useful.

They are already bug 508585 please cc :)  And improve it. But I agree
it will be nice to have it for next realease.

> Alternative: "implement ddebs.debian.org"

Yes and for all arch. Sparc is really an interesting arch particularly
when you use floatting point.

Regards

Bastien


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

Re: -dbg packages; are they actually useful?

[Bastien ROUCARIES]

On Wed, Mar 4, 2009 at 6:17 AM, Steve Langasek  wrote:
> On Tue, Mar 03, 2009 at 10:25:06PM -0500, Theodore Tso wrote:
>
>> > I'm looking at my local mirror (slowly) update at the moment, and I've
>> > got to wondering: are the large -dbg packages actually really useful
>> > to anybody? I can't imagine that more than a handful of users ever
>> > install (to pick an example) the amarok-dbg packages, but we have
>> > multiple copies of a 70MB-plus .deb taking up mirror space and
>> > bandwidth. I can understand this for library packages, maybe, but for
>> > applications?
>
>> There are people working on ways of compressing the debuginfo
>> information, and I've been told they might have results within a
>> couple of months.  Part of the problem is that depending on how the
>> package is built, the -dbg packages can be huge, so it makes the
>> cost/benefit ratio somewhat painful.
>
>> If the -dbg files were more like these sizes:
>
>> 224 e2fslibs-dbg_1.41.3-1_i386.deb     52 libss2-dbg_1.41.3-1_i386.deb
>> 452 e2fsprogs-dbg_1.41.3-1_i386.deb    48 libuuid1-dbg_1.41.3-1_i386.deb
>>  76 libblkid1-dbg_1.41.3-1_i386.deb    48 uuid-runtime-dbg_1.41.3-1_i386.deb
>>  44 libcomerr2-dbg_1.41.3-1_i386.deb
>
>> I doubt there's be too much concern
>
> Remaining concerns:
>
> - each of these dbg packages requires manual modification to the source
>  package (incl. adding the package to debian/control)
> - each has to go through the NEW queue
> - each takes up space afterwards in the Packages file
>
> Much better if these can be generated centrally as part of the builds.

Yes like for instance http://debug.debian.net/ limited unfortunatly to
i386 and not up to date,
see also #508585. It is really important for us in order to get nice
bactrace. I maintain for instance imagemagick and it will be really
nice to ask user to do an apt-get debug imagemagick in order to get a
reliable backtrace. Moreover this operation should not be priveligied,
simple joe user should be able to use debug package.

Moreover, apt-get debugdepend imagemagick should also include debug
package for dependancies of imagemagick in case of crash in library
used by imagemagick.

And a script like ddebug could ease user report. For instance the user
will do ddebug imagemagick
and the script will get a backstrace and generate a bug report.

Regards

Bastien


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

Re: group nvram

[Bastien ROUCARIES]

On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri  wrote:
> On Mar 18, Steve Langasek  wrote:
>
>> A peek at the source says it uses /proc/acpi/ibm/light.
> Other people told me that they believe that nowadays all modern
> thinkpads use a kernel driver.
>
> This is the complete list of groups which I'd rather stop using:
>
>    fuse (I have no idea about how FUSE works)

This group is important, fuse could lead to local dos.

>    kvm (what are the security implications of access to /dev/kvm?)

Idem local dos due to pinned memory

>    nvram
>    rdma (infiniband devices)
>    scanner (do SCSI scanners still exist? how are they used?)

scanner is also used for usb device.

>    tss (TPM devices, do select users have a need to access them?)


BTW why do you hate this group? They are here in order to give fine
gained privilege, that is the basis of good security.

> The other major reason to do this is that non-standard groups which are
> not in /etc/groups break some systems which use LDAP.

Add this group to standard ldap. Acces to harware should be limited by
policy, and group is a good policy. And a catch all group
coulddolocaldos is not really a good policy.

Bastien


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

Re: group nvram

[Bastien ROUCARIES]

On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri  wrote:
> On Mar 18, Steve Langasek  wrote:
>
>> A peek at the source says it uses /proc/acpi/ibm/light.
> Other people told me that they believe that nowadays all modern
> thinkpads use a kernel driver.
>
> This is the complete list of groups which I'd rather stop using:
>
>    fuse (I have no idea about how FUSE works)
>    kvm (what are the security implications of access to /dev/kvm?)
>    nvram
>    rdma (infiniband devices)
>    scanner (do SCSI scanners still exist? how are they used?)

Scanner is useful, imagine I work in a company working on a secret
project. One of the computer has a scanner. Do you wnat to give
scanning right to the internship student ?

Bastien


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

Re: group nvram

[Bastien ROUCARIES]

On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES
 wrote:
> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri  wrote:
>> On Mar 18, Steve Langasek  wrote:
>>
>>> A peek at the source says it uses /proc/acpi/ibm/light.
>> Other people told me that they believe that nowadays all modern
>> thinkpads use a kernel driver.
>>
>> This is the complete list of groups which I'd rather stop using:
>>
>>    fuse (I have no idea about how FUSE works)
>
> This group is important, fuse could lead to local dos.
>
>>    kvm (what are the security implications of access to /dev/kvm?)
>
> Idem local dos due to pinned memory
>
>>    nvram
>>    rdma (infiniband devices)

about this group:
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/256216

Having 0666 permissions would not necessarily be a bad idea, but the
consensus among other distributions is to limit RDMA access to an
"rdma" group so that administrators have some control over who gets
direct hardware access (even though in theory it is safe for anyone,
there is the possibility of untrusted users consuming network
bandwidth at least). Also, RDMA often requires increasing the amount
of locked memory allowed in /etc/security/limits.conf, and doing that
by group "rdma" is convenient as well.


>>    scanner (do SCSI scanners still exist? how are they used?)
>
> scanner is also used for usb device.
>
>>    tss (TPM devices, do select users have a need to access them?)
>
>
> BTW why do you hate this group? They are here in order to give fine
> gained privilege, that is the basis of good security.
>
>> The other major reason to do this is that non-standard groups which are
>> not in /etc/groups break some systems which use LDAP.
>
> Add this group to standard ldap. Acces to harware should be limited by
> policy, and group is a good policy. And a catch all group
> coulddolocaldos is not really a good policy.

BTW instead of arguing about group and something like this could we
create a wiki page on debian wiki about justification of group.
Therefore purpose of every system group will documented. With exemple
of security concern.

Regards

Bastien


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

Re: group nvram

[Bastien ROUCARIES]

On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
 wrote:
> On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES
>  wrote:
>> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri  wrote:
>>> On Mar 18, Steve Langasek  wrote:
>>>
>>>> A peek at the source says it uses /proc/acpi/ibm/light.
>>> Other people told me that they believe that nowadays all modern
>>> thinkpads use a kernel driver.
>>>
>>> This is the complete list of groups which I'd rather stop using:
>>>
>>>    fuse (I have no idea about how FUSE works)
>>
>> This group is important, fuse could lead to local dos.
>>
>>>    kvm (what are the security implications of access to /dev/kvm?)
>>
>> Idem local dos due to pinned memory
>>
>>>    nvram
>>>    rdma (infiniband devices)
>
> about this group:
> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/256216
>
> Having 0666 permissions would not necessarily be a bad idea, but the
> consensus among other distributions is to limit RDMA access to an
> "rdma" group so that administrators have some control over who gets
> direct hardware access (even though in theory it is safe for anyone,
> there is the possibility of untrusted users consuming network
> bandwidth at least). Also, RDMA often requires increasing the amount
> of locked memory allowed in /etc/security/limits.conf, and doing that
> by group "rdma" is convenient as well.
>
>
>>>    scanner (do SCSI scanners still exist? how are they used?)
>>
>> scanner is also used for usb device.
>>
>>>    tss (TPM devices, do select users have a need to access them?)
>>
>>
>> BTW why do you hate this group? They are here in order to give fine
>> gained privilege, that is the basis of good security.
>>
>>> The other major reason to do this is that non-standard groups which are
>>> not in /etc/groups break some systems which use LDAP.
>>
>> Add this group to standard ldap. Acces to harware should be limited by
>> policy, and group is a good policy. And a catch all group
>> coulddolocaldos is not really a good policy.
>
> BTW instead of arguing about group and something like this could we
> create a wiki page on debian wiki about justification of group.
> Therefore purpose of every system group will documented. With exemple
> of security concern.

Done under http://wiki.debian.org/SystemGroups Please contribute

> Regards
>
> Bastien
>


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

Re: User and groups justification (was Re: group nvram)

[Bastien ROUCARIES]

On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello  wrote:
> Hi there!
>
> On Wed, 18 Mar 2009 22:16:05 +0100, Bastien ROUCARIES wrote:
>> On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
>>  wrote:
>>> BTW instead of arguing about group and something like this could we
>>> create a wiki page on debian wiki about justification of group.
>>> Therefore purpose of every system group will documented. With exemple
>>> of security concern.
>>
>> Done under http://wiki.debian.org/SystemGroups Please contribute
>
> Do you know that a similar document is already installed on any Debian
> system (provided by the base-passwd package)?

I forget :S

>  /usr/share/doc/base-passwd/user-and-groups.html
>  /usr/share/doc/base-passwd/user-and-groups.txt.gz
>
> I would prefer any new information to be added there instead, since the
> files above are available offline as well.

Does not forbid to add to wiki in order to ease writing :) I agree we
should sync the offline file.

> Thx, bye,
> Gismo / Luca
>


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

Re: group nvram

[Bastien ROUCARIES]

On Thu, Mar 19, 2009 at 11:09 AM, Marco d'Itri  wrote:
> On Mar 19, Josselin Mouette  wrote:
>
>> Once was thrown the idea to prefix all system groups with ???Debian-???.
> One of the most stupid ideas which have ever been inflicted on the
> project.
>
>> This solves this specific problem in a much better way.
> How exactly? The problem is that these groups are referenced in the udev
> configuration but do not exist, and this causes problmes at boot time
> with systems using LDAP.

It is the same probleme with floppy, tty and disk group.

> But if the collective opinion of the project is that the issue does not
> exist then I will happily close bugs like #516149 and tell users to live
> with it. Please advise.

They should add this group to their ldap database. At least it should
be documented that debian system need this group. BTW redhat has also
rdma, fuse, kvm group.

Regards

Bastien


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

Re: group nvram

[Bastien ROUCARIES]

On Thu, Mar 19, 2009 at 10:59 AM, Marco d'Itri  wrote:
> On Mar 19, Bastien ROUCARIES  wrote:
>
>> It is the same probleme with floppy, tty and disk group.
> No, it's not.
>
>> They should add this group to their ldap database. At least it should
> This would not change anything.
>
>> be documented that debian system need this group. BTW redhat has also
>> rdma, fuse, kvm group.
> And recently removed them from the udev rules.
>
> If you have no clue about the issue being discussed you have no
> obligation to partecipate to the thread, you know?

First I was not offencive with you, so you please could you keep a
nice and peaceful thread.

Secondly, I use Unix for a long time, and last time I checked redhat
used kvm group. May be I am not up to date as you say, but please keep
the thread peaceful.

Moreover I respectfully disagree with you.? Permission on device file
should be from a security point of  view, permission should respect
the minimum privileges principle. Therefore daemon using /dev/fuse
should be able only to use /dev/kvm and not /dev/fuse.

You could note also that for instance Josselin mouette respectfully
disagree with you. So please keep this thread quiet.
I have the right to disagree with you, and you have the right to think
I am a sucker but please keep it private at least.

Best regard

Bastien


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

Re: group nvram

[Bastien ROUCARIES]

On Thu, Mar 19, 2009 at 2:39 PM, Henning Glawe  wrote:
> On Wed, Mar 18, 2009 at 07:13:22PM +0100, Marco d'Itri wrote:
>> This is the complete list of groups which I'd rather stop using:
>>     rdma (infiniband devices)
>
> is there any alternative way to restrict access to infiniband
> without this?

rdma group has some advantage. I have beginned to document reason
under http://wiki.debian.org/SystemGroups

You could see for instance that this group is needed in order to
update the mlock limit.

Regards

Bastien


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

Re: User and groups justification (was Re: group nvram)

[Bastien ROUCARIES]

On Fri, Mar 20, 2009 at 1:13 PM, Jon Dowland
 wrote:
> On Thu, Mar 19, 2009 at 12:34:44AM +0100, Bastien ROUCARIES wrote:
>> On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello  wrote:
>> > I would prefer any new information to be added there instead, since the
>> > files above are available offline as well.
>>
>> Does not forbid to add to wiki in order to ease writing :) I agree we should
>> sync the offline file.
>
> If you do so please bear in mind that doc/* in the base-passwd package is
> licensed GPL-2 and Debian wiki pages have no automatic explicit copyright
> exceptions (i.e. default to all rights reserved). See
> <http://wiki.debian.org/Maintainers> for an example of how to specify an
> explicit license for a new page (and the linked
> <http://wiki.debian.org/DebianWiki/LicencingTerms> for context and history)

Done.

Thank you

Bastien


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

Re: Architecture usertags

[Bastien ROUCARIES]

On Wed, Mar 25, 2009 at 7:03 PM, Luk Claes  wrote:
> Wouter Verhelst wrote:
>> Hi,
>
> Hi
>
>> I thought I'd sent out this mail, but apparently I did that when I had
>> just reinstalled my laptop and the mailsetup wasn't working yet. Sorry
>> about that.
>>
>> Now almost a month ago, I asked Don Armstrong to create architecture
>> tags in the BTS. I've always felt that such a thing would be useful,
>> because often porters are unaware of architecture-specific bugs, simply
>> because there's no way in the BTS to actually search for them. Having
>> such an ability could make porters of a particular architecture aware of
>> the issues that affect their architecture, and (where necessary) able to
>> help out.
>
> Note that porters can find many issues just by looking at the buildd.d.o
> [0] pages even for issues not (yet) known in the BTS for which they
> could file bugs.

Sometimes bug are arch specific. For instance a recent bug in librsvg
was due to a floatting point rounding. Under sparc the bug produce a
divide by zero, whereas under i386 it work normally. So arch tags are
useful.

Regards

Bastien


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

Re: deprecating /usr as a standalone filesystem?

[Bastien ROUCARIES]

On Tue, May 5, 2009 at 5:36 PM, Marco d'Itri  wrote:
> I have been told by upstream maintainers of one of my packages and by
> prominent developers of other distributions that supporting a standalone
> /usr is too much work and no other distribution worth mentioning does it
> (not Ubuntu, not Fedora, not SuSE).
>
> I know that Debian supports this, but I also know that maintaning
> forever large changes to packages for no real gain sucks.
>
> So, does anybody still see reasons to continue supporting a standalone
> /usr?
> If you do, please provide a detailed real-world use case.
> A partial list of invalid reasons is:
> - "I heard that this was popular in 1998"
> - "it's a longstanding tradition to support this"
> - "it's really useful on my 386 SX with a 40 MB hard disk"

- NFS
- for my wifi box (ie a 386 SX with 8MB of flash)

Regards

Bastien


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

Re: deprecating /usr as a standalone filesystem?

[Bastien ROUCARIES]

On Tue, May 5, 2009 at 5:43 PM, Marco d'Itri  wrote:
> On May 05, Bastien ROUCARIES  wrote:
>
>> - NFS
> This is not detailed.

/usr NFS shared. Scientific grid use this stuff and it is real world.
But may be it is too big for debian ;)

>> - for my wifi box (ie a 386 SX with 8MB of flash)
> This is not real world.

I am not really sure that embeded development is not real world. And
it will growth
more than classical PC in the next ten year. Maybe too small for debian ;)

If you believe that debian is only for new edge intel, I think that
you will feed a big troll.

Bastien


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

Re: Standardizing the layout of git packaging repositories

[Bastien ROUCARIES]

On Sat, Aug 16, 2014 at 1:59 PM, Raphael Hertzog  wrote:
> Hi,
>
> On Fri, 15 Aug 2014, Guido Günther wrote:
>> The gbp manual has a recommended branch layout:
>>
>>   
>> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING
>>
>> which could serve as a basis. There's plenty of room for improvement,
>> e.g. the case where one tracks upstream git isn't yet mentioned (I
>> started to follow the above layout also in this case).
>
> Some comments on this recommended layout:
>
> 1/ I suggested /master rather than /unstable (or sid)
>because it means we don't have to know the default codename/suite used
>for packaging of new upstream versions (in particular for downstreams)
>
> 2/ having multiple upstream/ is bound to never be up-to-date
>when I do "git checkout debian/experimental && git merge
>debian/master", upstream/experimental will get out of sync and I
>won't notice it because my package builds just fine
>
>However multiple upstream/* branches can be useful, they should
>just match real upstream branches... so things like upstream/master,
>upstream/4.8.x, upstream/4.9.x, etc.
>
> 3/ I don't see the need for backports/, I would rather
>use debian/wheezy-backports (which actually is just a specific case
>of / since wheezy-backports is the Codename in the
>Release file)
>and security/ is just the continuation of /
>after a stable release, so again I don't see the need for a specific
>branch here (and if we really need a separate branch, it can again
>be /-security)

I use for debian patches a debian-patches/version branch. Friendly
upstream could cherry pick if they need it.

Bastien

>> >   - upstream/
>> >   (note: we don't need an "upstream" branch, having the good tag for any
>> >   release that the distros are packaging is enough, it can point to a
>> >   synthetic commit built with tools like git-import-orig or to a real
>> >   upstream commit)
>>
>> Agreed, although having a branch (and recommended naming convention)
>> can be useful.
>
> Yes.
>
>> >   - pkg/
>> >   (note: git-buildpackage uses debian/ but I find this confusing
>> >   as we then also have the "debian/" prefix for ubuntu or kali uploads, we
>> >   don't need the vendor prefix as the usual versioning rules embed the
>> >   downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
>> >   any conflict on the namespace, keeping a prefix is important to easily
>> >   differentiate tags created by upstream developers from tags created
>> >   by packagers)
>>
>> The tag format is configurable in gbp and I'd expect downstreams to
>> use a different name space (e.g. ubuntu/). This makes it
>> simpler to tab complete (or delete) certain groups of tags. A patch to
>> make the tag message configurable too is waiting to be applied. pkg/
>> is too generic since we'll have more of the RPM support upstreamed
>> soonish.
>
> Anything that needs to be configured is a source of error. I'd rather
> have gbp do the right thing and pull the information from dpkg-vendor.
>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Discover the Debian Administrator's Handbook:
> → http://debian-handbook.info/get/
>
>
> --
> 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/20140816115946.gd13...@x230-buxy.home.ouaza.com
>


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

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Bastien ROUCARIES]

Le 1 sept. 2014 14:21, "Guillem Jover"  a écrit :
>
> Hi!
>
> I had noticed this a while ago while reading changelogs, but didn't
> realize at the time this poses actual problems, besides being possibly
> just a dubious practice.
>
> There seems to be some packages overriding the default compression
> level for xz to 9. This means dpkg-deb will require way more memory on
> both compression and decompression usually for extremely little gain,
> and might even fail on some systems with low memory (see #757740 for
> an example). But the real issue is that (as mentioned on the xz man
> page), using such high levels might actually make no sense at all
> when being using with data that is smaller than the dictionary size.
Could you fill a bug against lintian ?
> From doing a quick search on  for
> “dpkg-deb.*-z9” and “dh_builddeb.*-z9”, but w/o looking in detail, it
> seems that most packages are or have been maintained by Daniel Baumann
> or the Fonts Team (both CCed). Was there an actual reason to use -z9,
> beside maybe trying to get the “bestest” compression possible? :)
>
> This could be checked from lintian by using something like:
>
>   $ ar x pkg.deb data.tar.xz
>   $ xz --list --verbose --verbose --robot data.tar.xz
>
> and comparing the file sizes with the dictionary size used. I'll be
> filing a bug report about this.
>
> Thanks,
> Guillem
>
>
> --
> 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/20140901122030.ga25...@gaara.hadrons.org
>

Re: Can a leaf package require SSE2 on i386?

[Bastien ROUCARIES]

On Sun, Sep 14, 2014 at 8:47 AM, Sébastien Villemot
 wrote:
> Hi,
>
> As the maintainer of julia (a technical computing language built on top
> of LLVM), I am wondering whether I should continue supporting the i386
> architecture.
>
> The bottom line is that julia needs SSE2 (and porting it to the x87 FPU
> requires changes that are beyond what I am willing/able to do, see [1]
> for more details). And the presence of SSE2 is not guaranteed on the
> i386 architecture.
>
> So I have two options: either ship a i386 package that only works on
> SSE2 processors (ideally giving a meaningful error message when run on
> older CPUs); or drop support for i386, which is a disservice to our
> users (the few who have a SSE2-capable but not x86-64-capable processor
> will be left out; and those who are running the i386 arch on a
> x86-64-capable processor will have to cross-grade to amd64 or at least
> use multi-arch with a 64-bit kernel).
>
> Also note that my understanding is that some i386 buildds are not
> SSE2-capable (because they are qemu guests configured as such). So, if I
> were to ship an i386 package requiring SSE2, the testsuite would fail on
> those buildds (meaning that I would have to make the testsuite non
> fatal, or ask for blacklisting of those buildd).
>
> What's your opinion on this issue?

Add sse/sse2 support to libmmx ?

https://www-sop.inria.fr/members/Sylvain.Pion/progs/mmx-emu/

> [1] https://github.com/JuliaLang/julia/issues/7185
>
> --
>  .''`.Sébastien Villemot
> : :' :Debian Developer
> `. `' http://www.dynare.org/sebastien
>   `-  GPG Key: 4096R/381A7594
>


--
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/cae2spabg3bqjkx9sosnz7b_687yygi837ftxuxmfkgy-ylq...@mail.gmail.com

Re: Doxygen and embedded jquery problem, how to solve?

[Bastien ROUCARIES]

On Wed, Oct 29, 2014 at 5:48 PM, Scott Kitterman  wrote:
> On Wednesday, October 29, 2014 17:44:11 Cyril Brulebois wrote:
>> Scott Kitterman  (2014-10-29):
>> > Would another option be to use "built-using" the doxygen version in
>> > question.  Since effectively this is embedded code from the doxygen
>> > package if I understand it correctly.  Using doxygen to regenerate
>> > things is the preferred form of modification and all the source is
>> > available in doxygen.
>> >
>> > Other than being annoying and causing stuff to have to be rebuilt when
>> > doxygen is updated, what's wrong with that?
>>
>> AFAICT Built-Using means "keep the source around", not "things have to
>> be rebuilt when the source is updated".
>
> It does if you want the old source to go away.
>
> Scott K

Doxygen also embeded the png generated as C array encoded as hex on
the source code and do something like cout << pngarray to put it in
the documentation. I really doubt that C array are the prefered source
of modifcation...

Bastien


-- 
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/CAE2SPAZrpO0YY-==caghvidsrd-puwf+ho7ytrxv0dokxdh...@mail.gmail.com

Pre-Depends: init-system-helpers

[Bastien ROUCARIES]

Hi,

In order to solve #769551 I need to Pre-Depends: init-system-helpers

Indeed preinst script need it:
/var/lib/dpkg/tmp.ci/preinst: 27: /var/lib/dpkg/tmp.ci/preinst:
deb-systemd-helper: not found

Thus I am asking to add a pre-depends to init-system-helpers


-- 
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/cae2spazybwolhxcdmcu+xgqplryezvjdlp0d9sweaxxkqxt...@mail.gmail.com

Re: Pre-Depends: init-system-helpers

[Bastien ROUCARIES]

Le 15 nov. 2014 19:18, "Bastian Blank"  a écrit :
>
> On Sat, Nov 15, 2014 at 06:06:17PM +0100, Bastien ROUCARIES wrote:
> > In order to solve #769551 I need to Pre-Depends: init-system-helpers
> > Indeed preinst script need it:
> > /var/lib/dpkg/tmp.ci/preinst: 27: /var/lib/dpkg/tmp.ci/preinst:
> > deb-systemd-helper: not found
>
> Why do you need deb-systemd-helper in preinst?

See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730604#74

Bastien
> Bastian
>
> --
> The sight of death frightens them [Earthers].
> -- Kras the Klingon, "Friday's Child", stardate 3497.2
>
>
> --
> 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/20141115180044.gb12...@mail.waldi.eu.org
>

Re: Packages using old dpkg tools paths

[Bastien ROUCARIES]

Le 18 nov. 2014 17:29, "Guillem Jover"  a écrit :
>
> Hi!
>
> On Mon, 2014-11-03 at 11:23:37 +0100, Guillem Jover wrote:
> > I'm planning on starting to file bug reports for the source packages
> > below (BCCed).
>
> Here's the current status. I've filed bugs now with patches, or just
> uploaded for orphaned ones.

Note that lintian was improved here.

Bastien
>
> > Sources list (via codesearch.d.o)
> > 
> >
> > ,--- u-a ---
> > startupmanager_1.9.13-7/bootconfig/usplash.py
>
> QA upload startupmanager_1.9.13-8.
>
> > wmanager_0.2.1-11/debian/wmanagerrc-update
>
> Bug #769966.
>
> > `---
>
> > ,--- dpkg-divert ---
> > amule_2.3.1+git1a369e47-2/debian/amule-utils.preinst
> > amule_2.3.1+git1a369e47-2/debian/amule.preinst
>
> Bug #769847.
>
> > `---
>
> > ,--- dpkg-statoverride ---
> > acidbase_1.4.5-4/debian/postinst
>
> Bug #769899, wontfixed as the package will be left to die instead.
>
> > beep_1.3-3/debian/postinst
>
> Bug #769898.
>
> > geki2_2.0.3-8/debian/postinst
>
> Bug #770055.
>
> > geki3_1.0.3-7/debian/postinst
>
> Bug #770056.
>
> > gravitywars_1.102-32/debian/postinst
>
> Bug #770062.
>
> > im_1:151-3/debian/postrm
>
> Bug #770042.
>
> > monsterz_0.7.1-7/debian/postinst
>
> Bug #770057.
>
> > netdiag_1.1-1/debian/diagperm
>
> Bug #770044 (minor, it's just an example script now).
>
> > netselect_0.3.ds1-26/debian/netselect.postinst
>
> Bug #770045.
>
> > man-db_2.7.0.2-2/debian/postinst
> > openssh_1:6.7p1-2/debian/openssh-client.postinst
> > openssh_1:6.7p1-2/debian/openssh-server.postinst
>
> Coling uploaded these, thanks!
>
> > pconsole_1.0-11/debian/postinst
>
> Bug #770046, pending, was already fixed in VCS.
>
> > phpgacl_3.3.7-7.3/debian/phpgacl.postinst
>
> Bug #770048.
>
> > pure-ftpd_1.0.36-3/debian/pure-ftpd-common.postinst
>
> Bug #770049.
>
> > systemtap_2.6-0.1/debian/systemtap-runtime.postinst
>
> Bug #770050.
>
> > tecnoballz_0.93.1-1/debian/tecnoballz.postinst
>
> Bug #770059.
>
> > terminatorx_3.90-2/debian/postinst
>
> Bug #770051.
>
> > tvtime_1.0.2-12.1/debian/postinst
>
> QA upload tvtime_1.0.2-13.
>
> > xvt_2.1-20.1/debian/postinst
>
> Bug #770052.
>
> > `---
>
> Thanks,
> Guillem
>
>
> --
> 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/20141118162923.ga28...@gaara.hadrons.org
>

Re: Pre-Depends: init-system-helpers

[Bastien ROUCARIES]

Le 19 nov. 2014 21:33, "Russ Allbery"  a écrit :
>
> Jonas Smedegaard  writes:
>
> > Which implies, I believe, that any other way of starting daemons should
> > also respect policy-rc.d if it can lead to automated triggering.
>
> > Example: if a logrotate snippet uses "update-rc.d force-restart ..."
> > then suppressing that deamon with policy-rc.d will be circumvented when
> > cron triggers log rotation.
>
> Yes, absolutely.  Likewise for cron jobs, etc.  That's something that I
> don't think we're doing a great job of right now, and really should
> improve.

Could lintian help here ?
> --
> Russ Allbery (r...@debian.org)   
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive: https://lists.debian.org/87bno3hqwm@hope.eyrie.org
>

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Bastien ROUCARIES]

On Tue, May 15, 2012 at 11:10 AM, Jon Dowland  wrote:
> On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
>> No, I hereby start saying good by to 3.0
>
> I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
> found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last
> few packages.

You could use gitpkg with a quilt export hook. i use it regularly with
imagemagick and it work perfectly (it is gitpkg over git over svn).

Bastien
>
>
> --
> 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/20120515091028.GB24635@debian
>


-- 
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/CAE2SPAaMrJR2y15X0OKteGT47SZ1Ej=QG=v++iywstkvuod...@mail.gmail.com

RE : Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Bastien ROUCARIES]

gitpkg with quilt hook is very nice.

Have a branch with debian change, one for patch queue, one for upstream

Use git cherry pick for porting patch

I use it for imagemagick

Will post my workflow tomorrow I post from my phone, sorry for top post and
brievety

Bastien

Le 21 mai 2012 02:56, "Marco d'Itri"  a écrit :

On May 18, Russ Allbery  wrote:

> I do this work in cases where keeping the patches...
Some of my packages have 30-60 patches ("mature" software...), and
merging them would make them impossibile to understand.
Is there a VCS workflow which would make such packages easier to manage
than with quilt? (I like quilt, BTW.)

--
ciao,
Marco

Re: gitpkg with a quilt export hook

[Bastien ROUCARIES]

On Mon, May 21, 2012 at 3:28 AM, Brian May
 wrote:
> On 16 May 2012 19:45, Bastien ROUCARIES  wrote:
>> You could use gitpkg with a quilt export hook. i use it regularly with
>> imagemagick and it work perfectly (it is gitpkg over git over svn).
>
> Out of curiosity, how do you use that and not have it include changes
> to debian/*  ? That appeared to me my problem trying to use this
> method. Especially as some of my git commits change files both inside
> and outside debian/*

Ok step for imagemagick
1. git svn fetch #retrieve recent svn commit
2. git checkout 9682bf563240ad971717554bab3f69f7252767f5 # git
revision for svn commit 7980 aka version 6.7.7.0
3. git checkout -b upstream/6.7.7.0 # create an upstream branch for
revision 6.7.7.0
4. rm -rf * # clean up directory tree
5.  tar --strip 1 -xaf ../imagemagick_6.7.7.0.orig.tar.bz2 # extract origin
6. git add . # add everything
7. git commit -a -m "add uptream tar.bz2"
8. pristine-tar commit ../imagemagick_6.7.7.0.orig.tar.bz2
upstream/6.7.7.0 # use pristine tar
9. git checkout -b debian-patches/6.7.7.0-1
10. git checkout -b  debian/6.7.7.0-1 # create new debian branch
11. git checkout debian/6.7.6.8-1 # checkout previous debian tree
12. git merge  --no-commit upstream/6.7.7.0 # merge but without commiting
13. find ./* -path './debian' -prune -o -path './.git' -prune -o
-exec rm -rf '{}' + # remove all except debian and git
14.  tar --strip 1 -xaf ../imagemagick_6.7.7.0.orig.tar.bz2 # use upstream
15. git add .
16. git commit -a -m 'merge with upstream' # emulate git theirs but safer

now do your change on debian on  debian/6.7.7.0-1 branch and change on
other directory on   debian-patches/6.7.7.0-1 (you could use cherry
pick for back port of upstream or reusing previous patch queue)

Bastien




> Thanks
> --
> Brian May 
>
>
> --
> 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/CAA0ZO6DTeHx4Jve6RR=yns9zzt5j91ftx3bxodstogtvfnz...@mail.gmail.com
>


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