[02:08] <hyperair> Laney: what's the process for DD's to get PPU access to ubuntu again? just email you a list of packages i'm maintaining?
[02:11] <hyperair> aha found it: https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
[02:35] <Noskcaj> hyperair, tip: Don't apply be email, and i think the 19UTC meeting has a waiting list
[02:58] <hyperair> huh?
[03:00] <hyperair> Noskcaj: any reason why?
[03:01] <Noskcaj> Because applying by email takes a month or more
[03:01] <hyperair> ¬_¬ really?
[03:01] <Snow-Man> there's a waiting list?  hahahaha
[03:01] <Noskcaj> Whereas applying by irc take 1 hour max
[03:01] <hyperair> i'll wait for Laney to say something then.
[03:02] <hyperair> 19UTC today?
[03:02] <Noskcaj> It's later this month the 19utc meeting
[03:02] <hyperair> i see
[03:02] <hyperair> bleh 19utc is 3am here
[03:03] <Noskcaj> oh, then you'll want the 15utc meeting
[03:03] <hyperair> if i'm not asleep by then chances are i don't wake up on time then ext morning.
[03:03] <hyperair> ah 15utc
[03:03] <hyperair> when are the meetings anywya?
[03:04] <hyperair> ah every two weeks on monday eh
[03:05] <hyperair> hang on there's a 15UTC meeting today right?
[06:17] <pitti> bdmurray: that's because there currently is no code to try and install versions other than what apt would give you as default
[06:18] <pitti> Noskcaj: whoa, all-caps ping
[06:18] <pitti> Good morning
[06:38] <Noskcaj> pitti, debian just finished the libgphoto transition, but they chose a different -dev package name to you. We might need to do a second transition
[06:44] <pitti> Noskcaj: right; libgphoto2-dev is indeed saner, but I didn't want to change the naming schema in Ubuntu only
[06:45] <pitti> Noskcaj: shouldn't be a big deal, it's just adjusting < 10 build deps of packages; that can be done very quickly
[06:45] <pitti> Noskcaj: ah, were you looking at merging libgphoto2?
[06:45] <Noskcaj> yeah
[06:45] <pitti> Noskcaj: if you are, I can do the transition for the build dep renaming
[06:46] <Noskcaj> I'm trying to get the pkg-phototools stuff in a decent state.
[06:46] <Noskcaj> I can do all the work, just will need sponsoring
[06:46] <pitti> we used to be able to sync libgphoto2, perhaps we can even do that again
[06:46] <pitti> Noskcaj: nah, don't try to do the libgphoto2-6-dev → libgphoto2-dev transition
[06:46] <Noskcaj> ok
[06:46] <pitti> that's like zero brain work, just mechanical; without upload privs, sponsoring is more work than just doing it
[06:47] <Noskcaj> makes sense
[06:47] <pitti> ooh, Debian has a .hwdb file now?
[06:47] <pitti> *want*
[06:49] <pitti> Noskcaj: hopefully the only remaining change is dh-autoreconf (and that can be reported to Debian)
[06:50] <Noskcaj> looks like just the autoreconf
[06:52] <Noskcaj> Could you test if we do actually need the autoreconf?
[06:52] <pitti> Noskcaj: and it's missing the "Replaces: libgphoto2-2" on libgphoto2-6
[06:52] <Noskcaj> ok
[06:53] <pitti> it reintroduces libgphoto2-2-dev, that should just be dropped again for our merge, too
[06:53] <pitti> meh, and debian missed to update some 2-2 to 2-6 in various *.isntall
[06:54] <pitti> Noskcaj: looks like you actually need to walk through the whole debian/ubuntu diff; there are several fixes that ought to be done to Debian's package, too, so that will spit out some bug reports
[06:54] <pitti> Noskcaj: autoreconf isn't necessary, debian already has --with autotools_dev
[06:55] <pitti> Noskcaj: I mean, that delta can be dropped
[06:55]  * Noskcaj decides to try and fix everything in debian instead
[06:55] <pitti> *nod*
[06:55] <pitti> Noskcaj: also, Debian still installs the *.udev file, that ought to go
[06:55] <pitti> having *both* a .rules and a .hwdb is just unnecessary overhead
[06:56] <Noskcaj> How do i merge git branches? The debian uploader did his work in a separate branch
[06:56] <hyperair> git merge
[06:56] <pitti> sohudl just be "git checkout master; git merge <branch name>"
[06:56] <pitti> or even pull, for cleaner history
[06:57] <hyperair> afaik there's no difference between git fetch+merge and git pull
[06:57] <hyperair> unless you're talking about pull -r
[06:57] <hyperair> which is equivalent to rebase
[06:58] <pitti> maybe; so far I never merged in git
[06:58] <pitti> the git world is pretty deeply entrenched to the concept of "send git-formatted patches to MLs or bug reports"  workflow, at least in the gnome and plumbing world
[07:00] <hyperair> pitti: yeah, but in the github world it's deeply entrenched in "send me a pull request"
[07:00] <pitti> *nod*
[07:00]  * hyperair prefers the git-formatted patches approach though, for individual fixes
[07:01] <hyperair> for stuff that involves a non-linear history, then i upload somewhere and tell whoever to pull
[07:01] <pitti> yes, it works quite well for those "little contributions"
[07:01] <pitti> for developing a major new feature, branches work better though
[07:02] <hyperair> well, yes
[07:02] <hyperair> it really depends on the kind of contribution we're talking about
[07:02] <hyperair> imo it's more about the kind of commits that it generates that determines which approach is better rather than the kind of work you're doing.
[07:06] <Noskcaj> crap, alioth git is still broken
[07:11] <Noskcaj> pitti, If you have the time, please do the merge into ubuntu. It will be quite some time before this get's fully fixed in debian, and you actually understand the current changes
[07:11] <pitti> ok
[07:11] <Noskcaj> ty
[08:14] <dholbach> good morning
[08:40] <pitti> Noskcaj: libgphoto2 built, I sent the two remaining changes to Debian as bugs; I just uploaded all rebuilds/syncs
[08:42] <Noskcaj> pitti, thanks.
[09:07] <directhex> are there restrictions on who can post to ubuntu-devel-announce?
[09:08] <pitti> directhex: not from the sending side; but it's moderated
[09:51] <Laney> hyperair: don't listen to the trolling, DD-PPU is super quick if you already have some PPU, which you do
[09:52] <hyperair> Laney: i figured that might be the case. i've already sent the email.
[10:02] <darkxst> Laney, can you bump the codesearch server?
[10:02] <Laney> argh
[10:02] <Laney> that piece of ...
[10:20] <mpt> ev, bdmurray: Any idea what caused the big dip in reported Trusty errors from January 10th to 28th?
[10:21] <mpt> Or what caused the lack of data from January 30th to February 3rd?
[10:24] <Laney> darkxst: there we go
[10:25] <darkxst> Laney, thanks
[10:55] <shadeslayer> would it be possible to enable deb-src's in the Buildd's?
[11:07] <RAOF> shadeslayer: What do you want deb-srcs for on the buildds?
[11:08] <shadeslayer> RAOF: I have a meta package that should depend on the build depends of another package
[11:09] <shadeslayer> RAOF: http://paste.ubuntu.com/6908474/
[11:10] <rbasak> shadeslayer: I can't answer your question, but you might want to know about grep-dctrl(1) if you don't already.
[11:11] <rbasak> (for line 11)
[11:11] <shadeslayer> rbasak: how would that help ? I want to get the build depends of kdelibs in the source of meta-kde
[11:13] <rbasak> shadeslayer: just to parse apt-cache showsrc output a little more "correctly".
[11:13] <shadeslayer> oh
[11:13] <seb128> apachelogger, " libkubuntu0 - ((DESCRIPTION))" ... need better description ;-)
[11:13] <rbasak> shadeslayer: instead of the grep|cut thing you have which I could subvert with an imaginative package :-)
[11:14] <apachelogger> seb128: huh, lol
[11:14] <apachelogger> seb128: sounds descriptive enough to me :P
[11:14]  * apachelogger fixes
[11:14] <seb128> lol
[11:14] <seb128> thanks
[11:14] <seb128> I wonder who NEW reviewed it, could have spotted that :p
[11:14] <seb128> Riddell, ^?
[11:17] <Riddell> seb128: hmm, yes, my fail, I normally run .debs through lesspipe as well as lintian but I seem to have only done lintian for these ones :(
[11:18] <shadeslayer> rbasak: thanks for the tip :)
[11:18] <shadeslayer> RAOF: so any chance of getting deb-src enabled?
[11:19] <Mirv> could a core dev possibly ack the following libunity packaging change dropping libgee usage, so that cu2d could be used to publish the package (after finalizing testing on Ubuntu Touch too): http://pastebin.ubuntu.com/6908355/
[11:21] <apachelogger> Riddell, seb128: fixed
[11:21] <seb128> apachelogger, thanks
[11:23] <seb128> Mirv, +1
[11:33] <Mirv> thank you
[11:51] <xnox> cjwatson: in the new world order, which branch of click i should target? (as in which one has 0.4.15?)
[12:02] <cjwatson> xnox: just target lp:click, I should get round to pulling the trivial bump of 0.4.15
[12:03] <cjwatson> xnox: but feature branches should always target lp:click, and then the other branch is for landing
[12:03] <xnox> cjwatson: ack, thanks.
[12:08] <davmor2> tseliot: Morning.  Got hit by bug #1277014 this morning.  I did an apt-get update && apt-get dist-upgrade and everything is working again now.  I'm wondering if it might be that there is something racy there as I was hit by it yesterday when I used it a lot
[12:11] <Chipaca> since the last update, ctrl+space is popping up a keyboard layout switch thingie
[12:11] <Chipaca> as an emacs user, this is a huge problem :(
[12:12] <tseliot> davmor2: that doesn't seem to be a valid bug number
[12:12] <Chipaca> the keyboard layout switcher key was set to super-space, i changed it to ctrl-alt-space just in case, to no avail
[12:12] <davmor2> tseliot: ah it's private
[12:13] <tseliot> davmor2: can you subscribe me, please?
[12:13] <davmor2> tseliot: made it public bug #1277014
[12:17] <seb128> Chipaca, change it in ibus-setup I guess?
[12:17] <Chipaca> augh
[12:17] <Chipaca> seb128: indeed, it says ctrl-space there
[12:18] <Chipaca> seb128: thanks
[12:18] <seb128> Chipaca, yw
[12:18] <Chipaca> seb128: are you aware of a bug about this?
[12:18] <seb128> Chipaca, does changing it resolve the issue?
[12:18] <Chipaca> seb128: I mean: should changing this (in ibus-setup) do the same as changing whatever the indicator thingie changes?
[12:18] <seb128> no, I don't know how a bug about that
[12:19] <seb128> happyaron, ^
[12:19] <seb128> Chipaca, that was discussed in the past, I'm still unsure what the differences between both are
[12:19] <seb128> imho the ibus one should be unset by default
[12:19] <seb128> but I want happyaron to confirm, since he maintains ibus
[12:20] <Chipaca> also, ctrl-space offering two layouts when i only have one configured is quite surprising
[12:20] <seb128> what are the 2 ones?
[12:20] <tseliot> davmor2: ok, thanks, I'll investigate the issue
[12:21] <Chipaca> seb128: one is "English (US)". The other is "English (interna...". I believe the second one is the one I have configured, which starts with the same string.
[12:21] <seb128> Chipaca, I think US is added to the list as a fallback, it should probably not be displayed in the switcher though
[12:22] <Chipaca> also the indicator calling the bar where it's shown it the "menu bar" is not nice
[12:22] <davmor2> tseliot: I turned on the laptop about 4-5 times yesterday for various bits no issues, this morning turn it on and I was dropped to low gfx mode (which doesn't seem to work at all, by the way) dist-upgrade and now I'm back to a working system :) I Don't think there was anything GFX wise installed I'll double check though
[12:23]  * Chipaca stops moaning and gets back to work
[12:23] <mpt> Chipaca, why? That’s what it’s called.
[12:23] <Chipaca> mpt: wait, that bar is called the 'menu bar'?
[12:23] <shadeslayer> RAOF: still waiting for an answer
[12:23] <Chipaca> that bar, where a bunch of stuff is always present, and menus are only sometimes present, is called the 'menu bar'?
[12:24] <shadeslayer> seb128: ping
[12:24] <seb128> shadeslayer, hey
[12:25] <shadeslayer> seb128: any idea who maintains apturl? You were the last person to touch it
[12:25] <seb128> shadeslayer, not sure it's actively maintained, why?
[12:25] <seb128> shadeslayer, but mvo is the closest from a maintainer for it
[12:25] <tseliot> davmor2: ok
[12:25] <shadeslayer> seb128: well because apparently it doesn't work on any of the flavors or ubuntu for that matter
[12:26] <mpt> Chipaca, except for maximized window buttons, that stuff is all menus. Compare the Power panel of System Settings, and the Clock tab of the Time & Date panel.
[12:26] <seb128> shadeslayer, do you have a patch?
[12:26] <shadeslayer> seb128: sort of https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1261178/comments/1
[12:26] <shadeslayer> seb128: that sorts it out on Ubuntu and Xubuntu at the very least
[12:26] <shadeslayer> but not on Kubuntu
[12:27] <Chipaca> mpt: the indicators are considered menus?
[12:27] <seb128> shadeslayer, that bug is about firefox, not apturl
[12:27] <mpt> Chipaca, that was the whole point of introducing them in the first place.
[12:27] <shadeslayer> seb128: it most certainly is since apturl.js is provided by apturl
[12:28] <shadeslayer> apturl-common: /etc/firefox/pref/apturl.js
[12:28] <davmor2> tseliot: no x-org but there was a kernel+headers etc update so that may of had an effect
[12:28] <seb128> shadeslayer, running e.g
[12:28] <seb128> $ apturl-gtk apt:samba
[12:28] <seb128> works fine for me
[12:28] <shadeslayer> seb128: changed affected package to apturl
[12:28] <shadeslayer> seb128: sure, but try : apt://samba in firefox
[12:28] <Chipaca> mpt: the point of indicators was not to call them menus, i'm sure
[12:29] <seb128> shadeslayer, "sure", you just said that apturl didn't work
[12:29] <seb128> shadeslayer, do you have an example of website using an apt url?
[12:29] <mpt> Chipaca, http://design.canonical.com/2010/04/notification-area/
[12:29] <shadeslayer> okay, maybe I worded it poorly, but the bug is clearly in apturl since it does not symlink the file
[12:30] <shadeslayer> seb128: apps.ubuntu.com ? :)
[12:30] <seb128> shadeslayer, ok, I understand what you mean now, but it's not "apturl doesn't work at all", it's "apturl integration is buggy"
[12:30] <Chipaca> mpt: well i'll be
[12:30] <shadeslayer> seb128: yeah, to be more verbsoe, apturl integration with firefox is buggy
[12:31] <shadeslayer> http://www.getdeb.net/software/xVideoServiceThief
[12:31] <shadeslayer> so get deb uses apturl too ^^
[12:31] <Chipaca> mpt: i would've never, ever thought we called those things menus
[12:31] <Chipaca> mpt: i shall use the correct name from here on then
[12:31] <mpt> :)
[12:31] <seb128> chrisccoulson, hey, could you have a look to https://bugs.launchpad.net/ubuntu/+source/apturl/+bug/1261178 ? is that a firefox issue?
[12:36] <seb128> chrisccoulson, reading https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1169320/comments/2 ... should /usr/lib/firefox/defaults/pref be used indeed?
[12:39] <seb128> shadeslayer, I'm going to get it fixed, thanks for pointing the issue
[12:40] <chrisccoulson> seb128, yes, it's a firefox issue
[12:40] <chrisccoulson> adding a preference override is definitely not the correct fix though
[12:40] <seb128> chrisccoulson, should apturl just install that file in /usr/lib/firefox/defaults/pref ? that seems to make things work
[12:40] <chrisccoulson> seb128, no, that's wrong. nobody should be installing any files in there
[12:41] <seb128> chrisccoulson, ok, what's the correct fix then? ;-)
[12:41] <chrisccoulson> the URI handling in firefox needs fixing
[12:41] <seb128> shrug
[12:41] <seb128> that sounds like something non trivial :/
[12:42] <seb128> chrisccoulson, can I just do the wrong thing and install the file in that dir nobody should be using until that happens? ;-)
[12:43] <chrisccoulson> seb128, no, please don't do that ;)
[12:43] <seb128> chrisccoulson, can you fix the url handling then? ;-)
[12:43] <chrisccoulson> it needs somebody who understands the code in http://hg.mozilla.org/mozilla-central/file/d8d8fa98ee7d/uriloader/exthandler ;)
[12:45] <seb128> chrisccoulson, if you say so, I'm unsure why we needed that apturl.js at all, I assumed it was because that's not a standard handler
[13:03] <apachelogger> can anyone explain what the output regarding kubuntu-full means http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt please? or more to the point, why it is not considered for upgrade
[13:27] <cjwatson> apachelogger: it means that the arm64 kubuntu-full package would be uninstallable if promoted; proposed-migration won't increase the global uninstallable count
[13:27] <cjwatson>  kubuntu-full : Depends: calligra but it is not going to be installed
[13:27] <cjwatson>                 Depends: kdeedu but it is not going to be installed
[13:27] <cjwatson>                 Depends: kdenetwork but it is not going to be installed
[13:27] <cjwatson> that's the cause
[13:29] <cjwatson> we could hack those out of the seeds for arm64, but I'd rather see them all built since that's simpler all round
[13:30] <cjwatson> the current blocker is https://launchpad.net/ubuntu/+source/opengtl/0.9.18-0ubuntu1/+build/5378634, since arm64 never had llvm-3.3; it might be worth attempting to bump that to llvm-3.4
[13:31] <Riddell> cjwatson: where do you read those lines you pasted?
[13:32] <cjwatson> I ran "chdist apt-get trusty-proposed-arm64 install kubuntu-full" in a suitable chdist instance
[13:33] <Riddell> hmm, chdist sounds like something I should get to know
[13:34] <cjwatson> It's very handy
[13:35] <cjwatson> You obviously have to not let it actually try to install anything since it very much won't work
[13:35]  * rbasak uses a wrapper he calls hcdist which fixes chdist's braindead parameter ordering
[13:36] <Maulkin> cjwatson: I'm also lurking in here in case people have questions
[13:37]  * cjwatson nods
[13:44] <apachelogger> cjwatson: uh, thank you
[13:52] <Maulkin> cjwatson: you have mail for moderation.
[13:53] <pitti> Maulkin: ah, the valve games? moderating
[13:53] <Maulkin> pitti: yup
[13:54] <Maulkin> Thanks :)
[13:54] <pitti> nice!
[13:54] <Maulkin> pitti: Enjoy!
[13:54] <pitti> so after DoSing the Debian community, the Ubuntu community will be game-DoSed next :0
[13:54]  * pitti repairs his smiley -- ☺
[13:55] <Maulkin> Pretty much, and there's another one we're looking at too, but working out how to deal with the requests is more tricky. Apparently GPG isn't universal yet!
[14:00] <cjwatson> pitti: ah, you're too quick for me
[14:05] <xnox> Maulkin: well, launchpad account must have an email address setup, check launchpad account membership in e.g. ~ubuntu-members (or whatever the restriction is) and mail the activation keys via launchpad contact that user...
[14:05] <directhex> time to cower in fear of my inbox?
[14:05] <xnox> Maulkin: most of above is available over API I believe.
[14:05] <Maulkin> directhex: ack
[14:06] <xnox> Maulkin: uploading ~ubuntu-members have gpg key attached to their launchpad-id, so can verify that signed requests for a given id matches the key for that id on launchpad.
[14:07] <xnox> Maulkin: and launchpad does do gpg-signed challenge to add the gpg key to the account.
[14:07] <directhex> xnox, cjwatson helped me extract all valid keys from LP
[14:07] <xnox> (gpg-encrypted challenge that is)
[14:07] <xnox> directhex: i hope they aren't a lot of duplicates =)
[14:07] <directhex> Maulkin, which ML did that go on?
[14:08] <Maulkin> directhex: ubuntu-devel-announce
[14:13] <maswan> directhex: Ok, I'll slack yet another week before dusting off my very dusty gpg key then. :)
[14:14] <cjwatson> xnox: I used the correct approach, which is to follow ArchivePermission records attached to the primary archive
[14:17] <xnox> cjwatson: interesting, i see =)
[14:22] <mterry> @pilot in
[14:32] <mlankhorst> @pilot in
[14:38] <tseliot> davmor2: I think the problem lies in X, but we'll see...
[14:42] <davmor2> tseliot: right.
[14:42] <Riddell> can anyone give me the output of this on ppc64el and arm64? dpkg-architecture -qDEB_HOST_GNU_CPU
[14:42] <xnox> Riddell: dpkg-architecture -qDEB_HOST_GNU_CPU -aarm64
[14:43] <xnox> Riddell: dpkg-architecture -qDEB_HOST_GNU_CPU -appc64el
[14:43] <xnox> =)
[14:43] <Riddell> xnox: you're a genius
[14:44] <xnox> Riddell: nah, dpkg just hardcodes _all_ values for any arch =)
[14:50] <tseliot> davmor2: was the system set to use intel or nvidia when the system crashed?
[14:51] <davmor2> tseliot: let me double check for you
[14:51] <davmor2> tseliot: intel for me
[14:52] <tseliot> davmor2: ok, that's probably good news. Thanks
[14:53] <davmor2> tseliot: no worries
[15:13] <rbasak> Conflicting packages can be concurrently be in a removed-but-not-purged state, right?
[15:15] <cjwatson> Yes
[15:15] <rbasak> Thanks
[15:18] <rbasak> So mysql-server-5.5 owns /var/lib/mysql, and conflicts with mysql-server-5.6 (say), which does the same, and they conflict. What's the expected behaviour on package purge? Should /var/lib/mysql, which contains the relevant database itself, be purged? Currently, there's some really ugly code in this area.
[15:19] <rbasak> There's a debconf option to say what should happen, but also code to try and not do the purge if a different mysql-server-* is installed, since otherwise it would destroy the wrong data.
[15:19] <rbasak> The whole arrangement seems wrong to me, but I'm not sure of the correct solution.
[15:23] <arges> @pilot in
[15:29]  * dholbach hugs arges, mterry and mlankhorst
[15:29] <arges> lots of patch pilot love today
[15:30] <Laney> feel the lurve
[15:30] <mterry> arges, mlankhorst: btw, I was doing a run of syncs.  When I'm done I'll start on merge requests unless ya'll have started any
[15:30] <mterry> Didn't realize I had so much company today  :)
[15:31] <Laney> don't forget to prod the harder things along ;-)
[15:31] <Laney> (re: conversation in #-meeting atm)
[15:33] <arges> mterry: i'm working on kexec-tools atrm
[15:33] <mlankhorst> mterry: well hard for me since I'm not core-dev O:-)
[15:33] <mterry> arges, cool
[15:34] <Laney> no! you can help by reviewing and then communicating your findings to your fellow pilots so that they can upload
[15:34] <mterry> mlankhorst, yar if you reviewed a request in main that would make my job easier, I could just push a button then :)
[15:35] <Laney> patch piloting != uploading
[15:35] <Laney> if I drew a venn diagram there would be an overlap but one wouldn't be contained in the other
[15:40] <xnox> Laney: venn diagram for above: https://fbcdn-sphotos-d-a.akamaihd.net/hphotos-ak-prn2/t1/1920184_10153960264685727_501779264_n.jpg
[15:40] <mterry> :)
[15:41] <Laney> :D
[15:45] <mlankhorst> o.O
[15:48] <bdmurray> pitti: so then if a retracer config has -updates available the package version from -updates will be chosen regardless of whether or not the crashing system was using it, correct?
[15:49] <mlankhorst> @pilout out
[15:49] <udevbot> Error: "pilout" is not a valid command.
[15:49] <mlankhorst> ugh, have to run!
[15:49] <mlankhorst> @pilot out
[15:49] <pitti> bdmurray: right
[15:49] <bdmurray> pitti: do you think it would be much work to change that?
[15:50] <pitti> bdmurray: a few hours probably
[15:57]  * mterry works on makecoredump merge
[15:57] <mterry> makedumpfile that is
[16:11]  * mterry works on sshfs-fuse
[16:14] <ari-tczew> o/
[16:15] <ari-tczew> mterry: the change is forwarded to Debian
[16:15] <mterry> ari-tczew, oh good, I was about to look
[16:16] <mterry> ah, they accepted already
[16:16] <mterry> sync in the future, yay!  :)
[16:21] <ari-tczew> ;)
[16:24]  * mterry looks at zabbix, another Artur production
[16:26] <Laney> cjwatson: could you please moderate my u-d-a mail?
[16:28] <Laney> mterry: ari-tczew can now upload himself ;-)
[16:28] <caribou> mterry: thanks for makedumpfile; I got a bunch of uploads on duplicity if you fell like it ;-)
[16:29] <mterry> caribou, oh right!
[16:29] <mterry> caribou, yeah I should probably do those for ya
[16:29] <mterry> Laney, oh?  good news!
[16:29] <cjwatson> Laney: done
[16:30] <Laney> cheers
[16:30] <ari-tczew> Laney: not for main, unfortunately
[16:31] <Laney> ah
[16:31] <Laney> yeah, keep on getting sponsored there
[16:31] <mterry> ari-tczew, well, you can bug 1277268 off my hands then!  :)
[16:31] <mterry> *take
[16:32] <ari-tczew> mterry: sure
[16:32] <mterry> ari-tczew, congrats and welcome btw!  :)
[16:32]  * ari-tczew is out of battery
[16:33] <mterry> humph
[16:41] <xnox> Laney: lol, i should be elected straight out of the bat then ;-)
[17:13]  * arges looks at sudo merge
[17:20] <ogra_> arges, again ?!?
[17:21] <ogra_> feels like there are weekly merges now :)
[17:21] <arges> ogra_: i just looked at the grab-merge page and it was there
[17:23] <arges> but yea i see your point
[17:25] <ClientAlive> I would like to apply the patch given for bug 1161594 : https://bugs.launchpad.net/ubuntu/+source/gdevilspie/+bug/1161594?comments=all   but I am not comfortable enough with the process and don't feel the instruction given in post #9 : https://bugs.launchpad.net/ubuntu/+source/gdevilspie/+bug/1161594/comments/9   is adequate for me. Would someone be so kind as to clarify the instructions given in post #9, make sure nothing is missing,
[17:26] <ClientAlive> and walk me through the process for me, my first time doing something like this ?
[17:44] <arges> ClientAlive: so this is a bug in trusty?
[17:45] <ClientAlive> arges: I'm running Saucy
[17:45] <ClientAlive> It is a bug for me
[17:46] <arges> ClientAlive: ok so you know its a bug in saucy. So generally we first need to see if its a bug in the development release before we do whats called an SRU to stable releases
[17:46] <arges> from the look of it both trusty/saucy are the same version
[17:46] <ClientAlive> arges: I kinda need this app ( in fact, I was hoping to use it today ). Is there anything I can do?
[17:47] <ClientAlive> ok
[17:48] <arges> ClientAlive: so to get the package properly fixed it takes time. The SRU process can't happen immediately since it needs to go through testing and verification
[17:48] <arges> ClientAlive: it looks like somebody posted a test package that you could try to verify on your own system, and in the meantime we work on getting it fixed properly
[17:49] <arges> ClientAlive: are you the author of this fix?
[17:50] <ClientAlive> arges: No I am not. While I am studying to be a web developer/sortware developer, I'm far from knowing how to do something like that.
[17:50] <arges> ClientAlive: ok let me take a look
[17:51] <ClientAlive> arges: When you say test package, are you referring to post #10 ? Is that what that .deb is?
[17:51] <ClientAlive> ok
[17:51] <ClientAlive> thank you
[17:51] <arges> ClientAlive: yea a .deb is a debian package. This is what ubuntu/debian use to package and install software
[17:51] <arges> ClientAlive: so you could download that package and type 'dpkg -i <name of package>' in a terminal, or double click on the .deb file. You should be careful to ensure you trust the package you are installed
[17:51] <arges> installing
[17:54] <ClientAlive> arges: Ok, cool. May I ask, should I first remove the gdevilspie I installed through software center? And, if so, what is the best way to do that? My concern is mainly to do with whether I need to remove both devilspie and gdevilspie or if just removing gdevilspie would be sufficiant. Also, Would it be better to do a apt-get purge --autoremove   or something other?
[17:54] <ClientAlive> Thanks
[17:57] <arges> ClientAlive: should be able to just install it without removing since it should be built against the same version
[17:57] <ClientAlive> arges: Thanks
[17:59]  * mterry looks at dropbear merge
[18:02] <ClientAlive> arges: Appeas to be working just fine now. Your a life saver  :)
[18:13] <jtaylor> doko: so how would be bootstrap pandas/statsmodels on arm64?
[18:14] <ClientAlive> Guess I spoke too soon. Yes, gdevilspie does launch with that .deb installed, and yes the setting to autolaunch the daemon does stay set. However, after closing and restarting the application, it claims the daemon is not running ( even though the option remains ticked ). I don't know if the massage is accurate or not ( that the daemon is not running ) but that's a pretty crucial patrt of gdevilspie.
[18:14] <ClientAlive> Just thought I'd share. fwiw anyhow.
[18:15] <arges> ClientAlive: please add that feedback to the bug. Thanks!
[18:15] <ClientAlive> arges: Will do
[18:15] <mterry> @pilot out
[19:38] <doko> jtaylor, I can have a look. but honestly I don't care that much if the few tests are disabled
[19:38] <jtaylor> doko: k I'll upload pandas witohout the cycle
[19:38] <jtaylor> just test built it
[19:39] <jtaylor> fun 3MB large debian.tar.gz ._.
[19:58] <jtaylor> btw does someone want to get me a backtrace of the numpy segfault on ppc64?
[20:26] <sarnold> pitti: hello, I think the trusty retracers are unhappy again: https://bugs.launchpad.net/bugs/1278071 needs to be retraced still
[20:27] <sarnold> what's this 'malone' that the goofy bot keeps referring to? :)
[20:28] <slangasek> malone is the bugs component of launchpad; largely obsolete nomenclature
[20:29] <sarnold> ah :) thanks
[20:55] <g0twig> hey there
[20:55] <g0twig> I did read this
[20:56] <g0twig> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2014-February/001079.html
[20:56] <g0twig> did anyone of you take this offer?
[20:56] <g0twig> I dont know if I am allowed to accept this offer, well I am Ubuntu Member
[20:57] <g0twig> does this mean I am an "Ubuntu Developer"?
[20:57] <g0twig> I made code contributions to Ubuntu, to gain this status
[20:59] <slangasek> g0twig: that would be a question for Neil (on behalf of Valve); it states "Ubuntu Developers", which would mean members of the ~ubuntu-dev team in Launchpad
[20:59] <slangasek> but I don't know if that's the intent
[20:59] <g0twig> well, than I am not allowed :X
[20:59] <g0twig> I was into Unity stuff
[21:22] <dobey> slangasek, g0twig: you must have upload rights to some package in the archive to get the offer
[21:23] <slangasek> dobey: ok, so the wording is deliberate and it's tied to Ubuntu Developer rights, not Ubuntu Membership - thanks for confirming
[21:25] <dobey> slangasek: right. also, see http://apebox.org/wordpress/linux/595/
[21:26] <dobey> some people were confused about DD vs. contributor and such there
[21:28] <xnox> barry: if you are around, what's the progress on bilingual emulators? are those in the archive yet? or can i somehow test them with my phablet-test-run branch?
[21:29] <barry> xnox: not in the archive yet.  i'm working with the autopilot guys to get on the train, but i think it's more like america and less like germany in that there are delays along the line ;)
[21:30] <xnox> barry: lol =) well there are 10 merge proposals inflight to land, and i guess autopilot re-exec will make the next round of landing.
[21:30] <barry> xnox: that's what we're working toward ;)
[21:31] <xnox> barry: i think i'll ask sergiusens to land phablet-tools branch, after testing it doesn't regress current test-results. Such that when autopilot lands it all just works together =)
[21:31] <xnox> barry: or we will just have impedance mis-match fixes to get everything onto python3.
[21:32] <barry> xnox: that sounds like a plan
[21:32] <xnox> barry: cool =)
[21:39] <spineau> mterry: Hello, I have a new package in the checkbox dependency collection requiring a mir review: checkbox-ng. If you have time today could you please have a look at bug 1277408?
[21:39] <mterry> spineau, literally looking at it now!  :)
[21:39] <spineau> mterry: fantastic, thanks
[21:43] <g0twig> dobey: I am so sad
[21:44] <dobey> g0twig: go get to work and become a dev then
[21:44] <g0twig> dobey: I am not into packaging
[21:45] <g0twig> I am not a fan of those package principles
[21:45] <g0twig> I am a coder
[21:45] <g0twig> I think deb and rpm are outdated concepts
[21:48] <arges> @pilot out
[22:17] <sergiusens> xnox, barry we can put autopilot and phablet-tools in the same atomic train push
[22:17] <thomi> sergiusens: we're in the mniddle of landing a new AP today
[22:18] <sergiusens> thomi, that's a different landing though
[22:18] <thomi> different to what?
[22:18] <sergiusens> read backlog ;-)
[22:18] <xnox> thomi: next one =) autopilot re-exec branch.
[22:19] <thomi> right, but that branch isn't ready yet, AFAIK
[22:19] <xnox> sergiusens: well, phablet-tools can go ahead, as it does a dynamic check if /usr/bin/autopilot on device is new one or old one.
[22:20] <xnox> sergiusens: so, my changes shouldn't regress any existing tests with current autopilot & python2. And it should stay compatible, when autopilot-reexec lands.
[22:20] <sergiusens> xnox, want it in now then?
[22:20] <sergiusens> xnox, I want to wait for balloons to give me the list of ap py3 ready click tests though
[22:20] <xnox> sergiusens: well, having it in the ppa would be nice.
[22:21] <xnox> sergiusens: i don't think there are any py3 ap tests, since no emulators are python3 compatible in the archive.
[22:21] <xnox> sergiusens: so no clicks should declare autopilot_dir and last time I've checked none of them do.
[22:21] <xnox> sergiusens: did you already revert that? or did i not find those that declare that in the archive already / on the images?
[22:23] <RAOF> shadeslayer: Oh, sorry. I don't have any ability to enable deb-src on the buildds. I was just trying to extract reasoning so that someone who *does* could determine whether or not it's compelling.
[22:23] <sergiusens> xnox, I need to revert two
[22:24] <sergiusens> xnox, oh sweet, none have been actually released :-)
[22:25] <ari-tczew> who are the admins of 'Ubuntu Members' ?
[22:25] <ari-tczew> I'd like to set @ubuntu.com alias etc.
[22:27] <StevenK> ari-tczew: https://launchpad.net/~ubuntumembers
[22:32] <xnox> sergiusens: excellent, if they haven't been released they'd need to adapt if phablet-tools lands first.
[22:32] <xnox> sergiusens: can i get new phablet tools into a silo, such that i can do final testing and push it into the archive?
[22:43] <shadeslayer> RAOF: know anyone who could help me with that?
[22:45] <RAOF> shadeslayer: I'd probably poke the almighty cjwatson. That said, there's seems to be a roughly equally easy solution for you that doesn't require deb-src on the buildd - generating debian/control before upload.
[22:46] <RAOF> As far as I can tell the only thing that wouldn't get you is on-LP binary rebuilds. But we don't have them either :)
[22:49] <sergiusens> xnox, sure; but give me a chance to review as well
[22:54] <tkamppeter> jasoncwarner, hi
[23:10] <cjwatson> shadeslayer,RAOF: I think I would prefer not having to make a change to Launchpad to add deb-src to every build for the sake of a single package where there's a reasonable alternative ...
[23:10] <shadeslayer> cjwatson: ack
[23:10] <cjwatson> It *probably* wouldn't be harmful, but it would slow every build down a bit, don't know whether it's worth it
[23:11] <cjwatson> Is deb-src enabled in Debian buildds?
[23:11] <cjwatson> Hmm, https://buildd.debian.org/status/fetch.php?pkg=grub2&arch=amd64&ver=2.02~beta2-6&stamp=1390961236 suggests it is
[23:12] <cjwatson> Maybe it's worth doing just for the sake of alignment then?
[23:12] <cjwatson> shadeslayer: Basically I'm vacillating. :-)  I suggest filing a Launchpad bug, as Launchpad's what feeds the sources.list to each build
[23:12] <shadeslayer> cjwatson: haha, okay :)
[23:13] <cjwatson> I'm surprised this is the first time (AFAIK) in the eight years or so since we switched to LP for builds that it's come up
[23:13] <xnox> cjwatson: i used chdist in android build, to get deb-src lines. But i wouldn't want to slow down _all_ builders because of that.
[23:13] <xnox> (and thus apt-get source)
[23:13] <cjwatson> I was going to mention a performance penalty, but I suspect it's negligible
[23:14] <cjwatson> chdist would work, or other similar approaches with user-level apt configurations, though it's a bit roundabout
[23:14] <xnox> cjwatson: if it does incur in performance penalty, we have quite networking problems =) given that src are smaller than binary packages indexes.
[23:15] <cjwatson> Quite
[23:15] <shadeslayer> cjwatson: I'll file one tomorrow morning
[23:15] <cjwatson> OK, ta
[23:15]  * shadeslayer heads to bed, night \o
[23:17] <xnox> shadeslayer: what's the package in question? and are you sure you must use deb-src on the buildds?
[23:19] <cjwatson> Alignment with Debian's buildds carries a lot of weight with me.  Generally we win a few more things we don't have to mess about with to get them to build every time we fix some aspect of our builds to be more in line with Debian.
[23:19] <cjwatson> And at the very least it means people have fewer things to think about.
[23:20] <xnox> cjwatson: i wonder if deb-src lines enabled, is a pre-requisite for a proper build-using: * stanzas support.
[23:20] <xnox> unless i understand build-using:* wrong.
[23:28] <cjwatson> xnox: I don't think so; you can get enough information for that from binary control fields
[23:29] <cjwatson> The usual Source: if present, else Package: dance