Re: Dreamhost dumps Debian

[Vincent Bernat]

 ❦ 20 août 2013 02:04 CEST, Charles Plessy  :

>> Just to say that Debian usually has a 3 year support.
>
> Hi Vincent,
>
> this actually misleading for systems that have a long lifetime, where the
> turnover matters more, and in Debian it is 2 years.  In some workplaces It
> means that every second year, some people would have to discuss and reach an
> agreement on whether it is doable to upgrade a service, how much it will cost,
> or should it be discontinued or not, etc.  There, the 5-year or longer 
> turnover
> in Ubuntu or CentOS is a winning point.

I don't get the point. If we compare to 5-year, then Debian is
3-year. Ubuntu just defines its turnover to 5 years while we say next
release plus one year which is usually 3 years.

> A long term support for core packages would definitely help me to advocate
> Debian in my workplace (and therefore use it on our servers instead of 
> CentOS).
> Also, I do not think that it is relaxing our standards, since it is an
> additional service: there is no reduction in the current support.

I would also welcome such a thing. But, we seem to not have the needed
resources.
-- 
Use debugging compilers.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Bug#720294: ITP: puppet-module-puppetlabs-vswitch -- Puppet module for vSwitches

[Bastian Blank]

On Tue, Aug 20, 2013 at 08:43:13AM +0200, Thomas Bechtold wrote:
>  Puppet lets you centrally manage every important aspect of your system
>  using a cross-platform specification language that manages all the
>  separate elements normally aggregated in different files, like users,
>  cron jobs, and hosts, along with obviously discrete elements like
>  packages, services, and files.
>  .
>  Puppet's simple declarative specification language provides powerful
>  classing abilities for drawing out the similarities between hosts while
>  allowing them to be as specific as necessary, and it handles dependency
>  and prerequisite relationships between objects clearly and explicitly.

A lot of boilerplate.

>  This package contains a Puppet module for vSwitches.

Almost nothing about the module itself. Please extend this. At least
specify what a vswitch is and which implementations it supports.

Bastian

-- 
Without followers, evil cannot spread.
-- Spock, "And The Children Shall Lead", stardate 5029.5


-- 
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/20130820075043.ga9...@mail.waldi.eu.org

Re: Dreamhost dumps Debian

[Ben Hutchings]

On Mon, 2013-08-19 at 23:48 -0400, Michael Gilbert wrote:
[...]
> Plus, Ben Hutchings is putting together a plan to add support for
> newer hardware in stable releases:
> http://lists.debian.org/debian-boot/2013/08/msg00090.html
> 
> Presumably, continuing to support newer hardware will improve the
> useful lifetime of releases.

That's just what we need now to support new hardware for the current 2
years after release (or rather 2.5 years after freeze).

I had no intention of enabling a longer release cycle; that just makes
our job harder.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates


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

overriding udev rules

[olivier sallou]

hi,
I need for a package to override some udev standard rules.

If I put an identical rule name in /etc/udev/rules.d, I know it overrides
the one in /lib/udev/rules.d


However, lintian raises an error if I put an udev rule in /etc instead of
/lib.
And if I try to put the file in /lib, it fails at install because the file
is owned by udev package.

This particular package is for use in virtual machines creation where
package removes default network persistence.

Is there an other way to override udev rules in package or should I simply
override the lintian error message?

Thanks

Olivier

-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: overriding udev rules

[Arto Jantunen]

olivier sallou  writes:
> hi,
> I need for a package to override some udev standard rules.
>
> If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> the one in /lib/udev/rules.d
>
>
> However, lintian raises an error if I put an udev rule in /etc instead of
> /lib.
> And if I try to put the file in /lib, it fails at install because the file
> is owned by udev package.
>
> This particular package is for use in virtual machines creation where
> package removes default network persistence.
>
> Is there an other way to override udev rules in package or should I simply
> override the lintian error message?

I think you should divert (see man dpkg-divert) the original file in
/lib and install a new file in it's place. This way the /etc override
mechanism is still usable by the admin if needed.

-- 
Arto Jantunen


-- 
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/87mwoc3fgd@kirika.int.wmdata.fi

Re: overriding udev rules

[Chow Loong Jin]

On Tue, Aug 20, 2013 at 10:39:13AM +0200, olivier sallou wrote:
> hi,
> I need for a package to override some udev standard rules.
> 
> If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> the one in /lib/udev/rules.d
> [...]
> Is there an other way to override udev rules in package or should I simply
> override the lintian error message?

Stick it in /lib/udev/rules.d/ prefixed with a higher number than the rules file
you want to override. This is described, along with more guidelines on picking a
number in /lib/udev/rules.d/README.

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Re: arm laptops and d-i

[Adam Borowski]

On Wed, Aug 14, 2013 at 01:07:35AM +0200, Cyril Brulebois wrote:
> Adam Borowski  (2013-08-14):
> > I loathe laptops, and thus didn't own one.  Needing one for DebConf (and
> > this time no friend had a working one for me to borrow), instead of getting
> > an used x86 one, I bought a $150 13.3" android thing.  Because, you know,
> > installing a certain universal operating system should be easy, especially
> > if it's a popular SoC (Allwinner) and graphics chip (Mali 400), right?
> > Oh naive me.

[...]

> Also, thanks for the “why the hell isn't shiny new hardware working out
> of the box” attitude.

"It doesn't work.  This sucks.  It should!" is just the attitude we need,
because it's the first step to actually fixing things.


So, let's gather the results of discussions (plus some recap):

d-i is not popular on arm because most devices get installed a different way:
* N900 and others get flashed over USB
* raspi, hardkernel and others can have their "disk" plucked out and written
  to on another machine
* Omega Oan needs a bootable SD image: d-i, live CD, a recovery image of
  some kind.  You just plop the card in.
* Samsung Chromebook needs substantial effort to even boot from outside
  media, no idea if you can make it use the internal disk.

So I'm not sure how much interest there would be in getting d-i to work.
Perhaps Wookey or someone could tell us about upcoming devices.  It'd be
possible to make the Omega work just the same as on x86, the question is
whether it's worth the effort.  I for one am back, far from having to deal
with blasted laptops which greatly reduces the motivation, I have no skills
related to d-i either.  There are other users to think of, though, and
leaving a device not hacked enough goes against the principles.

So, here are the problems:
1. working kernel
2. booting d-i
3. partitioning the nand
4. making the nand bootable
5. misc device-specific setup

1.:
It looks like Allwinner support in 3.11 kernels is not that good yet, no
idea if it's enough.  If not, linux-sunxi kernels could be used in the
interim, but only for testing -- I don't see per-SoC kernel trees getting
into Debian, for good reasons.

2.:
Old kernels need a separate vfat partition for booting, and "fex" data with
a description of the device in question.  Not nice.  I heard that new uboot
can boot directly from ext4.

3.:
If that new uboot can cope with it, using nand as a yet another block device
in place of /dev/sda might be straightforward.  If not, creating the boot
partition is probably no rocket surgery, but well outside what I know about
d-i.

4.:
Making the final system bootable is another big piece.  Again, I know to
edit what I found on the android disk, but not to configure it for arbitrary
devices, because of fex.  Can new kernels just autodetect stuff?

5.:
Requiring specific steps for particular pieces of hardware (like enabling
a module named "led" here) is nothing new.


So... this is way too much for me to handle personally, so I'm afraid I
can't really volunteer here, other that minor parts, and, of course,
testing.  At least problem areas have been identified, though.  If you need
me, I'll be in the "UTF-8 everywhere" land for now :)

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130820092751.ga25...@angband.pl

Re: overriding udev rules

[Michael Biebl]

Am 20.08.2013 10:39, schrieb olivier sallou:
> hi,
> I need for a package to override some udev standard rules.
> 
> If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> the one in /lib/udev/rules.d
> 
> 
> However, lintian raises an error if I put an udev rule in /etc instead of
> /lib.
> And if I try to put the file in /lib, it fails at install because the file
> is owned by udev package.
> 
> This particular package is for use in virtual machines creation where
> package removes default network persistence.

Could you elobarate why you need that?
The persistent network interface naming rules are already skipped if
udev is run within a virtual machine.
Might be better to just fix udev if it doesn't work in your case.
For that, it would be good to know more about your problem / use case.

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: overriding udev rules

[Bastian Blank]

On Tue, Aug 20, 2013 at 10:39:13AM +0200, olivier sallou wrote:
> I need for a package to override some udev standard rules.

Well. This would be not suitable for a package in Debian itself.

> However, lintian raises an error if I put an udev rule in /etc instead of
> /lib.

lintian is moot for private packages.

> This particular package is for use in virtual machines creation where
> package removes default network persistence.

Use local administered MAC addresses. udev properly ignores them.

> Is there an other way to override udev rules in package or should I simply
> override the lintian error message?

You should neither. You have to fix the real problem.

Bastian

-- 
Without facts, the decision cannot be made logically.  You must rely on
your human intuition.
-- Spock, "Assignment: Earth", 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/20130820101807.gb9...@mail.waldi.eu.org

Re: Dreamhost dumps Debian

[Paul Wise]

On Mon, Aug 19, 2013 at 10:50 PM, Russ Allbery wrote:

> ...change anything about their model.  However, as a Debian Developer, I
> would be extremely uncomfortable about having tiers of security support
> for our packages were we to try to duplicate something like LTS.

We are already no longer supporting iceweasel in squeeze:

http://www.debian.org/security/2013/dsa-2735

At one point we stopped supporting clamav in oldstable:

http://www.debian.org/security/2008/dsa-1497

At one point there was an experiment to express the lack of security
support for specific packages using debtags. This seems to have been
dropped but you can see that sql-ledger and kfreebsd weren't supported
at one point:

http://debtags.alioth.debian.org/tagindex/secteam.html
https://lists.alioth.debian.org/pipermail/debtags-devel/2008-June/001795.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436161

-- 
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/CAKTje6ECtg-3tOaBa4bZujtwJpXAuth2ui1_25PnmQJ0=7j...@mail.gmail.com

Re: Dreamhost dumps Debian

[Steve Langasek]

On Mon, Aug 19, 2013 at 11:48:13PM -0400, Michael Gilbert wrote:
> > Russ already replied and I agree with its reply. Just to say that Debian
> > usually has a 3 year support. This is the kind of misguiding that I
> > usually hear when people promotes Ubuntu over Debian.

> I know already that this isn't a popular idea, but another option
> would be to release less often.  If releases were every 3 years, then
> the support window would be 4 years, which almost gets to the apparent
> sweet spot of 5.

I think the more useful option would be for Debian to figure out how to
lengthen its security support window instead.

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


signature.asc
Description: Digital signature

Re: Dreamhost dumps Debian

[Paul Wise]

There are also a number of packages that have no support or limited
support in squeeze/wheezy:

http://anonscm.debian.org/viewvc/secure-testing/data/package-tags?view=markup

-- 
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/CAKTje6GJYae5f=9ej-=8ytwqeuu2s91spujrd66g6iw7mdr...@mail.gmail.com

Re: Dreamhost dumps Debian

[Pau Garcia i Quiles]

On Tue, Aug 20, 2013 at 12:46 PM, Steve Langasek  wrote:

> On Mon, Aug 19, 2013 at 11:48:13PM -0400, Michael Gilbert wrote:
> > > Russ already replied and I agree with its reply. Just to say that
> Debian
> > > usually has a 3 year support. This is the kind of misguiding that I
> > > usually hear when people promotes Ubuntu over Debian.
>
> > I know already that this isn't a popular idea, but another option
> > would be to release less often.  If releases were every 3 years, then
> > the support window would be 4 years, which almost gets to the apparent
> > sweet spot of 5.
>
> I think the more useful option would be for Debian to figure out how to
> lengthen its security support window instead.
>

Agreed.

I know many companies that see Ubuntu's non-LTS releases as release
candidates with real-world testing and LTS's as stable releases. That's why
Ubuntu is successful: when a company picks an LTS, they perceive it as
something that has been properly stabilized (although often times it's not
true, e. g. Mir in the next LTS).

Maybe we should adopt a similar model:
- Stable release every 12-18 months to avoid shipping rotten software
- Alternate releases are LTS
- LTS releases get 4-5 years support (to determine)
- Non-LTS releases get 6 months support after the release of the next LTS
version
- LTS overlap in support for at least 1 year to give users ample time to
move to the next LTS


E. g:
- In January 2014 we release Debian 8.0. We make this an LTS release,
meaning it would get updates for, say 3 years (until January 2017), and
security updates for 5 years (until January 2019).
- In February 2015 we release Debian 9.0. Non-LTS release. It will get at
least 1 year of support (because we won't release the next version until at
least 1 year later) + 6 months
- In April 2016 we release Debian 10.0. LTS release. It will get again 3
years of updates and 5 years of security updates. This means support for
Debian 9.0 will end in October 2016 (LTS release date + 6 months)
- ...



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

Re: arm laptops and d-i

[Andrea Bolognani]

On Wed, Aug 14, 2013 at 12:54:27AM +0200, Adam Borowski wrote:

> It took me way too much time to figure it out, and I'm not exactly a
> Debian newbie (although no experience with laptops or arm bootloaders). 

Hi,

I understand that, while it took you quite a bit of effort, you managed
to run Debian on the thing after all.

Did you collect notes? I can't seem to find a page dedicated to the
device on the Debian Wiki[1], and no result shows up on Google. Would you
mind contributing the procedure you've followed, so that other interested
individuals can get Debian running with a reasonable amount of effort?

Thank you.


[1] https://wiki.debian.org/InstallingDebianOn/
-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: Digital signature

Re: Dreamhost dumps Debian

[Scott Kitterman]

Paul Wise  wrote:
...

>At one point we stopped supporting clamav in oldstable:
>
>http://www.debian.org/security/2008/dsa-1497
...

That, at least, is unlikely to be repeated. Upstream does a much better job of 
maintaining a consistent API and ABI compatibility these days.  

Scott K


-- 
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/7a8f320e-9d15-4707-aec7-b27cef978...@email.android.com

Re: overriding udev rules

[Marco d'Itri]

On Aug 20, olivier sallou  wrote:

> This particular package is for use in virtual machines creation where
> package removes default network persistence.
Please explain what you are actually trying to achieve.

> Is there an other way to override udev rules in package or should I simply
> override the lintian error message?
Packages MUST NOT install files in /etc/udev/rules.d/ .

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#720326: ITP: dualword-index -- Xapian index viewer...

[Alexander Busorguin]

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

* Package Name: dualword-index
* Home page: http://dualword.org
* License: GPLv3
* Description: Xapian index viewer.


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

Bug#720327: ITP: esu -- It allows to copy files with different checksums on the fly.

[root]

Package: wnpp
Severity: wishlist
Owner: Eun 

* Package name: esu
  Version : 1.01
  Upstream Author : Eun 
* URL : https://github.com/Eun/ecp
* License : GPLv3
  Programming Lang: C
  Description : It allows to copy files with different checksums on the fly.

Basicly a replacement for cp with additional checksum on the fly support.
It allows MD5, SHA1, SHA224, SHA265, SHA384, SHA512 algorithm to be used.


-- 
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/20130820133306.14692.36296.report...@sd-27422.dedibox.fr

Re: Bug#720327: ITP: esu -- It allows to copy files with different checksums on the fly.

[Ryan Kavanagh]

On Tue, Aug 20, 2013 at 03:33:06PM +0200, root wrote:
> * Package name: esu
>   Description : It allows to copy files with different checksums
> on the fly.
> 
> Basicly a replacement for cp with additional checksum on the fly
> support.  It allows MD5, SHA1, SHA224, SHA265, SHA384, SHA512
> algorithm to be used.

How is this different from rsync? Quoting rsync(1):

   Rsync is a fast and extraordinarily versatile file  copying
   tool.   It can  copy  locally,  to/from  another  host  over
   any remote shell, or to/from a remote rsync daemon.
   [...]
   -c, --checksum  skip based on checksum,
   not mod-time & size

Best wishes,
Ryan

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


signature.asc
Description: Digital signature

Re: Dreamhost dumps Debian

[Ian Jackson]

Charles Plessy writes ("Re: Dreamhost dumps Debian"):
> However, one difficulty that was not mentionned in this thread is that if we
> aim at both long term support and frequent releases, then we need to support
> users skipping releases or upgrading multiple releases in a row.

I have done skip upgrades on multiple occasions.  The fallout was
always manageable.  (The most recent one was etch->squeeze IIRC.)

Ian.


-- 
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/21011.32310.864168.568...@chiark.greenend.org.uk

Re: Bug#720327: ITP: esu -- It allows to copy files with different checksums on the fly.

[Eun]

The difference is that ecp generates the checksum on the fly, this means it
is faster then rsync,
rsync copy's first and compares the sum of the source and destination
afterwards (4 operations).
esu saves one operation by calculating the checksum during reading the file.

to make it clearer:

rsync:
1. read srcfile
2. write dstfile
3. checksum of src
4. checksum of dst

ecp:
1. read srcfile, checksum of src
2. write dstfile
3. checksum of dst



2013/8/20 Ryan Kavanagh 

> On Tue, Aug 20, 2013 at 03:33:06PM +0200, root wrote:
> > * Package name: esu
> >   Description : It allows to copy files with different checksums
> > on the fly.
> >
> > Basicly a replacement for cp with additional checksum on the fly
> > support.  It allows MD5, SHA1, SHA224, SHA265, SHA384, SHA512
> > algorithm to be used.
>
> How is this different from rsync? Quoting rsync(1):
>
>Rsync is a fast and extraordinarily versatile file  copying
>tool.   It can  copy  locally,  to/from  another  host  over
>any remote shell, or to/from a remote rsync daemon.
>[...]
>-c, --checksum  skip based on checksum,
>not mod-time & size
>
> Best wishes,
> Ryan
>
> --
> |_)|_/  Ryan Kavanagh   | Debian Developer
> | \| \  http://ryanak.ca/   | GPG Key 4A11C97A
>

Re: Dreamhost dumps Debian

[Adam Borowski]

On Tue, Aug 20, 2013 at 03:33:26PM +0100, Ian Jackson wrote:
> Charles Plessy writes ("Re: Dreamhost dumps Debian"):
> > However, one difficulty that was not mentionned in this thread is that if we
> > aim at both long term support and frequent releases, then we need to support
> > users skipping releases or upgrading multiple releases in a row.
> 
> I have done skip upgrades on multiple occasions.  The fallout was
> always manageable.  (The most recent one was etch->squeeze IIRC.)

Why wouldn't you instead:
sed -i s/etch/lenny/ /etc/apt/sources.list
apt-get dist-upgrade
sed -i s/lenny/squeeze/ /etc/apt/sources.list
apt-get dist-upgrade

This costs some machine time, yeah, but to solve that "fallout" costs human
time which is in most cases far more expensive.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130820145339.ga2...@angband.pl

Re: jessie release goal: verbose build logs

[Ian Jackson]

(Resending; first copy failed due to MIME non-8-bit-cleanliness damage.)

Joey Hess writes ("Re: jessie release goal: verbose build logs"):
> I've attached a simple proof of concept you can try it out with building
> your own packages.  For example:
> 
>dpkg-buildpackage | ssh
> 
> (The implementation needs to be improved; it should read both stdout and
> stderr and multiplex them properly. And it should check if stdout is not
> to a TTY, and if so avoid munging the build log output. The only other
> problem is that `make` outputs the lines it runs to stderr and so those
> continue to pollute the build display.)

I like the idea, but you need to make this an adverbial command, not a
pipe thing.  This is so that if you _aren't_ \r-mangling, you can pass
dpkg-buildpackage the same actual fd for both stdin and stdout, so
that the interleaving of stdout and stderr is correct.

Ian.


-- 
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/21011.33534.616618.445...@chiark.greenend.org.uk

Re: Bug#720327: ITP: esu -- It allows to copy files with different checksums on the fly.

[Konstantin Khomoutov]

On Tue, 20 Aug 2013 10:21:05 -0400
Ryan Kavanagh  wrote:

> On Tue, Aug 20, 2013 at 03:33:06PM +0200, root wrote:
> > * Package name: esu
> >   Description : It allows to copy files with different checksums
> > on the fly.
> > 
> > Basicly a replacement for cp with additional checksum on the fly
> > support.  It allows MD5, SHA1, SHA224, SHA265, SHA384, SHA512
> > algorithm to be used.
> 
> How is this different from rsync? Quoting rsync(1):
> 
>Rsync is a fast and extraordinarily versatile file  copying
>tool.   It can  copy  locally,  to/from  another  host  over
>any remote shell, or to/from a remote rsync daemon.
>[...]
>-c, --checksum  skip based on checksum,
>not mod-time & size

It means "do not copy a file if its checksum on the receiver is the
same as on the sender", that is, this option just modifies the way
`rsync` detects whether a particular file should be updated on the
receiver.  The proposed tool combines (unconditional) copying with
calculating a checksum over the copied content.  At least that's how I
read it.


-- 
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/20130820184122.7d07669ce7812ad02d814...@domain007.com

Re: Dreamhost dumps Debian

[Ian Jackson]

Adam Borowski writes ("Re: Dreamhost dumps Debian"):
> On Tue, Aug 20, 2013 at 03:33:26PM +0100, Ian Jackson wrote:
> > I have done skip upgrades on multiple occasions.  The fallout was
> > always manageable.  (The most recent one was etch->squeeze IIRC.)
> 
> Why wouldn't you instead:
> sed -i s/etch/lenny/ /etc/apt/sources.list
> apt-get dist-upgrade
> sed -i s/lenny/squeeze/ /etc/apt/sources.list
> apt-get dist-upgrade
> 
> This costs some machine time, yeah, but to solve that "fallout" costs human
> time which is in most cases far more expensive.

Well, what I mean is that the fallout could be fixed by fixing upgrade
bugs in the packaging.  Most of the core packages already have the
right metadata and upgrade support.  That the fallout is manageable
shows (I think) that this isn't an unreasonable thing for Debian to do
- we're already nearly there.

The bigger problem for a Debian LTS is this: 1. who is going to do
security support for it ?  2. How are we going to deal with 
drivers for new hardware - upgrade the kernel to LTS+1's ?

Ian.


-- 
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/21011.34255.48484.270...@chiark.greenend.org.uk

Re: Bug#720327: ITP: esu -- It allows to copy files with different checksums on the fly.

[Lars Wirzenius]

On Tue, Aug 20, 2013 at 06:41:22PM +0400, Konstantin Khomoutov wrote:
> On Tue, 20 Aug 2013 10:21:05 -0400
> Ryan Kavanagh  wrote:
> 
> > On Tue, Aug 20, 2013 at 03:33:06PM +0200, root wrote:
> > > * Package name: esu
> > >   Description : It allows to copy files with different checksums
> > > on the fly.
> > > 
> > > Basicly a replacement for cp with additional checksum on the fly
> > > support.  It allows MD5, SHA1, SHA224, SHA265, SHA384, SHA512
> > > algorithm to be used.
> > 
> > How is this different from rsync? Quoting rsync(1):
...
> [discussion of meaning of rsync option]

It would be helpful if the upstream README.md and the package description
explain what the checksums are for. Is this a replacement for cp+sha1sum
(or sha256sum or whatever algorithm is used), or is the checksum used
for verifying that the resulting file is copied correctly and has not
become corrupted during the copy? If the latter, does the program do
anything else to ensure a safe copy, such as fsync to make sure the
target file is committed to disk, or flushing kernel buffer caches so
that checksumming the target file happens on data that is read from the
target disk, and not from cache memory? Also an explanation of why this
is useful and why (and when) the kernel's usual mechanisms aren't enough
would be a good idea.

"cp, but with checksums" isn't a useful description of a program. Unless
the program's output includes the checksums (perhaps for later
verification), the checksums don't seem interesting to me as a user. They
seem like an implementation detail rather than an essential feature of
the program.

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers


-- 
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/20130820150940.gg4...@mavolio.codethink.co.uk

Re: Dreamhost dumps Debian

[Clint Byrum]

Excerpts from Pau Garcia i Quiles's message of 2013-08-20 04:15:12 -0700:
> On Tue, Aug 20, 2013 at 12:46 PM, Steve Langasek  wrote:
> 
> > On Mon, Aug 19, 2013 at 11:48:13PM -0400, Michael Gilbert wrote:
> > > > Russ already replied and I agree with its reply. Just to say that
> > Debian
> > > > usually has a 3 year support. This is the kind of misguiding that I
> > > > usually hear when people promotes Ubuntu over Debian.
> >
> > > I know already that this isn't a popular idea, but another option
> > > would be to release less often.  If releases were every 3 years, then
> > > the support window would be 4 years, which almost gets to the apparent
> > > sweet spot of 5.
> >
> > I think the more useful option would be for Debian to figure out how to
> > lengthen its security support window instead.
> >
> 
> Agreed.
> 
> I know many companies that see Ubuntu's non-LTS releases as release
> candidates with real-world testing and LTS's as stable releases. That's why
> Ubuntu is successful: when a company picks an LTS, they perceive it as
> something that has been properly stabilized (although often times it's not
> true, e. g. Mir in the next LTS).
> 

I think the term used there, "properly stabilized", implies there is a
definite process that one can use to stabilize an operating system and
all of its integrated software.

I think it is reasonable for a company to expect that Ubuntu would
be more conservative with the LTS release, as it is in Ubuntu's best
interest given the cost of supporting a radical release for 5 years.

Debian is expected to be conservative as well. For a long time,
with stable being alive for much longer than 2 years, I think users
didn't have to make the kind of choice Dreamhost did. The release was
an uncommon event that would kick off a year of decisions. However,
with squeeze and wheezy coming so close together, I'm certain that the
Dreamhost engineers were still weary from the squeeze transition when
they were asked to evaluate wheezy.

> Maybe we should adopt a similar model:
> - Stable release every 12-18 months to avoid shipping rotten software
> - Alternate releases are LTS
> - LTS releases get 4-5 years support (to determine)
> - Non-LTS releases get 6 months support after the release of the next LTS
> version
> - LTS overlap in support for at least 1 year to give users ample time to
> move to the next LTS
> 
> 
> E. g:
> - In January 2014 we release Debian 8.0. We make this an LTS release,
> meaning it would get updates for, say 3 years (until January 2017), and
> security updates for 5 years (until January 2019).
> - In February 2015 we release Debian 9.0. Non-LTS release. It will get at
> least 1 year of support (because we won't release the next version until at
> least 1 year later) + 6 months
> - In April 2016 we release Debian 10.0. LTS release. It will get again 3
> years of updates and 5 years of security updates. This means support for
> Debian 9.0 will end in October 2016 (LTS release date + 6 months)
> - ...
> 
> 
> 

All great ideas. I'm more inclined to just suggest that Debian keep
oldstable security patched for an extra year. That is easy for users and
developers to remember, and would give big server users a chance to slow
down the treadmill a little. Of course, it also would put more burden
on DD'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/1377011275-sup-1...@fewbar.com

Re: Dreamhost dumps Debian

[Pau Garcia i Quiles]

> The bigger problem for a Debian LTS is this: 1. who is going to do
> security support for it ?



The same people that maintain the packages in sid and stable: the
maintainer(s) for each package. For orphaned packages, NMUs by other
developers or even a new maintainer team ("foster-car...@debian.org").
Providing fixes, security or not, is our part of our duty as Debian
developers. Sure, packaging new upstream versions is always more exciting
than fixing a broken version/package but it needs to be done.



> 2. How are we going to deal with
> drivers for new hardware - upgrade the kernel to LTS+1's ?
>

AFAIK Ubuntu does not add drivers for new hardware to any version save for,
maybe, some exceptional cases (that I cannot remember, frankly).

Quite the opposite: it's the hardware manufacturers themselves who are
compelled to provide drivers for RHEL, SLES and Ubuntu LTS due to customers
asking. That's why there is an option to "load drivers from disk" at the
very beginning of installation (isolinux prompt) on RHEL, SLES and Ubuntu.

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

Re: overriding udev rules

[Kevin Chadwick]

> olivier sallou  writes:
> > hi,
> > I need for a package to override some udev standard rules.
> >
> > If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> > the one in /lib/udev/rules.d
> >
> >
> > However, lintian raises an error if I put an udev rule in /etc instead of
> > /lib.
> > And if I try to put the file in /lib, it fails at install because the file
> > is owned by udev package.
> >
> > This particular package is for use in virtual machines creation where
> > package removes default network persistence.
> >
> > Is there an other way to override udev rules in package or should I simply
> > override the lintian error message?
> 
> I think you should divert (see man dpkg-divert) the original file in
> /lib and install a new file in it's place. This way the /etc override
> mechanism is still usable by the admin if needed.
> 

Maybe doesn't apply here but why was LAST_ACTION removed anyway,
apparently in Debian first.

It is clear to me that whilst a great big warning and wrong usage
resulting in a pounding would be fine, removing it is simply bad design
and removes freedom from users and simply causes them problems.

An example being automatic removal of a usb key for Truecrypt which is
then remounted and so has to be manually unmounted before removal. A ro
mount may do but still.

Overriding files creates management that shouldn't be required and
GOTO is the wrong fix that doesn't really work and requires editing of
packages files or management of new files which is dumb when a USERS
rule applies to a single usb device.


___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___


-- 
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/611516.87910...@smtp140.mail.ir2.yahoo.com

Re: Dreamhost dumps Debian

[Ian Jackson]

Pau Garcia i Quiles writes ("Re: Dreamhost dumps Debian"):
> [Ian Jackson]
> > The bigger problem for a Debian LTS is this: 1. who is going to do
> > security support for it ?
> 
> The same people that maintain the packages in sid and stable: the
> maintainer(s) for each package. [...]

That is not the case.  At the moment most of this is done by the
Debian security team.  Of course some package maintainers do help.

>  For orphaned packages, NMUs by other
> developers or even a new maintainer team ("foster-car...@debian.org").
> Providing fixes, security or not, is our part of our duty as Debian
> developers. Sure, packaging new upstream versions is always more exciting
> than fixing a broken version/package but it needs to be done.

You seem to be saying "this is an important thing to do - will you
all please go and do it".

That's not how things work.  In summary, unless and until we have
people who volunteer to do the security support for an LTS, we won't
have an LTS.

Ian.


-- 
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/21011.39023.898706.120...@chiark.greenend.org.uk

Re: Dreamhost dumps Debian

[Pau Garcia i Quiles]

On Tue, Aug 20, 2013 at 6:25 PM, Ian Jackson <
ijack...@chiark.greenend.org.uk> wrote:

> > The bigger problem for a Debian LTS is this: 1. who is going to do
> > > security support for it ?
> >
> > The same people that maintain the packages in sid and stable: the
> > maintainer(s) for each package. [...]
>
> That is not the case.  At the moment most of this is done by the
> Debian security team.  Of course some package maintainers do help.
>
>
IMHO that should be turned around: package maintainers should be the ones
responsible for updates and the Security Team should help with that (e. g.
by providing tips and/or reviewing the fixes)


>  For orphaned packages, NMUs by other
> > developers or even a new maintainer team ("foster-car...@debian.org").
> > Providing fixes, security or not, is our part of our duty as Debian
> > developers. Sure, packaging new upstream versions is always more exciting
> > than fixing a broken version/package but it needs to be done.
>
> You seem to be saying "this is an important thing to do - will you
> all please go and do it".
>
>
Exactly. That's what I do for my packages (in fact I backport newer
versions of some of my packages to every Debian and Ubuntu which is still
supported).


> That's not how things work.  In summary, unless and until we have
> people who volunteer to do the security support for an LTS, we won't
> have an LTS.


Maybe I'm wrong but I fail to see why "security support for LTS" should be
a different team than "security support for stable". To me, it should be
the same team, and maintainers and packages should be #1 in the list of
people to work on fixes, as I said above.

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

Re: Bug#720327: ITP: esu -- It allows to copy files with different checksums on the fly.

[Eun]

Package name should be "ecp", sorry misspelled that.

I fixed the README and improved some things.

Thanks for your feedback!


2013/8/20 Lars Wirzenius 

> On Tue, Aug 20, 2013 at 06:41:22PM +0400, Konstantin Khomoutov wrote:
> > On Tue, 20 Aug 2013 10:21:05 -0400
> > Ryan Kavanagh  wrote:
> >
> > > On Tue, Aug 20, 2013 at 03:33:06PM +0200, root wrote:
> > > > * Package name: esu
> > > >   Description : It allows to copy files with different checksums
> > > > on the fly.
> > > >
> > > > Basicly a replacement for cp with additional checksum on the fly
> > > > support.  It allows MD5, SHA1, SHA224, SHA265, SHA384, SHA512
> > > > algorithm to be used.
> > >
> > > How is this different from rsync? Quoting rsync(1):
> ...
> > [discussion of meaning of rsync option]
>
> It would be helpful if the upstream README.md and the package description
> explain what the checksums are for. Is this a replacement for cp+sha1sum
> (or sha256sum or whatever algorithm is used), or is the checksum used
> for verifying that the resulting file is copied correctly and has not
> become corrupted during the copy? If the latter, does the program do
> anything else to ensure a safe copy, such as fsync to make sure the
> target file is committed to disk, or flushing kernel buffer caches so
> that checksumming the target file happens on data that is read from the
> target disk, and not from cache memory? Also an explanation of why this
> is useful and why (and when) the kernel's usual mechanisms aren't enough
> would be a good idea.
>
> "cp, but with checksums" isn't a useful description of a program. Unless
> the program's output includes the checksums (perhaps for later
> verification), the checksums don't seem interesting to me as a user. They
> seem like an implementation detail rather than an essential feature of
> the program.
>
> --
> http://www.cafepress.com/trunktees -- geeky funny T-shirts
> http://gtdfh.branchable.com/ -- GTD for hackers
>

Re: Dreamhost dumps Debian

[Russ Allbery]

Paul Wise  writes:

> We are already no longer supporting iceweasel in squeeze:

> http://www.debian.org/security/2013/dsa-2735

> At one point we stopped supporting clamav in oldstable:

> http://www.debian.org/security/2008/dsa-1497

> At one point there was an experiment to express the lack of security
> support for specific packages using debtags. This seems to have been
> dropped but you can see that sql-ledger and kfreebsd weren't supported
> at one point:

> http://debtags.alioth.debian.org/tagindex/secteam.html
> https://lists.alioth.debian.org/pipermail/debtags-devel/2008-June/001795.html
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436161

Yeah, I know.  But the number of such exceptions is relatively limited,
enough so that we can issue security advisories saying they're not
supported any more.  It's not a comfortable compromise, but it seems to be
a workable one.  The LTS security policy is quite a bit broader in its
implications.

-- 
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/878uzws2nq@windlord.stanford.edu

Re: overriding udev rules

[olivier sallou]

2013/8/20 Michael Biebl 

> Am 20.08.2013 10:39, schrieb olivier sallou:
> > hi,
> > I need for a package to override some udev standard rules.
> >
> > If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> > the one in /lib/udev/rules.d
> >
> >
> > However, lintian raises an error if I put an udev rule in /etc instead of
> > /lib.
> > And if I try to put the file in /lib, it fails at install because the
> file
> > is owned by udev package.
> >
> > This particular package is for use in virtual machines creation where
> > package removes default network persistence.
>
> Could you elobarate why you need that?
> The persistent network interface naming rules are already skipped if
> udev is run within a virtual machine.
> Might be better to just fix udev if it doesn't work in your case.
> For that, it would be good to know more about your problem / use case.
>
ok,
I am packaging a package for OpenNebula that is to be installed on virtual
machine images.
It does many setup at startup.
Among other things, in upstream packages, it replaces 2 udev rules:
75-cd-aliases-generator.rules and 75-persistent-net-generator.rules.
The new rules does nothing, it just expects to skip the existing one.

I did not know that udev skipped (at least) persistent-net in virtual
machines so I did not try without those replacement rules (how does it know
it is a virtual machine?).


Olivier

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


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: overriding udev rules

[olivier sallou]

2013/8/20 olivier sallou 

>
>
>
> 2013/8/20 Michael Biebl 
>
>> Am 20.08.2013 10:39, schrieb olivier sallou:
>> > hi,
>> > I need for a package to override some udev standard rules.
>> >
>> > If I put an identical rule name in /etc/udev/rules.d, I know it
>> overrides
>> > the one in /lib/udev/rules.d
>> >
>> >
>> > However, lintian raises an error if I put an udev rule in /etc instead
>> of
>> > /lib.
>> > And if I try to put the file in /lib, it fails at install because the
>> file
>> > is owned by udev package.
>> >
>> > This particular package is for use in virtual machines creation where
>> > package removes default network persistence.
>>
>> Could you elobarate why you need that?
>> The persistent network interface naming rules are already skipped if
>> udev is run within a virtual machine.
>> Might be better to just fix udev if it doesn't work in your case.
>> For that, it would be good to know more about your problem / use case.
>>
> ok,
> I am packaging a package for OpenNebula that is to be installed on virtual
> machine images.
> It does many setup at startup.
> Among other things, in upstream packages, it replaces 2 udev rules:
> 75-cd-aliases-generator.rules and 75-persistent-net-generator.rules.
>

As additional information, this is needed when you clone, reuse some
virtual machine.


> The new rules does nothing, it just expects to skip the existing one.
>
> I did not know that udev skipped (at least) persistent-net in virtual
> machines so I did not try without those replacement rules (how does it know
> it is a virtual machine?).
>
>
> Olivier
>
>>
>> Michael
>>
>>
>> --
>> Why is it that all of the instruments seeking intelligent life in the
>> universe are pointed away from Earth?
>>
>>
>
>
> --
>
> gpg key id: 4096R/326D8438  (keyring.debian.org)
>
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438
>
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: Dreamhost dumps Debian

[Christian PERRIER]

Quoting Pau Garcia i Quiles (pgqui...@elpauer.org):

> > That is not the case.  At the moment most of this is done by the
> > Debian security team.  Of course some package maintainers do help.
> >
> >
> IMHO that should be turned around: package maintainers should be the ones
> responsible for updates and the Security Team should help with that (e. g.
> by providing tips and/or reviewing the fixes)

I'm afraid you probably think that all packages are better maintained than
they really are 

The Security Team is indeed very opened to package maintainers doing
most of the update work.when there is really someone maintaining
the package and not a ghost.




signature.asc
Description: Digital signature

Bug#720336: ITP: ruby-puma -- Puma: A Ruby Web Server Built For Concurrency

[Shawn Landden]

Package: wnpp
Severity: wishlist
Owner: Shawn Landden 

* Package name: ruby-puma
  Version : 2.5.1
  Upstream Author : Engine Yard
* URL : http://puma.ui/
* License : BSD
  Programming Lang: C, Ruby
  Description : Ruby Web Server Built For Concurrency

Puma is a simple, fast, threaded, and highly concurrent HTTP 1.1 server for 
Ruby/Rack applications. Puma is intended for use in both development and 
production environments. In order to get the best throughput, it is highly 
recommended that you use a Ruby implementation with real threads like Rubinius 
or JRuby.
Built For Speed & Concurrency

Puma is a simple, fast, and highly concurrent HTTP 1.1 server for Ruby web 
applications. It can be used with any application that supports Rack, and is 
considered the replacement for Webrick and Mongrel. It was designed to be the 
go-to server for Rubinius, but also works well with JRuby and MRI. Puma is 
intended for use in both development and production environments.

Under the hood, Puma processes requests using a C-optimized Ragel extension 
(inherited from Mongrel) that provides fast, accurate HTTP 1.1 protocol parsing 
in a portable way. Puma then serves the request in a thread from an internal 
thread pool (which you can control). This allows Puma to provide real 
concurrency for your web application!

With Rubinius 2.0, Puma will utilize all cores on your CPU with real threads, 
meaning you won't have to spawn multiple processes to increase throughput. You 
can expect to see a similar benefit from JRuby.

On MRI, there is a Global Interpreter Lock (GIL) that ensures only one thread 
can be run at a time. But if you're doing a lot of blocking IO (such as HTTP 
calls to external APIs like Twitter), Puma still improves MRI's throughput by 
allowing blocking IO to be run concurrently (EventMachine-based servers such as 
Thin turn off this ability, requiring you to use special libraries). Your 
mileage may vary. In order to get the best throughput, it is highly recommended 
that you use a Ruby implementation with real threads like Rubinius or JRuby.


-- 
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/20130820173318.8348.60804.report...@chrome.churchofgit.com

Re: Bug#720336: ITP: ruby-puma -- Puma: A Ruby Web Server Built For Concurrency

[Andrew Starr-Bochicchio]

On Tue, Aug 20, 2013 at 1:33 PM, Shawn Landden  wrote:
> * URL : http://puma.ui/

That url redirects to the sporting clothes company. It seems you mean:
http://puma.io/


-- Andrew Starr-Bochicchio

   Ubuntu Developer 
   Debian Developer 
   PGP/GPG Key ID: D53FDCB1


-- 
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/CAL6k_Ax0YtPqp9L_OGsJshfdSO0Upo=jn-lkwrr6pzkw9jd...@mail.gmail.com

Re: Dreamhost dumps Debian

[Steve Langasek]

On Tue, Aug 20, 2013 at 06:35:08PM +0200, Pau Garcia i Quiles wrote:
> On Tue, Aug 20, 2013 at 6:25 PM, Ian Jackson <
> ijack...@chiark.greenend.org.uk> wrote:

> > > The bigger problem for a Debian LTS is this: 1. who is going to do
> > > > security support for it ?

> > > The same people that maintain the packages in sid and stable: the
> > > maintainer(s) for each package. [...]

> > That is not the case.  At the moment most of this is done by the
> > Debian security team.  Of course some package maintainers do help.

> IMHO that should be turned around: package maintainers should be the ones
> responsible for updates and the Security Team should help with that (e. g.
> by providing tips and/or reviewing the fixes)

That's not the understanding that was in place when I joined Debian.
Certainly there seems to be a move by the security team to push more and
more responsibility onto the package maintainers lately; I understand the
motivation (like everyone else they have more to do than they have time to
do it in), but I think the outcome, whereby the security team denies use of
the security update channel for non-"critical" security bugs and redirects
maintainers to stable-updates instead, is unfortunate.  As far as I'm
concerned, a security fix that isn't worth being pushed to
security.debian.org is also not worth me spending time on as a maintainer to
push to stable-updates.

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


signature.asc
Description: Digital signature

Re: Dreamhost dumps Debian

[Russ Allbery]

Ian Jackson  writes:
> Pau Garcia i Quiles writes ("Re: Dreamhost dumps Debian"):

>> The same people that maintain the packages in sid and stable: the
>> maintainer(s) for each package. [...]

> That is not the case.  At the moment most of this is done by the
> Debian security team.  Of course some package maintainers do help.

I consider it part of my responsibility as a package maintainer to provide
security support for my packages for as long as Debian does.  If I felt
like I couldn't do that, I would orphan the package or look at having it
removed from Debian.  I don't think there's any way that one team can
scale to providing security support for the entire archive; it's hard for
them to even track the existence of issues for the entire archive.

But even apart from manpower, I think there are some real challenges to
providing security support for any longer than we do, to the degree that I
feel like the security support that Ubuntu and Red Hat claim to provide is
partly illusory.  My experience is that I can just barely manage to
convince upstreams to look over my backports of security patches to
packages in oldstable; another two years would be so far out of upstream's
willingness to even consider the package that Debian would be entirely on
its own for quite a lot of packages.  Frequently, the version in oldstable
is already past upstream's official end of life announcement.  And it's
rare to see much involvement of Red Hat or Ubuntu security folks in those
conversations.

I don't want to be unfair to Red Hat's and Ubuntu's security teams, who do
a lot of hard and excellent work, and I realize that both have paid
employees doing this and therefore more resources available.  But even
given that, I suspect that, towards the end of that five year cycle, the
number of security fixes that are actually backported is fairly limited,
and quite a lot of triage is being done, even beyond the core versus
universe distinctions.  They'd be working without any assistance from the
upstream maintainers in many cases.

Two year upgrade cycles are uncomfortable for a lot of production IT
organizations, including the one I work for.  But even if Debian claimed
to support software for longer, I personally would be quite leery about
relying on that given my experience with talking to upstream projects
about security vulnerabilities.  I'm painfully aware of the steep cliff
dropoff of upstream support for security fixes once you go beyond two
years after the release of the software.  Beyond that point, even if you
do get security fixes, you're probably getting fixes that have been
backported by people with only a vague knowledge of the code, fixes that
often have not been thoroughly tested or tested by someone who uses the
software in question and that upstream has never looked at and will
disclaim any knowledge of or support for.

As painful as it is, if you are worried about security in a production
environment, falling more than a couple of years behind current
distribution releases is probably not in your best interests no matter
what security support you supposedly have.

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

Re: Bug#720202: ITP: qreator -- utility for creating QR codes

[Julien Cristau]

On Mon, Aug 19, 2013 at 22:16:11 +0200, Thomas Preud'homme wrote:

> Le lundi 19 août 2013 23:24:48 Chow Loong Jin a écrit :
> > Package: wnpp
> > Severity: wishlist
> > Owner: Chow Loong Jin 
> > 
> > * Package name: qreator
> >   Version : 13.05.3
> >   Upstream Author : David Planella 
> > * URL : https://launchpad.net/qreator
> > * License : GPL-3
> >   Programming Lang: Python
> >   Description : utility for creating QR codes
> > 
> > Qreator enables you to easily create your own QR codes to encode different
> > types of information in an efficient, compact and cool way.
> 
> Greetings Loong Jin,
> 
> Since it seems there is already a qr generator in Debian (qrencode), I 
> suppose 
> qreator has some feature that are lacking in qrencode. Could you develop 
> those? That would be especially useful in the long description so that a user 
> looking for a tool creating a qr code have enough information to choose 
> between these two packages.
> 
What would be even more useful is to just ship one.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Dreamhost dumps Debian

[Pau Garcia i Quiles]

On Tue, Aug 20, 2013 at 8:25 PM, Russ Allbery  wrote:


> >> The same people that maintain the packages in sid and stable: the
> >> maintainer(s) for each package. [...]
>
> > That is not the case.  At the moment most of this is done by the
> > Debian security team.  Of course some package maintainers do help.
>
> I consider it part of my responsibility as a package maintainer to provide
> security support for my packages for as long as Debian does.  If I felt
> like I couldn't do that, I would orphan the package or look at having it
> removed from Debian.  I don't think there's any way that one team can
> scale to providing security support for the entire archive; it's hard for
> them to even track the existence of issues for the entire archive.
>
>
That's exactly how I see it, glad to see I'm not alone :-)



> My experience is that I can just barely manage to
> convince upstreams to look over my backports of security patches to
> packages in oldstable


What makes you think Ubuntu, Red Hat, etc ask upstream to look at their
security patches for old versions or even approve them? When I backport
something, I send it to upstream as a courtesy, in case they want to
release a patch version, not because I expect them to give me the OK

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

Re: Dreamhost dumps Debian

[Thijs Kinkhorst]

On Tue, August 20, 2013 19:40, Steve Langasek wrote:
> On Tue, Aug 20, 2013 at 06:35:08PM +0200, Pau Garcia i Quiles wrote:

>> IMHO that should be turned around: package maintainers should be the
>> ones responsible for updates and the Security Team should help with that
>> (e.g. by providing tips and/or reviewing the fixes)
>
> That's not the understanding that was in place when I joined Debian.
> Certainly there seems to be a move by the security team to push more and
> more responsibility onto the package maintainers lately; I understand the
> motivation (like everyone else they have more to do than they have time to
> do it in),

Division of labour is very important to sustain the security support for
the full breadth of the archive, but an important part of the shift in
responsibility is that the package maintainers are in better contact with
upstream and much more used to the intricacies of the software and its
packaging, and on top are probably in a well suited position to test the
changes. Having the maintainers involved in creating updated packages is
therefore a much more preferable MO than the security team preparing the
updates on their own.

> but I think the outcome, whereby the security team denies use
> of the security update channel for non-"critical" security bugs and
> redirects maintainers to stable-updates instead, is unfortunate.  As far
> as I'm concerned, a security fix that isn't worth being pushed to
> security.debian.org is also not worth me spending time on as a maintainer
> to push to stable-updates.

And that is a very fair position. Everything that smells like security
regardless of impact and seriousness gets a CVE id and is called a
"security issue". The security team triages issues and decides what is not
critical enough for a DSA. Perhaps a good way to see those issues as bugs
of severity up to "important": where it's arguable that may improve Debian
by putting it into a spu, but can equally well be argued that there are
better ways to spend your time.


Thijs


-- 
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/0327d20c814d27da6a3e0b5fbc9e0658.squir...@aphrodite.kinkhorst.nl

Re: Dreamhost dumps Debian

[Thomas Goirand]

On 08/20/2013 02:04 AM, Charles Plessy wrote:
> However, one difficulty that was not mentionned in this thread is that if we
> aim at both long term support and frequent releases, then we need to support
> users skipping releases

I don't see why.

> or upgrading multiple releases in a row.

Don't we support that already?

Thomas


-- 
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/5213c10f.4070...@debian.org

Re: Dreamhost dumps Debian

[Russ Allbery]

Pau Garcia i Quiles  writes:
> On Tue, Aug 20, 2013 at 8:25 PM, Russ Allbery  wrote:

>> My experience is that I can just barely manage to convince upstreams to
>> look over my backports of security patches to packages in oldstable

> What makes you think Ubuntu, Red Hat, etc ask upstream to look at their
> security patches for old versions or even approve them? When I backport
> something, I send it to upstream as a courtesy, in case they want to
> release a patch version, not because I expect them to give me the OK

Well, I suppose they might not, but I would find that even more
disturbing.  It's very easy to not actually fix the problem or to add new
security holes in the process of fixing another problem, and the few times
when I've had to fix security holes without any upstream review, it's made
me very nervous.  I'd really like security fixes to be vetted by people
who are experts in that code base.

Now, if the distribution packagers are experts, that's great; at that
point, I consider them as something akin to part of upstream.

-- 
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/874nakqifh@windlord.stanford.edu

Re: Security support proposed workflow for the very-old-stable (was: Dreamhost dumps Debian)

[Thomas Goirand]

On 08/20/2013 05:17 PM, Clint Byrum wrote:
>> E. g:
>> - In January 2014 we release Debian 8.0. We make this an LTS release,
>> meaning it would get updates for, say 3 years (until January 2017), and
>> security updates for 5 years (until January 2019).
>> - In February 2015 we release Debian 9.0. Non-LTS release. It will get at
>> least 1 year of support (because we won't release the next version until at
>> least 1 year later) + 6 months
>> - In April 2016 we release Debian 10.0. LTS release. It will get again 3
>> years of updates and 5 years of security updates. This means support for
>> Debian 9.0 will end in October 2016 (LTS release date + 6 months)
>> - ...
>>
>> 
>>
> 
> All great ideas. I'm more inclined to just suggest that Debian keep
> oldstable security patched for an extra year. That is easy for users and
> developers to remember, and would give big server users a chance to slow
> down the treadmill a little. Of course, it also would put more burden
> on DD's.

I thought about having a BoF at Debconf13 about this topic (we talked
about it in this list), though there was not enough members of the
security team and FTP team so that it would have been productive. So I
gave up on the idea.

Though I would really like to have a more extended security support, and
we can probably discuss this in this list.

My initial idea wasn't to never *impose* the extended security
maintenance to all DDs. Instead, we could do it on a best-effort basis,
collectively. Meaning that anyone willing to do security fixes for the
EOL distribution (one year after stable is released) could do so through
a special repository. Nobody would be forced to maintain its own
packages, but at the same time, anyone could help on any package. Also,
we wouldn't have to tell that we maintain *all* packages, but probably a
subset of things we declare important (simply based on what we
collectively decide to work on).

This effort could be done experimentally to start with, through a
non-official debian.net repository, when Squeeze will be EOL. Then if it
works well for the next 2 years after Squeeze is EOL, then probably we
can make it a bit more official.

I don't think it is realistic to try to do anything else. We simply
don't have enough man power to do so. Remember that in Ubuntu, the role
of the security team is a lot different than what the Debian security
team does. In Debian, the security team is there to mainly do
communication, and peer-review the updated packages. In Ubuntu, the
security team is composed of Canonical *employees*, that actually do the
work of backporting patches. We can't reasonably expect that any given
package maintainer in Debian will backport patches for old-stable AND
very-old-stable.

I don't think it's reasonable also to impose more work to the FTP
masters, the security team, etc. if we don't just try, and see if it is
doable. Though I have no idea how to duplicate a dak setup and probably
will not have the time to investigate how to do it myself, it could be
done through a more light infrastructure (which I can host if we don't
find anything better).

Thoughts anyone?

Thomas Goirand (zigo)


-- 
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/5213c4a0.9000...@debian.org

Re: Dreamhost dumps Debian

[Thomas Goirand]

On 08/20/2013 05:05 PM, Ian Jackson wrote:
> The bigger problem for a Debian LTS is this: 1. who is going to do
> security support for it ?

My answer is: anyone who cares (and *not* necessarily the package
maintainer) in a free-for-all way, with peer review if possible (not
necessarily by the security team if they are already busy), for the
packages we care about (example: bind9 ...). Also, this could be done by
backporting old-stable packages to very-old-stable in a few cases, if we
can't (because of lack of time?) do otherwise. That would still be
better, IMO, than just dropping security support.

Let's try and see if that works when Squeeze is EOL...

> 2. How are we going to deal with 
> drivers for new hardware - upgrade the kernel to LTS+1's ?

IMO, that's not the problem. What maters is maintaining existing setups,
not allowing people to use very-old-stable with new hardware.

Thomas


-- 
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/5213c685.8030...@debian.org

Re: Dreamhost dumps Debian

[Clint Byrum]

Excerpts from Pau Garcia i Quiles's message of 2013-08-20 08:49:57 -0700:
> > The bigger problem for a Debian LTS is this: 1. who is going to do
> > security support for it ?
> 
> 
> 
> The same people that maintain the packages in sid and stable: the
> maintainer(s) for each package. For orphaned packages, NMUs by other
> developers or even a new maintainer team ("foster-car...@debian.org").
> Providing fixes, security or not, is our part of our duty as Debian
> developers. Sure, packaging new upstream versions is always more exciting
> than fixing a broken version/package but it needs to be done.
> 
> > 2. How are we going to deal with
> > drivers for new hardware - upgrade the kernel to LTS+1's ?
> >
> 
> AFAIK Ubuntu does not add drivers for new hardware to any version save for,
> maybe, some exceptional cases (that I cannot remember, frankly).
> 
> Quite the opposite: it's the hardware manufacturers themselves who are
> compelled to provide drivers for RHEL, SLES and Ubuntu LTS due to customers
> asking. That's why there is an option to "load drivers from disk" at the
> very beginning of installation (isolinux prompt) on RHEL, SLES and Ubuntu.
> 

https://wiki.ubuntu.com/LTS states:

"We will make point releases throughout the development cycle to provide
functional support for new server and desktop hardware."


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

Bug#720347: ITP: jaxb2-maven-plugin -- interlinking XML files with Java Objects from mojo.codehaus.org

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: jaxb2-maven-plugin
  Version : 1.5
* URL : http://mojo.codehaus.org/jaxb2-maven-plugin
* License : Apache-2.0
  Programming Lang: Java
  Description : interlinking XML files with Java Objects from 
mojo.codehaus.org

 Mojo's JAXB-2 Maven plugin is used to create an object graph from XSDs
 based on the JAXB 2.1 implementation and to generate XSDs from JAXB-annotated
 Java classes.
 .
 This plugin uses JAXB2 to generate Java classes from XML Schemas (and
 binding files) and to create XML Schemas for existing Java classes.
 .
 General Information about the plugin goals:
 .
  * jaxb2:schemagen Creates XML Schema Definition (XSD) file(s) from
annotated Java sources.
  * jaxb2:testSchemagen Creates XML Schema Definition (XSD) file(s)
from annotated Java test sources.
  * jaxb2:xjc Generates Java sources from XML Schema(s).
  * jaxb2:testXjc Generates Java test sources from XML Schema(s).


An mh_make prepared package is about to appear on pkg-java.


-- 
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/20130820194200.18199.46689.reportbug@Toshiba.siemens

Re: Dreamhost dumps Debian

[Wookey]

+++ Ian Jackson [2013-08-20 16:05 +0100]:

> The bigger problem for a Debian LTS is this: 1. who is going to do
> security support for it ? 

Ideally it would be the people that want releases supported longer -
e.g this dreamhost outfit, and presumably many organisations like them.

Security support is a very parallelisable task, so a small amout of
work by a lot of interested people ought to be do-able, but for
whatever reason this never seems to have prospered as a model. It
would be interesting to know why those entities that would like the
LTS don't choose to do this. Is it just because we don't make it easy
for them or because of free-loader aspects?

I have always thought that there was room for a business selling
longer-term Debian support. Maybe someone does? 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20130820195620.gl24...@stoneboat.aleph1.co.uk

Re: Dreamhost dumps Debian

[Philipp Kern]

Pau,

am Tue, Aug 20, 2013 at 05:49:57PM +0200 hast du folgendes geschrieben:
> AFAIK Ubuntu does not add drivers for new hardware to any version save for,
> maybe, some exceptional cases (that I cannot remember, frankly).

they backport the xservers and kernels of current releases to the latest LTS.
So that's plain wrong. ;-)

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: overriding udev rules

[Thomas Goirand]

On 08/20/2013 07:02 PM, olivier sallou wrote:
> ok,
> I am packaging a package for OpenNebula that is to be installed on
> virtual machine images.
> It does many setup at startup.
> Among other things, in upstream packages, it replaces 2 udev rules:
> 75-cd-aliases-generator.rules and 75-persistent-net-generator.rules.
> The new rules does nothing, it just expects to skip the existing one.
> 
> I did not know that udev skipped (at least) persistent-net in virtual
> machines so I did not try without those replacement rules (how does it
> know it is a virtual machine?).
>  
> 
> Olivier

I'd be happy to find a correct and clean way to do this, because I also
need to do it, and it seems to be a fairly common use case. I currently
only delete the 75-persistent-net-generator.rules file (which I know is
the wrong way to do it as it wont survive upgrades, though I currently
don't know how to do it cleanly, so I have fallen back to that).

It would be really nice to have a switch somewhere in /etc for this.
Maybe upstream could work that out, so that we don't have to hack and
hack again? I'm sure I'm not the only one to think that dpkg-divert
over-engineering something that should be fixed upstream.

Thomas


-- 
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/5213ca73.6080...@debian.org

Bug#720349: ITP: tcl-tdbc-sqlite3 -- Sqlite3 driver for package tdbc (Tcl Database Connectivity)

[Massimo Manghi]

Package: wnpp
Severity: wishlist
Owner: Massimo Manghi 

* Package name: tcl-tdbc-sqlite3
  Version : 1.0.0
  Upstream Author : Kevin B. Kenny 
The Tcl Core Team 
* URL : http://tdbc.tcl.tk/
* License : (custom, BSD-like)
  Programming Lang: (C, Tcl)
  Description : Sqlite3 driver for package tdbc (Tcl Database Connectivity)


-- 
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/20130820201149.25670.98135.report...@pokemon.bandasalute.it

Re: overriding udev rules

[Thomas Goirand]

On 08/20/2013 07:02 PM, olivier sallou wrote:
> I did not know that udev skipped (at least) persistent-net in virtual
> machines so I did not try without those replacement rules (how does it
> know it is a virtual machine?).

Oh, missed that part! I also would be happy to know how it does it.

Thomas


-- 
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/5213cace.5000...@debian.org

Fwd: Re: overriding udev rules

[olivier sallou]

Ccing the list
-- Message transféré --
De : "olivier sallou" 
Date : 20 août 2013 22:27
Objet : Re: overriding udev rules
À : "Thomas Goirand" 

Le 20 août 2013 22:18, "Thomas Goirand"  a écrit :

>
> On 08/20/2013 07:02 PM, olivier sallou wrote:
> > I did not know that udev skipped (at least) persistent-net in virtual
> > machines so I did not try without those replacement rules (how does it
> > know it is a virtual machine?).
>
> Oh, missed that part! I also would be happy to know how it does it.
With a quick look at script it seems to skip the rule for a set of MAC
address masks commonly used in different systems (KVM VMWARE..) but this
does not fit for all nor users custom config.
>
> Thomas
>
>
> --
> 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/5213cace.5000...@debian.org
>

Re: Bug#720202: ITP: qreator -- utility for creating QR codes

[Andrew Starr-Bochicchio]

On Tue, Aug 20, 2013 at 2:45 PM, Julien Cristau  wrote:
>> Since it seems there is already a qr generator in Debian (qrencode), I 
>> suppose
>> qreator has some feature that are lacking in qrencode. Could you develop
>> those? That would be especially useful in the long description so that a user
>> looking for a tool creating a qr code have enough information to choose
>> between these two packages.
>>
> What would be even more useful is to just ship one.

That's like saying we shouldn't have synaptic in the archive since we
have apt. qreator is a graphical front-end for python-qrencode. So
perhaps just a better description is needed, as hyperair has already
agreed to do.

Thanks,

-- Andrew Starr-Bochicchio

   Ubuntu Developer 
   Debian Developer 
   PGP/GPG Key ID: D53FDCB1


-- 
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/CAL6k_AzfZYG=mdskbqxspztjmkop58vzay9ezr-lbyqowme...@mail.gmail.com

Re: Security support proposed workflow for the very-old-stable (was: Dreamhost dumps Debian)

[Adam Borowski]

On Tue, Aug 20, 2013 at 09:33:52PM +0200, Thomas Goirand wrote:
> My initial idea wasn't to never *impose* the extended security
> maintenance to all DDs. Instead, we could do it on a best-effort basis,
> collectively. Meaning that anyone willing to do security fixes for the
> EOL distribution (one year after stable is released) could do so through
> a special repository. [...]
> 
> This effort could be done experimentally to start with, through a
> non-official debian.net repository, when Squeeze will be EOL. Then if it
> works well for the next 2 years after Squeeze is EOL, then probably we
> can make it a bit more official.

There's a practical consideration from starting with mostly-official:
old systems won't configure themselves to use your repository, and in the
real world, they don't even care about such details like no security
support.  The box does still work?  It can stay.

Thus it might be good to host the best-effort repository on, or 302ed from,
http://security.debian.org/ squeeze/updates

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130820214410.gb9...@angband.pl

Re: overriding udev rules

[Vincent Bernat]

 ❦ 20 août 2013 22:00 CEST, Thomas Goirand  :

>> I did not know that udev skipped (at least) persistent-net in virtual
>> machines so I did not try without those replacement rules (how does it
>> know it is a virtual machine?).
>
> Oh, missed that part! I also would be happy to know how it does it.

It relies on the MAC address starting with 52:54:00 or things like that.
-- 
Use recursive procedures for recursively-defined data structures.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Security support proposed workflow for the very-old-stable

[Thomas Goirand]

On 08/20/2013 11:44 PM, Adam Borowski wrote:
> On Tue, Aug 20, 2013 at 09:33:52PM +0200, Thomas Goirand wrote:
>> My initial idea wasn't to never *impose* the extended security
>> maintenance to all DDs. Instead, we could do it on a best-effort basis,
>> collectively. Meaning that anyone willing to do security fixes for the
>> EOL distribution (one year after stable is released) could do so through
>> a special repository. [...]
>>
>> This effort could be done experimentally to start with, through a
>> non-official debian.net repository, when Squeeze will be EOL. Then if it
>> works well for the next 2 years after Squeeze is EOL, then probably we
>> can make it a bit more official.
> 
> There's a practical consideration from starting with mostly-official:
> old systems won't configure themselves to use your repository, and in the
> real world, they don't even care about such details like no security
> support.  The box does still work?  It can stay.
> 
> Thus it might be good to host the best-effort repository on, or 302ed from,
> http://security.debian.org/ squeeze/updates

I agree, though this needs the FTP masters and security team to be
involved, and probably some infrastructure change too. Which might not
be practical. Of course, any of the parties involved can jump in this
thread and tell they want to do it... Though if they don't, I don't see
any other way we could do it.

Thomas


-- 
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/5213f429.3040...@debian.org

Re: overriding udev rules

[Thomas Goirand]

On 08/20/2013 11:44 PM, Vincent Bernat wrote:
>  ❦ 20 août 2013 22:00 CEST, Thomas Goirand  :
> 
>>> I did not know that udev skipped (at least) persistent-net in virtual
>>> machines so I did not try without those replacement rules (how does it
>>> know it is a virtual machine?).
>>
>> Oh, missed that part! I also would be happy to know how it does it.
> 
> It relies on the MAC address starting with 52:54:00 or things like that.

Oh ok. Not useful at all if you ask me. Why? Because sometimes, you
can't change the MAC address. For example, if you use the OpenStack bare
metal driver, then you continue to use virtual machine images, though
they will be used on a real hardware where you can't change the MAC
address. So this is a very wrong assumption that udev is doing here, and
we still need a way to fix it (by fixing, I mean disabling the
presistent-net rule in a non-too-hackish way).

Thomas


--
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/5213f358.6030...@debian.org

OPORTUNIDADE PARA MUDAR SUA VIDA !!!

[Gerlipaulo Vieira]

Você assim como eu esta cansado de ter seu negocio Mmn BLOQUEADO ?

Hoje eu vou te apresentar um SISTEMA REVOLUCIONÁRIO o sistema AJUDANDO A
TODOS.
Entre atraves do link e conheça
http://ajudandotodos.com.br/?ref=Spaulo

Um sistema completo e que depende apenas de voce, quanto mais voce se
dedicar em publicar o sistema maior seram suas chances de ganhos.
No sistema voce precisa apenas fazer 4 depósitos de R$ 10.
Apos realiza esses depositos vc recebera um link onde voce divulgara o
sistema e começara a receber dezenas,centenas ou ate milhares de depositos
diretamente em sua conta bancario.
Nao perca mais tempo faça agora seu cadastro e venha fazer parte desse
sistema fenomenal que esta mudando a vida de muita gente.Entre comigo o
sistema e fantastico
http://ajudandotodos.com.br/?ref=Spaulo
qualquer duvidas me add no facebook.

Re: Dreamhost dumps Debian

[Ben Hutchings]

On Tue, 2013-08-20 at 17:49 +0200, Pau Garcia i Quiles wrote:
[...]


> 2. How are we going to deal with
> drivers for new hardware - upgrade the kernel to LTS+1's ?
>  
> AFAIK Ubuntu does not add drivers for new hardware to any version save
> for, maybe, some exceptional cases (that I cannot remember, frankly). 
> 
> 
> Quite the opposite: it's the hardware manufacturers themselves who are
> compelled to provide drivers for RHEL, SLES and Ubuntu LTS due to
> customers asking. That's why there is an option to "load drivers from
> disk" at the very beginning of installation (isolinux prompt) on RHEL,
> SLES and Ubuntu.

Since I actually work on Linux support for a hardware manufacturer, I
can tell you that customers demand both - RPMs and driver disks, and
in-tree support.  I regularly work with Red Hat and SUSE developers on
backports of the latest in-tree driver to their 'enterprise'
distributions.

Ubuntu uses a combination of driver backports and newer kernel versions
in LTS releases.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates


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