[15:00] <ev> Hi guys.
[15:00] <ev> Steve is off today and has asked me to step in.
[15:00] <ev> #startmeeting
[15:00] <meetingology> Meeting started Wed Jul 31 15:00:37 2013 UTC.  The chair is ev. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[15:00] <ev> [TOPIC] Lightning round
[15:00] <ev> $ echo $(shuf -e barry doko stgraber jodh ev cjwatson xnox)
[15:01] <ev> stgraber xnox cjwatson doko ev barry jodh
[15:01] <doko> slangasek not here?
[15:01] <cjwatson> He's at the Isle of Man client sprint and unavailable
[15:02] <stgraber> xnox: I'm on vacation, so it's your turn
[15:02] <ev> oh right, apols :)
[15:02] <xnox> * Last week wed-sun was on holiday
[15:02] <xnox> * From the week before, android and blobs are packaged and uploaded
[15:02] <xnox>   into ubuntu universe.
[15:02] <xnox> * M.I.R. for above is filed, and in-progress (need to answer security
[15:02] <xnox>   enquiries).
[15:02] <xnox> * TODO: automate "binNMU"/daily building of android package (such that
[15:02] <xnox>   I'm not the only one who can/knows how to upload it)
[15:02] <xnox> * Working on sorting out btrfs mounting/fsck once and for all & get
[15:02] <xnox>   btrfs in sync between Debian & Ubuntu. Should be fine with -5
[15:02] <xnox>   update.
[15:02] <xnox> * Working on sorting out ubiquity: outstanding merge proposals & U1
[15:02] <cjwatson> xnox: Ah, you sorted out your internet troubles then
[15:03] <xnox>   login page.
[15:03] <xnox> * Verified pending-removal SRU bugs for mdadm & partman-lvm
[15:03] <xnox> * Trying to help resolve bug 1197766, initially provided workaround
[15:03] <xnox>   was not sufficient
[15:03] <xnox> ..
[15:03] <xnox> stgraber: touche =) i was out last week ;-)
[15:03] <xnox> cjwatson: yes. they trigger full line resynchronisation via automated telephone option selection. Which got my line back up.
[15:04] <xnox> so was only a short down-time <<30minuts.
[15:04] <cjwatson> Release engineering sprint.  Spent most of the second half of the week implementing build cancellation:
[15:04] <cjwatson>  - https://code.launchpad.net/~cjwatson/launchpad/buildstatus-aborted/+merge/176990
[15:04] <cjwatson>  - https://code.launchpad.net/~cjwatson/launchpad-buildd/fix-abort/+merge/177003
[15:04] <cjwatson>  - https://code.launchpad.net/~cjwatson/launchpad/buildmaster-cancel-properly/+merge/177580
[15:05] <cjwatson>  I'm still awaiting some reviews and will probably need to make some changes, but the bulk of it is done.
[15:05] <cjwatson> foundations-1305-click-package:
[15:05] <cjwatson>  - Various minor tweaks to prepare for the IoM demo.  Bug 1204523 was especially entertaining to fix.
[15:05] <cjwatson>  - Fixed rather embarrassing Unicode support failures.
[15:05] <cjwatson> foundations-1305-arm64-bringup:
[15:05] <cjwatson>  - Bent juju-core to my will to bootstrap a new build farm, after the Canonistack LCY02 instance-deletion instance.
[15:05] <cjwatson>  - Tried to get some saucy builds working.  Currently blocked on some tail-ends of toolchain rebootstrapping, but should be able to start helping out again soon.
[15:05] <cjwatson> ..
[15:05] <doko> - arm64 bootstrap (later more)
[15:05] <doko> - MIR's
[15:05] <doko> - binutils update
[15:05] <doko> (done)
[15:06] <ev> - I've spent much of the week continuing to get mobile error reporting up and
[15:06] <ev>   running. We now have whoopsie and apport on the Touch images as well as a
[15:06] <ev>   settings page for controlling reporting. I have a meeting later this week
[15:06] <ev>   with Katherine to discuss enabling reporting by default.
[15:06] <ev> - I've run into what looks like a race condition on whoopsie startup on the
[15:06] <ev>   Touch images, which prevent it from uploading reports. I'm taking the
[15:06] <ev>   opportunity to build some more tests into things like whoopsie-preferences
[15:06] <ev>   (hooray for dbus-test-runner, by the way) as I get to the bottom of this.
[15:06] <ev> - Work continues on the Cassandra crisis. You may have noticed that
[15:06] <ev>   https://errors.ubuntu.com is only showing data from the past week or so. We
[15:06] <ev>   had to cut over to a new database. Nothing is lost. We're backing up the old
[15:06] <ev>   database and will merge in the data when that is complete. If you don't
[15:06] <ev> UGH. Die pidgin.
[15:06] <ev> right, https://pastebin.canonical.com/95283/
[15:06] <ev> done!
[15:07] <barry> ev: i don't use dbus-test-runner, but i managed to finally track down a very interesting (and annoying) behavior in the underlying dbus libraries ;)
[15:07] <ev> errr http://paste.ubuntu.com/5933046/ :)
[15:07] <barry> image based updates: LP: #1206515; LP: #1206558; LP: #1206523; LP: #1204528; LP: #1204976; various dbus api changes for better u/i integration; upload 0.9, 0.9.1, 0.9.2
[15:07] <ev> barry: oh?
[15:07] <barry> other: LP: #1073919; LP: #1205505; LP: #1181814; python-webob 1.2.3-3 (py3 support) and 1.2.3-4, debian bug 717655; PEP 394 (shebang lines); emacs 24.3 bug fix and upload; python-coverage review
[15:07] <ev> ah nice
[15:07] <barry> in progress: LP: #1206866, system-image 0.9.3
[15:08] <barry> ev: yeah, so i use $DBUS_SYSTEM_BUS_ADDRESS envar to rendezvous on a private bus...
[15:08] <barry> turns out that once libdbus is intiialized, it never consults that envar again
[15:08] <cjwatson> How did the image-based-updates demo go?
[15:08] <ev> ha!
[15:09] <barry> so you can't change it and expect the same process to rendezvous on a different bus address
[15:09] <barry> cjwatson: mixed i think.  they got some weird bug that i don't understand at all but eventually got it to update and reboot
[15:09] <barry> cjwatson: and of course it wfm here locally :/
[15:09] <cjwatson> All the best bugs are like that
[15:10] <barry> cjwatson: anyway, that's LP: #1206866, ongoing
[15:10]  * barry is very happy that phablet-flash now allows --ubuntu-bootstrap and -r -2
[15:10] <cjwatson> (Oh, I forgot to mention, I'm also working on implementing the "devel" series alias for saucy)
[15:10] <barry> (allows you to flash to an older image)
[15:10] <barry> cjwatson: nice
[15:10] <barry> anyway...
[15:10] <barry> done
[15:10] <ev> :)
[15:10] <ev> [TOPIC] Bugs
[15:10] <ev> No Brian.
[15:10] <xnox> ev: paste.canonical.com instead of paste.ubuntu.com ? not using pastebinit? =)
[15:11] <ev> Does anyone have bugs worth a mention?
[15:11] <ev> xnox: that would've been the smart thing to do
[15:11] <jodh> erm, shall I go at the end? :)
[15:11] <ev> OH HAI
[15:11] <ev> jodh: you're up
[15:11] <cjwatson> Steve asked me to get back to bug 1065281, so I'm going to have to roll up my sleeves again on that :-/
[15:11] <ev> soz. I copy and pasted from when you weren't here :)
[15:11] <cjwatson> But nothing interesting to talk about as yet
[15:11] <jodh> * foundations-1305-upstart-work-items:
[15:11] <jodh>   - Finished the upstart-dconf-bridge and raised MP:
[15:11] <jodh>     https://code.launchpad.net/~jamesodhunt/upstart/upstart-dconf-bridge/+merge/177650
[15:11] <jodh>   - Upstart integration tests (DEP-8):
[15:11]  * ev nods
[15:11] <jodh>     - Updated python Upstart test module and resubmitted MP:
[15:11] <jodh>       https://code.launchpad.net/~jamesodhunt/upstart/python-upstart-module/+merge/157549
[15:11] <jodh>     - Spent remainder of time working on DEP-8 scripts to make use of
[15:11] <jodh>       nested pristine VM which will be provided by autopkgtest
[15:11] <jodh>       environment. Attempted to use NBD to mount VM disk and configure
[15:11] <jodh>       in chroot but requires too many hacks. Plan is now to boot VM, ssh
[15:11] <jodh>       in to configure it, reboot, then run tests, but use NBD to collect
[15:12] <jodh>       results data (ongoing).
[15:12] <jodh> * upstart:
[15:12] <jodh>   - upstart-text-bridge simplified (local sockets only), renamed to
[15:12] <jodh>     upstart-local-bridge and MP raised:
[15:12] <jodh>     https://code.launchpad.net/~jamesodhunt/upstart/upstart-local-bridge/+merge/177027
[15:12] <jodh>   - Investigated bugs 1205443 and 1202287 and merged the branch below that
[15:12] <slangasek> doko: mostly not here, no
[15:12] <jodh>     will hopefully resolve the issue:
[15:12] <jodh>     lp:~jamesodhunt/upstart/quiesce-cleanup-fix
[15:12] <jodh> * misc
[15:12] <jodh>   - debconf/LPC presentation: ongoing updates.
[15:12] <jodh> Ử
[15:12] <ev> [TOPIC] arm64 bootstrap
[15:12] <barry> ev: i finally got fixed a looooongggg standing emacs bug that was annoying the crap out of me for years :)
[15:12] <ev> Steve asked doko to bring us up to speed on the arm64 bootstrap
[15:12] <ev> With that, I yield to doko :)
[15:13] <ev> barry: :D
[15:13] <doko> Aarch64 bootstrap - how we did start ...
[15:13] <ev> was the fix to use Vim instead?
[15:13]  * barry is not amused
[15:13] <ogra_> instead ??
[15:13] <doko> (just waiting between my pastes ...)
[15:13] <doko> - Start with armhf. It's in the archive, we know that it does build (or not).
[15:13] <doko> - Build an armhf buildd chroot entirely with cross-built packages
[15:13] <doko> - Use staged builds (DEB_STAGE=stage1) to break cyclic dependencies, or not to build unnecessary/unbuildable binary packages.
[15:13] <doko> - Make sure that the cross-built chroot is usable.
[15:13] <ogra_> the fix always involves vim ... no matter what fix :P
[15:14] <doko> - Build and package the Aarch64 cross toolchain
[15:14] <doko> - Start the cross build again, targeting Aarch64
[15:14] <doko> - Fix Aarch64 specific bugs during that cross-build
[15:14] <doko> - Finally had a build chroot + debhelper available (April)
[15:14] <doko> - Make sure that it works using the foundations model (simulator).
[15:14] <doko> - Building gnu-hello takes over an hour.
[15:14] <doko> we got to this state in April
[15:15] <doko> - During saucy ... start building native packages (with nocheck enabled).
[15:15] <doko> - Build with nocheck. Good enogh if the package builds and can be used as a b-d
[15:15] <doko> - We don't have any sbuild or dep-wait information, so set a goal to build a package. Starting with ... you guess it ... the toolchain.
[15:15] <doko>   - For warming up, binutils
[15:15] <cjwatson> Turns out we've built the toolchain several times ;-)
[15:15] <cjwatson> I think of it as a stress-test of "Reflections on Trusting Trust"
[15:15] <doko>   - Build-depends: bison, flex, gettext, texinfo, dejagnu,  quilt, file, xz-utils, lsb-release, zlib1g-dev
[15:15] <doko>   - Identify the b-d's which are only needed for running the tests. Here: dejagnu
[15:15] <doko> cjwatson, not just the toolchain =)
[15:16] <xnox> if gnu-hello takes over an hour, gcc 3 stage bootstrap took... weeks?!
[15:16] <doko>   - Next eglibc .. b-d: libaudit-dev
[15:16] <cjwatson> (http://cm.bell-labs.com/who/ken/trust.html in the unlikely event anyone hasn't encountered it)
[15:16] <doko>     ... audit: b-d: libkrb5-dev, libldap2-dev, libprelude-dev, and finally systemd
[15:16] <doko>     crap, maybe we come back later ...
[15:16] <doko>   - Next gcc ... easy as binutils
[15:16] <doko>     ... wait, except for gcj and needing gtk+2.0 ...
[15:17] <doko>   - There are a lot of cyclic dependencies in the gtk stack.
[15:17] <doko>     - Often not clear which ones are only used for testing.
[15:17] <doko>     - gtk b-d's on cups, so disable
[15:17] <doko>     - disable udeb builds, halfs the build time
[15:17] <doko>   - Ok, now gcc did build
[15:17] <doko> - Next target: build LAMP ...
[15:18] <doko>   Break it down:
[15:18] <doko>   - build reduced build tools (cmake, doxygen without Qt)
[15:18] <doko>   - build reduced openldap, krb5, heimdal
[15:18] <doko>   - build reduced avahi
[15:18] <doko>   - build databases postgres and mysql (without krb, heimdal)
[15:18] <doko>   - build krb5, heimdal
[15:18] <doko>   - build cyrus-sasl2
[15:18] <doko>   - build apache
[15:18] <cjwatson> The object of the exercise of course is to get to the point where we can start normal-ish autobuilds as quickly as possible.  Did I hear correctly that we are at the point of being able to self-host sbuild soon?
[15:18] <doko>   - build php5
[15:18] <doko> - Any volunteers to test if that actually works?
[15:19] <cjwatson> Hm.  I'm slightly surprised we're doing LAMP in stage1.  I thought that was a stage2 target, or even something we'd want to push for early once we have builds in Launchpad
[15:19] <doko> well, busted1.53 did fail to build twice, and took the simulator down
[15:19] <cjwatson> Of course the bits that involve circular build-deps are worth doing in stage1
[15:19]  * xnox giggles at busted1.53
[15:20] <doko> it's systemd, audit and things like that needing the crypto stuff, and the crypto stuff the database stuff
[15:20] <doko> so if sbuild can use dchroot, fine, else we need schroot first
[15:20] <doko> - A lot of packages have b-d's for documentation builds not in build-indep ... these should be fixed.
[15:20] <doko> - Finally I had to build texlive-bin. Running dh_autoreconf on 60+ configuries takes more than three days ... I start hating it.
[15:20] <cjwatson> I don't believe it can
[15:21] <cjwatson> dchroot is fairly dead except for the version built out of schroot
[15:21] <doko> have to finish my other builds before I give it a try. but it's the last package
[15:21] <doko> - And now we can build eglibc ...
[15:21] <doko> - Not the only cycles. In a lot of cases you have to see where it is the easiest way to break a cycle. Don't touch "uncommon" build systems.
[15:21] <doko> - Next steps: Get build-deps for qt4-x11 ready (almost done)
[15:21] <doko>   - gstreamer (avoid gsl), gst-plugins (avoid external plugins)
[15:22] <doko> - Have a look at gtk+3.0 (install failure, don't understand it)
[15:22] <doko> - Have a look at the sound stack (pulseaudio, alsa, bluez)
[15:22] <doko> - Have a look at the video stack
[15:22] <doko> - Have a look at guile. The built interpreter doesn't terminate
[15:22] <doko> - Ocaml not yet ported, looks like other distros are working on that
[15:22] <doko> - How to build initramfs (klibc isn't yet ported, only used by Debian/Ubuntu)
[15:22] <doko> - Have a look at https://bugs.launchpad.net/linaro-aarch64
[15:22] <doko>   Help: How do identify both open and closed bugs, which either
[15:22] <doko>   don't have a distro task, or have an open distro task?
[15:22] <doko> - Get dep-wait information for packages without trying to build them
[15:22] <doko>   Just takes too long ...
[15:22] <doko> - Setup a sbuild which rebuilds already built but out-of-date packages
[15:22] <cjwatson> doko: Looked at edos-distcheck?
[15:22] <slangasek> doko: gtk+3.0> what fails to install?
[15:22] <cjwatson> That's what Debian's wanna-build uses
[15:22] <doko> not yet, chdist didn't work
[15:23] <cjwatson> chdist should work given that all sbuild is doing is an apt-get invocation
[15:23] <doko> slangasek, this is strange, I'll post the build log once it finishes again
[15:23] <cjwatson> And all chdist does is set up apt to look at different sources
[15:24] <xnox> doko: i'd also like to see gtk+3.0 fail to install errors / log.
[15:24] <doko> right, but it couldn't handle the saucy archive with the [armhf] identifier
[15:24] <doko> so the other blocker is guile (and we need it for autogen)
[15:24] <doko> - About packaging ...
[15:24] <doko>   - Unneeded build-deps, or ones which should be in build-indep
[15:24] <doko>   - shell script like makefiles (configure & build in one target)
[15:24] <doko>   - no support for parallel builds
[15:24] <doko>   - no support for staged builds
[15:24] <cjwatson> Still odd, since it doesn't parse sources.list itself :)
[15:25] <cjwatson> You might need to set APT::Architecture and/or APT::Architectures in the chdist environment's apt.conf
[15:25] <doko> I can give it a try later, I didn't care that much at the moment
[15:25] <doko> - About using the simulator:
[15:25] <doko>   - Crashes sometimes, having to restart builds
[15:25] <doko>   - The time is slower in the simulator. Uploading a package to saucy, then trying to build it has interesting effects (generated files are older than the one in the package).
[15:26] <doko> would love to install ntp, but that b-d's on autogen ...
[15:26] <cjwatson> I was about to say :)
[15:27] <doko> so, that's it what I did prepare ...
[15:27] <ev> thanks doko
[15:27] <slangasek> doko: how much is still being cross-built right now, vs. built under emulation?
[15:28] <doko> slangasek, for stage1 now nothing. but we didn't re-build cross-built packages from stage0 yet
[15:28] <doko> just when I noted issues, like the cross-built bash missing job control
[15:28]  * slangasek nods
[15:28] <ev> [TOPIC] AOB
[15:28] <ev> anything else?
[15:29] <cjwatson> We're keeping things reasonably separate between stage0 and stage1, but I'm working on a saucy-stage0 at the moment to see if I can make some cycles a bit easier to break
[15:29] <slangasek> brief update from the sprint? :)
[15:29] <cjwatson> (Since the raring-stage0 generally didn't use its own output to build, so it's only the first layer in a lot of cases)
[15:29] <ev> go for it :)
[15:29] <barry> slangasek: please!
[15:29] <slangasek> so click packages and system updates were both demoed this week
[15:30] <slangasek> the click package demo went off without a hitch (beuno clearly spent more time rehearsing than I did)
[15:30] <slangasek> very well-received
[15:30] <slangasek> and very close to being ready to go live, which is exciting
[15:31] <slangasek> the system updates demo had a few problems, but everything did come together well all things considered
[15:31] <cjwatson> beuno was doing little else but rehearsing from about last Wednesday :)
[15:31] <slangasek> and I've done several real upgrades through the UI, the code really does work :)
[15:31] <slangasek> so kudos to everyone who was involved in those two big pieces of work
[15:32] <ev> well done, guys
[15:32] <slangasek> everyone here is also happy to have whoopsie landed on the images
[15:32] <slangasek> though I've just noticed that with the system images, /var/crash is read-only, so we have some more fixing to do there ;)
[15:32] <ev> ha!
[15:32] <ev> Zarro boogs found.
[15:32] <slangasek> but the unity team are eagerly awaiting having their crashes recorded
[15:32] <ev> That's good to know.
[15:33] <slangasek> and there's pent-up demand for both the upstart android bridge and package cross-build support (a few more packages needed to support before it meets the team's needs)
[15:33] <slangasek> so they're chomping at the bit
[15:34] <slangasek> in short: you guys are all doing great work, which is greatly appreciated by the rest of the team
[15:34] <slangasek> so keep it up :)

[15:35] <ev> slangasek: if you see someone responsible for the current touch experience, spawn an app and then SIGSTOP it for me
[15:35] <ev> then tell them to use the launcher
[15:35] <ev> I've sent a mail to phablet about it
[15:37] <slangasek> ev: this demos a bug I suppose, with the launcher locking up?
[15:37] <ev> slangasek: if an application hangs, there is no way out
[15:37] <ev> all input seems to be channelled through the foreground application
[15:37] <ev> #endmeeting
[15:37] <meetingology> Meeting ended Wed Jul 31 15:37:52 2013 UTC.
[15:37] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-07-31-15.00.moin.txt
[15:37] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-07-31-15.00.html
[15:37] <slangasek> ev: ok; fwiw that's probably not worth following up on, since the switch to Mir is coming RSN
[15:37] <ev> thanks guys!
[15:38] <barry> thanks ev! and thanks slangasek for the update
[15:38] <ev> slangasek: yes, I was careful to ask if this would be a problem in Mir in th email
[15:38] <jodh> thanks!
[15:38] <ev> I tried to get it running on my nexus yesterday, but it sat on the bootloader image
[15:38] <slangasek> ev: it *might* be, but it's just not worth tracking that kind of process interaction bug at this stage
[15:38] <ev> and I only noticed that unity8 crashed by logging in and seeing a report in /var/crash for it \o/
[15:38] <slangasek> we should revisit once Mir lands
[15:38] <ev> slangasek: *nods*
[15:41] <slangasek> ev: impressive failure handling, though; when I restart the app again, the UI is now completely out of sync with the input layer :)
[15:41] <ev> lol
[15:41] <ev> I hadn't noticed that


[13:23] <zx2c4> DalekSec: alright, i guess this is apw territory then ^^^
[14:10] <zx2c4> DalekSec: https://salsa.debian.org/debian/wireguard-linux-compat/merge_requests/2
[14:10] <gitbot> Debian issue (Merge request) 2 in wireguard-linux-compat "postinst: remove bespoke error-prone auto-update mechanism" [Opened]
[14:11] <zx2c4> DalekSec: if dkg doesnt merge that in time, Ubuntu's focal package should take that before the 27th
[17:19] <apw> DalekSec: did you upload the merge?
[18:52] <DalekSec> apw: Yeppers.
[19:48] <zx2c4> apw: the 20200215 merge, but not https://salsa.debian.org/debian/wireguard-linux-compat/merge_requests/2 which you might consider applying in Ubuntu
[19:48] <gitbot> Debian issue (Merge request) 2 in wireguard-linux-compat "postinst: remove bespoke error-prone auto-update mechanism" [Opened]
[22:18] <DalekSec> Err, right.  That is correct, I just kept the current delta.


[00:42] <bcurtiswx> whats the easiest way to get what functions are called when performing an action in a program
[00:42] <bcurtiswx> say i open a new IM window in empathy, how do I find out what functions are called ?
[00:43] <penguin42> bcurtiswx: You trace it back or forward from something that you know must have happened
[00:44] <bcurtiswx> penguin42, so keep strace open, wait for it to stop then perform the action?
[00:44] <penguin42> bcurtiswx: So if it was a menu item that triggered it you'd look for the menu code and what ever registered the action for it; or you could go the other way, you could set a breakpoint at some function in gnome you know must have got called - e.g. whatever opens a new window
[00:44] <penguin42> bcurtiswx: strace is too low level really
[00:45] <penguin42> bcurtiswx: gdb and breakpoint on a function you expect to get called and then do a backtrace
[00:45] <bcurtiswx> OK
[00:45] <bcurtiswx> just 'break' in a c file ?
[00:45] <penguin42> yeh
[07:08] <pitti> Good morning
[07:08] <a3Dman> good morning
[07:08] <TheMuso> Hey pitti.
[07:09] <pitti> hey TheMuso, how are you?
[07:15] <TheMuso> pitti: Well thanks, yourself?
[07:23] <pitti> TheMuso: pretty well, thanks!
[07:27] <dholbach> good morning
[07:44] <didrocks> good morning
[07:46] <dholbach> salut didrocks
[07:46] <didrocks> hey dholbach
[09:31] <geser> pitti: Hi, as you dealt with hal in the past, is disabling the v4l code the right fix for the current hal FTBFS? (http://launchpadlibrarian.net/63796245/buildlog_ubuntu-natty-i386.hal_0.5.14-5_FAILEDTOBUILD.txt.gz)
[09:32] <pitti> geser: I filed bug 716275; if that is easy to do, I'd prefer that
[09:33] <pitti> geser: if not, I'd add a patch upstream to check if it is available and disable it in configure if not, and ask mbiebl to cherrypick it
[09:33] <geser> ok
[09:35] <alkisg> I've attached a debdiff for natty in LP bug #552404, is there anything else I need to do? The https://wiki.ubuntu.com/StableReleaseUpdates wiki page doesn't apply for development releases, right?
[09:37] <alkisg> So I can just re-subscribe ubuntu-sponsors?
[09:39] <persia> alkisg, Yes.  The sponsor will upload, and then the SRU process will resume.  Do you need something for maverick as well?
[09:39] <alkisg> persia: yes, but I don't have a maverick installation available for testing
[09:39] <persia> My understanding of lucid SRU is that there is an expectation of fix in natty and maverick first.
[09:40] <persia> alkisg, It's a chroot bug, right?  Do you have disk space to create a maverick chroot?
[09:41] <RAOF> pitti: /usr/include/linux/videodev.h is the header for the V4L API, which is entirely removed in 2.6.38 - we don't want to ship a header for code that can't work on Natty, do we?
[09:42] <alkisg> persia: I guess I could ask someone over in #ltsp to try it in maverick, to save me the time of creating a maverick chroot, since I won't ever be using maverick...
[09:42] <persia> alkisg, I've requested nomination for each release, which should make it easier to follow the correct status of SRU.  Needs someone to approve the nominations, but the sponsor will probably do that as well.
[09:42] <alkisg> Thank you :)
[09:42] <pitti> RAOF: ah, ok, good to know
[09:43] <persia> alkisg, Good luck!
[09:43] <pitti> RAOF: I'll patch hal upstream then
[09:43] <RAOF> pitti: The correct response is to port to V4L2 or, at a pinch, just disable V4L support.
[09:43] <RAOF> Given hal's tremendous utility, I'd guess disabling V4L support is the winning move :)
[09:44] <persia> Are there no devices that have V4L support, but not V4L2 support?
[09:44] <RAOF> persia: Not anymore, no.
[09:44] <pitti> RAOF: absolutely
[09:44] <persia> Cool!
[09:44] <RAOF> Well, not with 2.6.38, at least, because it doesn't support V4L at all :)
[09:45] <persia> heh.
[09:45] <RAOF> So there might now be some *unsupported* devices, but I don't know of any offhand.
[10:28] <pitti> geser: ok, fixed upstream; I'll talk to Michael now
[10:33] <ev> @pilot in
[10:34]  * dholbach hugs ev
[10:34] <dholbach> :-D
[10:34] <ev> google calendar ftw
[10:38] <apw> cjwatson, have you heard of any plymouth not working issues recently?  for example: bug #718044
[10:46] <cjwatson> apw: nothing new
[10:46] <cjwatson> apw: the last several updates to plymouth weren't mine, though
[10:48] <cjwatson> apw: ask soren
[10:48] <apw> cjwatson, will do thanks
[10:50] <soren> whuh?
[10:50] <soren> Oh, crap.
[10:50] <apw> soren, there is a bug about the latest plymouth affecting some people
[10:51] <apw> actaully ubuntu15 and up
[10:51] <udienz> cjwatson, is see in MoM that adduser need to merge, but an changelog says only undating translations. is aduser will be merge this time?
[10:51] <soren> ubuntu15 was  bit of a bust, but ubuntu16 should be fine.
[10:51] <soren> Darn it.
[10:51] <soren> I'm on it.
[10:51] <pitti> geser: pushed fix to Debian's hal svn; will wait for Michael to review/upload, though
[10:52] <cjwatson> udienz: we're after Debian import freeze, so merges are not a priority.  Is there a particular reason why we should pay attention to this merge?
[10:52] <apw> soren, there seems to be be little in the way of changes from the ubuntu14 which was claimed as working ... odd
[10:52] <cjwatson> udienz: the big merge push is in the first half of the release cycle, i.e. not now
[10:53] <udienz> cjwatson: ah ok.  i think is not, because only updating translation from debian.
[10:53] <lool> Ah
[10:54] <cjwatson> udienz: so just leave it, it'll happen in natty+1
[10:55] <lool> cjwatson: I've just seen util-linux gained armhf support in Debian and decided to merge it; in the merge, I ended up removing a lot of delta that I think we don't need anymore; do you mind these changes at this point?  Maybe it would be best if these got peer reviewed, I've pushed them as UNRELEASED to the UDD branch
[10:55] <lool> armhf support would be trivial to add on top of the Ubuntu package, but heck, I've merged it now  :-)
[10:55] <cjwatson> lool: what sort of things?
[10:56] <lool> cjwatson: upgrade snippets mostly
[10:56] <cjwatson> from pre-lucid?
[10:56] <lool> or diff which didn't add any value to us
[10:56] <lool> cjwatson: yes
[10:56] <cjwatson> I don't really care if we drop pre-lucid upgrade stuff
[10:56] <lool> http://paste.ubuntu.com/566915/
[10:57] <cjwatson> the stuff listed on https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/util-linux/natty seems generally fine
[10:57] <lool> cjwatson: I usually review the full debian -> ubuntu diff when documenting remaining changes; the longer it is, the more painful for me
[10:58] <lool> that's usually why I remove this stuff when I can, or to make maintainer scripts more readable
[10:58] <cjwatson> sure
[10:58] <soren> apw: Yeah. /me investigates
[10:59] <lool> cjwatson: Ok; will give it some testing now, and upload; thanks
[10:59] <apw> soren, the linked internally bug for the kernel seems to be reporting grub2 showing corrupted display ... so there may be a grub2 connection in part
[10:59] <cjwatson> none of that has changed recently
[11:00] <apw> cjwatson, yeah, the description is very hard to understand, i have requested much clarification on the linux bug
[11:00] <cjwatson> certainly not as recently as the plymouth changes mentioned
[11:11] <GunnarHj> ev: Hi Evan, do you have time to sponsor a couple of MPs? Both are linked to from https://launchpad.net/bugs/666565
[11:12] <ev> GunnarHj: I'll have a look
[11:13] <GunnarHj> ev: Great!
[11:20] <sivang> hi all
[11:20] <sivang> what's the relationship between Ubuntu and Linaro?
[11:20] <sivang> (ubuntu-mobile is closed and said to ask here)
[11:21] <persia> sivang: Complex :)
[11:21] <sivang> persia: complex?
[11:21] <sivang> persia: it is for armel yes?
[11:21] <persia> So, a number of folks involved in Linaro are also involved in Ubuntu.
[11:21] <sivang> does it use apt?
[11:22] <persia> Linaro has some goals (see www.linaro.org), and tries to accomplish them within Ubuntu, releasing things based on Ubuntu.
[11:22] <persia> So, from an Ubuntu perspective, Linaro just happens to be another project some folk are involved in.
[11:22] <persia> From a Linaro perspective (I'm guessing), Ubuntu is distribution project that is one of the targets for their efforts.
[11:23] <persia> Ubuntu supports armel, and tends to select the Linaro branches of tools to do so, because those tend to have the best performance on armel.
[11:23] <persia> But I don't believe there exists any single interface, or anything, which is why I say "complex".
[11:24] <sivang> so when I do linaro stuff I work .deb and can use ubuntun repos?
[11:25] <persia> Also, that's *completely* unrelated to ubuntu-mobile.  ubuntu-mobile was part of an effort to make Ubuntu better for highly mobile and embedded uses.  The consensus seemed to be that as the devices got better, it was more interesting to just deliver normal Ubuntu, than to try to make a special software stack.
[11:25] <persia> You'd do better to ask the linaro folk, but I believe so.
[11:26] <soren> apw: I think it
[11:26] <soren> s all me, actually.
[11:26] <soren> apw: I don't understand why at all, though.
[11:28] <soren> apw: the avoid-sigpipe patch causes it.
[11:28] <soren> apw: If I revert that, it works again
[11:28] <sivang> persia: thanks, makes sense.
[11:29] <soren> apw: It just don't understand. write(a,b,c) ought to be the same as send(a,b,c,0), but even that substitution causes it to fail.
[11:35] <cjwatson> soren: is 'a' a socket fd?
[11:37] <soren> cjwatson: Let's pretend the answer is "no".
[11:37] <soren> cjwatson: Just for giggles, let's say it's a pipe.
[11:37] <cjwatson> you can only use send() on sockets
[11:38] <soren> Ah.
[11:38] <soren> man send(2) is rather misleading, then.
[11:38] <soren> Darn it.
[11:38] <cjwatson> depends how you look at it
[11:39] <cjwatson> it does start "send a message on a socket"
[11:39] <soren> cjwatson: Is there any way I can get write() call to not SIGPIPE if the remote end of a pipe is closed?
[11:39] <cjwatson> I think "The only difference between send() and write(2)" is intended to be read as "(for sockets)"
[11:39] <soren> cjwatson: I thought changing it to send and passing MSG_NOSIGNAL would do the trick.
[11:40] <soren> And certainly it did in my tests, but they were using actual sockets :-/
[11:42] <cjwatson> I'm surprised it isn't a socket, actually.  ply_boot_client_connect calls ply_connect_to_unix_socket
[11:42] <soren> Alternatively, some way to reliably determine if an fd is a socket.
[11:42] <soren> I'm sure it is.
[11:43] <soren> It's probably just that other things are using the same routine with non-sockets.
[11:43] <cjwatson> ah
[11:43] <soren> ...which I hadn't expected, tbh.
[11:43] <cjwatson> yes, src/client/plymouth.c calls ply_open_unidirectional_pipe
[11:43] <cjwatson> and there are a couple of other calls
[11:45] <cjwatson> you probably get EBADF from send - you could just check for that and fall back to write
[11:45] <cjwatson> that would be OK
[11:45] <cjwatson> actually, you get ENOTSOCK
[11:45] <cjwatson> which is pretty clear
[11:46] <soren> Heh.
[11:47] <soren> cjwatson: Yeah, that's a good idea. I'll try that.
[11:56] <soren> cjwatson: So if this were a pipe, the only way to avoid being SIGPIPE'd is to flush the fd first and see if it's closed?
[11:57]  * soren reboots to check this new patch
[11:59] <soren> That seems to have done the trick.
[11:59] <cjwatson> soren: I guess so (or to ignore SIGPIPE, of course).  The pipe uses are all internal to plymouth though, so I don't think we need to worry about that
[12:00] <soren> cjwatson: Sure, I was just thinkin more gnerally.
[12:06] <persia> geser, DMB meeting?
[12:21] <PetrHH> Hello
[12:22] <PetrHH> I'm working on packaging my app to deb packages
[12:22] <PetrHH> but have no idea how to create menu entry after install
[12:23] <PetrHH> could anybody send me link to the how to? I'm not so successful with google
[12:23] <PetrHH> thank you
[12:23] <soren> PetrHH: Look at the .desktop files in /usr/share/applications
[12:25] <PetrHH> soren, Thank you!
[12:40] <soren> apw: Plymouth fix uploaded. Thanks for pointing it out. I've been watching the new bugs for plymouth, but it looks this this was filed as "confirmed" from the start.
[12:44] <soren> cjwatson: Thanks for your help on that, by the way.
[12:45] <cjwatson> np
[12:52] <PetrHH> soren, Where should I put application icon, please? I've found a lot of directories where e.g. f-spot.png icon is.
[12:52] <soren> I'm not entirely sure where it truly belongs.
[12:53]  * soren isn't a desktop person, really.
[13:23] <pitti> PetrHH: apps usually ship their "canonical" icons in /usr/share/icons/hicolor/
[13:25] <hallyn> slangasek: kirkland: so, where did we decide qemu-kvm-ppc64 belongs?  qemu-kvm, or qemu-user?
[13:26]  * hallyn objects to 'apt-get instlal tree' apparently having done an implicit 'apt-get dist-upgrade'
[13:27] <cjwatson> apt-get install never does an implicit dist-upgrade, but it may be necessary to upgrade other packages to fulfil dependencies.
[13:27] <cjwatson> I don't see why it would have done so for tree though.
[13:28] <hallyn> cjwatson: it even updated my firefox

[13:31] <hallyn> i dunno, this thing's package mgr must still be ina funky state.  it also refuses to install 2.6.38.  i may just need to reinstall
[13:33] <cjwatson> hallyn: it might have attempted to continue a previously incomplete upgrade
[13:33] <cjwatson> 'apt-get -f install' might be a good idea
[13:35] <hallyn> cjwatson: no, that didn't (and doesn't) seem to say anything other than about autoremove packages
[13:36] <hallyn> guess I'll try another rm -rf /var/cache/apt* and retry without apt-cacher again
[13:38] <kirkland> hallyn: qemu-kvm, as i recall
[13:38] <zyga> mvo, ping
[13:39] <zyga> mvo, do you have 3 minutes for a short brainstorm about dpkg?
[13:39] <hallyn> kirkland: that's what I had thought.
[13:40] <hallyn> kirkland: so should we reclasssify bug 717690 as against qemu-user ?
[13:45] <hallyn> kirkland: hm, so all of the arm-* patches should be removed from qemu-user, right?
[13:45] <hallyn> \o/
[13:47] <pitti> debfx: note that we already have python-gudev in the archive, which just like pyudev is obsolete
[13:47] <zul> @pilot in
[13:48] <kirkland> hallyn: should be fix released now
[13:48] <pitti> debfx: ah, sorry, it's libudev bindings, not libgudev; for the latter we have a GIR now
[13:48] <kirkland> hallyn: my last upload fixes that
[13:48] <pitti> debfx: ok, so ignore me :)
[13:48] <kirkland> hallyn: yes, all of the arm patches can go
[13:48] <hallyn> kirkland: you re-uploaded qemu-user?
[13:48] <kirkland> hallyn: no
[13:48] <kirkland> hallyn: qemu-kvm
[13:49] <kirkland> hallyn: we dropped that manpage from qemu-kvm (slangasek's patch)
[13:49] <hallyn> so you removed qemu-ppc64 from qemu-kvm?
[13:49] <hallyn> oh, it's the manpage!
[13:49] <hallyn> doh
[13:50] <hallyn> kirkland: at this particular moment, I'm down to two patches in qemu-kvm-0.14.0~rc1+noroms :)
[13:50] <kirkland> hallyn: rock
[13:50] <soren> No doko?
[13:50] <hallyn> kirkland: shoudl '~rc1' be in the name like that, btw?
[13:53] <soren> Maybe someone else can help me out.
[13:54] <ScottK> I thought he'd be back today (doko)
[13:56] <soren> ScottK: You might be able to help me with this, actually.
[13:56] <soren> Once upon a time, python-eventlet was built: https://edge.launchpad.net/ubuntu/+source/python-eventlet/0.9.13-0ubuntu1/+buildjob/2031930
[13:57] <ScottK> OK
[13:57] <soren> The build log from amd64 shows that the .deb ended up containing a bunch of things in /usr/lib/python2.7/dist-packages/eventlet/
[13:57] <soren> in addition to the expected stuff in  /usr/share/pyshared/eventlet/
[13:58] <soren> I just built a newer version earlier today that didn't end up with stuff in /usr/lib/python2.7/dist-packages/eventlet/
[13:58] <soren> ..this makes upgrades suck because there are leftover .pyc files in /usr/lib/python2.7/dist-packages/eventlet/.
[13:58] <ScottK> Where's the newer version?
[13:59] <soren> https://edge.launchpad.net/ubuntu/+source/python-eventlet/0.9.14-0ubuntu1/+buildjob/2261008
[13:59] <soren> I tried rebuilding the old source package, and this time I didn't get anything in in /usr/lib/python2.7/dist-packages/eventlet/ so it looks like there was a toolchain problem at some point.
[13:59] <soren> ...and I can't imagine I'm the only one having to deal with this fallout on upgrades.
[14:00] <seb128> soren, seems similar to the pywebkitgtk recent issues
[14:01] <seb128> soren, see the current upload of that one, the changelog has some details
[14:02] <soren> seb128: The one from about two weeks ago?
[14:02] <soren> Yeah, changelog entry sounds similar. Thanks.
[14:02] <seb128> soren, yes
[14:02] <seb128> soren, I think that was due to package rebuilt in natty when part of the python... didn't support 2.7 yet
[14:03] <ScottK> soren: I agree it was a problem with the 0.9.13 upload's toolchain.
[14:03] <seb128> soren, was the "buggy" version uploaded around the time python2.7 landed?
[14:03] <ScottK> Looks like it was.
[14:04] <seb128> soren, it's likely to be a similar issue, rebuilt at a time python2.7 was pulled it but part of the buildchain was not ready
[14:04] <soren> 2010-10-31 17:05:06 CET
[14:04] <ScottK> There was also a period where 2.7 was a supported version, but not all the helper tools had been updated to know about it yet.
[14:04] <soren> ScottK: Now that sounds like trouble.
[14:04] <soren> Uh, wrong timestamp.
[14:05] <seb128> soren, well, just add some code to clean it up on upgrade
[14:05] <soren> Yeah.
[14:05] <seb128> we should likely check what packages got rebuilt around this time
[14:05] <seb128> it's 2 of those which are spotted as broken now
[14:05] <seb128> we might have some other ones
[14:14] <ScottK> soren: I think seb128's suggestion is the right way.
[14:16] <ScottK> soren: Alternatively, I think switching to dh_python2 would also fix this as, IIRC, that's where it puts it's .pyc files.
[14:25] <soren> ScottK: I'll deal with dh_python2 some other day. :)
[14:25] <soren> ScottK, seb128: Thanks, guys!
[14:25] <ScottK> OK.
[14:26] <ScottK> barry: ^^^ It would probably be a good idea for someone to do a methodical search for other misbuilt packages.
[14:44] <mvo> ScottK: misbuild in what way? I may be able to help here (got a VM image with maverick->natty upgraded *python*)
[14:45] <ScottK> mvo: As soren and seb128 were discussing it looks like late Octoberish pysupport was installing files for python2.7 in the wrong place.
[14:47]  * mvo reads scrollback
[14:52]  * barry reads scrollback too
[15:17] <jelmer> zul: Thanks once again for sponsoring :)
[15:17] <zul> jelmer: no worries
[15:20] <kirkland> pitti: hey, are you still around?
[15:20] <pitti> hi kirkland
[15:21] <kirkland> pitti: i'm hoping there's an obvious fix for this ...
[15:21] <kirkland> pitti: been broken for me for 1 month now;  been hoping a magic update would just fix it
[15:21] <kirkland> pitti: i can't alt-tab to switch windows, resize windows, move windows, etc.
[15:21] <kirkland> pitti: this is natty gnome
[15:22] <kirkland> pitti: perhaps i'm missing a package?  or some configuration from day1 natty is not compatible with today?
[15:22] <pitti> kirkland: hm, that doesn't happen for me; seb128, didrocks, did you ever hear about alt+tab/resizing/moving windows being broken in natty?
[15:23] <pitti> kirkland: does it happen for a new user, too?
[15:23] <pitti> kirkland: that's usually the first litmus test whether it's package or config related
[15:23] <seb128> didn't read anything about that
[15:23] <pitti> I didn't see that either
[15:23] <seb128> kirkland, is that under unity or classic GNOME?
[15:23] <seb128> try to unity --reset maybe
[15:23] <pitti> kirkland: ok, so try with new user first, then let's bisect it todwn
[15:23] <pitti> down
[15:24] <pitti> seb128: "classic gnome"
[15:24] <highvoltage> pitti: that sounds like the start of a nercore rap :)
[15:24] <highvoltage> *nerdcore
[15:24] <didrocks> pitti: not really about that, alt + tab can be very slow
[15:25] <geser> kirkland: I got once a problem with alt-tab in unity too, I had to re-add the key shortcut as it was gone
[15:25] <kirkland> pitti: okay, i'll create a new user
[15:25] <kirkland> seb128: classic gnome
[15:25] <didrocks> kirkland: normally, I tried to migrate uncompatible settings, but yeah, --reset is always better :)
[15:25] <seb128> kirkland, try a guest session to start I guess
[15:25] <seb128> didrocks, is there a compiz --reset?
[15:26] <pitti> guest session would start unity, though
[15:26] <didrocks> seb128: not for that, unfortunately…
[15:26] <didrocks> guest session should start the session your are in
[15:26] <didrocks> you*
[15:26] <seb128> pitti, what didrocks said
[15:26] <pitti> didrocks: oh? clever
[15:26] <didrocks> so, classic if you are in gnome-classic, unity if you are in ubuntu desktop… and so on :)
[15:27] <kirkland> weird, unity was not installed
[15:27] <kirkland> i did not uninstall it
[15:27] <didrocks> pitti: I fixed it for alpha1, but didn't retest for alpha2
[15:28] <didrocks> so, in any case, it's in my checking TODO as it's often broken by inadvertance
[15:28] <seb128> didrocks, what?
[15:28] <didrocks> seb128: the "start the corresponding guest session"
[15:28] <seb128> didrocks, that works, at least it starts the classic session for me
[15:29] <didrocks> seb128: ok nice, not broken again yet :)
[15:29] <kirkland> didrocks: seb128: pitti: okay, i installed unity, and then ran unity --reset and I can now move windows and resize them again!
[15:29] <kirkland> i still can't alt-tab, though
[15:29] <pitti> kirkland: that's progress!
[15:29] <pitti> curious, though, as unity shouldn't be involved in classic gnome
[15:30] <didrocks> kirkland: try to hang the alt + tab for few seconds
[15:30] <pitti> ok, need to finish early today, sorry
[15:30] <pitti> kirkland: I'll read backscroll
[15:30] <seb128> pitti, well, unity --reset starts compiz with a fresh profile
[15:30] <pitti> ah
[15:30] <pitti> so, compiz bug
[15:30] <didrocks> kirkland: there is a performance issue with it, so maybe
[15:30] <hallyn> jinkeys - requestsync failed with 'too many concurrent connections' to mx.launchpad.net:25
[15:30] <kirkland> didrocks: nope ... if I'm in the terminal, I get "^[      " in my window
[15:30] <seb128> pitti, "bug" or "config issue"
[15:30] <didrocks> kirkland: staticswitcher in enabled in ccsm?
[15:31] <didrocks> (it should as you just reset the value)
[15:31] <kirkland> didrocks: what is ccsm?
[15:31] <hallyn> kirkland: did you allow the latin keyboard thingie to misconfigure with alt perhaps?
[15:31] <kirkland> hallyn: oh
[15:31] <didrocks> kirkland: compizconfig-setting-manager, a way to change everything in compiz and break it :)
[15:31] <kirkland> hallyn: maybe so
[15:31] <kirkland> didrocks: not installed, installing now
[15:31] <didrocks> kirkland: compizconfig-settings-manager and then, just launch "ccsm"
[15:32] <didrocks> kirkland: you should ensure that the staticswitcher plugin is activated
[15:32] <kirkland> didrocks: was not emabled
[15:32] <didrocks> hum…
[15:32] <didrocks>  /!\ activating/deactivating plugin make compiz crash now
[15:33] <kirkland> didrocks: got it, that works now
[15:33] <kirkland> didrocks: seb128: pitti: thanks so much!
[15:34] <didrocks> kirkland: that's really weird, unity.ini, debian/rules for autogeneration list, and the compiz gconf default are setting it…
[15:34] <didrocks> kirkland: but well, nice that fixed it for you, I'll try again with a new user :)
[15:34] <kirkland> didrocks: seb128: pitti: because of this, i have spent most of the last 4 weeks in tty1, with byobu+w3m+ irssi+mutt :-)
[15:34] <kirkland> (which is actually pretty nice :-)
[15:34] <seb128> kirkland, don't hesitate to ask early when you have a such issue
[15:35] <didrocks> kirkland: well, that's just a way for you to enjoy byobu a little more :)
[15:35] <kirkland> seb128: thanks, will do
[15:36] <tumbleweed> bdrung: ^5 (on ubuntu-sponsoring)
[15:39] <dholbach> bdrung, tumbleweed: are you both looking into the unicode problem right now?
[15:39] <dholbach> I just wanted to take the dog for a walk real quick - I can review whatever you have when I'm back
[15:40] <dholbach> it'd be nice to get the issue resolved :)
[15:40] <tumbleweed> dholbach: at least I am :)
[15:40] <dholbach> thanks muchly
[15:40] <dholbach> I'll let you know when I'm back
[15:46] <bdrung> dholbach: i am cooking
[15:47] <mvo> hey zyga - you pinged me earlier?
[15:47] <zyga> mvo, yes
[15:48] <zyga> mvo, I had this crazy idea of being able to install packages without invoking any scripts, then gathering the required scripts and executing them in sequence during first boot, I was wondering what kind of caveats would you think of in such design
[15:48] <mvo> barry: mind if I upload some rebuilds for python2.7 ? looks like python-oss is a candidate for this, probably more
[15:51] <mvo> zyga: you need to consider that pre-depends requires a package to be installed and configured, so you can only delay those with "regular" dependencies. then you need to run the configure scripts on bootup in the right order (well, dpkg --configure -a should actually handle this for you). and there is the issue that your daemon will not get restarted, so e.g. on security updates of libfoo the old copy keeps running
[16:00] <zyga> mvo, re, sorry about being missing
[16:00] <zyga> mvo, this about building system images "dry", without running the target system (pc->arm)
[16:01] <zyga> mvo, so issues such as running system are not important here
[16:01] <zyga> mvo, in fact we have a slightly easier work to perform, currently linaro has a tarball with the root fs created using lexbuilder/offspring with the regular method (which AFAIR depends on qemu faiking the target system)
[16:02] <zyga> mvo, then when you want to create a bootable media for your device you need to combine this filesystem with a "hardware pack" which is a tarball with extra packages and repository for anything that they might depend on
[16:02] <zyga> mvo, currently the procedure is somewhat complex because we need to install those hardware pack packages in the image we're building, I wanted to simplify that
[16:03] <zyga> mvo,  up to a point that the whole procedure would not depend on anything apart from simple file manipulation tools
[16:17] <ev> GunnarHj: merged both branches and uploaded; great work on these!
[16:30] <ev> @pilot out
[16:31] <seb128> hum
[16:31] <seb128> is launchpad or launchpadlib known to be broken?
[16:31] <seb128> the retracers crash on "NotImplementedError: Can't look up definition in another url (https://api.launchpad.net/1.0/#distributions)"
[16:32] <jpds> seb128: leonardr is talking about this in #launchpad with apw.
[16:33] <james_w> seb128, login_*(name, service_root=EDGE_SERVICE_ROOT) needs to change EDGE_SERVICE_ROOT to "production"
[16:35] <pitti> james_w: thanks
[16:35] <apw> james_w, so login_*(name, service_root="production") ??
[16:35] <james_w> apw, yeah
[16:35] <james_w> if you are on a really old version of launchpadlib that will crash, let me know if so
[16:36] <seb128> james_w, how come they didn't keep it working for compatibility purpose?
[16:36] <seb128> it's breaking retracers and sponsoring queue and versions and...
[16:36] <seb128> like is there any need to force us to do review and fix everything now by breaking it?
[16:37] <james_w> seb128, they wanted to reassign the edge machines to the production, and a redirect broke some other things
[16:38] <james_w> seb128, I disagree with the way they have gone about it
[16:38] <seb128> james_w, ok, thanks
[16:40] <bobg> i am writing a package for my company that supplies the debconf values for ldap-auth-config (so that we can install this package to config a machine to use the company ldap for authentication) what's the best channel to get help for that?
[16:42] <cjwatson> in fairness the edge decommissioning was announced several months ago
[16:44] <pitti> seb128: apport trunk already uses production, so the natty chroot should be okay, and the crash-digger merely needs a bzr pull
[16:44] <pitti> seb128: the only problem is the maverick chroot, we'd need either an SRU or a backport of apport in my PPA; I'll handle that one tomorrow
[16:45] <bdrung> dholbach, tumbleweed: merged
[16:45] <pitti> seb128: ok, branches updated and locks removed; let's see how it goes
[16:45] <seb128> pitti, thanks
[16:46] <pitti> seb128: ah, need to refresh the LP cookie, doing..
[16:51] <pitti> seb128: did it crash right away? it's currently consolidating the dup db, but that already means lots of LP access
[16:51] <seb128> pitti, yes
[16:52] <pitti> ok, cool
[16:52] <seb128> pitti, thanks for the quick fixing
[16:53] <achiang> pitti: do you understand the relationship between udev and usb_modeswitch? i'm playing around with a new modem, which i'm pretty sure needs to be mode-switched. it was not originally listed in /lib/udev/rules.d/40-..., so i stuck an entry in there. yet, when i plug it in, i don't really see udev calling the proper script
[16:53] <achiang> udevadm monitor isn't really showing me anything interesting (or i don't know what i should be looking for)
[16:54] <pitti> achiang: I'm just logging out, can you please mail me?
[16:54] <achiang> pitti: ok, sure
[16:54] <pitti> cheers
[16:54] <achiang> thanks
[16:55] <slangasek> hallyn: I thought the conclusion was that qemu*ppc64 rather belonged in /qemu-linaro/; is that not the plan?
[16:57] <hallyn> kirkland: ^
[16:58] <hallyn> slangasek: that hadn't been what i remembered, and i *think* not what kirkland took away from it either, but waiting for him to confirm
[16:58] <kirkland> slangasek: i thought we were putting any and all kvm-accelerated stuff in qemu-kvm
[16:58] <kirkland> slangasek: where ppc64 is (or will very soon be) kvm-accelerated
[17:03] <dholbach> bdrung, pulled
[17:05] <slangasek> kirkland: well, we said that, yes... we also earlier discussed that powerpc support would be going directly against qemu upstream so it might be just as good to package it via qemu-linaro
[17:05] <slangasek> kirkland: I guess I don't mind either way, but at this point you're missing a Replaces :)
[17:09] <kees> seb128: re 717358: what does that have to do with this goofy menu bar?
[17:10] <seb128> bug #717358
[17:10] <seb128> kees, I guess I didn't understand the issue, it seemed like you have the default config with a gnome-panel at the top of the screen and indicator-appmenu
[17:11] <kees> nope. I have no panel on the top.
[17:11] <kees> you can see in the screenshot that it's a menu bar
[17:11] <seb128> kees, well that could have been the indicator-appmenu applet on a panel weirdly themed as well
[17:11] <kees> and if I select "Help / About" it says nautilus
[17:11] <kirkland> slangasek: hrm, okay;  please commit the Replaces that we need against lp:ubuntu/qemu-kvm
[17:12] <seb128> right, the default appmenu if you have nothing focussed is the nautilus one
[17:12] <kees> I'm using classic desktop.
[17:12] <seb128> kees, do you have a dual screen config?
[17:12] <kees> nope
[17:12] <kirkland> slangasek: the ppc64 patches will be against HEAD, but we're shipping qemu-kvm-0.14 in 11.04, so we're not far off
[17:12] <seb128> kees, well, indicator-appmenu is in the default classic desktop applet list in natty
[17:13] <kees> none of my other menu bar end up there (thank goodness).
[17:13] <kirkland> slangasek: also, it's the server team doing the work and testing against ppc64/kvm, so i think it'll be better for us to work against qemu-kvm (ours) rather than stepping on qemu-linaro (yours)
[17:13] <seb128> kees, ok, dunno then, I just tried in a guest session and move the default gnome-panel which is at the top and I don't get that
[17:14] <seb128> kees, I've switched back the bug to New I will let someone else confirm
[17:14] <kees> seb128: mdeslaur already confirmed it
[17:14] <seb128> kees, nautilus didn't get an upload for a month so it's not likely due to it
[17:14] <slangasek> kirkland: well, I would like less of an ours vs yours here; qemu-linaro is just like any other Ubuntu package and if changes are needed any Ubuntu developer can make them as normal
[17:14]  * kees looks around for tedg
[17:14] <kirkland> slangasek: heh, fair enough
[17:14] <slangasek> kirkland: so from that POV I don't really think that having it in qemu-linaro instead of qemu-kvm should handicap you
[17:15] <seb128> kees, try mterry or kenvandine otherwise ;-)
[17:15] <kirkland> slangasek: okay, but you did tell me qemu-linaro will be 0.13.5, right?
[17:15] <kees> seb128: okay, thanks!
[17:15] <seb128> kees, you're welcome
[17:15] <kees> mterry, kenvandine: hi! :) can you look at 717358? does that relate to work you've done recently?
[17:15] <slangasek> kirkland: qemu-linaro is *currently* at 0.13.50, which is "straight from HEAD plus linaro cleanups"
[17:15] <kirkland> slangasek: we'll be uploading 0.14~rc1 today, so that puts us closer to HEAD (which I think is the main point)
[17:16] <slangasek> from my side I haven't heard that an rc was impending, but the line of communication is a bit long
[17:16] <slangasek> AIUI we're no more than 2 weeks out of date wrt upstream
[17:16] <slangasek> and will be syncing with them again between now and release
[17:17] <mterry> kees, wait, so nautilus is drawing its menu in gnome-panel even without the appmenu being active?
[17:17] <kees> mterry: no, no gnome panel at all up there.
[17:17] <slangasek> kirkland: the other question I have is, is whether it makes sense to install qemu-system-ppc64 for everyone on x86 who installs qemu-kvm
[17:17] <kirkland> slangasek: interesting choice of version, then :-)
[17:17] <kees> mterry: I have only a panel at the bottom of my screen, and I'm running classic desktop so none of the menu-bar stealing should be happening.
[17:17] <slangasek> kirkland: the 0.13.50? It's what was in the upstream git at the time as the label
[17:17] <mterry> kees, oh, weird.  No, not related to my work
[17:18] <kees> mterry: okay
[17:19] <kirkland> slangasek: fair enough;  qemu is weird then :-)
[17:19] <seb128> kees, mterry: ok, I can confirm that, if you don't have an appmenu container set it does that
[17:19] <seb128> kees, mterry: like in a guest session if you remove indicator-appmenu from gnome-panel
[17:19] <mterry> MUST SHOW APPMENU!!! GRR
[17:19] <seb128> ;-)
[17:19] <mterry> seb128, I can look at it
[17:19] <seb128> mterry, if you want to that would be welcome
[17:19] <seb128> otherwise we can ask ted when he's back
[17:20] <kirkland> slangasek: and yes, i think that to be consistent with myself (oh so important, btw!), qemu-kvm should install qemu-system-[i386,x86_64,ppc64]
[17:20] <kirkland> slangasek: and qemu-kvm is the home for "architectures that support kvm-acceleration"
[17:21] <kirkland> slangasek: at least for now
[17:21] <kirkland> slangasek: and then we have another interesting discussion when cortex15 adds VT support for ARM
[17:21] <kirkland> slangasek: hopefully by then, qemu-linaro has merged into qemu
[17:21] <slangasek> kirkland: <smirk>
[17:21] <kirkland> slangasek: but i won't hold my breath on that one
[17:21] <kirkland> slangasek: too many moving parts outside of our control (ARM, QEMU, etc)
[17:22] <ogra> and you cant be sure the VT variant is actually kvm
[17:22] <seb128> re
[17:22] <slangasek> kirkland: qemu-linaro is already the source for upstream qemu in Ubuntu packages, for all intents and purposes - merging isn't the issue
[17:22] <ogra> compatible
[17:22] <seb128> mterry, I was saying that if you want to look to it that would be welcome or we can ask ted
[17:22] <kirkland> slangasek: okay
[17:22] <seb128> laptop crashed on vt switch then
[17:22] <seb128> mterry, that's not an appmenu though but the nautilus menu
[17:23] <mterry> seb128, oh, it's only nautilus?  ah, thought it was everything
[17:23] <seb128> like it doesn't track other menus or anything and go away when you nautilus --quit
[17:23] <seb128> could be the compiz update for the invisible dialogs issue
[17:23] <mterry> seb128, ok, I'll delay looking at that then.  I've got other indicator stuff I can do
[17:25] <seb128> mterry, ok
[17:25] <seb128> it happens in unity as well in fact
[17:25] <seb128> I can see a one pixel grey line below the unity-panel there
[17:25] <seb128> if I switch workspaces I can see the menubar from nautilus during the transition
[17:35] <GunnarHj> ev: Thank you, Evan!
[17:56] <seb128> kees, mdeslaur: do you know when the menu issue started?
[17:58] <mdeslaur> seb128: Unfortunately, not really, since it's being drawn _underneath_ my gnome-panel
[17:59] <geser> seb128: a few days ago, I can check my IRC log when I asked about it #ubuntu-desktop
[17:59] <seb128> geser, you asked on friday morning european time
[17:59] <seb128> geser, I checked
[17:59] <seb128> ok
[17:59] <seb128> let's say it's one of the update on thursday
[18:04] <hyperair> was there a tool that allows you to check the signatures of source packages?
[18:07] <Laney> dscverify
[18:08] <hyperair> aha!
[18:08] <hyperair> thanks
[18:10] <hyperair> i'm uploading gdata-sharp to ubuntu now
[18:10] <Laney> ♥
[18:10] <Laney> sync?
[18:11] <hyperair> yes
[18:12] <hyperair> Laney: we'll need to rebuild gnome-do-plugins
[18:12] <Laney> sure
[18:12] <hyperair> in debian as wel
[18:12] <hyperair> +l
[18:13] <hyperair> well gdata# has been uploaded.
[18:13] <hyperair> next will be banshee
[18:13] <hyperair> but that'll have to wait for directhex to upload it to debian first.
[18:13] <Laney> you can probably make it syncable
[18:13] <hyperair> the one with amended debian/control
[18:13] <Laney> if you take that patch into debian
[18:13] <hyperair> nah, banshee isn't syncable.
[18:13] <Laney> i mean plugins
[18:13] <hyperair> ah
[18:14] <hyperair> i don't know, i didn't work on gnome-do-plugins before
[18:14] <Laney> it's your patch :P (which is already upstream)
[18:14] <hyperair> eh?
[18:14] <hyperair> it's my patch?
[18:14] <hyperair> O_o
[18:14] <Laney> check it out
[18:14]  * hyperair checks
[18:15]  * sebner hugs Laney and hyperair =)
[18:15] <hyperair> oh that one
[18:15] <hyperair> that's oooooooooold
[18:15] <hyperair> and that patch should go into debian, yes
[18:15] <Laney> there you go, an excuse for an upload/sync
[18:15] <Laney> \o/
[18:15] <hyperair> heheh
[18:16] <hyperair> hmm
[18:16] <hyperair> it's still svn? =O
[18:16] <Laney> RAOF was talking about migrating it the other day
[18:16]  * Laney knows not what the plans are
[18:17] <hyperair> i see.
[18:18] <hyperair> it seems that hibernate in gnome-do is broken though.
[18:18] <hyperair> on maverick
[18:18] <hyperair> i haven't had time to poke it to see
[18:19] <hyperair> or maybe it's my weird setup
[18:20]  * sebner goes crying into the corner as he feels slightly ignored
[18:20]  * Laney fluffs sebner
[18:21] <sebner> :D
[18:21]  * iulian hugs sebner.
[18:21] <sebner> \\o/
[18:21]  * Laney fades away
[18:21] <Laney> ttyl
[18:33] <bobg> is it possible to use debconf-set-selections inside a package preinst (or other) script so that it effects another package?
[18:52] <cody-somerville> pitti, Is apport sending a 'Crash report detected' to the notification daemon over and over repeatedly a known issue in Maverick? :P
[19:08] <cody-somerville> wow... I just noticed that apport will open up the web browser running as root. That can't be intentional.
[19:10] <satya> hello
[19:15] <kklimonda> jdstrand: hey, do you have a moment?
[19:16] <kklimonda> actually, anyone from the security team would help :)
[19:19] <jdstrand> kklimonda: whatcha need?
[19:20] <jdstrand> kklimonda: and hi! :)
[19:20] <kklimonda> jdstrand: hey. I have a small problem.
[19:21]  * jdstrand thinks he may know what it is...
[19:21] <kklimonda> jdstrand: Transmission requires a newer version of libevent then the rest of the archive, and we can't do the transition as we get some ftbfs - some of them in tests which indicates that something subtle has changed, and other packages may be affected.
[19:21] <jdstrand> that was not it :)
[19:22] <kklimonda> jdstrand: it leaves me with two choices - keep transmission at 2.13 for natty
[19:22] <kklimonda> which will make it harder on both us and upstream to maintain it.
[19:23] <kklimonda> jdstrand: or rebundle libevent2 in transmission source - it was bundled for a long time, I think we started using a system version only a year ago or so.
[19:23]  * jdstrand cringes a little
[19:23] <jdstrand> let me look at the source
[19:25] <kklimonda> sure - do you want a link to libevent 2.0.10?
[19:25] <jdstrand> looks like 1.73-3 use the system libevent
[19:25] <jdstrand> kklimonda: not really
[19:25] <kklimonda> so it was even earlier? How long have I been around..
[19:26] <jdstrand> so, lucid is supported until 2012-04 and natty is supported until 2012-10
[19:26] <jdstrand> yeah, that was pre-karmic
[19:26] <jdstrand> I'm sorry
[19:26] <jdstrand> lucid is supported until 2013-04
[19:26] <jdstrand> that makes it easier
[19:27] <jdstrand> natty will fall off before lucid is eol
[19:27] <kklimonda> right, how does it help
[19:27] <kklimonda> ?
[19:27] <jdstrand> so I'm not sure the maintenance burden is greatly reduced by having the absolute latest trnasmission
[19:28] <chrisccoulson> we want the latest crack though ;)
[19:28] <jdstrand> kklimonda: so, I'm inclined to say that the recommendation from a security team POV is to keep transmission where it is for now, until the libevent issues are worked out and it can use the system one
[19:29] <jdstrand> chrisccoulson: :P
[19:29] <jdstrand> there might be other factors, but embedded a library is really pretty bad, even more so when we diverge from Debian
[19:29] <jdstrand> s/embedded/embedding/
[19:30] <kklimonda> jdstrand: where can I check the history of security issues in libevent?
[19:30] <jdstrand> http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libevent
[19:33] <kklimonda> hmm.. so it's a choice between the latest crack, and ease of maintainance.. bummer, both choices suck ;)
[19:33] <jdstrand> well, what sucks is the timing of the library transition
[19:34] <SpamapS> Is hardy still getting actively updated with non-security SRU's or is it security only?
[19:34] <jdstrand> SpamapS: it will ge tthe occasional SRU
[19:42] <SpamapS> jdstrand: whiel I have your attention, I think that bug #251139 is making an unacceptable SRU request to have apr backport a change to use /dev/urandom instead of /dev/random. Would you concurr?
[19:42] <kklimonda> ok, we are staying with 2.13 in this case, I'm not willing to add burden on others so we can get latest features. thanks jdstrand :)
[19:43] <jdstrand> kklimonda: sure, np. a wise choice if I may say :)
[19:46] <jdstrand> SpamapS: on the face of it, I don't see it as particularly high-risk, but hardy is pretty stable these days. I think you might have a hard time convincing them it is needed. it is a 2.5 year old bug with no one saying it affects them too or duplicates
[19:46] <jdstrand> and by them, I mean ubuntu-sru
[19:46] <SpamapS> Yeah exactly
[19:47] <SpamapS> Entirely possible too that somebody has built a system out there expecting super-high-quality-randomness in apr.
[19:47] <jdstrand> "Won't Fix" is a viable choice. who knows, the user may come back with an important use case to reconsider
[19:47] <SpamapS> Thats what I was going to mark it.
[19:47] <SpamapS> Thanks for taking a look. :)
[19:47] <jdstrand> sure! :)
[19:48]  * SpamapS just loves triaging bugs that are older than his children.
[19:52] <kklimonda> oh, I just made my life harder then it should be - I'm subscribed to ubuntu MLs from my @ubuntu address, but bug mails are sent to my main address. Because of that people CC the email which is not subscribed, and my response ends up in the moderation..
[19:54] <micahg> kklimonda: virtual identity or correct identity for Thunderbird can help with that
[19:54] <kklimonda> thunderbird you say? :)
[19:54] <kklimonda> I guess it's time to give it another shot
[19:56] <SpamapS> Evolution seems to get the reply address mostly right, most of the time.
[22:11] <ScottK> Wow.  A nice comment about Evolution and multiple hours of stunned silence ensue.
[22:11] <maco> haha, especially after that pc world article
[22:14] <charlie-tca> amazing what a single good thing will do, huh?
[22:34] <kees> doko: what're your thoughts on 712662
[22:35] <doko> bug #712662
[22:38] <doko> kees: would it be ok, if such packages use /bin/sh in there scripts only? and if a user is created for these packages, to set the login shell to /bin/sh ?
[22:39] <kees> doko: hrm? the point is to keep any shell from having built-in network redirection
[22:40] <doko> kees: shell or interpreter?
[22:40] <kees> shell.
[22:40] <kees> scripting languages all have networking, even awk
[22:40] <doko> people did file bug reports to enable it
[22:40] <kees> but shells doing networking is odd
[22:40] <kees> yeah.
[22:40] <kees> but it's been off for so long; it's a security feature :)
[22:41] <doko> I did enable it once dash was the default shell
[22:41] <kees> true
[22:41] <kees> jdstrand: what do you think of making the distinction between dash and bash for this? I think it wouldn't work well.
[22:41] <kees> doko: the problem is that most apps (say, firefox) when running subshells are using the users's defined login shell to do the work.
[22:42] <kees> so it's not so simple to separate dash and bash in this case
[22:43] <doko> kees: what would break if we disable the redirects?
[22:43] <jdstrand> kees: I'm not sure I understand the question. your last comment is the problem. eg, things that use /bin/sh get dash in Ubuntu and profiling is no problem. it is things that specifically use bash
[22:43] <kees> doko: nothing I know depends on it
[22:44] <doko> jdstrand: bash is still essential, so it's difficult to determine what depends on bash
[22:45] <jdstrand> forgive me, I have no idea what I am being asked
[22:45] <doko> ask kees ;P
[22:45] <kees> jdstrand: heh, sorry.
[22:45] <jdstrand> I'm coming at it from an apparmor profiling angle
[22:46] <jdstrand> it is very easy to see when profiling an application which is used
[22:46] <kees> jdstrand: right, so how to the abstractions currently deal with dash vs bash?
[22:47] <jdstrand> there is no dash abstraction
[22:47] <jdstrand> things that use dash will use the bash abstraction
[22:47] <jdstrand> and ixr
[22:47] <kees> I'm just trying to use AppArmor as supporting evidence. I don't like shell redirection because it makes remote attacks much easier
[22:47] <jdstrand> the bash abstraction isn't a problem
[22:48] <jdstrand> it is when you pull in networking, and have bash ixr
[22:48] <jdstrand> eg,
[22:48] <jdstrand> #include <abstractions/namneservice>
[22:48] <jdstrand> #include <abstractions/bash>
[22:48] <jdstrand> /bin/bash ixr,
[22:48] <SpamapS> slangasek: around? I think we may need to make a change to upstart-job's handling of the 'restart' command after discussing something w/ Keybuk last week.
[22:49] <jdstrand> ^ with that, networking is implicitly allowed via the nameservice abstraction, and bash has network redireection, so you have a reverse shell
[22:49] <jdstrand> where one would not think one would
[22:49] <doko> kees, jdstrand: offline now, let's continue later this week, but not tomorrow. need to catch up on more things
[22:49] <jdstrand> if networking is not allowing in the profile, then no problem
[22:49] <kees> doko: okay
[22:50] <jdstrand> if dash is used and not bash, then no problem
[22:50] <kees> jdstrand: right
[22:50] <jdstrand> it is the combination of bash, networking in the profile and network redirection
[22:50] <jdstrand> then you have to go through ridiculous hoops to confine bash
[22:50] <jdstrand> (see the bug)
[22:51] <jdstrand> kees: cups suffers from this, as a specific example
[22:51] <jdstrand> ./usr.sbin.cupsd:  #include <abstractions/bash>
[22:51] <jdstrand> ./usr.sbin.cupsd:  /bin/bash ixr,
[23:05] <bdrung> zul: are you still progressing bug #719056?
[23:12] <zul> bdrung: hmm?
[23:13] <bdrung> zul: you gave your ACK, but ubuntu-sponsors is still subscribed, the status is still new, and ubuntu-archive isn't subscribed
[23:13] <zul> yeah i just stepped away for a momment
[23:14] <zul> @pilot out
[23:18] <bdrung> zul: status -> confirmed


[15:57] <Echo6> There is a troll bot in the main #ubuntu channel "Scumi". It messages people as soon as the log in and sends them political and racist stuff.
[15:57] <Echo6> .:Scumi:. Scumi:. You baztard   .:Echo6:. Do I know you?   .:Scumi:.  I have no idea who you are.   .:Scumi:. You nigger
[15:57] <Echo6> There is a sample.
[16:00] <nacc> please kick Scumi from #ubuntu
[16:00] <nacc> s/kick/kickban/
[16:40] <hggdh> already left
[16:41] <hggdh> jnewt: anything we can do for you here?
[16:48] <nacc> hggdh: thanks, nm


[02:41] <stupendousman> ahoy there .. some food for thought . not exactly implementable directly of course, but should help you think in different ways http://www.ted.com/talks/fabian_hemmert_the_shape_shifting_future_of_the_mobile_phone.html
[13:19] <thorwil> mpt, JanC, godbyk
[13:43] <JanCBorchardt> godbyk, I'm late and I blame it on Thunderbird :)
[13:54] <thorwil> JanCBorchardt: hi! didn't happen
[13:57]  * thorwil -> coffee
[14:00] <JanCBorchardt> thorwil: ok, thanks


 seems qtdatavis3d never made it for bionic @tsimonq2 ? I grabbed the WIP debian packaging, and built it for KCI repo anyway
 OK
 Qool