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