[00:18] Hi. If I'm looking to help with packaging or fixing bugs, where is the best place to look for things needing to be done (that isn't going to interfere with other's work)? I've worked through the wiki and have the precise toolchain setup on my machine... [00:28] dnewkirk: 2:30am for me, so I'm off to bed. But: https://wiki.ubuntu.com/MOTU/TODO has some links. I usually say, the best place to start is with something that affects you personally, and you want to fix it. e.g. a package in universe that you use, and isn't being cared for (lots of open bugs) === JackyAlcine is now known as EvilJackyAlcine === EvilJackyAlcine is now known as JackyAlcine === udienz__ is now known as udienz [07:52] good morning === yofel_ is now known as yofel === EvilResistance is now known as Resistance === TheEvilPhoenix is now known as EvilResistance === almaisan-away is now known as al-maisan [11:12] micahg: I think I get that. We need people to be able to propose merges to the configs branch... What's the best way of doing that? === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === nigelb_ is now known as nigelb === mdeslaur_ is now known as mdeslaur === Guest22186 is now known as Zic === micahg_ is now known as micahg [13:59] Laney: not sure I see the issue, once you have a regular non-junk branch, you should be able to propose a merge === bdrung_ is now known as bdrung === udienz__ is now known as udienz [14:49] NOW, BACK TO THIS! [14:49] if I push this branch https://code.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs [14:49] and then click 'Propose for merging' it tries to merge with lp:ubuntu-transition-tracker [14:50] it would default to the branch it's stacked on, that can be changed though [14:50] can I make it unstack? [14:50] it's a completely separate repository [14:51] sure, but wouldn't people just need to propose merges *to* that branch and not *from*? [14:51] to this branch https://code.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs [14:51] which says it is stacked [14:51] I assume that is why the other one is linked to lp:u-t-t [14:55] reconfigured it, let's see what that does [14:57] bah [15:01] bzr \o/ [15:09] Laney: if you make the configs branch the development focus, that should do the trick for merges, right? [15:09] whether its stacked or not shouldn't matter, surely? [15:10] what should i do to update a package (network-manager-openconnect) to a new version for precise? [15:11] there's a ftbfs of the package on armhf because of the glib thread api change this is already fixed upstream so a new version should fix the FTBFS [15:11] toabctl: talk to cyphermox as I think he touched it last [15:12] micahg, ok. [15:13] micahg, there's no way to create a branch and send a merge request'? [15:14] toabctl: ah, this isn't the version in Debian, still worth asking cyphermox in case he was already preparing an update, otherwise, yeah, a merge proposal/debdiff would be the way to go [15:15] micahg: Is it on purpose that a package used in Xubuntu and Lubuntu (abiword) got put in the new desktop-extras packageset? [15:15] ScottK: eh, not necessarily on purpose, but I don't see us having exclusivity on it [15:16] anyways, the current uploaders can already break those flavors with -desktop updates, so I don't see it as such a problem, we'll caution desktop-extra only people to play nice with the flavors :) [15:17] anyways, all uploaders should be aware of whether or not their uploads are in a another packageset at least and the impact of that (at least I would hope), not necessarily impact beyond that though [15:18] As long as they know it's not an exclusive type thing. [15:19] yeah [15:34] tumbleweed: indeed, but then doing it for ben becomes annoying. is this just a limitation of lp? [15:37] Laney: it will remember the popular merge locations, after a while, I think [15:37] I'm entirely rusty on this, though === jpds_ is now known as jpds === jbernard` is now known as jbernard === al-maisan is now known as almaisan-away [16:46] * achiang wonders if ubuntu-dev-tools should Recommend or Suggest quilt [16:46] achiang: why? [16:47] edit-patch? [16:47] tumbleweed: well, i'm just thinking out loud, but if you're working on packages, chances are high you'll need quilt. [16:47] that moved to devscripts [16:47] achiang: that's what packaging-dev is for [16:47] oh [16:48] tumbleweed: thanks, i didn't know that one [16:50] it's relatively new === bulldog98_ is now known as bulldog98 === jtaylor_ is now known as jtaylor [19:57] ScottK: Hmm, I wonder if I could/should upload the source to my PPA nevertheless - and let Debian lag behind this time. :) [19:58] I'd just switch to the versioned depends. [19:58] debating boost still? [19:58] My view has been that switching boost versions is not something you ever want to do by accident. [19:58] There is no 1.48 in Ubuntu ;) [19:58] True, but there's discussion about if we should switch or not. [19:58] no 1.48 yet, there's still time to get it in by accident :) [19:59] ajmitch: Yes. Totally uncoordinated transition attempt in Debian is going about as well as one might expect. [19:59] Right, but I would hope that a.) either the bugreport I just filed get fixed in Debian then, or b.) someone doing a merge including that patch. :) [19:59] I don't think anyone actually wants to coordinate a transition in ubuntu as well [19:59] s/then/by then/ [20:00] I see that 1.48 is in testing, at least [20:02] ScottK: Uhm, you just seem to have argued differently (to "switching boost versions is not something you ever want to do by accident") [20:02] Or I did misunderstand you in #debian-devel [20:02] s/stand/stood/ [20:03] * ajmitch suspects a little bit of sarcasm [20:04] Oh, just found out that there was mor sarcasm involved in ScottK's statements, I just wasn't following the boost mess too closely to notice, though. [20:04] ScottK: at least unity uses versioned build-depends :) [20:04] ajmitch: So do all the KDE packages that use it (in Ubuntu). [20:05] Duh, usually I am quite sarcastic myself and now fell for it. *bangs head against wall* [20:05] Sorry. [20:05] has discussion about 1.48 in ubuntu only been on irc? [20:05] ajmitch: Yes. [20:05] * ajmitch has probably skimmed over much of the discussion in #ubuntu-devel [20:05] ScottK: might be worth a mail to ubuntu-release [20:06] micahg: I resigned from caring about boost beyond repeating that I don't have time to pay attention to it. [20:07] it's something I could possibly do over the next couple of weeks that I'm off work, if it's necessary [20:07] * Rhonda . o O ( wget -r irclogs.ubuntu.com; ack-grep -a 'boost.*1\.48' irclogs.ubuntu.com ) [20:07] since ScottK seemed to want to drop me in it anyway [20:08] ajmitch: would you care to mail ubuntu-devel/ubuntu-release about it then? [20:08] once I look at how much work it is :) [20:08] Will there be a UDS in Vienna? [20:09] ajmitch: here's what the last one looked like: http://people.canonical.com/~ubuntu-archive/transitions/boost1.46.html [20:09] micahg: yeah, I was looking at that ubuntu-devel thread from august [20:26] installing ubuntu-dev-tools on a clean vm pulls in quite a few packages these days === santiago-ve is now known as foursixnine [21:00] Rhonda: why Vienna? [21:01] Because then I can sleep at home, and at least attend. [21:01] and because it's a great town! [21:02] Rhonda: budapest wasn't *too* far away :) [21:05] well, far enough and bad timing with my kiddo that I wasn't able to attend :( [21:14] can someone explain to me how this kind of bug report is at all useful? https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/788454 [21:14] Error: ubuntu bug 788454 not found [21:15] it's an automatic crash apport report... crazy complex gtk stack trace just doesn't seem usable to debug the problem... no information on how to reproduce, no core dump... [21:17] psusi: core dumps are removed after apport retraces crashes [21:18] psusi: steps to reproduce are in the description as well [21:18] micahg: without the core dump, how am I supposed to figure out what went wrong? [21:18] I can't load it up in gdb and poke around, and so if I can't reproduce the error... [21:19] i thought that was fairly clear from the stack trace - it's an assertion failure in gdk_rectangle_union [21:19] broder: yea, but why? [21:19] my guess would be use-after-free [21:20] that or something is just passing bogus data to gdk_rectangle_union, but that seems less likely [21:20] hrm... maybe a run with valgrind would help if that were the case.... [21:22] i mean, i'm taking shots in the dark here, but the rest of the stack trace doesn't really look suspicious, and it was deep gtk internals calling the gdk function, so i'm assuming the likelihood that gtk is screwing up its calls into gdk are pretty low [21:23] I'm sure it's a bug in gparted... but it looks like the kind of thing that it made some object with some weird values and then tried to update the display... but figuring that out from the stack trace doesn't really seem possible [21:24] window_rect in frame 8 is pretty suspicious looking [21:24] if it's a use-after-free, a core dump wouldn't help you [21:24] those values in window_rect look suspiciously like pointers to me [21:26] I wish I could just load up the coredump in gdb... [21:26] but what would you look for? [21:27] if it's use-after-free, the evidence has already been scribbled over [21:40] Quick question; I created a LXC to do my packaging in, and I'm now following the pbuilder instructions on the wiki to create an environment in that container, however at the very end, I get an error that "debootstrap failed" (that's the entire error message). [21:42] Are there packages that I must install in order for pbuilder to properly create? [21:55] so there's no way to get the core dump back? looks like this trace was done with some missing symbols for libparted, rendering the results less than useful: https://i87173081.restricted.launchpadlibrarian.net/87173081/Stacktrace.txt?token=8d7170a315a4651dd7935ddae004bbd6 [22:00] psusi: no, have you tried reproducing with the test case in the description? === adam_g_ is now known as adam_g [22:10] Rhonda: ScottK: ajmitch: http://lists.debian.org/debian-devel/2011/12/msg00545.html :), sanity has returned (at least for the time being) [22:12] micahg: so it may not hit testing before DIF then [22:12] I'm surprised that they managed to get libreoffice built in that time :) [22:12] ajmitch: it would have to be reverted and reuploaded before Dec 31 :) [22:13] still likely, but less likely to get the transition coordinated with the release team by then [22:13] it may still be worth emailing ubuntu-release about it though [22:14] the libreoffice failure was a gcc ICE, that won't be fun to dig out [22:14] yeah, and ubuntu-devel so that people are aware if they sync boost packages after DIF, there might be issues [22:15] but presumably people test build before syncing... [22:15] you're an optimist... [22:15] It's an interesting theory [22:15] I said presumably :) [22:15] certainly didn't hold up over the weekend :) [22:16] what broke? [22:16] nothing broke, but a few of syncs that FTBFS [22:17] ftbfs count is still looking a bit high [22:18] ajmitch: yeah, it doubled when the armhf ones were added, still most of those affected all the archs, but the rest were built previously [22:22] * ajmitch might need to just do package reviewing & bug fixing for the holidays then, instead of boost :) [23:30] what's the script to rebuild something in a PPA? [23:36] Riddell: maybe backportpackage? [23:45] hmm no [23:45] Riddell: are you trying to rebuild something that's already in a PPA, and you just want to do an automatic dch -i ? [23:46] it failed and the failure is transient so I want an automatic click the retry button [23:47] ah right === sagaci_ is now known as sagaci [23:48] we have the ubuntu-build command, but that only works on the main archive [23:54] hmm, I thought there was one for PPAs too, wonder why not