Re: asking for advice: all dependencies incl. version numbers

[FARKAS, Illes]

2013/8/23 Joachim Breitner 

> Dear Illes,
>
> Am Donnerstag, den 22.08.2013, 17:47 +0200 schrieb FARKAS, Illes:
>
> > This is a researcher asking for advice.
> >
> > I'd like to download/parse for each version of each debian package
> > which other package versions it depends on.
> >
> > Do you think this information available in managable formats?
>
> It is all in the Packages file, e.g.
>
> ftp://ftp.de.debian.org/debian/dists/unstable/main/binary-amd64/Packages.bz2
>
> It is a simple text file format and there are parsing libraries for
> various programming language around. If you are more specific about your
> goals and needs, I can give more specific advise.
>

Dear Joachim, Thanks for your detailed replies.

If I'm not mistaken, then the file you mention lists the dependencies of
the *current* package versions. For example, it tells that version
"0.0.13-2+b1" of the package called "0ad" depends on the following versions
of the following packages: 0ad-data (>= 0.0.13), 0ad-data (<= 0.0.13-2),
0ad-data-common (>= 0.0.13), etc.

According to the developer info page of the package (
http://packages.qa.debian.org/0/0ad.html) there have been also previous
versions of the package "0ad", for example, versions "0.0.12" and "0.0.11".
I would be curious to know too the list of package versions that
0ad-0.0.12, 0ad-0.0.11, etc depend on. Since I'm trying to find a
standardized way of doing this for all packages/versions, I stayed at the
above URL and I looked into the "buildd logs" and "RDF metadata" (links in
the right navigation area). But it seems these are not the files [droids] I
am looking for :-)

So the best solution I can think of right now is to download all
Packages.bz2 files I can find at debian. These may not contain all versions
of all packages, but they will probably contain most of the important
versions of most packages. If you have any other suggestions, I'd be happy
to learn from those.

> Have you seen similar work before?
>
> The researches at IRILL have done lots of work on Package relationsships
> and also created useful tools to investigate that. I don’t have a good
> entry page to send you to, but I guess http://www.mancoosi.org/edos/ and
> http://www.mancoosi.org/ are of relevance.
>

Thanks. I found that "Managing the Complexity of Large Free and Open Source
Package-Based
Software Distributions" (PDF at http://goo.gl/NTPqlE) describes the project
best. By the way, which is your favorite paper from IRILL?

Greetings,
> Joachim
> --
> Joachim "nomeata" Breitner
> Debian Developer
>   nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
>   JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
>

2013/8/23 Johannes Schauer 

> Hi,
>
> Quoting FARKAS, Illes (2013-08-22 17:47:57)
> > I'd like to download/parse for each version of each debian package which
> > other package versions it depends on.
> >
> > Do you think this information available in managable formats?
>
> In addition to the information Joachim already gave, let me specifically
> point
> you at dose3. It is a framework for working with dependencies and allows
> you to
> parse Packages.bz2 and Sources.bz2 files, create all kinds of dependency
> graphs
> and analyze them and includes a solver for package relationships.
>

Hi, Johannes (josch). Thanks for your help. The more complex features seem
to be the ones I'm interested in.


> > Have you seen similar work before?
>
> Joachim was pointing you at edos. There exists the tool edos-debcheck (or
> edos-distcheck as a more general tool) in the main archive. But instead you
> might want to look at the dose3 tools which supersede the edos tools. More
> specifically you want to look at the binary packages built from the source
> package dose3. The dose-extra binary package contains a tool called ceve
> which
> allows you to build many different kinds of dependency graphs from a
> Packages.bz2 file. Maybe this gives you the information you need.


> Contact me if you have any trouble.
>

Thanks, I'll do.

Cheers,
Illes


>
> cheers, josch
>



-- 
http://hal.elte.hu/fij

Re: Debian running on handhelds (or for terminals)

[Neil Williams]

On Mon, 26 Aug 2013 12:34:44 +0200
patrick295767 patrick295767  wrote:

> Hello,
> 
> I wonder what's Debian position in regards to installations on
> Handhelds.

Mostly already been handed over to Android on tablets, without so much
as a whimper. IMHO there's nowhere to go with mass market handhelds
which doesn't involve DRM, full screen video, & HDMI output. Much of
that could be supported but there is no work to get a usable UI on top
of it.

> Over the years, I have installed/contributed in installing Debian on
> various handheld machines, including for instance HP Jornadas (Sarge -
> archive), Psion Revo, Psion 5mx, ... armel, and finally the best of
> best the Pandora. (The default OS of the Pandora is Angstrom).

Any *current* hardware? i.e. still in mass production & available
through standard retail? Any hardware at all which sells at comparable
prices to a basic Android tablet?

The principle targets for Debian are mass market hardware, i386, amd64,
armhf.
 
> As shown, Debian can be readily installed on various platforms /
> machines, even with a very limited hardware.

The problem is that other installations make more sense in terms of
usable software and user expectations.
 
> What I regret is that end users keep asking: "which light distro for
> my computer?" Even, if the machine is a bit older.

Fundamental misunderstanding. An older machine needs an OS which has
lower resource requirements. A light distro typically involves using
the same resources as a standard distro but takes up less space. To use
less resources, you need to change core parts of the OS, like glibc, or
drop large components like perl.

> OPIE / GPE (in particular GPE added to our repos) are also a point for
> having Debian for Handelds.

GPE is all but dead. I am currently vacillating over whether to remove
all of GPE from Debian before the Jessie release. Even if it survives
into Jessie, the chances of it surviving into Jessie+1 are negligible.
There has been no significant upstream work for a couple of years.

The "functionality" of GPE is laughable or depressing, depending on
your perspective. It started as just a toy, a curiosity but it never
managed to support anything approaching day-to-day usability.

Openmoko tried as well - again, not getting close to everyday
competency for more than a few hardened geeks.

Wookey wrote:
> We've had GPE in debian for may years, but not well-maintained. Taking
> care of that would be great if you are interested in it.

It is maintained in Debian but it is not actively developed and hasn't
grown into a fully specified UI. IMHO it would need the replacement of
large chunks to be worth working on. Most of the upstream code hasn't
been touched in years.

There might be some promise in wayland/Qt5 but GPE is stuck in the world
of GTK2 and has little prospect of stepping out of it's own comfort
zone / rut. That's why it's on my list of "endangered" package chains.
There's no point being sentimental about these things, it had a go, it
got as far as it got but I'm starting to think that it should be
pensioned off and left to bit rot in peace.

> I believed we might lack of publicity on own easily Debian is
> installable on handhelds.

No. We lack a purpose for having Debian on handhelds - current, mass
market, handhelds - because those devices need a completely different
UI which is not compatible with the desktop type environments
supportable in Debian. 

IMHO Debian currently lacks software which is suitable for handhelds.
There is no suitable UI, there are no apps, there is no DRM support
(rightly so but still, a significant hindrance to what has become the
de facto usage of mass market handhelds) and there appears to be little
appetite for change and almost no new code.

> Debian can be installed very light. I mostly compiled my own apps,
> based on C, and Debian runs with a limited hardware (cpu/ram...)

To make that work it has to be pushed to such a level that it isn't
Debian anymore, e.g. by switching from glibc and dropping perl.

> Maybe we have missed something or it is not a major concern today?

I don't believe it is a major concern anymore.
 
> I would say that Handhelds (and also older computers) are the future
> way to go for Debian. Debian is light and installable on various
> machines.

Unsupported handhelds and older computers of all types are a deadend
for Debian or any actively developed OS. Just like other abandoned
ports and legacy architectures.

The future of Debian is in providing relevant software for hardware
which is current, readily available and suitable for everyday use by
those who want to use Debian.

Let dead dogs rest in peace.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: asking for advice: all dependencies incl. version numbers

[Johannes Schauer]

Hi,

Quoting FARKAS, Illes (2013-08-27 10:17:47)
> According to the developer info page of the package (http://
> packages.qa.debian.org/0/0ad.html) there have been also previous versions of
> the package "0ad", for example, versions "0.0.12" and "0.0.11". I would be
> curious to know too the list of package versions that 0ad-0.0.12, 0ad-0.0.11,
> etc depend on.

You can find Packages.bz2 files from Debian all the way back to 2005 at
http://snapshot.debian.org by downloading a sample of these (say, every few
days), you can possibly get enough data for older versions of every package
maintained in Debian since then.

Unfortunately, older versions of Packages.b2 files on snapshot.d.o contain
errors which make it impossible for dose3 to parse them. Since later in your
email you said you might want to use dose3, you might want to have a look at
this script I wrote to clean up and repair old Packages.bz2 files from
snapshot.d.o so that dose3 can parse them:

https://gitorious.org/debian-bootstrap/botch/source/examples/snapshot/download.sh

That script downloads and cleans Packages.bz2 and Sources.bz2 from
snapshot.d.org in a five day interval starting in 2005. You can find a bit more
here:

http://blog.mister-muffin.de/2012/10/12/analyzing-packages-and-sources-from-snapshot.debian.org/

The result can then be parsed with dose3.

cheers, josch


--
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/20130827084250.5326.87466@hoothoot

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Michael Meskes]

On Tue, Aug 27, 2013 at 02:11:56AM +0200, Thomas Goirand wrote:
> Guys, if you want it to happen, raise your hands *now* like Gustavo did.
> Otherwise, please everyone: let this thread die and never raise the
> topic again in this list.

Raising my hand here ...

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


-- 
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/20130827085613.ga10...@feivel.credativ.lan

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Pau Garcia i Quiles]

On Tue, Aug 27, 2013 at 10:56 AM, Michael Meskes  wrote:


> > Guys, if you want it to happen, raise your hands *now* like Gustavo did.
> > Otherwise, please everyone: let this thread die and never raise the
> > topic again in this list.
>
> Raising my hand here ...
>

One more hand.

But I'd like to stress we need *all* developers to be involved fix bugs
(esp. security) in their packages in all the supported releases, not only
in current-stable. Having a team of people like Mike, Michael, Gustavo, me,
etc to take care of EVERY package is plain impossible, especially if we
want 5 years support for the *whole* archive (IMHO Ubuntu did a smart move
in regards to support when it split the archive in main/universe/multiverse
and decided to support only main).

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

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Lars Wirzenius]

On Tue, Aug 27, 2013 at 11:53:47AM +0200, Pau Garcia i Quiles wrote:
> But I'd like to stress we need *all* developers to be involved fix bugs
> (esp. security) in their packages in all the supported releases, not only
> in current-stable.

I am afraid I am not on board for this. I do not agree with requiring
me to support old software for years and years after I've stopped using
it. It is not something that interests me as a technical challenge;
instead the task is tedious and boring.

If you think this extra couple of years of support is something you want
to work on, that's fine. Please don't think it is a goal everyone else
in Debian agrees with, or is willing to work on.

-- 
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/20130827100346.ga6...@mavolio.codethink.co.uk

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Ben Hutchings]

On Tue, 2013-08-27 at 11:53 +0200, Pau Garcia i Quiles wrote:
> 
> On Tue, Aug 27, 2013 at 10:56 AM, Michael Meskes 
> wrote:
>  
> > Guys, if you want it to happen, raise your hands *now* like
> Gustavo did.
> > Otherwise, please everyone: let this thread die and never
> raise the
> > topic again in this list.
> 
> 
> Raising my hand here ...
> 
> 
> One more hand. 
> 
> 
> But I'd like to stress we need *all* developers to be involved fix
> bugs (esp. security) in their packages in all the supported releases,
> not only in current-stable.
[...]

The challenge was: who is willing to do the work.  Your answer is: me,
but only everyone else helps.

That doesn't answer the challenge at all.

It's hard enough to get maintainers to fix bugs in current stable
(backporting can be difficult, and some just don't care), let alone
another 3 years of LTS.

Ben.

-- 
Ben Hutchings
All extremists should be taken out and shot.


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

Re: Custom Reload command/signal in upstart

[Kevin Chadwick]

> On Aug 23, 2013, at 8:45 PM, James McCoy  wrote:
> > 
> >> On Fri, Aug 23, 2013 at 04:42:15PM -0400, John Paul Adrian Glaubitz wrote:
> >> Imagine there is a vulnerability in SSH which has not been fixed
> >> yet for whatever reason. Having SSH run in this situation all the
> >> time would make the machine a target for possible attacks.
> > 
> > If all I have to do is make a connection to port 22 to start the
> > service, which would happen as part of an attack anyway, then there's no
> > added security provided by socket activation.
> 
> True. But you could have SSH listen on a different port to avoid such an 
> attack, couldn't you?
> 
> Also, I remember there was a 'knockd', which would open the port for SSH when 
> you send a certain sequence of packets to the host.
> 

So your going to add knockd a less audited process in to the mix and
have more code which includes more bugs when you could just use pubkey
or the recently added dual auth.

Or you don't and when they connect the attacker gets to choose and
maybe retry when more code and priviledged operations are carried out.

Daemons are tested completely but actually more fully audited and
tested once initialised.

Also if you are monitoring a system I would rather see the mem usage
and that any spikes include the default potential and that many spikes
can not be initiated all at once.

Like much of systemd it may seem impressive at first on the face of it
but actually holds little value or doing what are already optional
functions and has not been thought through or come from any great
experience.


-- 
___

'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/232028.14330...@smtp117.mail.ir2.yahoo.com

Re: DebianBootstrap supported in which Debian suites?

[Thorsten Glaser]

Jonas Smedegaard  jones.dk> writes:

> What I will do for now is to just add those extra build-dependencies and 
> add a note to README.source which build-dependencies can be manually 
> dropped in a custom bootstrap build.  I realize how painful it is for 

For “unimportant” packages, that is, ones below the radar of the porters,
they will never _see_ them at all: they just show up as Build-Depends-
Uninstallable in wanna-build and never be noticed.

I agree we really need to move the staged builds forward. There is some
consēnsus on how to do that, the syntax, etc. but that’s about it…

I’d also love to see Test-Depends for source packages, so that you can
build them with “nocheck” set without having those installed. (BSD ports
have this as ${REGRESS_DEPENDS}.)

bye,
//mirabilos


-- 
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/loom.20130827t140549-...@post.gmane.org

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Neil McGovern]

On Tue, Aug 27, 2013 at 11:41:58AM +0100, Ben Hutchings wrote:
> The challenge was: who is willing to do the work.  Your answer is: me,
> but only everyone else helps.
> 
> That doesn't answer the challenge at all.
> 
> It's hard enough to get maintainers to fix bugs in current stable
> (backporting can be difficult, and some just don't care), let alone
> another 3 years of LTS.
> 

Indeed. Look at the security team for example. In theory, if all
maintainers cared enough about the older packages, we woudn't need the
level of people we currently do.

So, if you want to see a longer support period, then *first* you should
join the teams who support the stable releases, and encourage others to
do the same.

Neil


signature.asc
Description: Digital signature

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Michael Meskes]

On Tue, Aug 27, 2013 at 11:41:58AM +0100, Ben Hutchings wrote:
> The challenge was: who is willing to do the work.  Your answer is: me,
> but only everyone else helps.
> 
> That doesn't answer the challenge at all.

Agreed.

> It's hard enough to get maintainers to fix bugs in current stable
> (backporting can be difficult, and some just don't care), let alone
> another 3 years of LTS.

Which brings up the interesting question how it works for stable now. How often
do bigs get fixed by the security team and how often by maintainers themselves?
How much work is this for the security team? Yes, I know, the older the
software gets, the more difficult it is to backport patches, if at all
possible.

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


-- 
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/20130827122809.ga20...@feivel.credativ.lan

Re: DebianBootstrap supported in which Debian suites?

[gregor herrmann]

On Tue, 27 Aug 2013 12:07:50 +, Thorsten Glaser wrote:

> I’d also love to see Test-Depends for source packages, so that you can
> build them with “nocheck” set without having those installed. (BSD ports
> have this as ${REGRESS_DEPENDS}.)

The perl tools also distinguish between build and test prerequisites
[0], and it would help for autopktest [1].

Cheers,
gregor

[0] https://metacpan.org/module/CPAN::Meta::Spec#prereqs1

[1] #720458
-- 
 .''`.  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
   `-   BOFH excuse #410:  Electrical conduits in machine room are melting. 


-- 
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/20130827124256.gb1...@colleen.colgarra.priv.at

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Pau Garcia i Quiles]

On Tue, Aug 27, 2013 at 2:09 PM, Neil McGovern  wrote:

Indeed. Look at the security team for example. In theory, if all
> maintainers cared enough about the older packages, we woudn't need the
> level of people we currently do.
>

IMHO the Security Team should not act as fixers themselves but more as
proxies, passing information about a security issue to the maintainer of
the package. Maintainers are not always fully aware some old version of
their package is affected by a security issue. OTOH, the Security Team is
continually monitoring CVEs, etc.

Or at least, that's how I'd like the Security Team to work. It would
alleviate the burden on them and move the bugfixing/security fixing to the
people who know the package better and are probably in touch with upstream.

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

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Thomas Goirand]

On 08/27/2013 11:53 AM, Pau Garcia i Quiles wrote:
> 
> On Tue, Aug 27, 2013 at 10:56 AM, Michael Meskes  > wrote:
>  
> 
> > Guys, if you want it to happen, raise your hands *now* like
> Gustavo did.
> > Otherwise, please everyone: let this thread die and never raise the
> > topic again in this list.
> 
> Raising my hand here ...
> 
> 
> One more hand. 

Cool, thanks. So, we are now 4, I think that's good enough to plan on
doing something.

> But I'd like to stress we need *all* developers to be involved fix bugs
> (esp. security) in their packages in all the supported releases, not
> only in current-stable. Having a team of people like Mike, Michael,
> Gustavo, me, etc to take care of EVERY package is plain impossible,
> especially if we want 5 years support for the *whole* archive

That's not my plan. My plan is to do as much as we can for the packages
we care about. For example, I need security updates for bind9, apache2,
postfix and such. I'm not interested at all in doing any Desktop
software maintenance (my laptop is using at least Stable, and sometimes
testing (when close to a release)).

> (IMHO
> Ubuntu did a smart move in regards to support when it split the archive
> in main/universe/multiverse and decided to support only main).

I don't see any smartness when declaring that things are "community
maintained" (eg: the work is done in Debian, and sync if we ask...).
It's just that they decided not to take responsibility for part of the
archive. What we could do, would be to track what needs to be patched
and what has already been fixed. If our users have a clear list of what
is maintained or not, then that's enough to me.

On 08/27/2013 12:03 PM, Lars Wirzenius wrote:
> I am afraid I am not on board for this. I do not agree with requiring
> me to support old software for years and years after I've stopped
> using it.

I don't think anyone wants to *require* this from anyone. At least
that's not my plan.

> It is not something that interests me as a technical
> challenge; instead the task is tedious and boring.

I agree, it's boring and not interesting. Though I need it for my
company online services, and so does a lot of people. My idea is just to
gather workforces of those who do it privately (like some already
reported in this thread) and put that in a single (trusted) repository,
then see how it goes. If it gains traction after Squeeze is EOL, then we
can push the idea further and make it more official, after Wheezy is EOL.

Cheers,

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/521caa35.6010...@debian.org

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Pau Garcia i Quiles]

On Tue, Aug 27, 2013 at 12:03 PM, Lars Wirzenius  wrote:

On Tue, Aug 27, 2013 at 11:53:47AM +0200, Pau Garcia i Quiles wrote:
> > But I'd like to stress we need *all* developers to be involved fix bugs
> > (esp. security) in their packages in all the supported releases, not only
> > in current-stable.
>
> I am afraid I am not on board for this. I do not agree with requiring
> me to support old software for years and years after I've stopped using
> it. It is not something that interests me as a technical challenge;
> instead the task is tedious and boring.
>

(I don't want this to sound rude or smartass but genuinely interested
because I'm surprised more DDs think like you, as I discovered in the
DreamHost thread)

What do you do with the 1 year of support Debian currently gives to
oldstable? It's also 1 year you stopped using that version, so no technical
challenge either.

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

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Thomas Goirand]

On 08/27/2013 12:41 PM, Ben Hutchings wrote:
> It's hard enough to get maintainers to fix bugs in current stable
> (backporting can be difficult, and some just don't care), let alone
> another 3 years of LTS.
> 
> Ben.

I agree with what you wrote above Ben. Though that is not in a direct
relation with what we can do for packages we care about (I already gave
a small list of very important packages for me).

Also, what one has to do currently to get packages updated in stable is
demotivating (don't get me wrong: I do understand why we have things
like they are in Stable, though one got to be blind to not see the
demotivating side of it). I don't intend to implement such
administrative overhead for updating this very-old-stable security
repository. If we are only a small group of volunteer working on it, it
will be easier to implement as well.

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/521cabed.5080...@debian.org

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Thomas Goirand]

On 08/27/2013 02:28 PM, Michael Meskes wrote:
> Which brings up the interesting question how it works for stable now. How 
> often
> do bigs get fixed by the security team and how often by maintainers 
> themselves?
> How much work is this for the security team? Yes, I know, the older the
> software gets, the more difficult it is to backport patches, if at all
> possible.
> 
> Michael

I too, would like to know these stats.

Thomas

P.S: Before this thread, I thought updates were always updated by
maintainers, and not by the security team.


-- 
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/521cacb4.8090...@debian.org

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Simon McVittie]

On 27/08/13 14:32, Pau Garcia i Quiles wrote:
> What do you do with the 1 year of support Debian currently gives to
> oldstable? It's also 1 year you stopped using that version, so no
> technical challenge either.

There does need to be some amount of overlap, because people can't
necessarily upgrade machines (particularly servers) instantaneously on
release day. Even a year of overlap seems rather long, though.

When there are serious bugs in my packages, I backport fixes to stable,
then weigh up the benefit of also backporting to oldstable vs. the time
I expect it to take and the risk of regressions. For things that didn't
merit a DSA (e.g. DoS via a remotely-triggerable NULL dereference in
desktop software), my conclusion has often been "the risk of regressions
is too close to the expected benefit, I'm not going to bother". After
all, if I accidentally introduce a crash bug, that's a "DoS" that
applies to everyone, not just people whose IM contacts were actively
trying to exploit a vulnerability.

Sorting out security vulnerabilities is something I do because I feel
responsible for packages, rather than something I do because it's fun -
doubly so for oldstable, where a diminishing number of people actually
care about the vulnerability.

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/521cb06b.2050...@debian.org

Re: Alioth.debian.org now exports project meta-data as RDF (using DOAP/ADMS.SW)

[Olivier Berger]

Hi.

Just a quick update on this.

Olivier Berger  writes:

> Hi.
>
> Since last week or so, and thanks to Lo-lan-do's work, we now publish
> RDF descriptions of every Alioth (950+) projects.
>
> See my proposed Debian devel's news bit at :
> http://wiki.debian.org/DeveloperNews#Alioth.debian.org_now_exports_project_meta-data_as_RDF_.28using_DOAP.2FADMS.SW.29
> reproduced below :
>
>
> The alioth.debian.org forge now runs the ADMS.SW FusionForge plugin,
> which publishes projects meta-data as RDF / Linked Data. 
>
> Every project's homepage  is
> then available as RDF for harvesting robots (using proper content-type
> negociation, for instance : 
>  $ curl -k -H "Accept: text/turtle" 
> https://alioth.debian.org/projects/PROJNAME/ 
> ). 
>
> The two main ontologies used are DOAP [0] and ADMS.SW [1], rendering such 
> meta-data compatible with
> other project indexes (such as meta-data published by the PTS [2]). 
>
> Note that due to the big number of hosted projects on Alioth (950+) some
> package indexes can't be exported as RDF yet. 
>
s/package/project/

FYI, the projects index was too big for PHP/Apache, but I've now fixed
the code to produce "paged" documents.

Accessing https://alioth.debian.org/projects/, requesting RDF, will
redirect to the first document /projects/?page=1, wich in turn contains
a pointer to /projects/?page=2, etc.

For the curious, this paging mechanism tends to implement parts of the
W3C LDP specs [3] (draft state).

You can test it with, for instance :
 $ curl -v -k -L -H "Accept: text/turtle" https://alioth.debian.org/projects/ 
2>&1 | less


Now, I'll write a project catalogue harvester and see what you guys are
doing, that the NSA hasn't collected yet ;)

Any comments/questions welcome.

Best regards,

[0] https://github.com/edumbill/doap/wiki
[1] http://joinup.ec.europa.eu/asset/adms_foss/home
[2] http://wiki.debian.org/qa.debian.org/pts/RdfInterface
[3] http://www.w3.org/TR/2013/WD-ldp-20130730/
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
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/87bo4jnpt9@inf-8660.int-evry.fr

Bug#697477: ITP: ostree -- Linux-based operating system develop/build/deploy tool

[telemaco]

Package: wnpp
Followup-For: Bug #697477
Owner: telemaco 

You can get more information about ostree here:

http://www.superlectures.com/guadec2013/news-from-the-gnome-ostree-project


-- 
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/20130827161538.9435.35730.reportbug@amy

Bug#721073: ITP: minetest-mod-pipeworks -- Minetest mod - Pipeworks

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: minetest-mod-pipeworks
  Version : 0~20130827+git59362e3d20
  Upstream Author : Vanessa Ezekowitz 
* License : WTFPL
  Programming Lang: Lua
  Description : Minetest mod - Pipeworks

This mod uses nodeboxes to supply a complete set of 3D pipes and tubes,
along devices that work with them.

Unlike the previous version of this mod, these pipes are rounded, and when
placed, they'll automatically join together as needed.  Pipes can go
vertically or horizontally, and there are enough nodes defined to allow for
all possible connections.  Valves and pumps can only be placed horizontally,
and will automatically rotate and join with neighboring pipes as objects are
added, as well as joining with each other under certain circumstances.

Pipes come in two variants: one type bears one or more dark windows on each
pipe, suggesting they're empty, while the other type bears green-tinted
windows, as if full (the two colors should also be easy to select if you want
to change them in a paint program).  These windows only appear on straight
lengths and on certain junctions.

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

iQJOBAEBCAA4BQJSHN6OMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8paxwQ//ciWBNPdw1jVxWjktitCk
krgqwyL/hb9mYgoWMRQQHhmM/TpuLhZMpQ3IkP+nn9jrxgkyrIP6UGCj2BcVXi25
DYxl9w6ehaWmEX35tHKXUR3hHPCLs5viAJrj4hhVC7LDWGKiD0JKcsZf5NrMHrQb
rYfI0mHrLEsIgmITHj0iz0WaioXa5o1v+NVGfyMhSYnMgbRwWI9PiytNKbDQ23fw
YW9XjxPX7nFnJk4S9EmDw7a+E56USYRaOeS6/mMPp8DjNoou/xxtEi+p2nTqIsWC
yFCblAwDy2cuRc1GpWoCoIN6l6rQtpD+OEnf6MTbOl4DVLSYVaTkiop7fSrT1VqK
un+v0pE2Ut5F2Jex6/HVtf4XkhDDi/SUW4hzAsQxqUQ45nObhEUvQT4sabxWqEH+
wW8RMyWasOMCiVM2ZqzWnJ+ytbo+SAgWmVGnbKfO0D4xmsIUrqWgKHOE1NV/TB/O
J3v7NU/FE2tFSOfnAV0pNjp/1SROrgaIwR5ljkiAkJDf+SW5tPSdQ6bvoY1glpMR
TqtdB27RUVbqQMSvGaoEuw2MGZsFQQIXN39R93CxFbvSLfAFZqLM3+Qsgz4ElT6H
Zgvy2dgSeddJUzthm/ZiFqk35Dedjtw1YTKDJquiSSAQonMjjEBHZePXp3NKHT2e
lE4xh01xgsfQNxSb0jhKjLY=
=abSK
-END PGP SIGNATURE-


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

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Russ Allbery]

Pau Garcia i Quiles  writes:

> IMHO the Security Team should not act as fixers themselves but more as
> proxies, passing information about a security issue to the maintainer of
> the package.

And what happens then if the maintainer doesn't respond?

If we're going to offer meaningful security support, we have to have a
bug-fixer of last resort, and that's the party most stressed by extending
security support.  Particularly since that for every year we extend it,
more maintainers will be uninterested in doing so for their own packages.

Alternately, we could be far more aggressive about removing packages from
oldstable, I suppose, but I don't think that's a good idea; that just
leaves our users with exactly the sorts of choices that we're trying to
avoid.  I think it's much cleaner and better for our users to offer full
security support and then retire the whole distribution at the same time.
It makes planning considerably easier, among other things.

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

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Ian Jackson]

Russ Allbery writes ("Re: Longer maintainance for (former) stable releases of 
Debian (Re: Dreamhost dumps Debian)"):
> If we're going to offer meaningful security support, we have to have a
> bug-fixer of last resort, and that's the party most stressed by extending
> security support.  Particularly since that for every year we extend it,
> more maintainers will be uninterested in doing so for their own packages.

This is for the the key point.  In practice fairly few maintainers are
going to be willing to put in extra effort for longer support - and
particularly not in the cases where this is most difficult.

So any proposal to do an LTS involves almost all of the extra security
effort falling on the LTS security team.  That we don't have an LTS
security team composed of people willing to shoulder that burden is
the reason we don't have an LTS.  Statements that "maintainers should
help out" are not encouraging.

If it turns out that there are people who _do_ want to do that work,
with a minimum of concrete help from maintainers, then of course that
is to be encouraged.

> Alternately, we could be far more aggressive about removing packages from
> oldstable, I suppose, but I don't think that's a good idea; that just
> leaves our users with exactly the sorts of choices that we're trying to
> avoid.  I think it's much cleaner and better for our users to offer full
> security support and then retire the whole distribution at the same time.
> It makes planning considerably easier, among other things.

Worse: in practice, removing packages is invisible to the users and
their package manager.  The `removed' packages just remain,
vulnerable, on the users' systems.

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

Re: Dreamhost dumps Debian

[Kevin Chadwick]

> > Large hosting companies not having made their scripts etc. good enough
> > to ride out upgrades well should have nothing to do with any decision.  
> 
> I don't think the problem here is with "Large hosting companies not
> having made their scripts etc. good enough". I don't think it has
> anything to do with size, or the type of company, or even the activity.
> I believe that the short life cycles of our stable releases is a problem
> for *MANY* companies. Dreamhost is the tree hiding the forest.

I can't see how it can be such a problem if they have well written
scripts. Run it on a new system, update the script or files to cater
for any fallout, deploy and larger companies deploy to more systems so
it is less taxing or more systems are deployed for the same effort.

Do they need to get some kind of long drawn out certification like out
of date Android images.

OTOH towards the end of a debian stable life cycle (ignoring extended
security support) you already find software that is problematic to run
atleast for desktops due to requiring newer QT to compile etc., meaning
it's often easier to use a chroot of Ubuntu etc. to run the latest
kdevelop or ffmpeg with webm support (I admit I haven't delved into the
backports yet as I only knew they existed recently, but would still be
wary of any packages with far reaching dependencies).


-- 
___

'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/575000.76357...@smtp104.mail.ir2.yahoo.com

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Kevin Chadwick]

> Alternately, we could be far more aggressive about removing packages from
> oldstable, I suppose, but I don't think that's a good idea; that just
> leaves our users with exactly the sorts of choices that we're trying to
> avoid.  I think it's much cleaner and better for our users to offer full
> security support and then retire the whole distribution at the same time.
> It makes planning considerably easier, among other things.

I don't really understand it myself as server packages and their
dependencies tend to be stable and I tend to want the latest versions of
dovecot, unbound etc..

However perhaps there is a divide here between servers which want longer
support for few packages and desktops which want stable but secure yet
as featureful as is sensible desktops.

-- 
___

'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/52116.2947...@smtp149.mail.ir2.yahoo.com

Re: Custom Reload command/signal in upstart

[Kevin Chadwick]

> Like much of systemd it may seem impressive at first on the face of it
> but actually holds little value or doing what are already optional
> functions and has not been thought through or come from any great
> experience.

It has since occured to me that it was alleged on the Gentoo list that
the real reasoning behind systemd was so that RedHat could use it on
it's cloud service where pulling servers up and down like apps is
required and so the stage of boot which systemd speeds up is actually
significant. It was also mentioned that they also wanted to benefit
from all the bug reporting, testing, patching and service file
migration that would only come if they tried to launch it for all users.

In that light the memory saving trade off for security and practicality
actually makes sense as you could save lots and lots of resources on a
massive server or server farm running hundreds or thousands of server
systems per machine etc..

For the average user or traditional server that also means that it is
like putting a round peg in a square hole. Ignoring the rest that makes
it round I bet almost all will leave it at the accordingly well
tested (for RedHat's benefit) default? of socket activation without
really thinking about it fully.

-- 
___

'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/659916.92640...@smtp122.mail.ir2.yahoo.com

Re: Custom Reload command/signal in upstart

[Kevin Chadwick]

> In that light the memory saving trade off for security and practicality
> actually makes sense as you could save lots and lots of resources on a
> massive server or server farm running hundreds or thousands of server
> systems per machine etc..

Unless someone conjures up a targeted attack (please don't) in which
case the DDOS may well be highly exacerbated or amplified in a new way.

Even then I guess the cost savings for a normal day will be worth it
for their business if they can ride any bad press.

-- 
___

'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/203862.14378...@smtp133.mail.ir2.yahoo.com

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Bastien ROUCARIES]

Le 27 août 2013 19:32, "Ian Jackson"  a
écrit :
>
> Russ Allbery writes ("Re: Longer maintainance for (former) stable
releases of Debian (Re: Dreamhost dumps Debian)"):
> > If we're going to offer meaningful security support, we have to have a
> > bug-fixer of last resort, and that's the party most stressed by
extending
> > security support.  Particularly since that for every year we extend it,
> > more maintainers will be uninterested in doing so for their own
packages.
>
> This is for the the key point.  In practice fairly few maintainers are
> going to be willing to put in extra effort for longer support - and
> particularly not in the cases where this is most difficult.
>
> So any proposal to do an LTS involves almost all of the extra security
> effort falling on the LTS security team.  That we don't have an LTS
> security team composed of people willing to shoulder that burden is
> the reason we don't have an LTS.  Statements that "maintainers should
> help out" are not encouraging.
>
> If it turns out that there are people who _do_ want to do that work,
> with a minimum of concrete help from maintainers, then of course that
> is to be encouraged.
>
> > Alternately, we could be far more aggressive about removing packages
from
> > oldstable, I suppose, but I don't think that's a good idea; that just
> > leaves our users with exactly the sorts of choices that we're trying to
> > avoid.  I think it's much cleaner and better for our users to offer full
> > security support and then retire the whole distribution at the same
time.
> > It makes planning considerably easier, among other things.
>
> Worse: in practice, removing packages is invisible to the users and
> their package manager.  The `removed' packages just remain,
> vulnerable, on the users' systems.

Why not un this case creating an empty package depending of an non existing
package ?
>
> 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/21020.58018.931259.723...@chiark.greenend.org.uk
>

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Pau Garcia i Quiles]

On Tue, Aug 27, 2013 at 7:18 PM, Russ Allbery  wrote:

> IMHO the Security Team should not act as fixers themselves but more as
> > proxies, passing information about a security issue to the maintainer of
> > the package.
>
> And what happens then if the maintainer doesn't respond?
>
>
Then, and only then, as a last resort, the Security Team / LTS Team takes
care of the problem

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

Re: Dreamhost dumps Debian

[Russ Allbery]

Clint Byrum  writes:

> Perhaps you missed the blog post [1] details?

> "About ten months ago, we realized that the next installation of Debian
> was upcoming, and after upgrading about 20,000 machines since Debian 6
> (aka Squeeze) was released, we got pretty tired."

> Even if the script is _PERFECT_ and handles all of the changes in
> wheezy, just scheduling downtime and doing basic sanity checks on 20,000
> machines would require an incredible effort. If you started on release
> day, and finished 2-3 machines per hour without taking any weekend days
> off, you would just barely finish in time for oldstable to reach EOL. I
> understand that they won't be done in a linear fashion, and some will
> truly be a 5 minute upgrade/reboot, but no matter how you swing it you
> are talking about a very expensive change.

A few comments here from an enterprise administration perspective:

First, if you have 20,000 machines, it's highly unlikely that each system
will be a special snowflake.  In that environment, you're instead talking
about large swaths of systems that are effectively identical.  You
therefore don't have to repeat your sanity checking on each individual
system, just on representives of the class, while using your configuration
management system to ensure that all the systems in a class are identical.
And in many cases you won't have to arrange downtime at all (because the
systems are part of redundant pools).

Second, with 20,000 machines, there is no way that I would upgrade the
systems.  Debian's upgrade support is very important for individual
systems, personal desktops, and smaller-scale environments, but even when
you're at the point of several dozen systems, I would stop doing upgrades.
At Stanford, we have a general policy that we rebuild systems from FAI for
new Debian releases.  All local data is kept isolated from the operating
system (or, ideally, not even on that system, which is the most common
case -- data is on separate database servers or on the network file
system) so that you can just wipe the disk, build a new system on the
current stable, and put the data back on (after performing whatever
related upgrade process you need to perform).  There's up-front
development required for your new service model for the new operating
system release, which you validate outside of production, and then the
production rollout is mechanical system rebuilds (which usually take under
10 minutes with FAI and are parallelizable).

My personal opinion is that if someone is scripting an upgrade to 20,000
systems and running it on those systems one-by-one, they're doing things
at the wrong scale and with the wrong tools for that sort of environment.

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

Re: Dreamhost dumps Debian

[Clint Byrum]

Excerpts from Kevin Chadwick's message of 2013-08-27 11:45:34 -0700:
> > > Large hosting companies not having made their scripts etc. good enough
> > > to ride out upgrades well should have nothing to do with any decision.  
> > 
> > I don't think the problem here is with "Large hosting companies not
> > having made their scripts etc. good enough". I don't think it has
> > anything to do with size, or the type of company, or even the activity.
> > I believe that the short life cycles of our stable releases is a problem
> > for *MANY* companies. Dreamhost is the tree hiding the forest.
> 
> I can't see how it can be such a problem if they have well written
> scripts. Run it on a new system, update the script or files to cater
> for any fallout, deploy and larger companies deploy to more systems so
> it is less taxing or more systems are deployed for the same effort.
> 
> Do they need to get some kind of long drawn out certification like out
> of date Android images.
> 
> OTOH towards the end of a debian stable life cycle (ignoring extended
> security support) you already find software that is problematic to run
> atleast for desktops due to requiring newer QT to compile etc., meaning
> it's often easier to use a chroot of Ubuntu etc. to run the latest
> kdevelop or ffmpeg with webm support (I admit I haven't delved into the
> backports yet as I only knew they existed recently, but would still be
> wary of any packages with far reaching dependencies).
> 

Perhaps you missed the blog post [1] details?

"About ten months ago, we realized that the next installation of Debian
was upcoming, and after upgrading about 20,000 machines since Debian 6
(aka Squeeze) was released, we got pretty tired."

Even if the script is _PERFECT_ and handles all of the changes in wheezy,
just scheduling downtime and doing basic sanity checks on 20,000 machines
would require an incredible effort. If you started on release day, and
finished 2-3 machines per hour without taking any weekend days off,
you would just barely finish in time for oldstable to reach EOL. I
understand that they won't be done in a linear fashion, and some will
truly be a 5 minute upgrade/reboot, but no matter how you swing it you
are talking about a very expensive change.

This is one of the things driving people to the more cloud/IaaS model
where individual machines are not precious and comprehensive testing is
intrinsic to the whole process. For people who already are in that model,
wheezy's release is a couple of days of test/fix/push and then "yaaay! we
can remove all of our hacks to work around 3 year old bugs in squeeze."

[1] 
http://www.dreamhost.com/dreamscape/2013/06/03/change-is-in-the-air-dreamhost-upgrades/


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

Bug#721086: ITP: minetest-mod-plantlife -- Minetest mod - Plantlife

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: minetest-mod-plantlife
  Upstream Author : Vanessa Ezetowski
* License : WTFPL, CC-BY-SA-2.0+
  Programming Lang: Lua
  Description : Minetest mod - Plantlife

 Plantlife is a combined form of the Flowers, Jungle Grass, and Poison Ivy mods
 and has been significantly rewritten and re-organized.  This mod supplies all
 three of these components and should be 100% compatible with mods that used
 the old versions.

 Its purpose is to add various kinds of flowers, cotton plants, water foliage,
 poison ivy, and jungle grass in a few sizes.  All of these are spawned as
 normal nodes and can be collected and used in any recipes that depend on the
 old mods.

 Spawning of plants is sensitive to the amount of available light.  Flowers,
 cotton, and waterlilies only spawn when there at least a signficant amount of
 light.  Seaweed will grow only in dimly-lit areas.  Jungle grass and poison
 ivy also grow in the daytime, but require less light than flowers.

 Growing of jungle grass and poison ivy will only occur for plants that are on
 the same surface that is necessary for them to spawn on, so they won't grow if
 placed on e.g. cobble or homedecor flower pot, etc.  This doesn't affect
 wall-climbing poison ivy, since it uses a different growth pattern.

 All plants use perlin noise to keep where they grow under control - no more
 random spread of plants!  In addition, the density of the plants in any region
 they appear in has been fixed and brought under control.

 Poison ivy is found sparsely among junglegrass, but will not grow near
 flowers.

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

iQJOBAEBCAA4BQJSHRDbMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYelQ/9FmjHQeIMhBOHUvSXv4+B
MemhvRQkuv/K5r5JwrU2TXGA19WLLGFz2o4PdLRLkyQieGk6lFmVpbh/6HVUTvqM
uzZJFgpxBmiZYfGzOVlfEeF+24b0ghePUI7ggK4YkaiI8NaDyQ0Ij8b31iTXidcE
1nRjpIUnAVatatE+q9Uz+ZFzvq7dqYPsVw73pPp0rbggedpwcaLlKX5JXfvV0To3
FG/mPy2s+wvv2/a8GqvLk/7PGU3s/3RxLqsoBlVOspcvFHX2RiKQVTTDgLnOrt97
QNEgGS/HJg8oKb3ow8lfmdWWjy+WbEgE60KmxSe6BVH3FagUMklF1S/cf0U/NiFB
LEUaKiyXfFDmbpXf1+cUCwhZiRjbSK8EIweEjUcRLd7lNdwXv5WLNcash8xUcAKo
AFzLUyylrkktNwX4gStb5yXneE8WjAcrQVGlwd3+97mPgZaakdyOlUV2jF5Y3awh
3CgEKl/pDGUwfCMpnDbaX4ZjAPpp9Rph0UxebNPQ25iYnX6SFd+kSFyE1ZWrT1M8
tsq74gaj2/LoHYUUEyr4CTf/By1+jQZT8H2byzI111UG2OMk8H4sZAz/lYPdZBRE
/FqjpFAEhc/amyQ7YywXYjazcptCvmLNxKePQLpMJ98FelEIU+jwJhVOUPNVfZX5
YHTHHNF4bXJVsXL4umdAxHs=
=Y7fg
-END PGP SIGNATURE-


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

Re: Dreamhost dumps Debian

[Moritz Mühlenhoff]

Russ Allbery  schrieb:
> 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? 
>
> Well, I suppose they might not, but I would find that even more
> disturbing.  

Red Hat hat upstream developers for almost all core code they support.
>From my experience these developers are involved in non-trivial RHEL 
backports (e.g. Bind) for older security releases.

Cheers,
Moritz








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

Re: Dreamhost dumps Debian

[Moritz Mühlenhoff]

Steve Langasek  schrieb:
> 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.  

We don't "deny" anything here, the current implementation of the security
release process simply doesn't allow more fine-grained control on who/how
security updates can be released.

There were some internal discussions in the past and that's certainly an
agenda topic on a future security team sprint.

> 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.

Pushing minor issues through point updates is the same process other enterprise
distros use as well; SLES and RHEL also pile up minor issues for point updates
instead of sending out a security update.

In the past such minor issues were simply left unfixed in stable. Since a few
years we've established a process to systematically keep the maintainers 
informed (Jonathan Wiltshire runs a notification bot for that).

Cheers,
Moritz





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

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Moritz Mühlenhoff]

Michael Meskes  schrieb:
> Which brings up the interesting question how it works for stable now. How 
> often
> do bigs get fixed by the security team and how often by maintainers 
> themselves?

No hard numbers, but I'd suppose half and half (i.e. cases, where the maintainer
prepared the update, which of course still needs to be reviewed/tested by the
person releasing it). 

Cheers,
Moirtz


-- 
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/slrnl1q87r.596@inutil.org

Bug#721098: ITP: python-pypump -- an interface to the pump.io APIs

[Simon Fondrie-Teitler]

Package: wnpp
Severity: wishlist
Owner: "Simon Fondrie-Teitler" 

* Package name: python-pypump
  Version : 0.3
  Upstream Author : Jessica Tallon 
* URL : https://github.com/xray7224/PyPump
* License : GPL-3
  Programming Lang: Python
  Description : an interface to the pump.io APIs

PyPump provides an interface to the pump.io APIs. The aim is to
provide very natural pythonic representations of Notes, Images,
People, etc... allowing you to painlessly interact with them.


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

Re: Dreamhost dumps Debian

[Steve Langasek]

On Tue, Aug 27, 2013 at 11:51:40PM +0200, Moritz Mühlenhoff wrote:
> Steve Langasek  schrieb:
> > 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.  

> We don't "deny" anything here, the current implementation of the security
> release process simply doesn't allow more fine-grained control on who/how
> security updates can be released.

Your answer doesn't match my experience as a maintainer.  I have had
non-"critical" security bugs answered by the security team with a request
for upload to stable-updates, *not* to the security queue.  If I were to
upload those fixes to the security queue (which has been possible for years
AFAIK, since the current security embargoed/unembargoed upload queues went
into effect), what would the security team do with them?

To me, being redirected to stable-updates constitutes a refusal/denial by
the security team to use the security updates channel.  Again, if it's a
security issue that's not important enough to be an official security
update, it's not important enough for me to spend time on it as a stable
update either.  And if the security team doesn't want a particular update as
a DSA, I don't think they should be encouraging maintainers to spend time on
a non-security stable update for the issue (which is what I've seen in the
past).

> > 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.

> Pushing minor issues through point updates is the same process other
> enterprise distros use as well; SLES and RHEL also pile up minor issues
> for point updates instead of sending out a security update.

> In the past such minor issues were simply left unfixed in stable. Since a
> few years we've established a process to systematically keep the
> maintainers informed (Jonathan Wiltshire runs a notification bot for
> that).

Well, I don't think that's a very good policy.  I don't see why, if the bug
is worth fixing in a stable release for security reasons, it should go
through the stable-updates channel instead of the security channel.  If the
argument is that there are multiple low-urgency security bugs that are not
worth individual uploads but that we should do roll-up uploads for once per
point release, I don't think the current mechanism is doing a very good job
of encouraging that.

Maybe instead of pushing this over to the SRMs, if the security team thinks
these bugs warrant a single update per package for the point release, it
would be better to have these staged in the security queue and only released
by the security team when it's point release time? 

-- 
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