[00:00] unfortunately [00:01] LaserJock will help [00:01] uh oh [00:01] I was wondering if anybody has looked at maxima? [00:02] persia: There we go, new iteration up there. [00:02] Night night [00:03] Laney: DId you also adjust the status to something other than "Incomplete" ? [00:03] persia: I did [00:03] LaserJock: tuxmaniac was in earlier looking at stuff, but I haven't seen maxima. [00:03] Still 57 minutes left though. [00:03] * persia definitely needs faster builds [00:04] MOAR CORES! [00:04] Does it actually have to be sponsored by then? Can't there just be a general FF exception for bugs with this tag? [00:04] hmm [00:04] I don't think I can even build maxima in 57 minutes [00:06] * ajmitch certainly hasn't upgraded his box at home for awhile [00:07] Laney: No. This tag is to concentrate the sponsors to help meet the deadline. It doesn't mean it's an exception. [00:07] LaserJock: In that case, you'll need an FFe to get it in. That's part of what's costing me cores: I'm building heaps of things in the background. [00:12] ch-ch-ch-ch-check it out! very last item on http://ftp-master.debian.org/new.html [00:13] persia: 19 items... [00:13] persia: I was proposing there *could* be such an exception so that you guys don't need to rush tonight. I thought that was the original intent of the tag. [00:13] But I'm off to bed. Night! [00:13] devfil: Thanks for the update, but with only 47 minutes left, somehow that seems to be the wrong direction :) [00:14] Laney: It was, and the list was about 60 items on Friday. We always have to rush tonight. [00:14] persia: can I do to help you? I don't want to go to sleep right now :P [00:14] s/can/what can/ [00:14] devfil: Nothing really, unfortunately. At this point, it's mostly all sponsoring that needs doing. There's not really time for much else. [00:15] Anyone who can build and upload, please take a look at https://bugs.launchpad.net/%7Eubuntu-universe-sponsors/+bugs?field.tag=uus-pre-ff-810&field.tags_combinator=ANY&search=Search [00:16] Most of them can build in the background whilst you do something else. About half of them include fixes for bugs deemed RC in Debian. [00:16] persia: https://bugs.edge.launchpad.net/ubuntu/+source/meta-gnome2/+bug/249505 this seems to not provide additional features, so we can remove the tag [00:16] Launchpad bug 249505 in meta-gnome2 "Please merge meta-gnome 2.22.2~3 (universe) from Debian unstable (main)" [Wishlist,New] [00:16] devfil: Thanks. Please do so. [00:19] persia: done [00:20] RainCT: Were you working on bug #246017 ? [00:20] Launchpad bug 246017 in sugar "Please sync sugar 0.81.4-1 from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/246017 [00:20] mok0: Do you have time for wxwidgets? [00:20] persia: what's the best workflow for those? [00:21] LaserJock: Syncs need a test-build, rdepends check, and upload. [00:21] upload? [00:21] For these, unsubscribe the team, test, and push to the archive admins (you have 39 minutes). [00:21] Err. No. ACK & subscribe archive-admins [00:21] For the merge, it's standard merge workflow. [00:22] are the syncs actually going to be processed though? [00:22] For the new upstreams (malbolge, glom, supercollider, flashplugin-nonfree, keytouch), verify upstream, apply the diff, check the package against the current version, check rdpends, and upload. [00:22] persia: mok0 there is no in chan [00:23] I very much suspect the archive admins will impose the same rule as previously: anything requested by teh deadline will be handled. [00:23] Otherwise, we're all grumpy about the lack or archive-admins, and it gets messy (this happened once, which is why it's so important to hit the timestamp) [00:23] devfil: Indeed, but I don't know that there isn't another nick that sends hints :) [00:24] slangasek: If you're still about, can you confirm that anything that gets requested by the deadline will be processed when the archive-admins get around to it (for NEW and syncs)? [00:26] persia: only on the grounds that I'll spend my time on this in the next 24h, yes :) [00:26] slangasek: Thank you :) [00:26] And actually, from my memory of previous releases, getting NEW cleared sometimes took two or three archive-admin days (as you are all busy with other things as well). [00:27] * persia takes supercollider [00:28] 16 yet unclaimed. 33 minutes. We can do this. [00:28] persia: are we assigning to ourselves? [00:29] persia: NEW was cleared yesterday [00:29] LaserJock: I always do (although I try to remember to unsubscribe the team beforehand) [00:29] slangasek: we filled it again :-) [00:29] heh [00:29] slangasek: Wise, that. Means you only get our new stuff for tomorrow :) [00:29] slangasek: there are new packages :) [00:29] RainCT: NCommander: http://revu.ubuntuwire.com/details.py?package=sced [00:29] * persia skips sced [00:30] persia: I just grabbed nanoweb and kaya [00:34] persia: ~ppa1 kills revu [00:35] :( [00:35] we're cut off form civilization [00:36] Sorry. Putting more in the queue means more that won't make FF, and anything not scheduled for FF isn't likely to get any attention now. [00:36] You can always go fix bugs, but you'll have to wait to get sponsored. [00:36] I'm almost ready to say that I think the 3 are ready to do [00:36] Plenty of time to work on backports [00:36] * persia notices supercollider was removed from hardy for being pointlessly buggy, and decides not to put it back without a proper review. [00:38] NCommander, [00:12] ch-ch-ch-ch-check it out! very last item on http://ftp-master.debian.org/new.html [00:39] Nice work directhex [00:39] now if only someone would sponsor codeblocks for me [00:39] * RAOF notes that when trying to preserve a file across dh_clean calls it's important that it doesn't have the suffix ".orig" [00:39] Well, I should have a bunch of free DDs in half an hour [00:39] NCommander, turns out my sponsor was getting svn-buildpackage syntax wrong [00:40] NCommander, all i need is for NEW to take less than 20 minutes, for a sync in intrepid! :p [00:40] directhex: That's exceedingly unlikely. [00:40] Well, it could wait a few months === superm1|away is now known as superm1 [00:40] my pangomm package is still stuck in the NEW queue [00:40] Take that, build-twice-in-a-row bug! [00:41] yeah, but nobody likes pango. this is visual basic we're talking about! who can say no? [00:41] RAOF: Can I pull you away from deep bug fixing for 19 minutes? We've only 13 bugs left to sponsor. [00:41] RAOF, i had an infuriating one of those for monodoc. spent literally hours on it. was unpatching before cleaning. oops. [00:41] persia: This bug fixing is also for FF. [00:41] RAOF: Awww... [00:41] persia: This is gnome-do-plugins 0.6, which I'd quite like in :) [00:42] superm1: What do you have planned for the next 18 mintues? Time to help out with the queue? [00:42] persia, is the freeze defined that hard down to 18 minutes? :) [00:42] bddebian! We need you. We've only a few bugs left in https://bugs.launchpad.net/%7Eubuntu-universe-sponsors/+bugs?field.tag=uus-pre-ff-810&field.tags_combinator=ANY&search=Search and only 18 minutes to get them uploads. [00:42] superm1: Yep. [00:42] persia, i can in a few minutes sure [00:43] superm1: Great. we've only 14 left, but there's not much time. [00:43] UUS queue? [00:43] persia: Bah, I'm useless anymore [00:43] persia: glom is Fix Released for Intrepid (has open Hardy task) shall I remove the tag? === Kopfgeldjaeger is now known as Kopfi|offline [00:43] bddebian: I know you. You can sponsor stuff like nobody else. [00:43] heh [00:43] LaserJock: Please. [00:43] SRUs are clearly not FF stuff. [00:44] An even dozen left. Who likes Flash? Should we use Flash 10? Now's your chance to make it work! [00:44] persia: I don't like that SRU in general... [00:44] Also, there's a nice upstream bugfix release of WX there. [00:45] devfil: Comment in the bug. For the next 15 minutes, I'm *only* interested in FF stuff. [00:45] * james_w curses as testing *neur has left him in a character set he doesn't recognise in his terminal [00:45] It's freakin' feature freeze already? [00:45] last time i tried flash 10 it was slow as molasses [00:46] compared to 9, anyway [00:47] bddebian: In 13 minutes. That's why I'm looking for all the sponsors I can find to hit the last bugs. [00:47] okay i'll take this merge one [00:47] for gxneur [00:48] Shite, I don't even think I have a working Intrepid pbuilder at the moment :( [00:48] superm1: If you're daring gxneur, perhaps you'll also take the rest of *neur? [00:48] (xneur, kxneur) [00:48] Hi, are there any way to receive email notifications on new comments to my REVU packages? [00:48] i can't commit that far, i'm multitasking on some other stuff right now [00:48] joh: Subscribe to the REVU email list, but you get *all* revu comments. [00:49] superm1: gxneur says it requires xneur to go though [00:49] gar. [00:49] taking libcairo-ruby [00:49] persia: *shrug* I guess I can filter mine out. Thanks. [00:49] Down to 11! With 11 minutes to go. [00:50] 1 for minutes [00:50] s/s/ [00:50] / [00:51] persia, sorry i dont think i'll be able to do any of these within 11 minutes, my sbuild can't exactly pull these packages fast over 3G/bluetooth internet [00:51] bddebian: Does the updated lordsawar beat all previous versions without question on all fronts? [00:51] superm1: I understand. Thanks for trying. Anything you're feeling confident about in that timeframe would be great. Anything else can apply for FFe. [00:51] ok, *neur build, install, start tested [00:51] bedtime. [00:52] comments in the respective bugs [00:52] superm1: There's also the option of trusting james_w, if you're in a trusting mood. [00:52] persia: Quite a few bugfixes [00:52] bddebian: OK. Pushing a sync request then. [00:52] i'm not much of a trusty kind of person with people that i've never even chatted with... [00:53] persia: Of course it probably has 0 users anyway :) [00:53] superm1: that's sensible [00:53] bddebian: It has you, which ought be enough for any upstream :) [00:53] james_w, if you've got build logs however? [00:53] persia: Heh [00:53] can you upload those? i'd be more apt to sponsor if i could see that these syncs really did build OK [00:53] persia: what a good way to check rdepends? libcairo-ruby has a few [00:54] persia: Where might I find info about the REVU mailing list? [00:54] LaserJock: Well, you could check for API/ABI type changes. No idea how to do that for a Ruby library. [00:54] joh: Used to be on REVU. Ask NCommander where it went. [00:55] superm1: not complete, sorry. my scollback isn't big enough for the start of the first. [00:55] persia: that's why I dislike working on libs ;-) [00:55] james_w, ah okay. if you switch to sbuild someday, it keeps logs for you :) [00:55] superm1: these packages should get an easy FFe I think though. [00:55] james_w, yeah probably [00:56] I suspect much of this will, I just thought we'd save some people some effort. [00:56] superm1: I'll consider it. Also, we did have breakfast one morning, but that's not good grounds for trusting my technical knowledge :-) [00:56] how many of you are going to the coffee meeting thing in September? [00:56] james_w, yeah after i /whois'ed I recognized your name, but you understood what i meant :) [00:56] persia: Alright, thanks. [00:59] Anyone got time to review my package? http://revu.ubuntuwire.com/details.py?package=alarm-clock-applet thanks! [01:01] Gah. Out of time :) [01:01] is that it? [01:02] nice work everyone, same time next year? [01:02] * persia sounds the big buzzer, and thanks everyone for playing [01:02] Oh, well. I'll push Do through Debian and then file a FFe for the sync instead. :/ [01:02] joh: I'm installing it right now [01:02] joh: do you have a homepage for it? [01:03] kolby: Great, thanks. Yes I do: http://alarm-clock.pseudoberries.com/ [01:03] james_w: Nah: we'll do this again in mid-February. [01:03] Dear motu-release, I would appreciate an email outlining procedures, expectations, and limitations for the freeze, would someone be able to do that? [01:03] james_w: Sending a request to the ML for that would likely be better. That said, there are docs on Feature Freeze exceptions on the wiki. [01:04] persia: yeah, but "same time in six months" just isn't as snappy. I'm lobbying to get the release schedule changed to make my jokes work better. [01:04] It's mostly a matter of filing a bug, justifying the changes, including the diff for review, and subscribing motu-release. [01:05] I guess my package just missed the deadline :P [01:05] james_w: I see. Count me in the opposition: I really don't want to see more than 15 weeks between archive open and feature freeze: it's just too much to try to clean up after. [01:05] joh: For intrepid, yes. [01:05] * persia sends apologies to the remaining 11 unsponsored bugs. [01:05] * joh blames non-existant REVU email notifications [01:05] persia: yeah, I should do that. There's a lot of new people, and I seem to remember there being a discussion six months ago where someone said "we should have explained our expectations, and how we would judge the requests better". I think a mail is a good idea. [01:06] joh: Well, actually, better to blame the fact that we had only one REVU day all cycle. We usually have 10-15, so this cycle almost nothing got in. [01:06] joh: If this is the same alarm clock applet I'm thinking of. Then it's very good. Got me to work on time. [01:08] persia: Ah, well I was late with my reply as well :-( [01:08] kolby: Might be ;-) Does it look like the screenshots from the website? [01:09] joh: There's always next cycle. The REVU Coordinator for intrepid+1 has already started planning, and we can expect it to be very dynamic. [01:09] Release is only two months away, after which it's a free-for-all for REVU and the like. [01:09] persia: Yeah, I've got PPA packages anyways so it's not that big of a deal :-) Would be cool to have it in universe though! [01:10] joh, where what went? [01:10] NCommander: Information on the REVU mailing list. [01:10] thats been broken sinec before I became an admin [01:10] Its a mailer issue [01:11] Aw... Would be very nice with email notifications in REVU. Where do I file the feature request? ;) [01:12] Talk to sistpoty on #ubuntuwire, he's the sysadmin [01:12] Ah, already there - https://blueprints.launchpad.net/revu/+spec/global-subscription [01:12] Launchpad #145267 [01:12] Launchpad bug 145267 in libgems-ruby "Add rubygems bin to PATH" [Low,Fix released] https://launchpad.net/bugs/145267 [01:13] Oh dear lord no. [01:15] ScottK, ? [01:15] *only did that so I could find that bug* [01:15] Gems in the path. Argh. [01:15] But as I read it [01:15] ARGH [01:15] * ScottK files bug. [01:15] For the love of stupid [01:15] CPAN drops in the path, but removing that from Perl would close to impossible [01:15] ScottK, see the message on the list "How not to work with upstream" [01:16] Yeah. [01:16] Oh well, nice work everyone, I'm off. Nite! [01:18] Bug 262063 [01:18] Launchpad bug 262063 in libgems-ruby "rubygems bin in PATH potentially breaks other applications and violates all sense of decency in packaging." [High,Confirmed] https://launchpad.net/bugs/262063 [01:18] lol [01:23] Does Soyuz support UNACCEPT? [01:26] persia: ok [01:27] TheMuso, i just used update-maintainer, and that was the result. is that behavior changed in the intrepid release of devscripts? [01:28] yep [01:28] we should backport it then [01:32] ScottK, I think this bug rates Critical since it also greatly violates the Debain FHS [01:32] And it could easily hose someones system if installed [01:32] superm1: yeah its been changed. [01:32] (it installs symlinks into /usr/local) [22:27] superm1: Who was the sponsor? [22:27] ScottK, how can I find out? [22:28] Grab the .dsc file from the source package, run gpg --verify on it. [22:28] That'll give you the key ID. [22:28] You can usually search in LP or on the Ubuntu key server for that. [22:29] well that can't be right. it says christian marrilat. which means that it was a sync then [22:29] and yeah the dist is unstable, so nullack requested the sync i suppose [22:29] lets see who ack'ed it [22:31] superm1: I'm less interested in knowing who it is than that they get feedback on the issue to the mistake isn't repeated. [22:31] okay looks like LucidFox was the one who ack'ed. [22:32] yeah exactly [22:32] An awful lot of packages FTBFSed because of that, but I forget to fix it and complain. [22:32] Damn uni. [22:32] Well we know who's job it is to complain then. [22:32] err complain/fix it [22:32] well i've already fixed 3 packages that got hit by it in the last day [22:32] i'm not sure how many are left [22:33] wgrant & superm1: If you can point me to the break list, I can help with the transition [22:34] NCommander, well basically look at the rdepends on liblame0 [22:34] anything on that that hasn't been rebuilt yet [22:34] Oh that's pretty [22:34] i'm not sure what has or hasn't; that's what transition bugs are for, to look at the list and keep track of it :) [22:35] NCommander, well if lucidfox comes around soon, be sure to split up work his way. i'm not sure it's worth making a transition bug at this point, but at least to finish off what's left [22:36] ScottK: May I /msg you? [22:36] Sure [22:50] Hmm, I'll handle some of these lame rebuilds [22:50] * Laney facepalms [22:51] http://paste.ubuntu.com/41369/ [22:55] lol at Laney [22:55] :) [22:56] Launchpad needs a binary rebuild function ala Debian [22:57] * Laney titters [22:58] woo, backport queue grows smaller and smaller [23:03] binary rebuild wouldn't solve this transition problem [23:03] you still need to modify build-depends on all these [23:03] oh d'oh [23:03] the dev package's name changed? [23:05] yup [23:05] Yep, that was the facepalming [23:05] I'll do a transition bug if you want to coordinate on it [23:08] You're going to need a transitional package anyway for upgrades, so why not add the old package names back for transition, then you just HAVE to do rebuilds. [23:09] ScottK: There's a Conflicts/Replaces set. Is that enough? [23:09] i've wondered about this, why *do* you need transitional packages on upgrades? how come the new dependencies aren't just sorted out? [23:10] I'm far to tired to remember right now, but I think not. === spass is now known as spas_a === spas_a is now known as spas_awej [23:11] I've no experience with this beyond doing simple rebuilds, so education much appreciated [23:11] Conflicts/Replaces doesn't quite work on dist-upgrades, for reasons which escape my mind for the moment. [23:12] So what needs to be done besides adjusting the build-deps of liblame0's rdepends? [23:12] was someone spreading word about it not working many years ago without explanation perhaps, and now it's just regular practice? a'la all those access points you find in airports called "Free Public Wifi" [23:12] which are of course really just adhoc networks broadcast from laptops due to a windows bug [23:14] superm1: I can hunt down a bug filed agains Miro by... pitti? For a real transitional package to fix upgrades if you like. [23:15] RAOF, actually it would be a good educational tool if you could see it === frostburn2 is now known as frostburn [23:17] superm1: Hm. It was pitti, but he just said "Miro needs to provide a real transitional package". [23:17] slangasek explained it to me once and it made sense. As I said, I'm too tired to recall. [23:19] normally, you want transitional packages for those packages that a user will have installed directly (i.e., nothing above it in the dependency graph) [23:19] so in the case of a library that came in from dependencies, you don't need such things? [23:19] so not for -data or -common or lib$foo [23:20] superm1: is there a package name I should be grepping for in scrollback? [23:20] slangasek, well liblame-dev was renamed libmp3lame-dev [23:20] and the person forgot to tell everyone who build-depended on liblame-dev to rebuild against the new package [23:20] heh [23:21] oh, hey lookie, libmp3lame-dev snuck into universe on hppa+sparc [23:21] * slangasek shunt [23:22] slangasek: So all we need to do is adjust the b-ds? [23:23] superm1: so for build-depends, /if/ the best procedure is to provide a transition rather than just forcing the reverse-deps to rebuild all at once (and I'm always a fan of gradual transitions for such things), you have to take into consideration whether anything has a versioned build-dep [23:23] since if there's a virtual build-dep, you have to use a real transitional package, due to lack of support for versioned Provides: [23:23] ah [23:23] Laney: how many packages are we talking about? [23:23] Laney, so what i'm doing on the packages i've touched is making them b-d on libmp3lame-dev | liblame-dev so that everything is still backportable [23:24] slangasek: Approximately 12 [23:24] superm1: Right, makes sense [23:26] Laney: yeah, I don't have a strong opinion then; I guess none of these packages are from Debian since Debian doesn't have lame, so it's not like there's going to be a big package delta to maintain as a result of touching the packages [23:26] slangasek, I thought Debian has lame in non-free [23:27] no, there are patent encumberance issues [23:27] * Laney nods [23:27] superm1: Which ones are you going to do, then? [23:27] oh [23:27] Ok [23:28] * NCommander continues to cut the backport NEW queue down to size [23:28] hm, i have a zabbix-proxy.init in my debian/ dir [23:28] and a dh_installinit -p $(PKG_PROXY_MYSQL) --name zabbix-proxy in my debian/rules [23:28] it should install the init file then, no? [23:29] any motu-release about? [23:29] NCommander: My inbox exploded due to your triaging today ;) [23:29] good work! [23:30] Laney, I haven't started on dapper or gutsy yet [23:30] (I'm not going to bother with feisty, its leaving support in a month, then I'm simply going to close every bug) [23:30] Surely the project will just be deleted? [23:30] Nope [23:30] Not if backports horay or warty are any indication. [23:31] or edgy [23:31] Laney, i did mythtv,mythplugins, and transcode so far [23:31] NCommander: hmm? by 'NEW' queue, do you mean something other than the binary/source NEW queue in LP? [23:31] He means bugs int he "New" status [23:31] ah [23:31] the backports queue to make sure things can actually be backported before we point you at it ;-) [23:32] superm1: OK, I'm just building mplayer atm [23:32] Laney, I recommend you add a rule to move all my emails to the trash, I already cut the que down to 47% NEW, so there is a lot more work to be done [23:32] Laney, okay [23:32] (it was 82% new yesterday) [23:32] Laney, was VLC on the list of rdepends? [23:32] superm1: No [23:33] Oh, mplayer FTBFS [23:36] Laney, looking at the list of people who are ubuntu backports, I'm probably going to be flooding the inbox of a few core-devs :-P [23:36] is their a place I can go to get a package created? Their is a walkthrough, that works well, that installs my printer. But I've never been able to create a working package to reproduce the results. [23:36] NCommander: At least they'll recognise your name when you come to apply for things [23:36] ;) [23:37] Yeah [23:37] "Application for MOTU rejected" [23:37] "Sends too many emails cited as reason" [23:38] NCommander: I imagine most of them are used to a lot of mail, as long as it's useful mail I expect they won't mind ;-) [23:38] "Make this man an archive admin right away" [23:38] LaserJock, my inbox says I've caused over 100 new messages [23:38] That may be a little excessive [23:38] Laney, https://bugs.edge.launchpad.net/hardy-backports - that looks much better considering what it used to look like [23:38] I saw, it doe [23:38] s [23:38] NCommander: I *used* to get ~ 1000 bugmails a day [23:39] Laney, want to help with dapper backfixes ;-)? [23:39] NCommander: I'll have a look next week, busy between now and then (except for tomorrow night) [23:40] Well, doing dapper ones is a hell of a lot more incompletes [23:40] I bet [23:40] Oh ffs, nothing wants to build [23:40] * NCommander has done dapper security fixs [23:41] * Laney stamps his feet [23:41] Laney, what's the bug? [23:41] NCommander: Doing rebuilds for this lame thing, both of the ones I've tried have failed now [23:41] mplayer and mpeg4ip [23:43] mpeg4ip one looks solvable, but I don't know about mplayer [23:45] Laney, FTBFS logs? [23:45] NCommander: If you like, one sec [23:46] wooo, backports down to 40% new (34 in the queue) [23:47] NCommander: http://orangesquash.org.uk/~laney/laney-mplayer_1.0~rc2-0ubuntu14-amd64-20080828-2328 [23:47] brb, shower [23:48] disable ivtv ao and vo i say [23:49] unless you want to hunt down the cause of that [23:49] possibly missing headers etc [23:49] ivtv vo is very rarely used these days [23:49] ivtv? [23:49] What is that? === Kopfgeldjaeger is now known as Kopfi|offline [23:50] in-vitro TV? ;-) [23:50] why would ivtv vo be seldom used [23:50] ? [23:51] LaserJock, NCommander: driver for the Hauppauge PVR-350, for one [23:51] Oh, I used to have one of those [23:51] * slangasek idly wonders whether recent X would do autoconfiguration magic on his PVR-350 [23:56] * NCommander keeps the backports queue low [23:56] weee [23:57] slangasek, because it can't play mp4 files nicely [23:58] hmm, ok :) [23:58] slangasek, and it's picky in the resolution of mp2 that it will play nice [23:58] * NCommander has never seen an MP2 file in the wild [23:59] well DVDs are all mpeg2 [23:59] and most files that are recorded from hauppauge pvr-xx are mpeg2 [23:59] as is everything you get over firewire from your cable company [23:59] or anything broadcast atsc in the US [23:59] It wants DVD standard mpeg2? There are a lot of ways to make DVD-incompatible mpeg2 streams :)