[01:23] -queuebot:#ubuntu-ci-eng- vorlon, https://bileto.ubuntu.com/#/ticket/3922 Pending binary packages
[01:43] -queuebot:#ubuntu-ci-eng- vorlon, https://bileto.ubuntu.com/#/ticket/3922 Successfully built
[01:53] -queuebot:#ubuntu-ci-eng- vorlon, https://bileto.ubuntu.com/#/ticket/3922 Generating diffs
[01:54] -queuebot:#ubuntu-ci-eng- vorlon, https://bileto.ubuntu.com/#/ticket/3922 Successfully built
[08:56] -queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3916 Needs rebuild due to higher version at destination
[10:34] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3534 Pending binary packages
[10:54] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3534 Diff missing
[11:55] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3534 Pending binary packages
[12:35] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3534 Needs rebuild due to higher version at destination (focal/openvswitch). Pending binary packages (focal/ovn)
[13:14] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3534 Diff missing (focal/ovn). Needs rebuild due to higher version at destination (focal/openvswitch)
[13:23] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3923 Needs rebuild due to higher version at destination
[13:34] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3534 Needs rebuild due to higher version at destination
[14:55] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3925 Preparing packages
[14:56] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3925 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[15:05] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3925 Generating diffs
[15:26] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3925 Failed to build (focal/qemu). Uploading build (focal/libvirt)
[15:46] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3925 Failed to build (focal/qemu). Pending binary packages (focal/libvirt)
[16:00] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3840 Pending binary packages
[16:05] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3925 Failed to build (focal/qemu). Successfully built (focal/libvirt)
[16:13] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3840 Preparing packages
[16:27] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3840 Generating diffs
[16:27] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3840 Successfully built
[17:00] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3925 Generating diffs
[17:26] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3925 Failed to build (focal/qemu). Successfully built (focal/libvirt)
[20:48] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3925 Generating diffs
[21:45] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3925 Failed to build (focal/qemu). Successfully built (focal/libvirt)


[00:58] <sn33zy> im having a hard time finding the package to satisfy aclocal-1.13
[01:02] <sarnold> sn33zy: the saucy automake package offered one http://packages.ubuntu.com/search?searchon=contents&keywords=aclocal-1.13&mode=exactfilename&suite=saucy&arch=any
[01:07] <sn33zy> sarnold, yeah i later realized i have aclocal 1.14 installed and wondering why it DESIRES the 1.13 version for the build instead
[01:08] <sarnold> sn33zy: auto* stuff sometimes doesn't work with newer versions; you can try with 1.14 and if it works fine, hooray :)
[01:17] <sn33zy> gah
[01:17] <sn33zy> ./configure: line 22834: GNOME_DEBUG_CHECK: command not found
[01:17] <sn33zy> ./configure: line 22835: syntax error near unexpected token `maximum'
[01:17] <sn33zy> ./configure: line 22835: `GNOME_COMPILE_WARNINGS(maximum)'
[03:21] <lamont> is utopic currently safe to do-release-upgrade to?
[03:21] <lamont> for developer values of safe, that is.
[03:22] <ScottK> It's certainly safe for me if you do it.
[03:23] <stgraber> lamont: I did it this morning on my laptop and outside of some compiz packaging mess which has been reasonably easy to fix (remove the mess, install ubuntu-desktop^), things went fine and the machine still boots
[04:49] <pitti> Good morning
[04:49] <pitti> hallyn: sure
[05:49] <pitti> hallyn: uploaded; and yay that we can sync now
[07:04] <LocutusOfBorg1> can anybody please retry this build? https://launchpad.net/ubuntu/+source/aegisub/3.1.2-1/+build/5939512
[07:04] <LocutusOfBorg1> it is a really old ICE
[07:05] <pitti> LocutusOfBorg1: done
[07:05] <LocutusOfBorg1> 10x
[07:15] <dholbach> good morning
[07:15] <ion> that
[07:17] <dholbach> Noskcaj, did you have any luck with python-wsme?
[07:18] <dholbach> Noskcaj, I'd really appreciate if you could take a look at it and fix it some time soon, or let folks know on the mailing list of elsewhere, that you need some help
[07:39] <LocutusOfBorg1> wxpython3.0 fails to build on ubuntu because of a missing dependency on mesa-common-dev
[07:39] <LocutusOfBorg1> dragged in by gtk2.0-dev in debian, but NOT in ubuntu
[07:39] <LocutusOfBorg1> some substvars is not working
[07:43] <LocutusOfBorg1> pitti, failing :(
[08:04] <doko> tkamppeter, system-config-printer python3 \o/, what is left, hplip?
[08:12] <pitti> oh wow, it did happen? nice!
[08:14] <pitti> err, how would that work? system-config-printer-gnome is still pulling in python-gtk2 and all the python 2 bits?
[08:15] <pitti> tkamppeter: ^ ah, it actually does use python3-gi and various gir1.2-* now, seems you just didn't update the Depends: for python3 and GI?
[08:16] <pitti> awesome, this was a really tough one
[08:46]  * xnox ponders who maintains system-config- et.al and friends
[08:47] <LocutusOfBorg1> pitti did you read the mesa-common-dev problem?
[08:48] <LocutusOfBorg1> seems that pango in debian needs it, while in ubuntu doesn't
[08:48] <LocutusOfBorg1> and this is (one) of the cause of the build failures
[08:48] <pitti> LocutusOfBorg1: sounds like a missing build dep in wxpython then?
[08:50] <LocutusOfBorg1> sound like a missing wl,as-needed in debian/pango? :)
[08:50] <LocutusOfBorg1> I wonder why pango drags unneeded dependencies
[08:51] <LocutusOfBorg1> anyway your solution seems the right one ;)
[09:22] <LocutusOfBorg1> seb128, you there?
[09:22] <LocutusOfBorg1> sorry for bothering
[09:22] <seb128> LocutusOfBorg1, sort of, not really, in a meeting
[09:22] <seb128> why?
[09:22] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1353362
[09:23] <LocutusOfBorg1> ^^^
[09:23] <seb128> I can have a look to that next week
[09:23] <seb128> I'm travelling this week/in meetings until friday
[09:23] <seb128> but anyone can do that
[09:24] <LocutusOfBorg1> can I just copy the debian packaging, look at the ubuntu1 delta and ask for a sponsor?
[09:25] <seb128> well, you can do the merge if you want yes
[09:26] <seb128> if that's the question
[09:27] <LocutusOfBorg1> yes, I don't know too much about cairo, I don't want to prepare a stupid debdiff
[09:27] <LocutusOfBorg1> this is why I asked you ;)
[09:27] <LocutusOfBorg1> I don't know how big is the delta from debian
[09:27] <Noskcaj> dholbach, transaction is not actively maintained in debian, and turbogears use python-support and many universe depends :(
[09:27] <dholbach> Noskcaj, yep, doko mentioned something like that - might be worth trying to workaround the new (build-)dep
[09:28] <Noskcaj> the debian maintainer seems to think it's needed, but i'll branch the code and have a look
[09:29] <dholbach> great
[09:29] <doko> Noskcaj, can can see this here: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[09:30]  * Noskcaj cries
[09:54] <Noskcaj> dholbach, Crappy patch for turbogears made, transaction maintainer contacted
[10:02] <Noskcaj> I'll push my fixes on i work transaction out
[11:01] <tkamppeter> pitti, principally, I have switched over to the Python-3-based s-c-p 1.5.0 now. If something in the packaging is still missing/wrong, please tell me (or patches welcome). Thanks.
[11:02] <pitti> tkamppeter: yes, the build deps are py3 now, but not the binary deps
[11:23] <doko> Noskcaj, transaction seems to be unproblematic, turbogears2 is the problematic one
[11:43] <tkamppeter> pitti, following python3 packages do not exist: python3-gtk2, python3-notify, python3-libxml2, python3-gnomekeyring, python3-pycurl. What are the replacements for them?
[11:44] <tkamppeter> pitti, is it correct that python-gobject is replaced by python3-gi?
[11:51] <pitti> tkamppeter: yes, python-gobject -> python3-gi
[11:52] <pitti> tkamppeter: python-gtk2 etc. are replaced with gir1.2-*-*
[11:52] <pitti> tkamppeter: you need to grep for "from gi.repository import" (e. g. Gtk, Pango, etc.) and map these to the gir1.2-* names
[11:52] <pitti> tkamppeter: python3-pycurl does exist
[11:53] <pitti> tkamppeter: supposedly python3-lxml is the corresponding replacement for python3-libxml2, but I'm not 100% sure
[12:16] <slangasek> xnox: so lp:~xnox/ubuntu/utopic/upstart/core-split says it's been merged, does that mean you no longer need my review?
[12:22] <xnox> slangasek: pitti has battled it out =)
[12:23] <xnox> slangasek: it typically request multiple reviews, but await at least one extensive review.
[12:23] <pitti> oh right, it's already in NEW; thanks xnox
[12:23] <xnox> slangasek: where is, is xnox =)
[12:23] <xnox> slangasek: where it, is xnox =)
[12:23]  * xnox can't type today
[12:23] <xnox> upgrades & operation tested on phone, desktop and server as well.
[12:25] <xnox> slangasek: you of course, as an archive admin, may choose to review NEW =)
[12:27] <tkamppeter> pitti, thanks. I did all the changes, but did not find a gdk and a gobject in the gir1.2 collection. All the rest seems to be solved.
[12:28] <pitti> tkamppeter: Gdk is part of gir1.2-gtk-3.0
[12:28] <pitti> tkamppeter: GObject is part of gir1.2-glib-2.0
[12:28] <tkamppeter> pitti, OK, thanks.
[12:31] <tkamppeter> pitti, as the whole thing is running with python3 now and depends only on python3 packages, do I have to rename the python-cupshelpers package into python3-cupshelpers (or simply let it provide python3-cupshelpers so that both python2 and python3 apps can use it)?
[12:31] <pitti> tkamppeter: err yes, it needs to be renamed to python3-cupshelpers
[12:32] <pitti> tkamppeter: in fact, the current python-cupshelpers is broken as it only provides a Python 2 package
[12:32] <pitti> tkamppeter: fortunately the only reverse dependencies are system-config-printer itself
[12:32] <pitti> so it didn't break anything
[12:32] <pitti> tkamppeter: but the rename needs to be done
[12:32] <tkamppeter> pitti, ho do I get a python3 package then?
[12:33] <pitti> tkamppeter: look at its contents, it already is a python3 package
[12:33] <pitti> tkamppeter: /usr/lib/python3/dist-packages/cupshelpers
[12:33] <pitti> tkamppeter: it just needs to be renamed
[12:33] <pitti> tkamppeter: and ${python:Depends} changed to ${python3:Depends}, and similar
[12:33] <pitti> tkamppeter: I suppose you updated its python-pycurl dep already
[12:35] <tkamppeter> yes I did so.
[12:36] <tkamppeter> pitti, all ${python:Depends} I replaced by ${python3:Depends} in the control file, all python-cupshelpers by python3-cupshelpers.
[12:36] <pitti> tkamppeter: great, thanks
[12:36] <tkamppeter> pitti, no "python-" any more, all "python3-" now.
[12:36] <pitti> \o/
[12:37] <tkamppeter> pitti, all "gir"ified in system-config-printer-gnome
[12:38] <LocutusOfBorg1> dholbach, do you have time for looking for a package?
[12:38] <tkamppeter> pitti, anything to do with the old python-cupshelpers binary package? Or will it simply go away by "apt-get autoremove"?
[12:39] <LocutusOfBorg1> or pitti maybe ;)
[12:39] <dholbach> LocutusOfBorg1, is it on http://reqorts.qa.ubuntu.com/reports/sponsoring/? :)
[12:40] <pitti> tkamppeter: yes, it'll be removed semi-automatically as it doesn't have remainin reverse dependencies
[12:40] <pitti> tkamppeter: so don't worry about it
[12:41] <dholbach> LocutusOfBorg1, I'm just asking because that's usually the best place to put something which needs uploading :)
[12:42] <LocutusOfBorg1> not right now
[12:42] <LocutusOfBorg1> yes I know
[12:42] <dholbach> ok good :)
[12:42] <LocutusOfBorg1> ;)
[12:42] <LocutusOfBorg1> (I just would like to see the problem fixed asap
[12:43] <dholbach> ok, which package is it?
[12:43] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1353362
[12:44] <LocutusOfBorg1> sorry for the long time, I needed to prepare the debdiff
[12:44] <tkamppeter> pitti, thank you very much, the package is on the way.
[12:44] <LocutusOfBorg1> and to check every change in debian if was merging with ubunut
[12:44] <slangasek> xnox: only the binary packages get into the new queue, no sane diffs from there ;P
[12:44] <LocutusOfBorg1>  /s/ubunut/ubuntu
[12:44] <slangasek> but yeah, I can look at it if no one beats me to it
[12:44] <LocutusOfBorg1> I checked every git commit since the last merge from debian and cherry picked them in ubuntu
[12:45] <LocutusOfBorg1> and for the shlib file I built it locally and double checked if symbols were still there in .13 release
[12:45] <LocutusOfBorg1> everything was good so far
[12:45] <dholbach> LocutusOfBorg1, maybe I'm not the best person to review this, but instead somebody from the desktop team could take a look at it?
[12:45] <LocutusOfBorg1> I still don't know if this is needed
[12:45] <LocutusOfBorg1> +  * debian/patches/server_side_gradients.patch:
[12:45] <LocutusOfBorg1> +    - Don't use server side gradients, most drivers don't handle those and
[12:45] <LocutusOfBorg1> +      are really slow
[12:46] <LocutusOfBorg1> seb128 has quit
[12:46] <dholbach> I mentioned this in #ubuntu-desktop
[12:46] <dholbach> LocutusOfBorg1, Séb is in China, where it's 20:46 right now :)
[12:46] <LocutusOfBorg1> wonderful :)
[12:46] <LocutusOfBorg1> time for VAC ;)
[12:47] <LocutusOfBorg1> anyway this is something that worries me a little bit, since the last 10 debian release fixed a lot of problems in the package
[12:47] <tjaalton> LocutusOfBorg1: can't enable gl backend
[12:47] <tjaalton> because of bug #725434
[12:48] <xnox> slangasek: well the diff is already generated for the source package by launchpad http://launchpadlibrarian.net/181650696/upstart_1.13.1-0ubuntu2_1.13.1-0ubuntu3.diff.gz
[12:48] <dholbach> LocutusOfBorg1, no vac though
[12:48] <xnox> slangasek: maybe queudiff simply needs to be taught how to fetch those?
[12:49] <slangasek> not particularly; the binary NEW review is for reviewing the binary delta
[12:52] <LocutusOfBorg1> tjaalton, do you think it is still the case? why debian doesn't have this problem?
[12:55] <tjaalton> i don't know
[12:57] <LocutusOfBorg1> anyway disabling again might be trivial
[13:20] <tkamppeter> pitti, the new python3-cupshelpers 1.5.0...0ubuntu3 conflicts with python-cupshelpers 1.5.0...0ubuntu1 and python-cupshelpers 1.5.0...0ubuntu2, but not with python-cupshelpers 1.4.x and older. How do I the breaks/conflicts/replaces with correct versioning?
[13:20] <pitti> tkamppeter: ah, for upgrades within utopic from the past few days
[13:21] <pitti> tkamppeter: hmm, tricky; but I suppose if you just do Replaces:/Breaks: python-cupshelpers (<< 1.5.0...0ubuntu3) it'll do
[13:21] <pitti> tkamppeter: you can drop these after a few weeks or so
[13:33] <tkamppeter> pitti, I get paste.ubuntu.com/7970474/  Anytjing missing?
[13:34] <tkamppeter> pitti, do I also needs Conflicts: or Provides:
[13:34] <pitti> tkamppeter: use --auto-deconfigure as advertised, or dpkg -P python-cupshelpers first and run it a few times
[13:35] <pitti> tkamppeter: with dpkg alone it's hard to upgrade over breaks: and package renames; apt will figure it out
[13:35] <pitti> tkamppeter: no, Provides: would be entirely wrong; Breaks:/Replaces: is correct and sufficient, no Conflcits: necessary
[13:36] <tkamppeter> pitti, thanks. So then all is correct and I can upload it?
[13:36] <doko> xnox, did you recently touch mpi? https://launchpadlibrarian.net/181599384/buildlog_ubuntu-utopic-amd64.dolfin_1.3.0%2Bdfsg-2build2_FAILEDTOBUILD.txt.gz
[13:36] <pitti> tkamppeter: did you manage to install the packages now?
[13:36] <pitti> tkamppeter: if that works (with removing python-cupshelpers manually), and s-c-p still runs, it's fine
[13:39] <tkamppeter> pitti, all works now. Thank you. I will upload now.
[13:40] <pitti> tkamppeter: cool, danke!
[13:41] <xnox> doko: i did touch a lot of mpi.... =(
[13:42] <xnox> doko: fun, we did do libpetsc3.4.2-dev transition as part of the mega transition.
[13:43] <xnox> doko: i like how ppc64el is green =) so perfect - ship it. Everyone has switched to ppc64el by now, haven't they? =)
[13:47] <mlankhorst> can xserver-xorg-video-s3 be removed? it's no longer in debian
[13:56] <doko> xnox, no, blacs-mpi wasn't built there. now fixed
[14:03] <hallyn> pitti: \o/  thanks
[14:09] <pitti> hallyn: ah, it's imported, want me to sync, or are you at it?
[14:10] <hallyn> what does imported mean?
[14:11] <pitti> hallyn: into Launchpad, so it's syncable
[14:13] <hallyn> ok - please go ahead, else i'll do it after bfast
[14:13] <hallyn> "you people" had a busy night, 236 unread since 8 hrs ago
[14:14] <pitti> hallyn: synced
[14:16] <hallyn> thx
[14:56] <LocutusOfBorg1> tjaalton, I'm checking right now
[15:01] <zyga> cjwatson: hi, I'm trying to convert pyotherside packaging from SVN to git and move it to collab-maint, I got the git tree by following https://wiki.debian.org/Alioth/Git#Convert_a_SVN_Alioth_repository_to_Git but I'm unsure about a few things. Do you have a moment for a few questions here on IRC?
[15:03] <cjwatson> zyga: probably not today; though in general I'd recommend asking rather than asking to ask :)
[15:05] <xnox> current utopic (without proposed) is trying to remove unity and compiz on upgrade and hold-back unity8
[15:05] <xnox> =(
[15:06] <zyga> cjwatson: excellent advice: should I try to integrate upstream git repository into the packaging repository? should I (do I have to?) do the same for pristine upstream tarballs
[15:07] <zyga> cjwatson: and lastly (most importantly perhaps) where do I put the repository to? various alioth docs are kind of fuzzy about that, links end up 404, etc
[15:11] <xnox> actually, i had a broken unity installed locally, downgrading to utopic fixed everything.
[15:13] <cjwatson> zyga: my opinion (not shared by everyone, apparently, but what the hell) is that if upstream git exists or is easily synthesisable, then there's no excuse for not integrating it into the packaging repository
[15:13] <cjwatson> zyga: pristine tarballs are really easy to handle in git using pristine-tar
[15:14] <cjwatson> zyga: I've been converting all my packages to git-dpm, and love it; it makes both the above things pretty straightforward.  I've gone on about it fairly recently on debian-devel
[15:15] <zyga> cjwatson: do you have an example package that I could look at?
[15:15] <zyga> cjwatson: branch/tag/etc arrangement
[15:15] <cjwatson> zyga: openssh, parted, grub2
[15:15] <zyga> cjwatson: where can I find them?
[15:15]  * zyga looks at grub2 control file
[15:15] <cjwatson> apt-cache showsrc has the vcs-* headers
[15:15] <zyga> right, thanks
[15:16] <cjwatson> zyga: or smaller-scale: man-db, putty, six, trn4
[15:16] <cjwatson> zyga: if you don't already have a suitable alioth group, you can push packages under users/; e.g. I have this in ~/.gitconfig:
[15:16] <cjwatson> [url "git+ssh://git.debian.org/git/"]
[15:16] <cjwatson>         insteadof = debian:
[15:17] <zyga> users/ ?
[15:17] <cjwatson> then I push to e.g. debian:users/cjwatson/libpipeline.git, and that shows up as git://anonscm.debian.org/users/cjwatson/libpipeline.git and http://anonscm.debian.org/cgit/users/cjwatson/libpipeline/
[15:17] <zyga> ah
[15:17] <zyga> do you co-maintain any of your packages?
[15:18] <cjwatson> yes, e.g. six is under collab-maint
[15:18] <zyga> ok, I'll start with that, thanks for your time!
[15:18] <cjwatson> so that's debian:collab-maint/six, git://anonscm.debian.org/collab-maint/six.git, http://anonscm.debian.org/gitweb/?p=collab-maint/six.git
[15:18] <cjwatson> or indeed http://anonscm.debian.org/cgit/collab-maint/six.git
[15:19] <cjwatson> zyga: http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2014-January/013883.html may be helpful too
[15:20] <zyga> cjwatson: thanks!
[15:21] <cjwatson> zyga: oh, my last comment, for converting existing packages I always like to keep as much history as possible, and http://www.catb.org/~esr/reposurgeon/ was the first tool I found that would let me convert my svn/bzr/etc. history into git without ridiculous amounts of effort
[15:22] <cjwatson> so I can recommend that as a good building block
[15:22] <zyga> cjwatson: git-svn got the history I wanted
[15:22] <zyga> cjwatson: though, that's a bare debian repo history
[15:22] <zyga> cjwatson: so I'm not sure if I shoud reply that on top of upstream releases or not
[15:22] <cjwatson> ah, you would want to stitch that into something better
[15:23] <cjwatson> if that were me, I would use reposurgeon to stitch it in on top of upstream so that I could pretend it was always that way
[15:23] <cjwatson> but your call :)
[15:23] <zyga> cjwatson: I guess a plain rebase will do in this case
[15:23] <zyga> cjwatson: rebase the packaging on top of each release
[15:23]  * zyga is still unclear about branches though
[15:23] <cjwatson> A plain rebase is unlikely to be at all straightforward with more than one branch point like that
[15:24] <cjwatson> Branches: if they're ones I want to generally advertise, I create them at the top level and push them, for random personal experimentation in shared repositories I tend to call them people/cjwatson/foo
[15:24] <cjwatson> if I want to push them
[15:25] <cjwatson> Not much more needed really.  If you're using git properly you'll likely have lots of short-term branches locally that you never push anywhere
[15:25] <zyga> cjwatson: I need to look at your code to have more meaningful questions now
[15:25] <cjwatson> Most of my packaging branches have master, upstream, pristine-tar at a minimum
[15:25] <cjwatson> *packaging repositories
[15:25] <zyga> I meant the upstream vs debianized branches
[15:25] <cjwatson> That's upstream vs. master
[15:25] <cjwatson> git-dpm puts the upstream ref in the right place when you import a new upstream version
[15:26] <cjwatson> Which in best practice is a commit whose parent is the upstream tag and which contains the delta between the upstream tag and the released tarball (if any)
[15:48] <gQuigs> I was wondering why bootchart2 hasn't been automatically synced from debian?  (https://bugs.launchpad.net/ubuntu/+source/bootchart/+bug/1035385)
[15:49] <gQuigs> ^the bug is now out of date as bootchart2 has made it all the way to stable (I'm not sure the best place to sync from right now...)
[16:08] <cjwatson> gQuigs: overwrites binaries from bootchart; when I last checked I heard there wasn't much point as our bootchart had most of the relevant stuff anyway
[16:08] <cjwatson> Actually binaries from pybootchartgui
[16:08] <cjwatson> anyway it's in the sync blacklist
[16:08] <cjwatson> bootchart # keybuk, entirely separate packaging
[16:08] <cjwatson> bootchart2 # cjwatson, ditto; our bootchart source has many of the improvements here, and the pybootchartgui binary clashes
[16:10] <gQuigs> cjwatson: oh.. in that case should I guess I should file a separate request to pull the systemd units out of boothchart2?
[16:10] <cjwatson> That might be a good idea, yeah
[16:10] <tedg> pitti, Saviq and I are looking at some PPA build issues, which might be from systemd needing a new sysvinit in proposed. Do you know about that?
[16:11] <gQuigs> cjwatson: will do, thanks
[16:14] <xnox> gQuigs: the problem with bootchart2 was that it was systemd only and doesn't support upstart boot. Kind of worthless for comparing bootspeed on ubuntu then, isn't it.
[16:15] <gQuigs> xnox: oh, right, that would make it very useless..
[16:17] <gQuigs> so I believe that bug could be marked "Won't Fix"
[16:36] <LocutusOfBorg1> tjaalton, please let me know if something else is needed
[16:36] <LocutusOfBorg1> right now I'm testing my package ;)
[16:52] <pitti> tedg: err no, I don't -- what's up with that?
[16:52] <tedg> pitti, It seems to be causing some failure in proposed
[16:52] <tedg> pitti, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd
[16:53] <pitti> tedg: oh argh -- I have a new sysvinit installed locally for a week or so, waiting for slangasek's go ahead
[17:31] <doko> tkamppeter, pitti: no way for foo2zjs to use lcms1 again ...
[17:45] <pitti> tedg: I uploaded another systemd with lower initscripts dep; thanks
[17:45] <pitti> Saviq: ^
[17:50] <pitti> stgraber: https://github.com/lxc/lxc/commit/281b843 > whoops, thanks!
[17:51] <stgraber> np :)
[18:34] <tedg> xnox, stgraber, so I'm trying to use the cgroup feature in Upstart. But it seems on the N4 there is no cpuset or even an upstart dir in /sys/fs/cgroup
[18:35] <tedg> Is there something I need to do to get those?
[18:47] <stgraber> tedg: no and they don't need to be there so long as cgmanager is running
[18:51] <tedg> stgraber, Then what should my cgroup line be in my upstart job? I was using "cpuset" before because that seemed to work on my desktop.
[18:51] <tedg> stgraber, So it was just "cgroup cpuset"
[19:00] <stgraber> tedg: just had a quick look at what cgroups are enabled in the mako kernel
[19:00] <stgraber> tedg: it looks like you can only use: debug, cpu, cpuacct and freezer
[19:00] <stgraber> tedg: if you need memory, cpuset or any of the others, you'll have to talk to the kernel team
[19:01] <tedg> stgraber, Well, what should I use? :-)  I really just want a bag of PIDs.
[19:01] <tedg> I tried cpu on my desktop, but that didn't seem to work.
[19:01] <tedg> Changing to cpuset fixed things
[19:02] <stgraber> tedg: did you try freezer? seems like this one is available everywhere
[19:02] <tedg> stgraber, No, I didn't. I can.
[19:12] <tedg> stgraber, freezer gets me much further, thanks!
[19:16] <hallyn> you can also just mount -o name=bag , if you only want to collect pids
[19:39] <stgraber> hallyn: you'd need to do that before cgmanager starts if you want to use it with upstart
[19:49] <hallyn> stgraber: /etc/default/cgmanager
[19:49] <hallyn> (add it to the list of options)
[21:50] <tkamppeter> doko, what do you mean? What is broken with foo2zjs?


[00:00] <mwhudson> wgrant: if you could read my email and tell me which stuff i need to pay attention to, that would be great :/
[00:00] <wgrant> mwhudson: Which email?
[00:00] <wgrant> Oh.
[00:00] <mwhudson> wgrant: my inbox :)
[00:00] <mwhudson> nm
[00:00] <wgrant> Right. Just worked that out.
[01:28] <thumper> rockstar: I'm back if you are around
[02:17] <Ursinha> hey wgrant, can you try to give me a little help here? :)
[02:18] <wgrant> Ursinha: Sure.
[02:19] <Ursinha> wgrant, I've added a field to the Product table, where on earth should I declare it to access it in translations side?
[02:20] <wgrant> Ursinha: Are you getting ForbiddenAttribute exceptions?
[02:20] <Ursinha> wgrant, yes sir
[02:20]  * thumper away again
[02:21] <wgrant> Ursinha: It depends on how the particular object is set up. In some cases there will be interfaces like IProductPublic, IProductEdit, IProductAdmin which have attributes protected by different permissions. In other cases, lib/lp/SOMETHING/configure.zcml will name a permission for each attribute.
[02:21] <wgrant> Let's see which case IProduct is...
[02:22] <wgrant> Ursinha: OK, so if you look at lib/lp/registry/configure.zcml around line 1040, you'll see security stuff.
[02:24] <Ursinha> let me see
[02:26] <wgrant> You'll see <require permission="launchpad.Foo" interface="IBar" />. That restricts access to the attributes and methods on Bar to those users holding the launchpad.Foo permission.
[02:26] <wgrant> <require permission="launchpad.Foo" set_attributes="foo bar" /> restricts setting of attributes 'foo' and 'bar' to launchpad.Foo.
[02:37] <Ursinha> argh, right, sorry wgrant, got lost here
[02:37] <wgrant> Still lost?
[02:37] <Ursinha> about other bit
[02:37] <wgrant> Ah.
[02:44] <Ursinha> wgrant, thank you very much.
[02:44] <Ursinha> again.
[02:44] <wgrant> np
[03:12] <noodles775> sinzui: did you get that QA done?
[03:12] <noodles775> I'm checking staging currently but the css issue still seems to be there :/
[03:13] <noodles775> Ah, staging is on r8640... np.
[03:56] <mwhudson> aargh soyuz is eating my brain
[03:57] <lifeless> nom nom nom
[03:58] <wgrant> mwhudson: Which bit?
[03:58] <wgrant> (it is very effective at that)
[03:58] <mwhudson> wgrant: the bit you told me to run away from
[03:59] <wgrant> Ah, yes.
[03:59] <wgrant> Got it to run or do anything yet?
[03:59] <mwhudson> nah, haven't even tried that
[04:02] <mwhudson> wgrant: there seems to be a "build style" concept, of which the only actual instance is debian style?
[04:02] <wgrant> mwhudson: Correct.
[04:02] <wgrant> mwhudson: You can see it registered in daemons/buildd-slave.tac
[04:02] <wgrant> (that bit took a while to find)
[04:03] <mwhudson> wgrant: right
[04:52] <mwhudson> wgrant: soyuz builders get the sourcepackage bits that need to be built from the librarian right?
[04:53] <wgrant> mwhudson: Sometimes.
[04:54] <wgrant> mwhudson: Unless the files are private.
[04:54] <mwhudson> oh right
[04:54] <wgrant> In that case, they live in the restricted librarian and cannot be retrieved.
[04:54] <mwhudson> so how does it work then, do you know?
[04:54] <wgrant> buildd-manager instead gives them a private-ppa.launchpad.net URL with credentials, IIRC.
[04:55] <mwhudson> oh ok
[04:55] <mwhudson> wgrant: the chroots are in the librarian too?
[04:55] <wgrant> Yup.
[04:57] <wgrant> mwhudson: You can probably reuse the same chroots, and just install bzr-buildpackage inside them during the build.
[04:58] <mwhudson> wgrant: yeah, not having to open that bear pit would be nice
[04:58] <wgrant> It will make $UOSA happy.
[04:59] <spm> wgrant: unlikely. he's a grumpy old bugger.
[05:00] <wgrant> :(
[05:00] <wgrant> I must try to catch him tomorrow morning, since I failed today.
[05:00] <mwhudson> spm: s/happy/less grumpy/
[05:01] <spm> tbh, I don't think I've ever seen lamont unhappy. irritated yes, unhappy, no.
[05:01] <wgrant> I'm sure that maintaining an extra set of buildd chroots would tip him just over into unhappy :P
[05:01] <mwhudson> spm: the baseline for admins is not especially happy after all
[05:02] <spm> mwhudson: gah!!!! do you mean to imply that I'm -EHAPPY ????
[05:03] <spm> wgrant: if you present them as hpia mk2's you could swing it with him being non the wiser? :-P
[05:04] <wgrant> Ooh, true.
[05:05] <wgrant> mwhudson: Deciphered the beast yet?
[05:06] <mwhudson> wgrant: well, making progress
[05:12] <mwhudson> wgrant: is there a difference between the slave scanner and the buildd master, or are they different names for the same thing?
[05:13] <wgrant> mwhudson: slave-scanner was scaling badly, so was reincarnated as buildd-manager. Both are builddmasters.
[05:13] <wgrant> slave-scanner is, I believe, only of historical value.
[05:13] <mwhudson> wgrant: ahh ok
[05:17] <mwhudson> wgrant: and aiui build scheduling is done be yet another process that manipulates the buildqueue table which is then consulted by builddmanager?
[05:17] <wgrant> mwhudson: mrrrrrrh sort of but not really
[05:17] <wgrant> mwhudson: There is this queue-builder thing.
[05:17] <wgrant> It is run occasionally.
[05:18] <wgrant> It only really needs to be run when you add a new arch or distroseries.
[05:18] <wgrant> It creates new builds, and creates buildqueues for those that are missing.
[05:18] <wgrant> But in the normal case, the Builds and BuildQueues are created and given a score at upload-time.
[05:19] <mwhudson> does it need to be run when a build is rescored for example?
[05:19] <wgrant> No.
[05:19] <wgrant> Rescoring directly updates the BuildQueue, which findBuildCandidate then sees.
[05:19] <mwhudson> or not, because the score is the output of the at-upload computation and rescoring overrides the result
[05:19] <wgrant> Right.
[05:20] <wgrant> queue-builder has a rescoring mode, where it will recalculate all scores.
[05:20] <wgrant> But I don't think queue-builder is run regularly in production at the moment.
[05:28] <wgrant> are bug subscriber sprites (not those in the "Also notified" section, though) slightly raised for anybody else)?
[05:35] <mwhudson> wgrant: sorry, i'll stop this soon
[05:36] <mwhudson> wgrant: does the buildd-manager suck the built files off the slaves too?
[05:36] <wgrant> mwhudson: Hey, it's more interesting than Java revision..
[05:36] <wgrant> It does.
[05:36] <wgrant> There's a handler in BuildQueue to do that, I think.
[05:37] <wgrant> (the slave will report its state as WAITING when it is complete)
[05:37] <wgrant> Hm, no, not in buildqueue.
[05:37] <wgrant> But it's somewhere, anyway.
[05:38] <wgrant> buildd-manager will grab the files, tell the slave to clean up, and then process the binary upload.
[05:38] <mwhudson> wgrant: lp.buildmaster.buildergroup it seems
[05:38] <wgrant> Something like that.
[05:40] <mwhudson>         # XXX cprov 2007-07-11 bug=129487: untested code path.
[05:40] <mwhudson> yay!
[05:41] <wgrant> This is Soyuz.
[05:42] <wgrant> There are altogether too many XXXs in that method.
[05:42] <wgrant> But bigjools wants to offload most of the processing, anyway.
[08:32] <adeuring> good morning
[09:10] <wgrant> noodles775: What's wrong with the librarian? Disk upgrades?
[09:18] <bigjools> mo disk IIRC
[09:18] <wgrant> Makes sense.
[09:19] <wgrant> bigjools: I wonder how much librarian disk would be saved if daily PPAs were configured to cull binaries after just a few days.
[09:20] <bigjools> lots!
[09:20] <bigjools> I might chop the current 28 day limit to much less
[09:20] <bigjools> across the board
[09:21] <bigjools> however the biggest culrprit by far is Ubuntu
[09:21] <mrevell> Morning
[09:21] <bigjools> eyup mrevell
[10:14] <SteveA> 10:11 < SteveA> the launchpad offline page is really really annoying
[10:14] <SteveA> 10:11 < SteveA> instead of serving a page up at the URL I want, but serving the offline page with a 5xx error
[10:14] <SteveA> 10:12 < SteveA> it redirects me to an "offline" page
[10:14] <SteveA> 10:12 < SteveA> the problem with this is, I lose any URLs I have in my browser when I refresh the URLs
[10:14] <SteveA> 10:12 < SteveA> such as when I restart my firefox session
[10:14] <SteveA> 10:12 < SteveA> this is a significant loss of state.
[10:14] <SteveA> 10:13 < SteveA> the offline page is even a 200 OK
[10:14] <SteveA> 10:13 < SteveA> it should be a 5xx
[10:25] <stub> I guess if haproxy doesn't support what we want, we can open a bug and maybe submit a patch.
[11:01] <deryck> Morning, all.
[11:32] <bigjools> james_w: fancy a trip to NZ in january?
[11:33] <james_w> I wouldn't say no :-)
[11:33] <bigjools> james_w: we're holding the build from branch sprint in Wellington
[11:34] <james_w> nice
[11:34] <bigjools> so it's up to you, it will be a mostly coding sprint I think
[11:34] <bigjools> LCA is the week after, which is why we're doing it there
[11:34] <james_w> thought so
[11:48] <bigjools> jtv: around?
[11:48] <jtv> bigjools: around
[11:49] <jtv> bigjools: what's up?
[11:49] <bigjools> jtv: howdy - I was wondering if you'd like to get involved in documenting how our build farm works, so you can learn a bit about it in preparation for the work we're doing to support translations jobs
[11:49] <jtv> bigjools: sounds like a good idea
[11:50] <jtv> bigjools: got any concrete plans for it?
[11:50] <bigjools> al-maisan and noodles775 are looking into it as well, can you join up with them
[11:50] <wgrant> mwhudson had fun with lp-buildd today, too!
[11:50] <bigjools> I hear :)
[11:51] <jtv> al-maisan, noodles775: how are you going about it?  (Or rather, how should I :-)
[11:52] <noodles775> jtv: I haven't yet (still following the release issues), but plan to install soyuz locally using wgrant's instructions (I've never had time to do it yet)
[11:53] <wgrant> noodles775: I rewrote them to be more useful this evening, but haven't uploaded them anywhere yet.
[11:53] <al-maisan> jtv: I am also a bit busy but thought of reading the code and playing with the Soyuz dogfood system.
[11:53] <jtv> noodles775: oh, I hadn't even realized that there was an additional installation procedure
[11:53] <noodles775> wgrant: ah, please let me know when you do...
[11:54] <bigjools> jtv: I'll include you on an email I am sending about the db schema
[11:54] <noodles775> jtv: for actually running the build infrastructure locally.
[11:54] <bigjools> jtv: you need to get a local buildd running
[11:54] <jtv> wgrant: as you've guessed by now, please add me to the distribution list.  :-)
[11:55] <jtv> bigjools, noodles775: were you deliberately completing each other's sentences there, or should I read you as two separate input channels?
[11:55] <bigjools> heh, separate :)
[11:56] <bigjools> prophecy - Guns n Roses "Back off Bitch" just started on my random playlist
[11:58] <wgrant> noodles775, jtv: http://williamgrant.id.au/f/1/2009/running-soyuz.html is the new version.
[11:58] <jtv> wgrant: thanks!
[12:01] <bigjools> nice
[12:02] <bigjools> wgrant: it would be good if you can put that on dev.launchpad.net
[12:02] <wgrant> bigjools: I've been planning to.
[12:03] <bigjools> coolio
[12:03] <wgrant> Any hints as to where it should go?
[12:03] <bigjools> somwhere under https://dev.launchpad.net/Soyuz
[12:04]  * wgrant hunts out the Codehosting equivalent.
[12:05] <noodles775> Thanks wgrant
[12:32] <wgrant> https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally
[12:32] <bigjools> \o/
[12:32] <noodles775> Nice :)
[12:32] <bigjools> thanks muchly
[12:33]  * wgrant works out how to attach those two helper scripts.
[12:36] <wgrant> Alright, that looks reasonable.
[12:37] <danilos> wgrant, btw, I think it'd be great to have sampledata on launchpad_dev updated to reflect what's there after update-ubuntu-sane.py script
[12:37] <wgrant> danilos: Probably, now that it's separate from ftest.
[12:37] <danilos> wgrant, exactly :)
[12:37] <wgrant> Amusingly, most of the tests use the 'ubuntutest' distro anyway, because the 'ubuntu' distro is too screwed.
[12:38] <danilos> wgrant, yeah, we're also trying to use more and more of in-place object creation instead of relying on sampledata
[12:40] <bigjools> but the jury's out on whether that's quicker than resetting the db each test
[12:41] <wgrant> I should also probably get the archive.launchpad.dev stuff added to rf-setup, like I did with ppa.launchpad.dev a couple of months back.
[12:44] <wgrant> bigjools: The external archive dependencies feature is very handy.
[12:44] <bigjools> wgrant: that's its problem :)
[12:57] <wgrant> I never like to see 'NIGHTMARE.' in specs.
[12:58] <maxb> ooi, when does the db-stable->devel merge take place? Is it scheduled, or somewhat adhoc?
[12:59]  * wgrant sadly compares the Codehosting and Soyuz local instance pages.
[13:00] <bigjools> wgrant: NIGHTMARE is honesty :/
[13:00] <wgrant> bigjools: Yep.
[13:00] <al-maisan> wgrant: which ones do you like better?
[13:00] <al-maisan> ;)
[13:57] <EdwinGrubbs> bigjools: ping
[14:13] <salgado> sidnei, around?
[14:33] <bigjools> EdwinGrubbs: hey, wassup
[14:35] <EdwinGrubbs> bigjools: you mentioned in bug 196322 that the +allpackages could be removed. Will this prevent google from crawling the source packages pages, and is that a problem?
[14:35] <mup> Bug #196322: "All source packages" page empty when distribution doesn't use Launchpad for packaging <post-3-ui-cleanup> <trivial> <ui> <Launchpad Registry:In Progress by edwin-grubbs> <https://launchpad.net/bugs/196322>
[14:36] <bigjools> let me check
[14:38] <bigjools> EdwinGrubbs: blow it away
[14:46] <Ursinha> matsubara, meeting in 15 mins?
[14:46] <matsubara> stub, Chex, gary_poster, rockstar, bigjools, danilos, sinzui, allenap: LP production meeting in 14 min @ #launchpad-meeting
[14:47] <danilos> matsubara, thanks for the reminder, I might not be a good participant (along with bigjools, gary_poster and sinzui) since we have a TL call at the same time
[14:47] <bigjools> damn DST
[14:48] <Ursinha> matsubara, oops summaries won't be completed in time as well
[14:48] <bigjools> noodles775: can you attend the production meeting instead of me please!
[14:53] <matsubara> danilos, I can cover for gary_poster
[14:54] <danilos> bigjools, that's why I had complaints about moving the call last week, but forgot about the timing for this week :)
[14:54] <gary_poster> matsubara: thank you.  what do you want to do about this longer term?  Presumably we hould move one or the other
[14:54] <gary_poster> I was wondering if the team lead meeting on Thursday should be moved to the same time as Wednesday during DST
[14:55] <matsubara> gary_poster, not sure what do about it in the longer term. we can try to re-schedule or send other people as QA contacts for each of the teams when the TL is not available
[14:56] <gary_poster> matsubara: ok.  I'm sure we'll bring up the conflict on the TL call; I or someone else will then check up with you and Ursinha
[14:57] <sidnei> salgado: sorta
[14:57] <matsubara> gary_poster, all right. thanks
[14:58] <salgado> sidnei, hi there. I was wondering if you could help me with that lazr-js bug I mentioned yesterday.  would you have some time for that today?
[14:59] <sidnei> salgado: today is looking nasty, but if you have a reproducible case, let's schedule it for 4pm BRT
[15:00] <salgado> sidnei, I do have one, yes.  thanks a lot!
[15:00] <sidnei> salgado: deal. thanks!
[15:06] <beuno> mrevell, I just realized I never replied to your tour email  (it dropped off my unread emails)
[15:07] <mrevell> hey beuno, there's no rush. I had a meeting with Iain Farrell yesterday, as I happened to be at Millbank for some other meetings. I'll CC you on the writeup of what we spoke about.
[15:08] <beuno> mrevell, thenks
[15:28] <flacoste> abentley: around?
[15:28] <flacoste> rockstar: around?
[15:28] <abentley> flacoste: Yes.
[15:29] <flacoste> abentley: we have a problem with codehosting can you help?
[15:29] <abentley> If it's the fact that http access doesn't work, I'm already looking into that.
[15:29] <flacoste> ok, what is the situation?
[15:29] <flacoste> do you need any help?
[15:30] <abentley> I don't know what's causing it.  It's hard to reproduce locally, but I'm getting there.
[15:38] <flacoste> abentley: what info do we have on the issue?
[15:38] <abentley> The best info I have is that some files which should be there are 404ing and others are not.
[15:39] <flacoste> abentley: btw, mthaddon was looking for you on #launchpad-code
[15:40] <abentley> flacoste, mthaddon: I lost my connection to irc.canonica.com, and it doesn't want to reconnect.
[15:40] <mthaddon> abentley: hmm, weird - well we can work here if you like
[15:41] <abentley> mthaddon: jam is reporting that not all files are 404ing, but I'm getting "connection timed out" when I try to access bazaar.launchpad.net.
[15:41] <abentley> mthaddon: This URL is reported to not 404: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/branch-format
[15:42] <mthaddon> yeah, I don't get a 404 for that one
[15:42] <abentley> mthaddon: Is that possibly a caching issue?
[15:42] <mthaddon> and http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes works for me too
[15:43] <mthaddon> I can't see any caching options in the apache configs
[15:43] <abentley> mthaddon: I guess it can always be a caching issue, with the prevalence of intercepting proxies.
[15:44] <abentley> mthaddon: But I tried it on devpad and it worked there too.
[15:45] <mthaddon> https://bazaar.launchpad.net/~launchpad-pqm/launchpad/production-devel/changes works for me too
[15:45] <mthaddon> so who is reporting problems, and what kind of problems?
[15:45] <abentley> mthaddon: Sure, but AIUI, we're worried about http codehosting, not codebrowse.
[15:46] <abentley> mthaddon: jam is one of the people noticing problems.
[15:47] <mthaddon> ok, so what specific bit is failing?
[15:52] <mars> BjornT, ping re: lazr-js and buildout
[15:52] <BjornT> hi mars
[15:52] <mars> hi BjornT.  Did your lazr-js and LP buildout changes land successfully?
[15:53] <BjornT> mars: yes, it landed quite a while ago
[15:54] <mars> BjornT, ok, so is it safe to bump the version number on the lazr-js trunk, and start landing sidnei's branches?
[15:54] <BjornT> mars: yes
[15:54] <sidnei> \o/
[15:54] <mars> BjornT, awesome, thank you
[15:54] <sidnei> now, how do i land them?
[15:54] <mars> ...
[15:55] <sidnei> bzr pqm-submit?
[15:55] <mars> sidnei, yes, that should work
[15:55] <mars> it Works For Me
[15:55] <sidnei> it didn't last time. maybe i have to be added to some acl somewhere
[15:55] <mars> BjornT, ^ ?
[15:56] <BjornT> sidnei: can you try again? or show me which error you got?
[15:56]  * mars wonders who is the scrollkeeper for the PQM system, the repository of such arcane knowledge?
[15:57] <sidnei> the error i got was []
[15:57] <sidnei> Command failed!
[15:57] <sidnei> All lines of log output:"Branch ['/home/pqm/archives/rocketfuel/lazr-js/toolchain', 'bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/lazr-js/toolchain'] not found in config"
[15:57] <abentley> flacoste: We are seeing a gradual recovery.  Do you have any examples of branches that are still failing?
[15:58] <BjornT> sidnei: to which pqm address did you send the request to?
[15:58] <flacoste> abentley: not really, mthaddon: do you have any example HTTP branches still failing?
[15:59] <sidnei> BjornT<EMAIL_ADDRESS>apparently
[15:59] <sidnei> BjornT: rockstar pasted me the config
[15:59] <BjornT> sidnei: i would try again
[16:00] <mars> BjornT, how much longer are you on for?
[16:00] <cody-somerville> Am I reading correctly the codehosting issue is slowly recovering? My commit from 2 hours ago is still not available via launchpad yet.
[16:01] <BjornT> mars: no idea. i'll probably be on and off the whole evening, and night since i need to prepare for my trip tomorrow
[16:01] <mars> ok
[16:01] <rockstar> Ursinha, sorry I missed the meeting.  I forgot my timezone changed.
[16:03] <mars> rockstar, btw, we are working on YUI3 for LP, devmode is good, but the production JS build is broken.  If I can fix that before the sprint, then we can land it.
[16:03] <mars> but we do have an integration branch for people to use.
[16:04] <mars> thumper could try that branch if he is feeling adventurous :)
[16:05] <BjornT> abentley: http://bazaar.launchpad.net/~launchpad-pqm/lazr-js/toolchain/
[16:08] <Ursinha> rockstar, okay
[16:09] <rockstar> mars, let me know how I can help.
[16:11] <sidnei> uhm, my submission didn't even show up in pqm, no reply even. maybe it's just a delay
[16:12] <rockstar> sidnei, there's funkiness in the web display recently.
[16:12] <abentley> BjornT: Are you able to view bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/lazr-js/toolchain/ ?
[16:13] <Ursinha> rockstar, it was asked someone from code to comment on https://bugs.edge.launchpad.net/launchpad-code/+bug/475394
[16:14] <mup> Bug #475394: bzr http access broken after 3.1.10 rollout <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/475394>
[16:14] <Ursinha> if you or abentley could do that it would be nice
[16:14] <Ursinha> thanks
[16:14] <rockstar> Ursinha, I'm trying to find out what's going on by reading the backchat.
[16:14] <mars> abentley, https://code.edge.launchpad.net/~launchpad-pqm/lazr-js/toolchain works for me
[16:14] <abentley> Ursinha: We don't know what's wrong.
[16:16] <sinzui> barry: EdwinGrubbs: bac: can you close your 3.1.10 registry bugs?
[16:16] <rockstar> abentley, shall we have a call to catch me up?
[16:16] <abentley> rockstar: Okay
[16:16] <barry> sinzui: i just ran close-my-bugs :)
[16:16] <EdwinGrubbs> sinzui: sure
[16:16] <sinzui> fab
[16:17] <sinzui> Maybe I will find and fix the insane karma action for that action so people can safely close other people's bugs
[16:17] <sinzui> barry: Do you think the rule is: use the assignee or the user doing the action?
[16:18] <barry> sinzui: i think the person who sets fix committed should get the karma
[16:18] <barry> fscking rich-roots kills me again!
[16:19] <sinzui> I disagree. I find lots of bugs that you have indirectly fixed a long time ago. I assign it to you and mark it fix committed. you should get the credit
[16:19] <barry> sinzui: oic.  assignee then
[16:19] <abentley> rockstar: ringing...
[16:19] <sinzui> barry: I think I gave you and edwin credit for about 30 bugs I discovered in foundations last month.
[16:19] <sidnei> uhm, now it shows up, but it's out of order. how can i remove a script from pqm?
[16:20] <barry> sinzui: awesome. i can go out to lunch now!  have you seen my new site www.karmaforgold.com?
[16:21] <sinzui> \o/
[16:21] <mars> losas, does someone have a moment to help sidnei with his PQM submission?
[16:23] <BjornT> abentley: yes, the bzr+ssh url works, but not http
[16:26] <abentley> BjornT: You don't have write access to that branch, do you?
[16:31] <Ursinha> bigjools, can I mark bugs 470150, 470411, 472326, 472608, 472929 as Fix Released?
[16:31] <Ursinha> hmm
[16:32] <bigjools> Ursinha: some URLs would be nice :)
[16:32] <Ursinha> bug 470150, bug 470411, bug 472326, bug 472608, bug 472929
[16:32] <mup> Bug #470150: package set based archive permission checks need to consider the distro series <current-rollout-blocker> <Soyuz:Fix Committed by al-maisan> <https://launchpad.net/bugs/470150>
[16:32] <mup> Bug #470411: please change the default source suite for Debian to 'testing' in _syncorigins.py <current-rollout-blocker> <trivial> <Soyuz:Fix Committed by al-maisan> <https://launchpad.net/bugs/470411>
[16:32] <mup> Bug #472326: When adding and removing package subsets the distro series needs to be observed <current-rollout-blocker> <Soyuz:Fix Committed by al-maisan> <https://launchpad.net/bugs/472326>
[16:32] <mup> Bug #472608: IPackagesetSet.getByName() is missing LP API metadata for the newly added 'distroseries' param. <current-rollout-blocker> <Soyuz:Fix Committed by al-maisan> <https://launchpad.net/bugs/472608>
[16:32] <mup> Bug #472929: Archive +upload URLs for package sets need to be distro series aware <current-rollout-blocker> <Soyuz:Fix Committed by al-maisan> <https://launchpad.net/bugs/472929>
[16:32] <Ursinha> :)
[16:32] <bigjools> lol
[16:32] <bigjools> Ursinha: well if you want to steal al-maisan's karma
[16:33] <al-maisan> yeah, all of these were rolled out.
[16:33] <Ursinha> bigjools, hm, I thought the assignee gets the karma
[16:33] <bigjools> Ursinha: I think the person who marks it does
[16:33] <Ursinha> bigjools, this kinda sucks
[16:33] <al-maisan> yes indeed.
[16:33] <bigjools> Ursinha: patches accepted I'm sure ;)
[16:33] <Ursinha> bigjools, I'm learning, hopefully will be able to do that soon :P
[16:34] <bigjools> \o/
[16:34]  * bigjools closes his bugs
[16:35] <bigjools> yay for the API
[16:37] <rockstar> noodles775, are we having a second rollout?
[16:38] <Ursinha> bigjools, so I won't close al-maisan's bugs so I won't steal his karma
[16:38] <bigjools> rockstar: noodles775 has left for the day, he was up at 3am his time
[16:38] <al-maisan> I can close them later if that suits
[16:38] <bigjools> al-maisan: I have a script that will close your own bugs in 10 seconds
[16:39] <mars> bigjools, I don't remember that part being in the Release Manager job description...
[16:39] <al-maisan> bigjools: that's very handy.
[16:39] <bigjools> mars: yeah it kinda sucks but he's a diligent man
[16:40]  * beuno-lunch hugs barry for filing the bzr bug
[16:46] <BjornT> abentley: no, i don't think i have write access to that branch. however, branches that i have write access to fail as well, i tink
[16:47] <BjornT> abentley: for example http://bazaar.launchpad.net/~bjornt/garmin-sync/devel
[16:47] <abentley> BjornT: Yes, it's just that as a debugging tool, we want to make sure the mirrored copy is alright, and the you see the mirrored copy over bzr+ssh if you don't have write access.
[16:47] <Ursinha> gary_poster, are you working on bug 475550 for the reroll?
[16:47] <mup> Bug #475550: _pythonpath whitelist of clean_modules is too fragile <Launchpad Foundations:In Progress by gary> <https://launchpad.net/bugs/475550>
[16:47] <gary_poster> Ursinha: yes
[16:47] <Ursinha> gary_poster, thanks
[16:48] <gary_poster> Ursinha: np
[16:55] <sidnei> BjornT, mars: pqm finally failed my branch, with the same error as before. i don't think it's because of release-critical though.
[16:56] <Ursinha> sinzui, I'm sorry, I think I forgot asking in the meeting, you said bug 475433 was a good candidate for CP. you meant CP or reroll?
[16:56] <mup> Bug #475433: oops leaving milestone code_name empty <oops> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/475433>
[16:56] <sinzui> I meant CP, but now that I see the issue is lower, I am working on an RC
[16:57] <sinzui> Ursinha: we may see many oops that end with:
[16:57] <sinzui> AttributeError: 'NoneType' object has no attribute 'str
[16:58] <sinzui> Ursinha: This may be happening with an not-required StrippedTextField
[16:58] <sinzui> s/an/any/
[16:58] <mars> sidnei, it looks like dealing with that will have to wait until after they get codehosting back to full speed :(
[16:58] <sidnei> mars: thats fine. i assume lazr-js will be taken out of pqm as well?
[16:59] <mars> sidnei, that I do not know
[17:01] <barry> beuno-lunch: ;)
[17:02] <sidnei> rockstar: are we getting your magic migrate-my-branch button this cycle or the next?
[17:03]  * Ursinha stabs oops-tools
[17:03] <rockstar> sidnei, probably the beginning of this next cycle, on edge.  The infrastructure got rolled out with the rollout, but the UI didnt'.
[17:03] <sidnei> rockstar: awesome, thanks!
[17:06] <BjornT> sidnei: you'll have to ask a losa about that error. we will only take lazr-js out of pqm if we set up a buildbot for it. but it might be better to run the tests before commit, rather than after, assuming it won't take long to run them.
[17:50] <Ursinha> anyone else able to file bugs in lp?
[17:50] <Ursinha> hi deryck, a user filed bug 475498 and I'm also getting consistently timeouts trying to do what he was doing
[17:51] <Ursinha> deryck, I initially thought about another bug on dupefinder with long sentences but even a few words trigger the timeout
[17:52] <deryck> Ursinha, ok, I'll take a look at it.
[17:52] <Ursinha> thanks deryck
[18:08] <mrevell> Night all
[18:34] <sidnei> salgado: just got out of a meeting, and have to leave in 20, can you email me instead?
[18:34] <salgado> sidnei, sure, I'll do that
[18:35] <sidnei> salgado: thanks!
[18:36] <salgado> sidnei, thank you
[19:14] <sinzui> barry: close this bug I rediscovered and get the karma: https://bugs.edge.launchpad.net/launchpad-registry/+bug/102273
[19:14] <mup> Bug #102273: product search shows description instead of summary <Launchpad Registry:Fix Committed by barry> <https://launchpad.net/bugs/102273>
[19:16] <barry> yay karma!
[19:29] <sinzui> EdwinGrubbs: I wrongly closed the bug I was looking for: bug 263223 relates to the layout you were looking at
[19:29] <mup> Bug #263223: "Working on" and "Latest Memberships" inconsistencies on person page <trivial> <ui> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/263223>
[21:42] <beuno> sinzui, EdwinGrubbs, FYI, +1 on all of sinzui's comments on the UI pre-review
[21:42] <beuno> I have nothing to add  :)
[21:43] <EdwinGrubbs> thanks
[22:35] <EdwinGrubbs> sinzui: I wasn't sure if you wanted me to put the badges in a table like person-portlet-contributions.pt. Alternatively, I could just float the badges to the right.
[22:35] <EdwinGrubbs> of course, that might be bad if the bug title should wrap.
[22:36] <sinzui> EdwinGrubbs: I am not sure. I do not like the table, but badges are shown in tables on all pages except this one instance
[22:37] <sinzui> EdwinGrubbs: I tried floating on the milestone page and later switched to a table column because users noticed that they were still displaying differently
[22:38] <sinzui> EdwinGrubbs: In this case, the user will see two presentation and they should be the same. so if you do not want to alter the erson-portlet-contributions.pt, I would use a table just like that portlet
[22:38] <EdwinGrubbs> ok
[22:46] <tsimpson> is there a decided time scale on https://bugs.edge.launchpad.net/launchpad-foundations/+bug/385517 ("launchpadlib users made to authenticate unnecessarily")?
[22:46] <mup> Bug #385517: launchpadlib users made to authenticate unnecessarily <Launchpad Foundations:In Progress by leonardr> <https://launchpad.net/bugs/385517>
[22:50] <mwhudson> airport time


[02:05] <bspencer> rustyl, mjg59  I got clutter running.  Default image doesn't have /etc/xdg/menus
[02:05] <rustyl> rustyl, yea, me too
[02:05] <bspencer> but after putting that down I'm able to get something wiggling on the Samsung.
[02:06] <rustyl> but it runs really really slow... i'm attempting to install libgl1-mesa-dri, but the libgl packages seem to be in flux, so the install fails on a dependency that doesn't exists yet
[02:06] <bspencer> note as fluid as I'd hoped
[02:06] <bspencer> rustyl, I got that working
[02:06] <bspencer> 3D games work ok
[02:07] <bspencer> my image is not LPIA though
[02:07] <rustyl> i'm updating again and will attempt the apt-install again
[02:07] <bspencer> it is a week old
[02:07] <rustyl> bspencer, you mean lpiacomat
[02:07] <bspencer> right.
[02:07] <bspencer> it is just mccasslin i386
[02:09] <rustyl> bspencer, mjg59, i went ahead and uploaded a fix to gstreamer-dbus-media-service.  The source now registers itself as org.moblin.MobileMediaSerivce with a changelog entry set as 'gutsy' in anticipation of pushing to the gutsy apt repository
[02:10] <rustyl> damn... still waiting on libgl1-mesa-glx (= 7.0.0-0ubuntu3)
[02:10] <mjg59> rustyl: Sweet, thanks
[02:10] <rustyl> the player still needs some love
[02:16] <bspencer> rustyl, mirror :)
[02:17] <bspencer> rustyl,   mjg59 also mentioned that the mobile player didn't have MobileMediaService as an install dependency
[03:13] <rustyl> mjg59, i just found something else that needs to be change in the gstreamer-dbus-media-service
[08:17] <dholbach> good morning
[12:25] <xyzzy_bill> Hey, guys.  What do you think of Google's GPhone OS effort?
[12:25] <mjg59> When we've seen it, we might be able to tell you
[12:42] <xyzzy_bill> As I understand it, Ubuntu-Mobile will not be of much use to smartphones, though I do see it listed in the mission statement.  Is there any effort to push towards phones?
[12:42] <mjg59> Not as yet
[12:43] <xyzzy_bill> Because frankly, the Samsung Q Ultra has the sex appeal of an Elephant.
[12:46] <mjg59> The Q1 is primarily a development platform for the MID hardware
[12:46] <mjg59> (from a UME perspective)
[04:16] <xyzzy_bill> Hey, guys... I'm really just interested in smartphone sw dev.  OpenMoko looks like it's making progress, though it could go under or be eclipsed by something else.
[04:16] <xyzzy_bill> Would you guys suggest I drop interest in Ubuntu Mobile for smartphones, and go join OpenMoko for smartphone dev?
[04:19] <smagoun> xyzzy_bill: A number of people have expressed interest in Ubuntu for smartphones, but it's not something being worked on. You're welcome to start such a project!
[06:35] <rustyl> Anyone know anything about the status of uploading libgl1-mesa-glx  version 7.0.0-0ubuntu3 in the ports apt repository?  This has been blocking my ability to install libgl1-mesa-dri since yesterday.
[06:36] <rustyl> or at least, yesterday is the first time i ever tried to install lbgl1-mesa-dri
[06:52] <bspencer> agoliveira, morning
[06:53] <bspencer> agoliveira, about claws + hildon, I saw your email to frank last night.  If I install claws today inside LPIA target, will it be Hildon?
[06:53] <agoliveira> bspencer: Good afternoon around here but it's the spirit that counts :)
[06:53] <bspencer> Goooooood afternoooon!!
[06:54] <agoliveira> bspencer: It should but there's a bug on the build that I already solved. I'm just finishing somehting before and make a final test before ask for upload it.
[06:55] <bspencer> can you let me know when it is done?  I'm bugging Frank to add some fixes to claws and he's pointing fingers
[06:55] <bspencer> (not that your work is blocking, but it is nice if we can verify everything is working good)
[06:56] <bspencer> anyway, just put it on your list.  thanks!
[06:58] <agoliveira> bspencer: No problem.
[08:04] <bspencer> is it possible to tell whether a package is part of a bigger meta package?
[08:04] <bspencer> for example, i want to put 3D hardware driver as an install requirement for my clutter UI, but this will be different for each platform
[08:05] <bspencer> perhaps there is a meta package for 3d hardware drivers   (e.g. libgl1-mesa-dri)    :)
[08:45] <amitk> anybody on who uses a crownbeach?
[08:46] <amitk> rustyl, bspencer: could you find me a scapegoat^Wbeta-tester who as a crownbeach board?
[08:48] <rob_moblin> amitk, what do you need?
[08:48] <amitk> rob_moblin: some to test a crownbeach kernel
[08:50] <rob_moblin> amitk: i've got cb hw
[08:51] <rob_moblin> and either myself or one of minions can test it ;-)
[08:52] <rob_moblin> amitk, btw how is the crown beach hw we sent you holding up?
[08:52] <rob_moblin> amitk, meet Inuka
[08:52] <rob_moblin> Inuka, meet amitk
[08:53] <rob_moblin> Inuka, amitk needs our help to test a CB kernel on a CB platform
[08:53] <amitk> rob_moblin: brilliant. Could you boot with linux-headers-2.6.22-14-lpia_2.6.22-14.41_lpia.deb, linux-headers-2.6.22-14_2.6.22-14.41_all.deb, linux-image-2.6.22-14-lpia_2.6.22-14.41_lpia.deb, linux-ubuntu-modules-2.6.22-14-lpia_2.6.22-14.35_lpia.deb from  http://people.ubuntu.com/~amitk/
[08:53] <amitk> hi Inuka
[08:53] <Inuka> hi, amit
[08:53] <Inuka> amit, I will give it a shot and let you know
[08:54] <amitk> rob_moblin: it's hold up fine. I just don't have SDIO HW at the moment.
[08:55] <amitk> Inuka: Could you test some SDIO, SDHC and that psb loads and thermal shows what you need it to show.
[08:55] <rob_moblin> amitk, do you mean the COMMS hw that connects over SDIO ? you should have SDIO controller as it's in the poulsbo chipset
[08:55] <amitk> Inuka: I have done the latter two, but confirmation would be good
[08:56] <amitk> rob_moblin: I don't have and SDIO peripheral handy right now
[08:57] <amitk> s/and/any
[08:57] <rob_moblin> amitk: what sdio drivers do you have configured in the kernel?
[08:58] <rob_moblin> amitk, we don't really have any sdio peripherals either, other than the same sdio dev board that mauri gave to someone from ubuntu in boston
[08:59] <amitk> rob_moblin: just mss_sdhci.ko at the moment
[08:59] <amitk> and I don't have an SDHC card handy either :/
[09:00] <amitk> rob_moblin: I have the sdio dev board from Mauri, but it is at my old place. Need to go fetch it this weekend.
[09:01] <rob_moblin> amitk, if you had the sd8686 driver configured in the kernel we could test that out, otherwise we could try some sd memory cards
[09:01] <amitk> rob_moblin: sd8686 driver is in there.. but you will have to copy the firmware manually into /lib/firmware/blahblahblah
[09:02] <rob_moblin> ok
[09:05] <rob_moblin> amitk, inuka will download and test your kernels, it might take him the day to get it configured and tested out
[09:06] <amitk> rob_moblin, Inuka: sure. Send me email if you run into problems. I am almost done here for the day.
[09:06] <amitk> Inuka: I tried this using image-creator and then manually installing the new kernels into the filesystem chroot
[09:07] <amitk> Inuka: rob_moblin: thanks
[09:08] <Inuka> amitk, I will let you know as soon as I get it setup


[06:06] <Kilos> morning svij nhaines and all others
[06:07] <svij> morning Kilos
[06:57] <dholbach> good morning
[08:17] <elacheche> o/
[08:18] <elacheche> Morning dholbach !
[08:19] <elacheche> dholbach, As a LoCo contact how can I get the administration access on the ML?!
[09:06] <nhaines> elacheche: to the LoCo mailing list?
[09:08] <nhaines> Send your request and the details of what team you're the contact of and what the mailing list address is to<EMAIL_ADDRESS> Although do note that the LoCo team contact and the LoCo team leader isnt necessarily the same person, and we'll be checking. :)
[09:29] <Pradip_> Good Afternoon Sir
[09:29] <nhaines> Good afternoon!
[09:29] <nhaines> Well, so much for that.  :)
[09:29] <elacheche> Well noted nhaines thanks :)
[09:29] <nhaines> elacheche: great, thanks.  :)
[09:31] <dholbach> hi elacheche
[09:32] <elacheche> Yo dholbach :)
[09:32] <svij> hey all ;)
[09:33] <dholbach> :)
[09:50] <nhaines> Hey everyone.  :)


[01:24] <fairuz> hello rakan2
[03:00] <excalibr> Helo rakan
[03:07] <fairuz> excalibr: tgh kerja keras ka
[03:11] <excalibr> takda la bro..hari ni slow sikit..tak byk keje
[03:35] <excalibr> what's up fairuz
[03:58] <fairuz> excalibr: pening kepala buat coding keke
[06:37] <excalibr> helo salax
[07:10] <salax> pong excalibr
[07:12] <salax> sapa2 pernah guna IPy before?
[07:12] <salax> need some assitance :D
[07:13] <salax> kbyakkanya bots eh.. xpun jadi zombi heheeh
[07:17] <excalibr> python > hyperair :P
[07:18] <hyperair> ?
[07:18] <excalibr> /poke salax
[07:22] <salax_> hyperair: pernah guna IPy?
[07:28] <fairuz> hkohko
[07:33] <hyperair> salax: yeah
[07:33] <hyperair> ipython, right?
[07:45] <salax> hyperair: IPy module
[07:45] <salax> or api
[07:46] <salax> btw what i need to do is to read a csv file with IP address, and to seggregate whether its private ip or not
[07:47] <salax> using regex is much hectic - sy failed lagi pun dlm bab2 regex ni heheh
[07:49] <excalibr> salax: mesti guna python ke
[08:05] <salax> excalibr: haha yes
[08:06] <salax> excalibr: kalau tak dah lama da gune bash jek keh3
[08:09] <hyperair> ip address? i guess it's not ipython then
[08:09] <hyperair> no i haven't used it.
[08:10] <excalibr> https://pypi.python.org/pypi/IPy/
[08:11] <excalibr> >>> ip.iptype()
[08:11] <excalibr>     'PRIVATE'
[08:11] <salax> excalibr: yes, module tu aku guna
[08:11] <salax> excalibr: not as simple as that :p
[08:13] <excalibr> salax: uh why bro


[03:30] <Jessedavid4> Has anyone tried to connect a Samson G-Track pro before? I just bought one and it is not being detected by jack or anything it seems. If anyone has some information on how to properly get this to work, I'd appreciate the help.
[03:39] <OvenWerks> Jessedavid4: have you tried arecord -l
[03:39] <OvenWerks> does it list there?
[03:44] <OvenWerks> Jessedavid4: next question... are you using the mic for both input and out put or are you trying to use the mic for input and the computer for output?
[03:45] <OvenWerks> Yet another question, how are you starting jack?
[03:46] <OvenWerks> Oh and I should ask, which OS are you using? Which release number (ie I am using 18.04)
[03:50] <OvenWerks> I should also ask how you intend to use the mic. Music, pod cast, interviews (this looks like a good one on one interview mic)
[04:30] <Jessedavid4> It does not list on arecord -l || I am using the mic for both input and output, but have just tried to use it for input as well. || I should slightly rephrase this. I was using the Ubuntu Studio Controls to try and set up the mic. And it cannot recognize it. Nor when I open up QJack, it does not detect a device is even there. ||  Using 18.10
[04:31] <Jessedavid4> Planning on using it for Music (with hooking up my mandolin =) and for group calls via google voice.
[05:03] <Jessedavid4> Another thing. It is hooked up via USB.