Re: support for installing unconfigured systems (VM images, Debian Live images, preinstalled mobile/tablet images)

[Ben Hutchings]

On Sun, 2011-08-14 at 01:34 +0200, Marco d'Itri wrote:
> On Aug 13, Colin Watson  wrote:
> 
> > > Marco, do you have any plans for using this scheme as an option or as
> > > the default?
> Yes, because the upstream maintainers decided that the current scheme
> cannot work and will remove support for it.
> I do not know how long it will be feasible to keep it as a Debian patch.

It works today for many users.  I don't see why it would stop working
for them.

> > This is implemented in the biosdevname package, which I think we should
> I never bothered packaging it because AFAIK it is not needed with recent
> kernels (and recent hardware?).

The kernel will continue to generate names using the formats eth%d,
wlan%d etc.  There needs some userland program to generate the new
device names, whether it's in the udev package or another package.

Ben.



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

Re: support for installing unconfigured systems (VM images, Debian Live images, preinstalled mobile/tablet images)

[Marco d'Itri]

On Aug 13, Colin Watson  wrote:

> > Marco, do you have any plans for using this scheme as an option or as
> > the default?
Yes, because the upstream maintainers decided that the current scheme
cannot work and will remove support for it.
I do not know how long it will be feasible to keep it as a Debian patch.

> This is implemented in the biosdevname package, which I think we should
I never bothered packaging it because AFAIK it is not needed with recent
kernels (and recent hardware?).

-- 
ciao,
Marco


-- 
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/20110813233445.gb17...@bongo.bofh.it

Re: Release Update: Goals, Arches, Rolling, Removals

[Luk Claes]

On 08/13/2011 09:59 PM, Jakub Wilk wrote:
> * Neil McGovern , 2011-08-01, 22:07:
>> As noted in our previous mail [0DAY:DDA], bug #625449 has been opened
>> against developers-reference. This now seems to be drawing itself to a
>> conclusion. We would still welcome use of delayed queues where
>> appropriate, but this also formalises the policy over the previous few
>> years which allows DELAYED/0 for uploads fixing only release-critical
>> bugs older than 7 days, with no maintainer activity on the bug for 7
>> days and no indication that a fix is in progress.
> 
> If you decide to NMU without delay a package maintained by me[0], please
> don't bother doing it, but orphan the package instead. I won't be
> interested in maintaining such a package anymore.
> 
> [0] That is, with the Maintainer field set to me.

The conclusion in the bug was to do have a delay btw... so your comment
does not make sense to me.

Cheers

Luk


-- 
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/4e46edd3.6030...@debian.org

Re: Release Update: Goals, Arches, Rolling, Removals

[Patrick Matthäi]

Am 13.08.2011 21:59, schrieb Jakub Wilk:
> * Neil McGovern , 2011-08-01, 22:07:
>> As noted in our previous mail [0DAY:DDA], bug #625449 has been opened
>> against developers-reference. This now seems to be drawing itself to a
>> conclusion. We would still welcome use of delayed queues where
>> appropriate, but this also formalises the policy over the previous few
>> years which allows DELAYED/0 for uploads fixing only release-critical
>> bugs older than 7 days, with no maintainer activity on the bug for
>> days and no indication that a fix is in progress.
> 
> If you decide to NMU without delay a package maintained by me[0], please
> don't bother doing it, but orphan the package instead. I won't be
> interested in maintaining such a package anymore.
> 
> [0] That is, with the Maintainer field set to me.
> 

There is no need to be sulk. Debian wants to reach some quality and also
to finish release goals and NMUing is crucial to reach everything.

I don't think, that it is a problem, to react within seven days @ a bug
(RC bug in this case), or not? If not, why (except of VAC)?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.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/4e46debf.1030...@debian.org

Re: Release Update: Goals, Arches, Rolling, Removals

[Jakub Wilk]

* Neil McGovern , 2011-08-01, 22:07:
As noted in our previous mail [0DAY:DDA], bug #625449 has been opened 
against developers-reference. This now seems to be drawing itself to a 
conclusion. We would still welcome use of delayed queues where 
appropriate, but this also formalises the policy over the previous few 
years which allows DELAYED/0 for uploads fixing only release-critical 
bugs older than 7 days, with no maintainer activity on the bug for 7 
days and no indication that a fix is in progress.


If you decide to NMU without delay a package maintained by me[0], please 
don't bother doing it, but orphan the package instead. I won't be 
interested in maintaining such a package anymore.


[0] That is, with the Maintainer field set to me.

--
Jakub Wilk


--
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/20110813195927.gb2...@jwilk.net

Re: Inactive maintainer for teamspeak packages

[Steve Langasek]

On Sat, Aug 13, 2011 at 10:27:08AM +0200, Stephan Windmüller wrote:
> For more than a half year I am monitoring the state of the non-free
> teamspeak packages. A new upstream version is available for more than a
> year (bug #594318) and there is also a grave bug with an attached patch
> (bug #598304).

> However, there has been no reply by the maintainer of the packages. All
> bugs are unmodified for at least 300 days. I tried to contact him in
> January but since then he did not reply.

> Does anyone know something about this maintainer or the states of these
> packages?

I know that teamspeak-client:amd64 should be dropped from the archive now
that we have multiarch support for all the relevant X libraries... :)  So I
could probably be convinced to help with an NMU of the package on that
basis, though I wouldn't be interested in maintaining it.

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

Bug#637232: general: Multiarch breaks support for non-multiarch toolchain

[Matthias Klose]

On 08/09/2011 07:31 PM, Aurelien Jarno wrote:
> I got fed up by people reporting bug on libc6, while this problem results
> from a decision Debian to implement multiarch. People should work on
> implementing a compatibility wrapper and to make upstream toolchain
> multiarch aware. Until this is done, this bug should be kept opened.

just do it. upstream changes will only land on trunk, and afaik the outcome of
one of the multiarch sessions at Debconf was to have a multiarch-compat package
at least containing symlinks for the .o files in /usr/lib, and maybe the
/usr/include/asm symlink (replacing the one from gcc-multilib).



-- 
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/4e46b05c.3090...@debian.org

Re: support for installing unconfigured systems (VM images, Debian Live images, preinstalled mobile/tablet images)

[Colin Watson]

On Sat, Aug 13, 2011 at 02:55:51PM +0100, Ben Hutchings wrote:
> There is a new network device naming scheme that uses physical location
> (slot number or firmware-provided port number) to name PCI network
> devices.  So far this is implemented in Fedora 15 and RHEL 6.1 (!).  I
> assume this would generate consistent device names for network devices
> in VMs if the configurations differ only by MAC address.
> 
> Marco, do you have any plans for using this scheme as an option or as
> the default?

This is implemented in the biosdevname package, which I think we should
get into Debian.  I got it into Ubuntu a while back, but have been
neglecting to sync up Debian.  Alex, what's the progress of your ITP
(#617820)?  Would you like to work together based on my Ubuntu package
(https://launchpad.net/ubuntu/+source/biosdevname), which in turn was
somewhat based on the packaging provided by upstream?

-- 
Colin Watson   [cjwat...@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/20110813161559.gc32...@riva.dynamic.greenend.org.uk

Bug#637668: ITP: pinpoint -- Tool for making hackers do excellent presentations

[Andrea Colangelo]

Package: wnpp
Severity: wishlist
Owner: Andrea Colangelo 

* Package name: pinpoint
  Version : 0.1
  Upstream Author : Øyvind Kolås 
* URL : https://live.gnome.org/Pinpoint
* License : LGPL-2.1
  Programming Lang: C
  Description : Tool for making hackers do excellent presentations

Pinpoint is a simple presentation tool that hopes to avoid audience death by
bullet point and instead encourage presentations containing beautiful images
and small amounts of concise text in slides.

Features include styling of font, text-color, contrast background and text
positioning for global default and per slide overrides, video backgrounds,
pango markup inside slides, transitions (extendable through json), PDF export,
embedding commands to run for demos in slides, with editable commandline
during presentation, monitoring of source file with live updates of changed
slide for authoring.



-- 
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/20110813154312.3380.78387.reportbug@starfleet

Re: mentors.debian.net runs the debexpo code now

[Ivan Shmakov]

> Paul Wise  writes:
> On Sat, Aug 13, 2011 at 5:12 AM, Ivan Shmakov wrote:

 >> I wonder, is it possible to add a bit more magic to debexpo, so that
 >> the comments made via the Web interface would be forwarded to the
 >> list, and vice versa?

 >> Perhaps Gmane's engine (which is, IIRC, free software) could be used
 >> as an inspiration?

 > Debexpo is software so it should be possible to add anything, as long
 > as there is a person who feels motivated enough to implement it.  Are
 > you that person?

 > I imagine that it would be hard to extract mails and present them on
 > the web,

This task is indeed in my queue, but I won't probably be able to
get to it this year.

 > but you could at least give pointers to NEW/incoming, list archives
 > and the ITP bug replies on the comments page.

I. e., the pointers to the related messages (or threads) within
the archive?

-- 
FSF associate member #7257


-- 
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/86zkjd728o@gray.siamics.net

Re: Introducing Build-Recommends / Build-Core-Depends?

[Neil Williams]

On Sat, 13 Aug 2011 16:48:39 +0200
Guillem Jover  wrote:

> On Sat, 2011-08-13 at 13:28:36 +0200, Andreas Barth wrote:
> > During bootstraping a new architecture, there are sometimes ugly
> > build-dependency-loops (usually involving generating documentation
> > for the core build utilities means you need to have the architecture
> > already available; same with graphical tools). During DebConf, Wookey
> > had a talk which lead to us discussing some ideas how to support that.
> > Most packages are not affected at all by that, and current behaviour
> > isn't changing as long as package source files are not changed.
> > 
> > Below is my summary of the ideas - names et all are of course just
> > names and up to be changed. Advantage of this schema is that most
> > implementation is just package-local - the maintainer knows which
> > minimal versions his source package could produce, and just annotates
> > them. Coordination between different packages is not needed so much
> > anymore, and we could try to bring the build-dependencies more into a
> > tree-shape. Please see e.g.
> > http://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/low/745_Bootstrapable_Debian.ogv
> > for the talk.
> 
> During the Extremadura Embedded meeting in 2006 we discussed too these
> things, and I came up with the following proposals, which should be
> generic enough not only for bootstrapping but also for embedded type
> of reduced builds:
> 
>   

Sounds like we need an Emdebian / FTP / Dpkg sprint in 2011/2012 to
finally decide on one of the many ideas, get it *implemented* and stop
going around the same loop with different names but the same objective.

There's nothing intrinsically wrong with the 2006 proposal, just like
there isn't that much wrong with Wookey's DebConf11 proposal and
Andreas' current nomenclature in this thread.

Can we please stop discussing / painting the bike shed, get together and
fix this for Wheezy? It's an ideal time when so many libraries are
being refreshed for MultiArch and the revolution in cross-building
which MultiArch itself can provide.

(Note: there won't be any point in a sprint unless Guillem & Raphael
are able to attend and this would also give a chance to sort out the
TDeb stalemate at the same time.)

Guillem - at DebConf11, our DPL pushed for more sprints. All that's
needed is the date of a long weekend which you and Raphael can be in
the same place. The venue will presumably be somewhere in France /
western Europe. Steve McIntyre & Neil McGovern stepped forward to
organise the event itself.

All the team need is a date when you, Guillem, & Raphael are both
available.

Just don't schedule it over the weekend of Steve McIntyre's wedding
(Sept 10th) or I will be in BIG trouble.
;-)

(Something in late October / November this year anyone?)

It'll be REALLY disappointing if this thread just results in yet more
discussion over semantics and nomenclature.

Debian is a do-ocracy, so 6 years of discussion really needs to end with
something actually being done.

-- 


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



pgprYLVlku8Aq.pgp
Description: PGP signature

Re: Introducing Build-Recommends / Build-Core-Depends?

[Henrique de Moraes Holschuh]

On Sat, 13 Aug 2011, Andreas Barth wrote:
> Resulting packages
> 
> All binary packages built need to be functionally working, and follow
> the standard for packages on ftp-master. This means they could e.g.
> miss documentation (as long as they are not RC-buggy, i.e. they need
> to have changelog and copyright), and that it might be that not all
> binary packages are built (e.g. via the Build-Dependency-mechanimsn in
> debian/control above). Often cutting off documentation and graphical
> packages is enough for a minimal version.
> 
> To mark such packages and to be able to decide when to re-schedule the
> build, all binary-packages get the additional header
>   Build-Depends: minmal package_version 
> injected, so that one could see later on that this was a partial build
> and reschedule a new build when newly upcoming packages allow more
> binary packages to be built, or all build-dependencies are available
> and we could do a clean full build.

The resulting packages MUST NOT lack any files or symbols/modules that
would be noticed by packages that depend on it.  Otherwise, we might
have unexpected (and untracked!) partial functionality down the
dependecy graph.

Alternatively, we can annotate all packages that depend on this one for
rebuilding.  This is entirely doable, but it may require an extremely
large number of rebuilds (entire trees might need to be rebuilt a number
of times) even if you do intelligent partitioning of the rebuild set.

I actually prefer the second alternative, because it is entirely
non-trivial to know that you're missing a symbol or file that could be
used by some other package (especially if such packages do something
weird).

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110813150941.ga32...@khazad-dum.debian.net

Re: Introducing Build-Recommends / Build-Core-Depends?

[Guillem Jover]

Hi!

On Sat, 2011-08-13 at 13:28:36 +0200, Andreas Barth wrote:
> During bootstraping a new architecture, there are sometimes ugly
> build-dependency-loops (usually involving generating documentation
> for the core build utilities means you need to have the architecture
> already available; same with graphical tools). During DebConf, Wookey
> had a talk which lead to us discussing some ideas how to support that.
> Most packages are not affected at all by that, and current behaviour
> isn't changing as long as package source files are not changed.
> 
> Below is my summary of the ideas - names et all are of course just
> names and up to be changed. Advantage of this schema is that most
> implementation is just package-local - the maintainer knows which
> minimal versions his source package could produce, and just annotates
> them. Coordination between different packages is not needed so much
> anymore, and we could try to bring the build-dependencies more into a
> tree-shape. Please see e.g.
> http://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/low/745_Bootstrapable_Debian.ogv
> for the talk.

During the Extremadura Embedded meeting in 2006 we discussed too these
things, and I came up with the following proposals, which should be
generic enough not only for bootstrapping but also for embedded type
of reduced builds:

  

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110813144839.ga5...@gaara.hadrons.org

Re: Introducing Build-Recommends / Build-Core-Depends?

[Andreas Barth]

* Joachim Breitner (nome...@debian.org) [110813 16:05]:
> Hi,
> 
> just a minor note:
> 
> Am Samstag, den 13.08.2011, 13:28 +0200 schrieb Andreas Barth:
> > To mark such packages and to be able to decide when to re-schedule the
> > build, all binary-packages get the additional header
> >   Build-Depends: minmal package_version 
> > injected, so that one could see later on that this was a partial build
> > and reschedule a new build when newly upcoming packages allow more
> > binary packages to be built, or all build-dependencies are available
> > and we could do a clean full build. 
> 
> This seems to be an unfortunate choice of a field name, as it has
> different semantics than other Build-Depends fields. Why not
> "Built-With:"?

As said - names are just names now, and I assume them to change till
implementation. (But if, I think "Build-With" is better.)

> Also, this might be useful independently from your feature, and in all
> package, and is similar to what dh-buildinfo provides.

My proposal isn't restricted to the package required to bootstrapping.
However, if they make bootstrapping way easier, that's the use case
why we should invest the effort. I see more usage in other areas than
only bootstrapping; that's the reason why I tried to make it a bit
more generic.



Andi


-- 
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/20110813142636.gv15...@mails.so.argh.org

Re: Introducing Build-Recommends / Build-Core-Depends?

[Andreas Barth]

* Colin Watson (cjwat...@debian.org) [110813 15:27]:
> On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote:
> > During bootstraping a new architecture, there are sometimes ugly
> > build-dependency-loops (usually involving generating documentation
> > for the core build utilities means you need to have the architecture
> > already available; same with graphical tools). During DebConf, Wookey
> > had a talk which lead to us discussing some ideas how to support that.
> > Most packages are not affected at all by that, and current behaviour
> > isn't changing as long as package source files are not changed.
> 
> Wookey's proposal was to have Build-Depends-Stage1 (etc. - I may have
> misspelled this slightly), and for a bootstrap-aware autobuilder to
> build its way through each of the stages until it reaches the real
> Build-Depends.  I personally prefer this approach because it makes it
> clearer that the final build-depends is what we really want to reach,
> and that binaries uploaded to the real Debian archive still need to have
> all those build-dependencies in place.

Wookeys proposal is less generic and more centric to bootstrapping.
Which has its advantages, and its disadvantages.

I'm not saying that this proposal is better. It is different, and has
a different set of advantages. Plusside is that it's more generic, so
you could do more with debian/control fields, debhelper and cdbs, and
less with specific additions to debian/rules. 

Generic options are usually better IMHO, but well - YMMV.



> I think Wookey indicated that there was at least one case where more
> than one stage is required, in which case Build-Recommends does not
> really seem to solve the full problem.


As long as all stages produces binary packages which are policy
conformant working, it does. 

Consider this case:
Source: A
Build-Depends: b, c
Build-Core-Depends: 
Binary: a1
Binary: a2, build-depends b
Binary: a3, build-depends c

Source: B
Build-Depends: a1
Binary: b

Source: C
Build-Depends: a2
Binary: c


In this case, the first run on A will only produce a1. Then B could be
built, then re-build A with what is available now. This will produce
a1 and a2. Then build C. Then re-build A with all Build-Depends
installed, which will give us a full package set.





Andi


-- 
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/20110813142328.gu15...@mails.so.argh.org

Re: use flags? (was: Re: Introducing Build-Recommends / Build-Core-Depends?)

[Andreas Barth]

* Eugene V. Lyubimkin (jac...@debian.org) [110813 14:58]:
> On 2011-08-13 13:28, Andreas Barth wrote:
> > Building with core Dependencies only
> > 
> > If doing an build of the core functionality only, norecommends is
> > added to the environment DEB_BUILD_OPTIONS. This is the signal for
> > dpkg-buildpackage etc to only check for the minimal set of packages,
> > and for the debian/rules to accept if some functionality is missing
> > (i.e. might require changes to usage of ./configure).
> > 
> > (Buildds should do it in a way that they first check if however all
> > recommends are available, and only failing that setting the header -
> > makes it more likely we get full packages early; but that's an
> > implementation sidenote).
> 
> This proposal effectively means there will two ways of building the
> package: 'core' and 'full' one.
> 
> If we accept the idea there's now more than one way to build the
> package, I would like us do not limit the number of ways to '2' but
> rather extend the prospoal to set up something similar to Gentoo's USE
> flags.

Eh, sorry. This proposal doesn't say "there are exactly two ways", but
"this is the minimal set of dependencies to get at least one working
binary package out" and "with this, you get all working binary
packages". You could build with anything inbetween as well.


Also, more flags are already available via DEBBUILDOPTIONS like
"nodocs".  However, we should make sure that we consistently get what
we want for the main archive. So (except during bootstrapping time)
buildds should run with the default options.




Andi


-- 
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/20110813141234.gt15...@mails.so.argh.org

Re: Introducing Build-Recommends / Build-Core-Depends?

[Joachim Breitner]

Hi,

just a minor note:

Am Samstag, den 13.08.2011, 13:28 +0200 schrieb Andreas Barth:
> To mark such packages and to be able to decide when to re-schedule the
> build, all binary-packages get the additional header
>   Build-Depends: minmal package_version 
> injected, so that one could see later on that this was a partial build
> and reschedule a new build when newly upcoming packages allow more
> binary packages to be built, or all build-dependencies are available
> and we could do a clean full build. 

This seems to be an unfortunate choice of a field name, as it has
different semantics than other Build-Depends fields. Why not
"Built-With:"?

Also, this might be useful independently from your feature, and in all
package, and is similar to what dh-buildinfo provides.

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


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

Re: support for installing unconfigured systems (VM images, Debian Live images, preinstalled mobile/tablet images)

[Ben Hutchings]

On Sat, 2011-08-13 at 12:51 +0200, Hector Oron wrote:
> Hello,
> 
>   Getting late to discussion, apologies for that.
> 
> 2011/7/26 Jonas Smedegaard :
> > On 11-07-26 at 12:03pm, Paul Wise wrote:
> 
> >> We were thinking that it might be nice to add support to
> >> openssh-server for installing the package, not generating the host
> >> keys and then generating them on first boot. debconf pre-seeding could
> >> be one way to do that, but it would be quite specific and a more
> >> general solution might be desirable.
> >>
> >> So, I was wondering if anyone has any ideas on this topic?
> 
> > Uhm, I did have an idea for this, but have forgotten it again now.
> >
> > Cc'ing Hector who might recall our discussion on this exact issue a few
> > weeks ago...
> 
> Indeed, openssh keys as well as udev fpostinst creates
> /etc/udev/rules.d/70-persistent-net.rules which hardcodes MAC
> addresses. Maybe some other packages are as well affected.
[...]

There is a new network device naming scheme that uses physical location
(slot number or firmware-provided port number) to name PCI network
devices.  So far this is implemented in Fedora 15 and RHEL 6.1 (!).  I
assume this would generate consistent device names for network devices
in VMs if the configurations differ only by MAC address.

Marco, do you have any plans for using this scheme as an option or as
the default?

Ben.



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

Re: Introducing Build-Recommends / Build-Core-Depends?

[Colin Watson]

On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote:
> During bootstraping a new architecture, there are sometimes ugly
> build-dependency-loops (usually involving generating documentation
> for the core build utilities means you need to have the architecture
> already available; same with graphical tools). During DebConf, Wookey
> had a talk which lead to us discussing some ideas how to support that.
> Most packages are not affected at all by that, and current behaviour
> isn't changing as long as package source files are not changed.

Wookey's proposal was to have Build-Depends-Stage1 (etc. - I may have
misspelled this slightly), and for a bootstrap-aware autobuilder to
build its way through each of the stages until it reaches the real
Build-Depends.  I personally prefer this approach because it makes it
clearer that the final build-depends is what we really want to reach,
and that binaries uploaded to the real Debian archive still need to have
all those build-dependencies in place.

I think Wookey indicated that there was at least one case where more
than one stage is required, in which case Build-Recommends does not
really seem to solve the full problem.

-- 
Colin Watson   [cjwat...@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/20110813132734.gb32...@riva.dynamic.greenend.org.uk

Re: Introducing Build-Recommends / Build-Core-Depends?

[Charles Plessy]

Le Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth a écrit :
> 
> We should be able to specify in the package saying "only these
> build-dependencies are needed to get a functionally working package".
> For such an build, the packages which are not needed for building
> working core packages are annoted in an additional header (e.g.
> Build-Recommends), but are still specified in Build-Depends to not
> break the old tools.

Dear Andreas and everybody,

I think that Build-Recommends would be very useful also in the case of packages
that run regression tests with extensive dependancies.  At build time, the
package could check for the availability of the recommended build dependancies,
and skip the steps that need them if they are not available.  With such a
behaviour, it would not be needed to duplicate the information between the
Build-Depends and the Build-Recomends field.

The Build-Recomends field has been proposed in the past and most objections
were about reproducibility of the builds.  Perhaps some policy could constraint
the use of Build-Recomends in order to avoid it to be misused.
 
> To mark such packages and to be able to decide when to re-schedule the
> build, all binary-packages get the additional header
>   Build-Depends: minmal package_version 
> injected, so that one could see later on that this was a partial build
> and reschedule a new build when newly upcoming packages allow more
> binary packages to be built, or all build-dependencies are available
> and we could do a clean full build.

Another possibility would be to append something like “~minimal” (or shorter)
to their version number.  But perhaps that would break the parsing of version
number for detecting binNMUs, if +b1~minimal would not be considered so.

> Tools
> 
> This affects dpkg-buildpackage, dpkg-checkbuilddeps, and
> dpkg-gencontrol. It also (should) affect debhelper and cdbs to ease
> migration of packages to build-recommends.

mk-build-deps is inherently tolerant to missing dependancies, since it uses a
combination of equivs and apt-get -f install, but on the other hands it means
that it will not be able to allow to distinguish Build-Depends and
Build-Recommends, as apt-get -f install does not seem to install Recommends by
default. 

Have a nice day,

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


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

use flags? (was: Re: Introducing Build-Recommends / Build-Core-Depends?)

[Eugene V. Lyubimkin]

On 2011-08-13 13:28, Andreas Barth wrote:
> Building with core Dependencies only
> 
> If doing an build of the core functionality only, norecommends is
> added to the environment DEB_BUILD_OPTIONS. This is the signal for
> dpkg-buildpackage etc to only check for the minimal set of packages,
> and for the debian/rules to accept if some functionality is missing
> (i.e. might require changes to usage of ./configure).
> 
> (Buildds should do it in a way that they first check if however all
> recommends are available, and only failing that setting the header -
> makes it more likely we get full packages early; but that's an
> implementation sidenote).

This proposal effectively means there will two ways of building the
package: 'core' and 'full' one.

If we accept the idea there's now more than one way to build the
package, I would like us do not limit the number of ways to '2' but
rather extend the prospoal to set up something similar to Gentoo's USE
flags. The advantages of that idea: 

- porters/buildds/local administrators will have the greater flexibility
  to choose what the want to (re)build;
- for the architecture bootstrap this could be used for packages that
  need to be rebuilt more than once with growing set of features
  build-by-build (don't know if such packages exist).

The disadvantage is obvious: harder to implement.

I imagine it to look something like:

Source: fbreader
Build-Depends-Core: debhelper (>= 7), libbz2-dev
Build-Depends-Qt3: libqt3-mt-dev
Build-Depends-Qt4: libqt4-dev
Build-Depends-Gtk2: libgtk2.0-dev

Like in the original proposal, sets of build-depends are to be chosen by
DEB_BUILD_OPTIONS, for example DEB_BUILD_OPTIONS=use=gtk2,qt4. In
absence of 'use' flag (i.e. by default), all 'optional' packages are
built. And like in the original proposal, there's a header in the
resulting .changes (and possibly in something else) which determines what
was the value of the 'use' flag when building, like

Built-With: gtk2,qt4.

For the compatibility, dpkg-genchanges would combine all Build-Depends-*
to a single Build-Depends.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


-- 
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/20110813125846.GA1656@r500-debian

Re: Introducing Build-Recommends / Build-Core-Depends?

[Neil Williams]

On Sat, 13 Aug 2011 11:44:46 + (UTC)
Sune Vuorela  wrote:

> On 2011-08-13, Andreas Barth  wrote:
> > Introducing Build-Recommends / Build-Core-Depends
> 
> I like making it easier to bootstrap new architectures, but I don't like
> overloading the 'recommends' word with a partly different meaning.

It's not 'that' different. Recommends currently means that the majority
of installations would be expected to need it. Build-Recommends means
that the majority of builds would be expected to need it.

Personally, I'm not sure if Build-Core-Depends is better but there does
need to be a way to list particular build-dependencies as imperative
and configurable, usually along the lines of what the
upstream ./configure type script can disable.

> (And since this is my biggest issue with this proposal, I think it is
> very good :)

Agreed.

I think the idea can be extended. There isn't much point in *only*
listing those packages which are directly involved in bootstrapping
cycles today, this would only cause repeated cycling through the
packages as the packages update their functional support. It would be
useful for this proposal to be adopted by many, many packages on the
basis of what can be disabled (with judicious use of the debhelper -N
option and changes in debian/rules to the ./configure or equivalent
support) as a form of future proofing.

If your (typically library) package *can* have functionality disabled,
it should be possible to use this support to build the package that way
for bootstrapping purposes, whether or not anyone is aware of a problem
in advance.

-- 


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



pgpOg33138G83.pgp
Description: PGP signature

Re: Introducing Build-Recommends / Build-Core-Depends?

[Sune Vuorela]

On 2011-08-13, Andreas Barth  wrote:
> Introducing Build-Recommends / Build-Core-Depends

I like making it easier to bootstrap new architectures, but I don't like
overloading the 'recommends' word with a partly different meaning.

(And since this is my biggest issue with this proposal, I think it is
very good :)

/Sune


-- 
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/slrnj4cotd.p7v.nos...@sshway.ssh.pusling.com

Introducing Build-Recommends / Build-Core-Depends?

[Andreas Barth]

Hi,


During bootstraping a new architecture, there are sometimes ugly
build-dependency-loops (usually involving generating documentation
for the core build utilities means you need to have the architecture
already available; same with graphical tools). During DebConf, Wookey
had a talk which lead to us discussing some ideas how to support that.
Most packages are not affected at all by that, and current behaviour
isn't changing as long as package source files are not changed.

Below is my summary of the ideas - names et all are of course just
names and up to be changed. Advantage of this schema is that most
implementation is just package-local - the maintainer knows which
minimal versions his source package could produce, and just annotates
them. Coordination between different packages is not needed so much
anymore, and we could try to bring the build-dependencies more into a
tree-shape. Please see e.g.
http://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/low/745_Bootstrapable_Debian.ogv
for the talk.


Situation

The usual variants of build-dependency-loops mean that the source
package could still produce working binary packages, but documentation
and/or additional (e.g. -x11) packages are missing. In the few cases
where this is not possible, porters need to hand-hold the package
anyways. This proposal would like to remove the repetative parts of
bootstraping a new architecture, not the parts where the porters
really need to port.

A typical loop is e.g.
cups needs qt, which needs poppler which needs cups
to build correctly.

The typical core loops only involves changing a small number of
packages, however many packages are affected by the loop (e.g. any
package using qt or poppler as build-depends).

I'd like to have that fixed in a way that we get rid of the
build-dependency-loops as far as technically possible. Upstream is
usually better than we are by using ./configure and scaning which
packages are there, and which not, whereas we usually depend on the
full archive being already built.


Introducing Build-Recommends / Build-Core-Depends

We should be able to specify in the package saying "only these
build-dependencies are needed to get a functionally working package".
For such an build, the packages which are not needed for building
working core packages are annoted in an additional header (e.g.
Build-Recommends), but are still specified in Build-Depends to not
break the old tools.

Optionally, we could introduce Build-Core-Depends which only has
the minimum set of build-dependencies the package needs. Technically,
that's not that large a difference but just a different way of writing
it down.

Also, the binary packages in the debian/control template could have
Build-Depends specified which means that they should only be built if
those packages are actually installed (so we could do an automated
graph analyis, and also dh and cdbs could just drop them, so that
debian/rules doesn't need to reflect the dependencies); however, any
package in an binary packages build-depends needs to be part of the
source package build-depends-line so that just downloading all
build-depends does the right thing (as of now).  Packages with no
additional Build-Depends specified can be built with the minimum set
installed.


Building with core Dependencies only

If doing an build of the core functionality only, norecommends is
added to the environment DEB_BUILD_OPTIONS. This is the signal for
dpkg-buildpackage etc to only check for the minimal set of packages,
and for the debian/rules to accept if some functionality is missing
(i.e. might require changes to usage of ./configure).

(Buildds should do it in a way that they first check if however all
recommends are available, and only failing that setting the header -
makes it more likely we get full packages early; but that's an
implementation sidenote).


Resulting packages

All binary packages built need to be functionally working, and follow
the standard for packages on ftp-master. This means they could e.g.
miss documentation (as long as they are not RC-buggy, i.e. they need
to have changelog and copyright), and that it might be that not all
binary packages are built (e.g. via the Build-Dependency-mechanimsn in
debian/control above). Often cutting off documentation and graphical
packages is enough for a minimal version.

To mark such packages and to be able to decide when to re-schedule the
build, all binary-packages get the additional header
  Build-Depends: minmal package_version 
injected, so that one could see later on that this was a partial build
and reschedule a new build when newly upcoming packages allow more
binary packages to be built, or all build-dependencies are available
and we could do a clean full build.



Tools

This affects dpkg-buildpackage, dpkg-checkbuilddeps, and
dpkg-gencontrol. It also (should) affect debhelper and cdbs to ease
migration of packages to build-recommends.

It would be nice if wanna-build could cope with such pa

Re: support for installing unconfigured systems (VM images, Debian Live images, preinstalled mobile/tablet images)

[Hector Oron]

Hello,

  Getting late to discussion, apologies for that.

2011/7/26 Jonas Smedegaard :
> On 11-07-26 at 12:03pm, Paul Wise wrote:

>> We were thinking that it might be nice to add support to
>> openssh-server for installing the package, not generating the host
>> keys and then generating them on first boot. debconf pre-seeding could
>> be one way to do that, but it would be quite specific and a more
>> general solution might be desirable.
>>
>> So, I was wondering if anyone has any ideas on this topic?

> Uhm, I did have an idea for this, but have forgotten it again now.
>
> Cc'ing Hector who might recall our discussion on this exact issue a few
> weeks ago...

Indeed, openssh keys as well as udev fpostinst creates
/etc/udev/rules.d/70-persistent-net.rules which hardcodes MAC
addresses. Maybe some other packages are as well affected.

Jonas and I discussed this problem and we had some random ideas. We
discussed on allowing preinst and postinst in two stages, one stage
being a 'generic' way and the other a 'unique' way.

So basically preinst/postinst would only run generic part when image
is generated and the unique part would be executed once the image
boots in the final device.

Best regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


--
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/CAODfWeFPxw_VZRc�H4R7Z2=UqJvFs=juczexfqlvfsj-n...@mail.gmail.com

Bug#637642: ITP: libbot-training-perl -- Plain text training material for bots

[Maximilian Gass]

Package: wnpp
Owner: Maximilian Gass 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libbot-training-perl
  Version : 0.04
  Upstream Author : Ævar Arnfjörð Bjarmason 
* URL : http://search.cpan.org/dist/Bot-Training/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Plain text training material for bots

Markov bots like Hailo and AI::MegaHAL are fun. But to get them working you
either need to train them on existing training material or make your own.

This package provides a pluggable way to install already existing training
files via the CPAN. It also comes with a command-line interface called
bot-training.



-- 
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/20110813104756.8b7f140b...@carrier.mxey.lan

Re: Inactive maintainer for teamspeak packages

[Paul Wise]

On Sat, Aug 13, 2011 at 10:27 AM, Stephan Windmüller
 wrote:

> Does anyone know something about this maintainer or the states of these
> packages?

It looks like he isn't active on other packages too, for eg
aircrack-ng (RC bug) or ntfs-3g (hijacked).

-- 
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/caktje6eg+ry-6a-lwgga7ygwzouo2yfmb4mttfhmb+16jxs...@mail.gmail.com

Inactive maintainer for teamspeak packages

[Stephan Windmüller]

Hello!

For more than a half year I am monitoring the state of the non-free
teamspeak packages. A new upstream version is available for more than a
year (bug #594318) and there is also a grave bug with an attached patch
(bug #598304).

However, there has been no reply by the maintainer of the packages. All
bugs are unmodified for at least 300 days. I tried to contact him in
January but since then he did not reply.

Does anyone know something about this maintainer or the states of these
packages?

Regards
 Stephan


-- 
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/4e46355c.5080...@white-hawk.de

Re: mentors.debian.net runs the debexpo code now

[Paul Wise]

On Sat, Aug 13, 2011 at 5:12 AM, Ivan Shmakov wrote:

>        I wonder, is it possible to add a bit more magic to debexpo, so
>        that the comments made via the Web interface would be forwarded
>        to the list, and vice versa?
>
>        Perhaps Gmane's engine (which is, IIRC, free software) could be
>        used as an inspiration?

Debexpo is software so it should be possible to add anything, as long
as there is a person who feels motivated enough to implement it. Are
you that person?

I imagine that it would be hard to extract mails and present them on
the web, but you could at least give pointers to NEW/incoming, list
archives and the ITP bug replies on the comments page.

-- 
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/CAKTje6E0ce6fNcSt9ny4Ea=oT69=siep_rbivyqyjode_y7...@mail.gmail.com