=== slank is now known as slank_away
slangasekrobert_ancell: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/972537/comments/16 ?00:30
ubottuUbuntu bug 972537 in unity-greeter (Ubuntu Precise) "lightdm doesn't allow expired passwords" [High,Fix committed]00:31
Bluefoxicyagain, using a Windows VM to access a Google Nexus phone because Linux can't do it.  Well known problem though.00:35
PhonequerShould I create one bazar repo for each package version? (I am following http://developer.ubuntu.com/packaging/html/packaging-new-software.html)00:51
robert_ancellslangasek, oh duh. Cheers :)00:53
=== chiluk_away is now known as chiluk
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== EagleScreen is now known as Guest68724
=== rafael is now known as Guest18012
=== Ursinha is now known as Ursinha-afk
pittiGood morning04:23
pittihallyn: TBH I don't understand the problem -- how do udev's dynamic ACLs get in the way of static group permissions?04:25
pittidobey: since yesterday, ubuntuone-syncd goes crazy, creates a million /tmp/tmp* files, and uses 100% CPU all the time04:26
pittidobey: there hasn't been a new ubuntuone-client upload in a while; do you know what changed, and how to debug this?04:27
hallynpitti: if you setfacl group::--- /dev/kvm; chmod g+rw /dev/kvm; then ls -l will show ???rw-??? for /dev/kvm, but group owner won't actually have rw.  so, the problem04:30
hallynis only when you isntall a new system and do 'apt-get install qemu-kvm'04:30
hallynbc udev won't remove that acl, so until you reboot group kvm can't use /dev/kvm04:31
hallynonce you reboot, the acl doesn't get reinstalled, so it's ok after that04:31
hallynpitti: look at qemu-system.postinst and qemu-system.udev in raring's qemu for what we have to do to work around it04:32
pittihallyn: the postinst only triggers udev to reapply its rules AFAICS04:32
hallynpitti: yes, and without adding an explicit setfacl to those rules, it's not enough04:32
hallynpitti:  (which is why i pointed out the new qemu-system.udev;  it's kind of ugly and unfortunate, and requires a depends from qemu on acl which wasn't there before)04:33
pittihallyn: so you are saying that GROUP="kvm" doesn't actually work?04:34
pittior that MODE="0660" doesn't?04:34
hallynpitti: well, ACTUALLY GROUP=kvm sometimes doesnt' work but that's another story,04:34
hallynMODE=0660 does work, but doesn't remove the acl04:34
hallynso you end up with file perms allowing g+rw, but acl denying it04:35
pittiyeah, it's not supposed to remove ACLs04:35
hallynwell something has to04:35
pittibut ACLs ought to be additive, not remove permissions04:35
hallynthey're additive in that they are always checked on top of the file perms, not in the "add more permission" sense :)04:35
hallynpitti: more to the point, though, there is no reason for a group acl ever,04:36
hallynthe user acl is used by consolekit to allow the loggedin user to access /dev/kvm, but group acl is worthless,04:36
pittihallyn: I thought the point of the ACLs was to allow the local active user to access it04:36
hallynso easiest just to remove it (as in my patch)04:36
hallynyes.  user acl.04:36
hallynthe group acl though is worthless04:36
pittihallyn: so why does the udev rule add this group ACL in the first place?04:37
pittiit seems odd to me to introduce the RUN:="/usr/bin/setfacl -m g::rw $env{DEVNAME}" in the distro, and then add a patch to revert it04:37
hallynoh, i'm mis-stating what my patch does - doesn't remove the acl, just sets it to group::rw-04:37
hallyni introduced that to workaroudn this udev bug04:38
hallynand want to remove it as soon as the udev bug is fixed04:38
pitti(also, I'm not sure that RUN:= actually does anything different than RUN=)04:38
hallyni'm not advocating keeping my changes to the qemu-system.udev in qemu source04:38
hallyni'm advocating simply adding GROUP=0660 to the 70-udev-acl.rules04:38
hallynso that /dev/kvm always gets group::rw- rather than group::--- acl04:39
pittiso I'm still confused -- why can't we just drop that odd RUN from /lib/udev/rules.d/40-qemu-system.rules ?04:39
hallynthen qemu can ship a simple udev rules file to chgrp /dev/kvm to group kvm04:39
pittithat already sets the MODE correctly AFAICS04:39
hallynpitti: if we *just* drop that, then after install qemu-kvm (and until rebooting) group kvm can't access /dev/kvm04:39
hallynyes, but it's too late04:39
hallynthat MODE only does chmod, not setfacl04:40
hallynbc udev is not smart enough to update the acl04:40
pittihallyn: oh, you mean this is solely to fix the upgrade from that current .rules which sets that odd group ACL?04:40
hallynpitti: (if i understand you right) yes04:41
pittihallyn: i. e. you are going to drop the RUN part in 40-qemu-system.rules, but you want it to work at instant?04:41
pittihallyn: that kind of thing is usually a job for the postinst04:41
hallyni'll go back to the old 40-qemukvm.rules04:41
pittii. e. check the version you are upgrading from, and just call chmod04:41
hallynwhich iirc was jsut KERNEL=="kvm", GROUP="kvm", MODE="0660"04:42
pittiyeah, and that looks nice and clean04:42
hallynpitti: well i'm not sure about calling chmod - that's what debian does so i may go back to it, but slangasek prefers we do udevadm trigger...  but either way the udev rule would like tobe KERNEL=="kvm", GROUP="kvm", MODE="0660" :)04:42
hallynpitti: so all i was really pinging you about was adding 'GROUP="0660"' for the kvm case to 70-udev-acl.rules04:43
pittihallyn: calling trigger is fine, and should always be done on upgrade04:43
hallynpitti: it's fine, but it's currently insufficient :)04:43
hallyninotify is sucking04:43
pittihallyn: and on upgrade to the next version, you just additionall call chmod04:43
hallynbut again that (inotify) is a different problem04:44
hallynpitti: so do you have any objectio to adding 'GROUP="0660"' to 70-udev-acl.rules? :)04:44
pittias that potentially breaks custom rules, and also is the wrong place for one-time upgrade fixes04:45
pittiwell, it only applies for upgrades from <= 1.3.0+dfsg-1~exp3ubuntu7 (assuming that ubuntu8 will fix it)04:46
hallyngroup=--- for /dev/kvm (when owned by root:root) has zero advantages04:46
hallynpitti: this has nothing to do with any version of qemu-kvm, really04:46
pittiso its postinst shoudl call chmod on upgrades from those versions, and then be done with it04:47
hallynchmod is not enough04:47
hallynqemu did not wrongly label anything04:47
hallynevery time you install an ubuntu system,04:47
hallyn/dev/kvm gets set up (when someone logs in on consoel) with a group::--- acl,04:47
pittihallyn: I thought /lib/udev/rules.d/40-qemu-system.rules was wrong (it certainly looks odd), and you were going to fix that?04:47
hallynwhich never gets cleared by udev (bc udev doesn't support that)04:47
pittiso apparently we still talk about completely different things then04:48
hallynpitti: if the udev bug gets fixed (which is what i'm pinging you about) then i'll simplify the 40-qemu-system.rules, yes.04:48
pittiudev does not add any group ACLs04:48
pittithat's only from that rule04:48
pittihallyn: I still don't understand what the udev bug is here?04:49
hallynwell, udev sets the initial perms, and then consolekti adds ana cl for it04:49
hallynthe udev bug is that it sets group perms to --- instead of rw-04:49
pittihallyn: ^ but that ACL has nothing to do with the one from 40-qemu-system.rules04:49
hallynno it has to do with 70-udev-acl.rules04:49
hallyni pointed you to 40-qemu-system.rules to show you how we have to work around the udev bug right now04:50
hallyn(i originally did it as an explicit setfacl in qemu-system.postinst, but slangasek asked me to change that)04:50
hallynpitti: so one more time (since you've set me straight :), the order of events is:04:51
pittiok, so back to my originally question: what _is_ the udev bug?04:51
hallyn1. set up a new ubuntu system, it modprobes kvm_intel, /dev/kvm gets created,04:51
hallyn2. 70-udev-acl.rules sets /dev/kvm to root:root rwx------, and tags it with acl04:51
hallyn3. user logs in, consolekit adds a group::--- acl04:51
pittihang on, why root:root?04:51
pittithat should be root:kvm, as per 40-qemu-system.rules04:51
hallynbecause group kvm doesn't yet exist,04:51
hallynqemu-kvm has not yet been installed04:52
hallyn4. admin logs in remotely, installs qemu-kvm, triggers udev,04:52
hallyn5. udev chowns /dev/kvm to root:kvm, and sets it to rwxrw----,04:52
pitti(qemu-system, BTW)04:52
hallyn6. libvirt tries to start a vm as group kvm, but the group:--- acl refuses it04:52
pittiI don't understand 3.04:53
pittiudev-acl only applies ACL_USER acls, it doesn't touch group ACLs04:53
pittithat's only from that weird 40-qemu-system.rules run rule04:53
hallyni don't know why the acl gets added, but it has done it since at least q,04:54
hallyni only updated that 40-qemu-kvm.rules recently to work around it04:54
hallynit only does it when user logs in on console before qemu-kvm gets installed04:54
hallynbut it's hit quite a few people over the past 6-12 months04:55
hallynso anyway, all that is to say that if the 70-udev-acl.rules shipped with udev would just set GROUP=0660, then the acl gets set as group::rw-, and all works out fine04:55
pittibut nowhere in udev's source code a group ACL is set04:55
hallynno, but somewhere (in the dank depths of consolekit iiuc) an acl gets set to mirror the perms udev has set04:56
hallyn(well, and no, acls DO get set in udev code...)04:56
pittithat's /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck04:56
hallyn(but i believe you that it isn't causing this acl)04:56
* hallyn goes to look04:56
pittihallyn: yes, udev-acl.ck sets user ACLs, but not group04:56
pittiso we need to understand where that  group:--- ACL gets set in the first place, and eliminate that04:57
hallynthat woudl be ideal04:57
pittihallyn: so you are saying that group ACL had been set even before 40-qemu-system.rules got that RUN rule?04:58
hallynthat acl is there if you just boot a new ubuntu system without qemu-system installed, and log in on cnosole04:59
hallynpitti: you're sure udev-acl.c can't set that?04:59
pittihallyn: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/udev/quantal/view/head:/extras/udev-acl/udev-acl.c is that code04:59
pittihallyn: I don't see where it should set group ACLs, and that thing isn't supposed to05:01
hallynyeah doesn't look like it, good05:02
pittihallyn: you can temporarily remove /lib/udev/rules.d/70-udev-acl.rules and /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck and check if that group ACL is still there, to be 100% sure05:02
pittiweird bugs are always possible, of course05:02
hallynpitti: or perhaps this is a time for systemtap (if it actually works in raring atm)05:03
pittiso IF udev-acl.ck sets a group ACL, then that's indeed a nasty bug05:03
hallynand what exaclty does /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck do?05:04
hallyn(i can aim to test this tomorrow, but will need to find some space to test it :)05:05
hallyn(i never did trust new-fangled consolekit :)05:05
pittihallyn: it adds an rw ACL for the user that is on the currently active console, and removes ACLs for the previously active user05:06
pittihallyn: for all devices which are tagged with UDEV_ACL05:06
hallynso if i *just* remove that that should be enough to test05:06
pittihallyn: the idea being to allow the current foreground session access to things like sound cards, cameras, or said /dev/kvm, but deny it to background sessions or remote users05:06
pittie. g. getfacl /dev/dri/card005:07
pittithe second is what udev-acl.ck does; and if I switch user, or to VT1, I lose that again05:08
pitti(that makes more sense on a sound card or digicam, of course)05:08
hallynpitti: you're on raring?05:08
hallynwaht does getfacl /dev/console give you?05:09
hallyndo you get group::--- ?05:09
hallynoh nm, that's not an acl in that instance05:09
pittiyes, but that's from normal unix perms?05:10
pitti/dev/kvm has05:10
pittiwhich might be either from the static unix permissions or from 40-qemu-system.rules (g::rw is the same, isn't it?)05:11
hallynpitti: right.05:12
hallynpitti: well if you have a raring iso handy to do a vmware install you can just give it a shot - but i've got to go, will see about udev-acl.ck tomorrow.05:12
hallynthanks - good ngiht05:12
pittigood night!05:13
sarnoldremoving the acl won't revoke access, though; does consolekit kill -9 processes that have resources open?05:14
pittino, it doesn't; that would be quite rude :)05:16
sarnoldperhaps; but perhaps someone holds a webcam open or something..05:18
sarnoldI guess that's one more reason to put a piece of tape over webcams and microphone ports..05:19
* hallyn pokes his head in just to remind sarnold real quick that we've been asking for revoke(2) syscall since around 2002 :)05:55
sarnoldhallyn: .. if not even earlier :)05:56
alwinI was on the look out for a C++ project in ubuntu so i can apply my programming skills06:34
alwinany help06:34
jackyalcinealwin: a lot of stuff in Ubuntu seems to be done in Python or Vala nowadays06:44
jackyalcinewith the bigger dependency on GNOME.06:45
jackyalcinealwin: check out U1, most of it is written in C++ using the Qt framework06:45
alwinJack: what is U106:49
infinityPretty much anything that depends on libqt will be C++ somewhere.06:51
infinityPlus all the Mozilla products.06:51
infinityLots of stuff.06:51
infinityBut if you're asking "what do we need help with?", the answer is "I dunno".  Find a package you feel passionately about and check its bugs.06:52
TheLordOfTimealwin, u1 = ubuntu one.06:52
TheLordOfTimebut i agree with infinity, find a package you're passionate about and start on the bugs in the package06:53
infinity(base)adconrad@cthulhu:~$ reverse-depends libstdc++6 | wc -l06:53
TheLordOfTimethat's what happened to me, except i went down the bug triage direction, and kind of pseudo-adopted nginx :p06:53
infinityShould be some choices in those 4695 packages. :)06:53
TheLordOfTime4695 packages... xD06:53
TheLordOfTimeinfinity, is gcc one of those packages?  :p06:53
infinityOf course.06:54
TheLordOfTimefigures :P06:54
* TheLordOfTime is curious what you need to build gcc... *checks builddeps*06:54
alwinRabbit hole it is then :)06:55
infinityTheLordOfTime: To build just the C compiler, you need precious little.  The more languages you add, the more interesting it gets.06:55
TheLordOfTimeinfinity, i meant gcc and the whole shebang that goes with the language :P06:55
TheLordOfTimebasically, "What is necessary to build all the GCC and related library packages" :P06:56
infinity(The only real gotcha for the C portion of GCC is that gcc/glibc are very tightly intertwined, and the bootstrap between the two is mildly entertaining)06:56
jackyalcinealwin: U1 = Ubuntu One07:14
jackyalcinesorry about that07:14
jackyalcineupgrading to 13.04 :)07:14
dholbachgood morning07:34
pittihey dholbach07:34
dholbachhi pitti07:35
pittihallyn: I responded to the bug again with a detailled analysis07:48
pittihallyn: ah, saw your response, thanks! Will check that out07:56
pittihallyn: so apparently that setfacl -m g::rw does something I don't understand07:56
pittihallyn: but "man setfacl" says that it will adjust the unix permissions as close as possible to the specified ACL, so apparently this is resetting the group to "root"07:57
pittiinfinity: time to build fresh precise langpacks09:04
pittiinfinity: I didn't hear from the RT, so I guess I'll build them on a porter box instead of macquarie's chroto?09:04
infinitypitti: Yeah.  I'm guessing your chroot didn't get updated yet?09:04
infinitypitti: If you can fudge it with a porter box this time, that might be nice.09:04
pittinope, hardy09:04
infinityOr we can ask a vanguard if they can get to the ticket today.09:05
infinityIf there was one.09:05
infinityI guess London's still snoozing.09:05
pittiI need to copy around the GPG key, launchpadlib token, etc, but no biggie09:06
infinitypitti: Alright, then let's not block on the ticket, and just hope it gets done before the next raring or precise.3 langpacks.09:08
pittiinfinity: ok, it's running09:21
infinitypitti: Shiny.09:21
* pitti hopes that the porter box can talk to launchpad09:22
infinitypitti: If it can't, we'll escalate the chroot ticket with vigor.09:23
pittiinfinity: .launchpadlib/api.launchpad.net/cache/ is getting data, so I guess it's alright09:26
hrwI hate writing xorg.conf ;(10:13
xnoxhrw: it's ok, it hates you too. =(10:30
* xnox hopes to never edit the "safe-fallback" xorg.conf in the installer.10:30
hrwxnox: I have a feeling that nevermind which gfx card I have foss driver fails10:31
hrwxnox: radeon + two monitors (one landscape, second portrait) can be configured in first minutes of x11 session only. later one has to display garbage instead10:32
ogra_radeon with three monitors made me eventually buy an nvidia card10:38
tedgIs there a way to get a test suite to clean up child processes, no matter what?10:50
tedgLike if a test that spawns a process crashes, still kill the children.10:50
pittiinfinity: built; I downloaded, built and binary-debdiffed all packages for de and es, looking fine10:51
pittiinfinity: downloading current precise daily to give them a live test in a VM10:51
LaneyQuintasan: Yo. I understand you've been working on packaging maliit - is that right? Where are you up to with that? I'm interested in helping out. :-)10:53
=== Ursinha-afk is now known as Ursinha
sladentedg: Lennart would probably say "use systemd process containers!!!"11:09
tedgsladen, Looking at cgroups, yes.11:27
xnoxtedg: or you can use PR_SET_CHILD_SUBREAPER to something which will not die (meta-testsuite running process), such that it will be the parent of all run away processes. Which you will be able to kill.11:30
xnox(which is what user session upstart will do)11:30
notgaryDoes anyone here know how I can have a regular event added to the Fridge Calendar (http://fridge.ubuntu.com/calendars/)?11:32
=== _salem is now known as salem_
cjwatsontedg: Or separate the child processes a bit less vigorously in the first place11:34
tedgxnox, I'm a bit confused on how to do that... is it something I could have a shell script set?11:34
cjwatson(For instance, it should be possible to at least keep them as a member of the same session, I'd have thought)11:35
cjwatsonThe relevant chapter of Stevens APUE should be useful11:35
=== Amaranthus is now known as Amaranth
tedgcjwatson, acquired the volume... turns out it's in the library here at Blue Fin :-)11:37
xnoxtedg: well it's a syscall, but somebody did write a package $ sudo apt-get install prctl, but that package seems to lack the subreaper support. So adding subreaper option to that package would be useful, as by default it can spawn shell or execute commands with those process options set.11:38
cjwatsontedg: I only need to reach for it about once or twice a year nowadays, but when I do it's invaluable11:38
xnoxand then it all should die gracefully.11:39
cjwatsonIt won't document Linux-specific things; but I'd be surprised if those were necessary here, as opposed to useful11:39
cjwatsonxnox: PR_SET_CHILD_SUBREAPER is no use here - it was introduced in Linux 3.3, and the buildds run 3.211:40
cjwatson(i.e. precise)11:40
cjwatsonSo it won't be usable in test suites until at least 201411:40
xnox=( can be used in DEP-8 autopkgtests and / or UTAH based tests at least.11:42
cjwatsonxnox: tedg's situation is that a runaway test suite is killing LP builders, so we need a solution that works there11:42
cjwatsontedg: As a belt-and-braces solution, you could get a process list before and after running your test suite, and kill any extra dbus processes that appear11:43
cjwatsontedg: It's obviously not perfect but would deal with the immediate problem easily enough11:43
tedgcjwatson, Yeah, I was thinking using a killall -9 -y dbus-daemon11:43
cjwatsonWell, I wouldn't do that, because people are allowed to build packages in their ordinary sessions11:43
tedgcjwatson, It might be easier... though very brute.11:43
cjwatson(also, killall is evil, use pkill)11:43
ogra_++ for pkill11:44
tedgWell in their sessions the dbus-daemon wouldn't be younger than the test suite.11:44
cjwatson(sorry, gut reaction from somebody who used to have to use more SysV-ish systems ...)11:44
cjwatsonSure, but just killing all dbus-daemon processes would kill their session dbus too11:44
cjwatsonHence needing to take a process list11:44
cjwatsonOh, -y - sorry, I misunderstood that option11:44
tedgIt doesn't seem pkill has the same option.11:45
cjwatsonI guess.  I think I'd prefer something more explicit, but as you wish :)11:45
infinitytedg: Why not just specify a pidfile in the config...?11:47
=== Ursinha is now known as Ursinha-afk
infinityThough, I'm also curious why this dbus-daemon, being run with --nofork is being reparented to init at all.11:47
cjwatsonIf I could control enough of the software involved, the way I'd do this would probably be simply to make sure that dbus-daemon remains in the same process group11:47
infinityIsn't that kind exactly the opposite of what one would expect?11:47
cjwatsonThen you can kill it with kill(-pgrp)11:48
tedgYeah, I do think it's odd that it's hanging out.11:48
tedgThis is all in libdbustest -- patches more than welcome :-)11:48
tedgSo if we used the temp file stuff to make PID files, and then we killed all of them.11:48
cjwatsonAn strace would probably be illuminating (although in this case strace will probably change behaviour - I just mean to see where it's disconnecting itself)11:48
infinityI'd have to go digging into other packages, but I assume the pidfile way is the general way to go.11:54
infinityAnd it doesn't need to be in randomly-named tmpfiles.  You control the namespace in your package build.11:54
tedginfinity, The problem is that we spawn probably 20-30 dbus-daemons11:57
tedginfinity, Some tests spawn several.11:58
tedgI guess we could have a unique name for each test... that'd be a bit crazy to manage though.11:59
infinitytedg: Err, are the tests in paralle or serial?11:59
infinitytedg: If they're serial, there's no problem with just reusing the same pidfile all over again (or grabbing the pid from --print-pid)12:00
tedginfinity, Uhm, that's a trick question.  They can be run in parallel locally, but the packaging runs them serially.12:00
tedginfinity, The problem with using the same file is that I'd have to clean up in the shell script, that would have an unknown number of dbus-daemons started.12:00
tedgAfter the debs are published can we just kill the builder :-)12:02
=== Ursinha-afk is now known as Ursinha
infinitytedg: tools/with-session-bus.sh from the telepathy-glib source may be enlightening.12:07
infinitytedg: And yeah, they use --print-pid=6 and then exec 6> $me-$$.pid12:08
infinitytedg: But the whole thing may be worth cargo-culting.  I doubt there are many testsuites that hit dbus harder than telepathy, and it never has a sad.12:08
tedginfinity, Well, we're a bit more sophisticated in our dbus testing than they are :-)12:09
=== Ursinha is now known as Ursinha-afk
infinitytedg: I disagree. :P12:09
tedginfinity, But, yes, writing out the PIDs makes sense.12:09
infinitytedg: And they intentionally fork, so they can get on with their scripts.  Which is probably the right thing to do, since --nofork doesn't do anything particularly useful.12:12
infinity(Sure, it keeps it attached and in the foreground... Right up until the parent dies, and it double-forks to oblivion)12:12
=== mpt_ is now known as mpt
pittimeh, I can't get the current precise dailys to work in kvm12:42
pitti... nor in virtualbox -- oh for heaven's sake!13:08
* pitti grumpily downloads the i386 one instead and test on his netbook13:08
=== Ursinha-afk is now known as Ursinha
pittiev: just caught my eye -- we still ship udisks in raring by default due to usb-creator; as gnome disks has had the ability to write images onto devices for a while, and our images are bootable by themselves now, do you think we could drop that? or do you (or someone else) plan to port it to udisks2?13:27
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
infinitytseliot: I see no point in that nvidia-common upload to precise-proposed.13:51
tseliotinfinity: It was just to reassure people who kept on blaming nvidia-common for a bug reported on errors.ubuntu.com13:52
infinitytseliot: Sure, but if it's just running a test at build time, you could have done the same thing in a PPA. :P13:53
tseliotinfinity: oh, sure. Had it been for me I wouldn't have done anything as the code speaks clearly ;)13:54
infinitytseliot: Right, well, given that it's only ever going to show up in a build log, rather than doing something different on users' machines, I'll just reject it.13:55
infinitytseliot: Should you ever upload nvidia-common to fix some other bug, feel free to include the shinier test suite too.13:56
tseliotinfinity: I will have to backport the linux-headers installation code, so I'll include the test suite in that upload13:56
infinitytseliot: Sure.  When you do, make the bug closure reference in the changelog actually have proper syntax next time. :P13:57
tseliotinfinity: oh, it was missing #13:59
tseliotgood point13:59
xnoxpitti: ev: I am working on porting to udisks2 now.14:00
xnoxpitti: ev: we can certainly use the "dd image from here to there" method. But doing that we will lose ability to create persistence file, won't we?!14:01
xnoxogra_: there are a few bugs about not being able to do update-initramfs and/or update-grub when booting from persistent usb. Can we somehow use flash-kernel to update the kernel on the real partition that has the kernel and not the bits inside squashfs?14:02
pittixnox: ah, right14:06
MCR1andyrock, if you are here, could you re-approve https://code.launchpad.net/~unity-team/unity/dash-blur-to-linear-sample/+merge/144104 ?14:06
=== Ursinha is now known as Ursinha-afk
andyrockMCR1, sure14:07
MCR1there was a conflict with trunk that is now fixed14:07
andyrockMCR1, i now nic just pinged me14:07
andyrockthanks for testing it ;)14:07
MCR1I just saw the diff ;)14:08
evxnox: cheers!14:09
xnoxev: not that I enjoy the new UDisks2 API with org.desktop.DBus.ObjectManager a whole load of new interfaces.14:11
xnoxpitti: any good examples of GDBus server python API used in the wild?14:11
pittixnox: no, because that doesn't work :(14:11
hallynpitti: oh?  when i manually do 'setfacl -m g::rw' it doesn't change the group for me.  (but i'd believe it)14:11
pittixnox: mostly due to gnome bug 65632514:12
ubottuGnome bug 656325 in gdbus "Make GDBusInterfaceVTable binding friendly" [Normal,Assigned] http://bugzilla.gnome.org/show_bug.cgi?id=65632514:12
pittixnox: so you need to use python-dbus14:12
pittixnox: or python3-dbus14:12
evxnox: this was the one that davidz was trying to defend by claiming that it was never intended to be consumed by anything but gdu, right?14:12
pittithat bug has been on my "assigned" list for far too long; the urgency has greatly been diminished by barry porting python-dbus to python314:13
xnoxev: yeah.... well new API is nice and gives a bucket loads more information, but it's very backwards. And one has to do bottom-up lookups =/ (filesystem->block-device->drive-type)14:13
pittixnox: but you know there's gir1.2-udisks-2.0 ?14:14
pittixnox: that's the API you ought to use, not the raw D-BUS one14:14
xnoxand do guess work - oh this object has: filesystem & block interface, and it's parent drive has property Optical then I'm guessing it's optical drive.14:14
pittixnox: well, you can still use raw D-BUS if you like14:14
xnoxpitti: ha. let me check that.14:14
pittixnox: http://cgit.freedesktop.org/udisks/tree/src/tests/integration-test uses it, so if you want to look at that for an example14:15
seb128ogra_, ok, so my nothing-on-screen-after-nexus-distupgrade ... I can see the session when I change screen backlight level14:15
seb128well, it does display when I change the value then goes back to blank14:15
=== Ursinha-afk is now known as Ursinha
xnoxpitti: thanks. looks very similar to DBus api, apart from no need to create connection first.14:18
pittixnox: yeah, libudisks and the gir are autogenerated from the D-BUS interface14:18
pittixnox: need to run out for a bit, bbl14:18
xnox=/ why would anyone support multiple ways to access the same crapy API is beyond me14:19
pittixnox: try to use libudisks from C, and then do the same with plain gdbus, and you'll know :)14:20
pittithe difference is a lot smaller in Python of course14:20
=== francisco is now known as Guest38765
QuintasanLaney: uh oh, I'm supposed to start packaging plugins14:29
Quintasanframeworks are done with the exception of tests which fail because they need an X instance, xvfb fails ofc14:30
LaneyQuintasan: did you start from their ppa package?14:30
dobeypitti: the issue is probably due to the new libc6 version, which broke some stuff. there hasn't been a new upload in a while, because lots of upstream changes broke lots of things, and i've been having to deal with them all across the u1 stack for the past week, including some infrastructure breakaage/downtime14:30
QuintasanLaney: More or less, I just took dependencies from there. The rest was done from scratch14:30
QuintasanLaney: Do you want to see frameworks pacakging?14:33
LaneyQuintasan: sure14:33
Laneydo you think it's ready to go?14:33
QuintasanIf missing tests are not a problem then yes14:33
Laneyhere I got xvfb tests working but then it's failing later on when trying to link some test with "dummyimplugin"14:33
Laneywell I say "got", I just xvfb-run make check ...14:34
QuintasanThat's how you did it.14:34
dholbachcoolbhavi, tumbleweed, mhall119, notgary: ready? :)14:35
coolbhavidholbach, yup :-)14:36
Quintasandholbach: I believe I won't be able to translate the packaging manual for this cycle14:36
dholbachQuintasan, do you think you could reach out to the polish loco for some help with translations?14:36
Quintasanuni has to eat more stuff than I expected it to.14:36
Quintasandholbach: I'll try, but I can't promise anything14:37
dholbachQuintasan, dzieki!14:37
Quintasandholbach: nie ma za co :)14:37
QuintasanLaney: I'll just testbuild it before I sent you not working stuff or something :P14:37
QuintasanLaney: mikhas is at #kubuntu-devel so if you have any particular thing to ask about maliit you can ping him there, or I can ask him to get in here14:38
Laneyah, I just had to make -C tests and it builds those libraries14:40
LaneyQuintasan: here would be good so I don't have to join another channel :P14:40
QuintasanLaney: http://people.ubuntu.com/~quintasan/uploads/maliit-framework_0.94.0-0ubuntu1.debian.tar.gz14:41
QuintasanHere is what I got14:41
dobeypitti: looks like all our necessary fix branches have landed now in our trunk, and our nightlies PPA has built fine, so i'll be able to upload the new version today14:41
LaneyQuintasan: thanks; I'll combine it up with what I have14:42
QuintasanLaney: I don't think I have symbols file there but they (i386, amd64, arm) are pending till I get my ARM box running.14:42
QuintasanLaney: I'd appreciate it if you left the uploading magic to me since we have to get it along with Plasma Active 314:42
* Quintasan looks at plugins14:43
LaneyQuintasan: Right, I don't know anything about that14:43
Laneyhow does that impact uploading to Debian?14:43
QuintasanOh wait14:43
QuintasanLaney: You think you can get it to Debian?14:43
Laneymy key's a bit rusty but it probably still fits the lock ;-)14:44
QuintasanThat would be like...great.14:44
Laneyanyway I'll get back to you before doing that14:44
QuintasanI'll be taking a look at plugins then14:45
tseliotcyphermox: hi, I was told that you worked on the drivers manager code for software-properties-gtk. Can you have a look at my code, please? https://code.launchpad.net/~albertomilone/software-properties/linux-headers/+merge/14538614:46
mhall119dholbach: not my turn yet14:46
dholbachmhall119, not immediately, but today, right? :)14:47
dholbachhttps://wiki.ubuntu.com/UbuntuDeveloperWeek Day 1  starting in 13 minutes in #ubuntu-classroom14:47
QuintasanLaney: I think framework still needs symbols file to be generated, got arm box or something to do that or want me to take care of that?14:47
mhall119dholbach: today yes, not yesteray :)14:48
* mhall119 needs much more coffee before he'll be ready14:48
dholbachyou should have one or the other minute :)14:49
LaneyQuintasan: I can do that, yeah14:49
* Quintasan doesn't have to set up his arm box14:49
* Quintasan hides14:49
=== slank_away is now known as slank
Laneyarmhf is actually the only arch on which I've run maliit :P14:50
Laney(nexus 7)14:50
cyphermoxtseliot: why have the driver packages changed in that way? seems like a better way to depends rather than introduce code to do this is it's needed to build...14:54
cyphermoxbut I'm not aware of all the details14:54
=== Ursinha is now known as Ursinha-afk
tseliotcyphermox: we agreed with infinity that we cannot make sure that the correct headers flavour can be installed with package dependencies if users decide to install a kernel flavour other that the one ubiquity installed or if they simply removed the headers14:55
cyphermoxah, makes sense14:55
QuintasanLaney: Mmmkay, also, be sure to bash me if I made any graves mistakes, never did libraries from scratch14:55
cyphermoxtseliot: I would have thought the headers to be mostly always the same though ;)14:56
tseliotcyphermox: yes, I wish ;)14:56
cyphermoxtseliot: ah, if you could just have not added one extra space in the PEP8 reformat it would have been so much easier to review :P14:57
tseliotcyphermox: heh, sorry but my text editor couldn't live with 2-spaces indentation ;)14:58
infinitycyphermox: Installers always install "linux-$flavour" which, as of recent SRUs, always depends on the headers for your flavour.15:03
infinitycyphermox: Any attempts to manage this outside the installer or kernel metapackages will invariably fail, as other packages just plain have no clue what you have installed.15:03
infinitycyphermox: (Though, the belt-and-bracers idea to also have jockey/drivers-common/whatever suggest installing headers if you've removed them is a good thing too)15:04
infinitytseliot: I'm too lazy to read the diff, but if it does what the changelog says, it's not ideal.15:05
tseliotinfinity: how so?15:05
infinitytseliot: Installing the missing headers isn't the right answer, installing "linux-$flavor" is.  Otherwise, as soon as they upgrade, they'll have mismatched headers again.15:06
tseliotinfinity: are you saying that linux-headers-$flavour is not enough?15:06
ogra_they wouldnt be upgraded with the kernel15:07
ogra_thats what the metapackages are for15:07
infinitytseliot: Oh, linux-headers-$flavour (without the ABI) is enough too, but we ideally want people to have the parent package anyway.15:07
cyphermoxIs there any case where the headers from get_kernel_headers() might not include all that is necessary to build a dkms package while another package does? Assuming a user has removed headers before, can they install a dkms package which will cause headers to be installed and the dkms package to still finish installing?15:08
tseliotinfinity: yes, it's just linux-headers-$flavour, no abi or version in it15:08
cyphermox(I mean still not finish)15:08
infinitytseliot: Did you test the regex against various differently-named kernels?15:10
EsokratesI need to setup an lxc conatiner using Xephyr for graphical output of an app. Do you know a good guide to help me achieving this? Is there a possibilite to resize the forwarded window? (I think a patch was applied to Xephyr, but I do not know if it made into the package)15:10
tseliotcyphermox: when you install a driver you get: 1) the driver and its dependencies hence 2) dkms and 3) the headers (Thanks to this change)15:10
infinitytseliot: Like, ones with '-' or numbers in the flavour name?15:10
tseliotinfinity: such as?15:11
cyphermoxtseliot: yeah, I'm concerned that $dkmspackage doesn't depends on $headers anymore, and $headers-flavor doesn't contain what it needs to successfully build15:11
infinitytseliot: omap4, nexu7, lowlatency-pae, or the ultimate test, powerpc64-smp15:11
tseliotcyphermox: headers + dkms + driver should be enough15:12
infinitycyphermox: Erm, headers-flavour depends on exactly what dkms used to (except correctly).15:12
cyphermoxinfinity: alright15:12
tseliotinfinity: I can certainly add a test for those packages in my test suite15:12
cyphermoxas far as I'm concerned the code for softwareproperties looks fine (although I'm not super fond of reformatting), and if we agree that the actual package to install from detect.get_linux_headers() is right, then it's all fine15:13
infinitytseliot: I didn't read the regex closely, but greediness can tend to bite one if you assume things like "linux-image-(.+)-(.+) will get you what you want from the end (it may end up just returning "pae" or "smp")15:14
tseliotinfinity: I remember testing -generic-pae but I haven't tested all of the possible flavours. This is what the testsuite is for and I'll make sure that these cases are covered15:15
tseliotcyphermox: the other changes that I'm discussing with infinity are meant will land in ubuntu-drivers-common, without any need to touch software-properties-gtk any more15:18
hallynsmb: plars: do you remember or have handy the bug # for qemu failures we had with cirrus vga, which were worked around by disabling cirrus driver at boot (or something like that)?15:19
hallynI'm asking so I can tie it to bug 110338515:19
ubottubug 1103385 in qemu-kvm (Ubuntu) "Raring crashes on 12.04 LTS host with cirrus @800x600" [Medium,Confirmed] https://launchpad.net/bugs/110338515:19
smbhallyn, Maybe ... a sec15:20
smbhallyn, one related was one I opened myself: bug  1039647 (its different though because the symptom was not "no fb" back then)...15:25
ubottubug 1039647 in unity (Ubuntu) "KVM/cirrus desktop fails to start" [High,Confirmed] https://launchpad.net/bugs/103964715:25
hallynsmb: thanks.  so that's yet another.15:26
hallynsmb: i was just trying out unity on 1.3.0 qemu withi vmware vga yesterday, corruption is definately still there15:26
smbhallyn, Yeah I think vmware could be. Cirrus was not crashing as badly as before but the underlying circular_area thingy was maybe fixed recently15:27
minohi guys. i have a package building related question posted here: http://askubuntu.com/questions/248994/howto-handle-packaging-and-development-in-one-git-repository . Any suggestions?15:29
plarshallyn: I think the one I had was https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/105412915:30
ubottuUbuntu bug 1054129 in qemu-kvm (Ubuntu Quantal) "reboot with -vga cirrus can result in broken output" [Medium,Confirmed]15:30
smbhallyn, actually the better one was bug 103805515:30
ubottubug 1038055 in linux (Ubuntu) "graphics fail to initialise correctly, in kvm with cirrus graphics (after LUKS install)" [High,Fix released] https://launchpad.net/bugs/103805515:30
xnoxsmb: yeah for above bug, in quantal the relevant kernel driver bit was reverted. is it back in, in raring?15:31
smbxnox, Yes and now causing no-framebuffer cases for a change :)15:32
notgarydholbach, ready :)15:32
xnoxsmb: awesome!15:32
xnoxwait, a second....!15:32
dholbachnotgary, great15:33
smbhallyn, For reference, this one seemed to bite occasionally when using 3D under KVM (with cirrus): bug 104351315:34
ubottubug 1043513 in xserver-xorg-video-cirrus (Ubuntu) "Xorg crashed with SIGABRT in memcpy() via cirRefreshArea() under KVM virtual machine" [Medium,Fix released] https://launchpad.net/bugs/104351315:34
hallynsmb: meaning you still occasionally get that one?15:36
hallynfunny i've patched a similar one not that long ago15:37
hallynoh, that was in xserver-xorg-video-qxl15:37
smbhallyn, Must admit I have not run desktop in KVM since then... On usual machine 3D in KVM sucks a lot of time15:37
hallynsmb: odd, bc so long as i dont specify -vga, desktop works pretty well for me over vnc usually15:38
hallynsmb: plars: thanks for the links15:38
hallynjdstrand: do you think the security review for MIR of spice will happen soon?  If not then I should go ahead and submit a new qemu-kvm-spice source so qemu-linaro can be dropped (to make infinity happy :)15:39
smbhallyn, I had a feeling it was also related to the speed of your guest. Since mine sucked it was more common. The machine I use for Xen mostly also uses an emulated cirrus but is quicker and so sees less crashes15:39
hallynsmb: so then i should be able to better reproduce it with a nested guest perhaps15:39
jdstrandhallyn: I can probably get to it this week. not today though15:41
smb(beside the fact that Xen uses a different pci subvendor ID and thus uses the xorg-cirrus driver, while kvm when the kernel drm driver works, uses  a different one (forgot the exact name gain)15:41
hallynjdstrand: that'd be awesome, thanks!15:44
mdeslaurhrm, I use quantal in kvm with llvmpipe every day with -cirrus15:45
smbmdeslaur, As I said it seemed much more likely when the host was overwhelmed. Like in my case when it took 3s to fade in windows...15:46
mdeslauroh, yeah, it's slow as heck...you have to be patient :)15:46
mdeslaurI usually switch it to gnome-panel if I have something graphical to test15:46
mdeslaurbut maybe I'm lucky15:47
smbYeah, much better. :)15:47
smbActually classic gnome with no fuzz... :-P15:47
mdeslaurit makes me miss unity though, switching back to gnome 2/gnome panel makes me realize how awful that desktop was :P15:48
mdeslaur(how awful gnome 2 was)15:49
smbI would not say awful. Different. Sure now it feels as bad going back as it felt going forward. Nothing works like your fingers/hands think. ;)15:51
=== Ursinha-afk is now known as Ursinha
dobeyi'm "using" unity now, but it actually is far inferior for me, than the setup i had with the old gnome 2 panel was. :-/15:56
mdeslaursorry, didn't mean to be insulting :P16:01
QuintasanLaney: Man, that xvfb-run is like magic16:08
QuintasanLaney: plugins should be done today or tomorrow.16:09
LaneyQuintasan: Nice :-). I've been tinkering with framework a bit.16:10
LaneyI'll upload it somewhere later today and you'll be able to see what I've changed16:10
QuintasanLaney: Be sure to poke me serveral times or send me an email - quintasan@kubuntu.org16:11
* Quintasan is sometimes forgetful16:11
tseliotinfinity: so, apparently all linux flavours but "-omap4" seem to work. The main problem is that the package source is named linux-ti-omap4 whereas the package is e.g. linux-image-3.2.0-1419-omap4 (without the "ti" part)16:18
infinitytseliot: You're using the source to map?  That's going to end in pain.16:19
infinitytseliot: linux-ti-omap4 isn't the only one with that oddity.16:22
tseliotinfinity: only when the source is linux-$something. For example, in the case of linux-image-3.5.0-19-generic in precise (a backported kernel from quantal) the source is linux-lts-quantal, therefore the correct headers are linux-headers-generic-lts-quantal, instead of linux-headers-generic16:22
infinitytseliot: Oh, yeah, the lts-* stuff is special.16:22
infinitytseliot: And probably makes more sense to special-case lts-* than to try to divine generic rules from it.16:23
infinitytseliot: (linux-ppc in raring would trip similar issues, no?)16:24
tseliotinfinity: linux-image-3.5.0-19-powerpc64-smp works fine16:24
infinitytseliot: That's quantal, where it comes from the linux source package. In raring, it doesn't.16:24
tseliotinfinity: oh, let me check16:25
infinitytseliot: Anyhow, you're probably better off doing the mapping based on binary packages, unless source contains -lts-16:25
infinitytseliot: Or something like that.16:26
tseliotinfinity: yes, if -lts is the only special case16:26
tseliotinfinity: thanks for the heads up, I'll change the logic a bit and make sure to add more tests16:29
infinitytseliot: Cool, thanks.16:30
=== tkamppeter_ is now known as tkamppeter
pittidobey: thanks for the heads-up!16:57
hallynstgraber: I'm looking to make qemu-user-static not install cross-32/64-bit handlers (work item in https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-binfmtns).  How would you recommend detecting that?16:59
hallynstgraber: should i just do a straight 'uname -m' comparison with blacklist?16:59
hallynor is there a way to just get the word size?16:59
ogra_hallyn, !17:01
hallyncjwatson: sorry to distract you, but i'm tryin gto remember our conversation at UDS about your machien... would checking 'uname -m' and refusing to install 64-bit handlers on i386 suffice?  or is that not enoguhf or you?17:01
hallynogra_: hi17:01
ogra_i think i have a never closed linux bug open for that17:01
infinityhallyn: The wordsize of... The kernel, or userspace?17:01
hallyninfinity: that's what i'm asking cjwatson about right now :)17:01
infinityhallyn: Checking his uname would be fine.17:01
hallyni think userspace17:01
hallynbecause you can run a 32-bit userspace on 64-bit kernel, and then you want to stick with 32-bit binfmt handler, right?17:02
infinityhallyn: I assume the bug was that on i386, it was installing an emulation handler for x86_64?17:02
hallyninfinity: also installing 386 handler on 64-bit,17:02
hallynas after that you can't run 64-bit binaries any more17:02
infinityThat can't be true, or I wouldn't be able to run anything.17:03
mlankhorsthallyn: erm wouldn't that fail on cross compile?17:03
ogra_hallyn, bug 42786317:03
ubottubug 427863 in linux (Ubuntu) "binfmt allows breaking out of chroots due to not respecting namespaces" [Medium,Invalid] https://launchpad.net/bugs/42786317:03
rtgcjwatson, upower is still harshing my buzz. see bug #110907617:04
ubottuError: Launchpad bug 1109076 could not be found17:04
hallynogra_: that looks like it'll be solved by the blueprint i linked above :)17:04
ogra_hallyn, though my prob was rather stacked binfmt stuff there, but its also namespace related17:05
ogra_great to see someone finally cares :)17:05
hallynogra_: yeah, though i'm afraid it's going ot be postponed ntil 13.1017:05
ogra_well, i opened the bug in 200917:05
* ogra_ is patient 17:06
hallynogra_: :)17:08
hallynhm, i don't seem able to install qemu-user-static:i38617:08
ogra_i wonder if thats actuallyl being built17:09
Laneyrtg: I just saw a segfault immediately after dist-upgrading it; is that what you got too?17:10
* ogra_ wouldnt mind trying that on an arm ... running wine uder it to play a windows game or so *g*17:10
Laney(can't see that bug)17:10
rtgLaney, yeah, it happens pretty early.17:11
Laneyupowerd crashed with SIGSEGV in __GI___libc_free()17:11
rtgLaney, my bug report is likely still waiting on the stack sanitizer17:11
rtgbut that looks like what I saw as well17:11
apwbug #110907617:22
ubottuError: Launchpad bug 1109076 could not be found17:22
GunnarHjcjwatson: ping?17:22
Laneyhere comes the pingfest ;-)17:23
GunnarHjyou bet :)17:23
jsalisburyrtg, apw, I don't think 1109076 is a valid bug number17:24
Laneyit's just private while it waits to be retraced17:24
=== Ursinha is now known as Ursinha-afk
pitticjwatson: hm, new upower is causing crashes (like bug 1108995) and retracing fails because apache on allspice is AWOL (I'll go ask IS)17:50
ubottuError: Launchpad bug 1108995 could not be found17:50
pittinot the best day17:51
seb128pitti, some others pinged him earlier, he seems to not be around ... I guess one of the leak fixes turned out to be a too-much-free ... do you have an idea which one or should we just revert meanwhile?17:52
pittithey both looked good, let me look again17:52
pittiseb128: no firm gut feeling I'm afraid17:52
seb128pitti, laney is getting the issue if you need debug infos17:53
Laneyyou'll probably get it too if you dist-upgrade to the new upower17:53
pittijust finished upgrading17:54
seb128upgrade runninghere...17:54
pittiI have tons of oneconf crashes, but no upower17:54
seb128Laney, it might depend of the type of device, if you are on battery/ac, etc17:54
pittiah, I don't have a battery17:55
Laneylet me try it on my other machine17:55
pittiif so, then it's the one in up_device_supply_get_design_voltage()/    up_history_finalize()17:55
seb128pitti, I'm building a dbg version of upower17:55
cjwatsonhallyn: My system is amd64 kernel, i386 userspace, some amd64 chroots/VMs; so IMO qemu-* should avoid installing an x86_64 emulation binfmt handler if uname -m says x86_6417:57
cjwatsonhallyn: And this has broken for me quite recently17:57
Laneyseb128: pitti: Yeah must be something about batteries; saw it on the nexus17:57
Laneybut not on the desktop PC17:57
cjwatsonrtg: I can't see thatbug17:57
pittiapw: seems we have some bigger prroblems with ddebs as well, cannot fetch from 7 buildds (sorting out with IS ATM)17:57
cjwatsonOh, never mind, now I cn17:57
cjwatsonI'll sort out upower in a bit, finishing up a call17:58
rtgcjwatson, np17:58
pitticjwatson: I can upload a revert if you want, to take out the pressure?17:58
cjwatsonpitti: please do - I haven't seen a valid stacktrace yet17:59
hallyncjwatson: when i create i386 chroot/container on amd64, install qemu-user-static doesn't break it...  did in precise, does not in raring.  but your exact use case i haven't tried.  but binfmt was acting like it has some new safeguards17:59
apwcjwatson, if you run the daemon on the command line it blows up in your face17:59
cjwatsonapw: Didn't for me, but that was armhf.  But OK, I'll try that17:59
seb128cjwatson, pitti: http://paste.ubuntu.com/1586544/17:59
pitticjwatson: yeah, that's the part of the problem I'm dealing with ATM17:59
cjwatsonhallyn: That isn't the same thing, certainly18:00
pittiseb128: merci, that helps18:00
apw*** Error in `/usr/lib/upower/upowerd': free(): invalid pointer: 0x098cfdd8 ***18:00
apwcjwatson, ^18:00
cjwatsonThe top level userspace on my system is i386, not amd6418:00
pittiapw: see seb128's stack trace, got it18:00
cjwatsonGunnarHj: upower, or something else?18:00
apwpitti, ahh right18:01
seb128pitti, cjwatson: http://paste.ubuntu.com/1586548/18:01
seb128valgrind log18:01
GunnarHjcjwatson: Hi Colin! It's something else, not urgent, asked my question on bug 960314 instead.18:01
ubottubug 960314 in ubiquity (Ubuntu) "Unnecessary languages listed but not installed after install" [Undecided,New] https://launchpad.net/bugs/96031418:01
hallyncjwatson: well, i can try a amd64 chroot under i386 container on amd64...  maybe that comes close18:02
cjwatsonGunnarHj: can't deal with that this week18:02
=== Ursinha-afk is now known as Ursinha
GunnarHjcjwatson: That's fine.18:03
cjwatsonhallyn: probably not18:03
hallyncjwatson: why not?  since there is no namespace for binfmt, i'd expec tsomething in that stack to get corrupted...18:03
cjwatsonpitti,seb128: IDGI, how can "energy = sysfs_get_double (native_path, "energy_avg") / 1000000.0;" be calling free on that value?18:03
cjwatsonhallyn: oh, container, I misread18:04
cjwatsonhallyn: But why don't you just tell me what you want me to try here ...18:04
pitticjwatson: it's the new free() in up_device_supply_get_design_voltage apparenlty, that's the bit I'm reverting18:04
hallyncjwatson: welli'm wondering whether new qemu-user-static (now coming from debian's qemu) or new binfmt has alredy worked around the problem you were having,18:04
hallyni.e. juts do what normally breaks (installing qemu-user-static in amd64 chroot?)18:05
cjwatsonGunnarHj: TBH, I don't think your mail was really very related to what I'm trying to fix, and what I am determined needs to be fixed18:05
hallyncjwatson: how did you set up your system?  install i386 system then compile your own adm64 kernel and install it?18:05
pittiapw, seb128: care to try http://people.canonical.com/~pitti/tmp/upower_0.9.19-1ubuntu2_amd64.deb ?18:05
cjwatsonhallyn: I installed i386 eons ago, then a little while back I installed the Ubuntu amd64 kernel using multiarch18:05
seb128pitti, I'm on i386; can run "make" on my current build tree if you tell me what to change though18:05
cjwatsonLife is far too short to be compiling my own kernels18:05
apwpitti, will do18:06
hallynhaha - multiarch for kernel, too cool18:06
pittiseb128: http://paste.ubuntu.com/1586563/18:06
seb128pitti, that fixes it18:07
pittiseb128: merci, uploaded18:07
GunnarHjcjwatson: Hmm.. Are possibly mixing up the paper size thing and the redundant Chinese locales?18:07
seb128pitti, danke18:07
* pitti goes to play some whack-a-rat with the dupes18:07
xnoxpitti: bug #960314 links to bug #863378 which has a branch merge proposal which is against langpack-locales not special casing for zh-XXXX lang packs.18:07
ubottubug 960314 in ubiquity (Ubuntu) "Unnecessary languages listed but not installed after install" [Undecided,New] https://launchpad.net/bugs/96031418:07
ubottubug 863378 in langpack-locales (Ubuntu) "Locales not removed when removing Chinese translations" [Low,In progress] https://launchpad.net/bugs/86337818:07
xnoxpitti: maybe you can review it?18:08
pittixnox: sorry, not right now; two "OMGnow" things ongoing right now, and I actually wanted to call it a day over an hour ago ..18:08
pittixnox: but I can review it in general, yes; can you please subscribe me so that I get a mail?18:08
apwpitti, you got a 32bit to test as well18:09
pittiapw: seb128 should have a deb now18:09
seb128apw, pitti: let me scp that18:10
pittilool: oh, that's also your upower crash, BTW (very very likely)18:10
pittialthough, maybe not; I'll have a look tomorrow18:11
xnoxpitti: ack.18:12
seb128apw, http://people.canonical.com/~seb128/upower_0.9.19-1ubuntu2_i386.deb18:12
apwwget *** Error in `/usr/lib/upower/upowerd': free(): invalid pointer: 0x098cfdd8 ***18:12
apwIGNORE that18:12
pittiamd64 build is somewhat blocked (where did all our buildds go}), rest building18:12
pittioh, moved to i386 for precise langpacks, I guess18:13
Laneythey probably got switched to i386 to ... that18:13
apwpitti, seb128's 32bit works for me18:13
cjwatsonGunnarHj: I only linked the Chinese one for reference - I don't think this is directly related18:14
=== ximion is now known as ximion-afk
GunnarHjcjwatson: Ok, thought it was worth asking. ;-) Thanks.18:16
GunnarHjpitti: You are already asked to review the bug 863378 MP, so you probably have a mail. Not urgent.18:17
ubottubug 863378 in langpack-locales (Ubuntu) "Locales not removed when removing Chinese translations" [Low,In progress] https://launchpad.net/bugs/86337818:17
pittiapw, seb128, cjwatson: ok, built everywhere (armhf is at dh_builddeb), so should be fine; leaving now, please call my mobile if you need more help18:20
apwpitti, thanks18:20
seb128pitti, thanks, have a good evening!18:20
ian__605Can anyone give me some advice for debugging an app? A user gets inconsistent crashes with a SIGSEGV in ccsGSettingsValueChanged(). I can't reproduce it but it seems to happen every 7-8 program starts for him. Starting with gdb never reproduces it, but an apport bug report gives some info. seems that SegvReason is reading unknown VMA18:24
ian__605From the top of the stacktrace: #0  0x00007fbb283f74b3 in ccsGSettingsValueChanged () from /usr/lib/libcompizconfig_gsettings_backend.so18:25
seb128ian__605, try asking on #ubuntu-unity18:26
seb128seems like a bug in the unity-gsettings backend18:26
seb128compiz-gsettings rather18:26
loolpitti: Yeah, sounds like it; I had installed updates at around the same time18:26
loolpitti: thanks!18:26
ian__605yeah... I will ask on #ubuntu-unity too, but is should I file a bug report with compiz-gnome since that's the package libcompizconfig_gsettings_backend.so comes from?18:28
=== ximion-afk is now known as ximion
seb128ian__605, you should get an apport prompt leading you to report a bug when that happens...18:30
ian__605The user gets one sometimes, but since it originated with my app, it goes to me (or would if it wasn't a ppa)18:31
seb128well; it's up to you to get the infos and report the bug then I guess18:31
seb128for what we know it could be a bug in your ppa and not in Ubuntu18:31
cjwatsonpitti: Oh, whoops, I see the bug18:33
=== Ursinha is now known as Ursinha-afk
ian__605seb128, Right.. so how would I figure that out?18:33
seb128ian__605, dunno, it's your ppa, you should know what you have in there and if it's likely to create such issues?18:34
cjwatsonpitti: For some reason the patch I uploaded didn't match the one I attached upstream18:34
seb128ian__605, getting a stacktrace would be useful in any case18:34
cjwatson(missing = NULL)18:34
ian__605seb128, I've got the stacktrace here: https://launchpadlibrarian.net/129813827/_opt_extras.ubuntu.com_drawers_bin_drawers.1000.crash18:35
infinityseb128 / tedg: More hung builds on the buildds, I thought you were going to keep that disabled until it was fixed. :/18:35
seb128tedg, ^ can you get those builds disabled until the issue is resolved?18:35
ian__605My app uses gsettings to store some configuration. It also uses python-compizconfig to get some info on settings18:36
tedgYeah, I'll try to figure that out.  Almost done with a fix.18:36
ian__605seb128, app sets up ok, but once the Gtk.main() is called it crashes. Again, it's just once-in-a-while and I can't reproduce on my system18:37
seb128ian__605, sorry, I'm not familiar with that codebase, best is to get a debug stacktrace and file a bug and see what the compiz guys say18:38
cjwatsonpitti,seb128: uploaded a corrected fix18:38
seb128cjwatson, great, thanks ... I will install the deb once it's on launchpad to confirm if that version is working for me18:38
cjwatsonhallyn: Yeah, looks like it's better at the moment because qemu-user-static_i386 doesn't ship /usr/share/binfmts/qemu-x86_6418:39
=== Ursinha-afk is now known as Ursinha
cjwatsonhallyn: Of course, this means that for people running an i386 kernel, they don't get automatic x86_64 emulation, so it's just moved the bug around :-)18:40
cjwatson(Well, assuming that's possible - maybe it isn't)18:40
infinityIt's possible.18:40
infinityBut painfully crap.18:41
hallyncjwatson: ok - i wonder if we'll be seeing a bug about restoring that emulation18:41
hallyncjwatson: thanks for checking!18:41
hallyncjwatson: so do you prefer that we postpone binfmt namespace discussions  until next cycle?18:42
cjwatsonhallyn: It's no particular rush for me18:43
cjwatsonAnd bazillion other things to do as usual, so as you like :)18:43
hallyncjwatson: yeah at this point it seems liek finishing up started items is more important18:43
hallyncjwatson: i'll re-raise it next cycle, thanks :)18:44
hallynsmb: ^18:44
smbhallyn, ok, thanks18:44
cjwatsonCertainly from my point of view it's been a problem since <=2000, so, you know, what're another couple of years18:45
hallyncjwatson: hopefully only a few more months! :)18:47
smbhallyn, In my optimistic ways I hope to have at least done a bit more preparation (research) work until for the next discussion...18:49
hallynsmb: I still think it'll have to start with my coaxing cjwatson to write the detailed namespace motivation (first WI int he blueprint)18:51
hallynoh well - lunch - bbl18:51
smblate enough for me - bbml :)18:52
=== Ursinha is now known as Ursinha-afk
barry@pilot in19:03
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
rtgcjwatson, upower_0.9.19-1ubuntu2 appears to have fixed my problem19:04
cjwatsonrtg: ubuntu3 should too19:06
cjwatsonmy own stupid fault, I evidently misapplied the patch by hand rather than applying the one I'd sent upstream19:06
rtgcjwatson, , thats the I really meant to build. drat.19:07
cjwatsonbecause it was short enough that I couldn't possibly get it wrong, right?19:07
dobeyslangasek and stokachu: would you care to check out my patch on https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/859600 ? xnox already looked at it, but said he'd prefer one of you to look at it as well, as you've had issues with doing this in gnome-keyring before19:36
ubottuUbuntu bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress]19:36
seb128dobey, sorry about that one, you pinged me about it but I also decided it would be better if some of the multiarch gurus had a look ;-)19:46
=== glebihan_ is now known as glebihan
=== andyrock is now known as andyrock|window
=== andyrock|window is now known as andyrock|dinner
stokachucjwatson: if a precompiled driver exist on an external source as a udeb that driver should be copied over to the existing target or does the installer rebuild the initrd?20:37
cjwatsonstokachu: nothing is copied out of the installer environment to the target.  the installer rebuilds the initrd; any driver that's to be on the target system must be available as a deb20:39
stokachucjwatson: so providing a udeb to the installer should make that driver available after installation and a reboot correct?20:41
infinitystokachu: No, that's the exact opposite of what he said. :)20:44
xnoxudeb makes that driver available during installation, you need a deb on top to make it available in the target / post-install.20:45
infinitystokachu: udebs are only available to the installer itself.20:45
stokachuah i see20:45
xnoxstokachu: e.g. if that driver is need both during install & in the final system, one needs both .deb & .udeb.20:45
stokachuah ok that makes sense now20:46
xnoxthere should be some examples in the archive of how to package that (e.g. duplicate the driver into two package)20:46
stokachuyea ive been looking for some documentation on that20:46
xnoxstokachu: also note the ModAliases feature that packages can declare for ubuntu-drivers-common to auto-install relevant .deb for you.20:46
xnox(e.g. any nvidia package)20:46
xnox.udeb drivers are typically ethernet/wifi cards20:47
infinityAnd filesystem and storage drivers.20:47
infinityAnd other stuff.20:47
stokachuhah ok20:48
infinitystokachu: But, yeah, if it's not vital to perform the install, you don't want a udeb at all.20:48
infinitystokachu: You want a deb, ideally a dkms package.20:48
stokachuthis is a storage driver to detect during install and after20:48
=== Ursinha-afk is now known as Ursinha
stokachuit detects during installation but im missing the second part for the target system20:49
stokachuif i've emailed an uploader about merging a new version of their package how long should i wait for a response?20:56
stokachuthe latest aptitude won't run its google mock tests without a newer google-mock package20:56
infinitystokachu: We seem to be up to date with Debian already.20:59
infinitystokachu: Unless their packaging had bugfixes you need.20:59
stokachuthere seems to be some differences in our package compared to debian's21:01
stokachui ran a test build of aptitude in sid against their google-mock and it ran the tests successfully21:02
stokachuwith raring it fails to find gtest21:02
stokachuim still going through the changes to see what may be inconsistent21:04
stokachulooks like we allow make install to proceed where debian does not21:10
stokachuim guessing other software is still dependent on the previous way google-mock worked before the recommendation was to include during each application build21:11
xnoxstokachu: well in ubuntu, it looks to me like we have an aptitude patch that turns off building/running google-mock tests21:15
stokachuxnox: yea in but i was attempting to merge in and re-enable google-mock since it landed in main21:15
xnoxI see.21:15
=== Ursinha is now known as Ursinha-afk
bryceslangasek, btw on SRU #1078290 the driver got moved to -updates but there's a jockey fix that goes along with that update, which has to be rolled out as well; otherwise the driver won't install properly22:11
bryceslangasek, I've tested jockey 0.9.7-0ubuntu7.7 along with the fglrx-experimental-9 update and verified that combination installs and boots fine22:12
=== salem_ is now known as _salem
slangasekbryce: right, but the jockey in -proposed is currently awaiting verification of a different bug22:15
slangasekoh, /was/22:15
slangasekI guess we can move that too then22:15
infinityIt doesn't hurt anything to have the driver preceed jockey, does it?22:15
bryceslangasek, Sarvatt verified it22:16
slangasekinfinity: indeed not22:16
brycethe kernel module will display in jockey prior to the jockey update22:16
bryceif the user attempts to install that, then they get half a driver, and thus a busted system22:16
bryceso I generally prefer to see the jockey changes go in first, then the driver update22:17
slangasekdobey: I haven't built the package, but the source diff looks sane to (gnome-keyring)22:17
slangasekbryce: ah - ok, then I'll get that published22:18
xnoxstokachu: right so aptitude's configure.ac is at fault here. It says if I can link mock, I don't need to build neither mock nor gtest. Which is not true in ubuntu currently as one has to still build gtest. It would be better if aptitude configure.ac checked mock & gtest separately whether to build none, one or both.22:18
brycein the jockey dialog, this situation shows up when you see the driver listed as "Experimental blah blah" rather than "AMD/ATI blah blah (**experimental**)...", which I notice is what is happening presently if you have only -updates22:18
xnoxstokachu: I have a crude fix to override this behaviour, by hardcoding BUILD_LOCAL_GMOCK to true.22:18
bryceslangasek, thanks22:19
dobeyslangasek: thanks. i've built it in my PPA, and have been running with the packages installed for some time now (on amd64 with the i386 p11kit bit installed as well)22:19
=== yofel_ is now known as yofel
JanCif any of you are coming to FOSDEM, please put your names on https://wiki.ubuntu.com/Fosdem/2013  ☺22:36
mlankhorstIt's really tentative for me22:37
mlankhorstno longer sure I'm going since the train from amsterdam to brussel has been cancelled :(22:37
JanCmlankhorst: there is a train between Roosendaal & Antwerp, which means you get 2 changeovers, but you should be able to get there  ☺22:40
mlankhorst2 additional changeovers22:40
mlankhorstits groningen->schiphol->rotterdam->roosendaal->antwerp->brussels22:40
JanCor you use the Thalys, if you are rich enough...22:40
JanCmlankhorst: or try to find a ride with someone else?22:41
mlankhorststartpoint is groningen, good luck :/22:41
JanCwell, if you can get a ride from Amsterdam or so, that would help a lot too, I suppose?22:42
JanCmlankhorst: I also asked in #debian-nl (on OFTC), maybe somebody there can help22:48
mlankhorstI might be getting a car though22:48
JanCwell, at least they don't expect the weather we got last year  :p22:49
JanC(last year I had to bring the Ubuntu mobile multiseat to FOSDEM during a snow storm on Friday)22:51
mlankhorsti was stuck for 7 hours in a car for what should have been a 2.5 hour trip to eindhoven22:55
* ogra_ will probably come but decide spontaneous based on the weather22:57
ogra_(i'll drive)22:58
TheMuso@pilot in23:00
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry, TheMuso
barryhi TheMuso.  perfect timing :)23:01
barry@pilot out23:01
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
=== Ursinha-afk is now known as Ursinha
jbebelWhat/where is the list of packages which are supported as part of 12.04 LTS?23:05
jbebelI remember there used to be a file that listed them specifically, but I can't seem to find it now.23:06
jbebelIt was fewer than just those in main, especially when the LTS was reduced to just server.23:06
jbebelbut that was for dapper, I think that I'm remembering.23:07
ScottKDefine "supported"23:07
ScottKIt can mean multiple things.23:07
jbebelThe S in LTS.23:07
TheMusobarry: Heh cool. I often wonder whether you just forget to do that... :p23:07
jbebelHow does canonical define it?23:07
barryTheMuso: sometimes i do! :)23:08
jbebelI expected it meant security updates are provided.23:08
ScottKThere's a field in LP that says.23:08
ogra_didnt we have a tool ?23:08
ScottKFor 12.04 it's somewhat complex since some desktop packages are supported for 5 years too.23:08
ogra_supported-in-ubuntu or so ?23:08
ogra_or was that only seeded stuff23:09
ScottKWe do have seeded-in-ubuntu.23:09
ogra_ah, then i mixed it up23:09
sarnoldis that the Supported: line in apt-cache show <packagename> ?23:10
jbebelI'm guessing it's at least a subset of main, not a superset.23:10
JanCogra_: the expected weather seems fine  http://www.yr.no/place/Belgium/Brussels/Brussels/long.html  ☺23:11
xnoxsarnold: depends on the value in the support field.23:11
ogra_JanC, well, its the weather inbetween :)23:11
ogra_if i arrive in brussels i wont be much outside anyway :)23:12
ScottKjbebel: It is a subset.23:12
ScottKsarnold: Yes.  That's what I was thinking of.23:13
sarnoldjbebel: I think from 12.04 LTS on, the idea is we'll support main/ for five years: https://wiki.ubuntu.com/Releases23:14
slangasekogra_, ScottK: "ubuntu-support-status"23:14
ogra_ah, i knew there was something !23:15
sarnoldjbebel: (at least, I haven't seen an equivalent to the hardy-supported.txt yet)23:15
matttbeJanC: yes, I confirm that the weather is fine (much better than the week before ;) )23:15
ScottKjbebel: ^^^ see slangasek's remark.23:15
ScottKslangasek: Thanks.  I didn't know about that one.23:16
sarnoldScottK: thanks :)23:16
JanCmatttbe: if you come --> see the wiki page  ;)23:16
sarnolderr, slangasek thanks, rather :) hehe23:16
JanCmatttbe: last year we had to drive through 15cm of snow in some places (first with my personal car, then with the van with the multiseat system), that was worse than anything we've had this year, I think23:18
matttbeJanC: yes I remember :) And it was very hot in some classrooms!23:19
* xnox is 75.0% supportable and 1.2% no longer downloadable23:19
jbebelThanks everyone.23:19
=== matttbe_ is now known as matttbe

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!