[00:02] RainCT: OK. I think it was cody-sommerville who gave me an example that used that style, so I've been doing it that way. I suppose it keeps the changelog shorter to just put (LP: #123456) at the end of the line describing the change. [00:02] * NCommander raises his hands, and upgrades REVU again [00:03] NCommander: Are you typing with your feet? :-) [00:03] :-P [00:03] I'm making revu pretty(er) [00:04] NCommander: how is all the stuff linking it to PPAs? Done already? [00:04] jmarsden, sorta done, I'm working on improving the general interface first [00:04] OK. [00:04] jmarsden, http://nemesisnetworks.com/revu-html [00:04] That's whats about to become on REVU [00:05] I think MOTUs should be MsOTU [00:05] heh [00:05] NCommander: I just browsed http://revu.tauware.de/ and it shows a mod_python error... is that your doing?? [00:06] jmarsden, sometimes that makes sense [00:06] RainCT: people at my university are building an elevator control system using dialogos, i can probably get you some pictures once they're done ;) [00:06] laga: great :). what's dialogo's homepage? [00:07] er [00:07] cody-somerville: Is there a Wiki page describing Ubuntu changelog style? Would one be useful to newcomers? [00:07] I forgot to upload a file [00:07] NCommander: you can do bzr push --overwrite and 3 bzr pull --overwrite 's if you want a nice log [00:07] NCommander: but don't get used to it :P [00:08] TADA [00:08] Wow [00:08] awesome :) [00:08] What an improvement [00:08] jmarsden, take a look now [00:08] NCommander rocks :) [00:09] NCommander: Yep, that looks better! [00:09] NCommander s/hestitate/hesitate [00:09] I just got sick of brown [00:09] NCommander: uhm.. why are there needs work entries without the hammer [00:09] That's how that got started :-P === ember_ is now known as ember [00:09] Oh crud [00:09] Those are actually updated packages [00:09] I thought I fixed this little glitch [00:10] hold on, I think I know how to fix [00:11] THat's frustatingly anonying [00:14] jmarsden: back to your debdiff, wouldn't it be better to just include the new .desktop file in debian/, considering that you are replacing upstream's one completely? [00:15] RainCT: I wondered about that... I can do it that way, sure. Is there a practical benefit to one approach over the other? [00:16] jmarsden: (and I've changed the short description in debian/control from "creates" to "graphical application to create". afaikt package descriptions don't use to start with verbs) [00:16] jmarsden: well, basically that the debdiff and .diff.gz are easier to read, but it doesn't really matter [00:19] RainCT: OK. Re the synopsis... I'll re-read policy, I thought it basically says "a short descriptive phrase", and phrases can sometimes start with a verb, I think. [00:19] if it starts with a verb that makes it a clause ;) [00:20] policy ought to, but doesn't, say that the short desc should be a noun phrase [00:21] slangasek: OK. Should one of us file a bug against it to that effect :-) [00:22] jmarsden: also, you've to think as the short description as " is " [00:23] Hmmm. OK. I just checked with a 'famous' package, dpkg -l openoffice.org-writer and it doesn't seem to quite fit, and it started with an upper case letter... oh well. [00:24] Where is the right place to document this kind of packaging "best practice" information? [00:25] * jmarsden thinks if I'm going to learn from my mistakes, maybe others can learn from them too :-) [00:26] NCommander, Iulian: I just came back from the data center from our club, which was full of water after a heavy rain [00:26] geser, call the fire department [00:26] geser, if it cheers you up, REVU got an upgrade and a face lift [00:28] NCommander: why tried, they called us we need to wait 4 or 5 hours and later when we called again, that need at least 20 cm for their pumps and we got only 15 cm or so [00:28] geser, sounds about right [00:28] geser, start the bucket brigade then :-P [00:28] * NCommander is a firefighter, and has done that when the pumps failed [00:29] we had got some smaller pumps and got the most water out again [00:29] Thas good [00:29] At least it could be worse [00:30] the interesting part is the main power connectors to our UPS's were completely under water and still worked [00:30] jmarsden: on your wiki page, for example :) [00:30] geser, you could have it worse; check out these guys http://thedailywtf.com/Articles/A-Bit-More-Dire.aspx [00:30] what we can tell now is that some furniture got damaged by the water but nothing technical [00:31] * jmarsden thinks a lot of well known packages don't have good synopses, based on what I'm learning... gcc, binutils, etc. [00:31] also, note that packages by Canonical employees are usually not good examples [00:31] * RainCT hides :P [00:31] RainCT: I can do that, but few wannabee MOTUs are going to be reading my wiki page! [00:33] NCommander: http://fun.drno.de/movies/serverraum.avi is like our situation but we didn't have windows in the server room [00:34] geser, no, I won't use windows as a server OS either [00:34] NCommander: real windows, not the one from MS [00:34] oh [00:34] wow [00:34] Classy server room then [00:34] We use an old AIX server as our chair in our server room [00:35] woo [00:35] * jmarsden waits for the punchline... "if you sit down too hard, it reboots" ? [00:35] the age of computing hasn't been the same since computers stopped also being furniture [00:36] jmarsden: well, I'm thinking since some time that we should have a "common mistakes" page (to refer to it from REVU and so) [00:36] what do you think about that guys? [00:36] RainCT, I'm game [00:36] RainCT, we can put "How to not upgrade a server" on it ;-) [00:37] So what do people think of the new REVU look? [00:37] geser, a machine room underwater breaks my heart :( [00:38] directhex, it could be worse. It could have been vaporized [00:39] directhex: not only yours, we needed more than 6 hours to get most water out again [00:39] geser, how long before you can survey the equipment for survivors? :( [00:39] RainCT: Looks like there used to be one, but it got merged into the Packaging Guide. https://wiki.ubuntu.com/PackagingGuide/Basic#head-c17f31ae0d8b97d4e679e2289707746e3c89fae0 [00:40] yes, but that one is pretty short [00:40] not sure if we should make it longer [00:41] NCommander, it's seeing disaster vids like the above that makes me a little happier about using an enormously dangerous fire suppression system [00:41] Well, as a fire fighter [00:41] Supression systems usually help [00:41] And they save our lives and equipment [00:41] RainCT: Maybe is should be an appendix to the guide, or something like that? [00:41] s/is/it/ [00:42] NCommander, as long as nobody with any breathing difficulties whatsoever goes near our machine room..... and have you seen the average equipment integrator? [00:43] Yeah, I've dealt with HVACs [00:43] Oh wait [00:43] * NCommander brainfart [00:44] our machine room is a reduced oxygen atmosphere. a few visiots have had a bit of a funny turn when entering [00:44] NCommander: I think directhex means the suppression systems that make the room oxygen-poor, as though it is a high altitude? [00:44] jmarsden, spot on [00:44] That's dangerous [00:44] I'm suprised that's even legal [00:44] NCommander, only if you don't like working at altitude! [00:45] directhex, I work on limited air enough [00:45] * NCommander has run out air in a fire [00:45] 15% ought to be enough for anybody [00:45] Scary ass situation [00:45] At 15, you get dizzy, but still can function [00:45] Its 12 when you pass out [00:45] and 9 when you die [00:45] NCommander, but 15 is also at a level where fires won't hold [00:46] directhex, yeah, but you create an incredibly dangerous setup which could cause a backdraft [00:46] One good backdraft, and the only thing that will be left of that room is MAYBE the floor [00:47] don't look at me, the university insurers insisted on fire suppression. and nobody seems to like halon anymore [00:47] pumping nitrogen into the room seemed like a good idea at the time [00:48] directhex, with good reason [00:48] halon will kill you [00:48] Hell, we're not even allowed to enter a building once a halon system goes unless we know someone is in there [00:48] NCommander, so will a fully loaded rack [00:48] We have to call in HAZMAT in all other situations [00:50] FM-200 may be a decent alternative to Halon these days? Not that I work in that kind of environment... [00:50] i wish the Powers That Be would make up their minds over the dangers of oxyreduct [00:50] we've been told everything between "no special measures needed" to "wear hazmat suit" [00:51] jmarsden, I heard it had some issues. If you want a fire out, Halon still the way to go. I know a lot of places that are underground which conviential firefighting is near impossible its still used [00:51] It stops the chain reaction just like that [00:51] (damn impressive stuff, I've seen it used) [00:51] currently i'm under orders to turn off the nitrogen plant & open the doors to let the levels rise. but that involves going to a small shed on the roof :/ [00:51] which is a PITA when just swapping an ethernet cable [00:52] directhex, where do you work, National Archives? [00:52] I can't picture a company being THAT paranoid [00:52] university [00:53] jmarsden: beh am I slow today :P. try to avoid lines longer than 80 characters in debian/changelog (and basically everywhere :P) [00:53] aha, here it is. http://www.wagner.de/fire-prevention/operation/index.html?L=2 [00:53] directhex@mortos:~$ echo "jmarsden: beh am I slow today :P. try to avoid lines longer than 80 characters in debian/changelog (and basically everywhere :P)" | wc [00:53] 1 21 129 [00:53] not everywhere ;) [00:54] directhex, I'm planning on adding a changelog preview to the details page soon [00:54] Just to make life easier [00:55] I need to run for about 10 minutes, but before I do, can I get your opinions on the updated REVU directhex and geser? [00:56] ooh, the new stylesheet looks much more pro [00:56] needs a logo, but still [00:56] directhex, well, a few people saw my working prototype [00:56] and begged it went on production [00:56] So it did [00:57] It got started with the fact I got sick of brown [00:57] (a brown skin WILL return; all the color changes are just CSS) [00:57] directhex, logins are now integrated with LP (although it bugs out with noscript), [00:58] keysyncing is history [00:58] (keys are synced on first login, and then new keys are downloaded if needed on subsequent logins) [00:58] NCommander, I like the new style sheet. I just need to get used to the smaller font [00:58] nhandler, I might have made it too small, its still a work in progress [00:58] I based it off the design of LP's bug tracker [00:59] Trying to keep the good elements, and loosing the bad [00:59] like I reversed the queue ordering, making it a FIFO [00:59] (newest uploads appear at the top) [01:00] nhandler, directhex, geser as an added bonus, the blob of text disappears once you login [01:01] jmarsden: (I'm pbuilding now and will upload after that) [01:01] RainCT: Cool, thanks! [01:02] NCommander: Very cool. That blob was a little annoying. But you might consider allowing the user to toggle it on and off. That way, they can access the information without having to logout [01:03] jmarsden: btw, next time you touch an Ubuntu package, as in a package which doesn't come from Debian, it may be worth to ping the Maintainer [01:03] as he knows it better [01:03] NCommander: what did I say about the blob? :P [01:05] nhandler, actually, I wanted to do that, but I don't know enough javascript to implement that [01:07] * jdong feels like such a nerd at the moment... he is sitting at his very first thinkpad X61 [01:07] NCommander: it's easy, I can do it if you do the visual part ;) [01:07] RainCT, yes please :-) [01:07] I'm not very good with java script [01:07] * NCommander is currently drafting an email [01:08] it's basically changing the CSS property "display" to "none" [01:08] RainCT, grab the current trunk, and just edit the info html page [01:08] to hide it and back to whatever (I haven't done much web stuff this last year :P) it is to show it again [01:08] yeah [01:09] I have to fix the resizing on one of the icons [01:09] And some more work [01:09] * RainCT tries to remember of some page where he did that [01:09] But it's such a massive improvement ... [01:09] NCommander: yep.. pray that siretart won't want you to revert it :P [01:10] He liked it [01:10] Although I think he was less thrilled about the purple/blush then I was [01:10] heh [01:10] NCommander: Is there a per-login themed REVU in your future :-) [01:10] jmarsden, yup [01:11] Thought so. [01:11] If you really miss the old style, you just need to load the old style sheet [01:11] NCommander: can you make the columns of the different tables be the same width in each table? so the entries don't move more left or right [01:11] * RainCT proposed the same some hours ago :) [01:11] geser, I will as soon as I remember enough CSS/HTML to do so, this was sorta a rushed out to make RainCT happy release [01:12] * RainCT pulls [01:12] NCommander: You should put that in the changelog :-) [01:12] put what in the changelog? [01:12] NCommander: "this was sorta a rushed out to make RainCT happy release" [01:12] :-) [01:12] sure, now I am the evil [01:12] ;P [01:12] aren't you? [01:13] * NCommander runs [01:13] j/k ;-) [01:13] of course I am [01:13] :P [01:13] You are greatly appreciated RainCT [01:13] nah, you are ;) [01:13] I'm no MOTU, you make my packages enter univere [01:13] *universe [01:13] lol [01:14] * NCommander would like to add an autouploader to REVU once a package gets two advocations [01:14] good argument [01:14] * wgrant wouldn't like REVU to have an archive key.... [01:14] NCommander: continue dreaming :P [01:14] you just want to abuse your admin privs :P [01:15] I said like [01:15] I know realistically it won't happen [01:15] Unless I add a way someone can upload a signed changes file [01:15] * NCommander strokes beard [01:16] * RainCT objects now before you think more about it :P [01:16] NCommander: try and several (see like I've done it for the FTBFS page) [01:16] anyway.. let's see if I do the hide think [01:16] geser, thank you :-) [01:16] geser: o_O [01:16] ? [01:16] * NCommander is right now drafting an email to -motu [01:16] is that new? [01:17] SInce I broke REVU for anyone who uses noscript :-/ [01:17] or LP did [01:17] NCommander: where should I put the link? [01:17] Put it under View: *list* [01:17] And if you want to straighten the tables out, that would be an added bonus [01:18] (can you also commit the index.py thats in my home folder in spooky) [01:19] what does it have? [01:20] RainCT, fixes the New Package list to not also include the Updated Packages [01:20] and why do you put it in your home? :P [01:20] (I coded it right on production ... probably a bad habit) [01:20] RainCT: new since HTML 4.0 [01:21] you can of course also specify the width in the data cells [01:22] geser: what's the difference? [01:23] oh, it's in my HTML4 book [01:23] my HTML book is 3.2 ... [01:23] Time to buy a new book [01:24] RainCT: I just got emails that the build of koverartist failed... ? [01:24] btw, does someone want to build a Visual Basic 5.0 book? :P [01:24] jmarsden: don't worry it's in my PPA [01:24] jmarsden: my PC wanted to download dependencies during 45 minutes :P [01:25] Wow, you must have a slow net connection? OK. [01:25] (don't worry = don't worry, but fix it ;)) [01:25] yep.. I've a 3G modem [01:26] OK... I can fix it... can I d/l it from your PPA? I've only used my own PPA so far, not someone elses! [01:26] RainCT: Why is julius-voxforge in NEW, but julius itself isn't? [01:27] wgrant: because I accidentally uploaded it - feel free to reject it [01:27] * I uploaded it accidentally, rather. I write strange after midnight (and before, too) :P [01:27] RainCT: I don't have such powers. I was just checking if we'd see it in Intrepid soon, as it looks rather interesting. [01:28] That sentence was fine. [01:28] wgrant: :) [01:28] yep, but I don't like it :P [01:28] Riddell, ping [01:29] NCommander: remember? weekend ;P [01:29] crap [01:30] RainCT, got the tables fixed? [01:31] NCommander: there's something wrong with the code in index.php from your home [01:32] PHP!? [01:32] NCommander: you check if isNew is True/False, but it defaults to 'false' (str) [01:32] *py [01:32] RainCT, ack, thats a left over from the conflict [01:32] Mind clearing that up ;-) [01:32] should it be True, or the other two strings? [01:32] * False [01:32] * RainCT should really finish now and go sleep :P [01:33] I don't know off the top of my head [01:33] * NCommander finishs his email to ubuntu-motu [01:33] I added a FIXME [01:33] comment [01:34] ok [01:34] RainCT, check your inbox for the email I just sent to Ubuntu-motu [01:34] And please weigh in before leaving us [01:34] in which .html is the uploads table? [01:35] RainCT, its printed out in code [01:35] Not an .html [01:35] ah [01:35] ugly :P [01:37] ok, listheader.html i tis [01:39] RainCT: koverartist build failed because of a KDE dependency issue of some kind... is that really my fault, or is that an Intrepid KDE library problem of some kind? [01:39] hey emgent [01:39] RainCT: http://launchpadlibrarian.net/16340421/buildlog_ubuntu-intrepid-i386.koverartist_0.5-0ubuntu2_FAILEDTOBUILD.txt.gz [01:39] seems like it's intrepid [01:40] RainCT: That's what I thought... shuold I file a bug somehow about that? [01:42] NCommander: I get a giant heart :P [01:42] RainCT, yeah, I wanted to drive home the fact that some packages are ready for upload ;-) [01:42] (actually, I forgot to resize that image and reave as heart_small.png) [01:42] * jmarsden thinks... well, it was "the release to make RainCT happy" :-) [01:43] bah+ [01:44] It made me happy to [01:44] NO MORE BROWN! [01:44] crap [01:44] My mail to ubuntu-motu bounced [01:45] Why did it bounce? [01:45] It says I'm unsubscribed [01:45] But I know I am [01:46] NCommander: Do you have multiple email addresses? Which one did you send from... etc. [01:46] no [01:46] Just sonicmctails@gmail.com [01:46] It does this will all ubuntu lists [01:47] NCommander: Then either someone somewhere in the Ubuntu mail processing crew hates you, or you really are unsubscribed...? [01:47] no [01:47] I get all emails sent to the list [01:47] Resending [01:47] I can see the Welcome to list [01:47] email [01:48] There it goes [01:48] Took two tries [01:48] jmarsden, care to weigh in? [01:49] https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004283.html [01:49] yeah I saw [01:50] christ [01:50] Why didn't I spell check this -_-; [01:50] I think I need to go to bed [01:52] hehe [01:52] Just start replying :-P [01:52] NCommander: nice job :) [01:52] on breaking REVU with everyone who has noscript? [01:52] * NCommander isn't sure if thats a feature or a bug [01:52] hehe [01:52] It requires people to loosen the tin foil [01:53] oh, that wasn't intended? *g* [01:53] * NCommander whacks RainCT [01:53] vorian, REVU actually going to get attached to an autobuilder network so packages can be built and caught for early failure before going through the NEW queue, and then blowing apart in four of the five release archs ;-) [01:54] nice :) [01:54] NCommander: please *don't* edit files in place - I just got a conflict :P [01:54] RainCT, do a bzr revert before merging [01:55] vorian, well, I'm debating if I want to actually bother with dak, or go try mini-dak [01:55] i think it looks much better in blue btw [01:55] * NCommander has used dak before, and has already lost a great number of brain cells [01:55] wow [01:55] * NCommander worhsips vorian [01:55] someone else who said it! [01:55] NCommander: that would undo the Config.py changes [01:55] RainCT, bzr revert index.py [01:55] I'm too lazy :P [01:56] * NCommander hits you over the head with his dak server [01:56] NCommander: how are the accounts figured, seems mine reverted ... [01:56] vorian, we didn't migrate over user permissions. If you want reviewer/admin back, you need to merge your old one [01:56] The problem is here the lostpw function broke going into production, and I have yet to run down the cause [01:57] weird [01:58] RainCT, Config.py hack applied [01:59] vorian, I just set you reviewer in the system [01:59] ty [01:59] RainCT, can you please chown the logs folder so the revu1 user can read themn? [02:00] Oh [02:00] I just figured out why the password reseter doesn't work [02:00] apache's error.log? [02:00] er wait [02:00] No [02:00] RainCT, yeah, and the /var/logs/apache2 folder [02:01] it's /var/log, not /var/logs (as you've alread done twice the same typoe :P) [02:01] :-P [02:01] I don't have tab complete here [02:02] done [02:02] and I've replied to your mail [02:03] oh [02:03] I get why the pw resetter isn't working [02:03] gpg: packages@schauenburg.nl: skipped: public key not found [02:03] THe best laid plans ... [02:06] Good evening all [02:06] RainCT, please add group readibility/writability to /srv/revu-production/random-seed [02:06] Whoever pinged me earlier today it's rolled off my scrollback, so please ping me again if it's still relevant. [02:06] NCommander: Ever find your power cord? [02:07] ScottK, sorry, I can't find the actual box [02:07] Like the actual HW is missing [02:07] Ah. [02:07] Not just the cord [02:07] Heh. [02:07] Yeah [02:07] bah [02:07] rainct went away [02:07] moment [02:08] ScottK, check out REVU; for everytime LP gets ugler, REVU gets prettier :-P [02:08] hah [02:08] ;-) [02:08] NCommander: tables aligned [02:09] FOSS is the future. You'd think they'd know that. [02:09] NCommander: I'll do the JS thing tomorrow - my brain doesn't work now :P [02:09] RainCT, I need permissions fixed [02:09] NCommander: I've also decremented the margin on the sides [02:09] Just stick around for a few more minutes while I work out why the PW resetter doesn't work [02:10] NCommander: revu1 can read random_seed [02:11] The www-data user needs to own it [02:11] THat's what the GPG error log is saying [02:11] ah [02:11] r or rw? [02:11] rw [02:11] ok, done [02:11] pubring.gpg too? [02:12] ok [02:12] no [02:12] No warnings [02:12] okay [02:12] Why the hell is this not working [02:12] why is there a launchpad.gpg again? I thoguht I removed it [02:12] anyway.. do you still need me? [02:13] I almost got it [02:13] RainCT, just another moment [02:13] * NCommander inserts the pathetic begging for you to stay [02:14] RainCT, can you look at the substituion in merge.py on line 72? [02:14] The right output coming out in key, but its not getting substituted in [02:16] """ % s [02:16] that's my line 72 [02:16] I changed it slightly in production for debugging [02:16] (since I'm not having this issue on 127.0.0.1( [02:16] *) [02:16] how do you know the line there? [02:17] nano Ctl-C :-P [02:17] its just a changed variable name [02:17] I thought for some reason it was doing something stupid with the variable name S [02:17] Wait ... [02:18] * NCommander forces the mime type to text [02:18] * RainCT gets a giant glove to hit NCommander :P [02:19] And there it goes [02:19] vorian, can you please try merging your accounts? [02:19] sure [02:19] fail [02:19] why? [02:19] Incorrect e-mail address or password. Back. [02:19] Er [02:20] Are you sure your using the right password? [02:20] REVU's are randomly generated [02:20] and there was never a change password function [02:20] i understand that :) [02:20] Can you recover? [02:20] haha [02:20] There is no REVU account for vorian@ubuntu.com, yet. [02:20] * NCommander falls backwards [02:20] * vorian hands NCommander a redbull [02:21] it has already been merged [02:21] I take it you don't use REVU very often vorian? [02:21] NCommander: vorian's account has already been merged.. [02:21] I merged it when NCommander said i should about 30 minutes ago [02:21] RainCT, er no, I see a vorian@ubuntu.com in the uploaders list [02:21] oh wait [02:21] stupid cache [02:21] my account seems fine now [02:22] ah, pretty blue :) [02:22] I'm not the only one sick of brown ;-) [02:23] now, good night [02:23] nn RainCT [02:23] it's half past 3 in the morning here :P [02:23] thank you for your contribution to REVU RainCT [02:23] Blue is good. [02:23] xD [02:23] ScottK, so I take it you approve of the new skin for REVU? [02:23] * RainCT doesn't like it somehow [02:24] it reminds me of sth.. [02:24] sth? [02:24] something [02:24] * ScottK hasn't looked yet... just likes blue better than brown. [02:24] I'm not sure about what exactly, but something displeasing [02:24] :P [02:24] RainCT, lack of sleep [02:24] ah, now I know. kubunu it was called [02:25] :P [02:25] * RainCT runs away [02:25] * vorian shoots lasers at RainCT [02:25] * RainCT dies [02:25] *** screen detached, good night :) [02:41] hello everybody [02:41] when building back for debian do you all do that with pbuilder or other methods? [02:41] Yes. [02:42] I do it with pbuilder. Others have other ways. [02:42] alright, thanks [02:42] are there any ubuntu-main sponsors on? [02:47] tbielawa: If it's not urgent, please just subscribe ubuntu-main-sponsors [02:47] ScottK: np. [02:52] I've got a question on the new REVU [02:52] what is the difference between Needs Work and Needs Review? [02:52] LaserJock, Needs Work are packages that have received a negative adovcation [02:52] Needs Review are ones that haven't been looked at all [02:52] NCommander: Where is the current API into LP documented? The one you are using for the new REVU stuff? [02:53] jmarsden, the "API" I'm using is parsing RDF documents [02:53] As for openid, its a published spec [02:53] jmarsden, that's why parsing revu-uploaders isn't an option [02:53] The rdf file is a megabyte, and TBH, spooky probably won't be too happy running through it [02:54] Ewww. That's all there is? Yes, I know about OpenID. With a team of paid prorgammers working on LP, I'd have expected it to come with some sort of documented API by now. [02:54] jmarsden: It's almost there... [02:56] jmarsden: Welcome to the large and growing club of people that expected more from Launchpad than they got. [02:56] wgrant: OK, good. But noone can see it, the API docs are not public, no-one can discuss it until it arrives, because LP is closed source... brrr. [02:56] jmarsden: Erm, I said it's almost there. [02:56] They will be public once it's done. [02:56] Though why not before I do not know. [02:57] NCommander: I don't see where a "negative advocation" (isn't that an oxymoron?) is indicated on the pages? [02:58] wgrant: why would they release docs for something they haven't built yet? [02:58] LaserJock: So we can poke holes in it beforehand. [02:58] LaserJock: So people can comment on the spec, suggest improvements, compare and contrast with other similar APIs, etc. [02:58] They must have a design somewhere. [02:58] LaserJock: This sounds like the sort order that, IIRC, sistpoty set up. [02:59] LaserJock, anytime a review posts a comment and doesn't advocate [02:59] LaserJock: A comment that isn't an advocation. [02:59] LaserJock: Right, no chance that external review of the design would yield improvments. [02:59] LaserJock: It is Launchpad after all and they understand this stuff so much better than we do. [03:00] * LaserJock backs away at seeing all the red highlights in his IRC client ;-) [03:00] perhaps you'd like red highlights in your e-mail inboxes via spam^W? [03:01] * NCommander unfortantely marks jmarsden's bug invalid [03:01] so umm, why can't I vote/advocate? [03:02] LaserJock: You need to merge your old account to get privileges. [03:02] LaserJock, you need to merge your old account to recover reviewer status [03:02] ah [03:02] NCommander: Sigh. OK. [03:02] so does that mean anybody can comment? [03:02] I have the start of a script that will set review/admins automatically somepoint [03:02] LaserJock: It has been that way for a while. [03:03] :( [03:03] jmarsden, that being said, emails will be added when REVU decides to reject an upload [03:03] hmm, I'm not entirely sure what my old REVU account was, I've had a few of them [03:04] LaserJock, you can merge multiple accounts together [03:04] Just try email addresses and Recover Password [03:04] ah, found it [03:04] NCommander: that was the problem [03:04] I couldn't remember which addresses I'd used [03:04] NCommander, You got the recover password feature working? [03:05] nhandler, yeah [03:05] It was a MIME bug; different apache setting between localhost and REVU [03:05] I just needed to force the recover screen to text/plain [03:06] well, I'm not much of a fan of OpenID, but it is a bit more convenient [03:06] LaserJock, well, Launchpad has an AuthServer API which they were going to let us use for REVU2 [03:07] LaserJock, I know one of the LP's devels pretty well, maybe I can poke him to find out if they're still willing to play ball [03:07] (that being said, LP admits their openid server needs some work) [03:07] NCommander: They won't. They're implementing another external auth system. [03:07] oh fun [03:07] They could just improve the one they have ... [03:07] It was meant to be out around January, but appears to have vanished. [03:07] *sigh* I guess with all this activity my hopes of turning REVU off are dashed ;-) [03:09] LaserJock, you wanted to turn REVU off? [03:09] LaserJock: Given Launchpad's track record of supporting distro requirements, I think it was forlorn to start with. [03:09] NCommander: yes [03:09] LaserJock wants us just to use Launchpad for everything. [03:09] no [03:09] I don't want us taking new packages [03:09] REVU needed quite a bit of TLC [03:09] LaserJock, huh? [03:09] LaserJock, you really think PPAs are a suitable alternative? [03:09] it's rediculous the amount of packages we pump into Ubuntu [03:10] NCommander: it's called Debian ... [03:10] * wgrant agrees with LaserJock. [03:10] * NCommander would agree with LaserJock if getting a package into Debian wasn't a massive headache [03:10] We have low enough QA at the moment. [03:10] It's a constant fight I find. [03:10] We don't need several hundred packages without a maintaining. [03:10] *maintainer [03:10] over 1/3 of the packages MOTU have to maintain are from REVU, and we have to maintain them *entirely* as opposed to getting help from Debian [03:11] LaserJock: What we need to do if find the crap ancient packages that have been abandoned and get rid of them. [03:11] if/is [03:11] and for the other 2/3s, you sometimes have to deal with rather stubborn DDs who would like to see us die. I can only get one to include glibc 2.8 fixes [03:11] ScottK: most of those we don't maintain, no burden on us [03:12] Is there an ubuntu equivelent of popcon? [03:12] uh, popcon [03:12] ;-) [03:12] Yeah. [03:13] NCommander: if a package can't get into Debian I'm very suspicous about it going into Ubuntu [03:13] the only cases are the few license differences [03:13] LaserJock, have you personally worked at finding a sponsor directly with Debian? [03:13] and Ubuntu-specific packages [03:13] * wgrant screams. [03:13] fujitsu@syklone:~/mdt/versions$ wc -l universe_not_sid [03:13] 857 universe_not_sid [03:13] It's a pain in the ass. [03:13] NCommander: um yeah, I'm a Debian Maintainer [03:13] You can update your packages [03:13] I'm not a D Anything [03:13] (yet) [03:13] NCommander: I've gotten my packages into Debian *much* faster than in Ubuntu [03:14] LaserJock, my experience is quite the opposite [03:14] my first package took 2 days to get into Debian [03:14] I do submit to Debian [03:14] as opposed to 2 weeks I think in Ubuntu [03:14] But after it goes through on Ubuntu and then request sync [03:14] but that was a couple years ago ;-) [03:14] LaserJock, still haven't found a sponsor for Code::Blocks [03:14] No one wants to touch it [03:14] yeah [03:14] because it's kind of a pain [03:14] code blocks has been attempted several times [03:15] The big problem was Debian was vetoing wxWidgets 2.8 for YEARS [03:15] NCommander: Re gpg info-finding from .changes files... can't you grab the Key ID and then do: gpg --keyserver keyserver.ubuntu.com --recv-keys [03:15] NCommander: so? [03:15] (there was a rather large spat about it on d-devel) [03:15] No, I'm just saying why it never actually got in despite previous attempts [03:15] just because it's hard doesn't mean it shouldn't be done! [03:16] NCommander: Yes, the wx stuff was stupid. But that's not why we have most of the packages. [03:16] jmarsden, the .changes file signature doesn't have the original figureprint [03:16] wgrant, no, I was just addressing why codeblocks was constantly rejected [03:16] the maintainence burden from all these packages is really quite troublesome [03:16] I'm quite aware [03:16] The current situation is ridiculous and unmaintainable. [03:16] But if we're the upstream packagers in Debian [03:16] I don't see the difference ... [03:17] Its the same group of people [03:17] Just spread across now two distributions [03:17] Is there something I'm not seeing? [03:17] NCommander: I have one from _RainCT , I can get its Key ID by doing gpg --verify --fingerprint . Then I can use the Key ID from that do to the command just poted and import his key. Isn't that what we want REVU to be able to do? [03:17] Except that our development community is a tiny percentage of the size of Debian's... [03:17] Part of the difference is that if you upload something to Debian you make a commitment to maintain it. Fewer drive by's. [03:17] ScottK: Right. [03:18] then the answer is pretty straightforward. We're not doing enough to push the appropriate changes upstream (not Debian). [03:18] It's ~100 versus ~1000 [03:18] I'll be damned [03:18] wgrant, ever get help from another DD resolving an issue? [03:18] NCommander: Other than for sponsorship I haven't tried. [03:18] jmarsden, ok ... I was under the impression that you couldn't get the fingerprint from the changes file [03:18] crimsun: Hm? That's not relevant here... [03:19] wgrant, at times I've gotten a porter to help if it was arch specifc [03:19] But I'm more used to people telling me that "It's my package, you fix it" [03:19] So TBH, there is no difference in my book [03:19] wgrant: packaging-specific shouldn't be that burdensome. [03:19] Maintainers in debian I find are on their own, or if the package is semi-popular, might see a little love from the QA group [03:19] NCommander: Assuming you know a keyserver to grab the key from given its Key ID, which is this case we do, it seems doable. [03:20] jmarsden, the only problem with allowing people to upload free nilly is just ripe for abuse :-/ [03:20] crimsun: We're talking about 900 packages which are in Ubuntu but not Debian... [03:20] NCommander: I've gotten a lot more help in maintaining packages in Debian than in Ubuntu [03:20] NCommander: ? You know *exactly* who they are, they signed the package with their GPG key... makes abuse awkward, I would think? [03:20] I'd like to note for the record that the Debian archive is roughly 8000 source packages, including arch all [03:20] wgrant: 900 source? [03:21] crimsun: yeah [03:21] jmarsden: No restriction on who can upload, though. [03:21] jmarsden, I can generate 10 or 20 fake keys and spam REVU straight to hell [03:21] OTOH, if I'd been told "Go see Debian to get stuff in" when I started, I probably wouldn't be here. All those packages are in Debian now. [03:21] I came here because I got fed up with the Debian attitude [03:21] crimsun: It looks that way. [03:21] ScottK: You are the exception, not the rule. [03:21] I would caution people to not close off Ubuntu as a vector. [03:21] and as a porter, especially a hurd one, I had a lot of trouble getting maintainers to accept fixes [03:22] ScottK: we can do better than "Go see Debian", but we don't have to keep dumping packages in like crazy [03:22] People always tell me that, and it's not always a good thing .... [03:22] LaserJock: How many new packages have been uploaded this cycle? [03:22] haven't a clue but since we were at 700 when I looked at gutsy [03:22] * NCommander looks at REVU [03:22] wgrant: Can you teach your script to find not in debian or hardy, but in intrepid? [03:22] at least 100/release I'm guessing [03:23] ScottK: I will try to do so now. [03:23] wgrant: Thanks. [03:23] LaserJock: For Hardy there were a lot. I don't think so many for Intrepid. [03:23] sure, not yet [03:23] but a few REVU Days and the FF push should do the trick [03:24] If someone can tell me what the command to count rows in postgreSQL, I can tell you how many packages got uploaded to REVU since April [03:24] FF push? [03:24] ScottK: people rush before Feature Freeze to get everything in [03:24] NCommander: This issue isn't how many to REVU, but how many in the archive? [03:24] Right [03:24] ScottK, people want to know how many were submitted [03:25] 714 distinct source packages have been uploaded to REVU since it was brought online [03:25] online when? [03:25] not counting nuked uploads [03:25] LaserJock, 2005 I would guess [03:25] No, we started over when it went to sparky. [03:25] The DB has been cleaned since then. [03:26] wgrant, any idea when? [03:26] I was going to say, that seems awfully low [03:26] Check the date of the first upload, I guess? [03:26] wasn't that like 1.5 years ago? [03:26] hmm, maybe not, I can't really remember [03:27] revubase=# SELECT * FROM upload ORDER BY dateofupload ASC LIMIT 1; [03:27] upid | dateofupload | sid | usid | isarchived [03:27] ------+----------------------------+-----+------+------------ [03:27] 7 | 2007-08-18 13:20:05.993181 | 4 | 5 | f [03:27] So less than a year. [03:27] I've got 2007-08-18 [03:27] Yeah [03:27] Wow. [03:27] revubase=# SELECT COUNT(*) FROM upload; [03:27] count [03:27] ------- [03:27] 2900 [03:28] So an average of somewhat over 4 uploads per sourcepackage. Not good. [03:29] wgrant: is there a way to see how many comments? [03:29] 2643. [03:30] I wonder if making people maintain REVU packages would do anything [03:30] if your aim is to move away from revu, then that's pretty silly. [03:30] I don't mind having packages in Ubuntu, not in Debian, quite so much if they're being maintained [03:31] my aim is to not have a pile of junk in our archive, especially when it's expensive junk [03:31] That'd make sense. [03:31] I wonder how easily I can work out the last time each was uploaded. [03:31] (it looks there might only be around 50 NEW so far for Intrepid, but that sounds wrong) [03:32] LaserJock: all of it is expensive; the only issue is where the initial effort is spent. [03:32] wgrant: I suspect that's about right. [03:34] anyhow, we've bitched enough about a lack of resources, so what I've been doing is going to middle- and high-schoolers, freshmen, etc. If the aim is to have them work with Debian from the onset, then it would be nice to know now. [03:34] * NCommander agrees with crimsun [03:34] We don't need people to work on new packages! [03:35] We need people to maintain existing ones. [03:35] wgrant: note the explicit lack of "new" in my statement. [03:35] This discussion is about putting new packages in Debian first. I don't think we made assertions about other types of changes. [03:35] wgrant: You have to let volunteers focus where their intent lies. There is nothing wrong with new packages. The problem is unmaintained new packages. [03:36] ScottK: Which is most of them, I suspect. [03:36] Right. [03:36] so then you could restrict new packages to MOTUs only [03:36] So for new packages not from Debian, make it an individual maintainer. [03:36] Maybe we should expire new packages after 12 months if they don't have any more uploads or don't meet a popcon requirement or something. [03:36] * NCommander has always thought that should be the case [03:37] or make part of the process of new Ubuntu source to get it into Debian within a reasonable timeframe of, say, 12 months. [03:37] wgrant: I'd rather it be like Testing where you pitch them if they have RC bugs not addressed. [03:37] ScottK: RC bugs can be Importance: Low here. [03:38] True. [03:38] There's no way to determine what is RC here. [03:38] We'd have to come up with our own standards. [03:38] I'm suggesting a parallel concept, not a carbon copy. [03:38] Maybe we should have some sorta testing archive [03:39] in what circumstances are RC bugs not also for Ubuntu? [03:39] Create Grumpy Groundhog, and then have Intrepid be testing [03:39] We can't. That would take LP a decade to do. [03:39] wgrant, is that why we dont' currently have a specific testing distribution? [03:39] crimsun: With the way somebody defined Launchpad bug importances, a critical bug in a package could be Low. [03:40] NCommander: No, that's because it's not how Ubuntu works. [03:40] How about something like if there is an SRU worthy bug that is unfixed through an entire development cycle, it gets remove at Beta. [03:41] wgrant: but LP triaging aside, surely Debian RC status should imply we get it fixed ASAP in Ubuntu, too? [03:41] ScottK: So we look through 900 packages each cycle? [03:41] crimsun: These packages aren't in Debian. [03:41] And note that a lot of our packages don't have users, so won't get bugs. [03:41] wgrant: It'll be fewer, faster and we could get bugsquad to triage the list perhaps. [03:41] wgrant: I'm talking of a larger problem that isn't restricted to those source packages. [03:41] No, users, no bugs, no maintenance, no problem. [03:42] crimsun: We have ajmitch's RC bugs page. [03:42] ScottK: But then when $USER comes along and tries to use it we look bad. [03:42] If universe was disabled out of the box and had a rather big disclaimer ... [03:42] That used to be the case. [03:42] There is a really, really easy solution to this problem. [03:43] Send people to Debian first! [03:43] wgrant: Fortunately it's Debian that makes me promise to care about the user, not Ubuntu. [03:43] It would make it much easier. [03:43] ;-) [03:43] wgrant, easy solutions are rarely the right ones [03:43] It will make Debian happier, us happier, users happier... [03:43] there seems to be a misleading "us" and "everybody else" mentality. [03:43] its more of moving the problem then solving us [03:44] *it [03:44] crimsun: 'us' == Ubuntu devs? [03:44] Excluding drive-by packagers. [03:44] wgrant: "us" is anybody outside the sphere of influence [03:45] wgrant: I belive the current usage of Importance is /packages not /distro as it used to be [03:45] that is /package [03:45] which should corredspond to Debian's usage [03:47] LaserJock: That was proposed. [03:47] LaserJock: I don't think it ever got approved. [03:47] Not agreed. [03:47] wgrant: I believe bdmurray changed the wiki pages [03:47] perhaps not though [03:47] Nobody told the devs. [03:47] I agree with that definition fully, but I don't think it was every officially changed. [03:47] well, of course that *would* be consistent with the way things are done ;-) [03:47] And it's a big change. [03:48] for the sake of expediency, are we concurring that mentoring new packages into Debian first is a good approach? [03:48] * wgrant is [03:48] I think so [03:48] crimsun: No. [03:49] I'd rather focus on if you get it into Ubuntu you're responsible for it. [03:49] I don't mind helping people get packages ready, but they really should be going into Debian unless there's a good reason not to [03:49] ScottK: I don't disagree with that, but wouldn't Debian also benefit? [03:50] OK, we very strongly encourage people to go to Debian first, but if they want it to pollute Ubuntu first we engrave their name all over it. [03:50] crimsun: I agree we should encourage people to go to Debian too. [03:51] * LaserJock notes that he hopes the new Ubuntu QA team would be able to offer some help regarding archive QA [03:51] I like the 'we'll upload it here, but only if you promise to get it into Debian approach. [03:51] rm -r /srv/archive.ubuntu.com/ubuntu/pool/universe/ [03:52] Most of the new packages I've done were done that way. [03:52] ScottK: s/promise to get/are actively getting/ [03:53] well [03:53] we could tie it to an ITP or a RFS [03:53] that's my thinking [03:53] that's fairly easy to do [03:54] if we had a set team that would work with people to get the package into Debian (remove the need for finding a sponsor), it won't be hard to get packages to flow into Debian [03:54] btw, I was totally wrong about the Bugs/Importance wiki page being updated [03:55] Look at the number of open ITP bugs and ask yourself how much that really buys you? [03:55] NCommander: well, the REVU frontpage talks about utnubu [03:55] LaserJock: I wonder what happened to that idea, then... [03:55] * ScottK looks around for a DD in this conversation. [03:55] What Utnubu? [03:55] Nope. Don't see any. [03:55] ScottK: right, but as you suggested, it's one avenue. Your proposal is quite valid. [03:55] wgrant: probably stalled [03:55] I don't see them as mutually exclusive. [03:57] utnubu is dead :/ [03:58] ScottK: i am around [03:58] white: That was unfortunately my point. [03:58] I see a big problem in the usage of the Maintainer Spec on REVU packages as well [03:58] LaserJock: Right, and that is enforced now. [03:58] we used to encourage people to put themselves as maintainer [03:58] wgrant: No. It's a warning. It's not enforced. [03:58] ok, so utnubu needs to be resurrected? [03:58] i personally think the problem is the difference in mentality, debian has constant maintainers and ubuntu has one-time contributors [03:59] one-time contributor can be a long-term contributor to ubuntu, but we are talking about specific packages [03:59] Heya white. [03:59] ScottK: Are you sure? I thought it was upgraded to an error. [03:59] wgrant: If I'm Maintainer in Debian I routinely ignore the maintainer spec on my packages. [03:59] so having a team taking care of getting the packages uploaded to debain does not solve the problem [03:59] ScottK: I believe if it isn't an @ubuntu.com address it's an error [04:00] Can we make reviewing take a couple of months and be generally foul and arduous to eliminate drivebys? [04:00] LaserJock: I'm not using an ubuntu.com address. [04:00] the team will have to maintain the packages, people drop out of the team, team has too many packages to maintain, which leads to unmaintained packages [04:00] ScottK: for Ubuntu uploads? [04:00] wgrant: that's the line we're attempting to avoid, no? [04:00] same problem as with utnubu [04:00] wgrant: So far we've been doing that pretty effectively for this cycle. [04:00] LaserJock: Yes. [04:00] ScottK: Why would you alter things in Ubuntu if you're a DM? [04:00] ScottK, I got patches for a package I maintain in debian (cvsps) in Ubuntu that I wrote, and I was removed from the maintainer from [04:00] ScottK: hmm, odd [04:01] I know I kept getting errors when I was trying to do PPA uploads [04:01] And security uploads for me. [04:01] wgrant: In one case I recall we were past FF in Ubuntu so I uploaded a new revision with a patch. In Debian I did a new upstream release and uploaded that. [04:01] I'm fairly sure it's an error. [04:02] what exactly is the problem with using the debian system of maintainers for new packages? [04:02] white: Nothing apart from deliberate dpkg-buildpackage restrictions. [04:02] wgrant: what restrictions? [04:02] Looks like April was the last time I did it. [04:02] and then only sync packages from debian [04:03] white: One cannot have 'ubuntu' in the version but a maintainer without 'ubuntu' in it. [04:03] wgrant: Go try to build a package and see. [04:03] It's not an error. [04:03] wgrant: that's a little weird, if you ask me [04:03] It was for a while, but they changed it to a warning. [04:03] ScottK, I've had patches for my own packages in Debian rejected because I didn't change the maintaier [04:03] Maybe we should bring up the Maintainer policy at the next MOTU meeting [04:03] white: it's our implementation of Debian's voting ;-) [04:03] well, i personally feel that a lot of extra ubuntu patches should not be added immediately [04:04] NCommander: That's what the rules require. I just sometimes ignore them. [04:04] NCommander: yes, we know how well those meetings go ;-) [04:04] Changing the way the MaintainerSpec works will have to go to the Tech Board. [04:05] No. [04:05] for example, sending a patch about a .desktop file to the debian BTS and then maybe waiting a few weeks woll turn out to be more beneficial, than implementing one straight away in ubuntu, then later on finding out that it differs from debian and needs to be merged all the times [04:05] that just cases a lot of workload [04:05] IMHO [04:05] ScottK, isn't it an MOTU issue? The core team always changed it to Core Team simply because they are supporting it via canonical [04:05] ScottK: The TB didn't mandate it for all packages. [04:05] NCommander: that's not it at all [04:05] NCommander: No. [04:05] NCommander: for one the Core Team is not all supported via Canonical [04:05] It's only an issue with packages from Debian, but somebody took a shortcut when implementing it technically. [04:06] ok [04:06] NCommander: Read https://wiki.ubuntu.com/DebianMaintainerField [04:07] Aha. It was made an error in February, and a warning again in May. [04:07] ok [04:07] I have learned [04:07] minimizing divergence is really the thing we're shooting for [04:07] whether that be ubuntu patches needing to go upstream [04:08] or getting packages not in Debian *in* Debian [04:08] Actually, it was made an error in July last year - the merge changelogs are just written badly. [04:08] This is probably a particularly bad time to be talking to Debian about all these new packages we have that they should take on. [04:08] wgrant: seemed like it was longer than that [04:08] LaserJock: what is the problem with making it a requirement to get everything into debian sid first? [04:08] LaserJock: Well, the changelogs could be even less reliable than I thought. [04:09] white: well, generally that people object to it [04:09] ScottK: Why? Throw them in sid tomorrow and they'll stay there until lenny+1. [04:09] white: learning how to do things in both Debian and Ubuntu at the same time is pretty overwhelming [04:09] wgrant: True, but who'se going to be paying attention right now. [04:09] LaserJock: this sounds like, "it is a good idea, but i do not want to lose my right to upload" [04:09] white: a lot of people aren't running Debian, for instance [04:10] that is a problem i presume [04:10] Lots of people aren't running Intrepid. [04:10] very true [04:10] well, if new people really need a package, then they need to adopt the mentality of being responsible and maintaining the package [04:10] Most of the stuff I do works out just find done in chroots. [04:11] if a new package is really needed for the world, then debian will package it anyway, sooner or later [04:11] ScottK: Same here. [04:11] white: +1 and we should encourage that. [04:11] white: Correct. [04:11] a lot of people also come up with new packages, which are let's say not that useful [04:11] I should compile popcon stats for our packages. [04:11] :( [04:11] I don't like popcon [04:12] and because it is the easiest way to contribute for them and they feel proud of having a package, i do understand that they want to get it in as easy/fast as possible [04:12] mostly because all my packages are very low on popcon ;-) [04:12] Or perhaps check how many have never had non-workflow bugs. [04:12] however, it needs to be made clear that this is not the best contribution, despite their efforts [04:12] white: that would work for probably a lot of people [04:12] but we've always had some people who resist the "you've got to get it in Debian" proposals [04:13] some people don't particularly like working with Debian (for whatever reason) [04:13] some people think Ubuntu should take packages that Debian might reject [04:13] well that is kind of hard seing that ubuntu depends on debian [04:13] Right. The response to "But I don't want to be responsible" should be "Then why do you think we want to be"? [04:13] and some people think that Ubuntu should be a more independent from Debian [04:14] LaserJock: Then those people aren't living in the real world. [04:14] so I guess a question is how do we have a reasonable proposal that people in general can get behind [04:15] I've advocated at times just shutting REVU off, but that's probably a bit drastic [04:15] get packages into debian first or get a responsible maintainer (whatever that means), who intends to bring it into debian (either alone or with someone from debian) in a reasonable time> [04:16] wgrant: Now that all upgrades to the development release are from Upstart releases (vice sysv-init) it was seriously proposed that we should rewrite all Main init scripts to be upstart native. [04:16] my guess is that we could use a combo of education (on how to get packages in Debian) and MOTUs pushing people towards Debian more [04:16] if $package is not in debian after one release cycle drop it again [04:16] That should happen eventually. [04:16] ScottK: ^^ [04:17] white: well, getting a responsible maintainer is the hard part, IMO [04:17] white: how would we figure that out? [04:17] wgrant: When it provides some actual benifit porportional to the added maintenance burden. [04:17] ScottK: Or Debian moves off sysvinit. [04:17] Agreed. [04:17] Which it hopefully will eventually. [04:18] LaserJock: by checking the package, before it gets sponsored and other contributions the person made [04:18] LaserJock: and his willingness (via email) to maintain the packages and probably bringing it into debian [04:18] white: most people who contribute packages don't have previous contributions per se [04:19] Fix 100 bugs, get a ticket to upload a NEW package! THat would discourage people. [04:19] well, in many cases I would let them send it to debian-mentors@ and point them to debian [04:19] hehe [04:19] I've also extracted promises to sign up as bug contact for the package. [04:19] ScottK: That should always happen. With no exceptions. [04:19] so would we just have people agree, via email or something, that they agree to either maintain the package in Debian or maintain the package in Ubuntu [04:19] wgrant: Maybe LP could make it automatic. [04:19] well, i got to go do some studies, just highlight me, if you want my opinion and I'll try to read it later :) [04:20] ScottK: : if we didn't have the DebianMaintainer issue it would be automatic, I think [04:20] LaserJock: No. Maintainer and Changed-By have no significance in LP. [04:20] or hmm [04:20] Apart from Changed-By being on the end of the fake changelogs. [04:20] for some reason I was thinking I was automatically sub'd to my packages [04:21] guess I must have done it myself ;-) [04:21] hmm [04:22] it seems to me that a "Maintain it in Debian or Ubuntu" ultimatum would be reasonable and broadly supported [04:22] When does dinstall run these days? [04:22] the only question is perhaps how to determine what "maintanence" means in Ubuntu since we don't formally have that [04:23] Being set as the maintainer, subscribing to the package, handling bugs, not being on the UEHS alerts for too long... [04:24] I suppose one could do a review at the end of one release [04:24] where somebody looks over the history of the package, etc. [04:24] Around beta, I would suggest. [04:25] well, I was thinking 6 months after it entered the archive [04:25] to try to stagger it a bit [04:25] That works. [04:25] so somebody doesn't have to do them all at once [04:26] I don't think there'll be many left after the first round. [04:27] perhaps not [04:27] well [04:27] maybe the first thing to do [04:28] would be to enhance the UEHS metrics [04:28] It would normally do popcon, but Ubuntu popcon is too old. [04:28] and do a review of *existing* packages to see what portion are not being maintained [04:29] I see from UEHS that a majority of packages are outdated [04:29] at least of the ones that have watch files (I'm guessing that the ones without watch files aren't going to be better) [04:29] fujitsu@syklone:~/mdt/versions$ wc -l uehs [04:29] 1239 uehs [04:29] popcon is'tn on by default anyway [04:30] Hobbsee: It's still more useful than nothing. [04:30] hmm, this is a difficult problem [04:30] :( [04:31] it seems like it'd mostly need to be done by a person [04:31] for instance (and perhaps I shouldn't be sharing this ;-) ) [04:32] I maintain plotdrop [04:32] but there have been 3 uploads in more than 2 years [04:32] there are no bugs in either Debian or Ubuntu [04:33] so how would one determine if I was maintaining it or not? [04:33] I'm not sure. [04:33] One of my packages is doing rather well, another isn't so much, though people do use it. [04:33] one would most likely have to look at what else I'd been up to [04:33] to see that I care about my packages in general [04:34] Right. [04:34] That would have to come into it somewhere. [04:34] yes, most recently touched for all your packages. [04:34] which definately creates a bootstrapping somewhere [04:34] or least if you want that metric [04:34] s/somewhere/problem/ [04:34] I think by the time this conversation is don't we'll need a Kalman filter. [04:35] heh [04:35] don't/done [04:35] g'night all [04:35] * wgrant has a good filter: "lambda: false" [04:35] That will fix our problems. === asac_ is now known as asac [04:46] wgrant: is universe_not_sid posted cronned and public? [04:47] crimsun: isn't that http://qa.ubuntuwire.com/multidistrotools/universe.html [04:47] *on [04:48] LaserJock: looks like it, but I haven't been involved in some time. [04:48] thanks. [04:49] crimsun: It's cronned but not public. [04:49] But other parts of that directory are, so I'll symlink it somewhere. [04:49] Aha. [04:50] http://qa.ubuntuwire.com/multidistrotools/universe_not_sid is the plaintext. [05:09] has DktrKranz talked to you guys about his transition tracker? [05:13] I'm particularly interested in what MOTU think of the design [05:15] I think that lobbying LP people to implement the small required changes would be better. [05:15] hmm, do you think LP would really be able to work that way? [05:16] I wonder if we could pay "LP people" to implement the changes. [05:16] I suppose minimally if people could unsubscribe from implicit subscriptions we'd be able to use LP as we would've normally [05:16] Right. [05:16] but I think a transitino tracker could be *better* than what LP could do [05:17] Why? [05:17] well, because LP is never going to explicitly create a transition tracker [05:18] at least I can't ever imagine them doing so [05:18] and if it's done without launchpad, there's the likelyhood that a) it won't break, and b) that if it does, it'll actually be fixed in a timely manner. [05:19] as in, not requiring to wait till the next release cycle, or something. [05:19] for instance, the tracker DktrKranz wrote just uses a plain text file to set up a transition [05:20] OTOH, so far, accepting packages via the UI hasn't broken so far this cycle. [05:20] (it has the last two) [05:20] although I suppose that could all be done in LP via scripting as well [05:21] I say just use big LP bugs that spam lots of people until the LP developers implement unsubscribe from implicit subscriptions to avoid lynching. [05:22] ScottK: you know that they won't do that in a timely manner. [05:22] i'ts not a use case that non-distro people use, so it won't get any priority at all. [05:22] well, it's apparently not a trivial issue at all [05:22] LaserJock: Anything they don't want to do is by definition non-trivial. [05:23] plus, whenever you do things like that, it breaks accepting packages, which is kinda useful. [05:23] well, that's not the reason I say it [05:23] so, i will probably poke you with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™ if you do. [05:24] LaserJock: By definition, if you've engineered (I use the term loosely) a system that requires 422 database queries to provide a single bug page, virtually anything is non-trivial. [05:25] right [05:25] That's a real number from the last bug page I opened: [05:25] is it 422? ouch. [05:25] at least. No promises it's not more. [05:26] well, in any case, I'm not sure if transitions are a very good use-case for LP so my thinking was perhaps we could do a better job [05:26] BTW, note that 2.39 seconds. That's a very long time to make people wait (and that's just for the database). [05:26] letting LP handle what it's supposed to, bugs [05:27] Any transition management discussion ought to be on ubuntu-devel in any case because it's not just a Universe thing. [05:27] for sure [05:27] but I was interested in what people thought of the design [05:28] Mentally multi-task bugs actually fit pretty well for me. [05:28] I'm not sure when people would go somewhere else to check and see if there was something on the transition tracker related to a package they were working on. [05:29] well, I was expecting that only people interested in the transition would be using it [05:29] and that it would be useful to see all transitions grouped somewhere [05:30] But wouldn't you also want people interested in the affected package to know about it? [05:30] not necessarilly [05:30] I mean, they should get that info via the bugs, no? [05:30] If we're using bugs. [05:30] of course [05:31] but the design was to use 1 bug/package rather than a large metabug with lots of tasks [05:31] That'll be really painful to file, won't it? [05:31] no, the tracker does it for you [05:32] OK. [05:32] you commit a plain-text template file with the packages involved, any comments (on a per package basis) [05:32] additionally, transition summary, transition description, and transition drivers [05:32] that information is used to file the bugs and subscribe the drivers [05:33] the perpackage/comments are added to the individual bug reports [05:33] s|/| | [05:34] It sounds like a lot of work to work around and LP bug, but it seems doable. [05:34] well, my point is that it's not a workaround [05:34] but a perhaps a better way to do transitions [05:35] we can continue to do transitinos via LP [05:35] I'm not seeing how it's better (assuming people could unsubscribe)? [05:35] well, it's easier to set up a transition [05:35] and if we collect them it's easier to see all ongoing transitions [05:35] Last time I set one up in LP it was one email to write. [05:36] I kind of liked the fine-grained control of bug reports [05:37] but that's why I'm asking you guys [05:37] if you don't see any benefit then it's good to know now [05:37] I personally like the idea [05:38] For setup it seems like write one plain text file versus write one long email. I see that as even. [05:39] People would only get bugmail about their package of interest with your approach and not the rest of the transition (not sure if that's a bug or a feature)? [05:39] well, I generally consider it a feature [05:40] but I guess everybody might not [05:40] I think for any transitions that might take discussion about individual packages the current system is not very good [05:41] you end up with a lot of jumbled up threading of comments on the metabug report [05:41] I'd like to be able to discuss individual packages [05:42] I can see that. [05:42] discussion of the transition as a whole should probably be done via mailing list [05:42] so the task is to be able to have people working/discussing individual packages involved in the transition [05:43] whilst making it easy for drivers to see overall what's going on [05:44] unless LP were to grow a per-task commenting feature I'm not sure it's possible to do that [05:49] LaserJock: I apologize. I've just hit a brick wall and need to go to bed. [05:49] Good night. We can continue this some more. [05:49] ScottK: well, I'm pretty much toast too [05:49] I'd encourage you to think some more on Launchpad deficiiencies that are driving you to make this external tool. [05:49] ScottK: I'll have DktrKranz send some emails to get more discussion [05:49] I suspect it's the right answer for now [05:50] Get \sh to integrate it in leonov and you'd have something. [06:50] oops I miseed LaserJock === Mez is now known as Mez|Moving === gaurdro_ is now known as gaurdro [10:32] morning [10:37] morning [10:40] morning [10:44] mourning [10:45] "Anything new?" [10:47] if someone from motu-sru has some spare time on their hands, please take a look at bug #241402. thanks :) [10:47] Launchpad bug 241402 in mythbuntu/8.10 "Mythbuntu control center VNC setup freezes if & in password" [Medium,Fix committed] https://launchpad.net/bugs/241402 [10:48] while it's fixed in intrepid, it still needs an SRU for 8.04 [11:16] any revu master can tell me about the fate of a package I'm trying to upload to revu? [11:16] foolano: name? [11:16] RainCT: libapache-authcookie-perl [11:17] foolano: it was rejected [11:17] agghh [11:17] may i know why? [11:19] foolano: have you logged in before you uploaded the package? [11:21] RainCT: I uploaded it in first place without being logged in. It didnt work and I logged in to upload it again. But I did both things in a short period of time [11:21] maybe i should have waited a bit longer? [11:22] now i've been logged in for at least 20 min [11:22] should i try now? [11:22] ok [11:23] oh and to add a bit more of entropy to the process i did the merge REVU accounts thing [11:25] * RainCT notes that he just did a minor update to REVU and that you will notice two new items in the menu now (well, new as in that they weren't in the menu before) [12:03] RainCT: I can see my upload if i click on "My packages" but it doesn't show up on the front page [12:09] foolano: it shows in "Updated packages", for some reason [12:10] RainCT: right, i guess that's cuz i uploaded several times [12:10] it* [12:12] foolano: no, that's the reason - https://edge.launchpad.net/ubuntu/+source/libapache-authcookie-perl [12:14] RainCT: the thing is it was removed from debian a few months ago because the package was unmaintained, after the debian sync in intrepid it was removed too [12:15] yep, but REVU doesn't seem to know that. feel free to file a bug about it [12:25] RainCT: done [12:38] foolano: thx [12:40] foolano: I moved the upload to new [12:49] RainCT: thx :) [13:07] lo [13:08] I have a package, which is already packaged for Ubuntu (ufraw) [13:08] however, it's compiled with plain cflags... [13:08] and ufraw is one of those apps which can actually significantly benefits from SSE [13:08] now, I could just hack the packages CFLAGS and gecompile... but that would be nasty [13:09] are there guidelines, on how to package a single source package build two binary packages each with different CFLAGS? [13:09] for example "ufraw" and "ufraw-sse" which provides plain "ufraw" [13:12] pmjdebruijn: ufraw cannot do run-time detection of CPU features? [13:13] I don't think so [13:14] that's unfortunate [13:14] true [13:15] so in the meanwhile I'd like to modify the source package to produce two binary packages [14:54] does somebody know how to strip "-Wl," from LDFLAGS inside a Makefile? [14:57] geser> Strip? [14:58] remove without touching other LDFLAGS? [14:58] By the way, does anyone want a package reviewed? [14:59] LDFLAGS is set to "-Wl,-Bsymbolic-functions" by dpkg-buildpackage, I could set LDFLAGS to "-Bsymbolic-functions" in the Makefile but I prefer to be flexible if the default changes and want only the "-Wl," removed [15:00] something like ${LDFLAGS#-Wl,} but for a Makefile [15:00] geser, using if's maybe? [15:01] LDFLAGS = $(shell echo $(LDFLAGS) | sed s/-Wl,//) [15:01] LucidFox: thanks, will try that out [15:07] LucidFox: doesn't work, the build still fails with ld: unrecognized option '-Wl,-Bsymbolic-functions' [15:07] Weird [15:08] Wait! [15:08] You should pass LDFLAGS="$(LDFLAGS)" as an environment variable to make [15:08] LDFLAGS="$(LDFLAGS)" make [15:09] doesn't "export LDFLAGS" inside the Makefile do the same? [15:26] Jazzva: Hey. I just got an email from upstream saying that development versions are odd numbered (0.7.x, 0.9.x, 1.1.x) and Stable versions are even numbered (0.8.x, 1.0.x, 1.2.x). [15:26] LucidFox: no wonder it doesn't work as expected, the value got already added earlier to an other variable [15:26] Iulian, right, then it's easy to make a regex :) [15:28] Iulian, http://.../pkg-[0-9]*\.[0-9]*[02468]\..* [15:28] I suppose something like that should work [15:28] Jazzva: So how do I use mangle option to exactly match upstream version? [15:28] Aw [15:29] Iulian, that will allow any number as major ver, a number that ends in an even digit as minor ver, and anything after that as release ver [15:30] Jazzva: Cool, thanks. Maybe some day I will understand the watch file better. [15:30] ;) [15:30] Iulian, to make it more strict you can use http://.../pkg-[0-9]+\.[0-9]*[02468]\..+ [15:31] Iulian, that will require to have something as major and release ver, so it will skip pkg-.2. (which is illogical) :) [15:31] Iulian, sure thing. It's not that hard... [15:54] This channel desperately needs a quote database. [15:54] why say you? === dereck is now known as Awsoonn [16:08] oops. if someone from motu-sru is listing, please remove the team from bug #224780 - i subscribed you guys to the wrong bug report ;) bug #241402 is the correct one. [16:08] Launchpad bug 224780 in mythbuntu-control-centre "Hardy - Myth Control Centre - optimize_mythdb.pl moved?" [Undecided,Fix committed] https://launchpad.net/bugs/224780 [16:08] Launchpad bug 241402 in mythbuntu/8.10 "Mythbuntu control center VNC setup freezes if & in password" [Medium,Fix committed] https://launchpad.net/bugs/241402 [16:14] when a file in directory X is updated, I want to run scrit foo; Is there a simple way to do this? [16:16] aren't there watch scripts for that [16:16] * pmjdebruijn is just ranting... [16:27] Awsoonn: there's a program that does that. I'm searching for it now [16:28] dnotify - Execute a command when the contents of a directory change [17:31] LucidFox: re bug 252318: ehcache depwaits on libhibernate3-java which depwaits on libjboss-cache1-java which depwaits on jbossas4 which is blocked by bug 184557 [17:31] Launchpad bug 252318 in ehcache "Please move to multiverse" [Undecided,New] https://launchpad.net/bugs/252318 [17:31] Launchpad bug 184557 in jbossas4 "Circular build-depends, needs initial bootstrapping on the buildds" [Medium,Confirmed] https://launchpad.net/bugs/184557 [17:32] have you an idea how to resolve this? [17:32] * LucidFox headdesks [17:32] actually, libjboss-cache1-java also depends on missing librarie [17:32] * libraries [17:32] This is a headache [17:33] LucidFox: it would be a start to get jbossas4 build as it would allow several libjboss-* to get build [17:34] I've tried to temporarily remove some build-dependencies to unbreak the cycle but didn't manage to get something that builds [17:34] I still wonder how the DD managed to get the package build on his machine, certainly not in a pbuilder [17:35] geser: LucidFox: Only way to get them built is bootstraping buildd [17:37] yes :( which needs help from infinity [17:38] On the bright side, as it turned out, Execute Query requires only two Java libraries not in Ubuntu, rather than a billion gazillion [17:38] anyone willing to take liquibase? [17:39] geser: LucidFox have time to review a small package? [17:39] tuxmaniac> sure [17:39] http://revu.tauware.de/details.py?package=gresistor [17:40] geser: Or, probably build only part of the source so at least some of the packages get built [17:42] Oooh, new and improved REVU [17:44] slytherin: if you figure out which part can be build to allow the other packages to get build to be able to undone the first changes (perhaps after some iterations) I'd sponsor them [17:44] LucidFox: even I was surprised. After a real long break I am back :-) [17:44] geser: I will try. Last time I tried I was running in circles. :-( [17:44] slytherin: me too :( [17:45] I wonder how fedora guys built jboss === AstralJa1a is now known as AstralJava [17:49] geser: Do you think the way jboss is packaged is wrong? [17:49] slytherin: I don't know, I didn't look much into it. [17:50] tuxmaniac> commented [17:50] geser: LucidFox: Anyone of you free enough to review update to 'electric'? [17:50] Apparently, with the upgrade, I lost my MOTU capabilities on REVU [17:51] LucidFox: ok thanks. I will update the manpage [17:51] slytherin: oh its still hanging? I would be more than happy to get it up in the repos [17:51] slytherin: btw, the .deb is 10 Mb. I think its better to split the package if there are a few arch indep stuff [17:52] tuxmaniac: it is all arch indep [17:52] tuxmaniac: There aren't much java guys among MOTU members. :-D [17:53] By the way, could someone review one of my two packages on REVU? [17:54] http://revu.ubuntuwire.com/details.py?package=fuse-zip [17:54] http://revu.ubuntuwire.com/details.py?package=subtitlecomposer [17:54] One is a console utility, the other a KDE3 application - take your pick === coppro_ is now known as coppro [18:05] LucidFox: I don't think we want new KDE3 apps for Intrepid [18:09] ScottK> Okay, that can be archived then [18:10] Can't archive it myself at the moment :/ [18:11] LucidFox: I just sent mail to Kubuntu devel to ask. [18:14] ScottK> Yes, I did merge my REVU accounts [18:14] with both sikon@lucidfox.org (which had MOTU capabilities) and sikon@ubuntu.com [18:14] OK. Just checking. [18:15] My recommendation is kvetch at NCommander when he shows up. [18:22] I am trying to solve FTBFS for libpdfbox-java. In the rules file there is a line which copied all the font files found in the build dependencies to a particular folder of the library. This causes FTBFS due to multiple packages containing same fonts. What is correct way to handle this? [18:27] LucidFox: I have added synopsis and author sections. the app does not have anything on options [18:28] so I leave it blank? I dont know what to put in. Its a very simpe but useful app [18:28] tuxmaniac> Just mention that it has no options [18:28] LucidFox: ok [18:52] LucidFox: updated the package. Kindly check whenever free. thanks === bmk789 is now known as Guest65844 === DreamThi1f is now known as DreamThief [20:08] slytherin: what about adding -u or -f to the cp call? [20:10] geser: will try === bmk789_ is now known as bmk789 [20:30] geser: Works, thanks for suggestion. === Majost_ is now known as Majost [21:43] I have the following two lines in a debian/links file: [21:43] usr/lib/libfmodex.so.4.16.07 usr/lib/libfmodex.so [21:43] usr/lib/libfmodexp.so.4.16.07 usr/lib/libfmodexp.so [21:43] Jazzva: for the case you are interested, there is a newer gnome-voice-control version (0.3) than that one in Ubuntu [21:43] The problem is that when I try to use these, the deb gets nulled out... [21:43] Hi all! [21:43] hi warp10 [21:43] and I am not exactly sure as to why [21:44] Heya RainCT [21:44] RainCT, yeah.... the developers said it depends on pocketsphinx, which we don't have atm. It's in REVU though :). [21:44] RainCT, thanks for the notice :) [21:45] I can probably just make the symlinks in the install section of my rules... but its still somewhat confusing [21:45] ah. /me goes to check the package on REVU :) [21:46] RainCT, in case you have time, you can review it (and sphinxbase, it's a build-depends of pocketsphinx). Though, it's a bit bigger package, I think [21:47] I left comments on both packages to make it easier for advocating. I'd be glad if some MOTU can review/advocate them :) [21:48] RainCT, thanks for checking :). [21:49] Jazzva: no problem. btw, the version in Hardy gives an error when I try to add it to the panel.. do you know what the problem could be? (the error is the standard one that it doesn't work and if you want to remove it again) [21:50] RainCT, yes. I just need to prepare a backport for 0.2 [21:50] Though I wonder if it's worth it. If I wait a bit more, we can get pocketsphinx, then package 0.3 and backport it [21:50] (and get it in Debian to... or at least 0.2) [21:51] Debian is frozen for Lenny, so no rush on getting new stuff to Debian right now. [21:51] ScottK, ok. Thanks [21:52] RainCT, I'll prepare a backport now and see if we can get it in Hardy [21:52] Jazzva: backport or SRU? [21:53] SRU, I suppose... I think this patch can qualify for it... [22:46] is it ok to use 0.2-0ubuntu5.8.04 for SRU, if current ver in stable is 0.2-0ubuntu5? [22:47] not according to the policy as far as I know [22:47] Jazzva: yep, but if you add an additional .1 it will follow the security release model (https://wiki.ubuntu.com/SecurityUpdateProcedures#Prepare) [22:47] Adri2000: doesn't the SRU policy say to use whatever you want as long as it doesn't cause problems? [22:48] Adri2000, RainCT, I missed the link to security policy. Thanks [22:50] yeah, I think I'll have to prepare SRU for Gutsy too. I'll go vith 8.04.1 and 7.10.1 [22:50] RainCT: I don't know. maybe/probably it changed since I looked at it. for me it should be .1 at the end, like -Xubuntu3.1 or -Xubuntu0.1 if there was no ubuntu change yet, etc. [22:51] Adri2000, I looked at it now. We can use .X.YZ.1 if we're preparing SRU's for more than one release [22:52] ok, that indeed makes sense if you are going to upload to multiple releases [22:54] Actually, IIRC the one in Gutsy should be fine... the problem happened in Hardy first. [22:58] https://wiki.ubuntu.com/StableReleaseUpdates says «Make sure that the version number does not conflict with any later and future version in other Ubuntu releases (The security policy document has a well-working scheme which can be used for SRUs.)» [22:58] right [23:04] hola [23:04] hi [23:07] hola fixutu [23:10] RainCT, you know if are there a ubuntu-motu channel on spanish? [23:12] fixutu: as far as I know, there isn't one [23:12] ok, thanks [23:12] fixutu: but I think there are "MOTU School" seasons in Spanish planned [23:14] i'll search about it, thanks a lot [23:18] fixutu: you're welcome :) [23:24] thanks RainCT i hope learn about a lot of about motu tasks [23:38] hello [23:42] If any guru packager has a minute, I'm looking for some comments on my revu package here: (http://revu.ubuntuwire.com/details.py?package=qlix) [23:48] i have xchat installed which requires >= tcl8.4 as a dependency and i need tcl8.5 for homegrown scripts. how can I get xchat to not report as broken with tcl8.5 installed instead of tcl8.4? [23:50] Sylphid: aren't tcl8.4 and tcl8.5 co-installable? [23:52] geser, they apear to be however tclsh reports the 8.4 version [23:52] so you need to grow a local, modified tcltk-defaults [23:53] Sylphid: try tclsh8.5 if you need that version [23:53] lets see if that works [23:53] is "LP xxx" (without the #) in debian/changelog recognized? [23:54] ahh .... thanks geser looks like tclsh is a sym link [23:54] should have caught that [23:55] RainCT: no [23:55] RainCT, was that for my benefit? about the LP xxx? [23:55] in fact, I often used "LP #foo" for references [23:56] SolarWar: yep :) [23:56] crimsun: thanks [23:56] RainCT, shouldn't it be with ":": LP: #...? [23:57] Jazzva: yes, dunno if it recognized it too without the ":" [23:57] * RainCT only knows that the parentheses are optional and that you can list more than one bug number separating them by ", " :P [23:58] * Jazzva didn't know about ", " [23:58] Cool :) [23:58] RainCT: the regex for it is: /lp:\s+\#\d+(?:,\s*\#\d+)*/ig [23:58] RainCT, nhandler remarked on this yesterday in his comments, posted on revu [23:59] oh wait [23:59] i see what you're saying