date:20120819

On Sat, 18 Aug 2012 18:44:10 +0200, Bastian Blank 
wrote:
>On Sat, Aug 18, 2012 at 06:31:08PM +0200, Marc Haber wrote:
>> On Sat, 18 Aug 2012 13:10:34 -0300, Henrique de Moraes Holschuh
>> >Anything that uses IPv6 and cannot deal with dynamic changes on the host
>> >addresses is critically broken.
>> That includes bind, radvd and apache, and, IIRC, sshd.
>
>bind does not listen on ::?
>
>Not sure about radvd, but it needs more than existing interfaces?

It chokes when the Interface changes after it was started, causing
very hard to debug connectivity outages.

>apache and sshd can listen on ::.

Configuring software to listen on all interfaces/IP is an unacceptable
solution, since it means losing significant functionality and/or
security.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1t2zg0-0002aj...@swivel.zugschlus.de

Re: RFC: terminate init script when service is ready

On Sat, 18 Aug 2012 22:43:15 +0200, m...@linux.it (Marco d'Itri) wrote:
>Non-static addresses on a web server are not a major use case.

IPv6 people say "renumbering is easy", which is only the case if SLAAC
is used and DNS doesn't matter or is dynamically used.

>But still, I agree that we should have a better way to signal to user 
>space when an interface is ready. Not just for IPv6, but also more 
>generally for interfaces which are subject to the STP delays.

Amen.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1t2zgs-0002aw...@swivel.zugschlus.de

Re: Misc Developer News (#30)

2012-08-19 Thread Vincent Danjean

Le 19/08/2012 01:17, Sandro Tosi a écrit :
> On Sun, Aug 19, 2012 at 1:12 AM, Vincent Danjean  wrote:
>>   Hi,
>>
>> Le 18/08/2012 12:47, Paul Wise a écrit :
>>> Control Commands at sub...@bugs.debian.org time
>>> ---
>>>
>>>  You can now use control commands at sub...@bugs.debian.org time in the
>>>  pseudo-headers.
>>
>>   Does this mean that it will be possible to improve reportbug so
>> that it will be possible to automaticcaly subscribe a bug when
>> reporting it?
> 
> yep
> 
>> Anyone already working on it?
> 
> not that I'm aware of. But please note that if Control support will
> land in reportbug, it will be something generic, that would allow also
> for all the other commands and not just statically add "Control:
> subscribe -1 " to the pseudo-headers section.

  I just opened #685271 in order to discuss about this feature.

  Regards,
Vincent

> Regards,


-- 
Vincent Danjean  Adresse: Laboratoire d'Informatique de Grenoble
Téléphone:  +33 4 76 61 20 11ENSIMAG - antenne de Montbonnot
Fax:+33 4 76 61 20 99ZIRST 51, avenue Jean Kuntzmann
Email: vincent.danj...@imag.fr   38330 Montbonnot Saint Martin


-- 
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/50309481.7070...@free.fr

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

On Sat, 18 Aug 2012 19:47:43 +0200, m...@linux.it (Marco d'Itri) wrote:
>On Aug 18, Marc Haber  wrote:
>> Because Debian prides itself in being Universal regarding ports and
>> architectures.
>Does it? Who said so?

"We". In the same way you say "we" when you claim to be talking about
Debian and trying to make your personal opinion sounds like it was
broad consensus.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1t2zhw-0002ac...@swivel.zugschlus.de

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

On Sun, 19 Aug 2012 02:14:22 +0800, Aron Xu 
wrote:
>For yourself, they might be toy ports, but please don't speak on
>behalf of others from time to time when nobody authorized you to do
>so. I'm not using those ports everyday but I respect their passion and
>efforts.

Amen. I find it derogatory towards the people spending months of their
private time to make exotic ports work to call their work "toy ports".
I am seriously thinking about a GR explicitly endorsing the work on
more exotic ports to stop this derogatory, impolite and
contraproductive behavior.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1t2zj7-0002bw...@swivel.zugschlus.de

Re: Enabling uupdate to simply remove files from upstream source

2012-08-19 Thread Tollef Fog Heen

]] Andreas Tille 

> Hi,
> 
> trying to summarise suggested changes for the proposal:
> 
>  1. The new field Files-Excluded in debian/copyright contains
> a space separated list of regular expressions.

Why regexes rather than globs, which is used elsewhere in the file?

Also, your example uses globs, AFAICS.

-- 
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/87boi75m67@xoog.err.no

Re: RFC: terminate init script when service is ready

2012-08-19 Thread Bastian Blank

On Sun, Aug 19, 2012 at 09:12:54AM +0200, Marc Haber wrote:
> On Sat, 18 Aug 2012 22:43:15 +0200, m...@linux.it (Marco d'Itri) wrote:
> >Non-static addresses on a web server are not a major use case.
> IPv6 people say "renumbering is easy", which is only the case if SLAAC
> is used and DNS doesn't matter or is dynamically used.

DNS for outgoing stuff is dead, praise privacy extensions. So what is
the problem?

> >But still, I agree that we should have a better way to signal to user 
> >space when an interface is ready. Not just for IPv6, but also more 
> >generally for interfaces which are subject to the STP delays.
> Amen.

And not possible.

Bastian

-- 
Another dream that failed.  There's nothing sadder.
-- Kirk, "This side of Paradise", stardate 3417.3


-- 
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/20120819081831.ga32...@wavehammer.waldi.eu.org

Re: RFC: terminate init script when service is ready

On Aug 19, Marc Haber  wrote:

> IPv6 people say "renumbering is easy", which is only the case if SLAAC
This is between wishful thinking and an urban legend, so people who 
actually know about IPv6 have not been saying this much in the last 
years.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: terminate init script when service is ready

2012-08-19 Thread Bastian Blank

On Sun, Aug 19, 2012 at 09:12:00AM +0200, Marc Haber wrote:
> On Sat, 18 Aug 2012 18:44:10 +0200, Bastian Blank 
> wrote:
> >Not sure about radvd, but it needs more than existing interfaces?
> It chokes when the Interface changes after it was started, causing
> very hard to debug connectivity outages.

radvd runs on routers, which are not subject to SLAAC. So no dynamic
changes, only changes by the admin.

> >apache and sshd can listen on ::.
> Configuring software to listen on all interfaces/IP is an unacceptable
> solution, since it means losing significant functionality and/or
> security.

Listening on a specific address is no security feature. Even if Linux
will not response to neighbor discoveries on an interface without the
particular address configured, it will answer to other protocols.

You can use setsockopt(SO_BINDTODEVICE) to force a service on a
particular interface.

Bastian

-- 
Peace was the way.
-- Kirk, "The City on the Edge of Forever", stardate unknown

-- 
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/20120819082949.gb32...@wavehammer.waldi.eu.org

Re: Misc Developer News (#30)

On Sun, Aug 19, 2012 at 7:12 AM, Vincent Danjean wrote:

>   Does this mean that it will be possible to improve reportbug so
> that it will be possible to automaticcaly subscribe a bug when
> reporting it? Anyone already working on it?

Subscribing to bugs does not use the control bot, so I'm not sure if
that would work. I guess debbugs would need some enhancements before
reportbug can be adapted.

http://www.debian.org/Bugs/Developer#subscribe

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

2012-08-19 Thread Joerg Jaspert


On 12942 March 1977, Marco d'Itri wrote:
>> Because Debian prides itself in being Universal regarding ports and
>> architectures.
> Does it? Who said so?
> But even if this were true, it does not automatically justify dumbing 
> down the OS which people in the real world use for the sake of toy 
> ports.

There are no toy ports. Just some (unfortunately) DDs who don't get it.

-- 
bye, Joerg
 Aquariophile: welches debian/ welche xfree version?
 woody
 Xfree version 86


-- 
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/874nnzl1ec@gkar.ganneff.de

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On 12-08-19 at 08:32am, Charles Plessy wrote:
> Le Sun, Aug 19, 2012 at 12:44:44AM +0200, Jonas Smedegaard a écrit :
> > On 12-08-18 at 10:19pm, Andreas Tille wrote:
> > >  1. The new field Files-Excluded in debian/copyright contains
> > > a space separated list of regular expressions.
> > > The deletion process will loop over every expression
> > > 
> > >   rm -rf ${MAIN_SOURCE_DIR}/
> > 
> > Copyright file format emplicitly emphasizes that the globbing is not 
> > shell style but find style.
> > 
> > I believe it is better to loop over either of these expressions:
> > 
> > find ${MAIN_SOURCE_DIR}/* -path  -delete
> > 
> > find ${MAIN_SOURCE_DIR}/* type f -name  -delete
> 
> Hi all,
> 
> it looks like it is necessary to add './' before the expression if 
> (and only if) the expression does not contain it.

Isn't that covered by the inverse above - trailing /* to base path?


 - Jonas

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

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


signature.asc
Description: Digital signature

Re: Enabling uupdate to simply remove files from upstream source

2012-08-19 Thread Ansgar Burchardt

gregor herrmann  writes:
> On Fri, 17 Aug 2012 13:08:39 +0200, Andreas Tille wrote:
>> my suggestion was just to settle with a common and simple
>> solution.  This should be pretty simple to implement (I'd volunteer to
>> do this but wanted to seek for comments before filing a bug report +
>> patch).
>
> Yup, that would be nice.
> But I don't think it belongs into uupdate but in uscan.

Please keep it usable for packages that do not use uscan to get the
upstream tarball.  I have some packages where I generate the upstream
tarball from a VCS repository, but have to exclude some files.  It would
be nice to use the tool for such cases as well.

Ansgar


-- 
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/87mx1rfbom@marvin.43-1.org

Re: Enabling uupdate to simply remove files from upstream source

2012-08-19 Thread Andreas Tille

On Sat, Aug 18, 2012 at 11:41:24PM +0200, gregor herrmann wrote:
> >  2. There was one vote from Gregor Hermann to use the --repack option
> > of uscan.  I personally admit that I do not fully agree with
> > Gregor that this means changing the semantics of an existing option.
> > We are just repackaging and without the additional information in
> > debian/copyright the functionality remains exactly the same.
> 
> Sorry if I was unclear here: actually I don't really like to re-use
> --repack because the "new" --repack would do something else (i.e:
> more) than the "old" repack.
>  
> > Gregor made also the remark that he likes the pkg-perl teams
> > method of doing things because once d/watch is adjusted you don't
> > have to do anything besides calling uscan.  I consider the method
> > I like to suggest here as serving the very same purpose
> 
> Sure, I guess I will get used to adding "--$option" instead of just
> using plain uscan, if needed :)

When reading this I wonder whether we actually will need any command
line option at all?  Shouldn't it rather be the other way around that we
want to *prevent* repackaging in some cases if Files-Excluded is set and
otherwise just to the repackaging as a default.  In other words:  If it
is documented in debian/copyright that some files will be excluded the
proper way to act for uscan would be actually to exclude the files.  We
rather would need an option

uscan --no-exclusion (or --fetch-original ???)

to prevent uscan from doing so.  BTW, we also would need an according
USCAN_NO_EXCLUSION (or whatever name we decide) for /etc/devscripts.conf
and ~/.devscripts.

Kind regards

   Andreas.

-- 
http://fam-tille.de

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

Re: RFC: terminate init script when service is ready

On Sun, 19 Aug 2012 10:29:49 +0200, Bastian Blank 
wrote:
>On Sun, Aug 19, 2012 at 09:12:00AM +0200, Marc Haber wrote:
>> On Sat, 18 Aug 2012 18:44:10 +0200, Bastian Blank 
>> wrote:
>> >Not sure about radvd, but it needs more than existing interfaces?
>> It chokes when the Interface changes after it was started, causing
>> very hard to debug connectivity outages.
>
>radvd runs on routers, which are not subject to SLAAC.

But they frequently have bridge and dummy devices. That aside, you
should take a look on real world systems. The vast majority of my
radvd devices run on hosted servers which have their external IP
address assigned dynamically from the outside and run IPv6 to
internally virtualized systems.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1t32wa-0003dx...@swivel.zugschlus.de

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

2012-08-19 Thread Andreas Tille

On Sun, Aug 19, 2012 at 12:44:44AM +0200, Jonas Smedegaard wrote:
> On 12-08-18 at 10:19pm, Andreas Tille wrote:
> >  1. The new field Files-Excluded in debian/copyright contains
> > a space separated list of regular expressions.
> > The deletion process will loop over every expression
> > 
> >   rm -rf ${MAIN_SOURCE_DIR}/
> 
> Copyright file format emplicitly emphasizes that the globbing is not 
> shell style but find style.
> 
> I believe it is better to loop over either of these expressions:
> 
> find ${MAIN_SOURCE_DIR}/* -path  -delete
> 
> find ${MAIN_SOURCE_DIR}/* type f -name  -delete
> 
> The latter is when item does not contain "/".

ACK. 
 
> >  4. In case something was removed the version string will be appended by
> > '+dfsg' to express the fact that the content of the original source
> > was changed.
> 
> Suffix should be configurable.
> 
> I use ~dfsg by default, ~dfsg1 and bumping numbers for multiple 
> repackagings, and only +dfsg when the repackaging happens after a 
> non-repackaged version was released into Debian.
> 
> Reason for this is that there is a slight chance upstream may re-release 
> same upstream version repackaged to fix a purely tarball-related issuem 
> and I would then have room for using that proper version instead of 
> using epoch or add a bogus .0 to the version.

This was also my initial idea when firt proposing ~dfsg.  On the other
hand:  I would *really* want to have upstream adding a new version number
to the cleaned up release.  It is just (uhmm, find your own word here)
if people release the same named file with different content.  So I do
not see great harm if we would settle with +dfsg.  Gregor, could you give
better reasons than Jonas for +dfsg?  I'm personally a friend of adding
one feature (the removal of files) first.  Later we could add additional
features like configuring suffixes and compression methods.
 
> > For the implementation of this it waqs suggested to
> > 
> >use Debian::Copyright;
> 
> That initial test by Gregor makes me worry if Debian::Copyright parser 
> might be too strict: Writing should be strict but parsing relaxed - 
> Copyright file format with undefined fields added should *not* be 
> treated as broken. Perhaps there are other surprises waiting to happen 
> :-/

Could anybody say something about this?

Kind regards

   Andreas.

-- 
http://fam-tille.de


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

Re: Enabling uupdate to simply remove files from upstream source

2012-08-19 Thread Andreas Tille

Hi,

On Sun, Aug 19, 2012 at 11:55:37AM +0200, Ansgar Burchardt wrote:
> > Yup, that would be nice.
> > But I don't think it belongs into uupdate but in uscan.
> 
> Please keep it usable for packages that do not use uscan to get the
> upstream tarball.  I have some packages where I generate the upstream
> tarball from a VCS repository, but have to exclude some files.  It would
> be nice to use the tool for such cases as well.

Wouldn't it make way more sense to teach uscan to read a VCS repository?
I admit I would not volunteer for this coding because it seems more
complex to me, but IMHO this would be the proper way to handle this. 

For the time beeing to help you with this we should probably come back
to the grep-dctrl suggestion from Jonas and write a simple shell script
that takes a directory as input and removes files by using find as
discussed above.  Uscan could call this script and you could do so as
well.

What do you think?

Kind regards

  Andreas.

-- 
http://fam-tille.de

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

Re: Possible release note for systems running PHP through CGI.

2012-08-19 Thread Cyril Brulebois

Charles Plessy  (19/08/2012):
> This will interrupt upgrade of servers using php5-cgi, but to avoid
> surprises, the rough consensus in #674089 is also to document the same
> information in the release notes.

I guess we could consider that for a very specific, low-popcon package.
But knowingly interrupting upgrades for a well-known problem, on a very
high number of systems? I'm not sure that's appropriate. Quite the
opposite, actually.

Mraw,
KiBi.


signature.asc
Description: Digital signature

DebConf12 Debian mobile BoF notes

Hi all,

During DebConf12 we had a BoF discussing Debian mobile stuff:

http://penta.debconf.org/dc12_schedule/events/947.en.html

Thanks to the DebConf video team, the session was recorded:

http://meetings-archive.debian.net/pub/debian-meetings/2012/debconf12/high/947_Debian_mobile_BoF.ogv
http://meetings-archive.debian.net/pub/debian-meetings/2012/debconf12/low/947_Debian_mobile_BoF.
http://wiki.debconf.org/wiki/DebConf12/Videoteam/Thanks

Here are some notes from the session:

==
== Agenda

* We are here to keep Debian relevant for mobile devices.
* Changes since last year?
* What now?

==
== Changes since last year

Inside Debian:

EFL mostly updated to recent versions.

FSO upstream worked with us to get their recent release into Debian.

pabs got a Samsung Galaxy S I, OdyX got a random Chinese tablet.

Debian mobile email list, IRC opened, not much work done.

Outside Debian:

GPU driver reverse engineering projects for ARM Mali, Qualcomm Andreno,
PowerVR, FIMG 3DSE.

http://limadriver.org/
http://gitorious.org/freedreno/
http://github.com/tom3q/openfimg/wiki/
http://powervr.gnu.org.ve/

Android Linux kernel stuff slowly merging.

KDE community released Plasma Active. http://plasma-active.org/

KDE community working on Vivaldi Tablet. http://makeplaylive.com/

OpenMoko/Replicant/FSO/SHR synergies and expansion of hardware support.

http://shr-project.org/
http://freesmartphone.org/
http://replicant.us/

GTA04 became available:

http://www.handheld-linux.com/wiki.php?page=GTA04

Canaima (Debian derivative) working with hardware vendors to produce
Canaima Mobile.

Mozilla started Boot to Gecko / Firefox OS.

MeeGo community was closed, Maemo is being de-funded, various projects
split out from Maemo/MeeGo as a result; Jolla, Mer, Nemo, Cordia Tab.

Tizen was released (Samsung/Intel, EFL, git repos indicate Debian/Ubuntu
heritage).

WebOS has been freed (not all yet?). http://openwebosproject.org/

==
== Discussion

Mobile is important to keep Debian relevant.
How do we deal with Linux drivers and binary blobs?
We need to pick a UI which is supported long term by upstreams and
packaged.

What about Debian chroots (or LXC) on Android kernels? that would solve
the problem of all the underlying headaches.

We could take cyanogen mod to steal hardware support from them and build
WebOS on top or any other stack. It might not be easy due to power
management differences between android and Linux, interesting bugs might
appear, but it would be nice to try it.

Meego was proven to be hard to follow due to ABI changes.

Tizen and WebOS are reasonable designed platforms, but we don't know
what we get or we don't get => we need investigation work. (send a
report to mailing list)

Need folks to start investigating the various platforms and report back
on how useful they are.

FSO, how is it? It is better aligned to Debian philosophy and binary
blob free. There is the feeling this platform is unmaintained and not
maintained long term, but it is expanding beyond the devices of OpenMoko
Inc. It is also a forum we can actively contribute, unlike vendor-driven
projects like Android.

E17, is active and part of Tizen and SHR, it can be suitable and
interesting for the purpose.

Getting stuff into upstream kernels takes a long time, kernel support
cycle is a problem for Debian. Still even an issue for OpenMoko GTA02.

We could provide out of Debian Linux kernels (maybe via PPA-like). The
Debian OpenMoko team did this for GTA02 and it proved suboptimal since
the upstream community (OpenMoko Inc, SHR etc) wasn't using the latest
upstream kernels nor focusing on getting patches merged there.

Embedding Debian appliances (eg FreedomBox) in an existing framework is
a pragmatic way to speed time-to-market whether using Windows (via
Virtualbox?) or Android in container.

Venezuela might be investing in development of a Debian based mobile OS
(Canaima). Partnership between govts of Venezuela & China. Vtelca
(http://www.vtelca.gob.ve/) & Orinoquia (http://orinoquia.com.ve/) have
relationships with Chinese manufacturers like ZTE and Huawei.

--
bye,
pabs

http://wiki.debian.org/PaulWise

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

Bug#685286: ITP: pyadb -- Python module to interact with the ADB tool

2012-08-19 Thread Chema Garcia

Package: pyadb
Severity: wishlist

Package name: pyadb
Version: 0.1.1
Upstream Author: Chema Garcia 
URL: https://github.com/sch3m4/pyadb/
License: BSD Revised
Description: Python module to interact with the ADB tool



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

Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=es_ES@euro, LC_CTYPE=es_ES@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120819110912.14232.71866.report...@debianito.hell.lan

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

2012-08-19 Thread Uoti Urpala

Marc Haber wrote:
> Amen. I find it derogatory towards the people spending months of their
> private time to make exotic ports work to call their work "toy ports".

There are people who use their time doing things like hopping across a
continent on one foot. That is a lot of work, but it's not particularly
useful to anyone. Amount of work alone does not imply something deserves
support. At best it's harmless; if the people doing it insist others
help them, or otherwise hinder others doing more useful things, then
it's contemptible.

-- 
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/1345375164.1896.23.camel@glyph.nonexistent.invalid

Re: RFC: terminate init script when service is ready

2012-08-19 Thread Henrique de Moraes Holschuh

On Sat, 18 Aug 2012, Marco d'Itri wrote:
> But still, I agree that we should have a better way to signal to user 
> space when an interface is ready. Not just for IPv6, but also more 

We need better userspace glue, then.  Because the netlink interface to
the kernel network core and IP stack has existed for ages.  FreeBSD has
something just as usable as well, and sample code to interface to both
can be found on the routing engines quagga and bird at the very least.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-- 
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/20120819130621.ga20...@khazad-dum.debian.net

Re: Minified javascript files

2012-08-19 Thread Bernhard R. Link

* Vincent Bernat  [120818 21:18]:
> The difference is that we need to bug upstream about a file that we
> won't even use. There is no real bug (not even a licensing issue).

They are distributing files without source, so everyone else can either
not just easily modify it or verify if it really does what it is
supposed to do. This is definitely a shortcoming in what upstream ships
and really something you should bug upstream about.

> We request him to add a file that we won't use anyway.

There is more than just "us". If it is for us, they could just remove
the file. It's for the people that those files is supposed to be for.
They should have the right to change it, for which they effectively
need the source.

> I don't know many upstream who have so much free time.

If just adding a source file they hopefully have anyway or to remove
a file does not take much time. (There is a lot of unmaintained
software out there, but as I said, not much difference to getting
any other patch in).

Bernhard R. Link


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

Re: RFC: terminate init script when service is ready

On Aug 19, Henrique de Moraes Holschuh  wrote:

> > But still, I agree that we should have a better way to signal to user 
> > space when an interface is ready. Not just for IPv6, but also more 
> We need better userspace glue, then.  Because the netlink interface to
> the kernel network core and IP stack has existed for ages.  FreeBSD has
Correct. With an event-driven init system it should be simple to write 
a bridge which will translate netlink events, deal with delays, etc.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Minified javascript files

 ❦ 19 août 2012 15:11 CEST, "Bernhard R. Link"  :

>> The difference is that we need to bug upstream about a file that we
>> won't even use. There is no real bug (not even a licensing issue).
>
> They are distributing files without source, so everyone else can either
> not just easily modify it or verify if it really does what it is
> supposed to do. This is definitely a shortcoming in what upstream ships
> and really something you should bug upstream about.

The source is one link away. People wanting the source just have to
click on the link in the header of the minified version. As for
verification, having the source next to the minified version does not
guarantee anything about the minified version, all the more that we
don't have currently in Debian Wheezy a reliable minifier.

>> We request him to add a file that we won't use anyway.
>
> There is more than just "us". If it is for us, they could just remove
> the file. It's for the people that those files is supposed to be for.
> They should have the right to change it, for which they effectively
> need the source.

Your use case is inexistant. Regular people needing the source will grab
it at http://jquery.com.

>> I don't know many upstream who have so much free time.
>
> If just adding a source file they hopefully have anyway or to remove
> a file does not take much time. (There is a lot of unmaintained
> software out there, but as I said, not much difference to getting
> any other patch in).

No, upstream usually don't have the source. They download the minified
version from jQuery website. And no upstream will remove a file that is
useful for 99.999% of his users just to please one Debian maintainer.
-- 
Modularise.  Use subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


pgpNUT2TYscKI.pgp
Description: PGP signature

Re: Possible release note for systems running PHP through CGI.

On 12-08-19 at 11:17am, Charles Plessy wrote:

>  - PHP scripts can be executed by Apache httpd through libapache2-mod-php5 or
>php5-cgi.  Debian recommends libapache2-mod-php5, but there are still
>thousands of installations wich report the use of php5-cgi according to the
>Popularity Contest statistics.

FWiW, out of the ~7'500 popcon hits of regular use of php5-cgi, ~900 
also regularly uses suphp, so might be unaffected by this issue.


 - Jonas

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

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


signature.asc
Description: Digital signature

Re: Request for testing pre-release of Systemd to SysVinit converter

2012-08-19 Thread akhil vij

Hello Michael,

Yeah, Mentors and I had this discussion earlier. Each approach had their
pros and cons resulting in too much disambiguation at that point. So, we
decided to focus only on getting the converter right.

I realize that the script's place in the Debian packaging overflow is still
vague, but through this discussion we'll be able to find out community's
opinion on the same.

However, with the standalone tool the package maintainers will at least be
able to generate SysV init scripts, following same format, with minimal
effort.

Kind Regards,
Akhil Vij

On Sun, Aug 19, 2012 at 5:37 AM, Michael Biebl  wrote:

> Hi Akhil!
>
> On 18.08.2012 15:41, akhil vij wrote:
> > I'm Akhil Vij, a Summer of Code 2012 student. I've been working on
> building
> > a tool for generating SysV init script from systemd
> > configuration(*.service) files. I will kindly request you to try the tool
> > and share your valuable feedback.
>
> Are there any plans/ideas how this tool is supposed to be integrated
> into the Debian packaging workflow?
> Do you plan to run this tool during package build time and ship the
> generated files in the binary package or generate the files during
> install time? If the former, integration into dh_installinit or a
> separate debhelper program would be great.
>
> I'm not sure, if this is something which is covered by your GSoC
> project, but imho to be really useful, having this kind of integration
> is needed.
>
> Cheers,
> Michael
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>

Re: RFC: terminate init script when service is ready

2012-08-19 Thread Clint Byrum

Excerpts from Salvo Tomaselli's message of 2012-08-05 15:35:09 -0700:
> Hello,
> 
> since services might depend on other services at boot, they must be sorted.
> 
> But after doing a "service foo start", and waiting for its termination, we 
> don't know if the service has started or not, maybe the process was just 
> created and is kept waiting by the sheduler, so when the next service is 
> started the service might not really be there.
> 

Salvo, thanks for bringing up this issue.

I've been watching the various discussions of boot dependencies
and service dependencies and wondering about this issue for the last
couple of years. I think we all need to consider looking at some guiding
principles before we run off and start solving perceived problems that
may not even exist.

First, the number of actual dependencies between services at boot time
is quite low. There is a necessary sequencing of events that takes place
in all modern operating systems. Mount filesystems, start networking,
setup auth, mount remote filesystems, etc.

But we take this too far. If your auth depends on mysql, and the mysql
service happens to be local, then the only thing that is important is
that mysql is started without waiting for auth, and vice-versa. This
potentially circular dependency should not be a problem. Both services
should be able to "start" without the other, and should just keep trying
the other service.

This is important, because if mysql is not on the box with auth, it will
need to act this way. Otherwise, one no longer needs to define service to
service dependencies, but full blown server to server dependencies. Now
you're using a complicated distributed orchestration system to handle
large scale system bring-up (or medium scale power infrastructure
failures..).

Even if you reject this as dodging the problem, just conider that the
service which claimed to start successfully before the dependent service
starts may go away immediately thereafter, so without making your daemons
resilient, dependencies don't mean much anyway.

In summary:

* Services which "depend" on others should be re-evaluated to see if they
  actually "depend" or just need them eventually.
* Consider the case of a service which may or may not be "local"


-- 
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/1345386383-sup-7...@fewbar.com

Re: Misc Developer News (#30)

2012-08-19 Thread Don Armstrong

On Sun, 19 Aug 2012, Vincent Danjean wrote:
> Le 18/08/2012 12:47, Paul Wise a écrit :
> > Control Commands at sub...@bugs.debian.org time
> > ---
> > 
> >  You can now use control commands at sub...@bugs.debian.org time in the
> >  pseudo-headers.
> 
>   Does this mean that it will be possible to improve reportbug so
> that it will be possible to automaticcaly subscribe a bug when
> reporting it? Anyone already working on it?

No, unfortunately. subscription is a request@ operation, not a
control@-only operation. [The difference between these is minor, and
really just requires additional code to make it so that it can be
specified at control@ time too.]

However, what I'd really like is a library that handled mailing list
subscription with perl bindings (or in perl) which I could easily
interface with the BTS that didn't suck, and then route all messages
through that. However, it appears that such a thing does not exist,
and I haven't had a chance to write it.

Don Armstrong

-- 
Judge if you want.
We are all going to die.
I intend to deserve it.
 -- a softer world #421
http://www.asofterworld.com/index.php?id=421

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

-- 
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/20120819163431.ga21...@teltox.donarmstrong.com

Bug#685316: ITP: molds -- semi-empirical electronic structure and molecular dynamics

2012-08-19 Thread Michael Banck

Package: wnpp
Severity: wishlist
Owner: debichem-de...@lists.alioth.debian.org


* Package name: molds
  Version : no release yet
  Upstream Author : Mikiya Fujii
* URL : http://en.sourceforge.jp/projects/molds/
* License : GPLv3+
  Programming Lang: C++
  Description : Semi-empirical electronic structure and molecular dynamics

MolDS is a Semi-Empirical electronic structure and molecular dynamics
package.
.
Features includes:
.
 * Semi-Empirical methods CNDO2, INDO, ZINDO/S, MNDO, AM1 and PM3
 * Excited States via Single Configuration Interaction (CIS)
 * Dispersion corrections to AM1 (AM1-D) and PM3 (PM3-D)
 * Pairwise Distance Directed Gaussian (PDDG) correction to PM3
   (PM3/PDDG)
 * Single-Point, geometry optimization, Molecular Dynamics (MD),
   Monte-Carlo (MC) and  Polymer Molecular Dynamics (RPMD) type of
   calculations
.
MolDS currently ships parameters for the elements H, C, N, O, and S.


-- 
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/20120819171633.ga9...@nighthawk.chemicalconnection.dyndns.org

can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

Hey.

I hope this won't become too much of a rant, but IMHO we long ago
crossed the point where something (well actually many things) would have
needed to be seriously done.
My grandparents always warned me about UNIX programs written in capital
letters ;-).


Seriously... I have nothing against a high level daemon that manages
underlying network control systems (ifupdown, vpnc, ppp, strongswan,
openswan, openvpn) but not the way NM does it, especially as it doesn't
work correctly at all edges and ends.

Until "recently" all that wasn't a big problem, because one was easily
able to simply not install NM, but nowadays more and more packages start
to depend on it (of those I know, most notably gnome-core) or at least
use it's functionality to determine whether one is online or not.

I know there was recently the discussion about recommends and
meta-package, this is _not_ about repeating it.
And as said above, in principle I like the idea of having a high level
system that exposes networking for users and also software.



Where do I see the main problems of NM?

1) In parts it has some security issues.
- At least the default setting seems to be that any user can connect to
any network.
This alone may already be a security risk, or method to intentionally or
accidentally circumvent things (like a VPN).
It may well be that one can disable this, but at least the default seems
to allow it.

- At least the network connections from /etc/network/interfaces are
exported to the normal user, even if that user cannot read that file.
A typical example is that I put in network connections that the normal
user should not be able to enable, or even connections that require
credentials in /etc/network/interfaces.
So NM should only export a connection, if the user would be able to read
the necessary config files.


2) NM's design seems to be wrong.
AFAIU (I didn't look into too much depth, though), NM is based on the
design idea, that it replaces all network management and configuration
from the respective distros.
So when NM brings up a connection, it does not simply invoke some e.g.
ifscheme wlan0-myHomeNet
ifup wlan0
but directly invokes wpa_supplicant.

That's IMHO quite awful, as you loose all the proper integration of
ifupdown by gaining nothing.
Moreover it complicates the code, as now NM needs to come with its
own /e/n/interfaces parsers (which will everytime the something changes
there)

The same problem exists for configuration. NM tries to be its own
canonical location for network configuration.
In most places (the quite defunct /etc/network/interfaces support is the
only exception I'd know of) it does not even export the connections from
the canonical locations (examples: vpnc, strongswan, ppp)

In my opinion, NM should:
- export any connections from the real canonical places
(e.g. /etc/network/interfaces, /etc/vpnc/*, /etc/ppp/peers/*
and /etc/chatscripts/*, /etc/ipsec.conf and /etc/ipsec.d/*, etc. pp.)
- only if a user doesn't find something there, a per user connection
configuration should be set up.
- I know, NM supports system wide configuration, too, but IMHO that
should be dropped altogether and NM should also not try to edit the real
canonical configuration.
If someone want's a system wide IPsec connection, that should e.g. go to
strongswan's /etc/ipsec.conf.


3) ifupdown integration is really bad
ifupdown is really a good framework, it offers hooks and and is properly
integrated in many packages.

Well this is similar to (2).
a) NM (AFAIU) doesn't really use ifupdown for controlling, it merely
parses /etc/network/interfaces
b) barely nothing from /etc/network/interfaces is supported, some bugs
I've noticed:
  - the dns-* options from resolvconf don't work at all
  - wireless connections aren't exported if wpa-key-mgmt is not set
(which there should be no need to in many cases), and for WPA-EAP it
seems to generally not work.
  - the same is the case with many advanced options (ap_scan, etc. pp.)
c) when NM is running, I cannot use ifup foo / ifdown foo / ifconfig
... well I can.. but then everything gets really messed up
d) when I disable wireless in NM it really blocks it, so I can't use it
with ifupdown. Now one can rfkill unblock then... but why? and even if
one does...NM seems to get confused again.


4) upstream more or less doesn't want to support these scenarios...
Already many months ago, I've opened a Debian bug, that some /e/n/i
connections are simply not shown by NM.
Given that this is actually an upstream issue, I've reported this (and
most other problems I've mentioned before, especially the poor ifupdown
integration but also the ideas about adding support for all the
canonical configurations) upstream.
I guess the conclusion is: "this won't be implemented".

It seems the "desired" scenario for NM is that /e/n/i is empty and
everything is handled Apple™ like: hide-everything, don't support
advanced setups.


So,... at least I want to continue our wonderful ifupdown and also the
other native

Re: Enabling uupdate to simply remove files from upstream source

Ansgar Burchardt  writes:

> Please keep it usable for packages that do not use uscan to get the
> upstream tarball.  I have some packages where I generate the upstream
> tarball from a VCS repository, but have to exclude some files.  It would
> be nice to use the tool for such cases as well.

Teaching uscan how to do things like git archive might be very useful.
One of my packages currently has the following, which I bet could be
replaced by a sufficiently Git-aware uscan and a bit of glue for finding
the upstream Git repository and understanding the upstream tag format
(perhaps in debian/watch?).

# These variables are used by get-orig-source, to construct dkms.conf, and
# to set the build version.  You will need to change TAG to package stable
# releases instead of experimental releases.
DEBIAN  := $(shell dpkg-parsechangelog | grep ^Version: | cut -d' ' -f2)
DEBVERS := $(shell echo '$(DEBIAN)' | cut -d- -f1)
VERSION := $(shell echo '$(DEBVERS)' | sed -e 's/[+-].*//' -e 's/~//g')
TAG := $(shell echo 'openafs-stable-$(VERSION)' | sed 's/\./_/g')
REPO:= git://git.openafs.org/openafs.git

# Upstream does tarball releases for major releases, but not for point
# relesaes, and the tarball releases are split into src and doc and contain
# the WINNT directory.  Dropping WINNT, which is not used on Debian, saves a
# substantial amount of space in the source package, and there's no reason
# to include the files generated by regen.sh when we're going to run it
# again ourselves anyway.
#
# This rule therefore generates an upstream tarball from the upstream Git
# tag, rather than the tarball release, without the generated files that are
# not in Git and without the WINNT directory.  It assumes that git-core is
# installed and there's network connectivity to the upstream repository.
get-orig-source:
git archive --remote='$(REPO)' --prefix='openafs_$(DEBVERS).orig/' \
--format=tar '$(TAG)' | tar xf -
rm -r openafs_$(DEBVERS).orig/src/WINNT
tar cf openafs_$(DEBVERS).orig.tar openafs_$(DEBVERS).orig
rm -r openafs_$(DEBVERS).orig
gzip -9 openafs_$(DEBVERS).orig.tar

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

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

Re: Possible release note for systems running PHP through CGI.

Charles Plessy  writes:

> In summary:

>  - PHP scripts can be executed by Apache httpd through libapache2-mod-php5 or
>php5-cgi.  Debian recommends libapache2-mod-php5, but there are still
>thousands of installations wich report the use of php5-cgi according to the
>Popularity Contest statistics.

Just to mention, one of the reasons to use php5-cgi instead of
libapache2-mod-php5 is that one can achieve much better privilege
separation (at the significant cost of speed) by using suexec or something
akin to suexec and running scripts via CGI.  That's what we do locally at
Stanford for our general sandbox web service (as opposed to the more
restricted ones that don't allow arbitrary user CGI scripts): we use a
locally-modified suexec that also chroots and acquires file system
credentials specific to the particular web site.  That way, insecure PHP
only permits a compromise of that particular web site and not any other
hosted on the same servers.

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

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

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

On Aug 19, Christoph Anton Mitterer  wrote:

> Where do I see the main problems of NM?
NM, as a design goal, is not supposed to be able to manage every 
possible configuration.
I see no reason do /discourage/ it use: it has important use cases where 
it works well, the problem is just the people who are making hard to not 
install it when it is not appropriate for the job.

> Or will we just mothball ifupdown silently and slowly (as it's replaced
> by NM).
As explained, NM is not a general ifupdown replacement.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

2012-08-19 Thread Stephan Seitz


On Sun, Aug 19, 2012 at 07:26:46PM +0200, Christoph Anton Mitterer wrote:

Until "recently" all that wasn't a big problem, because one was easily
able to simply not install NM, but nowadays more and more packages start
to depend on it (of those I know, most notably gnome-core) or at least
use it's functionality to determine whether one is online or not.


I don’t use NM, but I have it installed (you mentioned the dependencies).  
I have a „exit 0” in the init script, so NM won’t be started. I don’t see 
any problems with other applications (e.g. Pidgin).


So try it, and if it works for you, you can ignore NM.

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Minified javascript files

Vincent Bernat  writes:
> ❦ 19 août 2012 15:11 CEST, "Bernhard R. Link"  :

>> They are distributing files without source, so everyone else can either
>> not just easily modify it or verify if it really does what it is
>> supposed to do. This is definitely a shortcoming in what upstream ships
>> and really something you should bug upstream about.

> The source is one link away. People wanting the source just have to
> click on the link in the header of the minified version. As for
> verification, having the source next to the minified version does not
> guarantee anything about the minified version, all the more that we
> don't have currently in Debian Wheezy a reliable minifier.

Right.

Debian's current policies here aren't exactly wrong.  In an ideal world,
we would indeed always provide source next to everything, and that's a
good goal.  But this is a very hard sell upstream, whose immediate
reaction is "There are copies of the unminified source of jquery all over
the net -- you can't throw a rock without hitting one!  Why am I
responsible for shipping the 48,194th copy?"  There really isn't any
feasible scenario in which someone wanting to modify the package can't
find the relevant source (*provided* that they haven't modified jquery or
the similar Javascript library first before minimizing it, but that's
quite rare).

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

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

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

Marc Haber  writes:

> Amen. I find it derogatory towards the people spending months of their
> private time to make exotic ports work to call their work "toy ports".
> I am seriously thinking about a GR explicitly endorsing the work on more
> exotic ports to stop this derogatory, impolite and contraproductive
> behavior.

I'd second it, in exactly that hope.

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


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

Re: Possible release note for systems running PHP through CGI.

2012-08-19 Thread Roger Lynn

On 19/08/12 03:20, Charles Plessy wrote:
>  - PHP scripts can be executed by Apache httpd through libapache2-mod-php5 or
>php5-cgi.  Debian recommends libapache2-mod-php5, but there are still
>thousands of installations wich report the use of php5-cgi according to the
>Popularity Contest statistics.

Many of the users of php5-cgi will be doing so because they are using other
web servers. The discussion in #674089 seems to mainly revolve around
Apache. How does this affect other web servers?

Regards,

Roger


-- 
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/okj7g9-bb4@silverstone.rilynn.me.uk

Re: Minified javascript files

2012-08-19 Thread Simon Josefsson

Vincent Bernat  writes:

>  ❦ 19 août 2012 15:11 CEST, "Bernhard R. Link"  :
>
>>> The difference is that we need to bug upstream about a file that we
>>> won't even use. There is no real bug (not even a licensing issue).
>>
>> They are distributing files without source, so everyone else can either
>> not just easily modify it or verify if it really does what it is
>> supposed to do. This is definitely a shortcoming in what upstream ships
>> and really something you should bug upstream about.
>
> The source is one link away. People wanting the source just have to
> click on the link in the header of the minified version. As for
> verification, having the source next to the minified version does not
> guarantee anything about the minified version, all the more that we
> don't have currently in Debian Wheezy a reliable minifier.

That seems problematic -- so even if the source is shipped, there is no
way to re-build the minified file?

/Simon


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

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

2012-08-19 Thread Ben Hutchings

On Sun, 2012-08-19 at 19:26 +0200, Christoph Anton Mitterer wrote:
[...]
> 1) In parts it has some security issues.
> - At least the default setting seems to be that any user can connect to
> any network.
[...]

According to README.Debian:

To allow users to connect to the NetworkManager daemon they have to be in the
group "netdev".

> - At least the network connections from /etc/network/interfaces are
> exported to the normal user, even if that user cannot read that file.
> A typical example is that I put in network connections that the normal
> user should not be able to enable, or even connections that require
> credentials in /etc/network/interfaces.
> So NM should only export a connection, if the user would be able to read
> the necessary config files.

The capability to *use* credentials is separate from the capability to
*read* the credentials.

(Also, the design choice to read credentials from a file that is world-
readable by default is incredibly stupid, and you may wish to report
bugs on the packages that do that.)

> 2) NM's design seems to be wrong.
> AFAIU (I didn't look into too much depth, though), NM is based on the
> design idea, that it replaces all network management and configuration
> from the respective distros.

I don't think that was the original intent at all.  However it is
gradually being extended to manage more types of device.

[...]
> In my opinion, NM should:
> - export any connections from the real canonical places
> (e.g. /etc/network/interfaces, /etc/vpnc/*, /etc/ppp/peers/*
> and /etc/chatscripts/*, /etc/ipsec.conf and /etc/ipsec.d/*, etc. pp.)
> - only if a user doesn't find something there, a per user connection
> configuration should be set up.
> - I know, NM supports system wide configuration, too, but IMHO that
> should be dropped altogether and NM should also not try to edit the real
> canonical configuration.
> If someone want's a system wide IPsec connection, that should e.g. go to
> strongswan's /etc/ipsec.conf.

You seem to be asking for an awful lot of integration work within NM
itself, which means divergence from upstream.

> 3) ifupdown integration is really bad
> ifupdown is really a good framework, it offers hooks and and is properly
> integrated in many packages.

ifupdown *was* a good framework, but Linux moved on.  ifupdown doesn't
know anything about interface state.  It doesn't know whether hooks
succeeded and it can't check for failures because that would be an
incompatible change (#547587).

Yes, we have a large investment in ifupdown.  But the result is still
not good, and we don't get much help with this from other distributions.

[...]
> d) when I disable wireless in NM it really blocks it, so I can't use it
> with ifupdown. Now one can rfkill unblock then... but why? and even if
> one does...NM seems to get confused again.

If you say 'disable wireless', why are you surprised that it does what
you say?  I think it uses rfkill because that may save more power.

> 4) upstream more or less doesn't want to support these scenarios...
> Already many months ago, I've opened a Debian bug, that some /e/n/i
> connections are simply not shown by NM.
> Given that this is actually an upstream issue, I've reported this (and
> most other problems I've mentioned before, especially the poor ifupdown
> integration but also the ideas about adding support for all the
> canonical configurations) upstream.
> I guess the conclusion is: "this won't be implemented".
> 
> It seems the "desired" scenario for NM is that /e/n/i is empty and

I suspect so.

> everything is handled Apple™ like: hide-everything, don't support
> advanced setups.

I don't think this is the direction upstream is going in.  Instead, it's
adding more support for advanced setups.

[...]
> So what are the opinions of the others? Will we continue to live with
> the current disease? Are the alternatives better integrated? Could we
> get discourage NMs use if necessary?
> Or will we just mothball ifupdown silently and slowly (as it's replaced
> by NM).

I would really like to see Debian developers working to improve Network
Manager so it can replace ifupdown.  For example, improving the command
line interface and support for various types of software devices.
Unfortunately, I don't have the spare time to make much of a
contribution to that myself.  (I do install ifupdown hooks as part of
ethtool, so I'll have to think about those.)

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.

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

Re: Minified javascript files

2012-08-19 Thread Pau Garcia i Quiles

On Sun, Aug 19, 2012 at 8:10 PM, Simon Josefsson  wrote:

>> As for
>> verification, having the source next to the minified version does not
>> guarantee anything about the minified version, all the more that we
>> don't have currently in Debian Wheezy a reliable minifier.
>
> That seems problematic -- so even if the source is shipped, there is no
> way to re-build the minified file?

It really depends on using exactly the same version of the same
minifier with exactly the same parameters (which you may not know) and
even then you cannot be sure, e. g. a minifier may use generate
shortened variable names randomly.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


-- 
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/CAKcBoku94n7aqPsw3AYTZu=i84drkT=yqp9ayw-enpyrgzf...@mail.gmail.com

Re: Minified javascript files

2012-08-19 Thread Simon Josefsson

Pau Garcia i Quiles  writes:

> On Sun, Aug 19, 2012 at 8:10 PM, Simon Josefsson  wrote:
>
>>> As for
>>> verification, having the source next to the minified version does not
>>> guarantee anything about the minified version, all the more that we
>>> don't have currently in Debian Wheezy a reliable minifier.
>>
>> That seems problematic -- so even if the source is shipped, there is no
>> way to re-build the minified file?
>
> It really depends on using exactly the same version of the same
> minifier with exactly the same parameters (which you may not know) and
> even then you cannot be sure, e. g. a minifier may use generate
> shortened variable names randomly.

I believe differences like that are not important, compare how gcc
generate different binaries each time depending on parameters etc.
However, if a minified file is shipped that cannot be re-created at all
(due to no minifier) I don't think shipping source for the file is the
only problem.  Both source code and the tools needed to generate output
forms is needed for users to be able to use a modified version of the
program.

/Simon

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gsu4rfs@latte.josefsson.org

Re: Allowing multi-arch specs in depends line?

2012-08-19 Thread Chow Loong Jin

On 19/08/2012 09:05, Steve Langasek wrote:
> On Sat, Aug 18, 2012 at 03:09:46PM +0200, Steffen Möller wrote:
> 
>> I prepared a package for BOINC (http://boinc.berkeley.edu) with all the
>> dependencies for owners of CUDA-savvy NVidia cards to help installing the
>> libraries.  Since many scientific applications with BOINC only have 32bit
>> binaries, there are extra dependencies for the amd64 platform on the
>> respective 32bit variants.  This looked like
>>  libcuda1-ia32 [amd64]|nvidia-current [amd64]
>> in the past and was just fine. But recently the nvidia drivers became
>> multiarched, so libcuda1-ia32 no longer exists.  A respective update built
>> nicely, but lintian complains:
> 
>> E: boinc-nvidia-cuda: bad-provided-package-name libcuda1:i386
> 
>> The package name is fine, it is even installed:
> 
>> $ dpkg -l libcuda1* | egrep '^(ii|\|\|)' | awk '{print $2,$3,$4}'
>> Name Version Architecture
>> libcuda1:amd64 304.37-1 amd64
>> libcuda1:i386 304.37-1 i386
> 
>> Is there another way to express the dependency? Or is this a lintian bug?
>> I found my specification rather intuitive.
> 
> You may not use :$arch specifiers in dependencies for wheezy.  The squeeze
> package manager cannot parse such dependencies, so allowing them would make
> it impossible to upgrade to wheezy from squeeze.
> 
> To work around this, you may need the help of the libcuda maintainers to
> provide suitable architecture-dependent packages, marked Multi-Arch:
> foreign, that you can depend on in place of using the :$arch suffix.
> 

That might make sense if this sort of situation was common. If it were specific
to boinc-nvidia-cuda, I would think that boinc-nvidia-cuda should be split in a
manner similar to this:

Package: boinc-nvidia-cuda
Architecture: amd64 i386
Depends: boinc-nvidia-cuda-ia32 (= ${binary:Version}), libcuda1 | nvidia-current

Package: boinc-nvidia-cuda-ia32
Architecture: i386
Multi-Arch: foreign
Depends: libcuda1 | nvidia-current

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: Minified javascript files

 ❦ 19 août 2012 20:10 CEST, Simon Josefsson  :

>>> They are distributing files without source, so everyone else can either
>>> not just easily modify it or verify if it really does what it is
>>> supposed to do. This is definitely a shortcoming in what upstream ships
>>> and really something you should bug upstream about.
>>
>> The source is one link away. People wanting the source just have to
>> click on the link in the header of the minified version. As for
>> verification, having the source next to the minified version does not
>> guarantee anything about the minified version, all the more that we
>> don't have currently in Debian Wheezy a reliable minifier.
>
> That seems problematic -- so even if the source is shipped, there is no
> way to re-build the minified file?

Not in Debian Wheezy. The most up-to-date minifier, uglifyjs, has
suffered from the node.js name transition and is not currently available
in wheezy. Other minifiers (like yui-compressor) are considered not
reliable enough. Therefore, currently, we offer only uncompressed
version of jQuery.
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)


pgpQQQuSzsTgn.pgp
Description: PGP signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

 ❦ 19 août 2012 20:32 CEST, Ben Hutchings  :

>> 1) In parts it has some security issues.
>> - At least the default setting seems to be that any user can connect to
>> any network.
> [...]
>
> According to README.Debian:
>
> To allow users to connect to the NetworkManager daemon they have to be in the
> group "netdev".

But also:

  Alternatively you can install the "consolekit" package which will
  grant access for all locally logged in users.

But all this can be changed by altering the appropriate file in
/etc/dbus-1/system.d.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)


pgpge7rFD4ITs.pgp
Description: PGP signature

Re: Possible release note for systems running PHP through CGI.

On Aug 19, Charles Plessy  wrote:

>  - PHP scripts can be executed by Apache httpd through libapache2-mod-php5 or
>php5-cgi.  Debian recommends libapache2-mod-php5, but there are still
This is another issue which concerns me, since mod_php forces the use of 
preforking apache, which means that the server will either stop serving 
pages or OOM at the first hint of real traffic.
(And obviously mod_php is wildly insecure for multitenants servers.)

>thousands of installations wich report the use of php5-cgi according to the
>Popularity Contest statistics.
Yes, because sensible people who need PHP will try to use it as 
CGI/FastCGI (or FPM, finally in wheezy).

>  - This breaks the websites executing PHP scripts through php5-cgi, and
>a solution is being be documented in the php5 package's NEWS file.
>
> http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=commitdiff;h=f7a6351c620075a9d2a551fbed38ea26919f0d94
I think that this entry is too mild/vague:
- "including but possibly not limited to the Apache HTTPD Server": such 
  a major issue justifies being specific about the affected packages
- too many "may"s, while the entry should clearly state, maybe in caps, 
  something like "this will almost certainly break your server if you 
  use PHP as CGI/FastCGI, and also leak your source code and passwords"

> This will interrupt upgrade of servers using php5-cgi, but to avoid surprises,
> the rough consensus in #674089 is also to document the same information in the
> release notes.
I agree with the interrupting upgrades for such a major package is going 
to be annoying.
I am also concerned that a *simple* solution to restore the old 
behaviour in a secure way is not provided: maybe php5-cgi should install 
a sensible default configuration in /etc/apache2/conf.d/ ?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

2012-08-19 Thread Michael Biebl

On 19.08.2012 19:30, Russ Allbery wrote:
> Marc Haber  writes:
> 
>> Amen. I find it derogatory towards the people spending months of their
>> private time to make exotic ports work to call their work "toy ports".
>> I am seriously thinking about a GR explicitly endorsing the work on more
>> exotic ports to stop this derogatory, impolite and contraproductive
>> behavior.
> 
> I'd second it, in exactly that hope.

Sorry, but I think this would be non-sense.
Either the "exotic ports" (as Marc called them) prove themselves to be
useful and valuable based on their technical merits or they don't.

If those ports need a GR to silence any criticsm regarding those ports,
then something is going seriously wrong.

Michael

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

signature.asc
Description: OpenPGP digital signature

Re: Minified javascript files

On 12-08-19 at 08:10pm, Simon Josefsson wrote:
> Vincent Bernat  writes:
> 
> >  ❦ 19 août 2012 15:11 CEST, "Bernhard R. Link"  :
> >
> >>> The difference is that we need to bug upstream about a file that we
> >>> won't even use. There is no real bug (not even a licensing issue).
> >>
> >> They are distributing files without source, so everyone else can either
> >> not just easily modify it or verify if it really does what it is
> >> supposed to do. This is definitely a shortcoming in what upstream ships
> >> and really something you should bug upstream about.
> >
> > The source is one link away. People wanting the source just have to
> > click on the link in the header of the minified version. As for
> > verification, having the source next to the minified version does not
> > guarantee anything about the minified version, all the more that we
> > don't have currently in Debian Wheezy a reliable minifier.
> 
> That seems problematic -- so even if the source is shipped, there is no
> way to re-build the minified file?

In Wheezy we have the minifier yui-compressor which probably(!) doesn't 
produce broken code but is not the most efficient at its job.

I say probably, because regression testing is uncommon, and the 
environment for which is must work is often alien (e.g. compile on 
Debian but run the code in Internet Explorer in Windows), so broken 
JavaScript may go unnoticed for some time.

Because yui-compressor is not the most efficient at minifying, it 
receives less testing, which also leads to potential bugs going 
unnoticed for longer time.

For status of uglifyjs - the minifier used upstream for e.g. jQuery, see 
http://bugs.debian.org/684044

Regards,

 - Jonas

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

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

signature.asc
Description: Digital signature

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

2012-08-19 Thread Gergely Nagy

Michael Biebl  writes:

> If those ports need a GR to silence any criticsm regarding those ports,
> then something is going seriously wrong.

I've yet to see said criticism.

-- 
|8]


-- 
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/874nnyio0c@luthien.mhp

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

2012-08-19 Thread Andrew Shadura

Hello,

On Sun, 19 Aug 2012 19:32:03 +0100
Ben Hutchings  wrote:

> > 3) ifupdown integration is really bad
> > ifupdown is really a good framework, it offers hooks and and is
> > properly integrated in many packages.

> ifupdown *was* a good framework, but Linux moved on.  ifupdown doesn't
> know anything about interface state.

Why should it? It's a configuration tool, not a monitoring one. If
monitoring is needed, a different tool can be developed which would
perfectly integrate into ifupdown... but nobody has needed that yet?

> It doesn't know whether hooks succeeded and it can't check for
> failures because that would be an incompatible change (#547587).

It can, and compatibility isn't a matter here, it's just a question of
bringing other packages to a state they should have been in already.

Also, as you don't know the stuff behind ifupdown development, please
don't make such statements, okay? We're in the freeze now, so the work
on ifupdown is limited to fixing RC bugs for a while, but this doesn't
mean new stuff won't be developed to make ifupdown better.

-- 
WBR, Andrew

signature.asc
Description: PGP signature

Re: Enabling uupdate to simply remove files from upstream source

2012-08-19 Thread gregor herrmann

On Sun, 19 Aug 2012 12:19:57 +0200, Andreas Tille wrote:

> > Suffix should be configurable.

Ack.

> > I use ~dfsg by default, ~dfsg1 and bumping numbers for multiple 
> > repackagings, and only +dfsg when the repackaging happens after a 
> > non-repackaged version was released into Debian.
> > 
> > Reason for this is that there is a slight chance upstream may re-release 
> > same upstream version repackaged to fix a purely tarball-related issuem 
> > and I would then have room for using that proper version instead of 
> > using epoch or add a bogus .0 to the version.
> 
> This was also my initial idea when firt proposing ~dfsg.  On the other
> hand:  I would *really* want to have upstream adding a new version number
> to the cleaned up release.  It is just (uhmm, find your own word here)
> if people release the same named file with different content.  So I do
> not see great harm if we would settle with +dfsg.  Gregor, could you give
> better reasons than Jonas for +dfsg?  

Well, I see Jonas' point but I haven't encountered it yet in my
experience; and often repackaging happens after detecticting that
it's needed, in which case +dfsg seems more logical.

> > >use Debian::Copyright;
> > That initial test by Gregor makes me worry if Debian::Copyright parser 
> > might be too strict: Writing should be strict but parsing relaxed - 
> > Copyright file format with undefined fields added should *not* be 
> > treated as broken. Perhaps there are other surprises waiting to happen 
> > :-/

Yup, I was just the first that came to my mind.
 
> Could anybody say something about this?

Next guess:

Dpkg::Control::Hash - parse and manipulate a block of RFC822-like fields
(libdpkg-perl)

Let's try:

in d/copyright:

Files-Excluded: doc/a src/b
 bin/c

test script:

#v+
#!/usr/bin/perl   
 
use strict;
use warnings;

use Dpkg::Control::Hash;

my $c = Dpkg::Control::Hash->new();
$c->load('debian/copyright');

my @excluded_files = split /\s/, $c->{'Files-Excluded'};
print "@excluded_files\n";
#v-

Output:

doc/a src/b bin/c


Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Vic Chesnutt: Thailand


signature.asc
Description: Digital signature

Re: Enabling uupdate to simply remove files from upstream source

2012-08-19 Thread gregor herrmann

On Sun, 19 Aug 2012 12:09:59 +0200, Andreas Tille wrote:

> > Sure, I guess I will get used to adding "--$option" instead of just
> > using plain uscan, if needed :)
> When reading this I wonder whether we actually will need any command
> line option at all?  Shouldn't it rather be the other way around that we
> want to *prevent* repackaging in some cases if Files-Excluded is set and
> otherwise just to the repackaging as a default.  In other words:  If it
> is documented in debian/copyright that some files will be excluded the
> proper way to act for uscan would be actually to exclude the files. 

Yup, that would at least be more convenient.


Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Tom Waits: Lullaby


signature.asc
Description: Digital signature

Re: Possible release note for systems running PHP through CGI.

On Sun, 2012-08-19 at 12:43 +0200, Cyril Brulebois wrote:
> I guess we could consider that for a very specific, low-popcon package.
> But knowingly interrupting upgrades for a well-known problem, on a very
> high number of systems? I'm not sure that's appropriate. Quite the
> opposite, actually.
I don't quite understand how we could willingly let run our users into
broken sites and even worse possible security issues.

Be it low-popcon or high... and by the way I have some problem that
popcon is nowadays used as justification for many things... after all...
it's not representative, is it?


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Possible release note for systems running PHP through CGI.

On Sun, 2012-08-19 at 17:26 +0200, Jonas Smedegaard wrote:
> FWiW, out of the ~7'500 popcon hits of regular use of php5-cgi, ~900 
> also regularly uses suphp, so might be unaffected by this issue.
"mights" are not something we should build our security upon.

And apart from that... I had a very short glance at suphp,... and it
seems it also uses mime-types for handlers, right?
So that means setups may likely also be vulnerable to the removal of the
types from mime-types.

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Re: Possible release note for systems running PHP through CGI.

On Sun, 2012-08-19 at 18:16 +0100, Roger Lynn wrote:
> How does this affect other web servers?
There was someone mentioning that lighthtttp may use /etc/mime.types,
too.
So yes, basically anything (though I guess security critical things
should only be found at webservers, as they typically serve interpreted
PHP) using /etc/mime.types in such a manner may be vulnerable.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

On 12-08-18 at 12:36am, Andreas Tille wrote:
> On Fri, Aug 17, 2012 at 11:03:27PM +0200, Jonas Smedegaard wrote:
> > > I admit I'm not very experienced with Perl and reading RFC822 files - 
> > > so if somebody would help implementing this I'd be glad.
> > 
> >   grep-dctrl -FFormat -n -sFiles-Excluded \
> >   http://www.debian.org/doc/packaging-manuals/copyright-format/1.0 \
> >   < debian/copyright
> > 
> > Result should be a space-separated list of files or dirs consumable by 
> > find, as documented in copyright format.
> 
> Well, uscan makes some use of system so this could work - but I hoped
> for a more Perl-ish solution (similar to the rfc822 reader in
> python-debian).

Is this Perl-ish enough for you?:

#!/usr/bin/perl -w
use Parse::DebControl;
use feature "say";
$okformat = 
qr'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0';
$parser = new Parse::DebControl(1);
$data = $parser->parse_file($ARGV[0], {
discardCase=>1,
singleBlock=>1,
});
die unless ($data->{"format"} =~ m{^$okformat/?$});
foreach (grep {/\//} split /\s+/, $data->{"files-excluded"}) {
say 'dir: '.$_;
};
foreach (grep {/^[^\/]+$/} split /\s+/, $data->{"files-excluded"}) {
say 'file: '.$_;
};


Replace "say..." with calls to find ... -delete.


 - Jonas

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

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


signature.asc
Description: Digital signature

Re: Possible release note for systems running PHP through CGI.

Hey Russ, Marco.

On Sun, 2012-08-19 at 22:32 +0200, Marco d'Itri wrote:
> >thousands of installations wich report the use of php5-cgi according to 
> > the
> >Popularity Contest statistics.
> Yes, because sensible people who need PHP will try to use it as 
> CGI/FastCGI (or FPM, finally in wheezy).
Well... unfortunately upstream is quite stupid (to be honest) in that
they suggest mod_php as default.
It's from a security point of view the worst possible solution and from
a performance view at least not better than FPM (likely worse).

I would like to see Debian deviate from this and actively suggest CGI or
FCGI... but all my notes towards this were immediately turned down and I
did not even succeed in convincing them in adding far less intrusive
security and/or performance optimisations (just have a look at #674205)

But if anyone would lobby that (release goal: default to CGI/FCGI),
they'd have definitely my support :)

> I think that this entry is too mild/vague:
> - "including but possibly not limited to the Apache HTTPD Server": such 
>   a major issue justifies being specific about the affected packages
The reason why I wrote it that vague is, that you cannot definitely tell
whether a package is vulnerable or not, because it's not the package but
the configuration.
So if one made his own Apache config, used RemoveType php as I suggested
in the respective bugs and set the types new, one would be perfectly
safe.

And further,... at least I was not able to make a definite list even of
possibly affected packages.
Apache with PHP-CGI/FCGI is affected for sure... mod_php not, but only
because Ondrej included a sane default config for this.

> I am also concerned that a *simple* solution to restore the old 
> behaviour in a secure way is not provided: maybe php5-cgi should install 
> a sensible default configuration in /etc/apache2/conf.d/ ?
That was just the idea I had yesterday night, but I haven't had time yet to 
file a bug for it.
But actually I'd suggest that this goes to php5-common, and ALL PHP
SAPIs share a single conf.

Nevertheless,... this solves the issue ONLY for apache,... and won't
save use (at least if we don't ignore the security of our users) from
adding notes in NEWS file and release notes.

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

2012-08-19 Thread Charles Plessy

Le Sun, Aug 19, 2012 at 11:13:23PM +0200, Gergely Nagy a écrit :
> Michael Biebl  writes:
> 
> > If those ports need a GR to silence any criticsm regarding those ports,
> > then something is going seriously wrong.
> 
> I've yet to see said criticism.

In the absense of regression tests, we distribute thousands of packages that
nobody knows if they work or not, because nobody ever used them.

Then one day they happen to fail to build, or regression tests are implemented
and crash, and suddenly the maintainer has to take care of development issues
that are not supported upstream nor by the porters.  Both are dedicating their
work to areas where they know that users and themselves will directly benefit
from their efforts.

Have you seen mobile phones running with Itanium processors, or was the Higgs
boson discoverd by analysing particule accelerator output with a farm of MIPS
boards ?  No.  We need to take this specialisation into account, be proud of
what our ports bring to their users, and be more open-minded about ignoring
combinations of softwares and architectures that were never designed to work
together. 

There is a simple heuristic to detect such cases, it is when the only help a
maintainer receives is guidance on how to ask for a login on the porter box and
fix the package himself.  If neither upstream, the users and the porters care,
then we need to provide to the maintainer some ways to ignore issues without
having to spend time on requesting architecture-specific archive removals, etc.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

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

Re: Possible release note for systems running PHP through CGI.

On Sun, 2012-08-19 at 22:32 +0200, Marco d'Itri wrote:
> I am also concerned that a *simple* solution to restore the old 
> behaviour in a secure way is not provided: maybe php5-cgi should install 
> a sensible default configuration in /etc/apache2/conf.d/ ?
Again, I don't think this saves us from the current need for a NEWS file
and release notes entry, but...

I've opened #685340, proposing:

a) a single php config file for Apache, that enables the MIME-Types (or
handlers)

b) but that does _not_ enable (Action and ScriptAlias directives) PHP
globally on the server.
I think this is unclean and not the best with regards to security.
Also not any possible vhost needs the mapping to /cgi-bin/.

The goal should be that sysadmins (or package maintainers) set the
Action and ScriptAlias directives in their config snippets...
But this is definitely something for jessie.

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Re: RFC: terminate init script when service is ready

2012-08-19 Thread Henrique de Moraes Holschuh

On Sun, 19 Aug 2012, Marco d'Itri wrote:
> On Aug 19, Henrique de Moraes Holschuh  wrote:
> > > But still, I agree that we should have a better way to signal to user 
> > > space when an interface is ready. Not just for IPv6, but also more 
> > We need better userspace glue, then.  Because the netlink interface to
> > the kernel network core and IP stack has existed for ages.  FreeBSD has
> Correct. With an event-driven init system it should be simple to write 
> a bridge which will translate netlink events, deal with delays, etc.

I suppose.  Maybe startpar or openrc can be enhanced like that (to replace
sysv-rc), and it should be trivial to do it in a way systemd will also grok.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20120819233147.gb8...@khazad-dum.debian.net

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

Hi Stephan.

On Sun, 2012-08-19 at 19:35 +0200, Stephan Seitz wrote:
> I don’t use NM, but I have it installed (you mentioned the dependencies).  
> I have a „exit 0” in the init script, so NM won’t be started.
Yeah,... or just disable it but then what's the point on it?! I mean
the basic idea of NM or what it should be (high level interface for
users and software to control networking and determine the status) is a
good one..


And to some extent I hate to be required to install dead code, just to
fulfil some deps.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

Hi Marco.

On Sun, 2012-08-19 at 19:41 +0200, Marco d'Itri wrote:
> NM, as a design goal, is not supposed to be able to manage every 
> possible configuration.
Well but then it shouldn't be kind of a default package. And yes, I
know, strictly speaking it's neither required nor essential.
But as I mentioned before, more and more uses it... and one usually
get's it already with gnome-core.

After all, isn't Debian the "Universal Operating System" ... or is it
the "works with only one scenario OS" ;-) 

And to be honest, I don't think that it's impossible that NM would
integrate well with ifupdown (and the others).
Don't take it personal (and I guess neither should even the NM
developers)... but saying "it's not intended to such complex stuff"
sounds sometimes like an excuse.

> > Or will we just mothball ifupdown silently and slowly (as it's replaced
> > by NM).
> As explained, NM is not a general ifupdown replacement.
Ok,... but e.g. on a laptop it's very useful (easily selecting any
wireless networks and such)... but as I outlaid above it more or less
breaks ifupdown and doesn't work quite well with some others... so if I
not only want to go online with my laptop, but do a little more,... I'm
already screwed.

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

Please take over the netconf project and start implementing that
design in C, that would be much more productive than any new thread
about the current and previous deficiencies of NetworkManager.

http://web.archive.org/web/20100109113017/http://netconf.alioth.debian.org/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

2012-08-19 Thread Chris Knadle

On Sunday, August 19, 2012 13:26:46, Christoph Anton Mitterer wrote:
> Hey.
> 
> I hope this won't become too much of a rant, but IMHO we long ago
> crossed the point where something (well actually many things) would have
> needed to be seriously done.
> My grandparents always warned me about UNIX programs written in capital
> letters ;-).
> 
> 
> Seriously... I have nothing against a high level daemon that manages
> underlying network control systems (ifupdown, vpnc, ppp, strongswan,
> openswan, openvpn) but not the way NM does it, especially as it doesn't
> work correctly at all edges and ends.
> 
> Until "recently" all that wasn't a big problem, because one was easily
> able to simply not install NM, but nowadays more and more packages start
> to depend on it (of those I know, most notably gnome-core) or at least
> use it's functionality to determine whether one is online or not.
[…]

The first suggestion I have is to look at Wouter Verhelst's 'ipcfg' project 
[1], which he gave a talk about on the last day of DebConf12 [2], and which is 
currently a work-in-progress, thus making it a good time for this kind of 
input.  His plan for the project addresses many of the typical complaints 
about NM, as well as other network managers, and I think he's got some very 
interesting ideas and thoughts about the problems you've described.

Related note: I likewise repeatedly have confusion over how to deal with 
testing Network Status from within shell scripts for doing operations that 
require network access.  As a "for instance" a common suggestion for keeping 
GPG keys up to date is to set a 'gpg --referesh-keys' operation as a cron job, 
which doesn't make sense to do if the device the script is run on is offline, 
especially if you want to log the output from the command.  The conclusion 
I've come to is that there needs to be a standard way for programs in Debian 
to know whether the local environment has network access, but that right now 
this is something that doesn't currently exist and is also not covered in 
Debian Policy.  :-(

I've likewise repeatedly been frustrated by packages that try to pull in NM as 
a dependency, and there has been repeated discussion here in [debian-devel] on 
this topic as well.  I've used NM, learned to hate it, and today absolutely 
refuse to allow it to be installed.  Reason: I too tried the "solution" of 
"just disable it in the startup script" just to have THAT bite me in the ass 
every time NM gets upgraded.  I'd personally like to see the NM package in 
Debian come with an /etc/default/network-manager file [like wicd has] so that 
a user has a way of disabling NM in a way that won't get "fixed" upon 
upgrades.  Until then, when it comes to my own systems, it and any package 
that depends on it looses.  [Come to think of it, the right thing for me to do 
is to open up a Wishlist bug for this -- so I'll be doing that today.]

[1]  http://anonscm.debian.org/gitweb/?p=users/wouter/ipcfg.git

[2]  http://penta.debconf.org/dc12_schedule/events/953.en.html

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

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

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

On Mon, Aug 20, 2012 at 7:59 AM, Chris Knadle wrote:

> require network access. As a "for instance" a common suggestion for keeping
> GPG keys up to date is to set a 'gpg --referesh-keys' operation as a cron

I prefer this option for keeping my GPG keyring up to date:

http://packages.debian.org/sid/parcimonie

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

Hey Ben.


On Sun, 2012-08-19 at 19:32 +0100, Ben Hutchings wrote:
> To allow users to connect to the NetworkManager daemon they have to be in the
> group "netdev".
Like Vincent already pointed out, CK allows it, too.

In principle nothing speaks generally against either of the two, but I
guess both of them are just intended towards "who is allowed to connect
to networks"; either by being member of the group, or by being locally
logged on (CK).
But when I e.g. put WPA credentials into /e/n/interfaces and made the
file specifically readable by root and user foo only, then it still
exports that connection to all other users (e.g. being logged on
locally; at least per default).


> The capability to *use* credentials is separate from the capability to
> *read* the credentials.
Well nevertheless, both can be dangerous already, can't it?
Even if it just allows me to use (i.e. connect to) some WLAN but not
giving me the actual key, I might be able to access some resources
there, that ought to be secure.


> (Also, the design choice to read credentials from a file that is world-
> readable by default is incredibly stupid, and you may wish to report
> bugs on the packages that do that.)
I don't exactly understand what you mean :)


> > In my opinion, NM should:
> > - export any connections from the real canonical places
> > (e.g. /etc/network/interfaces, /etc/vpnc/*, /etc/ppp/peers/*
> > and /etc/chatscripts/*, /etc/ipsec.conf and /etc/ipsec.d/*, etc. pp.)
> > - only if a user doesn't find something there, a per user connection
> > configuration should be set up.
> > - I know, NM supports system wide configuration, too, but IMHO that
> > should be dropped altogether and NM should also not try to edit the real
> > canonical configuration.
> > If someone want's a system wide IPsec connection, that should e.g. go to
> > strongswan's /etc/ipsec.conf.
> 
> You seem to be asking for an awful lot of integration work within NM
> itself, which means divergence from upstream.

Well... yes ^^ ... but actually I don't want to have this in Debian
only.
As said, I've opened bugs for most of the above, e.g. proper integration
of /etc/vpnc/* config into NM's vpnc plugin.

It may however be reasonable, if the ifupdown plugins was really managed
by Debian (developers) and not by some upstream developers who may or
may not have the in depth knowledge to the Debian way of life.


> ifupdown *was* a good framework, but Linux moved on.  ifupdown doesn't
> know anything about interface state.
What exactly do you mean by "state"?

But anyway,.. it doesn't seem as if it would go away anytime soon,...
and NM is AFAICS surely not a powerful enough replacement.


> It doesn't know whether hooks
> succeeded and it can't check for failures because that would be an
> incompatible change (#547587).
Sometimes one have to break compatibility ;-)


> > d) when I disable wireless in NM it really blocks it, so I can't use it
> > with ifupdown. Now one can rfkill unblock then... but why? and even if
> > one does...NM seems to get confused again.
> If you say 'disable wireless', why are you surprised that it does what
> you say? I think it uses rfkill because that may save more power.
Ah is that the case? Didn't know.
Nevertheless, it seems to not handle it correctly when I manually change
things or stop/start NM and things like that.


> I don't think this is the direction upstream is going in.  Instead, it's
> adding more support for advanced setups.
Well even if they do,... to me it seems that every distro keeps it's own
native way of controlling networking and canonical configuration for it.
Trying to duplicate this in NM is IMHO a bad way.


> I would really like to see Debian developers working to improve Network
> Manager so it can replace ifupdown.  For example, improving the command
> line interface and support for various types of software devices.
> Unfortunately, I don't have the spare time to make much of a
> contribution to that myself.  (I do install ifupdown hooks as part of
> ethtool, so I'll have to think about those.)
If all that ever happens,... fine (though I like ifupdown and personally
don't see the need for replacing it),... but it's surely a long road to
it and has the big disadvantage that we (Debian) are then more or
less bound to what NM (and other distros) do.
Sometimes it's good of course, having homogeneous frameworks across
distros,... but this can also be bad.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

2012-08-19 Thread Michael Biebl

On 20.08.2012 02:07, Christoph Anton Mitterer wrote:

> But when I e.g. put WPA credentials into /e/n/interfaces and made the
> file specifically readable by root and user foo only, then it still
> exports that connection to all other users (e.g. being logged on
> locally; at least per default).

That is simply not true.
NM doesn't by default export any WPA secrets in /e/n/i to any user.
I'm not sure if you don't know any better or if you just want to spread FUD.

Michael

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

signature.asc
Description: OpenPGP digital signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

Dear Michael.

On Mon, 2012-08-20 at 02:13 +0200, Michael Biebl wrote:

> That is simply not true.
> NM doesn't by default export any WPA secrets in /e/n/i to any user.
> I'm not sure if you don't know any better or if you just want to spread FUD.
I specifcally wrote "export _connection_" and not "credentials"...
meaning that it allows to open a connection, that might be intednded to
be usable by only some users ...and I also gave some ideas that even
that could be an issue

So no,... don't want to spread FUD ;)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Possible release note for systems running PHP through CGI.

2012-08-19 Thread Henrique de Moraes Holschuh

On Sun, 19 Aug 2012, Marco d'Itri wrote:
> On Aug 19, Charles Plessy  wrote:
> >  - PHP scripts can be executed by Apache httpd through libapache2-mod-php5 
> > or
> >php5-cgi.  Debian recommends libapache2-mod-php5, but there are still
> This is another issue which concerns me, since mod_php forces the use of 
> preforking apache, which means that the server will either stop serving 
> pages or OOM at the first hint of real traffic.
> (And obviously mod_php is wildly insecure for multitenants servers.)

You need php-cgi with something like fcgid to have it properly isolate
several web applications and still be somewhat scalable.  mod-php is
just a toy in its current state, good enough to run stuff at home as
long as it is restricted to localhost...

> >thousands of installations wich report the use of php5-cgi according to 
> > the
> >Popularity Contest statistics.
> Yes, because sensible people who need PHP will try to use it as 
> CGI/FastCGI (or FPM, finally in wheezy).

Indeed.

> I am also concerned that a *simple* solution to restore the old 
> behaviour in a secure way is not provided: maybe php5-cgi should install 
> a sensible default configuration in /etc/apache2/conf.d/ ?

That, and leave mime.types alone.  If the problem is caused by mod-php
under apache, any "simple solution" should be biased towards breaking
mod-php under apache, not everything else.  A good solution would not
break anything.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20120820004115.gc8...@khazad-dum.debian.net

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

2012-08-19 Thread Michael Biebl

On 20.08.2012 02:18, Christoph Anton Mitterer wrote:
> On Mon, 2012-08-20 at 02:13 +0200, Michael Biebl wrote:
>> That is simply not true.
>> NM doesn't by default export any WPA secrets in /e/n/i to any user.
>> I'm not sure if you don't know any better or if you just want to spread FUD.
> I specifcally wrote "export _connection_" and not "credentials"...
> meaning that it allows to open a connection, that might be intednded to
> be usable by only some users ...and I also gave some ideas that even
> that could be an issue

Apparently it is still not clear to you: NM by *default* does not export
any wireless connections from /e/n/i to *any* user by the simple fact
that managed=false by *default*.

> So no,... don't want to spread FUD ;)

So my inital point still stands.

In your first paragraph you write "I hope this won't become too much of
a rant"
What follows is a lot of misconceptions and biased views and you
conclude with "Will we continue to live with the current disease?".

I won't bother following up as I'm really tired of all this BS on
debian-devel regarding NM lately. Sorry.
My guess is, that this will be another of those pointless NM bashing
threads, where nothing useful comes out of it. Actually I'm not sure
what the point of this thread is, but it definitely managed to piss me
off, the maintainer of network-manager, and I'm not going to further
participate.

Michael

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

signature.asc
Description: OpenPGP digital signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

On Mon, 2012-08-20 at 02:41 +0200, Michael Biebl wrote:
> Apparently it is still not clear to you: NM by *default* does not export
> any wireless connections from /e/n/i to *any* user by the simple fact
> that managed=false by *default*.
Well ok... but that's what one needs to set when one at least somehow
want's to use both NM and ifupdown. Or did I understand wrong that NM
ignores any interfaces mentioned in /e/n/i, if managed=false?


> What follows is a lot of misconceptions and biased views and you
> conclude with "Will we continue to live with the current disease?".
Well I guess by reporting tickets against the package and upstream, with
things that IMHO should work differently and ideas for enhancement I
made clear enough that I don't simply hate it or so, but want to improve
it..
If you, as maintainer, feel/felt offended, than I'm really sorry and
apologize,... that wasn't my intention; if it were I would have disabled
NM at my system, saved some hours of writing ideas for improvements, and
started lobbying around at all different packages, to drop NM support.

And the "disease" is not NM iself (at least not in my opinion) it's
rather the improper integration of NM with the "native"
tools/configuration.


After all, if NM's integration with ifupdown and the other native tools
(ppp, vpnc, strongswan, etc.) and their configuration would be as good
as I'd like to see it, then most if not all reasons for NM bashing would
fall away.
Because even if NM continues it's philosophy of begin a replacement for
these "native tools",... no could largely complain anymore when both are
well integrated and can just happily co-exist.


>> So no,... don't want to spread FUD ;)
> So my inital point still stands.
Well,... forgive me if I don't always know all lines of the code and the
details behind them.
I just think I have a valid use case (want to use both, ifupdown and NM
well integrated),... and this leads to all kinds of problems.
Assuming that I'm not totally stupid, I came to the conclusion that
there might be issues.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

2012-08-19 Thread Guillem Jover

On Sun, 2012-08-19 at 22:02:47 +0200, Vincent Bernat wrote:
> But also:
> 
>   Alternatively you can install the "consolekit" package which will
>   grant access for all locally logged in users.

ConsoleKit has already been dropped and deprecated by upstream:

  

regards,
guillem


-- 
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/20120820020757.ga2...@gaara.hadrons.org

Re: Enabling uupdate to simply remove files from upstream source

2012-08-19 Thread Guillem Jover

Hi!

On Sun, 2012-08-19 at 10:35:17 -0700, Russ Allbery wrote:
> get-orig-source:
>   git archive --remote='$(REPO)' --prefix='openafs_$(DEBVERS).orig/' \
>   --format=tar '$(TAG)' | tar xf -
>   rm -r openafs_$(DEBVERS).orig/src/WINNT
>   tar cf openafs_$(DEBVERS).orig.tar openafs_$(DEBVERS).orig
>   rm -r openafs_$(DEBVERS).orig
>   gzip -9 openafs_$(DEBVERS).orig.tar

Just a small off-topic tangent :), but this could be slightly optimized
with something like (untested):

git archive --remote='$(REPO)' --prefix='openafs_$(DEBVERS).orig/' \
--format=tar '$(TAG)' | \
tar --delete openafs_$(DEBVERS).orig/src/WINNT | \
gzip -9 > openafs_$(DEBVERS).orig.tar.gz

regards,
guillem


-- 
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/20120820021622.gb2...@gaara.hadrons.org

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

2012-08-19 Thread Chris Knadle

On Sunday, August 19, 2012 20:41:47, Michael Biebl wrote:
[…]
> I won't bother following up as I'm really tired of all this BS on
> debian-devel regarding NM lately. Sorry.
> My guess is, that this will be another of those pointless NM bashing
> threads, where nothing useful comes out of it. Actually I'm not sure
> what the point of this thread is, but it definitely managed to piss me
> off, the maintainer of network-manager, and I'm not going to further
> participate.

I'm sorry you're feeling hurt from the NM criticism.  I'm confident that 
nobody had any intent of hurting your feelings.

Whatever opinions I or others my have about NM are about the software is 
mostly about the software that comes from upstream -- which has nothing to do 
with you directly, so /please/ try not to take this personally.  Also this 
thread started mainly about *other* packages that pull in network-manager as a 
dependency, which doesn't even have to do with the network-manager package 
itself.  NM is just one part of a larger "meta issue" going on concerning 
coordination /between/ various packages.

There's a natural tendency to have an emotional attachment and pride one's 
work.  In the case of Debian packaging the maintainer gets to have a lot of 
input on how the package gets installed and might have /some/ control over the 
software's default behavior, but to a large extent it seems to me the 
maintainer only has minimal control over how the software actually works, 
because that comes from upstream and it's specifically /not/ the packager's 
task to implement major design changes to it.

I therefore think taking criticism about the /software itself/ that a 
maintainer packaged /personally/ is a harsh self-judgment, especially if 
there's not much a maintainer can actually /do/ about the perceived design 
failings that the software might have.  This reminds me of the the "Serenity 
Prayer" [1] mantra used during meetings of Alcoholics Anonymous (AA).

The part of this that I think is non-obvious is that one's emotions and 
reaction are actually a choice.  For instance, my experience is that if 
someone outright criticizes me directly with the obvious intent of /trying/ to 
hurt my feelings, /that/ is often far easier to dismiss than if someone 
criticizes the output of my efforts /without/ any obvious intent to make it 
hurt.  This is a good thing as otherwise I would be allowing someone else to 
/control/ my emotions and my reaction.  But the extension of this is even more 
interesting -- that I am /responsible/ for my emotions as as well as my 
reaction, because they are both my choice.  (There's an interesting 10-minute 
video [2] discussing some of these issues which I think is worth watching.)

Finally, I want to make it clear that none of the above is meant as criticism 
of any kind -- it's meant purely as an attempt to help.

[1] https://en.wikipedia.org/wiki/Serenity_Prayer

[2] https://www.youtube.com/watch?v=AhgtGFPTeMY

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

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

Re: Misc Developer News (#30)

2012-08-19 Thread Samuel Kerr

On 8/18/12, Paul Wise  wrote:
> The news are collected on http://wiki.debian.org/DeveloperNews
> Please contribute short news about your work/plans/subproject.
>
> In this issue:
>  + Report from DSA Team Sprint
>  + Using RAM for temporary files ?
>  + Control Commands at sub...@bugs.debian.org time
>  + Debian Maintainer Dashboard
>  + Declaring media (MIME) types with FreeDesktop menu entry files
>
> Report from DSA Team Sprint
> ---
>
>  The Debian System Administrators met for a sprint in Oslo, Norway. Luca
>  Filipozzi sent a report[1] about their activities at the sprint. The
>  goals of the meeting were to develop a long term plan for Debian's
>  infrastructure, to review the current set of machines we maintain and the
>  services we provide, and to formulate some policies and procedures
>  regarding account and group management.
>
>  They aim to ensure that all Debian hardware is no more than 5 years old
>  at any one time and hope to improve Debian donations and financial
>  contributions in order to support that. They are moving towards using
>  virtual machines for most services, consolidating our hosting locations
>  and adding disaster mitigation through geographically-distributed service
>  redundancy. They are starting a new Debian CDN for the distribution of
>  static content such as the Debian website and Planet Debian. They have
>  recently deployed a SSO solution for debian.org web based services. They
>  will also be locking inactive shell accounts and adding easy ways to
>  unlock them and monitoring the use of group memberships.
>
>   -- Paul Wise
>
>  [1] http://lists.debian.org/20120320012015.ga19...@emyr.net
>
> Using RAM for temporary files ?
> ---
>
>  As a result of ground work to use virtual filesystems for some
>  directories containing temporary files, it is easier to mount /tmp on
>  tmpfs. A long discussion about the default location (on RAM or on disk)
>  took place on the debian-devel mailing list, which is summarised in a
>  couple of posts and on LWN.
>
>  - Final decision on defaulting to disk:
>http://lists.debian.org/debian-devel/2012/06/msg00028.html
>
>  - Summary from the person who started the thread:
>http://lists.debian.org/debian-devel/2012/06/msg00311.html
>
>  - Rebuttal: http://lists.debian.org/debian-devel/2012/06/msg00318.html
>
>  - Article on LWN: https://lwn.net/Articles/499410/
>
> Control Commands at sub...@bugs.debian.org time
> ---
>
>  You can now use control commands at sub...@bugs.debian.org time in the
>  pseudo-headers. An example is the following:
>
>  Package: foo
>  Severity: normal
>  Control: retitle -1 a bug, a bug, a buggy bug
>  Control: tag -1 moreinfo help
>
>  See pseudo header control commands[2], my blog post[3], and the
>  DebConf12 lighting talk[4] for more information.
>
>   -- Don Armstrong
>
>  [2] http://www.debian.org/Bugs/Reporting#control
>  [3] http://www.donarmstrong.com/posts/control_at_submit/
>  [4] http://penta.debconf.org/dc12_schedule/events/900.en.html
>
> Debian Maintainer Dashboard
> ---
>
>  Debian Maintainer Dashboard[5] aims at gathering various kind of
>  information useful to maintainers and teams. In addition to the usual
>  information about packages versions, bug counts, etc., it exposes a list
>  of TODO items (RC bugs to fix, missing builds, testing migration issues,
>  new upstream releases etc). DMD gets all the data from the Ultimate Debian
>  Database.
>
>   -- Lucas Nussbaum
>
>  [5] http://udd.debian.org/dmd.cgi
>
> Declaring media (MIME) types with FreeDesktop menu entry files
> --
>
>  The package mime-support version 3.53~experimental1[6] was uploaded in
>  experimental. It implements the parsing of .desktop files to generate
>  mailcap entries, thanks to a patch[7] from Brian M. Carlson. This will
>  allow to de-duplicate media type information in packages containing
>  FreeDesktop menu entry files.
>
>   -- Charles Plessy
>
>  [6]
> http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git;a=commitdiff;hp=3.52-1;h=3.53_experimental1
>  [7] http://bugs.debian.org/497779
>
> --
> bye,
> pabs
>
> http://wiki.debian.org/PaulWise
>

-- 
Sent from my mobile device


-- 
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/CAKHivZK=ywnwkksj-v3tgybrbue2dpunschbhk1p0moq+qj...@mail.gmail.com

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning