[00:21] <slangasek> dobey: that looks like it would DTRT
[00:38] <nik90> Is the right place to ask python related questions?
[00:38] <nik90> this*
[00:40] <nik90> nvr mind I will come later :)
[00:46] <smoser> slangasek, the issue with your suggested 'install' is that modprobe of mlx4_en triggers recursion
[00:47] <smoser> as it depends on mlx4_core
[00:49] <smoser> ok... so i tested, and your way does not seem to cause recursion . do you have a preference on which way that is done?
[00:53] <slangasek> smoser: I don't have a preference, I just don't know anything about the 'softdep' so don't know how "standard" it is
[00:55] <smoser> slangasek, well, it documented in natty modprobe.conf
[00:56] <slangasek> then I guess you're ok :)
[01:02] <infinity> smoser: Oh, if you plan to upload module-init-tools/kmod for this, mind if you toss the kmod patch to me to upload?  I'm trying to keep TIL on it, so I can watch for merges. :P
[01:02] <infinity> And it's getting irritating to find a bug to fix to steal it back every time someone else uploads it...
[01:05] <smoser> infinity, https://code.launchpad.net/~smoser/ubuntu/raring/kmod/lp-1115710
[01:05] <smoser> i think we're ready for "propose for merging" if you are ok to look
[01:32] <infinity> smoser: Shiny.  I'd love it if someone could do a by-hand test of that on real hardware to see if it actually DTRT, mind you.
[01:33] <smoser> me too.
[01:33] <smoser> i'll see what i can do about hat.
[01:33] <smoser> EntropyWorks, lifeless ^
[01:34] <infinity> smoser: Would be nice if they could test it with both module-init-tools in precise and kmod in raring.  I make no guarantees that kmod actually honors softdep correctly.
[01:34] <infinity> (Though it's meant to...)
[01:34] <smoser> either of you able to do that for me? basically we want to boot a system , disable whatever hacks you have inside it that are loading mlx4_en, and then add the /etc/modprobe.d/mlx4.conf file that you see http://bazaar.launchpad.net/~smoser/ubuntu/raring/kmod/lp-1115710/revision/11 and reboot.
[01:35] <smoser> infinity, i can verify that it honors it.
[01:35] <smoser> i've tested 'modprobe mlx4_core' with those in place
[01:35] <smoser> and seen the _en and _ib get loaded.
[01:35] <smoser> on raring.
[01:36] <smoser> but i cannot attest that they actually load and function if the hardware is present
[02:24] <lifeless> smoser: EntropyWorks: - will see what we can do
[02:27] <smoser> lifeless, thanks. update/comment at https://bugs.launchpad.net/maas/+bug/1115710
[04:30] <Niraj_>  Hi can anybody tell me, as a beginner to ubuntu dev, where can I find issues to fix?
[04:31] <scientes> how can i debug plymouth without changing my kernel cmdline?
[04:31] <scientes> i'd really like to be connected to it in gdb during bootup
[04:33] <scientes> oh looks like xorg problem nvm
[04:33] <scientes> but probably stilla bug i n plymouth
[04:43] <Ramsrambo> I am running Quantal 12.10 I need libcstdc++ lib for installing lotus Symphony where do I get this from?
[04:45] <scientes> Ramsrambo, probably libstdc++-dev
[04:45] <scientes> * libstdc++6-dev
[04:45] <scientes> but you may need another version
[04:45] <Ramsrambo> but the IBM installation manual says libcstdc++
[04:46] <scientes> wait libstdc++6-4.7-dev
[04:46] <scientes> thats the same thing
[04:46] <scientes> basically you just need to install build-essential
[04:46] <scientes> apt-get install build-essential
[04:47] <Ramsrambo> I hope so let me install that lib thru synaptic and see if I can install this lotus
[04:47] <Ramsrambo> just hang on I will give the feed back
[04:48] <Ramsrambo> essential not able to locate ?
[04:49] <scientes> build-essential
[04:50] <Ramsrambo> that was installed already
[04:50] <scientes> may need old libstdc++5 then
[04:50] <Ramsrambo> so go to synaptic and install this ?
[04:51] <scientes> you need the -dev version
[04:51] <scientes> probably
[04:51] <scientes> but yeah install that
[04:51] <Ramsrambo> I hv synaptic installed already
[04:51] <scientes> apt-get install libstdc++5
[04:54] <Ramsrambo> I installled the old libstdc++
[04:55] <Ramsrambo> when I click on the .deb file it goes to software centre
[04:55] <scientes> Ramsrambo, this doesn't belong in #ubuntu-devel
[04:55] <Ramsrambo> and gives a error that dependency is not satisfiable libnotify
[04:55] <scientes> yeah its using the old libnotify1
[04:55] <scientes> (like firefox did a few months ago)
[04:56] <Ramsrambo> that is right libnotify1
[04:56] <Ramsrambo> >=0.4.4
[04:57] <scientes> packages.debian.org/libnotify1
[04:57] <scientes> * packages.ubuntu.com/libnotify1
[04:58] <Ramsrambo> so I cannot install then
[04:58] <scientes> you can
[04:58] <scientes> you just have to pull from old version of ubuntu
[04:59] <Ramsrambo> maybe on the old lib will do ??
[05:01] <Ramsrambo> How do I do that ?
[05:01] <scientes> i just told you packages.ubuntu.com/libnotify
[05:01] <scientes> i just told you packages.ubuntu.com/libnotify1
[05:05] <Ramsrambo> yeah! after installing libnotify1 it started installing
[05:11] <Ramsrambo> I cannot see any progress at all in software centre ! not sure what is going on
[05:15] <kees> hallyn: so... CAP_TO_MASK only seems valid for __u32 caps...
[05:17] <kees> hallyn: and is 7b9a7ec565505699f503b4fcf61500dceb36e744 valid then?
[06:25] <cyphermox> @pilot out
[06:27] <didrocks> @pilot in
[06:37] <kees> hallyn: unping; I see now how CAP_TO_INDEX works with CAP_TO_MASK :)
[06:39] <pitti> Good morning
[07:26] <didrocks> pitti: do you mind marking as merged the 3 following branches:
[07:26] <didrocks> https://code.launchpad.net/~dobey/ubuntu/quantal/tomboy/no-more-u1/+merge/146674
[07:27] <didrocks> hhttps://code.launchpad.net/~dobey/ubuntu/precise/tomboy/no-more-u1/+merge/146675
[07:27] <didrocks> https://code.launchpad.net/~dobey/ubuntu/oneiric/tomboy/no-more-u1/+merge/146676
[07:27] <pitti> didrocks: done
[07:28] <didrocks> pitti: thanks :)
[07:53] <dholbach> good morning
[07:56] <didrocks> hey dholbach
[07:57] <dholbach> hey didrocks
[07:59] <Whoopie> cyphermox: Hi, just saw the network-manager upload and the enabling of connectivity check. You need libsoup build dependency so that it's correctly enabled.
[08:00] <Whoopie> cyphermox: oh sorry, it's already there.
[08:04] <dholbach> @pilot in
[08:23] <didrocks> @pilot out
[08:25]  * dholbach hugs didrocks
[08:25]  * didrocks hugs dholbach back
[08:26] <vibhav> Hey, is somebody aquinted with autopkgtests?
[08:26] <didrocks> dholbach: short day (2h30 of sponsoring), but look at the ML, tomorrow is Qt5 sponsoring for me
[08:26] <vibhav> I wanted to know whether one must test all packages for a test case
[08:27] <vibhav> I was creating test cases for libestr
[08:27] <vibhav> (http://developer.ubuntu.com/packaging/html/auto-pkg-test.html)
[08:28] <dholbach> vibhav, you might want to ask in #ubuntu-quality - but if the test case works for you as described in the packaging guide, things should be all right
[08:28] <vibhav> dholbach: Actually, I dont have time to test all functions. Would it be fine to test some functions only? (Of course they can be extended later)
[08:29] <dholbach> some tests are better than no tests
[08:29] <vibhav> Indeed.
[08:30] <vibhav> Anyways, Ill try to do my best
[08:30] <dholbach> great!
[08:30] <dholbach> pitti, jibel: ^ :)
[08:33] <pitti> vibhav: indeed, and the first test usually covers a lot more implicit stuff (loading library, etc.) than it might seem
[08:35] <vibhav> pitti: thanks
[08:40] <jibel> vibhav, it's perfectly fine to start with a small set of tests and increase the coverage afterwards when you have time
[08:51] <caribou> Q: what is required to get a newly available Debian/Sid package synchronized in the Raring archive ?
[08:52] <vibhav> jibel: So basically, I only have to check if function work correctly (return 1 or 0, etc), right?
[08:52] <pitti> caribou: which package?
[08:52] <caribou> pitti: makedumpfile & kdump-tools
[08:52] <caribou> pitti: they're not available yet, they were just uploaded last night
[08:53] <caribou> pitti: but since the freeze is getting near, I'm inquiring ahead just to know
[08:53] <pitti> caribou: they are both unmodified, so we can just sync them
[08:54] <tjaalton> doko_: ping re: llvm-snapshot
[08:54] <pitti> caribou: once you see the new version on https://launchpad.net/debian/+source/makedumpfile/+changelog , feel free to prod me
[08:54] <caribou> pitti: true, matter of fact, the Debian modification that I made is specific to a requirement I have for an Ubuntu blueprint
[08:55] <caribou> pitti: ok, will do. This is regarding the email I sent to ev (you were CC) yesterday
[09:06] <jibel> vibhav, very basically yes :) actually your test script will verify that the systems functions as expected, as for example checking the returncode of a function for different set of conditions
[09:22] <dholbach> blueyed, Happy Birthday! :)
[09:23] <caribou> pitti: a while back I asked about getting a package in main when its source is already in main
[09:23] <caribou> pitti: you guys told me that it was only a matter of having a dependancy on this package from another package in Main
[09:23] <caribou> pitti: does it applies to meta-packages as well ?
[09:25] <pitti> caribou: in general as well, yes
[09:25] <caribou> pitti: ok. kdump-tools will have a dependency from the linux-crashdump tool meta-package soon. we'll see
[09:26] <caribou> pitti: thanks
[09:31] <smb> pitti, Would it be enough to have only the source in main but not the binary (to be ok depending on the binary from meta)?
[09:32] <cjwatson> caribou: makedumpfile and kdump-tools will be auto-synced without any human intervention
[09:32] <caribou> cjwatson: thanks, good to know
[09:32] <pitti> cjwatson: oh, we are still before DIF?
[09:32] <caribou> cjwatson: just wanted to be sure as the freeze date is approaching
[09:33] <cjwatson> the freeze is still eight days away
[09:33] <pitti> smb: MIRs are source based, so promoting a binary is not a big process indeed
[09:33] <cjwatson> and the auto-sync runs four times a day
[09:34] <caribou> cjwatson: ok, I'll keep an eye on it
[09:49] <dholbach> @pilot out
[09:53] <dholbach> down to 29! (once http://reqorts.qa.ubuntu.com/reports/sponsoring/ updates)
[09:53] <dholbach> yeehaw
[09:55] <seb128> dholbach, \o/
[09:55] <ion> down to 8841761993739701954543616000000 :-)
[09:55] <dholbach> ion, what are you counting? :)
[09:55] <ion> 29!
[09:59]  * pitti hugs dholbach
[09:59]  * dholbach hugs pitti back :)
[09:59] <dholbach> ion, ok, I'm still a bit slow it seems ;-)
[10:00] <ion> dholbach: That was just a stupid joke, ! is the factorial operator.
[10:00] <dholbach> yeah, it took me 4 minutes to figure it out :)
[10:00]  * dholbach hugs ion
[10:00]  * ion hugs dholbach
[10:41] <ev> cjwatson: thanks for recommending sbuild. I'm finding it a lot better than pbuilder.
[10:44] <xnox> \o/
[10:49] <cjwatson> ev: Great, glad you got over the initial hump
[10:52] <vibhav> jibel: ping
[10:53] <caribou> xnox: just saw your upload; I'll test it after lunch
[10:54] <xnox> caribou: lvm2? it's not published yet.
[10:54] <cjwatson> And won't be until after 12.04.2, unless there's a pressing urgency.
[10:55] <caribou> xnox: true; I'll wait 'til the "please test" msg comes in
[10:55] <xnox> caribou: ;-)))))
[10:56] <vibhav> pitti: what does `pkg-config --cflags --libs glib-2.0` in the gcc flags mean? Is it important for me to include those flags? (Of course, I will need to replace glib-2.0 with something else)
[10:57] <vibhav> pitti: wrt http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
[10:57] <cjwatson> It's important to include those flags if you're building something that uses glib headers
[11:00] <vibhav> cjwatson: I am writing autopkgtest cases for libestr. Do I need to replace glib-2.0 with libestr?"
[11:01] <cjwatson> You probably need some kind of build flags for libestr.  I have no idea whether they'll involve pkg-config
[11:01] <cjwatson> Check the library's documentation
[11:02] <vibhav> ah, so it varies with libraries. Thanks cjwatson
[11:15] <jibel> vibhav, libestr supports pkg-config, you can replace glib-2.0 by libestr on the line above
[11:16] <jibel> vibhav, pkg-config --list-all will tell you which modules are found in the path
[11:19] <vibhav> jibel: Hmm, will -lestr too work?
[11:20] <vibhav> jibel: I already uploaded a debdiff at https://bugs.launchpad.net/ubuntu/+source/libestr/+bug/1117222
[11:27] <cjwatson> vibhav: with programs that ship pkg-config configuration, you always *can* compile/link without it but it's more correct to use pkg-config
[11:27] <cjwatson> vibhav: it insulates you against changes
[11:28] <vibhav> cjwatson: changes as in?
[11:28] <cjwatson> to the way the library requires you to compile or link
[11:29] <cjwatson> for example 'pkg-config --cflags gtk+-3.0' has a bunch of useful -I options that you really wouldn't want to write out by hand
[11:31] <vibhav> ah, so it makes work easier
[11:31] <vibhav> I will upload the correct debdiff then
[11:32] <vibhav> thanks cjwatson
[11:38] <jibel> vibhav, the test exit 1 but there is no output at all and don't know which function call failed.
[11:39] <jibel> vibhav, you'd rather use one method/function per test, read http://xunitpatterns.com/Obscure%20Test.html#Eager%20Test for example
[11:40] <tjaalton> are the builders having some issues, or why do they reject uploads with timestamps "too far in the future"?
[11:41] <vibhav> jibel: So, shall I print "Failed"?
[11:43] <cjwatson> tjaalton: Are the timestamps in the future?
[11:44] <tjaalton> cjwatson: yes, some files of the packages, like lintian overrides and copyright
[11:45] <tjaalton> hmm
[11:45] <cjwatson> You'll probably find dpkg-source -x does that by default.
[11:45] <cjwatson> I mean, errors.
[11:46] <tjaalton> I'm building off a git branch, and for some reason some files under debian/ were touched
[11:47] <cjwatson> Since you have to pass a special option to get tar not to issue a warning.
[11:47] <vibhav> jibel: Also, would should I print in case of an error?
[11:48] <cjwatson> tjaalton: I would suggest just fixing the timestamps :)
[11:48] <tjaalton> cjwatson: well they are ok here, on my timezone
[11:51] <cjwatson> You could ask #webops (internal) to check that the builder's time is OK, I suppose
[11:55] <Quintasan> \o
[11:58] <Quintasan> Laney: \o/ thanks for uploading maliit to Debian.
[12:25] <jibel> vibhav, in case of error, you could print which function you're testing, the expected result and the actual result
[12:28] <jibel> vibhav, keep in mind that human are reading log files, so the message in case of failure must be as clear as possible
[13:08] <jibel> vibhav, I added a comment to the report
[13:17] <ogra_> ogra@anubis:~$ pkexec gedit /etc/fstab
[13:17] <ogra_> ** (gedit:8717): WARNING **: Befehlszeile »dbus-launch --autolaunch=806ff5b359b95482f2158d5e000009df --binary-syntax --close-stderr« brach mit von Null verschiedenem Beenden-Status 1 ab: Autolaunch error: X11 initialization failed.\n
[13:17] <ogra_> Anzeige kann nicht geöffnet werden:
[13:18] <ogra_> pitti, any idea why that happens ? ^^^^
[13:18] <ogra_> pitti, i',m executing it from a gnome-terminal, i would assume i have access to the display (adding DISPLAY=:0 doesnt change a thing btw)
[13:18] <pitti> ogra_: yes, pkexec doesn't pass through $DISPLAY by default
[13:19] <ogra_> pitti, hmm, so how would i use it as gksu replacement as an enduser ?
[13:19] <pitti> ogra_: you'd need to define a policy for gedit with the allow-gui attribute, like in /usr/share/polkit-1/actions/com.ubuntu.apport.policy
[13:20] <ogra_> pitti, eeek, so that means we cant drop gksu ?
[13:20] <pitti> ogra_: pkexec is not meant to be a general gksu replacement
[13:20] <ogra_> sigh
[13:20] <pitti> ogra_: but on the command line you can use sudo?
[13:20] <ogra_> sure
[13:20] <ogra_> but thats npot what users do or what our docs recommend ...
[13:21] <ogra_> i would like to remove gksu from the images in raring
[13:21] <pitti> I discussed that with David a while ago, and he wasn't fond of making pkexec a general user tool
[13:21] <pitti> we could write some wrapper, of course, which passes through $DISPLAY
[13:21] <ogra_> bah, but that forces us to ship two tools for similar purpose
[13:22] <nik90> anybody here familiar with GTK  Treeview? I am trying to get the row index to the currently selected row (all in python)
[13:22] <ogra_> a wrapper thats called gksu ;)
[13:22] <ogra_> nik90, did you read the topic ... i guess a gtk channel would be better
[13:22] <pitti> pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit
[13:22] <pitti> ogra_: ^ that works, for example; but ugh :)
[13:23] <nik90> oh thnx
[13:23] <pitti> ogra_: well, it's still not "su"; users shold just call sudo from the CLI reall
[13:23] <pitti> y
[13:23] <pitti> ogra_: and from .desktop files we could use such a pkexecx wrapper?
[13:23] <ogra_> pitti, generally thats not what supporters seem to recommend (or wikis and other docs)
[13:24] <pitti> ogra_: well *shrug*, those need to be changed anyway, no?
[13:24] <pitti> from gksu to pkexec or pkexecx or sudo
[13:24] <ogra_> hmm, probably
[14:10] <smartboyhw> dholbach, ping
[14:17] <mpt> ev, http://store.steampowered.com/hwsurvey
[14:17] <mpt> Expand the "OS version" row under "Windows and Mac"
[14:19] <ev> excellent, thanks!
[14:19] <ogra_> pfft, that wants to install flash on my nexus7
[14:20] <ogra_> (if it only would !)
[14:21] <ev> slangasek: a while back you had a better idea for measuring the health of the retracers than the current graphs of the average processing time and the success/failure rate
[14:21] <ev> I don't suppose you remember what it was? :)
[14:21] <ev> I can dig through all my notes if you can't
[14:21] <smartboyhw> dholbach, help me to test https://code.launchpad.net/~smartboyhw/ubuntu/raring/calligra/2.6.0-0ubuntu1/+merge/146644 again, new things uploaded
[14:22] <ev> mpt, bdmurray, pitti, slangasek: https://bugs.launchpad.net/errors/+bug/1117372
[14:22] <ev> just in case you have interesting ideas
[14:22] <hallyn> kees: ok, so to be sure, all is good? :)
[14:25] <ion> (Re: the Steam stats) Over 1 percent total? That’s actually more than i expected. That’s, like, half a million users.
[14:25] <ion> I wonder if it counts those who run it under Wine?
[14:26] <smartboyhw> dholbach, DON'T. I've got a patch error now
[14:35] <dholbach> smartboyhw, maybe you best point out in the merge proposal when it builds for you, etc
[14:35] <dholbach> smartboyhw, then others can jump in any help too
[14:36] <smartboyhw> dholbach, ok
[14:36] <mlankhorst> for MRE sru's, do I still need a bug?
[14:38] <Laney> yes
[14:43] <mlankhorst> ah thought so, I originally cherry picked some fixes so my game would be stable in nouveau, now I can't get it to crash >:(
[14:45] <Laney> MREs are only valid for changes in the new upstream release btw
[14:45] <Laney> so your cherry-pick would be a normal SRU
[14:49] <vibhav> jibel: Ive correct the debdiff
[14:51] <vibhav> corrected*
[14:52] <mlankhorst> Laney: well in this case I was part of upstream :-)
[14:55] <jibel> vibhav, thanks, I'll review it in a bit.
[14:56]  * vibhav hugs jibel 
[15:00] <mlankhorst> Laney: hm what about things that have been sru'd already? like the patches to reduce size in mesa's renamed lts-quantal package
[15:00] <ev> mpt: Whenever you have a free moment, do you think formatting the function column this way makes it easier to read: http://poppy-dev.local/ ? See http://errors.ubuntu.com for comparison.
[15:00] <ev> I'm tempted to implement a custom ellipsize
[15:00] <Laney> mlankhorst: what about them? I assume they went through SRU verification ~normally
[15:00] <ev> that tries to take from the center of the call stack, rather than the right hand side
[15:00] <Laney> mlankhorst: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[15:02] <mlankhorst> yeah, I'll try piglit on it, but mesa is a pain point so the update wouldn't be falling under MRE I suppose :/
[15:03] <tjaalton> mesa has a provisional mre
[15:03] <Laney> MRE is for micro releases
[15:03] <Laney> it's still valid to follow the normal SRU process for non-micro-release changes
[15:03] <tjaalton> well mlankhorst is testing 9.0.2 for quantal
[15:04] <mlankhorst> It'll have to be a hybrid then. MRE for the version bump, normal SRU for the patches cherry picked from mesa-lts-quantal in precise.
[15:04] <Laney> sounds right
[15:04] <Laney> you'll assume that upstream's fixes in the micro release are good and verify your cherry picks normally
[15:05] <vibhav> Hmm, are libraries like libxdo (Which simulate X11 keyboard/mouse input) work with autopkgtest?
[15:06] <vibhav> AFAIK, these tests will run on Launchpad Servers, which probably dont have GUIs
[15:08] <mlankhorst> I don't want to assume, but looking  seems there have been no big regressions in mesa for raring, which is mostly identical to the version I want to upload. Only difference is a revert to wayland 0.95.
[15:09] <Laney> assume means not having to manually verify each one - broad testing and running piglit is required as said on the page I linked you to
[15:09] <mlankhorst> yeah
[15:09] <mlankhorst> but it's on top of that :-)
[15:09] <Laney> and then explicitly verifying anyting extra, yeah
[15:22] <hrw> can someone help me with debconfing package? http://tygrysek.juszkiewicz.com.pl/~hrw/tmp/chromium-mali-opengles_0.45-0ubuntu1.dsc - builds fine but does not display license ;(
[15:30] <geser> hrw: did you forget to update the preinst or is the checking the msttcorefonts license intended?
[15:32] <hrw> ops
[15:33] <geser> you've updated the license variable but not the configuration space
[15:33] <hrw> ysp
[15:33] <hrw> rebuildng
[15:34] <hrw> yay! works now
[15:34] <hrw> previous version was based on nexus7 firmware and I had other bugs
[15:37] <bdmurray> mterry: might you have a look at bug 1110585?
[15:37] <hrw> so my first multiverse package works. but I wonder about pushing it into archive
[15:39] <sveinse> I've written a local-premount script for an embedded device running precise. In this script I mount some filesystems, do something and umount them afterwards. However the script is failing because umount reports Device or resource busy on the device I just mounted. Why could that be?
[15:41] <hallyn> I'm confused.  3.8.0-4.9~userns1 <= 3.8.0-0.4-userns1  ?
[15:42] <mterry> bdmurray, huh
[15:43] <sveinse> hallyn: http://www.debian.org/doc/manuals/maint-guide/first.en.html#namever
[15:44] <tjaalton> cjwatson: so, didn't think to check that my machine had jumped forward a month after a hibernate cycle.. it caused the archive upload fail
[15:45] <sveinse> hallyn: Your version statement is true. (Notice the tilde vs the dash)
[15:45] <zaytsev> hi folks. i noticed base-files bump to 12.04.2, but can't find images on cdimage. the latest is still 12.04.1. any etas?
[15:46] <infinity> hallyn: Having two dashes in the second version is reolcating what you believe is the "debian" and "upstream" versions.
[15:47] <infinity> hallyn: And 3.8.0 is definitely << 3.8.0-0.4
[15:48] <infinity> zaytsev: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-January/001009.html
[15:48] <hrw> hallyn: two dashes are killer with debian versioning ;(
[15:48] <hallyn> sveinse: i notice the tilde, but i would expect in 'dpkg --compare-version X~Y lt Y~Y' for the ~Y to be ignored
[15:48] <dobey> is it just me, or did the libc 2.17 update break squid3? (i can't think of anything else it might be)
[15:49] <infinity> dobey: I might need more to go on than that.
[15:49] <hallyn> infinity: i guess

[15:49] <hallyn> all right, thanks all :)
[15:49] <infinity> hallyn: The last dash is the one used for the Debian revision.
[15:49] <dobey> infinity: https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1111880
[15:50] <hallyn> i see, so it was my fault at the *last* submission.  drat.
[15:50] <zaytsev> infinity: thank you very much, this is what i was looking for, but failed to fine.
[15:50] <dobey> infinity: also, there seems to be a squid3 in quantal-security/updates that is newer than what's in raring. not sure why there isn't a -1ubuntu2 in raring with the fix in that -1ubuntu1.1 security update
[15:51] <zaytsev> s/fine/find/
[15:51] <hallyn> infinity: good news, the cleanup patches for spice are on their way into debian archive.  should be able to sync soon
[15:53] <dobey> infinity: but anyway, since the libc update, i've been seeing squid3 crashing while running tests in ubuntu-sso-client and ubuntuone-client (but we don't run those tests in the ubuntu builds, because they depend on the poorly maintained qt4reactor package which isn't in main)
[15:56] <jdstrand> dobey: I'll update squid3
[15:56] <infinity> dobey: Hey, I'm all for blaming glibc but, on the other hand, when only one package is exploding, I tend to blame that package. ;)
[15:56] <dobey> jdstrand: thanks
[15:58] <dobey> infinity: i'm not blaming glibc. but maybe it exposed a bug, which was working fine before the update
[15:58] <dobey> infinity: but the stack trace is a bit suspiscious, too, given how short it is :)
[15:58] <caribou> slangasek: ping
[15:59] <infinity> dobey: Really short stack traces when you manage to segv libc aren't uncommon. :)
[15:59] <infinity> dobey: (Usually due to doing something undefined, out of bounds, or just plain silly)
[16:00] <dobey> infinity: well, usually, crashes in strcmp are because someone passed in a NULL and the trace is several function calls deep. but maybe ncsa_auth is just a really small file too
[16:00] <dobey> but i would also expect passing NULL to strcmp to crash in the older glibc, as it's done many times before :)
[16:01] <infinity> You'd generally expect, yes.
[16:01] <infinity> Anyhow, if Jamie updates and it and it still explodes, I'll pass the buck to him.
[16:01] <dobey> heh
[16:12] <slangasek> caribou: in a meeting, but pong
[16:12] <caribou> slangasek: no rush, just disregard my last comment about install with secureboot/UEFI
[16:13] <caribou> slangasek: in the LP bug#1100247
[16:14] <caribou> slangasek: tl;dr : I used the +mac Quantal iso to install which doesn't have the ./efi bits
[16:14] <slangasek> caribou: hah, indeed it doesn't
[16:14] <caribou> slangasek: I'll update the bug & mark it invalid once I've completed the install
[16:15] <slangasek> caribou: oh, you mean /all/ this testing was with the mac image?
[16:15] <slangasek> or the original problem is just no longer reproducible?
[16:15] <caribou> slangasek: yep
[16:15] <slangasek> man
[16:15] <slangasek> I need to be more careful about asking people for image URLs :)
[16:15] <caribou> slangasek: all the testing with the mac, which is why it didn't see it on startup
[16:16] <slangasek> thanks for following up
[16:16] <slangasek> also, I need to kill the mac image with fire, but ENOTIME :/
[16:16] <caribou> slangasek: I _really_ wanted to nail this one down
[16:16] <caribou> slangasek: I don't even know why this image made it to my HDD to start with
[16:38] <hrw> how does repo for package is selected? I mean universe/multiverse - it is on server only or in package somehow?
[16:55] <xnox> hrw: as in, what adds univer/multiverse to apt config - or how does apt chooses which package version out of multiple available to install?
[16:55] <xnox> (your question is a bit ambigious to me)
[16:55] <hrw> xnox: no. I have package which is multiverse material - should I mark it somehow in debian/* or is it repo admin job?
[16:55] <ogra_> hrw, by the archive admins iirc ...
[16:57] <xnox> hrw: you will upload it into ubuntu and it will end up in the New queue. Archive Admins will accept and assign it to multiverse. Make sure your debian/copyright is correct.
[16:57] <hrw> xnox: thanks
[16:58] <hrw> ogra_: thx as well ;)
[16:58] <infinity> hrw: You can totally mark it multiverse in the source package.
[16:59] <ogra_> but that wont auto-move it there, will it ?
[16:59] <infinity> hrw: "Section: multiverse/whatever" instead of "Section: whatever"
[16:59] <hrw> thx
[16:59] <infinity> ogra_: No, but it'll land in the right place in the queue, so I don't have to override it.
[16:59] <xnox> infinity: ha =)))) *cheat*
[17:00] <ogra_> good to know
[17:00] <infinity> ogra_: Overrides and packages should match, they just often don't because we're importing from Debian and have different overrides.
[17:00] <infinity> ogra_: But in Debian, dinstall actually yells at you every time you upload something where debian/control doesn't match the overrides.
[17:00] <ogra_> ah
[17:01] <infinity> (The reason you tend to want them to match is so people making custom archives without overrides get the same Sources.gz/Packages.gz as the primary archive)
[17:01] <ogra_> i'll try to develop a habit for that in plain ubuntu packages then
[17:02] <infinity> hrw: If it's something you'd be eventually targetting for Debian, then "Section: non-free/whatever" also works fine, and our queues will s/non-free/multiverse/
[17:03] <hrw> infinity: due to non-mainline kernel it will probably not land in Debian but adapted
[17:05] <hrw> ok, so whole NEW queue is mine :D
[17:40] <vibhav> Does Launchpad allow root privilages on its build servers?
[17:40] <vibhav> Oops, wrong channel
[17:44] <sladen> vibhav: errm, for the sys-ops that run the buildds.  What are you trying to do?
[17:44] <marga> slangasek, you around?
[17:45] <marga> slangasek, I just sent an update to the dropbear bug.  Please let me know if you have any comments.
[17:45] <vibhav> sladen: autopkgtest case which uses Xvfb, which requires root
[17:47] <vibhav> sladen: Or, is there any way to run Xvfb without root?
[17:48] <slangasek> marga: around-ish, fighting kernel bugs; I'll have a look at the bug report in a bit, thanks
[17:48] <slangasek> vibhav: why would you think Xvfb requires root?
[17:50] <vibhav> slangasek: It does not seem to work with xdotool then
[17:51] <marga> slangasek, no rush, don't worry.  Turns out it was a cosmetic issue not a real one.
[17:52] <vibhav> slangasek: I am writing a autopkgtest for libxdo. Since launchpad build servers dont have X11, I need Xvfb. According to http://mojo.codehaus.org/selenium-maven-plugin/examples/headless-with-xvfb.html , Xvfb cannot functino correctly without root
[17:53] <slangasek> vibhav: yeah, that page is nonsense.  Have a look at any of the packages that build-depend on xvfb for example usage
[17:54] <vibhav> Wait, it works without root
[17:54] <vibhav> slangasek: Yes, that page is nonsense. Thanks!
[17:54]  * vibhav slaps forhead
[17:55] <sladen> vibhav: /usr/bin/Xvfb :42  works for me  ... but it seems you just discovered that
[17:55] <vibhav> sladen: Yes, I am a fool
[17:58] <xnox> vibhav: you are not a fool. you simply learned something new today ;-) which is good. all of us should be learning something new every day.
[17:58] <vibhav> xnox: :)
[17:58] <vibhav> xnox: Not only something new, something very important too :)
[18:09] <slangasek> marga: hey, followed up to the report; there is still a bug here
[18:10] <slangasek> marga: it's fine if you don't consider it high enough priority for an SRU, but plymouth is not always used in the initramfs so dropbear should not be relying on plymouth doing the file copy
[18:11] <doko> infinity, will you update the cross-toolchain-base packages?
[18:11] <infinity> doko: Yeap.  Was looking at that during the meeting.
[18:11] <vibhav> I cant find anything in the archives, does the repositories still have xlib?
[18:12] <infinity> vibhav: libx11, you mean?
[18:12] <vibhav> infinity: ah, found it
[18:12] <vibhav> I was searching for xlib and got libxcb
[18:13] <infinity> vibhav: Unlike many RPM distros, where library packages have bizarre names based on upstream project names, ours are always (except when someone messes up, *cough*) named after the SONAME, which should make them rather obvious to find.
[18:13] <vibhav> ah
[18:14] <infinity> I kinda wish I could convince Fedora to do the same.  Having to remember that your headers for libx11.so.6 are in xlib-dev is pretty unintuitive, IMO.
[18:14] <vibhav> Indeed. It is rather confusing
[18:14] <infinity> (Especially since there's no consistent naming scheme, and you get to hunt every time)
[18:16] <vibhav> yep
[18:51] <marga> slangasek, yes, I understand there's a bug, but it's unlikely to get triggered, since you need to not use plymouth nor mountall...
[18:53] <marga> slangasek, about the nsswitch file, there is also a different file being generated by these same tools.
[18:53] <marga> Much more complex than just the passwd line from dropbear
[19:15] <leighman> any one have any idea about https://launchpadlibrarian.net/130549294/buildlog_ubuntu-quantal-amd64.evolution-data-server_3.6.2-0ubuntu0.2~ppa1_FAILEDTOBUILD.txt.gz - it is just the quantal-updates branch with a single patch applied
[19:20] <dobey> infinity, jdstrand: ah, looks like squid3 failed to build. i wonder if it's the same issue causing my crash :)
[19:22] <geser> leighman: try a give-back (as it built on i386); might be due your gnome-online-accounts was not build for amd64 at the time evolution-data-server was tried
[19:22] <infinity> dobey: It's just because it builds with -Werror
[19:23] <leighman> geser: yeh, okay, cool
[19:28] <dobey> infinity: right. but -Werror wasn't added in that change. i guess a new gcc might have added a new warning though, or the change in libc caused the warning to happen, since it's an (apparently new) attribute on the setuid method
[19:29] <dobey> anyway
[19:50] <seb128> ScottK, hey, https://launchpad.net/ubuntu/+source/pyside/1.1.2-1 is depwaiting for over 3 months, is that something on your todolist?
[19:50] <ScottK> seb128: No.  It's non-trivial to solve and nothing I care about really needs pyside.
[19:51] <seb128> ScottK, well, you are the one who synced it according the raring-changes... should we revert to the previous version then?
[19:51] <xnox> seb128: we removed binaries from raring. maybe it will be fixed in debian at one point.
[19:51] <ScottK> seb128: No.  The version before was even more broken.
[19:52] <xnox> seb128: there is nothing to revert to =)))))
[19:52] <ScottK> Make xnox fix it.  He loves that kind of pain.
[19:54] <seb128> ScottK, xnox: ok, thanks ... some of the #ps guys need it, I will point them to xnox
[19:55] <ScottK> seb128: If they think they want pyside, I think you should convince them they want python-qt4 instead.  AFAIK, pyside is no longer developed upstream (or not much).  Python-qt4 already supports Qt5.
[19:55] <seb128> ScottK, ok
[19:55] <seb128> ScottK, I don't think they "want" anything, they are trying to package something that uses pyside
[19:56] <ScottK> I see.
[20:13] <jdstrand> dobey: I have the fix, I just got pulled into a meeting
[20:13] <jdstrand> (and infinity ^)
[20:14] <jdstrand> (I even filed 1117517 for myself)
[20:15] <marga> slangasek: sorry, had to reboot my vps.  If you said anything after I last spoke, I lost it :-/
[20:15] <dobey> jdstrand: great. thanks again
[20:16] <slangasek> marga: mountall doesn't put anything at all in the initramfs.  This is specific to whether plymouth is in the initramfs, which is *not* the default in Ubuntu
[20:16] <slangasek> marga: plymouth is only in the initramfs if cryptsetup is installed
[20:17] <marga> slangasek: ah, right.  That was what I was testing, because otherwise is really hard to get the boot image to stop and wait for connections
[20:17] <marga> In any case, you still want the patch for the correct copying?
[20:18]  * xnox thought we always have plymouth in initramfs. I guess I simply always have cryptsetup.....
[20:18] <hallyn> mjt: I'm not yet seeing new spice in debian experimental - is there some place we can watch it roll through the queue?
[20:24] <slangasek> marga: I'm indifferent, I'm just pointing out that it's still a real bug with real consequences - but if you know that *you* always have plymouth in the initramfs, thus making it a low priority for you, then I wouldn't bother
[20:25] <marga> slangasek: ok, I already closed the bug on our side.  But given that I spent easily 20 hours on this bug, I'm willing to send a new diff so that it doesn't all go to waste
[20:26] <slangasek> marga: up to you :)
[20:26] <slangasek> marga: if we do go ahead with it for precise, please also send the fix to the Debian maintainer
[20:27] <bdmurray> what are the status.ubuntu.com templates written in?
[20:29] <bdmurray> or maybe for is the right question
[20:51] <mterry> If I'm trying to reliably reproduce a debconf question (any question, testing frontend support in update-manager), is there an easy way to force a package to ask?
[20:54] <janimo> mterry, dpkg-reconfigure packagename or you mean something more specific?
[20:54] <mterry> janimo, I want to put my system in a state so that when I run update-manager, I get asked a debconf question
[20:54] <janimo> mterry, for ex lightdm
[20:55] <mterry> janimo, lightdm asks a debconf question?  hmm, maybe if I install an old one.  The other one I knew about was libc6, but that was so intertwined with my system I had problems installing an old one
[20:55] <janimo> mterry, I don't know then. I thought such questions are asked when a package is installed/upgraded or forcibly reconfigured not on any run of update-manager
[20:56] <mterry> ah, lightdm doesn't
[20:56] <mterry> janimo, if update-manager upgrades a package it may have to ask
[20:56] <janimo> mterry, ok it did for me as I have gdm installed, so a question pops up about picking the default login manager
[20:56] <mterry> janimo, ah... interesting
[21:32] <dobey> anyone have any idea why "python-all (>= 2.6.6-3) |
[21:32] <dobey> err
[21:33] <dobey> anyone have any idea why "python-all (>= 2.6.6-3) | python-support" as a Build-Depends for a package building on Lucid, would fail in a PPA? it builds fine locally, and have built other packages with the same dependency before :-/
[21:33] <dobey> problem is: python-all(inst 2.6.5-0ubuntu1 ! >= wanted 2.6.6-3)|python-support(missing)
[21:49] <Elbrus> dobey: I don't think | is allowed or at least working in a buildd
[21:50] <Elbrus> but maybe I am wrong
[21:50]  * Elbrus means as a build-depends obviously, not as a depends
[21:51] <Laney> kirkland asked that exact question in #-motu yesterday - it's https://launchpad.net/bugs/594916
[21:51] <Laney> summary: alternate build-depends don't really work
[21:51] <Laney> dobey: ^
[21:53] <kirkland> Laney: yeah, I still think that's strange :-)
[21:55] <Laney> bug's a bug
[21:58] <dobey> kirkland: indeed. what's even more strange, is that i've used it quite often, and am only hitting an issue now :(
[21:59] <Laney> perhaps you had python-support installed before
[22:04] <infinity> dobey: It's never worked on the buildds (or, rather, that bug has always existed).
[22:04] <adam_g> is my assumption correct that a test suite's attempt to use udev_monitor_new_from_netlink() via pyudev or similar will fail on a buildd and FTBFS?
[22:04] <dobey> infinity: i'm pretty sure i would have noticed before now if it's never worked at all
[22:05] <infinity> dobey: I'm pretty sure, as the person who wrote the bug, that it's never worked. Just sayin'.
[22:05] <dobey> infinity: considering i have had lots of packages building in multiple PPAs that depend on that exact thing :)
[22:05] <infinity> dobey: Alternate deps work, but not in that one corner case.
[22:33] <kirkland> Laney: dobey: infinity: now, if I were to put "python-support | python-all (>= 2.6.6-3)" as a build-depends, would that cause a package currently in main to trigger a mismatch (since python-support is in universe)?
[22:33] <kirkland> even though python-all is in main and satisfies the build dep?
[22:34] <dobey> kirkland: it doesn't matter if it's in main or not. first satisfied would be used; at least in a PPA, maybe not for actual archive buidls
[22:34] <infinity> kirkland: If your package is in main, that'll work splendidly.  If your package is in universe, that'll probably pull in python-support, even though you didn't need it.
[22:35] <dobey> builds
[22:35] <infinity> dobey: PPA and archive resolution is exactly the same.
[22:35] <infinity> (Well, except that PPAs have all components enabled and such)
[22:35] <kirkland> infinity: interesting, let me give that a go...
[22:36] <infinity> kirkland: The whole reason we support alternate deps at all is because of the main/universe split.
[22:36] <infinity> kirkland / dobey: Worth noting that Debian doesn't support alternate build-deps, period, so it's generally best practice to not bother.
[22:37] <infinity> (You can have them in your Build-dep line for ease of backporters, but the Debian archive buildds will only ever take the first option, by design)
[22:37] <kirkland> infinity: ack,thanks
[22:37] <infinity> Because non-deterministic build-deps were considered a bad idea.
[22:38] <kirkland> ^ boring
[22:39] <dobey> well, if there was some way to do if $DISTRO_VERSION; elsif... in build-deps, that would be nice too. but having to do a control.in and write a bunch of sed commands into a makefile to do it, sucks
[22:39] <infinity> dobey: Or, you could not expect the same source package to build on 5 releases.
[22:40] <infinity> I do believe that's the root of most people's concern here. :P
[22:40] <dobey> when i don't have to support 5 different versions of ubuntu, then we can discuss that :)
[22:40] <Laney> VCS are quite good at this kind of thing
[22:41] <infinity> dobey: What package do you have that has to support multiple versions from the same source package?
[22:41] <infinity> dobey: Note I said "has to" not, "you want to".
[22:42] <dobey> infinity: all of ubuntu one
[22:42] <infinity> (But yes, VCSes are really good at this whole "having a delta and merging branches" thing, as Laney points out)
[22:43] <dobey> VCSes don't know anything about dependencies or ubuntu releases.
[22:43] <infinity> Uhm.
[22:43] <infinity> You have a branch per ubuntu release.  They have subtly different debian/control.  You merge your upstream into each branch.  Done.
[22:43] <infinity> Pretty sure your VCS doesn't need to know what a raring ringtail is to get that job done.
[22:44] <dobey> yeah, i don't want to have to manage N copies of the same code just to build it on N versions of ubuntu
[22:44] <dobey> and i'm no going to
[22:45] <dobey> having to maintain N debian/ directories is pain
[22:46] <infinity> You could be wrong with the "and I'm not going to" assertion.
[22:46] <infinity> I'm down with your "I don't want to", but such is life.