[00:00] arand: Should be updated in an hour or so. [00:00] Bah. [00:00] ari-tczew, who is no longer here. [00:00] :) [00:09] Laney: played around with ubuntu_upload_history a little this evening: http://people.ubuntu.com/~stefanor/upload_activity/ [00:09] more universe uploads than I expected [00:09] would be interesting to compare canonical vs community uploads :P [00:39] tumbleweed: indeedy [03:17] I notice that both avidemux and gddcontrol disappeared from ubuntu repos [03:17] launchpad does they that they are in 10.04 [03:18] is there a problem with main server or what? [03:19] MaximLevitsky: Disappeared how? [03:19] I don't have it in apt cache [03:19] I updated it and that doesn't help [03:19] Ah, it was removed because it fails to build. [03:19] https://launchpad.net/ubuntu/oneiric/i386/avidemux [03:20] https://launchpad.net/bugs/831096 [03:20] Ubuntu bug 831096 in avidemux (Ubuntu) "avidemux version 1:2.5.4-0ubuntu7 failed to build in oneiric" [High,Triaged] [03:20] I am sorry that I ask here, its not 100% ontopic [03:20] Apt-get doesn't let me install it [03:20] And I am quite sure I have everything right here [03:20] Maybe a problem with servers? [03:20] Right, it was removed because it no longer builds successfully. [03:21] And i guess gddccontrol too :-( [03:21] It has optional gnome-panel applet [03:22] Its really sad as I use it often [03:22] I know its not maintained [03:22] It was also removed, as it's a GNOME 2 panel applet. [03:22] nope, its not an applet [03:22] it has optional applet [03:22] "old gnome-panel 2 applet, unmaintained" [03:23] app itself is normal gnome2 app [03:23] Hm, let's see... [03:24] It controls lots of monitors [03:24] Sad that nobody maintains it [03:25] Maybe I should... [03:25] Looks like it could reasonably be revived if someone ports/removes the GNOME 2 dep from it. [03:25] I'll take a look [03:46] wgrant: and last question [03:46] what about KDE3 libraries? [03:46] I suspect they got removed too? [03:52] MaximLevitsky: I'm not sure about the KDE situation, sorry. But Qt3 is still around. [03:53] kdelibs4 got removed, that what I see [03:54] and I have app (kscope) also abadoned that I use very often [03:54] I compiled it from source [03:56] Sorry for trolling, but peoples say that windows breaks support for apps, and linux not... So much for that.... [03:58] MaximLevitsky: sorry, I can't quite follow. What's the question? [03:58] ubuntu 10.04 removed some packages [03:58] 11.10, you mean? [03:59] including as I see kde3 libraries [03:59] kdelibs was last in 11.04. [03:59] but why? [03:59] (also, Windows has probably the best backward application compatibility of any operating system... I don't see many people saying otherwise) [03:59] wgrant: agree. sorry for trolling :-) [04:00] Anyway, please consider not removing support for legacy apps [04:00] Bug #794513 [04:00] Launchpad bug 794513 in kdewebdev-kde3 (Ubuntu) "Please remove kdelibs and kdewebdev-kde3 from the archive" [High,Fix released] https://launchpad.net/bugs/794513 [04:00] IIRC we moved to KDE4 3 years ago now... [04:01] Agreed, but there are always apps that aren't ported [04:01] And upstream dropped support for all that *long* ago. [04:01] GTk1 I think is still included [04:01] There's only so much that it's practical for distributions to do, once upstream drops support. [04:01] or at least was for such long time [04:02] I believe libgtk1.2 was kept around mostly because there were proprietary applications that used it. [04:03] Applications that could not be ported. [04:03] Whereas, for KDE3 apps, it's more that nobody can be bothered to port them in the three years that they have been using deprecated libraries. [04:03] wgrant: but even if app is open source who has time to port it? [04:03] kscope was abadoned I know [04:04] but its only IDE with sane browsing support [04:04] I use it for all developing [04:04] If KDE upstream maintained the KDE3 libraries then we might have kept them around. [04:04] fair [04:05] But why there is need to maintain it? [04:05] the package from 10.04 does work just fine [04:05] Packages fail to build due to toolchain changes, or need security fixes, or whatever. [04:05] MaximLevitsky: if an application is important, somebody will port or maintain it. The problem comes when nobody maintains it (in which case it's not being used much) [04:05] Right. [04:05] For most FOSS applications it's not a problem, because someone will care enough to port it. [04:06] Apparently that's not the case for kscope. [04:06] There was attempt for Qt4 version, but it didn't work out [06:05] If I want a package of mine to be more compatible with Debian, I'd better use sysv init.d scripts and not upstart, right? Or should I have different packages for Debian/Ubuntu? [06:14] alkisg: it sounds like you're not relying on any of the advanced features of upstart, in which case, just install sysV init.d scripts [06:14] My upstart jobs now starts on (filesystem and started networking), so will do, thank you :) [06:15] alkisg: if you were /relying/ on upstart, then you'd be using functionality that would not be possible to replicate in init.d scripts (* without basically reimplementing upstart) === Elbrus_busy is now known as Elbrus [09:59] tumbleweed: cool! [10:00] maybe it could also show the freeze dates? [10:01] yeah, I was also thinking that [10:01] i started to write the lplib importer [10:01] but then i got bogged down parsing the changelog and urgh [10:02] you can steal the bug closing regex from lp [10:02] i was just using vendor profiles to get launchpad-bugs-fixed [10:03] * tumbleweed finishes making http://qa.ubuntuwire.org/oldmerges/ prettier and faster [10:03] ah yeah if you are parsing .changes files, you can do that [10:03] you'll miss bugs closed in lp by syncs, though [10:04] dpkg-parsechangelog gives you it too [10:04] oh, I see [10:05] * tumbleweed doesn't want to even think about how slow an initial import will be [10:05] erk [10:05] I didn't consider doing that [10:21] I'm getting "update-rc.d: warning: /etc/init.d/epoptes-client missing LSB information" when I install my package that contains this sysvinit script, any hints? http://paste.ubuntu.com/709472/ [10:29] Hmm it seemed like a temporary error, I somehow had some dpkg-new entries in init.d/ [12:46] micahg_: is bug #670659 still valid or is this fixed in the current FTBFS pages? [12:46] Launchpad bug 670659 in FTBFS Report "Show FTBFS per packageset" [Undecided,New] https://launchpad.net/bugs/670659 [12:47] geser: just busy working on incorporating my historical graph into the FTBFS page (at the end of the page, rather than on a separate page) [12:47] Laney: I added some milestones http://people.ubuntu.com/~stefanor/upload_activity/ [12:48] nice [12:48] tumbleweed: I didn't had time yet to review your MP. Does it work with the multi-archive support of the script? [12:49] geser: haven't looked at all. Also, with the current state of the MP, it just spits out JSON, but doesn't generate the (previously static) html page that draws the graph [12:51] Laney: for oneiric, it looks suspiciously like it's including syncs before DIF. I tried to exclude that with WHERE signed_by != 'N/A'. That's about the best I can do, right? [12:52] tumbleweed: you could put the static files directly into the top-directory (I should probably move the css and the .js files there too and let the source link point to the LP project now that it exists) [12:52] my merge will update the source link [12:53] problem with the static pages as they stand is that we need to generate one per release [12:53] also, I don't think having that many graphs is useful. One, with the right configuration options, should suffice [12:56] could the graph be updated through JS to load the matching JSON data file? [12:57] well, right now you can add and remove series. I'll ad a dropdown to select architecture http://corelli.tumbleweed.org.za/ubuntu-qa/qa-ftbfs/oneiric-historical.html instead of one graph per arch [12:57] it can all come from one json file [12:58] that page does nto work with opera :( [12:58] jtaylor: any idea why? === Nigel_ is now known as G [12:59] geser: actually, I'll probably just dump the json into the generated html [13:00] what happened on sep 1? :) [13:01] don't know [13:02] the logs didn't show anything unuual [13:02] this is the error I'm getting with opera http://paste.ubuntu.com/709642/ [13:03] thanks [13:05] jtaylor: fixed? [13:05] yes thanks [13:21] So my problem (much) above seems to be that dh_installinit makes symlinks in init.d for upstart jobs, but it doesn't remove them before upgrading. So to migrate my app from upstart to sysvinit I had to put a preinst script and remove the symlinks manually :( [13:23] why do you migrate from upstart to sysvinit? [13:23] (09:05:02 πμ) alkisg: If I want a package of mine to be more compatible with Debian, I'd better use sysv init.d scripts and not upstart, right? Or should I have different packages for Debian/Ubuntu? [13:23] Mainly for debian compatibility [13:24] alkisg: you can have both in your package. debian/.init is for sysvinit and debian/.upstart is for upstart [13:24] alkisg: that way you can provide both, you'll have sysvinit on Debian and Upstart on Ubuntu [13:24] stgraber: yes, but I can't have one package for both distros [13:24] if it's not to much work provide both a sysvinit and upstart file. If I'm not mistaken Debian's dh_installinit will install the sysvinit and Ubuntu's dh_installinit prefers the upstart file [13:24] (binary) [13:25] alkisg: indeed, but all the packages get rebuilt when syncing from Debian, so that's not a problem [13:25] alkisg: assuming you plan on actually uploading that package to Debian [13:25] Any downsides for providing only a sysvinit script? [13:25] so this is for an external repository? [13:25] Currently it's being built on launchpad and uploaded on a PPA [13:26] if that's for a PPA/external repository, I'd suggest building two separate packages. If that's for actual archive upload, then provide both in debian/ and let the Debian and Ubuntu builders do the needed magic [13:26] I want to try if the same .deb works on debian, so that I can minimize the things I need to do for each release (now I only click on a recipe) [13:26] stgraber: Ubuntu won't be running both script on boot, right? Only the upstart one... [13:27] (the sysvinit and the upstart one) [13:27] alkisg: if the sysvinit script is a symlink autogenerated by the builder, then it'll only start it once [13:27] alkisg: only one will get installed during package building by dh_installinit [13:27] Ah, so dh_installinit is clever and only takes the upstart one [13:27] alkisg: if your binary package contains both a valid (non-symlink) sysvinit script + and upstart job, then both will start [13:27] Gotcha [13:27] Thank you guys [13:29] stgraber: the main reason I include a sysvinit/upstart script anyway, is because ltsp clients don't receive an if-up event, so I'll remove it completely if/once we fix that part in ltsp... [13:29] So I only use that script to fake an if-up event [13:32] * tumbleweed doesn't quite get the ARB poll. We are selecting 3 from 3? [13:32] alkisg: ah, yeah, not quite sure I want to fix that "bug" to be honest ;) as quite a lot of stuff can get triggered by the if-up event that we always handle another way [13:32] tumbleweed: yeah, that's a bit weird ;) it's basically some kind of confirmation vote but with no way of selecting "I don't want him" :) [13:32] anyway, got to run, flight is boarding! [13:32] stgraber: yeah, it either needs a NOTA or more applicants [13:33] stgraber: I think we only handle ntpdate, and it doesn't matter much if it gets called a second time. E.g: avahi-autoipd avahi-daemon ethtool ntpdate openssh-server postfix upstart wireless wpasupplicant [13:33] Let's think about it at BTS [13:34] It might even be better to remove our ntpdate handling [13:34] (as it's even ran synchronously now) [13:44] hmm [13:44] you get publication records when a new series is initialised from an old one [14:45] geser: done: http://people.ubuntuwire.org/~stefanor/lp-ftbfs-report/historical [14:46] looks great [14:47] will it do the right thing also when used on the archive rebuilds? [14:47] haven't tested that :P [14:48] does it list all package sets with a current count > 0 or also those which had in the past at least one FTBFS? (or even all available package sets?) [14:49] every time it runs, it records the packages with failed builds in a per-series-per-archive sqlite db [14:50] then it mines that db to produce aggregate failures per packageset per arch per day [14:50] yeah it just lists all package sets that appear in the data, so >0 failures [14:52] some cosmetic issues: can you configure the min step size and min value of the y-axis? try selecting only xubuntu or mythbuntu or utouch or netbook [14:52] right, I think we need to include 0s everywhere [15:00] I guess adding "yaxis: { min: 0; minTickSize: 1;}" would solve it [15:04] that still wouldn't be quite right [15:05] why? [15:06] there is nothing like -1 FTBFS or a fraction of a FTBFS (0.5 FTBFS) [15:07] the problem is that we are not displaynig data points where we know there were 0 failures [15:07] I do agree about adding those options, though [15:07] ah, that's an other issue [15:07] I was just looking at the y-axis [15:38] geser: there. My js-fu isn't great, took me a while... [15:49] and regenerated my demo [15:53] huhm, my neighbour called me for upgrade issues to oneiric - and now I'm stuck. :) === micahg_ is now known as micahg [17:17] geser: I think it's fixed now === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === Elbrus_ is now known as Elbrus === kloeri_ is now known as kloeri [19:40] ffs [19:41] the lplib method is rather annoying [19:43] to do what? [19:43] list uploads [19:43] Ah. [19:44] I'm tempted to suggest screen scraping, but people will shoot me for that. [19:46] http://paste.debian.net/137132/ [19:51] nigelb: yes, you would be shot for that [19:51] Laney: that's ugly [19:51] indeed. [19:51] isn't there something in python-debian you can use instead of calling out to dpkg-parsechangelog? [19:51] ajmitch: I know. Which is why I was careful not to suggest. [19:52] dunno [19:52] fix it? [19:52] "patches welcome" [19:52] or get nigelb to add something to the API so you don't have to do this [19:52] i filed a bug asking for them to expose the changelog url [19:52] drat, should keep a low profile of my lp hacking :P [19:52] that would be nice [19:53] nigelb: too late for that [19:53] and the closed bugs, indeed [19:53] But then, I'm careful not to touch Soyuz. [19:53] so you still have a tenuous grasp on sanity? [19:53] Yep! [19:53] Mostly I like solving UI things that irritate me. [19:54] Like the the one about mouseovering a bug and getting the bug title. [19:54] That's my proudest fix :D [19:54] i definitely looked at python-debian [19:54] some reason it didnt do what i wanted [19:54] hm [19:55] currently mainly need a way to ignore the spphs that you get when intialising a new release [19:55] any ideas? [19:56] * ajmitch hasn't dealt with that part of lplib [19:58] Neither have I. [19:58] nigelb: beware, you might get hired if you work to much on LP, happened to wgrant :) [19:59] geser: haha, I'll take that as positive outcome :P [20:04] Laney: I guess you have no choice but to keep track of versions you've already visited === ampelbein_ is now known as Ampelbein [20:05] Laney: for ubuntu upload history, can't you get changes files in the vast majority of cases? [20:05] i am searching for Published spphs with the same version [20:05] seems like it would be easier to just use the same method for everything [20:05] I suggest asking wgrant in the morning. He'd know better than all of us. [20:05] (in *his* morning) [20:05] it is his morning, just 7AM there [20:06] Oh right. Timezones. Gah. [20:06] yeah, wonderful things [20:06] means that I'm already at work on a monday morning now :( [20:07] aww :( [21:35] erm, well I think it works, but it is pretty much the slowest thing ever [21:37] how long does it take to run? [21:37] and are you tracking what you've checked in the past, so that you don't have to look up all of precise-changes for every run? [21:40] that is why we have created_since_date [21:42] oh it's not that bad if you give it a more recent date [21:43] going to run it from a cron job locally, or do you want to put it somewhere like qa.ubuntuwire.org? [21:45] i'll run it on samosa [21:45] if they install lplib for me [21:46] useful if you need access to udd as well, I guess [21:47] given that importing into udd is the whole point, seems to make sense [21:48] the one advantage of ubuntuwire is that it's about 3ms away from LP [21:49] Laney: I see you've just NMUed hp-ppd which is at the top of oldmerges (thanks to the NMU versions being lower than the ubuntu one). I hope you'll merge it :) [21:49] ajmitch: yeah, it is impressively quick for lplib [21:49] erm erm erm [22:42] tumbleweed, i think xmem need to sync instead of merge [22:42] bug 876032 [22:42] Launchpad bug 876032 in xmem (Ubuntu) "Please sync xmem 1.20-27.1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/876032 [22:46] udienz: agreed [23:24] does only rebuild package is approved to -proposed/-updates? [23:25] bug 873984 seems like proftpd-dfsg need to rebuild again cureent openssl [23:25] Launchpad bug 873984 in proftpd-dfsg (Ubuntu) "mod_tls and mod_sftp broken (need rebuild)" [Undecided,New] https://launchpad.net/bugs/873984 [23:26] udienz: if the package is currently broke, sure