=== TheMuso_ is now known as TheMuso [02:02] I am putting together a request for "speakers" for the next open week; is it reasonable to expect most motus follow ubuntu-devel or should I crosspost to -motu as well? [02:02] * jcastro gets anxious when sending out mass mails [02:03] feel free to cross post [02:03] you won't get savaged by a pack of rabid animals [02:05] oh don't worry, I can handle being savaged, I just like to not spam. :D [02:06] ajmitch: long time no see, how are thing? [02:06] yeah good, how are you? [02:07] ajmitch: "ahhh, release month" is the best I can say. :D [02:07] hah [02:07] yes :) [02:07] surely you're just sitting back & relaxing? [02:08] heh [02:08] spam spam spam spam === RoAk is now known as RoAkSoAx [03:15] emgent, ping === mcasadevall is now known as NCommander [03:40] jcastro: count on me for UOW [03:40] nxvl: add yourself to the prep page please! [03:40] jcastro: already done [03:40] :D [03:41] jcastro: i want to run a session explaining the development cicle, freezes, milestones and all that stuff [03:44] those sort of things are never at a decent time for me :) [04:21] <_Andrew> If I need to package a deb twice with different data for i386 and amd64 how do I name it so that they're the same package but different debs? [04:21] _Andrew: In what way different data for i386 and amd64? [04:22] NCommander: Looking for some FTBFS? [04:22] <_Andrew> Well if it's a binary package [04:23] NCommander: You might want to get gtklookat to build with the current libopenvrml so the old one can be NBS'ed out. [04:23] _Andrew, You don't want to do it that way. Create a source package with both the amd64 and i386 blobs, and then generate the correct contents for the .deb in debian/rules [04:23] NCommander, it's a bit of an API change. [04:25] <_Andrew> Is there a way you know off the top of your head to check if a build is 64 or 86 in the rules file? [04:25] I think it's DEB_HOST_ARCH [04:25] * persia checks [04:27] Hrm. Actually, I'm confused about the right rune to support crosscompilation. Just use `DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)` for now. [04:28] <_Andrew> ok [04:29] If you construct your source using the right directories, you can then install from the $(DEB_HOST_ARCH)/ directory, and it ought to do the right thing (assuming you are unpacking into directories named "i386" and "amd64"). [04:29] Note for those without context : this is about packaging the nvidia-cg-toolkit binary blobs for multiverse : this is *not* a good packaging technique in most cases. [04:34] <_Andrew> ok i'll do that then.. [04:37] persia, which package? [04:38] persia, -ENOSOURCE [04:38] makes you jump through hoops [04:44] NCommander, gtklookat [04:45] mdomsch, Yep: that's precisely the problem :) [04:45] persia, what's the current libopenvrml? [04:45] oh [04:45] I see [04:45] NCommander, build-dep is libopenvrml-dev (unversioned) [04:46] ah [04:46] That makes sense :-) [04:46] I spent a few hours on it last night : there's more changes than I usually like. [04:46] How far did you get? [04:47] My current version still doesn't parse as valid C. [04:47] (mind you, this is probably because half of it is C++, but it still ought parse) [04:48] Ouch [04:48] I take it this is going to be a major headache? [04:49] 383 days since the last Debian upload, so no hints there. [04:49] what about upstream? [04:49] Well, someone has to learn the libopenvrml API, I suspect [04:50] Argh, I *Hate* quilt [04:50] upstream doesn't distribute it in the newer releases. [04:50] wait, what? [04:50] * persia looks for evidence of consolidation [04:55] NCommander, There's a reference in the upstream changelog from 2006: "Removed lingering reference to lookat". Given that the version of openvrml we currently ship happens to produce lookat, I suspect that the issue is larger than an API. I should have looked at this last night. [04:56] * NCommander checks popcon on gtklookat [04:56] Removal may be the correct solution [04:56] I'm thinking that. [04:56] Argh [04:57] why does ubuntu's popcon suck compared to debian's :-/ [04:57] How do you mean? [04:57] On popcon, you can look up specific packages without having to open the by_inst log which is huge [04:58] Ah, yes, that would be frustrating. === lacqui_ is now known as lacqui [05:00] persia, its got 1 recent usage on Debian [05:00] and I don't even see it on the Ubuntu installation lists [05:00] (aka, no one who has popcon has it installed ... [05:02] persia, so I think it can be safely removed :-) [05:05] NCommander, Sounds good. I'll file a bug. I think openvrml needs a major packaging overhaul, based on upstream NEWS. I'm strongly of the opinion that the current package has some issues. [05:05] It likely needs to be fixed in Debian [05:05] Or should be [05:06] Oh, certainly, but I suspect the number of users is sufficiently small that it can happen in squeeze. [05:06] persia, looking at popcon (I made a type) there are 18 recent users [05:07] But 980 installations, 56 recent users, 18 recent upgrades [05:07] * NCommander isn't used to reading popcon data [05:08] NCommander, Of gtklookat? [05:08] yeah [05:09] :-/ [05:10] OK. So, it wants porting then, or people want working VRML? [05:10] persia, gtklookat was dropped upstream [05:10] Yes, a couple years ago. [05:10] I think dropping it is the correct solution [05:11] persia, it looks like the gtklookat plugin was replaced with a browser plugin or something [05:12] Oh, I don't disagree with that, I'm just wondering how to pander to the users. [05:12] so its useless if your using modern versions of the library [05:12] There's a plugin and a standalone app. [05:12] the functionality probably went into the standalone app [05:12] There's also an RC bug in Debian about openvrml FTBFS (which I'm checking). It may be worth fixing in Debian sooner, rather than later. [05:13] And according to Debian bug #459242 , it doesn't even work correctly :) [05:13] Debian bug 459242 in gtklookat "gtklookat: different results on different computers" [Important,Open] http://bugs.debian.org/459242 [05:14] persia, where's the FTBFS bug? [05:14] * NCommander was looking at RC bugs [05:14] I can get that NMUed in Debian [05:15] NCommander, http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=openvrml&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious&repeatmerged=no has two of them. [05:15] I'd suggest the new upstream to be the solution, and not shipping in Lenny. I'm testing in intrepid, but suspect I'll feel the same about that. [05:16] Note that new upstream requires NEW, so probably doesn't belong in either lenny or intrepid. [05:17] So what do we do? [05:17] Drop openvrml? [05:17] (plus it needs ubuntu delta for mozilla-ness, so sync isn't right either). [05:18] I say we drop gtklookat, and drop openvrml if my build-test fails. gtklookat belongs on the blacklist, but I don't think we should blacklist openvrml, and we can try to fix it for squeeze/jaunty. [05:18] We have openvrml-atlook now [05:18] So the newer versions have replacements [05:18] Take a look in debian/patches :) [05:18] ? [05:19] We have openvrml-lookat. Upstream doesn't. [05:19] Can we drop like the 20 odd versions of this library? [05:19] (there are like four seperate versions ...) [05:20] I only see libopenvrml8 and the NBS libopenvrml5c2a [05:20] persia: gtklookat is quite stuffed [05:21] persia: Upstream doesn't care any more, and it needs significant rewriting to deal with the API changes that openvrml has gone through [05:21] StevenK, Yeah. I'm filing a removal bug as soon as the openvrml build fails. Perhaps you'd like to action it once I'm done? [05:21] persia: Perhaps [05:22] It seems we have a few other VRML viewers, so I'm not very worried. [05:22] persia, I have libopenvrml4, 3, and 0 [05:23] or [05:23] More specificly [05:23] NCommander, If your apt-cache clean? [05:23] NCommander, Is your sources.list trim? [05:23] apt-cache clean says command not found [05:24] Yes. making a clean apt-cache comes from running any of the many apt-cache affecting tools in "update" mode. [05:24] How do I do that if apt-cache clean doesn't exist ;-)? [05:24] Mind you, you'll want a trim sources.list before you do that. [05:24] It's just intrepid [05:24] And my PPA [05:24] oh wait, I have the REVU sources list on it [05:25] O_o; [05:25] No, you run an update from adept, synaptic, update-manager, apt-get, aptitude, python-apt, libept, or something similar. [05:25] That cleans the apt-cache. [05:25] ok [05:25] Trying [05:25] (but only if you have a good sources.list) [05:25] You don't have it on yours? [05:25] (if you don't, then its not going to irk me) [05:25] No. [05:25] ok [05:25] Try updating a build chroot, and checking the apt cache therein. [05:26] So what do we do now? [05:26] (while I check) [05:26] If you find lots of libopenvrmls, please hunt and kill them. I'll take care of 5c2a and 8. [05:27] I'll deal with 5c2a [05:27] Along with gtklookat [05:27] Cool. That just leaves me 8. [05:27] anything else I can do? [05:27] 8 is also NBS? [05:27] * persia files the gtklookat bug quick so StevenK has an excuse. [05:27] No, but I believe it to be FTBFS, and require a new upstream to be sensible. [05:28] wait [05:28] Intrepid went frozen? [05:28] Right [05:28] when did that happen? [05:29] Yesterday] [05:29] s/]// [05:29] after it wasn't frozen [05:29] Hah [05:29] * NCommander whacks lifeless [05:29] so what does that mean specifically? [05:29] It won't thaw before release. That makes me sad. [05:29] * lifeless releases the hounds [05:29] * NCommander eats the hounds [05:29] * NCommander uses a phoenix down on lifeless [05:29] thats gonna smart [05:30] "Ow! That's going to bleed when my heart beats!" [05:30] NCommander, It means that if you upload something that changes anyone's build images, and you don't have an RC reason, you'll get smacked. [05:30] NCommander: it means that no changes without approval from here on in [05:30] Right [05:30] Ok [05:30] I was expecting that [05:30] I just didn't realize the actual status of the archive changed in launchpad [05:30] It's the only way to enforce the approvals. [05:30] For universe/multiverse, not yet [05:30] Read -devel-announce [05:31] StevenK, Well, it still needs approvals, but it's a little easier to get them. [05:31] * NCommander should subscribe to that ;-) [05:31] * StevenK thumps NCommander [05:31] * NCommander looks forward to finishing his first cycle with DIF jaunty [05:31] * NCommander thumps StevenK [05:31] StevenK, bug #284768 for posterity. [05:31] Launchpad bug 284768 in gtklookat "Please remove gtklookat from Intrepid" [Wishlist,Confirmed] https://launchpad.net/bugs/284768 [05:32] * StevenK logs into cocoplum again [05:32] cocoplum? [05:32] Is there ANY logic behind canonicals naming scheme? [05:32] No. [05:32] <_Andrew> sorry guys one last question, how do I authenticate my packages when I download them from myppa? [05:32] _Andrew, you can't [05:32] Limitation of PPAs [05:32] _Andrew, Copy them to some other repo, and sign that repo. [05:32] or do that [05:33] <_Andrew> So I can't distribute a key or something and download them from myppa? [05:33] Nope. [05:33] <_Andrew> That sucks [05:33] <_Andrew> hehe [05:33] _Andrew, its a known bug with Launchpad, but the fix isn't trival or even clear [05:34] persia: gtklookat and libopenvrml5c2a killed [05:34] StevenK, Cool. I suspect I'm going to want all of openvrml gone (but not blacklisted), but that can wait. [05:34] StevenK, that's an awesome power [05:34] Oh yeah [05:35] * StevenK blacklists gtklookat [05:35] <_Andrew> ok it doesn't really matter.. I've been packaging all the things I need for people to download to compile my code.. Here you can check it out.. https://launchpad.net/~andrewfenn/+archive [05:35] <_Andrew> I'm pretty proud since i've never packaged before [05:35] _Andrew, you can submit your packages for submission into Ubuntu via REVU [05:35] (although you'll have to wait for Jaunty to open) [05:35] NCommander: Hmm? [05:36] StevenK, the power to zap packages ;-) [05:36] NCommander, This particular package would do better to go through Debian, as it's a repackaging to take advantage of upstream license changes, and would solve a number of complex issues. [05:36] NCommander: It's quite fun [05:36] persia, I can see about getting it NMUed since upstream is quite dead [05:36] OK. Last meaningful NBS issue seems to be octave-gpc. [05:36] <_Andrew> I submitted a bug at debian already [05:36] persia, I have someone willing to do the NMU, which mean once squeeze is opened, I can look at getting it orphaned and then updated [05:37] NCommander, I think you're talking about a different package than _Andrew and I. [05:37] <_Andrew> and in Ubuntu linking to the debian bug and also put in where to find the deb I made incase anyone wants it [05:37] persia, I'm talking about openvrml [05:37] _Andrew, Did you run lintian against your package (nvidia-cg-toolkit) ? [05:38] <_Andrew> I have no idea hehe [05:38] That probably means no [05:38] NCommander, Getting that updated would be good. You might want to check with sam about dropping gtklookat as well. [05:38] _Andrew, lintian is a utility to find common bugs in packages [05:38] Try running lintian on your .dsc and on your debs [05:38] <_Andrew> oh right, I didn't do that for any of them [05:39] _Andrew, if your interested in getting those packages in Debian, I'd be glad to help you with that [05:40] _Andrew, You've generated a native package. You don't want to do that. [05:40] Argh [05:40] * NCommander just possibly found an RC bug [05:40] libfam-dev: Depends: libfam0 (= 2.7.0-13.3ubuntu1) [05:40] Can't install [05:40] can someone confirm? [05:40] * StevenK checks [05:40] <_Andrew> I ran lintian against my dsc and it doesn't do anything.. that's good right? [05:41] That's good. [05:41] It means there are no stupid packaging bugs, so yes :-) [05:41] _Andrew: It does do stuff, it just doesn't report anything [05:41] You also want a debian/rules get-orig-source rule to explain how to construct the source files. [05:41] _Andrew, most *NIX utilities say nothing if everything is ok [05:41] <_Andrew> yeah I know but well.. sometimes you just wanna confirm.. [05:42] :-) [05:42] _Andrew, Also, you are editorialising in debian/copyright : don't do that. Do identify the upstream authors and copyright holder. [05:42] StevenK, can you install libfam-dev? [05:42] <_Andrew> Which file? [05:42] NCommander: Yes [05:42] <_Andrew> the toolkit? [05:42] Ok [05:43] hrm [05:43] * NCommander looks at why this went boom [05:43] NCommander: Direct from archive.u.c to my machine [05:55] persia, are you on -release? [05:55] oh [05:55] TheMuso, ping? [05:56] NCommander: pong [05:56] TheMuso, can I get an ack for an upload to universe? [05:56] NCommander: bug? [05:57] You don't need an ack currently, I think [05:57] The archive is frozen [05:57] NCommander, Very much not. [05:57] So doesn't -release have to unfreeze that package [05:57] or do I misunderstand? [05:57] NCommander: only for upstrea/Feature freeze. [05:57] upstream [05:57] * NCommander is familiar with Debian freezes [05:57] but not Ubuntu [05:58] * persia files bug #284775 [05:58] Launchpad bug 284775 in openvrml "Please remove openvrml from intrepid" [Undecided,New] https://launchpad.net/bugs/284775 [05:58] So who gets a package to enter the archive if archive state == frozen? [05:58] main/restricted requires -release to say yes [05:58] NCommander, An archive admin needs to explicitly accept it. They will only do so based on the guidance of the relevant release team. [05:58] ah [05:58] I see [05:58] that makes sense [05:58] ok [05:58] * NCommander runs and hides now ;-) [05:59] StevenK, Technically, universe/multiverse requires MOTU-release to say yes, but there's been a semi-blanket "yes" said for the next few days. [06:02] OK. It's archive-consistency season. I've 76 packages on amd64 that cannot install. Could people with other architectures please run `apt-cache unmet -i | grep ^Package | wc -l` and report the results? I suspect we've some work to do. [06:03] persia: Does intrepid_probs.html agree with you? [06:03] StevenK, intrepid_probs.html is only 2 architectures, and only main. It doesn't tend to be a very interesting source of stuff to do. [06:04] Everything in there is either langpacks or kernels. [06:04] persia: Oh, yes. libhdf5-serial-1.6.5-0 essentially only contains octave-gpc to be fixed. [06:04] intrepid_outdate.html is a little more interesting [06:04] persia: octave-gpc looks to be very hard to get working against octave 3.0 [06:04] StevenK, Yeah. I looked at that, and deleted the results after fiddling a bit. [06:05] It needs someone who actually understands octave. [06:05] I managed to get it compiling stuff, but the API has changed [06:06] Since configure.in was written by someone who assumed that $major_version is always 2 [06:07] NCommander, You like playing with goats, right? [06:07] persia, er? [06:07] goats? [06:07] * persia finds an image from the O'Reilly catalog [06:07] What needs porting? [06:08] octave-gpc [06:08] I don't know anything about octave [06:09] http://sources.redhat.com/autobook/cover.jpg [06:09] What does upstream have to say on the subject? [06:09] (that should explain the goats) [06:09] It does [06:09] But it still sounds wrong [06:10] octave-gpc | 0.1.6-5 | unstable/contrib | source, amd64, arm, ia64 [06:10] I guess that explains a little [06:10] 219 days old (needed 10 days) [06:10] It's a multiverse package? [06:10] It's got no rdepends [06:11] 17152 octave-gpc 488 4 97 2 385 (Debian Octave Group) [06:12] NCommander, It's GPL multiverse though, which makes it less unpleasant. [06:12] so 488 installs, 4 regular users, 97 old users, two recent upgrades, and 384 unknowns [06:12] http://changelogs.ubuntu.com/changelogs/pool/multiverse/o/octave-gpc/octave-gpc_0.1.6-5/copyright [06:13] persia, looks dead upstream [06:14] StevenK, How do you feel about removal? [06:14] Four users, no rdepends [06:16] I'd like to discuss with pitti, first [06:16] * NCommander checks debian popcon [06:16] persia: 47 on i386 here. [06:17] sbeattie, That's a much smaller number, which is good, but still a bit to do :) [06:20] NCommander, Not so dead upstream. Last commit was only 8 months ago. [06:21] I can't see a stable release for it [06:30] persia: mind you, edos-debcheck finds 99 on i386. Not sure why some don't show up in apt-cache unmet -i. [06:30] Lack of stable release doesn't mean dead. [06:30] sbeattie, Recommends. [06:32] http://qa.ubuntuwire.com/debcheck/ provides a pretty good picture of everything that needs doing, but it's *lots* of packages. I think apt-cache unmet -i is the first stage : once those are complete, it's worth chasing the rest. [06:40] apt-cache unmet -i? [06:40] Run it [06:41] persia: odd, neither apt-cache unmet -i nor http://qa.ubuntuwire.com/debcheck/ list xxkb as uninstallable, but it definitely is, though it just needs a rebuild. [06:41] good morning [06:42] (well, I have no idea if the rebuilt package actually works as expected; it did things, but it was not obvious that it was behaving correctly and the online documentation for it is in russian) [06:42] sbeattie, Very odd indeed. [06:42] Well, that's a help. Is there a bug for that? [06:43] bug 76260 [06:43] Launchpad bug 76260 in xxkb "[UNMETDEPS] x11-common conflicts with xxkb, but xxkb depends on x11-common inderectly" [Undecided,Confirmed] https://launchpad.net/bugs/76260 [06:43] good morning dholbach [06:44] hi geser [06:44] good morning everyone ! :) [06:44] hi didrocks [06:44] hi dholbach ! [06:45] how goes it dholbach [06:45] NCommander: good good, slowly waking up :) [06:45] * NCommander gives dholbach coffee [06:45] gracias :) [06:45] dholbach: http://xkcd.com/490/ ? [06:46] geser: no no, I got up already :-) [06:50] sbeattie, Just for future note, it's a good idea to subscribe the sponsors when you attach a debdiff to a bug. [06:52] persia: I know, I was hoping for some confirmation that the ppa package actually worked correctly first; if it didn't, I was going to request it just be dropped. [06:52] sbeattie, For exceedingly unloved packages like that, we usually just test a bit locally, and if it doesn't break anything, upload, as it's probably better than the previous state. [06:53] Mind you, the package still build-deps on x-dev, which is non-ideal, but that can be fixed for Jaunty. [07:41] moring dholbach [07:41] hiya highvoltage [07:41] morning all [07:41] dholbach: will http://www.jonobacon.org/?p=1345 be available on http://video.ubuntu.com/motuvideos/ as well? [07:41] hi BugMaN [07:42] highvoltage: I'll ask him for the original [07:43] thanks dholbach! [09:27] morning everyone ! [09:27] is it? :o [09:31] morning huats ;) [09:31] morning didrocks [10:13] lfaraone: congratulations [10:24] james_w: morning! [10:25] * morgs is looking for a good example of how to handle binary package renames. Provide a transition package? [10:26] morgs: what is the reason for rename? [10:26] slytherin: we synced from debian which had some different names to hardy - e.g. hulahop -> python-hulahop [10:27] and sugar-toolkit -> python-sugar-toolkit [10:27] so it's for upgrades from hardy [10:28] morgs: do the new packages replace any files form the old one? I think you might want to take a look at how it was done for bluez. [10:28] morgs: bluez replaces everything that was present in bluez-utils. [10:29] slytherin: OK thanks, it's basically a rename, so if you had hulahop installed, you now want python-hulahop installed to replace hulahop [10:29] I'll look at bluez [10:57] dude, put openoffice3 and blender248 in repo [10:57] there is old version in repo [10:57] ok dude [10:58] thx dude [10:58] np === asac_ is now known as asac [11:03] hey morgs [11:38] persia: there? [11:43] python-webkitgtk is broken and fails to build from source :/ === thekorn_ is now known as thekorn [12:01] webkit-sharp is great and builds fine from source. boo to python [12:03] lol [12:05] * jrib sees the problem methinks and boo sharp :) [12:06] slytherin, kinda, but distracted. [12:19] persia: when you have time, just let me know if we should get merge change - http://packages.qa.debian.org/libj/libjogl-java/news/20081012T161521Z.html [12:22] hi folks [12:22] slytherin, No, we don't want to do that while it's frozen. [12:23] persia: So do you mean we can get it past RC? [12:23] s/past/post [12:23] slytherin, I mean I don't think it's worth trying to push it. We're not going to get a multiverse->universe change, so the license change isn't so important. [12:23] thanks, james_w [12:25] Ok. [12:32] persia: and what about this - http://lists.debian.org/debian-java/2008/10/msg00014.html [12:44] slytherin, How many packages? If it's only three or four, it's worth fixing. If it's more, it's probably not worth fixing. [12:45] when is it ok for pywebkitgtk_1.0.1.orig.tar.gz to be modified? [12:46] from whatever the project actually puts out [12:46] jrib, When it contains stuff you can't distribute because of the licensing. [12:46] jrib, The rest of the time, you shouldn't do that. [12:48] persia: thanks [12:51] jrib, Actually, there's also a repack exemption. If upstream produces a .bz or a .zip or something, we can repack to orig.tar.gz, but the contents must remain identical in that case. [13:00] persia, Launchpad still doesn't accept orig.tar.bz2's? [13:01] NCommander, I haven't tried in a while, but I've not seen an announcement that it does. Ask in #launchpad to be sure. [13:01] persia, I'll fire an upload to my PPA at some point to test [13:05] DktrKranz, Would you have time to test an -rt kernel for intrepid this evening? [13:08] persia: two packages, statcvs and jta [13:09] persia: A sync is preferred, right? Those packages are already fixed in Debian. [13:09] slytherin, Pushing two packages to drop two obsolete libraries is definitely worth it. Please proceed, and give me the bug numbers. [13:09] A sync is preferred iff there is nothing else that is worrisome. [13:09] If that's the only change, certainly. If the other changes are also critical, yes. Otherwise, backport the changes. [13:13] persia: The latest changelogs are not available on packages.debian.org and hence request-sync is giving trouble. I will tell you bug numbers by tomorrow. [13:14] slytherin, Sounds good. [13:15] please update python-pyglet in repo from 1.0 to 1.1 [13:17] doggymenz, The archive is frozen for the intrepid release. What does the new version bring that would be worth a possible regression? [13:17] the example code i download dont run, because its coded for the old version [13:18] the documentation i lookup doesnt work [13:18] because its documentation for new version [13:18] and there i stand with my dick in my hand using an old version [13:18] persia: sure... if I find time to break other packages with "security fixes" :D [13:18] maybe if i would have the new version, i wouldnt have this problem, not being able to grab keyboard events from NUMPAd [13:18] persia: where can I find it' [13:19] DktrKranz, Bug #281276 has a pointer. [13:19] Launchpad bug 281276 in linux-rt "Upgrade linux-rt to 2.6.27" [Undecided,New] https://launchpad.net/bugs/281276 [13:20] also if archive is frozen, then put it in backports [13:20] persia: mind subscribing me at the bug report? I'm lacking a browser right now [13:21] doggymenz, It can probably be put in backports for intrepid in early November. At this point, there's nowhere from which to backport it. [13:21] DktrKranz, Not at all. [13:21] DktrKranz, even w3m or elinks? [13:21] yep [13:21] its in debian-unstable [13:25] I need to add a ___.install for a package where I'm adding a separate transitional package. Is there any quick way to generate that? [13:28] morgs: does the package need to contain anything? [13:28] NCommander: all GNAT related packages are in hardy-proposed \o/ [13:29] * NCommander sprays some bugspray on -proposed [13:29] DktrKranz, finally :-)! [13:29] NCommander: I plan to have some testing during weekend, mind giving a look you too? [13:30] james_w: no, the transitional package doesn't need anything, but it's like the sugar package when we added sugar-activities... the files in the main package aren't installing [13:30] * NCommander would have to install Hardy on something [13:30] morgs: ah, I see. [13:30] NCommander, virtualisation is the key [13:30] morgs: not really, depends what's in it, just installing usr/ might be a good start [13:30] hm... suggestions on debian/watch of a svn repo? [13:31] NCommander: a hardy pbuilder should be enough for most packages [13:31] persia, its a good thing I hacked VTx in my BIOS to on [13:31] james_w: so putting debian/tmp/usr/* would install anything in /usr/lib/python2.5/site-packates/.../.../ etc? [13:31] (if not all) [13:31] morgs: I believe so [13:31] james_w: thanks, that's great. [13:32] * james_w realises he hasn't actually done much packaging for a long time [13:32] james_w, You've been coding, which makes up for that. [13:32] doggymenz: we only post sources from debian. The way backports work - the version has to enter first in the latest unstable version and built there without problem. Then one can request for backport and it will be evaluated. One there are no build problems for backport it will made available as test build. Only after confirmation it will be actually out in -backports repository. [13:33] just curious, has anyone here ever tried coreboot? [13:33] slytherin, yes, awhile back [13:34] NCommander: how good is it? And what are the chances that I would put my system in completely unusable state? [13:34] slytherin, pretty awesome, and pretty high if your hardware isn't supported [13:34] on that note, can someone check this for me please? http://paste.ubuntu.com/58790/ [13:36] slytherin, well pyglet is in debian-unstable, so someone should put it in backports... also someone should put blender and openoffice3 there too [13:37] doggymenz, we only backport from intrepid expect in extremely rare cases [13:37]