Debian port bootstrap build ordering tool status
Hi, On Fri, Nov 23, 2012 at 03:48:04AM +, peter green wrote: > >Since yesterday, my tools can now finally turn the whole dependency > >graph > Does this "whole dependency graph" include the implicit > build-dependency every package has on build-essential? For source packages for native compilation, yes. What is not included is Build-Depends-Indep. I have been told that there are many problems with Build-Depends-Indep but not considering those dependencies tremendously helps to reduced the amount of cyclic dependency hell, so they should be made working for better bootstrappability. For binary packages, the implicit dependency on priority:essential is kept. For source packages for cross compilation, afaik wookey currently uses an implicit dependency on crossbuild-essential-$arch but this is not yet policy of course and has to be discussed still. > >The above case for example has no alternative solution as the cycle > >is of length two and has no other way of braking it than building > >pkg-config without libglib2.0-dev. Since this is unlikely to be > >possible > I don't see why it would be impossible to hack up the glib source > package to not rely on pkg-config. Whether that is a good idea or > not is another matter. It is not a dependency loop between the pkg-config source package and the glib2.0 source package. It is a dependency loop between src:pkg-config (we use the src: prefix to never confuse source package names with binary package names) and libglib2.0-dev. There is a loop because libglib2.0-dev has a binary dependency on pkg-config but the source package that pkg-config builds from (src:pkg-config) cannot be built without libglib2.0-dev. So even if the glib2.0 source package can be built and therefor make libglib2.0-dev available, libglib2.0-dev can never be installed because it has a binary dependency on pkg-config. pkg-config builds from src:pkg-config but src:pkg-config can never be compiled because it has a build dependency on libglib2.0-dev, which cannot be installed -> loop. The assumption that this specific loop cannot trivially (without cross compilation) be broken depends on the following two assumptions: - binary dependencies should never be modified - src:pkg-config cannot be built without libglib2.0-dev > > and since the assumption is that only > >build dependencies might be dropped when necessary but not binary > >dependencies, a possible solution might be cross compilation. > It seems pretty clear to me that there is a "core" of software that > will need to be cross-built as the first stage of bootstrapping a > port. Obviously "essential" and "build-essential" fall into this > category but while i'm sure there are ways one could hack away the > cycles and make things like pkg-config and debhelper natively > bootstrapable I don't think there is much point in doing so. It is always the call of the user to decide what is easier: - to bootstrap package A natively by braking cycles or - to make all source packages that need to be cross compiled to have package A installable cross compile Both tasks (finding out if the necessary source packages can be built with reduced build dependencies and checking how easy it is to make them cross compilable) can only be solved by a human. My tools help the user in that task by allowing to analyze the dependency graph situation for native compilation and also allow to investigate the list of source packages that have otherwise to be cross compiled to make the package installable. Comparing these two options allows the user to make a better call when he has to decide for either of those two choices. But right now, debhelper is indeed taken as part of the packages to be cross compiled to avoid a horribly messy initial dependency graph. > What i'd ideally like to see is for a tool to be able to generate a > directed acyclic graph of "build jobs" (some cross, some native, there > should be an option in the tool as to whether to preffer native or > cross-build jobs) that takes the user from having no packages for the > target architecture to having a set of bootstrap packages that can be > used to seed the "regular" building process. This is the final goal of my project. What is currently done is the native part of the above. Given a minimal build system (build-essential, priority:essential) it can devise said order of "build jobs" by braking the graph into a directed acyclic graph (DAG). The tool helps the user to find build dependencies that make most sense to be broken and uses a list of brake-able build dependencies supplied by the user to break the graph into DAG with a close to minimal number of source packages that have to be built with reduced build dependencies. Once Debian understands "build profiles" (see my last email) those will of course be taken into account as well. Until this is the case, my tool can help to identify those source packages that make sense to have build dependencies dropped. In a state where D
Re: Accepted bonnie++ 1.97 (source amd64)
On 23.11.2012 08:47, Russell Coker wrote: Format: 1.8 Date: Fri, 15 Jan 2010 20:26:55 +1100 Really? Source: bonnie++ Binary: bonnie++ Architecture: source amd64 Version: 1.97 Distribution: wheezy [...] bonnie++ (1.97) wheezy; urgency=medium I'm afraid I've removed that upload from testing-proposed-uploads. Testing and unstable (and stable!) all have the same version of the package currently, so any updates need to go via unstable, not directly to testing. Regards, Adam -- 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/e82b48309da7e04ce030335190031...@mail.adsl.funky-badger.org
Re: Accepted bonnie++ 1.97 (source amd64)
On Fri, 23 Nov 2012, "Adam D. Barratt" wrote: > On 23.11.2012 08:47, Russell Coker wrote: > > Format: 1.8 > > Date: Fri, 15 Jan 2010 20:26:55 +1100 > > Really? That was a mistake. > I'm afraid I've removed that upload from testing-proposed-uploads. > Testing and unstable (and stable!) all have the same version of the > package currently, so any updates need to go via unstable, not directly > to testing. Sure. Sorry for the inconvenience. I'll upload a new one for unstable. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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/201211232015.46644.russ...@coker.com.au
Bug#694054: ITP: drumkv1 -- old-school drum-kit sampler
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: drumkv1 Version : 0.2.0 Upstream Author : Rui Nuno Capela * URL : http://drumkv1.sf.net/ * License : GPL Programming Lang: C++ Description : old-school drum-kit sampler drumkv1 is an old-school all-digital drum-kit sampler synthesizer with stereo effects. It is provided in both forms of a LV2 plugin and a a pure stand-alone JACK client with JACK-session and both JACK MIDI and ALSA MIDI input support. -- 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/20121123114449.3671.39748.reportbug@Aspire-1410
Re: Bug#693998: ITP: linux-minidisc -- Free software for accessing NetMD and HiMD MiniDisc devices
On Fri, Nov 23, 2012 at 09:02:18AM +0800, Paul Wise wrote: > On Fri, Nov 23, 2012 at 3:16 AM, John Paul Adrian Glaubitz wrote: > > > * Package name: linux-minidisc > > Thats a strange name considering it builds and runs on MacOS, Windows, > Linux, FreeBSD and Haiku. Yes, the name is indeed somewhat confusing in that regard. But when we first came up with the project, we were initially only concerned about Linux, so the name was obvious. Finding a good name for such a project is complicated because of possible trademark violations. If you have a better idea, I'd be happy to hear it ;). Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/20121123132632.ga2...@physik.fu-berlin.de
Re: debian mate
Jon Dowland writes ("Re: debian mate"):
> On 22 Nov 2012, at 15:57, Ian Jackson wrote:
> > So if you don't like that decision it should be escalated to the
> > Technical Committee.
>
> I'm surprised that *anyone* can refer issues to tech ctte.
Of course they can. Users, upstreams, downstreams, maintainers who
are not DDs and allied organisations are all examples of
(potentially-)non-DDs who have a legitimate interest in the way we do
things.
> Has a non DD ever submitted something worthwhile?
Jakub has given some examples.
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/20655.36600.907724.952...@chiark.greenend.org.uk
Re: release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
Didier Raboud dijo [Wed, Nov 21, 2012 at 09:21:19PM +0100]: > > > > I am asking why, when I had a reason to do so, was not able to do a > > > > source-only upload. > > > > Is this a feature of dak, or a policy enforcement? > > > > > > Both. > > > > I'd argue that it's a bug in both. > > > > BTW, can we have this as a release goal for jessie, that all packages have > > been build on Debian buildd infrastructure? ;-) > > Actually, I like that way to put it as it leaves us with multiple ways > forward: > > * accept source-only; > * drop uploaded binaries; I would join this camp as well. Without the working knowledge of being a DSA or buildd-admin, I cannot assure how much would this increase our workload, but it would probably just mean rebuilding for the most popular architectures (that is, AMD64 or i386), hardware for which is readily available and should pose no additional effort to get. And it would mean IMO a good leap forward in ensuring buildability — Even more with arch:all > * (optionally: ) diff built and uploaded binaries, blame; This can be a bit more tricky. Of course, diffing the .build fails would not work, to begin with, because of the pathnames. But even diffing the shipped files — two shipped files are not guaranteed to be bit-by-bit identical, even if compiled in the same hardware. > What is yet unclear is if we want to build all (as in arch:any+all) or all > (as > in arch:any) packages on buildds. Rebuilding arch:all packages is quite important IMO. I would probably add a "rebuild when entering testing" where this to be a perfect world, to ensure continued buildability. But I know it's probably too much to ask... And it would still be incomplete (as "rebuilding anything that build-depends on this package" could still be added — And down this path we can find madness...) -- 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/20121123163002.ga6...@gwolf.org
Automated rebuilding
On Fri, Nov 23, 2012 at 10:30:02AM -0600, Gunnar Wolf wrote: > I would probably add a "rebuild when entering testing" where this to > be a perfect world, to ensure continued buildability. The proper solution to this is regular test rebuilds of testing or unstable (to make sure packages are still buildable and tests still pass; bonus points for testing as much as possible during the build process), together with regular binNMUs of "sufficiently old" packages (not that critical, but would theoretically give old packages some advantages of newer toolchains etc.). Also, if I understand correctly, testing is not self-contained wrt building, so you can either test that a package from sid rebuilds in sid (not very useful for release QA) or that a package from testing rebuilds in sid (doesn't actually prove anything useful at all). -- WBR, wRAR signature.asc Description: Digital signature
Bug#694080: ITP: avw.lv2 -- collection of Voltage Controlled LV2 modules
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: avw.lv2 Version : 0.0.8 Upstream Author : Aurélien Leblond * URL : https://sourceforge.net/projects/avwlv2/ * License : GPL, ISC Programming Lang: C++ Description : collection of Voltage Controlled LV2 modules avw.lv2 consists in a subset of the AMS internal modules ported into LV2 plugins. It provides VCOs, LFOs, Filters and other modules controlled using Voltage Controls. -- 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/20121123180758.8359.59511.reportbug@Aspire-1410
Re: debian mate
Am 22.11.2012 16:57, schrieb Ian Jackson:
Michael Schmitt writes ("Re: debian mate"):
Am 21.11.2012 10:30, schrieb Neil Williams:
As part of the Debian release team it is Adam's call to make. He's
declared his decision which is fully in line with the freeze policy and
that's that. There is no point even thinking about MATE in Wheezy any
longer. It's done, closed, ended - denied. Move along now, nothing to
see here.
Please calm down. Please, don't domineer opinions of others based on
such questionable arguments. I really prefer the open-minded approach
here. You don't have to agree but to just say "They said no, so stop
bickering" feels horribly wrong.
Neil's message was entirely appropriate.
I guess I did get lost in time there... somewhat. Because as I answered
his mail I thought he wrote that after I already told *numerous* times
that I had droped my "insane suggestion". I still think his tone was too
harsh, but I may be a bit sensitive there, so an overall apology is
needed from my part.
Like so many of these kind of arguments with are controversial outside
Debian as well as within Debian, many of the people here aren't aware
of how we do things here, who is in charge, and what decisions have
been made.
That was one of the problems... I was not aware that there was already a
decision made. I had the *strong* impression everybody just assumed it
would be too late and not worth bothering anyway. See, I am so damn
convinced, that with wheezy many desktop users will be lost and grumpy
and that is very very unfortunate. Anyway. I thought what if most
maintainers don't see the desktop users at all and for sure, all
maintainers that are concerned of desktop users as they package
desktop-related stuff like KDE, Xfce and so on and so forth would just
be interested in their own consumers. The gnome2-users just do not have
any lobby anymore, as most gnome-maintainers seem to be very happy with
gnome3 these days. So I took the liberty to become their lobby! :D.
If I re-read my mails here, I still think I made a not-so-bad job with
that. I was rather polite, calm and focused. Not trying to battle with
anyone, just trying to make a point. And I hope those willing to think
about the whole issue would at least grant me that.
And for the record, the details are somewhat blurry, but as I use Debian
for almost 10 years now at least the overall workflow is not a mystery
to me. :)
Everything Neil said was entirely true. And discussing it further is
just wasting everyone's time.
Ack.
If anyone feels that the Debian Release Team have made the wrong
decision here, there are escalation routes available within the
project. You have been told that they don't want to discuss it
further here.
And that was about the time I dropped my idea. Many many thanks to Russ
there. It was a pleasure to discuss that utterly insane suggestion in a
very calm and polite way. He did convince me, the best thing that can
happen with such issues. As I am very committed and a strong believer in
the gnome2^wMATE-ish way of ui-design, I don't like orders and decisions
without merit there.
And on that note, Russ was the only one from TC kind of voting for
"no"... at least I had (and still do) no idea the TC already discussed
the issue and came to a negative conclusion. And I did think about
raising that issue in front of the them but decided to drop the idea
before it came that far.
So if you don't like that decision it should be escalated to the
Technical Committee. But I can tell you now that if you escalate to
the TC you will get short shrift. (Or what passes for short shrift
within the TC, anyway.)
I guess you may be right. :)
So Neil was right to say "drop it".
It was not what he said, but how he said it. But as already said... I
may be overly sensitive there. :)
Ian.
regards
Michael
--
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/50afc52a.6030...@gmail.com
Re: Automated rebuilding
Hi! Andrey Rahmatullin writes: > Also, if I understand correctly, testing is not self-contained wrt > building, so you can either test that a package from sid rebuilds in > sid (not very useful for release QA) or that a package from testing > rebuilds in sid (doesn't actually prove anything useful at all). Of course it is. Testing is the next stable and you really want to build updates for stable in stable .. would be bad if one had to build security updates for squeeze in unstable first .. or wheezy once it is released. And testing won't magically become self-contained wrt building once it's promoted to stable so it needs to be before as well. Regards Christoph -- 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/87zk28qged@mitoraj.siccegge.de
Re: release goal for jessie! (Re: Source-only uploads
On 11/24/2012 12:30 AM, Gunnar Wolf wrote: > I would join this camp as well. Without the working knowledge of being > a DSA or buildd-admin, I cannot assure how much would this increase > our workload, but it would probably just mean rebuilding for the most > popular architectures (that is, AMD64 or i386), hardware for which is > readily available and should pose no additional effort to get. And it > would mean IMO a good leap forward in ensuring buildability — Even > more with arch:all +1 to all of the above Though I'm in the favor of dropping binaries rather than source-only, so that later it would be possible to do some sanity checks with the buildd and DD version of the binary packages (it doesn't have to be a bit-by-bit compare, but I'm sure we can find some interesting tests to do, like checking if control files are identical, etc...). Just a 2 cents idea, since I wont be implementing it, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50afd5a3.6090...@debian.org
Re: debian mate
On Tue, Nov 20, 2012 at 08:12:55PM +0100, Josselin Mouette wrote: > Because nobody knows anymore how to maintain libraries as complex as > bonobo, for example. And I’m pretty sure the MATE developers don’t have > the expertise. Yet. Can you please accept that there are some people who dislike gnome3, just like there are some people who don't? And that there are those who dislike it enough that they want to ensure a gnome2-like environment remains available for their own use? I've always thought that the freedom to fork is one of the more central tenets to the Open Source/Free Software philosophy: if you don't like what the developer is doing, fork, try to be better, and see what happens. But your argument against MATE seems to consist of: - They used sed!!!1! oh noes! - This bunch of people deprecated those old APIs! How DARE this other group revive it! It's fine if you don't want to maintain it. Nobody's asking you to. If someone were to upload some MATE components to Debian without consideration, and were to break (part of) the Gnome environment while doing so, then you'd have very good reason to complain. So far I've not seen many convincing arguments that this is going to happen, however. Pretty please, just drop it. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- 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/20121124001250.ga22...@grep.be
