[00:21] <lfaraone> Is there any real restriction beyond "we can distribute the binary legally" with software in multiverse? Can binary-only software be distributed this way?
[00:36] <JanC> lfaraone: as long as there are no restrictions about distributing and (very important!) redistributing, that's the only restrictions AFAIK
[00:38] <JanC> for example Adobe's flash plugin doesn't allow re-distribution, so it can't go into multiverse as is
[01:17] <lfaraone> JanC: okay. how do we evaluate SRUs for binary-only software in multiverse? If upstream or someone with access to the source provides a new binary, we can't audit that they followed the SRU criteria, right?
[01:24] <JanC> lfaraone: I suppose you'd have to rely on their word, which is exactly why open source software is preferred...
[01:25] <JanC> and I have no idea if there is any official process for that currently
[01:32] <lfaraone> JanC: okay, thanks.
[03:57] <paultag> Hey MOTU. I'm looking to practice debian-izing a small app that I wrote. It's in python. What should I be doing to make my debianizing life easy down the road ( only thing I can think of is build system, but I'm sure there is more )
[03:58] <paultag> and by debianizing, I mean rolling it into a .deb, this is Ubuntu only ( a small app for an Ubuntu team )
[03:58] <paultag> not that that matters :)
[04:14] <paultag> Anyone? Bueller?
[04:25] <micahg> paultag: are you packaging for the archive or for your own use?
[04:25] <paultag> micahg, PPA, I am not going to be guidelines strict. I get a lot of that upstream
[04:26] <micahg> paultag: ok, then we have a special channel for that: #ubuntu-packaging, but being the weekend, idk who's around, so patience is suggested
[04:26] <paultag> micahg, I don't quit freenode often :)
[04:26] <paultag> micahg, thanks :)
[04:26] <micahg> paultag: np
[08:01] <fabrice_sp> Hi. atlas is FTBFS because "Warning: In order to build Atlas under i386, you need the CPU extension sse3 available on your CPU"
[08:01] <fabrice_sp> is there any buildds that have sse3 capability?
[08:02] <fabrice_sp> or they are all virtualized?
[08:02] <tumbleweed> fabrice_sp: ran atlas on armel all night. It still loops
[08:02] <fabrice_sp> tumbleweed, thanks for trying :-)
[08:02] <tumbleweed> np
[08:02] <fabrice_sp> what is strange is that is doesn't seem to loop on Debian :-/
[08:03] <fabrice_sp> bug in compiler?
[08:03] <tumbleweed> dunno, can't see anything obvious. But I'm off hiking this morning - will have a look later
[08:06] <fabrice_sp> good hiking then :-)
[10:58] <BlackZ> fabrice_sp: openturns merge finished, I'm building it right now
[10:59] <arand> Can the debian packaging be GPLv3 when something that is packaged (e.g. images sounds) are under a "only along with this software and no modification"-type of license?
[11:04] <BlackZ> arand: just specify in the debian/copyright file other licenses of the software
[11:04] <BlackZ> specifying the files
[11:07] <arand> Yea, There's a whole tonne of them, since there's different contributors etc.
[11:07] <arand> So the GPL only applies to the debian/ folder, regardless of what is packaged then?
[11:08] <BlackZ> arand: yes, and the other files with the GPL license applied
[11:09] <BlackZ> arand: you can follow http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
[11:12] <arand> Oh, that's something to delve into alright..
[12:40] <EricBa> Please could someone revu my package at http://revu.ubuntuwire.com/details.py?package=cortina
[12:41] <EricBa> i ment review
[12:46] <EricBa> hier kriegt man nie ne antwort oder?
[12:49] <geser> EricBa: most people are idle, especially on weekends. And to find reviewers is at all times hard.
[12:50] <EricBa> i tried many times befor
[12:50] <EricBa> many days
[12:52] <geser> you are not the only person who has trouble to find a reviewer as only a few MOTUs do reviews
[12:57] <fabrice_sp> EricBa, I'll have a look
[12:57] <fabrice_sp> but I see 6 uploads a day, I don't know if it's still stable enough
[12:58] <BlackZ> fabrice_sp: merge of openturns finished bug #593284 it builds!
[12:58] <fabrice_sp> BlackZ, cool: I'll have a look later (I'm processing the sponsoring queue)
[12:58] <fabrice_sp> thanks ;-)
[12:59] <fabrice_sp> EricBa, here?
[12:59] <BlackZ> fabrice_sp: if you don't want to build it, http://launchpadlibrarian.net/50262430/buildlog_ubuntu-maverick-i386.openturns_0.13.2-4ubuntu1~maverick1_FULLYBUILT.txt.gz
[12:59] <BlackZ> the build will take around 1 hr
[13:00] <fabrice_sp> I know :-/
[13:00] <EricBa> yes
[13:00] <fabrice_sp> I always build locally, to check the resulting deb file
[13:00] <fabrice_sp> why are all dependency with versions?
[13:01] <fabrice_sp> it will make harder backporting, excp if mandatory
[13:01] <EricBa> it needs that version
[13:03] <EricBa> ok pkg-config and dbus dont need a version
[13:04] <BlackZ> fabrice_sp: so you will build it locally ?
[13:04] <fabrice_sp> sorry: have to go. Will check later
[13:04] <fabrice_sp> BlackZ, yes
[17:34] <ScottK> fabrice_sp: Even for i686 you can't assume sse2, so something needs to be done run time to detect if sse2 is present or not and not use it if it isn't.
[17:47] <fabrice_sp> ScottK, so what would be the fix for atlas in i386?
[17:48] <fabrice_sp> I can desactivate the detection of sse3, but I'm not sure the package will be usable
[17:48] <fabrice_sp> it compiles fine in amd64
[17:51] <tumbleweed> Automatically Tuned Linear Algebra Software - that says it all :/
[17:51] <tumbleweed> fabrice_sp: I've been looking at the armel build log, I'm not convinced that it wouldn't have eventually finished
[17:51] <fabrice_sp> so just slowness?
[17:51] <tumbleweed> very very slow. It keeps tuning things until it's happy, as far as I can tell
[17:52] <jpds> The arms are slow.
[17:52]  * tumbleweed is trying another build - a few days this time...
[17:52] <tumbleweed> jpds: I gave it about 8 hrs
[17:54] <fabrice_sp> I've desactivated it in the last upload, so until someone complains that there is no armel build of atlas, it will stay that way
[17:54] <fabrice_sp> the worst part is that the i386 build failed because of missing sse3 instruction in the buildds...
[17:56] <fabrice_sp> so right now, atlas is broken
[17:56] <tumbleweed> hmm: from debian's build logs:
[17:56] <tumbleweed> Build needed 42:20:15, 216776k disc space
[17:56] <fabrice_sp> 42 hours?! not too bad :-)
[17:56] <tumbleweed> that'll be on real hardware though, probably a lot faster (and doesn't segfault like qemu)
[17:57] <fabrice_sp> the armel buildds in Ubuntu are real hardware or qemu?
[17:57]  * tumbleweed was going to ask the same thing
[17:57] <fabrice_sp> :-)
[17:58] <BlackZ> fabrice_sp: Warning: In order to build Atlas under i386, you need the CPU extension sse3 available on your CPU
[17:58] <BlackZ> are you afraid to enable it?
[17:58] <tumbleweed> BlackZ: we can't require sse3 on i386
[17:58] <fabrice_sp> BlackZ, and this is in the buildds, not in my computer ;-)
[17:59] <jpds> fabrice_sp: Real hardware.
[17:59] <fabrice_sp> BlackZ, it's detected with cpuinfo
[17:59] <fabrice_sp> jpds, thx
[17:59] <BlackZ> fabrice_sp: ahhh, hmm ...
[18:01] <tumbleweed> fabrice_sp: oh you mean it needs sse3 for building a version that doesn't require sse3?
[18:01] <fabrice_sp> tumbleweed, not sure about not requiringsse3 to run, but build requires it
[18:01] <fabrice_sp> I have to disable the sse3 detection, and upload to a ppa, to test
[18:03] <fabrice_sp> BlackZ, your comment in Bug 589120 means that it can be a sync?
[18:04] <BlackZ> fabrice_sp: no, there's another change
[18:04] <fabrice_sp> ok: I've seen so many nug reports this afternoon that I don't remember each of them :-)
[18:05] <BlackZ> fabrice_sp: check in the changelog file
[18:05] <fabrice_sp> ok
[18:06] <fabrice_sp> about atlas: it build sse3 packages: libatlas3gf-sse3
[18:08] <tumbleweed> ah right. and it probably wants to test them so it can tune
[18:08] <fabrice_sp> exactly
[18:08] <tumbleweed> time for canonical to upgrade the buildd farm :)
[18:08] <fabrice_sp> hmm, my guess is that I will desactivate the optimized version :-D
[18:10] <jpds> tumbleweed: There's no better armel hardware to upgrade to.
[18:10] <tumbleweed> jpds: no I mean sse3
[18:10]  * jpds looks at wikipedia.
[18:21] <ScottK> fabrice_sp: sse2 detection needs to be done at run time.
[18:21] <ScottK> I'm not sure what needs to be done to achieve that.
[18:28] <tumbleweed> ScottK: this is for a -sse3 package
[18:28] <ScottK> Oh.
[18:28] <ScottK> Ignore me then.
[18:36]  * fabrice_sp has just uploaded a package that deltes all sse3 packages and 'downgrade' builds to sse2
[18:38] <fabrice_sp> BlackZ, why the second hcnage is still required?
[18:39] <fabrice_sp> IIRC, -DGTK_DISABLE_DEPRECATED is used to avoid error on deprecated methods
[18:40] <fabrice_sp> anyone can confirm that?
[18:41] <BlackZ> fabrice_sp: I think to allow to package
[18:41] <BlackZ> why drop it?
[18:47] <fabrice_sp> It seems that the comment is broken :-)
[18:48] <fabrice_sp> BlackZ, and this would allow us to sync the package ;-)
[18:48] <fabrice_sp> no bug is referenced, so it's hard to find why it has been changed
[18:48] <BlackZ> fabrice_sp: then feel free to rename the bug and delete the patch
[18:49] <BlackZ> I can't right now
[18:49] <fabrice_sp> if I were sure, I would have done it already :-)
[18:50] <fabrice_sp> I'll try to build 0.2.8-1ubuntu1 in lucid, to see if it FTBFS
[18:55] <fabrice_sp> BlackZ, 0.2.8-1ubuntu1 FTBFS in lucid, so that would explain the fix
[18:55] <fabrice_sp> I'll convert the bug to a sync request and ack it
[19:08] <dupondje> If something is ftbfs on armel, can we somewhere retry to build it to see if it build now ?
[19:08] <tumbleweed> dupondje: on your own qemu
[19:09] <dupondje> no other way ?
[19:09]  * tumbleweed has one set up if you want me to test for you
[19:09] <dupondje> https://launchpad.net/ubuntu/+source/loop-aes-utils/2.16.2-1/+build/1764607 => is quit a strange error :s
[19:10] <tumbleweed> that looks like a compiler bug
[19:11] <dupondje> gcc is upgraded
[19:11] <dupondje> so maby it works now
[19:11] <tumbleweed> ok, I'll test
[19:18] <tumbleweed> yay, qemu segfault :)
[19:19] <dupondje> lol
[19:20] <tumbleweed> dupondje: building (it probably won't segfault again until its done)
[19:21] <dupondje> what was wrong ? :)
[19:21] <tumbleweed> IO seems to cause it. it aften segfaults soon after running aptitude
[19:23] <dupondje> I hate it when merges reported are lagging :)
[19:23] <dupondje> accept them :D
[19:40] <dupondje> its still building ? ;)
[19:40] <dupondje> https://merges.ubuntu.com/universe.html => what are the different colors btw ? :)
[19:40] <tumbleweed> dupondje: yes, it's slow
[19:41] <tumbleweed> hah. I had to read the source to answer that for myself
[19:41] <tumbleweed> the colours are for debian priorities
[19:41] <tumbleweed> it really should say at the top "ordered by by priority"
[19:50] <tumbleweed> dupondje: same build error
[19:53] <dupondje> crap :(
[20:24] <anoteng> I'd like a review of http://revu.ubuntuwire.com/p/transgui . This is an application I and many others use daily, and I'd like to see it included in Ubuntu. I'm sure the pro's will find a lot of things for me to fix in the package… bug #332067
[20:35] <fabrice_sp> anoteng, version should be 0ubuntu1, target maverick
[20:36] <fabrice_sp> run update-maintainer to use latest value for maintainer
[20:36] <Rhonda> Alright. wesnoth-1.8 v 1.8.2 hit lenny-backports earlier than wesnoth-1.8 v 1.8 did hit karmic-backports.  %-)
[20:45] <arand> Is it possible to manage binary changes in the diff.gz? e.g. I'm adding an image, am I needed to stick it in the .orig.? (I'm not packaging with policy in mind..)
[20:50] <Rhonda> arand: With source format 3.0 (quilt) it's possible to manage binary changes.
[20:50] <Rhonda> Because it will be .debian.tar.gz instead of .diff.gz
[20:52] <arand> Ah, ok, I'm not using 3.0 then I guess.. Well making an .xpm of the image works as my quickfix :/
[20:52] <tumbleweed> arand: that are base64
[20:52] <tumbleweed> or
[21:19] <BlackZ> fabrice_sp: could you look at bug #593416 ?
[21:21] <fabrice_sp> BlackZ, strange enough: there is no qemu in maverick :-/
[21:22] <fabrice_sp> from karmic: Deleted in karmic-release on 2009-09-24  (Reason: merged into qemu-kvm,
[21:24] <BlackZ> hmm, but it provides the 'qemu' package
[21:24] <BlackZ> (seems the old one)
[21:24] <fabrice_sp> so sorry: it seems that you worked on a dead-end merge
[21:24] <fabrice_sp> yeah: the qemu package is the old one
[21:24] <BlackZ> ok, marking as invalid
[21:24] <fabrice_sp> seems so
[21:24] <BlackZ> please, unsubrscribe U-S
[21:25] <fabrice_sp> I found strange qemu in universe
[21:25] <fabrice_sp> done
[21:28] <BlackZ> fabrice_sp: so you could look at bug #590158 :P
[21:31]  * fabrice_sp hates merges from -0ubuntu1 versions :-)
[21:32] <fabrice_sp> I'll have a look tomorrow :-)
[21:33] <BlackZ> heh thanks fabrice_sp !
[21:33] <fabrice_sp> yw!
[21:33] <fabrice_sp> thanks to you to work on that!
[21:33] <fabrice_sp> really


[00:04] <daftykins> because of HDR mode
[00:04] <daftykins> 4K is utter rubbish tbh in new TVs, can't see the difference over 1080p easily... but HDR is a huuuuge change
[00:05] <penguin42> 4k on my new monitor is nice, but so are the extra 4 inches
[00:05] <daftykins> yeah that's comp usage, i'm really talking about video content her as per a TV
[00:05] <penguin42> daftykins: I don't see why HDR is giving that change - I'd expected more subtle gradations, not such a big overall difference
[00:11]  * penguin42 thinks he needs some experimental drivers to drive his at HDR
[00:49] <ali1234> HDR essentially separates the colour of an object from how bright it is
[00:49] <ali1234> without HDR the only way to make something "lighter" is to make it more white, hence the washed out colours in the first image
[00:51] <penguin42> hmm, ok, maybe I'm missing something about what HDR is - I just thought it was a higher bit depth - is it something else?
[00:51] <ali1234> it is
[00:52] <ali1234> just a higher bit depth
[00:52] <penguin42> so why does that change how you make it more white?
[00:52] <ali1234> because you can literally have values greater than "255, 255, 255"
[00:53] <penguin42> but aren't your bits getting added at the bottom, not the top?  So that your normal full range is 1023,1023,1023 and your HDR is giving you the subtelty for the range?
[00:53] <ali1234> no, that's the point :)
[00:54] <penguin42> oh...
[00:54] <ali1234> ultimately the actual "white" level is determined after you render everything
[00:55] <ali1234> ie what value gets mapped to 255, 255, 255 on your monitor
[00:55] <ali1234> and what value is 0,0,0
[00:55] <ali1234> the thing is, you can choose them after rendering
[00:56] <penguin42> oh, hmm that's not how I'd imagined it
[00:59] <ali1234> you can do this with 8 bit per channel but then you lose colour depth in the process
[01:00] <penguin42> yes, I guess that is easier to take existing code; I'd assumed I'd be seeing 10bpp pixmaps
[01:00] <ali1234> well you would be, but your monitor probably can't display them :)
[01:00] <penguin42> yes it can
[01:00] <penguin42> well, it apparently can; the advert says it can do 2^30 colours
[01:01] <penguin42> but perhaps that's just via this HDR mech
[01:01] <ali1234> well some monitors can
[01:02] <ali1234> but even so, white is still white
[01:02] <ali1234> because monitors are backlit
[01:02] <penguin42> (nod, having turned my brightness down to 30%)
[01:03] <ali1234> i believe HDR uses floats anyway :)
[01:04] <penguin42> https://www.youtube.com/watch?v=QkwmSzPdVnY
[01:04] <penguin42> ali1234: Down the monitor?
[01:04] <ali1234> no, in the internal render buffers
[01:05] <ali1234> the final step is to map that into the monitor colour space somehow - and maybe add a bloom effect on things that are too bright for the monitor to directly display
[01:05] <penguin42> yeh ok
[01:10] <penguin42> I need to fiddle with cabling to get the display onto the DP rather than the HDMI anyway I think before we can think about that, but I've not quite figured out where it will show up if the monitor can do it
[01:10] <ali1234> probably nowhere - i don't think xorg supports more than 32 bpp
[01:11] <ali1234> no idea about wayland
[01:11] <penguin42> ali1234: Well it's not even in the edid data that I can see
[01:11] <penguin42> ali1234: Although this is plugged in via the HDMI at the moment so maybe that will change
[01:13] <penguin42> (The monitor has one uDP, one full DP, and 2 HDMI, so juggling them is interesting)
[01:27] <daftykin1> problem with the basic mode in use in my pics is HDR10 is defined once at the beginning of setting the mode, whereas Dolby Vision is a constantly running variant
[01:27] <daftykin1> one of the kodi fork devs was working on splitting the metadata in Dolby Vision over the last few days, seemed interesting
[16:32] <penguin42> ali1234: ediddecode on this monitor plugged into DP shows '10 bits per primary color channel'
[16:32] <ali1234> cool
[16:33] <ali1234> but can you get Xorg to output that?
[16:34] <penguin42> ali1234: Not that I know of, I'm told there are some Mesa patches that might do it - but I don't understand what happens given that I have a 2nd monitor connected that is only 8bpp - I'm asusming it'll go to lowest depth
[19:22] <ali1234> I would expect the video card to drop the extra bits for the other monitors - if the driver supports it at all that is
[19:35] <penguin42> I'd expect it to only offer a depth supported by all devices
[19:38] <diddledan> a monitor can advertise 10bit support all it likes. that doesn't mean the panel is any more capable in displaying those extra bits
[19:39] <penguin42> diddledan: The advertised spec claims it can
[19:44] <zmoylan-pi> ...advertised...
[19:46] <penguin42> well, it seems to meet the other advertised features
[20:05] <brobostigon> evening boys and girls.
[20:06] <penguin42> hey brobostigon
[20:08] <zmoylan-pi> you're late :-P
[20:12] <Maefs> hi
[20:13] <Maefs> how are you?
[20:14] <diddledan> 12 hours late
[20:18] <brobostigon> hey penguin42
[20:18]  * brobostigon has spent most of the day with family,
[20:19] <zmoylan-pi> pffffft, what have they ever done for you? :-P
[20:19] <brobostigon> well, quite a few things.
[20:20] <zmoylan-pi> the aquaduct? :-D
[20:20] <brobostigon> sounds more like the romans, :). lolz.


[00:18] <dnewkirk> 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] <tumbleweed> 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)
[07:52] <dholbach> good morning
[11:12] <Laney> 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?
[13:59] <micahg> Laney: not sure I see the issue, once you have a regular non-junk branch, you should be able to propose a merge
[14:49] <Laney> NOW, BACK TO THIS!
[14:49] <Laney> if I push this branch https://code.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs
[14:49] <Laney> and then click 'Propose for merging' it tries to merge with lp:ubuntu-transition-tracker
[14:50] <micahg> it would default to the branch it's stacked on, that can be changed though
[14:50] <Laney> can I make it unstack?
[14:50] <Laney> it's a completely separate repository
[14:51] <micahg> sure, but wouldn't people just need to propose merges *to* that branch and not *from*?
[14:51] <Laney> to this branch https://code.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs
[14:51] <Laney> which says it is stacked
[14:51] <Laney> I assume that is why the other one is linked to lp:u-t-t
[14:55] <Laney> reconfigured it, let's see what that does
[14:57] <Laney> bah
[15:01] <directhex> bzr \o/
[15:09] <tumbleweed> Laney: if you make the configs branch the development focus, that should do the trick for merges, right?
[15:09] <tumbleweed> whether its stacked or not shouldn't matter, surely?
[15:10] <toabctl> what should i do to update a package (network-manager-openconnect) to a new version for precise?
[15:11] <toabctl> 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] <micahg> toabctl: talk to cyphermox as I think he touched it last
[15:12] <toabctl> micahg, ok.
[15:13] <toabctl> micahg, there's no way to create a branch and send a merge request'?
[15:14] <micahg> 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] <ScottK> micahg: Is it on purpose that a package used in Xubuntu and Lubuntu (abiword) got put in the new desktop-extras packageset?
[15:15] <micahg> ScottK: eh, not necessarily on purpose, but I don't see us having exclusivity on it
[15:16] <micahg> 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] <micahg> 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] <ScottK> As long as they know it's not an exclusive type thing.
[15:19] <micahg> yeah
[15:34] <Laney> tumbleweed: indeed, but then doing it for ben becomes annoying. is this just a limitation of lp?
[15:37] <tumbleweed> Laney: it will remember the popular merge locations, after a while, I think
[15:37] <tumbleweed> I'm entirely rusty on this, though
[16:46]  * achiang wonders if ubuntu-dev-tools should Recommend or Suggest quilt
[16:46] <tumbleweed> achiang: why?
[16:47] <tumbleweed> edit-patch?
[16:47] <achiang> tumbleweed: well, i'm just thinking out loud, but if you're working on packages, chances are high you'll need quilt.
[16:47] <tumbleweed> that moved to devscripts
[16:47] <tumbleweed> achiang: that's what packaging-dev is for
[16:47] <achiang> oh
[16:48] <achiang> tumbleweed: thanks, i didn't know that one
[16:50] <tumbleweed> it's relatively new
[19:57] <Rhonda> ScottK: Hmm, I wonder if I could/should upload the source to my PPA nevertheless - and let Debian lag behind this time. :)
[19:58] <ScottK> I'd just switch to the versioned depends.
[19:58] <ajmitch> debating boost still?
[19:58] <ScottK> My view has been that switching boost versions is not something you ever want to do by accident.
[19:58] <Rhonda> There is no 1.48 in Ubuntu ;)
[19:58] <ScottK> True, but there's discussion about if we should switch or not.
[19:58] <ajmitch> no 1.48 yet, there's still time to get it in by accident :)
[19:59] <ScottK> ajmitch: Yes.  Totally uncoordinated transition attempt in Debian is going about as well as one might expect.
[19:59] <Rhonda> 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] <ajmitch> I don't think anyone actually wants to coordinate a transition in ubuntu as well
[19:59] <Rhonda> s/then/by then/
[20:00] <ajmitch> I see that 1.48 is in testing, at least
[20:02] <Rhonda> 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] <Rhonda> Or I did misunderstand you in #debian-devel
[20:02] <Rhonda> s/stand/stood/
[20:03]  * ajmitch suspects a little bit of sarcasm
[20:04] <Rhonda> 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] <ajmitch> ScottK: at least unity uses versioned build-depends :)
[20:04] <ScottK> ajmitch: So do all the KDE packages that use it (in Ubuntu).
[20:05] <Rhonda> Duh, usually I am quite sarcastic myself and now fell for it.  *bangs head against wall*
[20:05] <ScottK> Sorry.
[20:05] <ajmitch> has discussion about 1.48 in ubuntu only been on irc?
[20:05] <ScottK> ajmitch: Yes.
[20:05]  * ajmitch has probably skimmed over much of the discussion in #ubuntu-devel
[20:05] <micahg> ScottK: might be worth a mail to ubuntu-release
[20:06] <ScottK> micahg: I resigned from caring about boost beyond repeating that I don't have time to pay attention to it.
[20:07] <ajmitch> 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] <ajmitch> since ScottK seemed to want to drop me in it anyway
[20:08] <micahg> ajmitch: would you care to mail ubuntu-devel/ubuntu-release about it then?
[20:08] <ajmitch> once I look at how much work it is :)
[20:08] <Rhonda> Will there be a UDS in Vienna?
[20:09] <micahg> ajmitch: here's what the last one looked like: http://people.canonical.com/~ubuntu-archive/transitions/boost1.46.html
[20:09] <ajmitch> micahg: yeah, I was looking at that ubuntu-devel thread from august
[20:26] <ajmitch> installing ubuntu-dev-tools on a clean vm pulls in quite a few packages these days
[21:00] <ockham> Rhonda: why Vienna?
[21:01] <Rhonda> Because then I can sleep at home, and at least attend.
[21:01] <Rhonda> and because it's a great town!
[21:02] <broder> Rhonda: budapest wasn't *too* far away :)
[21:05] <Rhonda> well, far enough and bad timing with my kiddo that I wasn't able to attend :(
[21:14] <psusi> 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:15] <psusi> 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] <micahg> psusi: core dumps are removed after apport retraces crashes
[21:18] <micahg> psusi: steps to reproduce are in the description as well
[21:18] <psusi> micahg: without the core dump, how am I supposed to figure out what went wrong?
[21:18] <psusi> I can't load it up in gdb and poke around, and so if I can't reproduce the error...
[21:19] <broder> i thought that was fairly clear from the stack trace - it's an assertion failure in gdk_rectangle_union
[21:19] <psusi> broder: yea, but why?
[21:19] <broder> my guess would be use-after-free
[21:20] <broder> that or something is just passing bogus data to gdk_rectangle_union, but that seems less likely
[21:20] <psusi> hrm... maybe a run with valgrind would help if that were the case....
[21:22] <broder> 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] <psusi> 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] <broder> window_rect in frame 8 is pretty suspicious looking
[21:24] <broder> if it's a use-after-free, a core dump wouldn't help you
[21:24] <broder> those values in window_rect look suspiciously like pointers to me
[21:26] <psusi> I wish I could just load up the coredump in gdb...
[21:26] <broder> but what would you look for?
[21:27] <broder> if it's use-after-free, the evidence has already been scribbled over
[21:40] <gnuvince> 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] <gnuvince> Are there packages that I must install in order for pbuilder to properly create?
[21:55] <psusi> 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] <micahg> psusi: no, have you tried reproducing with the test case in the description?
[22:10] <micahg> Rhonda: ScottK: ajmitch: http://lists.debian.org/debian-devel/2011/12/msg00545.html :), sanity has returned (at least for the time being)
[22:12] <ajmitch> micahg: so it may not hit testing before DIF then
[22:12] <ajmitch> I'm surprised that they managed to get libreoffice built in that time :)
[22:12] <micahg> ajmitch: it would have to be reverted and reuploaded before Dec 31 :)
[22:13] <ajmitch> still likely, but less likely to get the transition coordinated with the release team by then
[22:13] <ajmitch> it may still be worth emailing ubuntu-release about it though
[22:14] <ajmitch> the libreoffice failure was a gcc ICE, that won't be fun to dig out
[22:14] <micahg> yeah, and ubuntu-devel so that people are aware if they sync boost packages after DIF, there might be issues
[22:15] <micahg> but presumably people test build before syncing...
[22:15] <ajmitch> you're an optimist...
[22:15] <ScottK> It's an interesting theory
[22:15] <micahg> I said presumably :)
[22:15] <micahg> certainly didn't hold up over the weekend :)
[22:16] <ajmitch> what broke?
[22:16] <micahg> nothing broke, but a few of syncs that FTBFS
[22:17] <ajmitch> ftbfs count is still looking a bit high
[22:18] <micahg> 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] <Riddell> what's the script to rebuild something in a PPA?
[23:36] <ajmitch> Riddell: maybe backportpackage?
[23:45] <Riddell> hmm no
[23:45] <ajmitch> 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] <Riddell> it failed and the failure is transient so I want an automatic click the retry button
[23:47] <ajmitch> ah right
[23:48] <tumbleweed> we have the ubuntu-build command, but that only works on the main archive
[23:54] <Riddell> hmm, I thought there was one for PPAs too, wonder why not


[16:05] <mhall119> All 3 Qimo packages have been accepted into 10.04!!
[19:39] <mhall119> highvoltage: qimo-* packages made it through FFe!
[19:40] <pleia2> FFe?
[19:40] <pleia2> congrats mhall119 :)
[19:40] <mhall119> FFe=Feature Freeze Exception
[19:40] <mhall119> it means, despite being late, qimo-* packages will be in Universe for Luci
[19:41] <mhall119> Lucid
[19:41] <pleia2> aj. rogjt
[19:41] <pleia2> gah
[19:41] <pleia2> ah, right
[19:42] <mhall119> I'll be so happy to tell Ubuntu users "just apt-get install qimo-session"
[19:43] <highvoltage> mhall119: I saw the e-mails about the tarball problems, did you or jamie fix it?
[19:44] <mhall119> tarball problems?
[19:44] <mhall119> I haven't seen those emails yet, let me check
[19:44] <highvoltage> mhall119: I'm not sure whether it was my fault yet, I'll check in about 30 minutes after some people here leave
[19:45] <mhall119> ok, I'll check my end
[19:45] <mhall119> thanks for the heads up
[19:49] <mhall119> highvoltage: unless I screwed up how I was handling the .orig.tar.gz file, I'm not sure what's going on
[19:49] <mhall119> when I debuild -us -uc, the .deb I get doesn't have an archive within an archive
[19:50] <alkisg> Anyone with some experience in python packaging (setup.py, dist-utils etc) that cares to help in properly packaging sch-scripts? :)
[19:51]  * mhall119 needs to learn pythong packaging
[19:57] <mhall119> highvoltage: I did the dpkg-source -x 14:42 < mhall119> thanks for the heads up
[19:57] <mhall119> gah, dpkg-source -x qimo-session_2.0.0-ubuntu1.dsc
[19:57] <mhall119> and it didn't find the extra archive
[19:57] <mhall119> did you have to re-package it to upload it?
[20:01] <highvoltage> mhall119: nope, bit it is possible that something might have gone wrong on my side, I'll check and let you know within the hour or so
[20:03] <mhall119> thanks
[20:03] <mhall119> he said it won't effect the FFe grant at least
[20:31] <nubae> mhall119: I'm interested in python packaging, I have a python program I'd like to package..... did u write down your instructions somewhere?
[20:31] <mhall119> nubae: I said I need to learn it
[20:31] <mhall119> I have no idea how to properly package python apps
[20:33] <nubae> :-) ok... same boat then, however, I have been packagin pythong apps for opensuse for quite a while
[20:33] <nubae> but they are rpms
[20:33] <nubae> and I use buildservice for that
[20:34] <nubae> in theory, u can also cretedebs that way, but perhaps doing it the ubuntu prooopeer way would be better
[20:35] <mhall119> yeah, there's a difference between creating debs, and creating debs the ubuntu way
[20:35] <mhall119> if you want to get them into the repos, it's gotta be the ubuntu way
[21:12] <nubae> yah... :-(
[21:13] <nubae> I've been putting that off for far too long... I need to get into it though since I'm supposed to be at least moving towards a edubuntu membership position...
[21:16] <mhall119> heh, me too
[21:53] <Lns> Has anyone here looked into how skolelinux does user administration with lwat?
[21:54] <Lns> It seems to be something that edubuntu could really use..it's user/group/system administration based on an existing LDAP schema for schools specifically
[21:56] <alkisg> We should at least copy their ldap schema and make a package out of it, for easy ldap installation...
[21:58] <Lns> alkisg: check this out
[21:58] <Lns> http://maintainer.skolelinux.org/debian-edu-doc/en/debian-edu-lenny-manual.html#AEN792
[21:58] <Lns> it looks pretty mature
[21:59] <Lns> i'm talking to the skolelinux ppl right now and they say upstream lwat project is dying..maybe with a joint effort with us and skolelinux it could help maintain it
[21:59] <Lns> hehe, speak of the devil.. hi and1bm ;)
[21:59]  * alkisg doesn't really like web-based administration tools...
[21:59] <alkisg> I'd prefer if users-admin or some other tool was modified to support ldap, like kuser does
[22:00] <Lns> but this is much more..this does dns/dhcp and a lot of other things, and already has a schema built out
[22:00] <Lns> imho there's nothing wrong with web based admin tools as long as you secure them
[22:01] <alkisg> Nah I'm not worried about security, I don't like their interface
[22:01] <alkisg> Sure, having a default ldap schema in ubuntu (could be the same as skolelinux) would be great
[22:01] <Lns> well i'm just saying, there's a tool that already seems to do what edubuntu lacks for a school environment...it would be worth looking into collaborating on
[22:02] <alkisg> But it isn't actively maintained anymore?
[22:02] <alkisg> Why is that?
[22:04] <Lns> not sure..looking at the site right now
[22:04] <Lns> it looks like it was a project by a company at bzz.no
[22:07] <alkisg> Btw, for schools using thin & fat clients (not standalone PCs) ldap isn't really important... ldm ssh authentication works fine, and users-admin for creating/editing users accounts...
[22:10] <Lns> alkisg: i would really think that depends on the size of the infrastructure
[22:11] <Lns> and yikes...users-admin? Did they ever even fix the sorting by name bug?
[22:11] <alkisg> Sure, but if a school has some thousands of users, then it surely has a capable sysadmin that can install ldap manually... :)
[22:11] <Lns> alkisg: that's not a good assumption to make!
[22:12] <alkisg> Sure, I too want an easier ldap installation method - but I'd like it to be ubuntu-wide, not edubuntu-specific... so that it gets more support
[22:14] <Lns> alkisg: well of course, that's why I'm suggesting to both the edubuntu-devs and skolelinux teams that a possible collaboration might help everyone :)
[22:15] <alkisg> http://maintainer.skolelinux.org/debian-edu-doc/en/debian-edu-lenny-manual.html#AEN159 ==> "Dynamic desktop icons and menu options that adjust based on user group." - cool...
[22:17] <Lns> Yeah, there are tons of similarities between us and them
[22:55] <Lns> cheers all :)