[02:52] <pmatulis_> doesn't look like it to me
[19:34] <feo> Hi all
[19:34] <pmatulis> hello
[19:35] <feo> Wanted to do some good thing and contribute to the wiki and change one of the pages I used and wanted correct it a bit
[19:36] <feo> But looks like not allowed to do it
[19:39] <feo> https://help.ubuntu.com/community/PostfixCompleteVirtualMailSystemHowto
[20:04] <pmatulis> feo: the wiki is lock-down due to vandalism. it's taking a while to resolve
[20:04] <pmatulis> send info to ubuntu-doc mailing list and someone can make the change
[20:05] <pmatulis> (see topic above)


[02:09] <jfcaron1> I have a local bzr repository which accidentally versioned some huge data files.  I unversioned them, but now I want to push the project to launchpad.  How can I make it not upload those huge files?  Can I push only the history from a given point?
[08:21] <mgz> test OOPS-3f88a8b6ed6964be842c6737eea45655
[08:21] <mgz> woho.
[08:21] <czajkowski> yay
[08:21] <czajkowski> nicely done mgz
[09:57] <lifeless> mgz: so who did you speak to to fix that?
[09:59] <czajkowski> lifeless: we asked in -ops yesterday
[09:59] <czajkowski> then alanbell said it was up to tsimpson or jussi to get it landed
[10:00] <czajkowski> lifeless: I saw your Q on answers, unsure if it's for me to ollow up on or you logged it there to track something
[10:00] <lifeless> czajkowski: which one ?
[10:01] <czajkowski> lifeless: https://answers.launchpad.net/launchpad/+question/208613
[10:02] <lifeless> czajkowski: the linked bug covers it; I suspect maintenance squad are best placed to file an RT to get the current situation resolved until the data can be migrated to use the new stuff exclusively.
[10:02] <lifeless> wgrant: ^ :P
[10:02] <czajkowski> lifeless: ok thanks
[12:19] <exarkun> what format are timestamps on launchpad?  YYYY-MM-DD?
[12:21] <wgrant> exarkun: Yes
[12:22] <wgrant> Is YYYY-DD-MM ever a thing? :)
[12:23] <nigelb> god I hope not.
[12:26] <czajkowski> bah should be DD-MM-YYYY
[12:26] <wgrant> czajkowski: Burn!
[12:26] <czajkowski> *HATE*  MM-DD
[12:26] <wgrant> ISO8601 and derivatives over all!
[12:27] <wgrant> MM-DD-YYYY is satan
[12:27] <czajkowski> yes well doesnt make the rest of the world use it
[12:27] <wgrant> DD-MM-YYYY is acceptable
[12:27] <wgrant> YYYY-MM-DD is ideal
[12:27] <czajkowski> I'd accept YYYY-DD-MM at a push
[12:27] <wgrant> What!?
[12:27] <wgrant> Middle-endian should be illegal.
[12:28] <czajkowski> we shall agree to disagree shall we
[12:28] <exarkun> wgrant: I thought that Launchpad might have decided to invent YYYY-DD-MM.
[12:28] <exarkun> Canonical seems to like to invent things like that.
[12:29] <exarkun> Thanks
[12:30] <czajkowski> we invent many things, but I don;t think we can take credit for the date standard
[12:43] <davmor2> czajkowski: as ali1234 was so keen to point out, YYYY-MM-DD is an iso standard :D
[12:44] <wgrant> As well as making sense
[12:48] <davmor2> wgrant: and making positioning far more sensible YY changes least, MM second DD well daily :D  Add to that HH:MM:SS and the tree of time is complete :D
[13:09] <dobey> davmor2: people should just stop dwelling on the past
[13:10] <xnox> lp is a bit slow for me.... i got timeouts each time trying to add small attachments (<1MB), now I am getting "Timeout, server bazaar.launchpad.net not responding." upon bzr push...
[13:12] <czajkowski> hmm
[13:13] <czajkowski> not seeing anything
[13:13] <wgrant> xnox: There are no known issues, and it's working fine for me from multiple continents. Does a traceroute show anything odd?
[13:13] <xnox> wgrant: let me check.
[13:14] <xnox> wgrant: it does show odd stuff =)
[13:14] <czajkowski> xnox: show wgrant and he'll judge on the oddness
[13:14] <xnox> czajkowski: let me collect a bit more oddness first =) to boost the odd factor =)
[13:16] <xnox> wgrant: http://paste.ubuntu.com/1212887/
[13:16] <wgrant> xnox: 15% packet loss to your first hop is slightly suspicious
[13:16] <xnox> first of all Virgin Media is having an odd day and something is off in ae-2-52.edge4.London1.Level3.net
[13:17]  * xnox ponders if I should restart my router
[13:17] <wgrant> ae-2-52 doesn't return ICMP very much
[13:17] <wgrant> So that's expected
[13:17] <wgrant> And all the rest have at most as much packet loss as your first hop
[13:17] <xnox> ah, fair enough =)
[13:17] <wgrant> So it's something very close to you
[13:19] <czajkowski> so no lp :)
[13:19] <wgrant> Right, nothing there suggests a problem on the LP side
[13:20] <TheLordOfTime> bazaar's working for me, just tested.
[13:20] <TheLordOfTime> so it has to be on your end, not LP
[13:43] <xnox> I should probably finish setting up WRT on my new router and put it into production. Restarted router and now everything is fine.
[13:44] <xnox> no packet loss...
[18:49] <om26er> Hi! my login.ubuntu.com account has been suspended
[18:49] <om26er> how to get it reactivated ?
[18:50] <om26er> i kind of Can't work :/
[19:02] <greenit> hi, i have a question regarding translation: is it possible to let a software translate in different languages at launchpad, although it is not open source?
[19:06] <xnox> greenit: as long as the translations are BSD license i believe, you can have 'translations only' project.
[19:07] <greenit> thx
[19:07] <xnox> greenit: you will need to manually provide templates & download tarballs to update them.
[19:07] <greenit> ok
[19:08] <xnox> greenit: people generally make wrapper scripts, e.g. something like 'make tempalates-for-lp' and 'make update-translations-from-lp'
[19:09] <greenit> could you give me a link to an example, or a how to? :)
[19:14] <xnox> greenit: can you give source code and the build system of your proprietary project?
[19:15] <xnox> greenit: i believe there is some documentation on help.launchpad.net
[19:17] <greenit> thx, found a page :)
[19:25] <dobey> om26er: that's not launchpad, but sso. you should probably bug someone in #canonical-is (i think that's the channel)
[19:25] <om26er> dobey, yeah, this was sorted in #is now my account is back on :)
[19:25] <dobey> ah ok :)


[21:24] <blkperl> slangasek: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1292628
[21:47] <blkperl> slangasek: http://www.debian.org/doc/manuals/maint-guide/start.en.html
[21:49] <slangasek> blkperl: apt-cache show packaging-tutorial
[22:13] <slangasek> blkperl: apt-cache show wwwconfig-common :)
[22:15] <slangasek> https://launchpad.net/drupal-charm
[22:26] <slangasek> blkperl: have added a request for more info on bug #1292628
[22:26] <slangasek> nightfly: hi there
[22:26] <nightfly> hello
[22:26] <slangasek> nightfly: so on https://launchpad.net/bugs/1292628 I asked for more info - basically, to understand why grub-installer failed to figure out the correct root device
[22:30] <slangasek> (hd0)	/dev/disk/by-id/ata-INTEL_SSDSA2CW300G3_CVPR142500XY300EGN
[23:11] <blkperl> slangasek: https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1274013
[23:17] <slangasek> blkperl: do you have 'debconf-communicate' in the installer environment? (not in the target environment)
[23:17] <blkperl> yes
[23:17] <slangasek> blkperl:  debconf-show grub-installer/bootdev
[23:19] <slangasek> blkperl: look for the grub-installer/bootdev section in /var/cache/debconf/config.dat (outside the chroot)
[23:22] <slangasek> blkperl: I found the guilty code in kickseed handlers/bootloader.sh: http://paste.ubuntu.com/7159727/
[23:22] <slangasek> blkperl: so if you drop the --location mbr part from your kickstart file, it should DTRT
[23:22] <slangasek> blkperl: it's still a bug in grub-installer, but the above should work around
[23:33] <slangasek> blkperl, nightfly: cf. lightdm-remote-session-freerdp
[23:35] <blkperl> slangasek++ wooto!


[21:26] <XubXubXub> My HTPC running Xubuntu LTS decided to just default to a kodi-standalone session by default instead of the desktop all on it's own.  When I exit kodi it just logs out and when I log back in it starts kodi again.  I don't know what caused this to change from the default behavior but I would like to change it back to default x11 xfce4.  It's been a long time since I messed with changing default session settings and googling it
[21:26] <XubXubXub> returns very wide results.  Can someone remind me how to switch default desktop sessions via terminal?
[21:52] <new-user> morning, I just swapped to Xubuntu, I was using ElementaryOS before but it wasn't doing too great in the install size side, I like Xubuntu so far and I want to stick with it, but.. the touchpad feels a little unresponsive, it was working just perfectly fine in ElementaryOS, is there any known config or update to configure touchpad responsiveness?
[21:53] <gnrp> new-user: What do you mean with "responsiveness"?
[21:53] <gnrp> you can set the acceleration and speed in the settings
[21:54] <new-user> well.. sometimes I drag my finger across the touchpad and it doesn't register anything at all, I've been using my whole thumb to move the pointer around and it tracks it well, but with my previous distro it would work just fine with the tip of any finger
[21:55] <new-user> like it ignores the input if the touch surface is way too small
[21:56] <XubXubXub> Nevermind my question I found the big ole button in LightDM to change sessions.  I knew there was an easier way than going all 2011 and editing config files...
[22:05] <gnrp> new-user: What is your notebook model?
[22:06] <new-user> gnrp it's a flashed Chromebook HP 11 G7 EE
[22:07] <new-user> I found sound synaptics documentation, there's a prop finger setting for pressure sensitivity, will look if it works
[22:08] <gnrp> new-user: That's why I was asking, so I could look up the touchpad model. If it is a synaptic, synclient might help
[22:09] <XubXubXub> i wonder if youre using synclient or libinput
[22:10] <new-user> synclient, gotcha, I will try and report back, thank you!
[22:11] <XubXubXub> I guess libinput has the ability to detect "pressure" or surface area..there must be some way to configure it https://wayland.freedesktop.org/libinput/doc/1.11.3/touchpad_pressure.html
[22:11] <XubXubXub> it sounds like synclient isnt really updated anymore and libinput is taking over
[22:11] <XubXubXub> I found this though https://wayland.freedesktop.org/libinput/doc/1.11.3/touchpad_pressure.html
[22:23] <new-user> synclient FingerLow and FingerHigh did the trick
[22:23] <new-user> it now feels very very responsive
[22:23] <new-user> thank you guys!
[22:24] <new-user> it was 25 and 30 respectively, set it to 5 and 10


[00:00] <jbicha> the webkit2gtk amd64 build might work when we aren't building and autopkgtesting so much stuff, but I'll probably update https://salsa.debian.org/webkit-team/webkit/-/merge_requests/9 for amd64 too tomorrow
[00:01] <Eickmeyer[m]> jbicha: Oh, ok. I have reason to believe it's all related.
[00:07] <jbicha> Eickmeyer[m]: not sure what you mean. But anyway, there are multiple issues with the new mesa. If you're using Intel, this may help: https://launchpad.net/ubuntu/+source/intel-media-driver/22.2.1+dfsg1-1build1
[00:08] <jbicha> it didn't fix my issue but it helps other people :)
[00:08] <Eickmeyer[m]> jbicha: Actually, I'm on both Intel and Nvidia (hybrid laptop).
[00:10] <jbicha> I don't know how to troubleshoot that, but please add details about your graphics cards to that bug
[00:11] <jbicha> if you want to see if your issue was triggered by the new mesa, see my Planet Ubuntu post
[00:13] <Eickmeyer[m]> jbicha: Well, I did attempt to install intel-media-va-driver from proposed, and there was no change in behavior, so I'm not sure it's that.
[00:15] <jbicha> log out and log back in if you didn't. But the rebuilt intel-media-va-driver didn't help me either
[00:16] <Eickmeyer[m]> Yeah, no dice on the relog.
[00:17] <Eickmeyer[m]> ALTHOUGH, this time Evolution showed a crash.
[00:32] <Eickmeyer> jbicha: It's wayland-related.
[08:53] <tjaalton> systemd-timesyncd is installed by default on jammy and up?
[09:01] <seb128> tjaalton, it was already in the focal manifest for desktop
[09:01] <seb128> so not new
[09:02] <tjaalton> oh
[09:03] <tjaalton> I don't have it installed
[09:03] <seb128> tjaalton, sudo apt install ubuntu-desktop^ :)
[09:03] <tjaalton> though I probably used 19.10 to install
[09:04] <Unit193> Huh, thought chrony was, OK.
[09:16] <cpaelzer> Unit193: chrony is the default if you need a time-server or the more sophisticated behavior of chrony
[12:02] <ahasenack> morning
[16:04] <bdmurray> seb128: Will the desktop team be looking at bug 1966317?
[19:38] <mwhudson> for go snap users btw https://twitter.com/mwhudson/status/1508964109274218501
[19:41] <rbasak> ubuntu-devel-announce@ moderation please
[20:04] <bdmurray> rbasak: I'll do the moderation
[20:07] <mwhudson> dbungert, mclemenceau, bdmurray: apparently i can't access any canonical system currently, i think my ISP has messed up their routing or something
[20:08] <mwhudson> oh nm
[20:28] <rbasak> Thanks!
[20:40] <rbasak> !dmb-ping is ddstreet, rbasak, sil2100, teward, bdmurray, kanashiro, seb128: DMB ping
[20:40] <rbasak> ?
[20:41] <rbasak> Unit193: ^ help please?
[20:44] <teward> !no dmb ping is ddstreet, rbasak, sil2100, teward, bdmurray, kanashiro, seb128: DMB ping
[20:44] <teward> oops
[20:44] <teward> !no dmb-ping is ddstreet, rbasak, sil2100, teward, bdmurray, kanashiro, seb128: DMB ping
[20:45] <teward> rbasak: ops just has to approve it
[20:46] <rbasak> Thanks!
[21:13] <tomreyn> rbasak, teward: that's updated
[21:13] <teward> tomreyn: thank you!
[21:13] <tomreyn> you're welcome :)


[01:18] <cjwatson> cjohnston: Any idea why http://status.ubuntu.com/ubuntu-quantal/canonical-foundations.html hasn't updated in over a day?
[04:58] <pitti> Good morning
[04:59] <ajmitch> morning pitti
[06:28] <geser> good morning
[07:01] <dholbach> good morning
[07:41] <dholbach> hey pitti, so the translations in /opt problem was not a gtk problem after all?
[07:42] <pitti> dholbach: I didn't hear any news about this since yesterday
[07:42] <dholbach> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=676543#c4
[07:43] <dholbach> seems we need to document it properly, so apps authors know how to special-case shipping in /opt :-/
[07:44] <pitti> ah :)
[07:44] <pitti> what a bad trap to fall into
[07:44] <pitti> I thought gettext.bindtextdomain() would actually set it in glibc
[07:45] <dholbach> yeah, it's a bit unpleasant
[09:07] <alexbligh1> When building a package, what is the approved dh_ method of installing files with an owner other than root?
[09:07] <alexbligh1> (specifically in this case into /etc)
[09:11] <pitti> alexbligh1: call dh_fixperms with some -X options to ignore these files
[09:11] <alexbligh1> pitti, thanks
[09:11] <pitti> alexbligh1: haven't (recently) tested that myself, but it ought to work
[09:11] <pitti> alexbligh1: HOWEVER
[09:12] <pitti> alexbligh1: this is only valid if the files you ship are owned by a static system user, i. e. uid < 100
[09:12] <alexbligh1> pitti, but how do I get them owned by non-root in the first place?
[09:12] <pitti> alexbligh1: for a dynamic system user (created with add_user), you need a postinst which calls chown for you
[09:12] <alexbligh1> (it's www-data)
[09:12] <pitti> ok, www-data is a static one, that works
[09:13] <alexbligh1> Currently I am doing a chown -R in my postinst, but I worry that when I next install the package, it will think the user has changed the perms, and not update the file.
[09:13] <pitti> alexbligh1: chown?
[09:13] <alexbligh1> owner
[09:13] <alexbligh1> yes
[09:13] <alexbligh1> pitti, ah, dh_fixperms is permissions. I need *owner*
[09:14] <pitti> alexbligh1: yes, what I said; your "make install" or whatever chowns them to www-data, and then you tell dh_fixperms to not change it back to root
[09:14] <pitti> alexbligh1: dh_fixperms sets files to root:root by default
[09:15] <alexbligh1> is the chown in postinst safe? Or might it have problems as set out above in upgrading? chown seems far easier
[09:16] <pitti> alexbligh1: you should check dpkg-statoverride if you reapply them on upgrade
[09:16] <pitti> alexbligh1: but you can just call chown if [ -z "$2" ], i. e. on first install
[09:17] <alexbligh1> pitti, thanks
[09:49] <apw> pitti, hey ... have we manually overridden the ddeb remover?  it seems that the natty release kernel ddebs are gone?
[09:50] <pitti> apw: yes; we again ran out of space :/
[09:50] <pitti> and since the RT to add more is still pending, I needed some drastic measures :(
[09:50] <pitti> otherwise we would have lost quantal
[09:51] <pitti> so we now have lucid, oneiric, precise, and quantal
[09:51] <Daviey> pitti: does the RT have suitable levels of priority attached to it?
[09:52] <apw> pitti, should we need them does IS have them on backup somewhere ?
[09:52] <smb> Like lava-hot-burning-ass ?
[09:53] <pitti> https://rt.admin.canonical.com/Ticket/Display.html?id=52633
[09:53] <pitti> Priorität: 0/
[09:53] <pitti> I guess not
[10:04] <diwic> apw / pitti, can't we just rebuild the package with pkg-create-dbgsym installed?
[10:05] <diwic> If there's a particular package we desperately need it for.
[10:05] <apw> diwic, perhaps, am trying it now, but th
[10:05] <apw> the old 3.x/2.6.x issue is biting me as the kernel is sooooo old
[10:13] <apw> infinity, when we did --uname-2.6 stuff did schroot gain a personality type for it too ?
[10:26] <cjwatson> apw: setarch x86_64 --uname-2.6 schroot ... #  ?
[10:26] <cjwatson> I guess that's less convenient than schroot knowing for itself
[10:27] <apw> cjwatson, yeah, the chroot kind knows for 32bit so it seems orthoganal to have it inside but yes linux64 --uname-2.6 seems to work ok for me
[10:30] <cjwatson> I don't see support for any of the personality options in schroot, anyway
[10:44] <jamespage> vibhav: (late response) I don't think that bug is effected by the perl version - just the memory monitor one we did for precise
[11:10] <Caribou> apw: pitti: what's the best way / less disruptive way to mirror an archive ?
[11:10] <Caribou> the kernel ddebs are only 120Gb, I'll make a copy somewhere
[11:11] <pitti> Caribou: debmirror is reasonably easy to use and quite robust, AFAIK
[11:11] <pitti> I had used it years ago, but not recently
[11:12] <Caribou> pitti: ok, I'll try that, thanks
[11:15] <pitti> :w
[11:15] <pitti> err, EFOCUS
[11:16] <dholbach> popey, wow - so you're going to maintain the unity/bamf/etc packages now? :)
[11:20] <popey> thanks ☺
[11:20] <popey> (I think)
[11:20] <dholbach> :-)
[11:21] <cjwatson> wookey_: dunno if you noticed, but libc6-dev/armhf should be happier now, thanks to Adam
[11:23] <xnox> http://www.gtk.org/ got a new layout with 'Avatar'-like tubes hanging of it, interesting.
[11:23] <xnox> just noticed....
[11:53] <seb128> bdmurray, is bugbot your bot?
[11:53] <seb128> why did it tag https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1001249 "lucid"?
[11:53] <seb128> it's a precise user
[12:08] <wookey_> cjwatson: I hadn't. but yes I see a -12 now. That should come through in tomorrow's build results. (which I've just noticed say 'armle' even though they are armhf. That's rebuildd being thick (and currently hacked somewhat) I think.
[12:10] <dupondje> could anyone upload https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/1000356 for me? Will check for SRU also
[12:16] <vibhav> Who has the upload rights to main?
[12:18] <sladen> vibhav: https://launchpad.net/~ubuntu-core-dev + per-package-uploads
[12:19] <vibhav> thanks
[12:22] <cjwatson> mvo: Does http://bugs.debian.org/674338 ring any kind of bell for you?  It seems like it's probably an apt bug ...
[12:23] <mvo> cjwatson: yes, its a recent regression with python-apt/apt in debian/unstable
[12:25] <cjwatson> mvo: Do you happen to have the bug number to hand?
[12:25] <cjwatson> That said the strace seems to suggest that the EBADFs are in dealing with a seed file ...
[12:26] <tjaalton> is the relaxed sru policy still under review, or is there hope for bugfix release sru's for precise sometime soon?
[12:27] <cjwatson> My code looks OK though, perhaps some coincidental interaction
[12:30] <mvo> cjwatson: not right now, but I hope to find time to work on it today, juliank did figure out the issue already
[12:31] <smoser> stgraber, around ?
[12:31] <cjwatson> mvo: ok, cool, I've lobbed the bug over to python-apt as a first step
[12:31] <mvo> ok
[12:32] <juliank> cjwatson: It's a simple bug where apt passes a file descriptor to gzip, which closes it automatically, whereas the descriptor should not be closed automatically (unless requested so using an AutoClose flag in APT's FileFd)
[12:33] <cjwatson> OK
[12:34] <cjwatson> I like it when my test failures turn out not to be my fault
[12:35] <mvo> :)
[12:58] <xnox> stgraber: rumour has it you run ubiquity from lxc container for testing is that true?
[13:04] <seb128> SpamapS, hey
[13:16] <Bluefoxicy> what ever happened to deb patching anyway?
[13:16] <Bluefoxicy> somebody changes 1 line of code in libreoffice and you have 6 packages to update and 300MB to download
[13:17] <Bluefoxicy> Hell, somebody changes a 'recommends' to 'suggest' in LibreOffice and you have 6 packages to updated and300MB to download
[13:19] <zul> mterry: ping
[13:19] <mterry> zul, pong
[13:20] <zul> mterry: we have a couple of MIR that are blocking us, dwarves-dfsg, python-jsonschema, and python-repoze.lru can they be looked at toute suite?
[13:21] <zul> its also blocking some SRUs as well
[13:24] <dobey> oi i need to do some MIRs
[13:24] <mterry> zul, OK.  What's the SRU connection?
[13:25] <zul> mterry:  dwarves-dfsg is libvirt and python-jsonschema, python-repoze.lru (new deps for python-routes) is glance related
[13:25] <pitti> mterry: speaking about MIRs, are you aware that your openal-soft merge introduced quite a few new universe deps?
[13:27] <mterry> pitti, aw darn it.  I forgot to check for that
[13:28] <pitti> I created some MIRs for many other universe deps after the intial debian syncs/merges, and also dropped a few dependencies
[13:28] <mterry> zul, sorry, am still confused.  Why does an SRU for precise care which component a quantal package is in
[13:29] <zul> mterry: because we need to fix glance in quantal in order to start an SRU for it and its blocked on jsonschema not being in main, and python-repoze.lru being a new build deps for python-routes
[13:31] <mterry> zul, OK, can start looking now
[13:31] <zul> mterry: thanks
[13:38] <stgraber> smoser: around now
[13:39] <stgraber> xnox: yes, I run part of ubiquity in containers on my machine, though I doubt it'll work for you as I'm guessing you're working on partitioning and there isn't much we can fake from a container for that part
[13:39] <xnox> =(
[13:39] <xnox> ok
[13:39] <xnox> thanks
[13:40] <xnox> stgraber: do you get point & click interface though? =)
[13:40] <stgraber> xnox: yes
[13:41] <smoser> stgraber, i think i was going ot ping about bug 993794
[13:41] <smoser> but i then realize its not actually a resolvconf issue, but really more network manager's issue
[13:42] <stgraber> smoser: yeah, that has to do with the way dnsmasq balances the requests between the servers, I believe it mostly happens when the secondary servers answer faster than the primary one
[13:43] <smoser> well, its a generic issue. not related to speed really.
[13:44] <stgraber> well, in theory dnsmasq will send the request to the server with the lowest latency, so if you primary server is the fastest one, you'll get the right record back
[13:46] <tseliot> pitti: I'm trying to build ubuntu-drivers-common in my quantal chroot: http://paste.ubuntu.com/1004747/
[13:48] <pitti> tseliot: hmm, thanks; I tried to build an earlier version in my PPA successfully, but that was two days ago already
[13:50] <pitti> tseliot: that's with latest aptdaemon, I presume? 0.43+bzr810-0ubuntu3 ?
[13:56] <tseliot> pitti: let me check
[13:57] <mterry> zul, for python-repoze.lru, is there a reason to not sync back up with Debian (we added delta to run tests, but added "|| true" because the tests failed on buildd) -- could we be more selective with tests that don't need network access?
[13:58] <zul> we could be more selective
[13:58] <zul> mterry: but im not sure how
[14:00] <tseliot> pitti: the chroot used aptdaemon_0.43+bzr810-0ubuntu3
[14:00] <pitti> tseliot: ok, thanks; I'll build a chroot here to replicate this
[14:02] <tseliot> ok, thanks
[14:14] <pitti> tseliot: so, a local dpkg-buildpackage still works fine here; I need to run out for a bit, but letting that chroot build in the meantime
[14:15] <tseliot> pitti: ok, I'll try that
[14:15] <slangasek> roaksoax: you appear to have dropped the dh_python2 delta in python-xattr by syncing it - this is not ok, python-support is package non grata in main.  Can you please move this back to dh_python2?
[14:20] <roaksoax> slangasek: ah yes, my bad.. missed the fact that python-support was a Dep, while the package was being build with python2 from debian. :) Thanks for noticing
[14:21] <slangasek> roaksoax: the components-mismatches report makes us notice ;)  thanks in advance for fixing :)
[14:23] <roaksoax> slangasek: :) is this sent over the ML?
[14:23]  * roaksoax needs to wake up... need more coffee
[14:24] <stgraber> roaksoax: that's sent to the ubuntu-release ML
[14:25] <roaksoax> stgraber: cool thanks
[14:25]  * roaksoax needs to update his spam filters :)
[14:26] <roaksoax> and subscribe to it
[14:34] <tseliot> pitti: building it locally inside a chroot: http://paste.ubuntu.com/1004842/
[14:40] <SpamapS> seb128: hey back. :) Whats up?
[14:42] <seb128> SpamapS, is there any way you could review 2 SRU candidate for me today?
[14:44] <seb128> SpamapS, unity and bamf in precise (unapproved), those are overdue and I would really get them out before the w.e but not on friday in case there is any issue...
[14:45] <seb128> SpamapS, if you don't have time I will try with chance with slangasek or infinity next ;-)
[14:45] <seb128> SpamapS, hey btw, how are you? ;-)
[14:46] <bdmurray> seb128: that's bryce's bot
[14:47] <seb128> bdmurray, thanks
[14:47] <seb128> bryceh, hey, how is you bot deciding that a bug should be tagged "lucid"? it tagged a precise report "lucid" ;-)
[14:47] <slangasek> seb128: why is friday a concern for pushing to -proposed?  (not that I don't think we shouldn't get them out ASAP)
[14:48] <seb128> slangasek, "I'm there for too long", "french paranoia", "pick something that doesn't make sense to others" :p
[14:48] <seb128> slangasek, basically just me being paranoid about friday uploads
[14:49] <slangasek> seb128: well... it's -proposed, we don't require or warrant them to be regression-free at that point :)
[14:49] <seb128> right, I still like to be around and to be able to deal with any issue if there would happen to be one
[14:50] <SpamapS> seb128: I'll do as many reviews as I can today. Will start in about 1 hour.
[14:50] <seb128> SpamapS, thanks
[14:51] <SpamapS> seb128: lots of uploads from kde update too, so the queue is getting backed up
[14:51] <seb128> SpamapS, well as said I would appreciate to get that unity one out, it's over due and fix some annoying bug in the default desktop on the lts
[14:52] <seb128> SpamapS, the other desktopish ones from me have lower priority
[14:52] <seb128> SpamapS, (bamf is included in the "unity update set" btw)
[14:54] <slangasek> SpamapS, seb128: let me go ahead and queue-jump those two
[14:54] <seb128> slangasek, thanks! ;-)
[14:54] <slangasek> seb128: btw, do all of the changelog-referenced bugs have test cases in the description?  I'm going to be a hard-nose about that going forward :)
[14:55] <seb128> slangasek, yes, though the format is not strict, i.e they don't all start with TESTCASE:, but they all have steps to trigger the issue and what to test in the description
[14:55] <slangasek> ok, sounds good
[14:56] <seb128> slangasek, didrocks has been strict on that, that's one of the reasons the SRU is coming a bit later in the week that planned ;-)
[14:56] <slangasek> cool ;)
[15:09] <SpamapS> slangasek: thanks :)
[15:25] <pitti> tseliot: ok, I get the same errors in my pbuilder
[15:25] <tseliot> pitti: I hope those errors make sense to you
[15:26] <tseliot> I really don't know what's going on
[15:27] <pitti> tseliot: they don't make sense to me yet, looking now
[15:28] <tseliot> hehe, ok
[15:37] <dupondje> could anyone upload https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/1000356 for me? Should be SRU'ed also
[15:38] <seb128> dupondje, try asking chrisccoulson or mterry they are patch pilot today according to the schedule
[15:38] <seb128> doh, though chrisccoulson still didn't apply for upload rights I think
[15:38] <chrisccoulson> i'm meant to be patch pilot today? :/
[15:39] <chrisccoulson> man, i suck ;)
[15:39] <dupondje> come on!
[15:39] <dupondje> :D
[15:39] <chrisccoulson> why do my patch pilot days always collide with firefighting?
[15:39] <seb128> chrisccoulson, yes you are! didn't google calendar email you? ;-)
[15:39] <micahg> remmina is in desktop
[15:39] <mterry> seb128, I will patch pilot, but I'm busy doing MIRs to unblock people now.  :(
[15:39] <seb128> chrisccoulson, is there any day you are not firefighting?
[15:39] <mterry> dupondje, I will look at it later today if chrisccoulson doesn't first
[15:39] <seb128> mterry, no hurry ;-)
[15:40] <pitti> tseliot: ooh, it makes perfect sense now
[15:40] <tseliot> pitti: what is it?
[15:41] <pitti> -    @unittest.skipUnless(os.path.isdir('/sys'), 'no /sys dir on this system')
[15:41] <pitti> +    @unittest.skipUnless(os.path.isdir('/sys/devices'), 'no /sys dir on this system')
[15:41] <pitti> tseliot: pbuilders/chroots have an empty /sys
[15:41] <pitti> but it tries to access /sys/devices/
[15:41] <dupondje> micahg: its bug in FreeRDP lib :)
[15:41] <tseliot> pitti: ok, that would explain it
[15:42] <pitti> tseliot: pushed
[15:42] <micahg> ah, yeah, freerdp is in core
[15:42] <pitti> tseliot: I get some more errors in my pbuilder, but these two are the ones you got
[15:42] <dupondje> Would like to fix some more things in Remmina/FreeRDP later on
[15:42] <dupondje> cause there seems to be alot of complaints
[15:42] <tseliot> pitti: can I pull the code? (in my local branch)
[15:43] <dupondje> broken things :(
[15:43] <pitti> tseliot: yes, I pushed to my branch on github
[15:43] <pitti> tseliot: perhaps wait a bit with merging it into your official one until it's working?
[15:43] <tseliot> pitti: yes, that's just for testing things locally
[15:44] <pitti> tseliot: "GError: Query type 'modalias' is not supported" means that the PackageKit plugin crashed; I'll try to get a better error message out of that
[15:45] <pitti> in fact, I already have some provision for that: setting APTDAEMON_LOG and APTDAEMON_DEBUG in tests/ubuntu_drivers.py
[15:46] <tseliot> pitti: it builds here. Maybe add packagekit-backend-apt to the dependencies?
[15:46] <pitti> oh, that's separate now?
[15:47] <pitti> tseliot: hm, I'd need python-aptdaemon.pkcompat | (packagekit && packagekit-backend-apt)
[15:47] <pitti> I guess that expands to pkcompat || packagekit, pkcompat || p-backend-apt
[15:47] <pitti> (deMorgan, was it not?)
[15:47] <pitti> ah, now I see what's wrong with the other tests
[15:48] <tseliot> ok
[15:50] <tseliot> pitti: shall I just test it with jockey-text?
[15:51] <pitti> tseliot: shoudln't matter which jockey frontend you use
[16:00] <tseliot> pitti: I don't think it can be tested in a chroot as it looks for the result of "uname -r" which doesn't match the kernel in the chroot: http://paste.ubuntu.com/1004953/
[16:00] <tseliot> (which is 3.4)
[16:01] <pitti> tseliot: oh, you mean jockey, not ubuntu-drivers?
[16:01] <pitti> tseliot: yes, ubiquity calls it with -k <kernel>
[16:01] <pitti> that overides uname -e
[16:01] <tseliot> pitti: yes, which I need to test ubuntu-drivers, no?
[16:01] <pitti> err, -r
[16:01] <tseliot> ah
[16:02] <tseliot> pitti: sudo jockey-text -l --no-dbus -k 3.4.0-3-generic doesn't seem to work
[16:05] <tremolux> slangasek: just fyi, we uploaded a software-center <IP_ADDRESS> for precise SRU that targets just the two issues, per our discussion yesterday
[16:07] <tremolux> slangasek: I did most of the verifies yesterday, I'll finish the last of them for <IP_ADDRESS> soon
[16:08] <pitti> tseliot: ok, now fully builds for me as well; pushed a small fix again
[16:09] <tseliot> pitti: good. How shall I test it now?
[16:10] <pitti> tseliot: would you be ok with pulling this into git, and me uploading the current trunk?
[16:10] <tseliot> pitti: sure, feel free to make a pull request and to upload
[16:12] <zul> mterry:  repoze fixed now i think
[16:12] <mterry> zul, awesome
[16:15] <cjohnston> cjwatson: I believe its due to the cron not being turned back on after having it off for a bit for some troubleshooting.. an oversite most likely.. I have requested from IS that it be investigated..
[16:21] <jamespage> doko: OK with you if I sync nmap from Debian?  delta no longer required (Debian have moved to dh_python2)
[16:21] <cjwatson> cjohnston: thanks
[16:21] <pitti> tseliot: argh, got disconnected
[16:22] <tseliot> pitti: sure, feel free to make a pull request and to upload
[16:22] <cjohnston> cjwatson: its re-enabled
[16:22] <cjwatson> great
[16:22] <pitti> tseliot: ah, thanks
[16:22] <cjohnston> thanks for pointing it out
[16:23] <pitti> tseliot: https://github.com/martinpitt/ubuntu-drivers-common/commits/master now has the release tag as well
[16:23] <pitti> tseliot: pull request sent
[16:23] <cjwatson> cjohnston: How frequently does it normally run, and how long does it generally take to update?  Just so I know how long to wait before reporting something in future ...
[16:24] <cjohnston> cjwatson: its now at every three hours :-(
[16:24] <tseliot> pitti: merged, thanks
[16:24] <cjohnston> so it could be up to 6 hours from now in theory
[16:24] <pitti> tseliot: uploaded
[16:24] <pitti> tseliot: thanks for testing it!
[16:24] <tseliot> \o/
[16:24] <cjwatson> cjohnston: Fun
[16:25] <cjohnston> cjwatson: it should be brought up for discussion during the release meeting
[16:25] <cjohnston> it needs some love
[16:25] <cjohnston> i most likely wont be there for it, but pitti seb128 and skaet are all aware of the issue
[16:27] <pitti> tseliot: would it be possible for me to directly commit to the official branch?
[16:28] <tseliot> pitti: let me check
[16:28] <pitti> tseliot: I can e. g. commit to packagekit, hughsie gave me access
[16:29] <pitti> tseliot: Admin -> Collaborators perhaps?
[16:29] <tseliot> pitti: I've just done that. Can you see if you have access?
[16:30] <pitti> tseliot: yep, page grew an "ssh" checkout now; thanks!
[16:30] <tseliot> pitti: excellent :)
[16:34] <pitti> good night everyone!
[16:40] <mterry> zul, hiyo.  In python-jsonschema, you write that it's "An(other) implementation of JSON Schema".  Are there others?  Presumably none in main yet?
[16:41] <zul> none in main yet
[17:02] <mterry> zul, your patch for repoze.lru just comments out the tests, which doesn't seem like a real fix.  Do we know why they are failing?
[17:03] <zul> mterry: no they work fine locally but not in the buildds
[17:05] <mterry> zul, if they are provably bogus failures, that's one thing (and the patch should document why), but it's not clear these are completely bad tests (or at least, just need some grease to work in the buildd).
[17:06] <zul> mterry: so document the patch and try to get a real fix later?
[17:08] <mterry> zul, I meant the patch should document why the tests are provably bogus.  We don't have enough information to document it one way or the other
[17:09] <mterry> zul, I'd like either a real fix or a real explanation for why they are failing in buildd and why it's OK to ignore them
[17:09] <zul> mterry: i dont have enough information for you why they are failing but this is blocking python-routes which is blocking glance f1
[17:11] <zul> and i dont have enough experience with repose.lru either
[17:13] <mterry> zul, so once you get this in main, you update glance, and then how does that work with precise?  You're not moving python-repoze.lru in precise, right?
[17:14] <zul> mterry: no we arent just quantal
[17:14] <mterry> zul, so you're selectively backporting parts of glance to precise?  But you still need the version update in quantal before you backport?
[17:15] <zul> mterry:  yes and yes
[17:15] <zul> but repoze.lru is not a requirement for precise
[17:16] <mterry> zul, can your team commit to fixing the test stuff before alpha 1?  (I'm OK with waving my hands at the tests for now, but they shouldn't stay broken)
[17:17] <mterry> (and by fix, it may just mean explaining why buildd's can't reasonably run those tests)
[17:18] <zul> mterry: yes i can commit to fix the test stuff before alpha1
[17:18] <mterry> zul, cool.  I'll file a bug for that and assign it to the server team (or you?)
[17:18] <zul> mterry:  preferably me :)
[17:23] <mterry> zul, cool, approved that one then.  Just the dwarves one has problems then, I believe
[17:29] <zul> mterry: yeah ill have a look after im done here
[17:30] <henrix> pitti: any chance of having someone looking at kernel linux-ec2: 2.6.32-345.48 ?
[17:31] <hallyn> slangasek: regarding /dev/shm (set up by initscripts), I notice that sid has /dev/shm as a bind mount of /run/shm;  precise has it as a symlink.  Is that difference intended?
[17:31] <hallyn> (it affects whether sid's initscripts postinst can be deemed broken or not)
[17:31] <henrix> pitti: we have the next kernel ready to upload, but we can't do it before this one is moved away from proposed
[17:32] <slangasek> hallyn: a bind mount?  surely that's only in a chroot?
[17:32] <hallyn> nope
[17:32] <hallyn> amazon ami
[17:32] <slangasek> hallyn: or prior to the first reboot?
[17:32] <slangasek> er
[17:32] <slangasek> then I think the ami was built wrong
[17:32] <hallyn> feh
[17:33] <slangasek> the bind mount is supposed to be a temporary "until next reboot" measure in the upgrade handling
[17:33] <slangasek> after which it should be replaced by a symlink on shutdown
[17:34] <hallyn> hm. lemme look through its init
[17:36] <hallyn> yeah maybe i need to reboot the ami
[17:39] <hallyn> except of course it doesn't want to reboot
[17:43] <hallyn> slangasek: phew, right you are.  (for some reason after reboot /proc didn't get mounted, but I'll assume that's not my problem for now - instance badness)
[17:43] <hallyn> so /dev/shm after reboot -> /run/shm.
[17:43]  * slangasek nods
[17:47] <mterry> @pilot in
[17:52]  * dholbach hugs mterry
[17:52] <seb128> jcastro, you got your chrome unity fix in proposed, thanks to Trevinho for the fix, popey for the packaging work and slangasek for the SRU processing ;-)
[17:54] <cjwatson> Auto-sync from unstable in progress, as agreed at UDS
[18:00] <bryceh> seb128, it scans for mentions of 'lucid' or '10.04' in description or comments (think it may look in attachments too.)  Certainly it isn't foolproof
[18:02] <seb128> bryceh, ok, the bug description says "it was working on 10.04 but it's not on 12.04" so I guess that's it
[18:02] <seb128> bryceh, you don't use the same logic to tag "precise" if 12.04 is mentioned?
[18:04] <bryceh> seb128, yeah that type of description will get it doubletagged.
[18:04] <seb128> bryceh, well it got only tagged "lucid" in this case
[18:04] <seb128> bryceh, i.e no precise tagging
[18:05] <bryceh> seb128, it should use the same logic for tagging precise; if it isn't then that's a bug.  point me at the bug report and I'll investigate when I get a chance
[18:05] <seb128> bryceh, it's https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1001249
[18:05] <seb128> bryceh, thanks
[18:06] <bryceh> seb128, ah, well to be honest these days I rely more on apport adding the tag when running apport-collect or ubuntu-bug
[18:07] <bryceh> since most of the time if they've filed a report without doing that, their bug usually is not diagnosable anyway
[18:07] <seb128> bryceh, I don't rely on the feature, I was just curious why a precise bug got tagged "lucid"
[18:07] <bryceh> but I'll check my script
[18:08] <seb128> bryceh, thanks, though it's very low priority, I was mostly curious there so don't bother much about it
[18:11] <bryceh> seb128, hah, found it
[18:11] <bryceh> the bot uses brad's kernel lookup table, which hasn't been updated since maverick
[18:11] <bryceh> easy fix...
[18:20] <alexbligh1> pitti, sorry to bother you again with what I was asking earlier. If I install a .deb with conffiles with owner root, then in my postinst chown www-data those files, then at some later date install an upgraded version of the package, will it treat those conffiles as changed (and thus not reinstall them) or will it leave them as it is?
[18:20] <alexbligh1> s/leave them as it is/install the new versions/
[18:22] <alexbligh1> I'm reading this: "Note that a package should not modify a dpkg-handled conffile in its maintainer scripts" <- does this only apply to the contents of conffiles, or also their permissions?
[18:27] <slangasek> alexbligh1: generally applies only to the contents
[18:28] <mterry> dupondje, btw, doing your bug now.  Thanks for the patch!
[18:28] <mterry> dupondje, uploaded to quantal, working on SRU for 12.04
[18:29] <alexbligh1> slangasek, so I am safe to chown conffiles in my postinst? I'm just wondering whether I should should be doing override_dh_install and a chown there at build time...
[18:30] <slangasek> alexbligh1: files are stored in the .deb by numeric uid and you can't rely on that being the same on the build system and target system (sometimes you can't rely on the user existing at all on the build system)
[18:31] <slangasek> well... www-data is actually an exception
[18:31] <slangasek> because it's in /usr/share/base-passwd/passwd.master :)
[18:31] <slangasek> so actually, yes, you can chown them in the package
[18:32] <alexbligh1> slangasek, may be override dh_fixperms then, and do a chown www-data:www-data $(CURDIR)/debian/$(package)/etc/foo
[18:32] <alexbligh1> ?
[18:33] <slangasek> alexbligh1: yep, that works in principle
[18:33] <slangasek> though, I do have to ask, why is www-data supposed to be able to write to these files?
[18:33] <slangasek> we generally try hard to *not* let web apps write their own configs
[18:33] <slangasek> since that tends to lead to security problems rather quickly
[18:36] <alexbligh1> slangasek, they aren't really configs. They're .po files for different translations.
[18:37] <slangasek> so a) why do they need to be owned by anyone other than root? b) why do they belong in /etc/
[18:37] <slangasek> ?
[18:40] <alexbligh1> slangasek, (a) so they can be uploaded through the webserver, (b) well, there are two ways of configuring these, the old way (which involves editing the files), and the new way which involves the pofile being uploaded, sanitised, running msgfmt on it, and putting it somewhere. I really don't want to suid the last process, hence owned by www-data. They are in /etc because we want conffile behaviour on upgrade.
[18:40] <alexbligh1> (so yes they could be elsewhere but I still have the conffile interaction)
[18:49] <slangasek> alexbligh1: well, if you're going to this much trouble to enable them to be updated via the webserver, I think conffiles are the wrong mechanism; it would probably be better to ship these as templates under /usr, and copy them to /var at package install time, letting the webserver update them there
[18:50] <slangasek> tremolux: software-center accepted into -proposed now; and apologies, I had noticed the oddness of the fix for bug #999486 being commented out when reviewing the debdiff for the last one but didn't follow up
[18:51] <slangasek> tremolux: oh, hold up - not accepted just yet
[18:51] <tremolux> slangasek: oh, no worries, yeah, we overlooked that  :/
[18:51] <slangasek> tremolux: hmm - it seems someone has already published 5.2.2 to -updates, that was unexpected
[18:52] <slangasek> <IP_ADDRESS> accepted into -proposed now
[18:52] <tremolux> slangasek: ?? really?
[18:52] <slangasek> yes
[18:52] <slangasek> I don't know who or why
[18:52] <tremolux> slangasek: hmm, not all of the verifies were complete
[18:52] <slangasek> yeah
[18:52] <slangasek> well, it's done now
[18:52] <tremolux> slangasek: but it should not be a problem, we have all of those fixes in trunk and test everyday
[18:52]  * slangasek nods
[18:55] <tremolux> slangasek: so to get <IP_ADDRESS>, we just need do the remaining verifies? (most of the unverified bugs from 5.2.2 were related to the regression and the disabled fix actually)
[18:55] <slangasek> tremolux: yes
[18:56] <tremolux> slangasek: ok, I'll look for it on here and take care of them: http://people.canonical.com/~ubuntu-archive/pending-sru.html
[18:56] <tremolux> slangasek: thanks a lot for your help!
[18:56] <slangasek> tremolux: no problem :)
[19:08] <seb128> bryceh, oh, good, thanks!
[19:20] <seb128> slangasek, s-c, @who; pitti (from -changes), why: I guess it's "90% of the bugs verification-done and no verification-failed or regression signaled on a long list of bugs"
[19:21] <seb128> slangasek, it's sometime tricky to wait that all bugs are confirmed on such updates and if most bugs are verification-done and nobody pointed regression it's better to get moving that to stale
[19:22] <slangasek> well
[19:23] <seb128> slangasek, just saying, and I might be wrong so keep the discussion for pitti if you disagree ;-)
[19:23] <slangasek> honestly, I would rather we be prepared to kick proposed SRUs back out if we can't get full coverage
[19:24] <slangasek> but yeah... the problem here is that tremolux had been talking with me about it, but we didn't actually mark any of the bugs verification-failed to block its promotion
[19:24] <seb128> right
[19:25] <seb128> that's one of the issues pitti raised on the list about SRU team and bug emails flood
[19:25] <seb128> somebody has to watch for any regression mentioned in any of the bugs and set a failed flag somewhere
[19:25] <slangasek> I don't think it was mentioned on the bug
[19:25] <slangasek> on any bug
[19:25] <seb128> slangasek, another issue with such uploads is that apport bugs often have no steps, they are like "they happen randomly to some users", so it's hard to get verification-done
[19:25] <slangasek> we should've flagged it with the tag
[19:26] <seb128> i.e fixed come from guessing from the stacktrace
[19:26] <seb128> but it's hard to find anyone to verify the fix
[19:27] <seb128> we can't block the updates for ever because "obvious code fixes" didn't get verified by anyone
[19:27] <slangasek> yes, well, errors.ubuntu.com will help with that eventually :)
[19:27] <seb128> it helps if we see that the issue stop being reported
[19:27] <seb128> but it means we need a progress tracking for specific issues which I think we don't have yet?
[19:28] <slangasek> yep - hence, "eventually"
[19:29] <tremolux> slangasek, seb128: for bugs that are impossible to consistently reproduce (there were a couple out of about 20 fixes in this SRU), we simply try to provide the steps that can cause it and ask the verifier to do those steps repeatedly..that sort of thing
[19:29] <tremolux> slangasek, seb128: but we are definitely counting on errors.ubuntu.com, because that's where we prioritized them from
[19:30] <seb128> tremolux, right, it's not specific to you, most of the segfaults are like that
[19:30] <seb128> i.e we have g-s-d segfaults which apparently randomly happen at logout in a racy way
[19:31] <seb128> it's hard to test them out of checking that the update creates no regression and watch the reporting status
[19:31] <tremolux> seb128: yep, I see, just clarifying for our case
[19:31] <seb128> stats
[19:31] <tremolux> yes
[19:31] <tremolux> same situation
[19:32] <seb128> slangasek, btw speaking for SRU, shotwell has a SRU with 3 bugs listed, 2 got verification-done, the third one seems to not be enough of a fix but improve things (i.e incomplete fix)
[19:33] <seb128> slangasek, what's the recommend way to mark the remaining bug in a way which doesn't hold the copy to -updates? (no reason since it fixes 2.5 issues and create no regression)
[19:33] <slangasek> seb128: mark it 'verification-done' now, then reset the state after publishing
[19:34] <seb128> slangasek, ok, thanks
[19:41] <hallyn> what assumptions do we make about mounted MOUNTPOINT=/sys versus the rest of the base root filesystem (i.e. /usr/bin)?
[19:42] <hallyn> Can I assume that if /sys is mounted, the programs installed by a package are going to be available?
[19:43] <slangasek> hallyn: no
[19:43] <hallyn> drat
[19:43] <slangasek> hallyn: that's probably going to change this cycle, but you can't rely on it /yet/
[19:44] <slangasek> hallyn: any reason not to just wait for the 'filesystem' event?
[19:44] <hallyn> bug 995956 wants libcgroup to start earlier
[19:44] <hallyn> oh that should be fine
[19:45] <slangasek> hmm, well, 'filesystem' won't usually be much earlier than 'runlevel'
[19:45] <stgraber> hallyn: is there any reason not to get that out of the archive and use cgroup-lite everywhere? last I checked cgconfig was so bad it'd prevent my laptop from resuming (still haven't figured out exactly how it managed that ;))
[19:45] <slangasek> ('runlevel' is basically 'filesystem' + 'network')
[19:46] <slangasek> hallyn: 'start on filesystem' definitely won't do what the bug submitter is asking for... lots of other stuff starts in parallel as soon as the 'filesystem' event fires
[19:47] <hallyn> stgraber: that would be MY preference
[19:47] <hallyn> i don't know why people insist on installing libcgroup :)
[19:50] <dupondje> mterry: thanks alot! more bugkills to come! :)
[19:50] <mterry> :)
[19:52] <jbernard> hallyn: that would be my preference too. Also for debian, that might be the best solution
[19:55] <hallyn> jbernard: i think i've asked this before, but (since you maintain it) what exactly do you need from libcgroup?
[19:56] <dupondje> mterry: won't we need a rebuild of Remmina because of the multiarch lib dirs ?
[19:56] <jbernard> hallyn: if you take out the initscripts, I think the package has some nice features.
[19:56] <hallyn> jbernard: the utilities to manage cgroup settings you mean?
[19:56] <jbernard> hallyn: yes
[19:56] <hallyn> my main beef actually is not the initscripts but the daemon, which cannot deliver on its promises :)
[19:57] <jbernard> i agree completely
[19:57] <mterry> dupondje, probably, yes.  Not for 12.04, but for 12.10
[19:57] <hallyn> the submitter of the above bug was also askign for some tools to change settings
[19:57] <jbernard> the utilities are useful, but the daemon is a nightmare
[19:57] <mterry> dupondje, it should find them in both locations I think
[19:57] <hallyn> jbernard: so perhaps on top of the cgroup-lite package we should add a cgroup-mgmt package with whatever tools you like/need to use?
[19:58] <dupondje> ah but you didn't do the multiarch stuff for 12.04 ?
[19:59] <jbernard> hallyn: that would work well for me, but i don't know how many people rely on the daemon
[19:59] <jbernard> hallyn: it seems like a great idea to me, remove cgroup-bin, replace with cgroup-lite + additional utils
[20:02] <hallyn> jbernard: would that scratch a big enough itch for you to want to make a debdiff adding a cgroup-lite-mgmt package?  :)
[20:04] <jbernard> jbernard: i think so, it's also an appealing way to re-sync the ubuntu package with the debian one
[20:16] <jbernard> hallyn: in which bug is the user requesting additional managment utilities?
[20:19] <mterry> @pilot out
[20:20] <hallyn> jbernard: bug 995956
[20:39] <dupondje> bdmurray: about the remmina clipboard bug. Some people commented on the bugreport when they had crashes + on the upstream tracker. I also got some emails. All those crashes got fixed. And didn't had any reports anymore. Alot of people confirm its working fine.
[20:39] <dupondje> I'm also using it myself, and having no issues :)
[20:42] <dylan-m> Hey, mterry, do you know any examples of packages with that reboot-required metadata in their control files?
[20:42] <dylan-m> I can't find anything about it, but that's probably because I don't know where to look ;)
[20:42] <broder> dylan-m: network-manager
[20:43] <broder> i don't think there's any metadata mechanism currently, unless one got added
[20:43] <broder> you run a script which sets a flagfile
[20:51] <slangasek> bdmurray: is the security bug that let apt passwords into attachments fixed now?  (for all releases?)
[20:52] <slangasek> bdmurray: I ask because I see the bot still removing attachments
[21:04] <dmitrii> negronjl: thanks for helping iamfuzz with the partition devices problem
[21:04] <dmitrii> negronjl: I am the one seeing this on Precise: http://paste.ubuntu.com/1005486/
[21:05] <JordiGH> Is there a way to contact someone on Launchpad if they didn't provide an email?
[21:05] <JordiGH> I want to contact this guy: https://launchpad.net/~picaso
[21:05] <slangasek> you can click the "contact this user" button
[21:05] <JordiGH> He backported Octave to the PP release.
[21:05] <JordiGH> slangasek: I don't see anything there for contacting them.
[21:06] <slangasek> are you logged into launchpad?
[21:06] <JordiGH> Yes, it says no public email
[21:06] <JordiGH> C'mon, Steve, help me out. :-)
[21:06] <slangasek> well, there is a "contact this user" button; I don't know why you don't have it if you're logged in
[21:06] <JordiGH> Ah, it's top right.
[21:06] <JordiGH> Had to grep for it.
[21:09] <bdmurray> slangasek: just because its fixed doesn't everyone installed it
[21:10] <slangasek> bdmurray: certainly... does that mean, though, that we're not going to have any apt clone tarballs at all in bug reports for the foreseeable future?
[21:10] <slangasek> in theory those are important for reproducing upgrade bugs
[21:10] <bdmurray> right, I heard cjwatson say that too
[21:16] <slangasek> anyone know where the packages for "ubuntu satanic edition" are?  I think one of them has called dpkg --sacrifice-goat >> plymouth
[21:16] <bdmurray> slangasek: in the bug mvo indicated he would work on a proper fix that scans data first
[21:16] <slangasek> bdmurray: ok
[21:17] <bdmurray> slangasek: I think at ubuntusatanic.com
[21:17] <azeem> bdmurray: noooo, http://ubuntusatanic.org/
[21:17] <slangasek> http://ubuntusatanic.org/hell/
[21:17] <slangasek> what an obvious name for a repository
[21:18] <azeem> and it has a ad banner for MS Dynamics
[21:18] <bdmurray> slangasek: I might look at fixing the aptclone stuff too
[21:18] <slangasek> bdmurray: that would be keen
[21:25] <adam_g> how do i go about opening and pushing to a -proposed branch for a precise package that is getting its first update?
[21:28] <stgraber> adam_g: you can't get the -proposed branch until at least one SRU was uploaded. So the first one you need to dput without commiting to bzr first
[21:29] <adam_g> stgraber: ahhh gotcha, thanks
[22:04]  * slangasek blinks at the follow-up to bug #1004121
[22:04] <slangasek> I certainly did not expect that
[22:55] <tumbleweed> the new merges.u.c is too fast. it gets ahead of the LP importer which breaks my oldmerges page :)
[22:55] <slangasek> heh
[22:56]  * tumbleweed guards against that. such merges are *not* old


[05:15] <didrocks> good morning
[06:50] <seb128> good morning desktopers
[06:51] <didrocks> re seb128
[06:51] <seb128> re didrocks :-)
[06:58] <willcooke> morning desktoppers
[06:59] <seb128> hey willcooke
[06:59] <TheMuso> Hey willcooke, hey folks.
[06:59] <willcooke> hey TheMuso!
[06:59] <seb128> hey TheMuso
[07:00] <willcooke> Hrm
[07:00] <willcooke> TheMuso, are we due to meet this week?
[07:00] <willcooke> I think the 1:1s in my calendar have started to vanish
[07:01] <willcooke> ohhhhhhhhhhhhhh
[07:01] <willcooke> hehehe
[07:01] <willcooke> When I created them I set them to repeat for 52 weeks by the looks of things
[07:01] <didrocks> good morning willcooke
[07:01] <willcooke> so I guess that means I've been here a year.
[07:01] <didrocks> hey TheMuso
[07:01] <willcooke> hey didrocks
[07:01] <didrocks> congrats willcooke ;)
[07:01] <willcooke> \o/
[07:02] <willcooke> didrocks, speaking of 1:1s - can I move ours?  I have a clash.
[07:02] <TheMuso> willcooke: Yes showing up here.
[07:02] <willcooke> I can move it earlier or later by 30 mins
[07:02] <willcooke> TheMuso, cool, I just reset it to not end...
[07:02] <didrocks> willcooke: earlier is better
[07:02] <willcooke> I'd better check the others
[07:02] <willcooke> didrocks, done
[07:03] <didrocks> great ;)
[07:09] <jhenke> hi folks. The recent 8.1 release of ownCloud server does not allow owncloud-client < 1.7 to sync files. I have filed bug 1477421 about this. Would you consider backporting owncloud-client from wily to odler releases to make it work again?
[07:15] <seb128> jhenke, hey, it's not really a desktop topic, that seems like a valid reason for an update though
[07:36] <willcooke> TheMuso, ready when you are
[07:48] <TheMuso> willcooke: Ok, jumping into the hangout now.
[07:48] <jhenke> seb128 thanks, I will ask #ubuntu-devel then
[08:05] <Laney> hey hey
[08:06] <didrocks> morningning Laney
[08:09] <Laney> 7~hey didrocks
[08:09] <Laney> 7~!!!!
[08:09] <Laney> what's up?
[08:09] <didrocks> and more importantly, why not 8? :)
[08:38] <seb128> nice, mir boottest are ok now
[08:38] <seb128> it got hit by the autopilot issues though
[08:38] <seb128> that makes ubuntu-system-settings-online-accounts  fails
[08:44] <Laney> nice
[08:45] <Laney> I just tested that
[08:45] <Laney> gonig to ack it
[09:10] <seb128> Laney, great
[09:25] <seb128> anpok_, ^ btw for info
[09:27] <anpok_> seb128: hu?
[09:27] <anpok_> usc failed..
[09:27]  * anpok_ crawls back into his abi cave.
[09:28] <seb128> anpok_, it seems a setup issue
[09:29] <seb128> I wanted to kick a retry earlier, but connecting to the vpn from nm in wily doesn't work for me
[09:30] <anpok_> seb128: usc fails now because boottest does not update the graphics driver..
[09:30] <seb128> I get a "VPN connection disconnected because the VPN service has been halted"
[09:30] <seb128> oh? :-(
[09:30] <seb128> Laney, is vpn connection from n-m working for you in wily?
[09:31] <Laney> yep
[09:31] <seb128> I'm not asking didrocks since he's on vivid
[09:31] <seb128> hum, k
[09:31] <Laney> I use it most days
[09:31] <Laney> sorry :(
[09:31] <seb128> Jul 23 11:30:02 localhost nm-openvpn[20232]: MANAGEMENT: Socket bind failed on local address [AF_INET]<IP_ADDRESS>:1194: Address already in use
[09:32] <seb128> Jul 23 11:30:02 localhost NetworkManager[794]: <warn> error disconnecting VPN: The name org.freedesktop.NetworkManager.openvpn was not provided by any .service files
[09:32] <seb128> weird
[09:32]  * didrocks was unsure what this "I'm not asking" was about
[09:32] <didrocks> if you are not asking, don't ask, no need for hilighting :p
[09:33] <Laney> we didn't want you to feel left out
[09:33] <seb128> didrocks, it was in case you upgraded to wily since the other day :-)
[09:33] <seb128> and that
[09:34] <didrocks> seb128: so, ask it the other way if I upgraded then please ;)
[09:34] <seb128> didrocks, do you have a wily install with vpn configured? if so does connecting from n-m works for you?
[09:35] <didrocks> seb128: and now I can answer you "no" :)
[09:35] <seb128> :-)
[09:36] <seb128> bug #1297849
[09:36] <seb128> I guess that's my issue
[09:36] <seb128> it was fixed yesterday
[09:36] <seb128> I didn't restart my session since
[09:43] <Laney> ah I went straight to wily on this laptop
[09:46] <Laney> anpok_: do you need a versioned dependency?
[09:47] <Laney> this mir release seems like hard work. :(
[10:39] <seb128> anpok_, anything we can do to help you to get mir unblocked?
[10:40] <seb128> session restart, brb
[10:42] <seb128> yeah, vpn back to working
[10:54] <Laney> yeahhhh, shotwell green again
[10:54] <seb128> :-)
[10:54] <seb128> gnome-photos retry worked as well
[10:59] <seb128> shrug
[10:59] <seb128> qengho, hey, is https://jenkins.qa.ubuntu.com/job/wily-adt-chromium-browser/lastBuild/ARCH=amd64,label=adt/ known? autopkgtest from chromium are grumpy again it seems
[11:00] <seb128> that blocks cups gconf and probably others in proposed
[11:06] <anpok_> seb128, Laney: a better way to specify that drivers need to be replaced...
[11:08] <seb128> why do they need to be replaced?
[11:08] <seb128> did some other abi change?
[11:14] <seb128> mvo, hey, do you know if anyone looked a bug #1470655
[11:14] <seb128> how much changed between 0.8 and 1.0?
[11:15] <seb128> hum
[11:15] <seb128> "   * New upstream release: 1.0.0
[11:15] <seb128>      - This release drops support for plugins
[11:15] <seb128>      - Aptcc is now the only viable backend for Debian, other
[11:15] <seb128>        backends have been removed upstream."
[11:25] <seb128> Laney, what's the status of webkit/webkit2? we should keep on using webkit right?
[11:26] <Laney> seb128: yeah, for now in main
[11:28] <seb128> webkit2gtk is not/not going to this cycle right?
[11:28] <seb128> https://launchpad.net/ubuntu/+source/zenity/3.16.3-1 is why I'm asking
[11:28] <Laney> doubt it
[11:29] <Laney> probably want to undo that bit
[12:10] <mvo> seb128: yeah, the plugin is the big one, someone *cough* like me *cough* needs to finish  lp:~mvo/click/native-dbus  and then we can get rid of the PK plugin requirement. right now updating to 1.0 would break the click plugin
[12:11] <mvo> seb128: but we don't really need much of PK in click, almost nothing, the native-dbus branch is implementing all thats needed
[12:16] <seb128> mvo, k, I was asking because gnome-software is blocked in proposed since it depends on the new packagekit version
[12:16] <seb128> it's not a big issue for us but eventually we want to update
[12:22] <seb128> bah, gnome-online-account is currently stucked in proposed due to webkit2 as well, bug #1466290
[12:26] <Laney> darkxst has been on that
[12:27] <Laney> ah yes, in that bug
[12:27] <darkxst> seb128, Laney waiting on infinity to review the proposed demotions
[12:27] <seb128> not jdstrand?
[12:27] <seb128> he's the one assigned on the bug
[12:29] <darkxst> seb128, oh oops wasnt actually subscribed to the bug so didnt see that, but infinity did say he was looking into it
[12:30] <darkxst> I can remove the dejadup dep in g-c-c
[12:30] <seb128> it's the other way around
[12:30] <seb128> deja-dup depends on g-c-c to build a panel no?
[12:30] <darkxst> seb128, I want to drop that panel
[12:30] <seb128> is that up to you or mterry (the deja-dup maintainer/upstream)?
[12:31] <darkxst> and hence drop libgnome-control-center, since deja-dup is the only remaining panel and its a pain maintaining the patches that allow for that
[12:31] <seb128> k
[12:32] <darkxst> no idea why there would be a compiz dep though?
[12:33] <seb128> because it integrates with the keybindings
[12:33] <seb128> and it uses the .pc to know the directory where to install the .xml
[12:33] <seb128> iirc
[12:33] <darkxst> can that move to u-c-c?
[12:33] <seb128> yes
[12:33] <seb128> I can have a look to that today
[12:37] <darkxst> ok, I'm tired from a long day so out for the night, I will deal with deja-dup stuff over the weekend
[12:37] <mvo> seb128: yeah, sorry, snappy madness
[12:38] <seb128> darkxst, good night!
[12:46] <darkxst> night!
[12:47] <darkxst> left a comment on the g-o-a bug, now gone!
[12:51] <xnox> Laney: why is evolution so old?
[12:53] <Laney> what kind of a question is that?
[12:53] <Laney> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-028/+packages
[12:54] <ogra_> xnox, because it was born so early :P
[12:54] <darkxst> xnox, evo is on a 12 month release cycle now, so there was no 3.14
[12:57] <seb128> Laney, do you need help pushing that transition?
[12:57] <seb128> like me to nag some people to do reviews/land changes?
[12:59] <xnox> Laney: ah, so 16 is in the works. I somehow thought 16 bits were all landed now.
[12:59] <xnox> and i had no idea there was no 3.14. thanks darkxst.
[12:59] <Laney> seb128: just need to test and upload it
[12:59] <xnox> it seemed like it's stuck on old series for one reason or another.
[12:59] <seb128> xnox, do you need it for something?
[13:00] <xnox> seb128: yes. it looks like the only client that supports XOAUTH2 authentication =) hence it's looking like i'll be switching to evolution by default.
[13:00] <xnox> and xoauth2 is enforced by google for me =(
[13:05] <xnox> yeap, definately switching to evolution now.
[13:06] <seb128> xnox, good, maybe you can help maintaining the packages then :-)
[13:09] <mdeslaur> xnox: doesn't thunderbird 38 support it also?
[13:10] <mdeslaur> xnox: https://blog.mozilla.org/thunderbird/2015/06/thunderbird-38-released/
[13:10] <xnox> hah, but their bug tracker is not updated. loads of developers screaming there "we must not let google dictate email standards"
[13:11] <xnox> horum, checking which thungerbird i have.
[13:11] <xnox> i'm on 31 =(
[13:12] <seb128> when did middle click/dnd stop working?
[13:25] <Laney> seb128: what is middle click/dnd?
[13:26] <seb128> Laney, like in nautilus doing an icon dnd with the middle button used to open a menu asking if you want to symlink/copy it
[13:27] <seb128> http://askubuntu.com/questions/23534/is-it-possible-to-drag-files-with-right-click
[13:27] <Laney> oh, never seen that before, but it seems to work
[13:27] <Laney> move here, copy here, link here
[13:28] <seb128> k
[13:28] <Laney> real mouse though
[13:28] <seb128> here I can move the cursor after clicking
[13:28] <seb128> k, it's limited to the trackpad nibble
[13:28] <seb128> works on the touchpad
[13:28] <seb128> grrr
[14:24]  * Laney fixes chromium tests
[14:24] <Laney> qengho: if this works please merge
[14:24] <qengho> Er, okay.
[14:24] <seb128> qengho, did you see my ping about that earlier?
[14:24] <seb128> I didn't see a reply
[14:24] <qengho> seb128: No, I didn't.
[14:25] <seb128> shrug
[14:25] <seb128> qengho, hey, is https://jenkins.qa.ubuntu.com/job/wily-adt-chromium-browser/lastBuild/ARCH=amd64,label=adt/ known? autopkgtest from chromium are grumpy again it seems
[14:25] <seb128>  that blocks cups gconf and probably others in proposed
[14:25] <qengho> seb128: I see it in my scrollback, but didn't see a notification.
[14:25] <seb128> but I guess Laney is handling it for you
[14:25] <Laney> I was like oh hey
[14:25] <seb128> Laney_beers++
[14:25] <Laney> it looksl ike a missing dep
[14:25] <Laney> then it wasn't quite just that ... :)
[14:26] <seb128> haha
[14:35] <seb128> qengho, is there any way we could get those tests run before upload to minimize those sort of issues in the futur?
[14:38] <qengho> seb128: of course. I usually do. The last two breaks were some other package without tests. I'm interested to see what this is.
[14:38] <Laney> I didn't investigate why these things changed
[14:38] <Laney> 'convert' is due to not depending on the package which provides it
[14:39] <qengho> seb128: no, actually, there was a problem in the tests last time. That's true.
[14:41] <qengho> Laney: I thought it would be easier to see files from Jenkins, but it's so difficult that I may just remove the screenshot convert'ion one day.
[14:42] <Laney> there's meant to be a way to attach artifacts
[14:44] <qengho> Laney: IIRC, they used to be in the result list, but I haven't seen them in about a year.
[14:53] <Laney> qengho: Ah, you changed the harness to catch more errors but some of them are innocuous
[14:53] <Laney> qengho: I just added a grep -v to filter those out
[16:23] <qengho> Laney: my tests still pass here. What did you grep away in Cr test?
[16:48] <Laney> qengho: http://launchpadlibrarian.net/212478045/chromium-browser_43.0.2357.130-0ubuntu1.1188_43.0.2357.130-0ubuntu2.diff.gz
[16:48] <Laney> qengho: Are you running with adt-run?
[16:49] <Laney> adt-run chromium-browser -s -U --apt-pocket=proposed --- qemu ~/temp/reallytemp/adt-wily-amd64-cloud.img
[16:50] <qengho> Laney: Thanks. I'll have Cr 44 in my PPA soon.
[16:50] <Laney> instead of 'chromium-browser' you can give a .dsc or an _amd64.changes there
[16:51] <Laney> the latter to avoid rebuilding if you already have it built
[16:53] <qengho> Laney: thanks. I think that logic is buggy. Pipeline return value is the final item, right? I'll reverse to remove good things first, then test for error.
[17:02] <Laney> qengho: Dunno what you mean, but fix as you wish as long as it works. You probably want '-qs' on the last one too to silence it.
[17:13] <Laney> bye!
[17:15] <willcooke> cya Laney
[17:15]  * willcooke -> EOD too
[17:15] <willcooke> night
[17:18]  * willcooke <- Columbo
[17:19] <willcooke> done
[17:19] <willcooke> so long