[00:58] hmm...does anybody do processing on lintian.d.o for things like tags over time? [02:14] hey broder [02:15] do you know if there's a script or site that can show me packages that are in universe but not in debian? [02:29] highvoltage: why yes there are scripts :) [02:29] http://qa.ubuntuwire.com/mdt/universe.html [02:29] thanks, ajmitch [02:30] Not in Wheezy : 1135 packages [02:30] I honestly didn't expect that number to be so high. [02:30] that includes a lot of i18n packages, packages removed from testing, etc [02:31] usually the comparison is between sid & the current ubuntu release, but the LTS is special [02:41] and that's not including main packages [02:42] right, there's probably quite a few more in main [02:44] yeah, at least the packages in main are probably cared for. I'm wondering about packages that should be dropped/orphaned in universe. (stuff like feisty-session-splashes, potentially) [02:45] highvoltage: we need to do a lot of cleaning before the LTS, so feel free to start now :) [02:47] micahg: yep. I'll do my part. If that list of 1135 packages could be halved for 12.04 then that would already be good I think. [02:47] so that script just compares between wheezy and precise? I guess some of those packages might be in unstable too [02:47] yep, some are updated in unstable, some removed [02:48] highvoltage: I can get you a list of the difference between unstable & precise [02:48] just not as pretty as mdt [02:48] well, that's not entirely good either, we don't want everything from unstable [02:49] ah, you mean in precise but missing in unstable [02:49] yes [02:49] carry on :) [02:49] ajmitch: yeah, I need to learn how that works. Ideally I'd like a column that says when the package was last updated, and how many bugs it has against it [02:49] micahg: I have that list somewhere as a byproduct of the rcbugs list [02:49] would be nice to have some kind of idea of which packages are bad and kind of abandoned [02:49] highvoltage: that's possible, might be best to do that with UDD [02:50] highvoltage: i think tumbleweed put a report kind of like that together [02:50] something like "packages that have gone the longest without being uploaded" [02:50] let me see if i can find it [02:50] well, there's a semi-automated script I think which can remove stuff that's been removed from Debian where we have no diff, maybe we can get that run before we start to file removal requests [02:51] broder: that would make sense, tumbleweed is always 2 steps ahead of me :) [02:51] http://qa.ubuntuwire.com/oldmerges/ [02:51] ajmitch: that's the one [02:52] also, lintian run is on "z" :) [02:52] it doesn't include packages that haven't been touched for years in debian & are unmodified in ubuntu, but that probably wouldn't be hard to get either [02:52] broder: nice [02:52] though i bet it'll take it a while to generate the html reports after it finishes [02:52] ajmitch: i think those packages are definitely a secondary concern for us [02:53] broder: I need to sort out stuff on mekaneck with wgrant, so that I can set up a CNAME record for lintian.uw.o [02:53] broder: agreed, the oldmerges page should keep us busy enough :) [02:54] ajmitch: no worries. i'll keep working on the output some anyway [02:55] broder: you plan to push the lintian reports there regularly? [02:56] yeah, i was planning to put it on a cron job [02:56] fair enough, tell me if you need me to set anything else up [02:57] i think all i need is somewhere to throw it [02:58] sure, you can put it somewhere in your home dir & I'll point apache to it [02:58] ok. sounds good. i guess i'll push it to people.uw.o for the time being until we get the CNAME setup [02:58] it's the same host, so whatever works :) [02:59] "arkose exists in precise (universe) but not in Debian" - not the most detailed output there per package, I guess [03:02] ajmitch: What's up? [03:04] wgrant: can you check if I have sudo access on mekaneck? [03:05] ajmitch: You seem to... [03:06] ajmitch: sudo -l ? [03:07] it's more likely that I can't recall which password I'd used at some time in the distant past on that machine, but I've never had a ~/.sudo_as_admin_successful on there [03:08] ajmitch: That is a slightly seperate problem :-) [03:09] StevenK: yeah, a pity that sudo doesn't just trust my ssh key :) [03:09] Haha [03:26] ajmitch: alias sudo="ssh root@localhost" [03:26] ;) [03:30] funkyHat: /win 28 [03:30] oops :) [03:30] * funkyHat looks in window 28. Huh, that's just #ubuntu-devel. ;) [03:30] funkyHat: yeah, that'd work with agent forwarding, and if the public key was allowed for root as well [03:30] #ubuntu-devel should be in your top 10 at least [03:31] It would break if you tried to use -i or anything else though [03:31] ajmitch: I have bindings for windows up to 100 [03:31] still no excuse :) [03:32] And -motu is 8, so -devel being 28 is nice because they have almost the same keybinding ⢁) [03:32] (I have a whole bunch like that, -meta sits on top of #u for example) [03:33] How sad ❡⢁) [03:52] broder: lintian stuff still rsyncing? [04:49] ajmitch: uh...it seems to have followed a recursive symlink :) [04:51] ajmitch: there [04:52] http://people.ubuntuwire.org/~broder/lintian/ (note: for those playing along at home, url not permanent. skinning not permanent. etc.) [04:55] broder: right, I was looking at the tags there & found I couldn't access them earlier :) [04:55] I'll point lintian.uw.o there [04:55] cool :) [05:12] Hmmm. [05:12] I wonder if I still have my Ubuntu lintian instance around somewhere. [05:13] I ran one for a little while years ago, but then liw started one in the DC. [05:13] http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ is still the canonical source for "ubuntu policy", in so much as it exists distinct from "debian policy", right? [05:23] ok. made a half-hearted effort to ubuntu-ify the output :) [05:29] broder: how long did it take to run over the whole archive? [05:30] day and a half, i guess? [05:30] maybe longer [05:30] so I guess you won't be updating it too often [05:30] wasn't really paying attention, and had to restart it a couple of times [05:30] it does incremental updates [05:30] ah good [05:30] I was about to ask that :) [05:55] ajmitch: ok. lab and sync is on a cron job now === jussio1 is now known as jussi [08:38] good morning [11:05] highvoltage: you are actually looking for http://ubuntu-dev.alioth.debian.org/cgi-bin/neglected-packages.cgi === dpm is now known as dpm-lunch === medberry is now known as med_temp [13:29] sladen vs kinect: http://www.youtube.com/watch?feature=player_embedded&v=sxZplO4XPpE [13:36] damn youtube === yofel_ is now known as yofel [15:07] tumbleweed: you mentioned before about debian unstable for a library with a constantly changing API/ABI. is there some kind of thing where i can hand over the packages to a maintainer? [15:08] i already made the packages but i have no idea what i'm doing because i'm a lacklustre maintainer [15:08] https://launchpad.net/~genjix/+archive/libbitcoin === dpm-lunch is now known as dpm === dholbach_ is now known as dholbach === Quintasan_ is now known as Quintasan [15:36] dholbach: hey, do you know who owns the ubuntu fridge calendar? [15:37] jdstrand, you should be able to make modifications if I read https://wiki.ubuntu.com/Fridge/Calendar correctly [15:38] dholbach: yes. I was able to add a calendar [15:38] dholbach: err, calendar item [15:38] dholbach: problem is, I want it to forget about one that is not in a calendar I control [15:38] dholbach: ie, kees' [15:38] good question [15:39] dholbach: 'Security Team Catch-up' should be forgotten by the Ubuntu Fridge clendar [15:39] maybe the guys in #ubuntu-news (or was it #ubuntu-news-team) know? [15:39] I'm fairly certain kees can't access that calendar any more too [15:39] * jdstrand tries [15:39] dholbach: thanks [15:41] dholbach: Your air hockey match should be up on internets soon, depending on when my ISP unbreaks my internet :) [15:42] Quintasan, oh man.............. it's not like I was actually good :) [15:43] Well, but the idea of playing with two of those disks was superb [15:44] ok, let's wait for the video then ;-) [16:51] genjix: Actually, I was talking about experimental. Having libraries like that in ustable isn't easy because you'll have lots of transitions to handle. [17:10] tumbleweed: ok [17:10] but same thing still [17:26] + Has there been a recent scrub to highlight the orphaned packages in Universe? It might be useful to make them visible and put them up for adoption? Failing that, possibly look at removing from the archive? [17:26] dholbach: should that perhaps also be a work item? ^^^ (to initiate/drive a scrub?) [17:28] maybe [17:28] or bring it up on the mailing list? [17:33] ok [18:04] so if I have a package in Oneiric that segaults, and an to fix it I need to fix a library and then rebuild, would I need to do 2 separate SRUs? [18:04] s/and an/and/ [18:04] Hello, what was the last sync from Debian testing to precise ? [18:04] s/what/when [18:06] Is it not ongoing still? [18:06] AnAnt: try asking an archive admin in #ubuntu-devel [18:07] geser: how can I know archive admins ? [18:07] simply ask and hopefully someone will answer [18:08] LaserJock: yes, well, 2 uploads, I think 1 bug can track both [18:09] if the library is used to build other packages would I have to rebuild those too or is it enough to leave them alone? [18:09] there are only a handful, but I'd rather not have to SRU a bunch of packages to fix 1 [18:10] LaserJock: are you breaking ABI with the fix? [18:10] depends, if the soversion changes yes, else no [18:10] there were just headers that failed to be installed via the .install [18:11] the broken packages need those headers, the code isn't changing [18:11] how did the rdeps build then in the first place? [18:11] without the headers [18:12] they must not have needed those particular one [18:12] s [18:12] not needed, or disabled some features? [18:12] I don't know yet [18:13] is there a reason that the following packages are not sync'ed from Debian testing: xpra & xcb-util-renderutil [18:13] should be checked, it would be problematic if yes, as the next update of the rdeps will enable new features not previsously in the release [18:14] AnAnt: there probably hasn't been a sync since before UDS [18:14] ok [18:14] xpra is version 0.0.6+dfsg-1ubuntu1, so it needs merged or manually synced after explaining why the diff can be dropped [18:14] ajmitch: oh [18:15] mjeanson: btw, here's the link to the ding-libs source package I last uploaded: http://mentors.debian.net/package/ding-libs [18:15] does request-sync also only look in testing? [18:15] it always complains that ubuntu version is newer [18:15] although its not since 3 days [18:15] AnAnt: the other one is a new package apparently and those are syncd less frequently than what's already in then archive [18:16] micahg: ? [18:16] micahg: why's that ? [18:16] different set of commands I think? [18:17] AnAnt: if it's needed relatively soon, you can file a sync request (still has to go through NEW though) (idk about syncpackage and new packages) [18:18] micahg: ok, thanks [18:18] NEW syncing also includes checking if the new binary packages don't "overwrite" other binary packages from existing source packages and also processing of the NEW queue (accept/review the source package) [18:18] hm is something wrong with importing new versions from debian? [18:19] deleted my lpcache and its still not letting me sync ._. [18:19] new versions or NEW source packages? [18:19] just version numbers [18:19] check what LP knows about the package in Debian and Ubuntu [18:19] requestsync thinks python-django-piston is newer in ubuntu than debian [18:19] which package btw? [18:20] jtaylor: requestsync should be looking at testing, so that's correct [18:20] how do I force it to unstable? [18:20] tried setting the base version [18:20] jtaylor: -d unstable [18:20] ah, xpra is also a new package ! [18:20] and parti-all needs to be removed [18:21] AnAnt: ah, yes, new source, binaries are in already [18:22] yey changelog not found ._. [18:22] that shouldn't be a blocker [18:22] ok then the manual way ._. [18:23] or can one already sync via a button in launchpad? if yes can someone do that? its an security update [18:23] we use a script (syncpackage) not a button [18:24] micahg: so, should a removal be requested for parti-all (because of the Ubuntu delta), or that isn't needed anyways ? [18:24] a security update probably shouldn't have used urgency=low [18:24] hi all, i just uploaded a package to REVU (my first) and I was wondering if anybody could spot-check it for me to see if there are any serious issues: http://revu.ubuntuwire.com/p/mixxx [18:25] AnAnt: yeah, if we have a diff, you can file that after the new source is sync'd though [18:25] tumbleweed: I agree, it was a bit weirdly handled, debian stable hasn't got the update yet either [18:25] rryan`: we're trying to get rid of REVU, and generally trying to get new packages in via Debian [18:26] rryan`: but in this case, mixx is already in Ubuntu, are you trying to update it? [18:26] micahg: shouldn't the removal be requested first before syncing xpra (since both provide the same binary packages) ? [18:26] what's the best way to build a package if it requires a package not in the archives? PPA, local repo, some trick with pbuilder? [18:26] AnAnt: no, the new binaries will supersede the old ones [18:26] micahg: thanks [18:26] tumbleweed : yup, we just released a new bugfix release [18:26] LaserJock: PPA is probably most straightforward [18:27] shouldn't have to do anything special - just upload the out-of-archive dependencies, then the actual package [18:27] tumbleweed : oneiric onwards has 1.9.0+dfsg0-4, 1.9.2 is our latest version [18:27] broder: make sense, thanks [18:28] rryan`: I suggest you contact the debian maintainers of the package. Packages filter through from Debian to Ubuntu (unless there's a good reason for them not to) [18:28] (also in this case, the maintainer is active in Ubuntu too) [18:28] http://packages.qa.debian.org/m/mixxx.html [18:29] tumbleweed: gotcha, thanks. I did send alessio a note but haven't heard back from him yet [18:30] indeed, also, that team is pretty open, so if you'd like to help maintain in Ubuntu/Debian, I'd suggest joining the team and doing it in the Debian Multimedia git repo [18:30] rryan`: he was at UDS last week, probably still getting home / recovering. Give him a few days... [18:30] tumbleweed : k, will do [18:31] (assuming you poked him in the last week) [18:35] jtaylor: synced [18:36] thx [18:37] jtaylor: need release nominations for the bug? [18:37] is already on the security sponsors todolist [18:37] * tumbleweed should probably learn more about Ubuntu's security workflows at some point... [18:37] jtaylor: I suggest joining #ubuntu-security [18:38] not -hardened? [18:38] jtaylor: we have a role for processing sponsored patches [18:38] thats what I was told last time is the place to go :) [18:38] jtaylor: either. -security forwards to -hardened [18:38] UDS kinda put last week behind, but I think tyhicks may be looking at it [18:49] Laney: I see you got mentioned on bansheegeddon [18:49] highvoltage: of course he would be [18:52] highvoltage: he's part of the supersecretelite debian team that looks after such packages [19:03] geser: DMB? [19:07] now? [19:16] geser: yes [19:18] forgot that due to DST change it's now an hour earlier for me [19:19] mdeslaur: ^^ you win :) [19:19] heh [19:20] micahg: hehe :) [19:20] micahg: what did he win? [19:20] geser: the right to say "I told you so" :) [19:39] tumbleweed: have you pushed any of your requestbackport stuff anywhere yet? i want to experiment with writing a backport bugbot === Amaranth_ is now known as Amaranth === Amaranth_ is now known as Amaranth [20:56] broder: right, I think I finished that on the plane, let me test it and push it to a branch for you to play with [21:03] i wrote commit and pushed it into a bzr branch to update python-rbtools 0.2 to 0.3.4. the package is also in debian, so does the new ubuntu version number have "ubuntu" in it? [21:04] as in 0.3.4-1ubuntu1 or should it be 0.3.4-1? [21:04] it would be 0.3.4-0ubuntu1 in that case [21:04] * ajmitch saw that the maintainer hadn't replied to the 'new upstream version' bug filed in february [21:05] i want to get this into the 12.04 release that i want to move our company to (from fedora13), is doing the work in ubuntu the best way, or having debian get the upgrade and doing a sync to ubuntu? [21:06] it'd be best to get it done in debian first & synced - you'd have until feature freeze to get that done [21:06] providing an updated package for the debian maintainer to look at can be useful [21:06] ok, so take my bzr changes and make the same change to the debian package? [21:08] yes, though you'd be basing it off the upstream tarball [21:08] right [21:08] the debian maintainer may not find a bzr branch useful :) [21:08] no, probably not :) [21:08] was it much work to update it to the new version? [21:08] mentors.debian.net might be useful [21:08] no, not too much work [21:09] but i had some questions: [21:09] 1) it's one debian policy version behind, does it need to be updated? [21:09] 2) in the bzr checkout, there's a .pc directory at the top level that had some patching info in it, it's not in debian's checkout or anywhere else, so i deleted it in my branch since it seemed like cruft [21:10] if you've checked that the package follows the policy updates in 3.9.2, then you could update it in debian/control [21:11] yeah, i've been doing a few debian packages over the years, but definitely not an expert to know the differences between policy updates [21:11] i did a git diff in the debian policy repository, but didn't see anything relevant [21:11] There's a checklist in the debian-policy package. [21:11] In general, I wouldn't worry about it. [21:12] http://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt also has it [21:12] BTW, i'm a MacPorts committer and we have a policy where if a ticket isn't responded to in 3 days a non-maintainer can make a change, is there a similar policy in debian or ubuntu [21:12] There is actually Ubuntu policy not to update the policy version relative to Debian since it generates meaningless diff. [21:12] policy changes in minor version are generally minimal [21:12] ScottK: I figured that it'd be ok to update the version in this case when offering it to the debian maintainer [21:12] ScottK: this is about preparing a diff for Debian (iiuc) [21:12] blair: Debian has a similar policy for severe (release critical) bugs. For Ubuntu there are no dedicated maintainers so anyone can fix anything. [21:12] ajmitch: True. [21:12] Laney: OK. Nevermind then. [21:18] blair: also, we're not going to hold up 0.3.4 from going into ubuntu if you can't get a response from the debian maintainer in a reasonable amount of time [21:20] broder: lp:~stefanor/ubuntu-dev-tools/requestbackport [21:21] tumbleweed: cool. i'll check it out tonight [21:22] broder: my demo bug https://bugs.staging.launchpad.net/bugs/860919 [21:22] Error: malone bug 860919 not found [21:22] note that all the non-production launchpads don't know that precise is the current dev release, so play along [21:23] * broder nods [21:23] dogfood thinks we are on 'rusty robot' :P [21:23] looks reasonable [21:23] ajmitch, thanks, i'll prepare the patch for upstream and update the ubuntu tickets with the status [21:24] alright, thanks [21:24] tumbleweed: that seems to have all the information we'd expect to show up in the bug report [21:24] as a random thought, it might be cool to have a verification checklist in the "testing" section [21:24] yes, if you will provide one of those [21:24] i'll see what i can come up with [21:25] ...but not while i'm at work. i'm far enough behind from UDS :) [21:25] it currently has << Mention any build & install tests you've done >>, < List the reverse dependencies that you've tested > [21:25] oh right, we got stuck because there's no good way to lookup rdeps for the not-current release in the absence of chdist/chroot/etc. setup, right? [21:26] we decided to solve that with a webservice [21:26] we just need to write it... [21:27] broder: unless you went with manually grabbing the Packages files & using grep-dctrl [21:27] ajmitch: *good* way :-P [21:27] :) [21:28] we should make the ubuntu-dev-tools refuse to proceed if you've left templates in [21:28] * ajmitch still has to get that backport tester in a working shape for demo purposes [21:28] especially submittodebian [21:28] Laney: good point, but please file a bug because I'm pretty tired (thankfully, slept until 2pm today...) [21:29] ditto [21:29] tumbleweed: it's not like you would have had a long flight? :) [21:29] * ajmitch was tired after UDS, but that was more because of getting up at 2AM to listen in on sessions [21:30] ajmitch: no, it was shorter on the way back, only 18 hours total :) [21:30] that's nothing [21:31] :) [21:32] dunedin->seville was about 36 hours travelling each way, was a fun trip :) [21:51] tumbleweed: hmm...looks like the determine_destinations isn't quite working correctly. determine_destinations('precise', 'hardy') -> ['hardy', 'lucid'] [21:51] but as of right now we'd still need to do maverick/natty/oneiric backports for that as well [21:59] true [22:00] it might be sufficient to reset support_gap every time you hit an LTS [22:01] that sounds reasonable [22:04] broder: pushed [22:12] why not just take every supported release between the 2 in question [22:12] ah, nevermind :)