[00:17] <kees> well that was fun. installed precise on top of a machine that had lucid on it. alternative install decided it was an EFI machine (BIOS yes, drive layout no), and installed grub-efi which happily ignored the old grub on the sda, which became highly confused about drives moving.
[00:17] <kees> seems like partman needs to learn about GPT and offer that on EFI machines.
[00:18] <cjwatson> Err
[00:18] <cjwatson> partman learned about GPT years ago and it's the EFI default
[00:19] <cjwatson> This is a bug, not a missing feature
[00:19] <cjwatson> But
[00:19] <cjwatson> If you already have a partition table, it isn't sane to offer a different partition table type
[00:19] <cjwatson> Rewriting the partition table would be very scary and very likely to break whatever's already on there
[00:20] <cjwatson> Dual-booting BIOS and UEFI installs on the same disk is not likely to work desperately well in general, really; you lose either way round
[00:21] <cjwatson> A BIOS boot loader can't boot a UEFI install, so leaving the existing GRUB on there wasn't an option, and as you say there are confusion issues with using a UEFI boot loader
[00:21] <cjwatson> Probably the right thing to do was to boot the installer in legacy mode (there's generally an option for this in the firmware boot menu) and then it would have proceeded in BIOS mode
[00:22] <cjwatson> If the installer is booted using UEFI, it assumes that it should install using UEFI too
[00:23] <cjwatson> Though if you weren't preserving the old partition table (it's not clear?), then perhaps we should zero out the old boot sector when doing a UEFI install
[00:23] <cjwatson> I dunno, doing that kind of thing scares me a bit
[00:24] <cjwatson> Maybe do it at the time the old partition table is wiped instead
[03:20] <pitti> Good morning
[03:24] <em> good morning
[05:44] <pitti> infinity, RAOF: I'd be grateful if you could process the postgresql-9.1 SRUs for bug 1055944
[05:44] <pitti> infinity, RAOF: standard microrelease exception, but the -9.1 update is rather urgent and people are nagging for it
[05:44] <RAOF> pitti: Sure.
[05:44] <pitti> I'll do the verification as soon as the packages are built in -proposed
[05:44] <pitti> RAOF: merci beaucoup
[05:45] <RAOF> Bitte
[06:01] <RAOF> pitti: Done.
[06:02] <pitti> RAOF: cheers! I uploaded the 8.4/8.3 updates as well, but they are a bit less urgent
[06:02] <RAOF> I might do them tomorrow on my regular processing day if infinity doesn't get to them first.
[06:03] <pitti> sounds fine
[06:31] <infinity> RAOF: Thanks for catching those, I was out all evening.
[06:32] <infinity> pitti: Many thanks for the fixed glib.
[06:51] <pitti> infinity: well, here's hoping it'll build at last..
[06:51] <pitti> I have no idea what changed on the arm builders that they suddenly became so slow/loaded/whatever
[06:52] <pitti> infinity: btw, if/when that builds, do you want them copied to quantal? there's no source changes compared to the one in quantal, just the arm ftbfs fix
[06:52] <pitti> infinity: but that would need coordination with image respins, of course
[06:53] <pitti> well, only source changes in tests, that is
[06:56] <dholbach> good morning
[06:56] <pitti> hey dholbach, how are you?
[06:57] <freyja_> can this https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1055766 bug just be deleted? It is a waste of everyone's time and immature. It's posted on /r/linux and will contribute to FUD. It's a waste of time and burden on the community.
[06:58] <dholbach> hey hey pitti - doing well, I'm almost over my cold :)
[06:58] <dholbach> how are you?
[06:58] <pitti> dholbach: je vais tres bien, merci :)
[06:58] <dholbach> excellent :)
[07:28] <bryceh> infinity (or another archive admin), mind bumping the nvidia packages from NEW?  https://launchpad.net/ubuntu/precise/+queue
[07:36] <bkerensa> bryceh: I did the fix you had for task
[07:38] <bryceh> bkerensa, awesome thanks.  Yes I did spot that today.
[07:38] <bkerensa> bryceh: do you think it will land quantal?
[07:38] <bryceh> bkerensa, one thing I noticed was that the fix was applied to source, rather than as a patch in debian/patches/, so I wanted to take a look at that.
[07:39] <bkerensa> k
[07:39] <bryceh> bkerensa, yes I am certain it will.  Even if it has to be SRU'd in post release, I'll help you make sure it happens.  :-)
[07:40] <bryceh> bkerensa, would you like to take a shot at adding the patch in debian/patches/ ?
[07:41] <bkerensa> hmm
[07:41] <bkerensa> I dont think I have done that before
[07:41] <bkerensa> let me go rtfm for a bit and have a try
[07:42] <bryceh> it looks like I already set up quilt for this package.  I think all you need to do is create a "debian/patches/<something>.patch" file, and then also add that filename to debian/patches/series and a changelog entry
[07:42] <bkerensa> hmm
[07:42] <bkerensa> ok
[07:42] <bkerensa> and revert the source back to what it was?
[07:42] <bryceh> yep
[07:42] <bkerensa> k
[07:42] <bryceh> bkerensa, cool, it's a good thing to learn to do.   If you get stuck or have questions just drop me a PM or email and I'll help.
[07:48] <Daviey> RAOF: hey, the precise unapproved SRU queue is looking pretty huge.. is iot being attacked?
[07:48] <Daviey> (The reason i noticed, is that we are being nagged for openvswitch which has been there since the 8th.)
[07:49] <bkerensa> bryceh: ok I made the changes I understand need to be made can you check and let me know if it looks sane or just comment needs fixing with suggestions
[07:49] <bkerensa> thx
[07:52] <bryceh> bkerensa, ok will do
[07:56] <bryceh> bkerensa, ok this looks good!  But a couple suggestions
[07:56] <bkerensa> bryceh: sure
[07:56] <bryceh> bkerensa, the patch should be named to mention what it's solving, not just a bug number since that can just be looked up easy enough
[07:57] <bkerensa> ok
[07:57] <bryceh> so in this case maybe let's see...
[07:57] <bryceh> only_stack_size_1.patch
[07:57] <bryceh> or whatever... something like that
[07:58] <bryceh> bkerensa, second, if the changelog make sure to answer three questions:  1.  Where did the  patch come from (e.g. upstream bug number or url), 2.  What does the patch do, and 3. What is the problem it fixes.
[07:58] <bkerensa> ok
[07:58] <bryceh> s/if the/in the/
[07:59] <bryceh> so 3 is "Fixes a crash when ...."
[07:59] <bryceh> 2 is something like "Check that the stack size is exactly 1 rather than just some value lower than 2" (or look at the upstream bug report if they give a better explanation)
[08:00] <bryceh> and 1 is just "Fixes upstream crash bug #xyz"
[08:01] <bryceh> as part of #1 I usually like to indicate if the patch was taken directly from upstream or if I've had to modify it in some fashion to get it to apply.  But that's probably irrelevant here.
[08:02] <bkerensa> bryceh: how do we list bug #'s for projects like task?
[08:04] <bkerensa> bryceh: "Cherrypick patch from upstream bug 1048 to fix a segfault when modify"
[08:06] <bryceh> bkerensa, "upstream bug 1048" would be sufficient.  Anyone looking at the package could be expected to figure out where their bug tracker is.  But if you want to be super clear you could just paste the full URL.
[08:07] <bkerensa> bryceh: ok and do I need to still mention our bug?
[08:08] <bryceh> bkerensa, yep always.  Just like you did, (LP: #1032861) appended to the description is perfect
[08:09] <bryceh> btw you don't have to mention that you updated the series
[08:12] <bkerensa> bryceh: ok all done
[08:14] <bryceh> bkerensa, good work!  Oh one last thing.  In this case instead of "* debian/patches:" can you make the changelog read "* debian/patches/only_stack_size_1.patch:"
[08:15] <bkerensa> surely
[08:15] <bryceh> it's nitpicky in this case since there's just the one patch, but in packages with a lot of patches it is helpful since then other devs can search for the patch name to see when it got added and why
[08:16] <bkerensa> bryceh: done and pushed
[08:17] <bryceh> bkerensa, excellent, looks good.
[08:30] <bryceh> bkerensa, upload sponsored for quantal. thanks again!
[08:30] <bkerensa> bryceh: :) thx
[09:24] <ev> mpt_: well, we could have done worse: http://people.canonical.com/~evand/tmp/Screen%20Shot%202012-09-25%20at%2010.21.16.png
[09:25] <seb128> ev, hey, did you see my ping yesterday?
[09:25] <ev> seb128: no - I guess that was past my irc bouncer scrollback buffer
[09:25] <ev> what's up?
[09:25] <ev> (I was on holiday friday and monday)
[09:26] <seb128> ev, is there known issue with e.u.c? I'm wondering why bug #1053670 is not showing up on the daily or monthly view seeing the list of duplicates from the retracers, whoopsie should at least have the same number and that should be enough to make it displayed on the main page
[09:31] <ev> seb128: it may have failed to retrace on the daisy retracers (but not the crash-digger ones): https://bugs.launchpad.net/daisy/+bug/1044418
[09:32] <ev> I'll try hunt it down on errors.u.c in a bit
[09:32] <ev> thanks for bringing that to my attention
[09:33] <seb128> ev, thanks
[10:02] <dpm> xnox, are you now maintaining ubiquity? And if so, could you look at bug 1040438 if you've got some time? thanks!
[10:05] <xnox> dpm: i'm not the only maintainer =) there are a few in the installer team taking. Well I saw the bug mail & there are a couple of other l10n issues, I may look at them in bulk sometime.
[10:06] <dpm> xnox, thanks. Yeah, I just wanted to know the best person to poke. I used to ping Evan, but I wasn't sure if he still maintained it
[10:07] <xnox> dpm: the best way is to simply add a tag 'rls-q-incoming'
[10:07] <dpm> xnox, cool, thanks.
[10:08] <xnox> and then appropriate teams will triange the bug and either nominate it for a release, assign to correct 'maintainer' etc.
[10:08] <xnox> dpm: that tag works on any supported package ;-)
[10:08] <xnox> not just ubiquity.
[10:10] <cjwatson> it's not a guarantee; we do elect not to commit to fixing some rls-q-incoming bugs
[10:10] <cjwatson> if the number of people using it rises, I expect we will commit to a lower percentage :)
[10:20] <pitti> ev: hey Evan, how are you?
[10:20] <pitti> ev: If you have a minute, I'd appreciate your opinion in bug 1039220 before I merge that branch
[10:20] <ev> hi pitti! I'm excellent, thanks.
[10:20] <ev> how are you?
[10:20] <ev> will do!
[10:21] <pitti> ev: I'm great, thanks! (when I'm not headdesking on glib FTBFS, that is :) )
[10:22] <ev> :)
[10:56] <doko> pitti, please see the pkgbinarymangler ftbfs
[10:59] <doko> directhex, gnome related ftbfs: libgtk2-perl, (main), gcompris, glade-3, gestreamermm, launchpad-integration, libgnomecups (package sets)
[11:00] <doko> forgot gtk2-engines
[11:01] <doko> tkamppeter, please have a look at the hplip ftbfs, https://launchpadlibrarian.net/117005844/buildlog_ubuntu-quantal-i386.hplip_3.12.6-3ubuntu1_FAILEDTOBUILD.txt.gz
[11:04] <directhex> doko, hm?
[11:04] <doko> seb128, please could you add the ubuntu-toolchain-r ppa as a dep to the webkit ppa, and give back webkit?
[11:04] <seb128> doko, can do
[11:05] <doko> directhex, should have been didrocks
[11:05] <seb128> didrocks, doko: I will look at those desktop ftfbses, didrocks is already under heavy pinging and todo ;-)
[11:05] <didrocks> doko: right, so you are quite lucky to not be under this load
[11:06] <doko> seb128, and any desktopish ftbfs ;)
[11:06] <seb128> doko, will do
[11:06] <davmor2> Hey guys I see a launcher for amazon after todays updates however if I click on it, it opens FF and then removes the launcher
[11:07] <doko> pitti: ubuntu-defaults-builder ftbfs
[11:08] <Laney> doko: the make patch is not needed?
[11:08] <seb128> Laney, I guess it is, binutils should fix the ar issue, not the argument list one
[11:09] <Laney> that's what I think
[11:09] <pitti> doko: yes, will do
[11:10] <doko> Laney, I didn't see it in the ppa
[11:12] <Laney> doko: https://launchpad.net/~ubuntu-desktop/+archive/ppa/+packages
[11:13] <Laney> doko: and do you mean ubuntu-toolchain-r/test, staging or ppa?
[11:14] <doko> Laney, ppa
[11:15] <Laney> I'll try without make first
[11:17] <Laney> doko: https://launchpad.net/~laney/+archive/webkit/+build/3853350
[11:20] <doko> looks like we were not good with merging this cycle ...
[11:20] <cjwatson> doko: I'm looking at klibc
[11:34] <pitti> doko: u-defaults-builder test failure points out a config file format change in unity, so that's great to catch \o/
[11:39] <doko> Laney, pitti: libproxy looks like your pet
[11:39] <doko> ftbfs ...
[11:39]  * pitti bounces to Laney
[11:40] <Laney> ta
[11:40] <Laney> probably just a missing include
[11:42] <pitti> doko: defaults-builder FTBFS fix uploaded to unapproved
[11:46] <pitti> I cannot reproduce the pkgbinarymangler FTBFS here, all tests work; trying in my PPA; looks like pkgbinarymangler is installed in the rebuild test environment, but in some special way
[11:48] <doko> it shouldn't be anything special, nothing preseeded
[11:49] <pitti> oh hang on
[11:49] <pitti> ok, lunch, then fix :)
[11:55]  * doko is staring at the ppp ftbfs
[11:59] <Laney> libproxy uploaded
[12:16] <alexbligh1> Does this quantal->precise backport request have a snowball's chance in hell of succeeding? (allows Precise to mount Windows 2012 server exported SMB drives). Not trying to persuade anyone, just get an idea of the height of the hurdle for backport requests.
[12:16] <alexbligh1> https://bugs.launchpad.net/precise-backports/+bug/1056137
[12:28] <tumbleweed> alexbligh1: it sounds like a big enough issue that it should be dealt with by an SRU rather than a backport (backports don't exist to fix bugs)
[12:29] <tumbleweed> but I have no idea how big the patches to bring win 2012 support to the version in precise would be
[12:29] <tumbleweed> in general, for a backport to have a snowball's chance in hell of succeeding: you should do all the testing requestbackport asks for
[12:38] <alexbligh1> tumbleweed, the issue (both with an SRU and the testing) is that updating the samba source package means the SMB /server/ gets updated too. I have no idea how to test that fully as I haven't got any Windows clients, printers, blah blah blah. I've not much idea what has changed server side. All I really want to update is the client, so Precise can mount Windows 2012 servers. Windows 2012 clients will (I believe) mount older servers an
[12:38] <alexbligh1> ywhere.
[12:38] <alexbligh1> s/anywhere/anyway/
[12:39] <alexbligh1> I'd be nervous about changing the default *server* (by upgrading samba). If it were possible to break out just the library from Samba, that would I think be far safer.
[12:40] <tumbleweed> alexbligh1: we apply minimal patches in SRUs - so it would only be SRUable if there was something fairly minimal that could be applied
[12:40] <tumbleweed> anyway, chat to the #ubuntu-server people
[12:45] <tkamppeter> doko, I am looking currently into that. The starnge thing which happemns here is that formaerly HPLIP built perfectly and suddenly, all "->" raises the error "dereferencing pointer to incomplete type".
[12:46] <tkamppeter> doko, do you have any idea what that means? The CUPS API did not change with respect to these data structures, and HPLIP built some weeks ago.
[12:47] <doko> tkamppeter, I assume some reorganization did change. glib, gtk?
[12:47] <doko> header reorg, I mean
[12:48] <alexbligh1> tumbleweed, thanks
[12:48] <tkamppeter> doko, the data structures are defined in CUPS but they did not change, they still match. Strange is also that EVERY "->" raises the error.
[12:49] <tkamppeter> cupsext
[12:49] <cjwatson> tkamppeter: That indicates that at the point when the compiler encounters the thing before the ->, it doesn't have a full definition of its type
[12:49] <cjwatson> i.e. usually missing header or similar
[12:53] <tkamppeter> cjwatson, earlier in the code there is a line "ipp_t *request = NULL;", which clearly assigns the correct type to the variable "request", and assuming that the header would be missing, the compiler should already complain at "ipp_t" which it does not do.
[12:59] <doko> tkamppeter, but at this point, it doesn't need to know the struct
[13:31] <dholbach> I'm doing an ubuntu development hangout in ~30m - would anyone like to co-host it with me? :)
[13:33] <cjwatson> tkamppeter: not true
[13:34] <cjwatson> tkamppeter: the compiler has enough information for "ipp_t *request = NULL;", because the size of a pointer is the same no matter what it points to.
[13:34] <cjwatson> tkamppeter: that doesn't mean it has enough information to dereference the point
[13:34] <cjwatson> *pointer
[13:36] <stgraber> dpm: a broken html file was preventing the generation of updated pot templates...
[13:36] <stgraber> dpm: I'll do a manual import of the new .pot in launchpad for now and will do a full translation update before release.
[13:37] <dpm> stgraber, excellent. Could you just ping me when you've done the manual import, so that I can give a heads up to translators?
[13:39] <tkamppeter> cjwatson, thank you very much. I have found the cause of the problem now, in the CUPS *.h files new conditionals to hide the private data structure from non-CUPS builds were added. Now I succeeded to rebuild the package by overriding the conditionals via "-D..." in CFLAGS.
[13:40] <stgraber> dpm: done
[13:40] <stgraber> dpm: LP correctly reports the "Welcome to Ubuntu 12.10" string as needs translation now
[13:41] <cjwatson> tkamppeter: Right.  Though be careful as that kind of thing often indicates that the relevant structures are now considered private and won't be ABI-stable
[13:41] <sconklin_> @pilot in
[13:42] <cjwatson> Sometimes it goes along with better alternative ways to do the same things (e.g. accessor functions)
[13:42] <cjwatson> Not that I know anything about CUPS, this is just standard practice for libraries
[13:44] <diwic> doko, I believe I have fixed the quantal ftbfs for libffado (by cherrypicking a patch from upstream), where do I put it so that someone finds and uploads it?
[13:44] <dpm> stgraber, excellent, thanks!
[13:44] <doko> diwic, please open a bug report
[13:45] <doko> or just put the diff.gz and .dsc somewhere where I can fetch it
[13:45] <diwic> doko, ok, will ping you once I have a debdiff ready
[13:46] <doko> can't explain the noweb build failure on armhf, giving it back
[13:51] <tkamppeter> cjwatson, I have reported the problem upstream to the HPLIP guys now: bug 1056214. Feel free to comment.
[13:54] <Laney> Subject: [Build #3853350] amd64 build of webkit 1.9.91-0ubuntu1~build1 in ubuntu quantal RELEASE (laney-webkit PPA) :(
[13:54] <tkamppeter> doko, cjwatson, fixed HPLIP uploaded.
[13:55] <Laney> ok, so I'll take the new make-dfsg now
[13:56] <ev> mpt: http://poppy-dev.local/ - is that dot pattern what you're after, or should we go a blank background or something else?
[13:57] <doko> Laney, is the new webkit a requirement for q?
[13:57] <Laney> we can't really stay on a dev release
[13:58] <Laney> https://bugs.webkit.org/show_bug.cgi?id=94435 if that gets fixed we'll be ok
[14:01] <diwic> doko, ok, bug 1056193, debdiff in comment 4, diff.gz/.dsc in 5 and 6
[14:05] <cjwatson> mvo: Do you know whether there's a sensible way in python-apt to reset the entirety of apt_pkg.config to what you'd get from apt_pkg.init_config()?
[14:05] <cjwatson> I'm trying to make sure tests I'm writing are correctly isolated, and would like to avoid having to use a subprocess if possible.
[14:06] <cjwatson> Taking a copy of the whole apt_pkg.config object doesn't work, presumably because the actual configuration lives in libapt_pkg itself; apt_pkg.init_config() uses CndSet under the covers so ignores anything already set; and there's no obvious "clear everything" method
[14:06] <cjwatson> I feel I must be missing something
[14:06] <mvo> cjwatson: there is none right now, but that should be (re)added really, I'm in a meeting right now, but I'm happy to talk about it in a bit
[14:07] <cjwatson> OK.  These are Launchpad tests so they have to run on lucid (at least at the moment), so I'll have to come up with a workaround that doesn't involve changing {python-,}apt.  Thanks.
[14:10] <cjwatson> Maybe apt_pkg.config.clear("APT"); apt_pkg.config.clear("Dir"); apt_pkg.init_config() would be sufficient in practice
[14:11] <cjwatson> A nice interface might involve making apt_pkg.config.clear() work ...
[14:12] <mvo> cjwatson: yeah, I think that is the key, adding libapt clear() and exposing that to python-apt
[14:15] <mvo> cjwatson: let me try to build something for you, will be a bit slow due to the call but
[14:17] <mpt> ev, pretty good. :-) The values on the axis need tick marks, and the dots should subdivide them sensibly. 7 days for X is good, but 0.00333 for Y is a bit weird.
[14:18] <mvo> cjwatson: does http://paste.ubuntu.com/1226696/ look reasonable?
[14:18] <ev> mpt: yes - I'm working on lining them up, but I wanted to make sure the dot pattern worked as an idea first
[14:19] <mpt> ok
[14:19] <ev> might work backwards and figure out what the tick interval should be to get the same spacing between the dots on the x and y axis
[14:25] <seb128> ev, did you figure out why the nautilus issue is not showing up on e.u.c?
[14:25] <ev> still working onit
[14:25] <ev> on it
[14:26] <seb128> ok
[14:29] <cjwatson> mvo: oh, yeah, duh, that would work wouldn't it
[14:29] <cjwatson> Slightly inclined to take a copy of .keys() first to defend against problems with modifying something while iterating over it
[14:30] <mvo> cjwatson: yeah, good idea, it seems to be ok, but +1 for safety
[14:31]  * cjwatson sticks that in tearDown() then, thanks a lot
[14:32] <doko> Sweetsha1k, seb128: libreoffice b-d's on libvigraimpex-dev, however there is no libreoffice binary depending on the library. what's the reason for this b-d? it's the last user of vigra in main, would like to demote it
[14:42] <Sweetsha1k> doko: vigra is mostly a header-only lib, so we are using the headers only (like most of e.g. boost)
[14:43] <Sweetsha1k> doko: thus build time only, nothing needed at runtime.
[14:43] <doko> Sweetsha1k, which cannot be avoided?
[14:45] <Sweetsha1k> doko: As you say its the only user left in main, I can use the interal LibreOffice copy of vigra -- shouldnt be much of an change. Its likely different for debian because they have no main/universe split and thus have more users for vigra anyway.
[14:46] <bdmurray> ev: could you look comment on bug 1039220 again?  I think we should not send bugs with an unreportable reason to the crash database at this point in time.
[14:47] <ev> bdmurray: yeah, pitti asked me this morning
[14:47] <ev> it's on the list :)
[14:47] <bdmurray> ev: ah, okay then!
[14:55] <mitya57> didrocks/Mirv: will there be one more libunity upload before the release?
[14:59] <Mirv> mitya57: yes, and the changes should be gotten in this week
[15:00] <mitya57> Mirv: ah thanks. So I want you to merge lp:~mitya57/ubuntu/quantal/libunity/lp1055019 now :)
[15:00] <needhelp1> Hello
[15:01] <needhelp1> I wanted to share the link to the Ubuntu Beta Users Survey, http://nathanheafner.com/home/2012/09/11/ubuntu-beta-users-survey/   . This survey ends tomorrow.
[15:03] <sladen> needhelp1: were you the person I helped before?
[15:03] <needhelp1> sladen: im not sure
[15:03] <sladen> needhelp1: on 12 September 2012 I spent a large amount of time discussing with you
[15:04] <needhelp1> nice to talk again
[15:05] <needhelp1> sladen: you been doing ok?
[15:05] <sladen> needhelp1: about how to improve the chance of getting survey data;  by eg. making questions such 'sex' optional, and moving them to the end;  and working with  OMG!Ubuntu, rather than trying to find users on a developer channel
[15:06] <needhelp1> sladen: yeah, thanks. I have had a lot of success with the survey.
[15:06] <sladen> needhelp1: IIRC, you were going to make the questions optional, and get in touch with OMG!Ubuntu by email
[15:06] <sladen> needhelp1: did you actually do either of these things?
[15:07] <Mirv> mitya57: please do a merge request so it shows here https://code.launchpad.net/~unity-team/libunity/trunk/+activereviews :) then we should hunt for someone to review it
[15:07] <Mirv> merge proposal, that is
[15:07] <needhelp1> yeah, i was asked by some ubuntu groups to leave the sex question as required
[15:08] <needhelp1> the stats for the sex question are in line with other ubuntu surveys , and a large effort was made to ensure equal access
[15:09] <mitya57> Mirv: that affects only packaging, so I've proposed a merge to lp:ubuntu/libunity
[15:09] <mitya57> https://code.launchpad.net/~mitya57/ubuntu/quantal/libunity/lp1055019/+merge/125881
[15:10] <mitya57> (I thought the right branch should be lp:~ubuntu-desktop/libunity/ubuntu, but that one seems quite outdated...)
[15:10] <Mirv> mitya57: ah, right, I didn't check it since I'm in a free software evening event atm. that's indeed the correct place.
[15:12] <sladen> needhelp1: who?
[15:27] <bdmurray> doko: could you look at bug 938869 again?  there are some new duplicates of it coming in in bug 1045726.
[15:29] <doko> bdmurray, the last time I tried, I couldn't reproduce it here. I'm sure I left a comment in a duplicate issue, or closed another one
[15:30] <bdmurray> doko: is there some additional information we need?
[15:31] <doko> bdmurray, ahh, see my comment in #12
[15:36] <user82> hi. can i report a bug via launchpad webinterface?
[15:36] <user82> or does this question go to #ubuntu-bugs?
[15:37] <ogra_> you shouldnt, but you can indeed
[15:37] <ogra_> better use the ubuntu-bug tool
[15:38] <user82> okay thanks. it is totally simple i am 100% sure no detailed report is needed
[15:57] <xnox> @pilot in
[16:06] <doko> getting nearer to the ocaml ftbfs
[16:10] <Laney> tkamppeter: your hplip diff is a bit crazy, what happened there?
[16:11] <Laney> https://launchpadlibrarian.net/117287697/hplip_3.12.6-3ubuntu1_3.12.6-3ubuntu2.diff.gz
[16:41] <bryceh> could someone accept the two nvidia-* packages in NEW?  https://launchpad.net/ubuntu/precise/+queue
[16:46] <infinity> bryceh: I'll look at them laterish.
[16:47] <bryceh> infinity, thanks
[16:50] <ev> pitti, bdmurray: replied to the merge proposal
[16:50] <ev> sorry that took so long
[16:50] <ev> was caught up in tasks I started before I went on holiday and wanted to finish them before they completely left my brain
[16:53] <Laney> tkamppeter: I'll reject it. There's an autogenerated debian-changes patch that you almost certainly don't want.
[16:58] <doko> bryceh, didrocks: is libtxc-dxtn-s2tc-bin needed in main too? if yes, please seed it
[17:01] <ev> seb128: still investigating, but it will have to go into tomorrow as I'm nearly done for the day. Just wanted to let you know that I haven't forgotten :)
[17:01] <seb128> ev, ok, thanks ;-)
[17:01] <seb128> ev, have a good evening!
[17:01] <ev> thanks! you too
[17:02] <xnox> @pilot out
[17:09] <bryceh> doko, I have a Recommends on it from mesa, do I also need to include it in seeds as well?
[17:09] <cjwatson> No
[17:09] <doko> hmm, still shows up in component mismatches
[17:10] <cjwatson> Assuming that the binary package with the Recommends is itself either directly seeded or included by way of transitive Depends/Recommends
[17:10] <bryceh> doko, the Recommends has been in for several days, so if you're still seeing it in component mismatches something is wrong
[17:10] <cjwatson> Which binary has the Recommends?
[17:10] <bryceh> libgl1-mesa-glx
[17:11] <cjwatson> No, that Recommends: libtxc-dxtn-s2tc0
[17:11] <cjwatson> At least in my apt cache
[17:11] <bryceh> doko, oh rats sorry I didn't actually read
[17:11] <bryceh> no, libtxc-dxtn-s2tc-bin is just some utilities, we don't care about that
[17:11] <doko> ok, demoting
[17:14] <ahasenack> SpamapS: hi, just a ping to say that I have updated my application at https://wiki.ubuntu.com/AndreasHasenack/LandscapeClientPerPackageUploadApplication, it probably has some things that weren't there when you endorsed it first
[17:15] <SpamapS> ahasenack: added some of your dark seedy past? ;)
[17:18] <doko> Daviey, I promoted the python-tornado binaries as well
[17:19] <ahasenack> SpamapS: ;)
[17:26] <doko> infinity, you did look at mksh in main this cycle, please could you have a look at the ftbfs?
[17:45] <infinity> doko: Yeahp, can do.
[17:52] <doko> hmm, ruby1.9.1 builds locally here. trying another buildd
[18:35] <Laney> doko: https://launchpadlibrarian.net/117310167/buildlog_ubuntu-quantal-amd64.webkit_1.9.91-0ubuntu1~build1_FAILEDTOBUILD.txt.gz
[18:36] <doko> bah ... will try again with a fresh chroot later
[18:38]  * doko curses gophers
[18:43] <doko> zul, Daviey: having a look at the nova and python-babel dependency
[18:43] <highvoltage> in the old days, people used to gopher curses.
[18:43] <doko> in the upstream ChangeLog I find: Adds Distutils.Extra support, removes Babel support, which is half-baked at best
[18:44] <doko> but: $ grep Babel nova.egg-info/*
[18:44] <doko> nova.egg-info/requires.txt:Babel>=0.9.6
[18:44] <doko> and dh_python2 adds this to the dependencies
[18:45] <doko> so to remove this, add Babel to debian/pydist-overrides
[18:45] <doko> are you ok with this change?
[18:45] <zul> doko:  which i did this morning
[18:45] <zul> in rc2 which is sitting in pending
[18:46] <doko> ahh, ok
[18:46] <tkamppeter> Laney, I don't knowm, I will try to do a clean rebuild.
[18:50] <tkamppeter> Laney, the problem is the build system, the original tarball seems to contain machine-generated build system files which get remade by "make clean", so I need to backup the build system to restore in the end of "make clean".
[18:51] <tkamppeter> popd
[19:03] <doko> the binutils fix did allow the ocaml build to succeed, and ruby given back on another buildd builds fine as well. time to finish for today ...
[19:09] <tkamppeter> Laney, still around
[19:09] <tkamppeter> Laney, still around?
[19:09] <Laney> tkamppeter: kind of, not to review/accept though
[19:10] <tkamppeter> Laney, I have some problem with HPLIP, I do not succeed to keep the build system files conserved.
[19:11] <tkamppeter> Laney, I save them in the "configure" rule, right after "dh_testdir" and restore them in the "clean" rule, AFTER dh_clean.
[19:11] <Laney> what do you mean save and restore?
[19:11] <Laney> are you using dh_autoreconf?
[19:13] <tkamppeter> Laney, the problem is that only running the "clean" rule (which runs the "configure" rule as dependency) the build system files get changed and so the change gets recorded as "debian/patches/debian-changes" in the source file.
[19:13] <kees> anyone around that knows efi booting? I'm trying to debug why my system won't... :P I can't figure out if I'm even loading the grub .efi file or not
[19:14] <tkamppeter> Laney, yes, I use "dh_autoreconf debian/autogen.sh" in the "configure" rule.
[19:14] <Laney> clean runs configure?
[19:14] <Laney> that sounds less than ideal
[19:15] <tkamppeter> Laney, I do not know why, the Debian maintainer must have added that. I will try to remove it.
[19:18] <Laney> tkamppeter: OK. Let's revisit it tomorrow if you want
[19:20] <infinity> pitti: This pkgbinarymangler diff looks curious.
[19:21] <tkamppeter> Laney, that's it, the "configure" dependency was wrong, I have removed it and now all works well. Thanks.
[19:28] <Laney> tkamppeter: ah, nice. I wonder why it was there. How curious.
[19:29] <tkamppeter> Laney, fixed package uploaded.
[19:31] <Laney> tkamppeter: if you want to close bugs, you need to upload with -v
[19:31] <tkamppeter> Laney, perhaps the debian/patches/debian-changes file was already there for longer time only that no one has taken note of it. Especially all these changes get overwritten on each package build, so that they do not break the software provided by the package.
[19:32] <Laney> alternatively, since they were never in the archive, you don't need to use a new version number
[19:34] <tkamppeter> Laney, now it is already uploaded, I will close the one bug report manually.
[19:34] <Laney> up to you. It's no problem to reupload multiple copies to the queue.
[19:35] <tkamppeter> Laney, does this mean that as the last upload is not yet approved I can do another upload with a lower version number?
[19:35] <doko> Laney, where was this fixed make version?
[19:36] <Laney> doko: https://launchpad.net/~laney/+archive/webkit/+packages
[19:40] <tkamppeter> Laney, now I have uploaded a new -3ubuntu2 with all the changes. So you can reject -3ubuntu4 and accept -3ubuntu2.
[19:41] <Laney> ack
[19:51] <doko> bdmurray, could you find out about the env vars which are set?
[19:51] <Laney>  7 files changed, 18 insertions(+), 11135 deletions(-)
[19:52] <Laney> tkamppeter: nice!
[19:53] <bdmurray> doko: what do you mean exactly?
[19:55] <doko> bdmurray, so what do you suggest to do? dear vmware, please fix your broken installer?
[19:57] <doko> bdmurray, I assume they ship a python2.x environment, and then calling everything else with this environment
[19:58] <bdmurray> doko: no, if its vmware's fault that's fine. I'd just like to be able to have that information in the bug and write a bug pattern for the crash if possible.  Also modifying apport so we know if python was modified seems like a good idea too.
[20:00] <doko> ok, so the bug pattern would be to look for something vmware'ish in PYTHONHOME and PYTHONPATH. I assume they only see this on Ubuntu, because other distros ship a lsb_release implemenation not written in python
[20:00] <bdmurray> and it doesn't look like apport gathers either of those
[20:04] <bkerensa> sconklin_: your PP today?
[20:04] <sconklin_> yes, what's up?
[20:04] <sconklin_> I'm only looking at kernel issues, fwiw
[20:12] <doko> bdmurray, even ProcMaps.txt doesn't show any references, because the error happens that early
[20:12] <smoser> pretty sure i just time traveled.
[20:12] <smoser> my clock now says 4 hours in the future
[20:13] <smoser> hm.. no, it just lost my timezone.
[20:13] <smoser> strange
[20:13] <Daviey> smoser: no, you fell asleep.. check for the key imprints on your face
[20:25] <bkerensa> sconklin_: oh nvm then :) just have a line of MP's waiting for review
[20:26] <sconklin_> bkerensa: as luck would have it, both PPs who were assigned today were kernel people
[20:27] <bkerensa> peh
[20:27] <bkerensa> :D
[20:28] <sconklin_> I'm almost EOD anyway
[20:53] <doko> Laney, so I was bad with testing. webkit ar failure still reproducible. maybe you could work around it by configureing with --disable-static?
[20:54] <Laney> maybe
[20:56] <cjwatson> kees: with GRUB 2.00, you can 'echo $grub_platform' to see which platform you're running (at least assuming GRUB has got out of rescue mode)
[20:59] <Sweetshark> doko: so, do you want that vigra drop still? If so, I would assume so for quantal+1, which is a bit of: could you drop a minibug on me for that then?
[20:59] <doko> Sweetshark, no, your are free to fix the ftbfs of libvigraimpex in q, as the only user of this package ;-P
[21:04] <Sweetshark> doko: hah!
[21:06] <Sweetshark> jasoncwarner_: ping?
[21:09] <doko> barry, ^^^ you did touch libvigraimpex before, maybe give it a try?
[21:11] <barry> doko: tbh, i've never actually used libvigraimpex
[21:12] <doko> ok
[21:15] <kees> cjwatson: after more debugging and running the efi shell from a usb stick, it seems like my ami firmware is refusing to notice my efisys partition, and I don't understand why.
[21:16] <kees> cjwatson: the HDD shows up under "devices" in the efi shell, but it doesn't see any partitions listed under "map", which only shows the usb stick.
[21:16] <kees> oddly, I created the partitions with the same tools: gdisk and mkfs.vfat
[21:30] <Laney> doko: --disable-static is the default
[21:30] <Laney> and we don't enable it
[21:40] <bryceh> infinity, chance you could peek at the nvidia NEW?  I'm hoping it should be an easy wave-thru for you since we got TB approval on it (http://ubuntu.5.n6.nabble.com/Minutes-from-the-Technical-Board-meeting-2012-09-17-td4992536.html)
[21:57] <infinity> bryceh: It's on my TODO today, don't worry.
[22:11] <TheLordOfTime> where can i report a possible issue with the retracer for a crash bug on a Quantal system?
[22:11] <TheLordOfTime> or am i asking in the wrong location
[22:16] <SpamapS> TheLordOfTime: here is probably a good place. Whats up?
[22:17] <TheLordOfTime> SpamapS, https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1056419  <-- should the retracer be expecting proposed repo packages to be used for testing?
[22:18] <SpamapS> TheLordOfTime: its entirely possible the retracer does not know how to deal with proposed.
[22:18] <TheLordOfTime> SpamapS, that might be something to look into, unless i'm misreading the retracer's whining
[22:19] <TheLordOfTime> libgtk2.0-0 version 2.24.13-0ubuntu1 required, but 2.24.13-0ubuntu2 is available  <-- that one caught my attention since -0ubuntu2 is only in proposed
[22:20] <TheLordOfTime> and unless you're an idiot, or a hardcore tester of everything, you don't run stuff from proposed very often.
[22:20] <TheLordOfTime> if at all.
[22:21]  * micahg would think it's more likely that the ddebs are removed before stuff in moved to the release pocket
[22:25] <cjwatson> find pitti when he's around and ask him; not sure anyone else really knows how the ddeb publisher works
[22:25] <cjwatson> but I could well imagine that it fails to handle the -proposed workflow somehow
[22:26] <TheLordOfTime> cjwatson, that was my thought
[22:26] <Laney> I've definitely had apport refuse to let me file a bug because of -proposed
[22:27] <TheLordOfTime> cjwatson, the main reason i saw that is it  was a quantal bug, and it was invalid'd pretty much when it got on the feed the announce bot in #ubuntu-bugs-announce posted it, and I dont usually see that.  'Tis why I was curious, then i saw that
[22:28] <TheLordOfTime> cjwatson, if the retracer's processing -proposed as if it is an approved, uploaded package to the standard repos, then the retracer needs an overhaul
[22:28] <TheLordOfTime> since that's a possibility of legitimate crash bugs being invalid'd because of -proposed
[22:28] <micahg> well, what we need is ddeb support in soyuz
[22:29] <cjwatson> we know the retracer needs an overhaul; in this case though it should be a relatively small fix
[22:31] <TheLordOfTime> cjwatson, then a targetted code stabbing session should work :P  but my original point stands: at least with $currentDevRelease it can result in legit crash bugs being marked invalid and thereby being completely ignored by devs, which can definitely lead to reported-but-not-fixed issues at release
[22:31] <Laney> Nobody is disagreeing with you
[22:31] <TheLordOfTime> :)
[22:31] <TheLordOfTime> Laney, indeed.  i'm just reiterating my point :)
[22:31] <TheLordOfTime> as a triager, i don't like broken stuff, esp. if the retracer is doing othe breaking :p
[22:32]  * TheLordOfTime returns to lurkmode