[02:03] <mup> Issue operator#486 closed: Can't send environment to pebble <Created by mthaddon> <Closed by benhoyt> <https://github.com/canonical/operator/issues/486>
[02:03] <mup> PR operator#492 closed: Parse "environment" correctly from YAML: [{k: v}, ...], not {k: v, ...} <Created by benhoyt> <Merged by benhoyt> <https://github.com/canonical/operator/pull/492>
[02:34] <mup> PR operator#485 closed: Get-services API to talk to Pebble /v1/services <Created by benhoyt> <Merged by benhoyt> <https://github.com/canonical/operator/pull/485>
[14:00] <jam1> lewq[m], the fix should now be in the released 2.9-rc7, so it should be in 2.9/candidate
[14:01] <lewq[m]> oh wonderful, I was just this second testing 2.9/edge :)
[14:01] <lewq[m]> (thanks ruivasconcelos for the poke :))
[14:27]  * lewq[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/vdclpWLOHbiHRhuUjngPnhFi/message.txt >
[14:28]  * lewq[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/ymMVXZhDUVkekmllksdWbUxz/message.txt >
[14:30] <lewq[m]> the error message is strange because I haven't deployed into namespace `controller`, rather `controller-testfaster` (the default one `juju` deploys into)
[14:30]  * lewq[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/pUdzOgBUwvwtfgpRKfYTHzhP/message.txt >
[14:31] <lewq[m]> jam1: does that sound familiar at all? was the permissions issue related to something using the wrong k8s namespace?
[14:32] <jam1> So your 'juju status -m kf' looks like it is progressing, even if model-operator in the controller model is complaining, but you aren't deploying there, so while I think there is an issue, I don't think it is the one affecting your deployment
[14:32] <jam1> do you have other errors on "model-operator-0" running in the kf namespace?
[14:34] <lewq[m]> the reason I feel like it's stuck is that `bmon` isn't showing any downloading happening. I'd expect it to be pulling in a bunch of container images.
[14:34] <lewq[m]> and `juju status` doesn't seem to be changing
[14:35]  * lewq[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/AIMjKlTolSEQmMohSyTmUcrA/message.txt >
[14:35] <lewq[m]> mysteriously no logs
[14:35]  * lewq[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/RBBJzaYeSkwrYLnLaVJZKhlM/message.txt >
[14:36]  * lewq[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/eoQwjvDqWthQSIjdTYPgxNvI/message.txt >
[14:37]  * lewq[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/npSWnrUKfsitLdhWlWUHqzWX/message.txt >
[14:38] <lewq[m]> `kubectl get events` shows nothing untoward, everything looks healthy
[14:38] <lewq[m]> (except that juju is not making progress with the deployment)
[14:39] <jam1> lewq[m], hm. so I wonder if we are assuming the controller namespace is 'controller' and not 'controller-testfaster'. Is it possible to bootstrap with a controller namespace? (I feel like we still have a bug to fix, but might allow you to make progress)
[14:40] <lewq[m]> @jam1: anything else i can check for you?
[14:40] <jam1> lewq[m], also, logs for 'controller-0'
[14:40] <jam1> lewq[m], do you have your original 'bootstrap' command?
[14:41] <lewq[m]> https://github.com/mlopsworks/charms/blob/main/.testfaster.yml#L80
[14:42] <lewq[m]> @jam1: controller-0 logs are the last ones i posted
[14:42] <jam1> lewq[m], sure, all your messages are ".../message.txt" so it can be hard to know which ones I have/haven't seen :)
[14:42] <lewq[m]> oh, I'm sorry :)
[14:43] <lewq[m]> what should I try to make the bootstrap command?
[14:43] <jam1> lewq[m], 'juju debug-log --replay -m controller > all-logs.txt'
[14:45] <lewq[m]> https://gist.github.com/lukemarsden/3122960d1f3c768251e7265da66f9a49
[14:46] <lewq[m]> jam1: did you want me to try a different bootstrap command to `juju bootstrap testfaster`, if so what please?
[14:48] <jam1> lewq[m], I'm investigating, I'll get back to you
[14:50] <lewq[m]> thanks!
[19:55] <mup> Issue operator#487 closed: Ports not visible in `juju status` with pebble approach <Created by mthaddon> <Closed by benhoyt> <https://github.com/canonical/operator/issues/487>
[21:27] <mup> PR operator#493 opened: Update Pebble layer field from "default" to "startup" <Created by benhoyt> <https://github.com/canonical/operator/pull/493>


[21:06] <DDoc> hi everyone
[21:06] <DDoc> I need help ! PLS
[21:08] <DDoc> I've been experienced erratic mouse movements, how can I fix this ?
[21:10] <Fuchs> DDoc: hi ,you probably want #ubuntu  instead :)
[21:11] <DDoc> ohhh, tx then
[21:13] <Fuchs> you're welcome :)


[00:12] <ScottK> Dear everyone: Please testbuild before you upload.  I just 'love' it when I see FTBFS that there is no way could ever have worked.
[00:12] <ScottK> kthnxbye
[00:14] <directhex> i'm getting better at that!
[00:15] <dolanor_> (that's so a real pain to find email for the debian/copyright file !!)
[00:15] <dolanor_> 30 min to find a mail of a developer for 1 .h ... :(
[00:16] <directhex> dolanor, welcome to debian/copyright
[00:16] <directhex> please enjoy your stay
[00:17] <ScottK> directhex: In the case that caused me to save that the uploader had inexplicably added a new patch name to debian/patches/series when all the changes in the revision where in the debian dir (no patch).
[00:17] <ScottK> So it FTBFS when it couldn't find the non-extant patch.
[00:18] <dolanor_> directhex: thanks ^^'
[00:18] <ScottK> There is no way in God's green Earth that was test built.
[00:18] <ScottK> Unfortunately Daniel Hahler lives in +0100, so I imagine he uploaded and went to bed.
[00:20] <ScottK> If you see him, let him know I want that 15 minutes of my life back.
[00:20]  * ScottK steps off the soap box.
[00:21]  * Laney snoops
[00:23]  * directhex burns soapbox for warmth
[00:23]  * directhex also wonders the chances of a motu in the UK having an intel core i7 processor
[00:25] <Laney> Good god, how can I still *never* remember to run update-maintainer?
[00:26] <Laney> also, how does my housemate not understand that running your torrents at full upstream is not a good idea?
[00:26]  * Laney mutters
[00:26] <directhex> fire him into the sun?
[00:26] <directhex> also, bedtime
[00:27] <Laney> I think I will
[00:27] <Laney> nn
[00:27] <dolanor_> and when some people do captcha for email, that's even harder !
[00:27] <dolanor_> http://www.smilax.org/101
[00:28] <dolanor_> (love the area code of his)
[00:28] <ScottK> Laney: This will make your snooping easier: http://launchpadlibrarian.net/22618531/lighttpd_1.4.19-5ubuntu2_1.4.19-5ubuntu3.diff.gz
[00:28] <dolanor_> but when you see what 123people do, you understand why some become paranoid ...
[00:28] <Laney> ScottK: Yeah, I found it
[00:28] <Laney> why test build locally when you have several powerful buildds to do it for you?
[00:29] <ScottK> Yes, why confine the breakage to your system when you can break the archive.
[00:29] <ScottK> dolanor: Captcha for email?  You mean like Challenge and Response?
[00:34] <directhex> ScottK, "click this url and fill in the captcha for your mail to be relayed"
[00:35] <ScottK> I take stuff like that as a sign they don't actually want mail from me.
[00:35] <directhex> heh
[00:35] <directhex> anyway, bed
[01:05] <dolanor_> ScottK: yes some captcha
[01:05] <dolanor_> not automatic, though
[01:06] <dolanor_> You have to understand english to determine his mail or physical address
[01:06] <dolanor_> hmmm, is the mail in copyright mandatory ? I've search for 30 min for 1 email, and can't find any clue for that ...
[01:08] <nhandler> dolanor_: I don't think it is mandatory
[01:12] <dolanor_> nhandler: ok, so i'll skip this one :o
[01:12] <dolanor_> lucky me, he was the last one
[01:18] <dolanor_> what is the command to avoid typing gpg password at each debuild ?
[01:19] <ScottK> dolanor: Install gnupg-agent.
[01:21] <dolanor_> i have gpg-agent running, is it that ?
[01:23] <tgm4883> dolanor, I followed this https://help.ubuntu.com/community/KMailGPGAgent
[01:24] <tgm4883> F me
[01:24] <tgm4883> dolanor, and by that link, I meant https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[01:24] <tgm4883> sorry about that
[01:27] <quadrispro> dolanor_: hi! hexdiff looks good, I'm test-building it now
[01:28] <dolanor_> sorry quadrispro, I misguided you with X-Comment
[01:28] <dolanor_> you were right !
[01:28] <dolanor_> I was too lazy to read the entire RFC :o
[01:28] <quadrispro> :)
[01:28] <quadrispro> it builds fine -> http://home.alessiotreglia.com/jaunty/result/hexdiff_0.0.53-0ubuntu1/hexdiff_0.0.53-0ubuntu1.buildlog
[01:28] <dolanor_> I'm reading it tgm4883, thanks :)
[01:29] <quadrispro> dolanor_:  there's just a little thing -> I: hexdiff: hyphen-used-as-minus-sign usr/share/man/fr/man1/hexdiff.1.gz:7
[01:36] <dolanor_> quadrispro: oh, I thought I corrected that one
[01:37] <dolanor_> hmmmm, that's the original manpage
[01:37] <dolanor_> I didn't modify it at all
[01:37] <dolanor_> must I provide a patch ?
[01:37] <quadrispro> dolanor_: no no
[01:37] <quadrispro> dolanor_: it's not very important
[01:39] <dolanor_> tgm4883: hmmm, the pinentry-gtk doesn't work for me
[01:39] <dolanor_> I can't use the graphical gpg manager of gnome
[01:39] <quadrispro> dolanor_: the application name is Visual Hexdiff -> http://tboudet.free.fr/hexdiff/
[01:39] <dolanor_> don't know why ...
[01:39] <dolanor_> I can't type in
[01:39] <quadrispro> dolanor_: why upstream doesn't provide the last release?? :-/
[01:40] <dolanor_> Not sure :) google for it. If you type "visual hexdiff", it find some sites speaking of this one. If you type "Visuel hexdiff", you get the official website
[01:40] <dolanor_> because I'm in close contact with upstream
[01:41] <quadrispro> ah-ah! you're right
[01:41] <quadrispro> ok ok
[01:41] <dolanor_> he wait for me to upload the new version
[01:41] <dolanor_> since he is quite busy, he hasn't time to upload every minor thing that I change :p
[01:42] <quadrispro> I understand
[01:52] <quadrispro> dolanor_: uploaded to Jaunty NEW
[01:52] <quadrispro> bug 317331
[01:58] <tgm4883> doko, did you go though the tips and tricks part of that link/
[02:00] <dolanor_> quadrispro: \o/
[02:00] <dolanor_> thanks :)
[02:01] <quadrispro> you're welcome
[02:01] <quadrispro> thanks for your work ;)
[02:02] <ScottK> dolanor: pinentry-gtk you almost certainly don't want.  Try pinentry-gtk2.
[02:04] <TheMuso> c
[02:05] <ScottK> dolanor: What release are you running?
[02:07] <dolanor_> ScottK : the pinentry bug since I use SCIM ...
[02:07] <dolanor_> https://bugs.edge.launchpad.net/ubuntu/+source/seahorse/+bug/284044
[02:08] <ScottK> dolanor: seahorse is not much of an agent.  It's pretty broken.
[02:08] <ScottK> dolanor: The reason I ask is that we removed pinentry-gtk in Gutsy, so either you've upgraded your system several times or you're using an olde release.
[02:09] <dolanor_> no no, I was using a shortcut
[02:10] <dolanor_> I don't know exactly what utility it use, but this is the window from seahorse when I have GPGKEY env set
[02:10] <dolanor_> can't I use the gpg-agent with only terminal prompt ?
[02:11] <ScottK> You should be able to.  I don't use Gnome, so I can't say how Seahorse gets involved.
[02:13] <jmarsden> dolanor_: sudo apt-get install gnupg-agent  && man gpg-agent
[02:14] <dolanor_> jmarsden: already done, the bug is between scim and seahorse
[02:14] <dolanor_> :)
[02:14] <ScottK> jmarsden: Part of the problem is that Seahorse is involved.   But at least... It works :)
[02:15] <kolby> seahorse could get better.
[02:15] <kolby> right now it isn't very useful.
[02:16] <dolanor_> another question ... Any cdbs guru there ?
[02:17] <ScottK> kolby: As recently as the version in Hardy it would do 'fun' stuff like remove an existing gnupg.conf and replace it with a blank one (except I nice comment confessing it's sins).
[02:17] <ScottK> !ask
[02:17] <ScottK> dolanor: ^^
[02:17] <dolanor_> ^^
[02:18] <kolby> World of Goo came out for Linux today
[02:18] <kolby> it's a game I've never heard of... it has a debian package => it's related to motu.
[02:18] <kolby> (not really) I just found it interesting.
[02:19] <dolanor_> In debian/rules with cdbs, it tells : put any env var here (after the makefile.mk include, etc ...) but if I set DEBBUILDDIR after the include ... the options is not passed to make
[02:19] <dolanor_> kolby: world of goo is a great game
[02:19] <dolanor_> I don't really like puzzle game, but I think I like this one very much :)
[02:19] <kolby> Yay !  ^^
[02:19] <kolby> I have the demo
[02:20] <dolanor_> yes me too
[02:20] <kolby> I might buy it then
[02:20]  * kolby plays games...
[02:20] <dolanor_> I can't afford the 15€ right now (french taxes, ouch), but next month, he is mine
[02:20] <sbaginov> hi all! got a bug to file... any info on how to do it?
[02:20] <dolanor_> so I'll play the demo ... And for now I'm blocked by tower of goo
[02:20] <kolby> launchpad, right?
[02:21] <dolanor_> sbaginov: just fill the bug description in launchpad :) (But verify if it doesn't exist on launchpad already)
[02:21] <kolby> Then there's this:  https://help.ubuntu.com/community/ReportingBugs
[02:21] <sbaginov> thank you
[02:22] <kolby> I hope I gave you the right info.  I'm new here.
[02:23] <sbaginov> yes, i found the bugs list and no info on mine, but i did not know how to report it even if i was logged in. i thought that motu had its page to report bugs
[02:24] <dolanor_> I think I'll buy world of goo for my mother... I just installed ubuntu for her ^^ Must keep her on it by any means :p She is fond of those type of games
[03:08] <tgm4883> Can I please get a REVU on http://revu.ubuntuwire.com/p/mythnettv
[03:35] <dolanor_> tgm4883: looking at it
[03:35] <tgm4883> dolanor_, thanks
[03:38] <dolanor_> tgm4883: ftbfs
[03:38] <tgm4883> :/
[03:38] <dolanor_> tgm4883: just kidding
[03:39] <dolanor_> but I'm no expert in python package
[03:39] <tgm4883> lol, you got me ;)
[03:39] <dolanor_> from what I see, it is good
[03:39] <dolanor_> except from the COPYING file
[03:39] <dolanor_> it is still in the .deb
[03:39] <tgm4883> what about the copying file?
[03:39] <tgm4883> hmm
[03:40] <tgm4883> let me get on that like a pirate getting some booty
[03:41] <dolanor_> as said superm1 or mok0, there shouldn't be a COPYING file in the .deb, only the source file
[03:41] <dolanor_> I'm commenting on revu
[03:45] <dolanor_> did you patch yourself the original source package ?
[03:45] <dolanor_> without dpatch ?
[03:46] <tgm4883> dolanor_, when adding the license?
[03:48] <dolanor_> I speak for setup.py
[03:48] <dolanor_> hmmmm, I may be dumb
[03:48] <dolanor_> wait :p
[03:49] <dolanor_> no I'm not that dumb :p
[03:49] <tgm4883> all editing i've done should be in either dpatches or done upstream
[03:49] <dolanor_> so you wrote setup.py in upstream ?
[03:49] <tgm4883> yea
[03:49] <dolanor_> ok
[03:49] <dolanor_> so, 1 more issue with copyright :)
[03:49] <dolanor_> gflags.py is full of google coder copyright
[03:49] <dolanor_> and BSD license i think
[03:49] <dolanor_> you should add it
[03:49] <tgm4883> hmm
[03:50] <tgm4883> ok, will do
[03:50] <dolanor_> Added comment on revu
[03:50] <dolanor_> and now ... goind to bed ..., already 5:50
[03:50] <dolanor_> bye
[03:52] <tgm4883> night
[09:46] <kpirc> Anyone around who could have a peek at one last issue I'm having with a package on REVU? It's "modglue".
[09:51] <persia> kpirc, What issue are you having?
[10:03] <kpirc> persia, another MOTU made a remark concerning re-factoring of debian/rules to account for arch all in the -dev package. I don't understand what that comment means.
[10:06] <persia> kpirc, Well, packages that are arch-specific or arch-any will run the binary-arch rule.  Packages that are arch-all will run the binary-indep rule.  Your current binary-indep rules doesn't do anything, so it won't build the arch-all binary.
[10:07] <kpirc> persia, strange, when I build the binary packages I do get a -dev package which contains the relevant files. In any case, should I just copy the stuff below binary-arch to the binary-indep section?
[10:08] <persia> kpirc, Also, it's recommended to pass -a and -i to debhelper programs when building both arch-dependent and arch-independent packages from the same source.
[10:08] <persia> Well, you might not need all of them, but yes.
[10:09] <persia> In fact, you don't need all the ones you have listed now for arch-specific.  Read the manpages: I suspect you'll find that many can just be removed.
[10:09] <persia> What architecture do you run?
[10:09] <kpirc> i386
[10:09] <persia> Try setting up an lpia pbuilder or sbuild chroot in parallel.
[10:10] <persia> When you build packages on i386, it builds both arch-dependent and arch-independent binary packages by default.
[10:10] <persia> With lpia, it won't build the arch-independent binary packages by default.
[10:10] <persia> If you try your current source, you'll find that it builds your -dev package also on lpia, which is the source of the complaint.
[10:11] <persia> (for those with amd64 environments, the recommendation is to use i386 and amd64 chroots, as amd64 doesn't get arch-all by default either: no lpia required).
[10:13] <wgrant> persia: Can one not also test just with i386?
[10:15] <kpirc> ok, so now I'm thoroughly confused. Can you give me a rough guess of what my binary-indep and binary-arch parts of debian/rules should look like? I see no dh_* calls which seem to have anything to do with installing the header files, so I don't understand how to change these sections.
[10:16] <persia> wgrant, I suppose.  I find it easier to launch two sbuild sessions in separate architectures and examine the results than remember the appropriate flags to pass to override the default behaviour, and build twice.
[10:17] <persia> kpirc, First lets trim you binary-arch rule.  Do you need each of the helpers?  Also, you want to pass -a as an argument.
[10:20] <kpirc> I don't think there's any helpers that can be dropped, given that this is building a shared library. Should '-a' be given as an argument to all helpers or only specific ones?
[10:20] <persia> OK.  Let's look at some specifics.  How are you using dh_installdocs?
[10:21] <persia> -a should be passed to all helpers in the binary-arch target, and -i to all helpers in the binary-indep target
[10:22] <kpirc> I don't know whether that gets used. I never understand which files these helpers act on, so I was assuming that READMEs and other related material would get installed by this helper.
[10:22] <persia> Does reading man dh_installdocs help you determine this?
[10:23] <kpirc> well, it mentions installing debian/copyright, so I guess I need this one.
[10:23] <persia> OK.  It would also install a README if your package had one, but it doesn't, so it's not important, and yes, you need this one.
[10:23] <persia> How about dh_installexamples?
[10:25] <kpirc> Bad man page for that one. How does dh_installexamples figure out which files count as 'examples'? Does it not do anything without parameters?
[10:26] <persia> It can either take arguments, or look in the contents of a file named "debian/package.examples".  It does nothing if there are no arguments, and this file doesn't exist.
[10:26] <persia> In the case of your package, you have a nice examples directory, which you probably want to install as examples.  Given that it's dev examples, you probably want to install it in the -dev package.
[10:27] <persia> I'd recommend only having `dh_installexamples -i -plibmodglue1-dev` in binary-indep, and not including it in binary-arch.
[10:27] <kpirc> ok. Why the explicit -plibmodglue1-dev ?
[10:28] <persia> Because I think you want to include the examples only for that package.  Of course, you could run it for all arch:all packages, and just only have debian/libmodglue1-dev.examples contain anything.  Your choice.
[10:29] <persia> With the extended argument, I believe you can just use debian/examples.
[10:29] <persia> Since it doesn't matter which way you do it, please pick the one that makes more sense to you.
[10:31] <kpirc> ok
[10:35] <persia> Shall we go through the others individually, or would you like to go through them, and just ask if you have questions?
[10:37] <kpirc> I would say that for a minimal -dev which only installs the 'examples' directory and the header files, I need
[10:38] <kpirc> 	dh_testdir -i
[10:38] <kpirc> 	dh_testroot -i
[10:38] <kpirc> 	dh_installexamples -i
[10:38] <kpirc> 	dh_fixperms -i
[10:38] <kpirc> 	dh_installdeb -i
[10:38] <kpirc> 	dh_gencontrol -i
[10:38] <kpirc> 	dh_md5sums -i
[10:38] <kpirc> 	dh_builddeb -i
[10:38] <kpirc> (plus the debian/libmodglue1-dev.examples file containing 'examples').
[10:38] <persia> Well, I'd probably put the manpages in the -dev package, so put dh_installman there, and dh_compress
[10:39] <StevenK> kpirc: Please use a pastebin
[10:39] <persia> I'd also suggest putting the changelog there, either with dh_installchangelogs, or with dh_link to the changelog from the actual library.
[10:40] <kpirc> no, there are some small binary helper programs which go into the non-dev package, and they need manual pages.
[10:40] <directhex> i'd use dh7, and not manually list any dh_foo stuff
[10:40] <kpirc> (the library itself is still not properly documented; have been spending my time making debian packages ;-))
[10:40] <kpirc> StevenK: sorry
[10:41] <persia> kpirc, So you'd have your section 1 pages in the tools package and the section 3 pages in the -dev package, so you'd put it in both (and need to add a couple package.manpages to get them included with the right binary.
[10:42] <persia> Where "both" means binary-arch and binary-indep (sorry for the lost referent).
[10:43] <kpirc> I only have section 1 pages so far, so I'll keep this as-is for now.
[10:44] <persia> Well, OK, but don't be too surprised if some future reviewer balks at a lack of manpages :)
[10:45] <kpirc> I know. The problem is that I'm only packaging modglue because it is needed by my cadabra package (also waiting on REVU). If I had known all this I would probably have stuffed the lot into cadabra itself, and made it non-public and statically linked to the binary.
[10:46] <persia> kpirc, Well, then you would have had complaints about static linking and embedded libraries :)
[10:47] <persia> Anyway, I'm not sure everyone checks for library-missing-manpage: you might get lucky.
[10:47] <kpirc> you can never please them all...
[10:47] <kpirc> It's work in progress, I can't do all at once _and_ get a decent number of users interested.
[10:48] <kpirc> Release early, release often, so to say.
[10:48] <loic-m> kpirc: you can also just check a common library man page and use it as a model - it saves a lot of time, and might end up faster ;)
[10:49] <persia> loic-m, Except that a *good* set of library manpages actually document each function call, which is a bit more documentation than most application manpages.
[10:49] <kpirc> loic-m: any recommendations for a good C++ library man page? I never use them, they are mostly of the microsoft form: "do_something():  this function does something."
[10:50] <loic-m> persia: that would be quite a pain then ;)
[10:52] <persia> loic-m, Which is precisely why not everyone checks for library-missing-manpage.  Pretty much every reviewer checks for binary-missing-manpage, as that's more directly exposed, and much easier to fix in packaging.
[10:54] <loic-m> kpirc: I can't remember having read any... As long as the doc is there in a way or another (I just checked a bit and couldn't find one ;) )
[10:55] <kpirc> All in the header files so far. It takes _a lot_ of effort to write good library docs, I'd rather have none than a bunch of useless pages.
[10:57] <persia> loic-m, The manpages-dev package as some very good examples, as does glibc-doc.
[10:57] <kpirc> neither of those are C++
[10:57] <directhex> monodoc!
[11:00] <persia> kpirc, libcrypto++-doc has some C++ examples (dunno how good).  Anyway, as discussed above, let's skip writing full documentation for a single-user library right now, and focus on your packaging.
[11:04] <kpirc> persia, ok, I have uploaded a new version to revu, can you give that a look?
[11:04] <mok0> kpirc, look at doxygen
[11:05] <persia> kpirc, I thought you had manpages for some of the helper binaries that belonged in an arch-specific package.
[11:05] <mok0> It can extract documentation from your source files
[11:05] <AndrewGee> Hey all. Any MOTUs available to review my package, gpxviewer? It's an application that allows users to look at GPS traces files in GPX format. Thanks :) http://revu.ubuntuwire.com/details.py?package=gpxviewer
[11:05] <kpirc> mok0: I don't like doxygen, it tends to focus on documentation in which each and every function is documented well, but there is no proper overview (I know, you can do that with doxygen too, but it does not really help you in that area).
[11:06] <persia> kpirc, Also, you either need to install a changelog for your arch:any stuff, or link it with dh_link.
[11:06] <persia> Lastly, how are you using dh_link for your arch:any packages?
[11:06] <persia> On another note, why does control specify debhelper (>=5) and compat have "4"?
[11:06] <kpirc> persia, "dh_link -a". I guess that can go too.
[11:07] <kpirc> persia, because it took me more than 6 months to have someone look at this package... In the meantime versions bumped several times.
[11:07] <mok0> kpirc: that depends on how you do the markup
[11:07] <mok0> mok0: up to you of course
[11:08] <persia> kpirc, I understand the delay, which is why I'm not suggesting dh7: it's just the inconsistency that stands out.
[11:10] <persia> kpirc, Reading through the comments, I'm also curious why you haven't included mok0's contributed symbols file.
[11:12] <persia> kpirc, You probably also want to check the "legal" link from your REVU upload.  I suspect there may be issues with some files (I didn't look in depth).
[11:13] <kpirc> persia: ok, fixed dh_link, compat version, included the symbols file (was on a different machine, forgot to check it in there). Will now check legal.
[11:15] <kpirc> persia: legal, ouch, this is a serious pain, will have to go through all files now. Hang on.
[11:33] <kpirc> persia, ok, have uploaded a new version. Please have a look, and leave a comment on REVU if there's anything else missing (have to run now). Thanks a lot for the help!
[11:55]  * directhex smiles sweetly @ motu-release
[11:56] <sebner> DktrKranz: your turn \o/
[11:57] <DktrKranz> sebner, huh?
[11:58] <DktrKranz> btw, congrats Debian! \o/
[11:58] <sebner> DktrKranz: heh, MD2 beta needs motu-release love to make it into the archive ;D
[11:58] <DktrKranz> md2?
[11:58] <sebner> DktrKranz: monodevelop 2 :P
[11:59] <DktrKranz> heh
[11:59] <DktrKranz> it's not motu-release time already
[11:59] <directhex> DktrKranz, not until tuesday, but reality has a horrible habit of doing things an expected way... see https://lists.ubuntu.com/archives/ubuntu-motu/2008-November/005025.html
[12:02] <DktrKranz> directhex, which stage is current development?
[12:02] <directhex> DktrKranz, beta 1 preview packages are building and being tested
[12:03] <DktrKranz> directhex, has schedule for 2.0 final been defined?
[12:03] <directhex> DktrKranz, yes, let me find their release schedule...
[12:03] <mok0> Is it ok if I tag packages on REVU with my nick? It is a useful way to keep track of  packages I've looked at. It does pollute tag-space, though
[12:04] <sebner> DktrKranz: mid march -> final releaes
[12:04] <sebner> DktrKranz: http://www.monodevelop.com/Development_Roadmap
[12:04] <directhex> DktrKranz, http://monodevelop.com/Development_Roadmap
[12:04] <directhex> hah
[12:04] <sebner> :)
[12:04] <DktrKranz> which one should I follow? :P
[12:04] <DktrKranz> not sebner's ;)
[12:04] <directhex> DktrKranz, we delayed packaging work until upstream feature freeze, so updating the packages would be 0-effort
[12:05] <binarymutant> is there a ruby package that doesn't use cdbs?
[12:05] <directhex> i.e. who knows what would break from alpha1->alpha2 from a packager perspective, but beta1--->final should just be uupdate
[12:06] <DktrKranz> directhex, if we have 2.0beta1 now, I think we can safely ship 2.0 final before release day
[12:06] <DktrKranz> the question is if we want 2.0beta1 now
[12:06] <DktrKranz> I guess there will be several bugs fixed since 1.0
[12:07] <directhex> DktrKranz, yes, and some major new features
[12:07] <directhex> DktrKranz, hence worried about feature freeze more than bug fixes, since bug fixes are due in beta2 and final too
[12:07] <DktrKranz> could we gather some informations and bug fixed somewhere, and make packages available for testing?
[12:09] <directhex> DktrKranz, trying to get my hands on a source package for ppa love
[12:10] <DktrKranz> I could test it from a mono-dumb perspective
[12:10] <DktrKranz> (so I can understand C# a bit)
[12:10] <directhex> DktrKranz, well MD is a nice IDE for other languages too
[12:10]  * DktrKranz is basically a Python-lover guy
[12:11] <directhex> it has a python plugin afaik
[12:12] <directhex> though c# is the main focus of it, that's true
[12:23] <DktrKranz> Laney, gnome-do-plugins FTBFS applying 03_buildsystem_respect_mcs.dpatch, removing it should fix it. Mind looking at it?
[12:23] <Laney> DktrKranz: I am
[12:23] <Laney> and there's another problem
[12:38] <DktrKranz> Laney, re bug 328224, it seems package in experimental didn't transition to new gnome-sharp2 packages
[12:43] <Laney> DktrKranz: is it uninstallable?
[12:44] <DktrKranz> it is until we ship old gnome-sharp2 packages, which are scheduled for removal before release
[12:44] <directhex> DktrKranz, the gnome# transition is a mess. experimental doesn't help
[12:44] <geser> aren't the old gnome-sharp2 packages already on NBS?
[12:44] <DktrKranz> geser, they are
[12:44] <directhex> geser, yes
[12:45] <DktrKranz> directhex, fortunately we're close to finish it
[12:45] <directhex> DktrKranz, excellent
[12:45] <Laney> DktrKranz: Then you'll submit all patches to Debian?!
[12:45] <Laney> ;)
[12:45] <geser> iirc only package build-depending on it are still to be done (tomboy is in progress)
[12:46] <DktrKranz> Laney, not sure if they already have new gnome-sharp2
[12:46] <directhex> problem is there's a little API breakage as well as ABI
[12:46] <directhex> DktrKranz, in experimental... but experimental is a funny beast
[12:46] <DktrKranz> heh :)
[12:46] <Laney> we need to do this transition somehow
[12:46] <Laney> we = debian
[12:46] <directhex> DktrKranz, i.e. you cherry-pick version numbers on things, so building against mono from exp but gnome# from sid is possible
[12:46] <directhex> and infact building against gnome# from exp is hard
[12:46] <DktrKranz> I noticed ;)
[12:47] <DktrKranz> but I noticed it in jaunty, which should *not* be a funny beast at this stage
[12:47] <geser> re Debian experimental: someone set an alias for experimental on the Debian archive: rc-buggy :)
[12:47] <c_korn> http://pastebin.com/d38c51efc lintian message misses the important part. do you know what is going wrong?
[12:48] <geser> remove build-essential from your Build-Depends line in debian/control
[12:48] <DktrKranz> directhex, Laney: except for b-d mangling, there aren't many changes. I just faced some GnomePrint routines (obsolete) to be removed
[12:49] <DktrKranz> I use sed to make this transition ;)
[12:49] <DktrKranz> sed -i 's/libgconf2.0-cil/libgconf2.24-cil/;s/libgnome2.0-cil/libgnome2.24-cil/;s/libgnome-vfs2.0-cil/libgnome-vfs2.24-cil/;s/libart2.0-cil/libart2.24-cil/' debian/control
[12:49] <c_korn> geser: I had the build-dependency g++ before there. lintian wanted me to replace it with build-essential
[12:50] <geser> c_korn: you don't need g++ in Build-Depends unless you need it versioned (very unlikely)
[12:51] <c_korn> so g++ can be expected to be installed in every build environment?
[12:52] <directhex> DktrKranz, we can start to move things to unstable now, where the "funny" goes way..... but meebey's priority is now MD2 ;)
[12:52] <geser> yes, it's guaranteed that build-essential (and it dependencies) are always installed
[12:53] <c_korn> ok, thanks
[12:53] <DktrKranz> directhex, if I can borrow a hand... I'm definitely not good in C#, but it's a good way to learn things
[12:57] <directhex> DktrKranz, i've been working hard in the background really at the debian end... if you need specific help with something, let me know
[12:57] <DktrKranz> sure
[12:57] <DktrKranz> thanks ;)
[12:57] <directhex> DktrKranz, i contribute to ubuntu through alioth & LAUNCHPAD ;p
[12:58] <directhex>  BAH capslock
[13:30] <Laney> DktrKranz: I will fix muine and muinescrobbler
[13:31]  * DktrKranz hugs Laney
[13:34] <_16aR_> Hello
[13:44] <DktrKranz> does anybody notice sound issues with jaunty. my audio is quite distorted
[13:53] <dolanor_> is it possible to have some sort of orig.tar.gz like that : soft_x.y.z-revision.orig.tar.gz ?
[13:53] <dolanor_> with revision made of text
[13:54] <pop79> hi
[13:54] <pop79> im wanting to get involved
[13:54] <dolanor_> pop79: no problem :)
[13:54] <pop79> wait
[13:54] <persia> dolanor, You can certainly do that, although it's only in the rare case you wish to do so.
[13:54] <dolanor_> Lot of work to be done :)
[13:54] <pop79> what im wanting to do is design a presentation of ubuntu
[13:55] <dolanor_> persia: the fact is that the revision is some sort of branch of the original soft. Not already released right now (I've asked upstream to do so). This branch only add Cmake support
[13:55] <mok0> dolanor: doesn't the <IP_ADDRESS>.5.... scheme give you enough variables for defining your version ;-)
[13:55] <pop79> i was discussing it on #ubuntu-offtopic, but they didn't like the idea
[13:55] <persia> pop79, Based on what you've said above, and what you've said on #ubuntu-devel, I'd recommend chatting with the folk in #ubuntu-docs to both build on the work already done, and integrate with future efforts.
[13:56] <pop79> ok
[13:56] <persia> dolanor, Hrm.  That's trickier.  It's usually only used for things like ~ppaX or +dfsgX.  Dunno how to advise you.
[13:56] <pop79> there is only one person there
[13:56] <persia> mok0, Think multiple parallel trees...
[13:56] <dolanor_> persia: and since the original Makefile aren't that cool (I have to modify a lot to have shared lib compiling instead of static, with soname support, etc... With cmake, only a 1 line patch do this
[13:57] <dolanor_> or else, I do a static lib package, but I don't like the idea
[13:58] <pop79> there is soooo much i want to do to help the ubuntu project
[13:58] <dolanor_> as it is preferred to have dynamic lib into debian
[13:58] <dolanor_> (that's a 2d physcis engine in C++)
[13:59] <persia> dolanor, I'd recommend working with upstream to build a common solution, rather than patching in a branch, and packaging your branch.  It will save considerable coordinate issues later.
[13:59] <dolanor_> ok... I try to do with my version and see what happens ?
[13:59] <dolanor_> ok
[14:00] <dolanor_> because right now, the original upstream is ok to add cmake support. But hasn't done it. So the only package is an embedded archive in the forum. Or else you must get it from a branch in the svn
[14:09] <iulian> DktrKranz: Yes, I have the same issue.  I believe there is a bug reported, not sure though.
[14:10] <DktrKranz> iulian, nice to know. If you will remember, could you please subscribe me?
[14:10] <iulian> Sure
[14:21] <geser> dolanor_: using x.y.z-revision as upstream is possible but you have to use an pkg-revision also, e.g. x.y.z-revision-0ubuntu1
[14:21] <geser> as packageversion
[14:26] <persia> One shouldn't use "-" for that, if it can be avoided, as it's confusing.  "+" is generally preferred.
[14:27] <dolanor_> no problems if I use + instead of - then ?
[14:28] <dolanor_> so If I use : box2d_2.0.1+cmake.orig.tar.gz, every body is ok ?
[14:29] <dolanor_> I can even drop the cmake if wanted. That was just better to track from what source it was since it wasn't the official release available in the download section of sourceforge
[14:29] <geser> it's a least better than using 2.0.1-cmake
[14:29] <dolanor_> but i forgot to say that it correct some FTBFS error of the original package n linux :) so it is better anyway :)
[14:30] <dolanor_> allright, I'll use +cmake then, I'm happy with that :)
[14:30] <dolanor_> i'm going now, bye
[14:31] <persia> dolanor, It's still *much* better to coordinate with upstream about it.
[14:32] <persia> dolanor, Given that box2d isn't in either Ubuntu or Debian now, your best bet is to get it into squeeze sometime in the next couple months, and that gives you enough time for upstream to complete the transition and make a proper release.
[14:35] <Laney> Miriam has started packaging box2d in SVN
[14:35] <Laney> (not read context, ignore me if you know this)
[14:52] <RainCT> If I modify the .diff.gz manually, is there some script to update the .diff.gz and .changes files accordingly?
[14:53] <geser> why would you want to modify the .diff.gz manually?
[14:53] <persia> RainCT, Just manually modify the md5sums.
[14:54] <persia> RainCT, Be *very* careful manually adjusting diff.gz: use editdiff if you are at all unsure, and don't upload the result.
[14:54] <RainCT> geser: to remove some crap from it to minimize the debdiff to the previous version, without having to touch debian/rules (as this would allso increase the diff)
[14:54] <persia> RainCT, What!  What are you doing?
[14:54] <RainCT> don't worry, it's not for Ubuntu
[14:54] <RainCT> :P
[14:55] <geser> RainCT: why not edit the debdiff?
[14:55] <persia> No, but trimming diff.gz to minimise debdiff is very rarely actually useful.
[14:55] <RainCT> right, not really sure why I'm messing with this anyway XD
[14:57] <Tamass> hi
[14:58] <RainCT> geser: (because it's not me who is going to look at the debdiff, but someone else who will create it himself)
[14:58] <RainCT> hi Tamass
[14:58] <Tamass> :)
[15:04] <RainCT> uhm.. why did  cowbuilder-hardy login --bindmounts $(pwd)  just delete everything I had in $(pwd)? -.-
[15:07] <pochu> RainCT: I hope $(pwd) wasn't ~ :(
[15:08] <RainCT> heh nope, only half an hour of work but I can redo it in 5 minutes :P
[15:27] <ia> hello. I have set of scripts, which can be installed via "./acpi-scripts.sh install" command. But I would like to make deb package for it. So, could you tell me, please, which the best way to do it? for additional info see http://pastebin.com/m6bf2f60b
[15:28] <RainCT> ia: does that script allow to specify the root dir?
[15:29] <RainCT> ia: you must tell it to install the files into $(CURDIR)/debian/<pkgname> instead of /
[15:31] <ia> RainCT: 1. looks like no. 2. yes, i've tried "$(MAKE) DESTDIR=$(CURDIR)/debian/eeepc-acpi-support install" in "install" section of "rules", but the result was the same (
[15:32] <RainCT> ia: that's for make, not for the script
[15:32] <RainCT> if it doesn't you'll have to patch the script, or do whatever it does yourself in debian/rules
[15:36] <quadrispro> nellery: about bug 329495, I've just prepared a patch :)
[15:44] <mok0> RainCT: Is it OK if I use my nick as a tag on REVU to mark the packages I am following?
[15:45]  * RainCT won't complain, mok0
[15:45] <mok0> RainCT: perhaps there's a better way to achieve the same, though
[15:45] <RainCT> mok0: you don't want e-mail notifications, or?
[15:46] <mok0> RainCT: I am thinking of listing all the packages I'm involved in
[15:46] <RainCT> because packages to which you are subscribed are displayed in your profile..
[15:46] <mok0> ah
[15:46] <RainCT> you can also have a feed for them but then you've to modify the URL every time you want to add a new package
[15:47] <RainCT> revu.ubuntuwire.com/feeds.py?package=pkg,pkg2,pkg3  it's something like that iirc
[15:47] <RainCT> * feed.py
[15:47] <RainCT> I'll add a "Packages which I've commented:" option to the profle
[15:48] <mok0> RainCT: If you click the "mok0" tag, you can see what kind of thing I am lookign for
[15:48] <RainCT> or a filter in index.py even
[15:48] <mok0> RainCT: yes
[15:49] <RainCT> for packages where you've left a comment.. then i'd achieve the same as a tag
[15:49] <mok0> RainCT: right
[15:52] <RainCT> mok0: ok, let me eat something and then I'll get to it
[16:07] <mok0> RainCT: amazing!
[16:14] <superm1> mok0, can you look at tgm4883's other package, mythnettv? it's paired with mythnettv-gui, so i'd like to be able to upload the pair?
[16:28]  * nhandler still thinks the automatic package checks should tag the packages (i.e. bad-maintainer, missing-watch, no-bug-closed, etc)
[16:54] <mok0> superm1: will do
[16:57] <RainCT> mok0: ready, uploading now :)
[16:58] <RainCT> «WHERE sp.sid IN (SELECT sid FROM Upload WHERE upid in (SELECT upid FROM Comments WHERE usid IN (SELECT usid FROM Users WHERE nickname IN ('mok0','rainct'))))»
[16:58] <RainCT> nice, eh? :P
[17:01] <RainCT> (and yes, you can now do /tag/tag1,tag2,tag3 and ?user=user1,user2, etc.)
[17:02] <RainCT> ok, it's up
[17:03] <RainCT> mok0: http://revu.ubuntuwire.com/?user=mok0 (and you can combine it with &tag, &archived and &updated, of course)
[17:03] <nhandler> RainCT: You have no idea how much better you made my REVU life with that feature
[17:04] <mok0> RainCT: cute
[17:05] <mok0> RainCT:  I just deleted the "mok0" tags, and discovered that when you edit the tags, you get a strange string with part of an url
[17:05] <nhandler> RainCT: One more suggestion, add a message at the very top of REVU that says "Showing [archived/unarchived] [new/updated] pacakges [commented on by foo]
[17:09] <RainCT> nhandler: hehe great :)
[17:09] <RainCT> mok0: uhm.. where? that shouldn't happen
[17:09] <RainCT> oh
[17:10] <RainCT> ah, right
[17:10] <RainCT> because I linkified them
[17:11] <mok0> You see it?
[17:11] <RainCT> now I don't know how to fix this properly :(
[17:11] <mok0> I still works
[17:11] <mok0> heh, IT still works
[17:11] <RainCT> does someone know how to get the text between <a ..>HERE</a>, for serveral links, with JS?
[17:14] <Laney> innerText isn't it?
[17:15] <RainCT> Laney: perhaps, but to get it for all of them?
[17:15]  * RainCT is sad JS has no nice list comprehensions :P
[17:16] <Laney> document.getElementsByTagName('a') will give you all of the 'a' tags
[17:17] <Laney> RainCT: And you can use map on that like a good functional programmer
[17:17]  * RainCT grumbles about a   <script language="text/python"   support in Firefox :P
[17:18] <Laney> to get a list of all the innerTexts
[17:18] <Laney> https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference:Objects:Array:map
[17:18]  * RainCT wonders why nobody has though of adding Python scripting support to webbrowsers before! :P :P
[18:33] <kpirc> persia, are you able to advocate the modglue package you helped me with earlier today? (provided, of course, you don't see anything else wrong with it).
[18:41] <kpirc> Is anyone here able to advocate a package for me? (modglue, on REVU) I went through the final bits of cleanup earlier today, just need a second MOTU to ok it.
[19:32] <AndrewGee> Hey all. Any MOTUs available to review my package, gpxviewer? It's an application that allows users to look at GPS traces files in GPX format. Thanks :) http://revu.ubuntuwire.com/details.py?package=gpxviewer
[19:35] <RainCT> Laney: so, how can I convert the result of document.getElementById('tags-list').getElementsByTagName('a') into an array?
[19:37]  * danielm thinks that is already an array
[19:38] <RainCT> directhex: but I save that as  var tags  and then try tags.map but that says that it doesn't have "map"
[19:44] <danielm> i'm not sure but you can try ".length" to check if there is elements on it
[19:44] <RainCT> there is
[19:44] <RainCT> I've now got around this with:   var tags = document.getElementById('tags-list').getElementsByTagName('a'); var tags = Array.prototype.map.call(tags, function(x) { return x.innerText });
[19:44] <RainCT> but the content of tags becomes just ",,"
[19:48] <RainCT> oh, now it works
[19:49] <RainCT> ah
[19:49] <RainCT> innerHTML works, innerText not
[19:50] <danielm> :)
[19:59] <ajmitch_> RainCT: javascript is an evil language to be dabbling in :)
[20:00] <ajmitch_> or maybe it's just my recent struggles with it at work that have made me annoyed with it
[20:00] <RainCT> hhehe yeah
[20:01] <RainCT> at the end I got it working with jquery.. $('#tags-list a').map(function() { return $(this).text(); }).get().join(' ');
[20:19] <tgm4883> can I get a 2nd revu on http://revu.ubuntuwire.com/p/mythnettv
[21:54] <RainCT> mok0: got something nice for you
[21:54]  * RainCT waits for LP to process his commit -.-
[21:56] <RainCT> http://revu.ubuntuwire.com/?search_name=py  :)
[21:57] <nhandler> RainCT: I still think having a search box is the way to go.
[21:57] <RainCT> nhandler: that's on my TODO ;)
[21:58] <andersk> Is there a MOTU sponsor available to review a quick fix in bug 34376? I fixed a regression introduced by the last patch.
[21:59] <andersk> I think that it can then be closed, because the original problem has been addressed.
[21:59] <nhandler> RainCT: Would the search box allow you to restrict the results in the same way as the current URL parameters do?
[21:59] <RainCT> nhandler: yep
[22:00] <RainCT> (it would not be a single box, but a form -hidden by default like the help- with inputs for the different filters)
[22:02] <nhandler> RainCT: Sounds awesome. Would it be possible to get RSS feeds for these custom lists?
[22:02] <RainCT> yeah, I'll work on that too (..somewhen :P)
[22:13] <RainCT> (Now you can also do exclusive searches based on tags, with ?exclude-tag=)
[22:13] <RainCT> this way we can ignore mono packages :D
[22:13]  * RainCT runs away from directhex
[22:15]  * directhex chases after RainCT with a sharpened gpg signature
[22:15] <nhandler> Could we automatically tag packages based on language?
[22:17]  * directhex tags nhandler "visual basic 6"
[22:17]  * nhandler filters all non perl packages and nukes them
[22:19]  * directhex deletes nhandler's kernel
[22:19]  * RainCT helps directhex
[22:21] <ajmitch> RainCT: so how are they tagged? :)
[22:23] <RainCT> ajmitch: above the comment box there is "Tags: [edit]"
[22:23] <RainCT> mok0: caution, games is catching up with python :P
[22:24] <ajmitch> RainCT: I'd take a look, but firefox has decided to die
[22:24] <RainCT> :(
[22:24]  * ajmitch wonders if it'd be possible to encourage the use of debtags
[22:25] <RainCT> here Firefox is stable like a rock since I'm using Flash through ndiswrapper :P
[22:25]  * ajmitch has flashblock enabled, but firefox can still hang
[22:26]  * nhandler wishes pbuilder would behave as well as Firefox does
[22:26] <ajmitch> maybe having 100+ tabs open is a bad thing
[22:27] <RainCT> and most of the times I look at a flash thingie (I also have flashblock, btw) it's greyed out (=crashed) or crashes in the middle, so I don't want to imagine how Firefox would behave without ndiswraper :P
[22:27] <RainCT> nhandler: uhm? It never crashed for me
[22:27] <RainCT> the only weird thing it did was delete a folder a while ago, but that was cowbuilder :P
[22:27] <nhandler> RainCT: It doesn't crash for me. It just refuses to create a Jaunty chroot (works fine for intrepid and sid)
[22:27] <RainCT> nhandler: are you using the script from ubuntu-dev-tools?
[22:28] <ajmitch> create an intrepid chroot & login, --save-after-login & dist-upgrade ?
[22:28] <RainCT> and do you have installed the backported <Idon'trememberwhat>
[22:28] <nhandler> RainCT: No. I have separate .pbuilderrc files for intrpeid, jaunty, and sid. I tried using pbuilder-dist with the same result. And I do have backports enabled
[23:12] <binarymutant> how do I go about asking for a debian sync request? Anyone have any links to that info?
[23:13] <directhex> requestsync
[23:13] <geser> binarymutant: https://wiki.ubuntu.com/SyncRequestProcess
[23:13] <directhex> from ubuntu-dev-tools
[23:13] <binarymutant> thanks :)
[23:17] <RainCT> good night
[23:37] <dolanor_> re
[23:37] <dolanor_> back
[23:38] <dolanor> If use box2d-2.0.1+cmake.orig.tar.gz, do i need to work under the box2d-2.0.1+cmake/ directory too ?


[00:04] <poolie> hi wgz
[00:10] <wgz> hey poolie
[07:37] <vila> hi alll !
[07:58] <mgz> morning!
[08:01] <vila> heya mgz
[08:13] <jelmer> hi mgz, vila
[08:14] <wgz> shall we get this party started?
[08:16]  * vila nods
[08:21] <wgz> I created a thingy via the new cunning means described in a thread on the wotsit
[08:25] <vila> jelmer: joining ?
[08:27] <jelmer> vila: sorry, on my way
[08:27] <vila> jelmer: no worries
[08:46] <bialix> hi
[08:47] <bialix> mgz, vila: can you look at the "what's new iun qbzr 0.22" and check this text for mistakes? http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/view/head:/NEWS.txt
[08:48] <wgz> looking
[08:51] <wgz> seems good bialix
[08:51] <bialix> thank you, wgz
[08:51] <bialix> new hat? new clothes?
[08:51] <bialix> :-)
[08:53] <wgz> I need to dress up in two outfits at once :)
[08:54] <bialix> ninja
[08:57] <bialix> wgz: I'll release qbzr then
[08:57] <bialix> not sure what I can do for explorer right now
[09:05] <wgz> bialix: I want to still get some fixes in for explorer
[10:32] <ccxCZ> can anyone help me with converting svn to bzr? currently I'm stuck at: bzr: ERROR: Unable to convert Subversion path e16/fnlib/fonts/fonts/shinymetal/45/\.tif because it contains characters invalid in Bazaar.
[10:38] <jelmer> ccxCZ: that's a really hard thing to work around, bzr doesn't support backslashes in filenames at the moment
[10:39] <ccxCZ> I guess that filename is there by mistake anyway and I certainly don't need the e16/ subtree
[10:40] <jelmer> ccxCZ: you could dump the svn repository, remove the problematic filename and then import
[10:41] <ccxCZ> can we import from svndump?
[10:42] <ccxCZ> atm I have local copy of the repo obtained with svnsync, can I branch a subdir of that?
[10:43] <ccxCZ> it uses /trunk/projectname layout and I need only few of these
[10:56] <jelmer> ccxCZ: you can use a subdir, you just can't exclude a subdir
[10:56] <jelmer> ccxCZ: "bzr branch" allows you to specify a path in the repo
[10:58] <ccxCZ> ah got it to work now, thanks
[11:35] <ccxCZ> jelmer: I branched out successfully and now I tried to pull new changes from the source on the net http://paste.pocoo.org/show/547220/
[11:46] <ccxCZ> I can svn co from that uri successfully; when I disable all plugins but svn it behaves the same
[11:47] <ccxCZ> fileabug?
[11:49] <jelmer> ccxCZ: you're running an old version f bzr-svn
[11:51] <ccxCZ> should I try 1.1.2 or trunk?
[11:51] <jelmer> 1.1.2
[11:55] <ccxCZ> seems to work now, thanks again
[11:55]  * ccxCZ should have checked for latest version himself
[11:56] <ccxCZ> hmm but why is it checking out the whole history?
[11:56] <jelmer> ccxCZ: it's just caching the revision metadata, not the contents of the revisions
[11:57] <ccxCZ> server is too unstable to get all 6k commits in one session, that's why I used svnsync
[11:57] <ccxCZ> seems I'll have to keep the sync version around for pulling then
[11:57] <ccxCZ> 60k commits actually
[12:01] <ccxCZ> that's one unhappy server :-( bzr: ERROR: A Subversion remote access command failed: REPORT of '/svn/e/!svn/bc/58596': Could not read response body: Connection reset by peer (http://svn.enlightenment.org)
[12:02] <ccxCZ> okay, I'll make some scripts to update my repos from the svnsync copy then
[12:13] <mgz> man, lwn trolls pretty hard of riddell's post about kubuntu
[12:13] <mgz> *off
[12:13] <mgz> and it works, 32 comments already :)
[14:12] <Riddell> mgz: yeah that jono guy holds no punches :)
[14:25] <mgz> Riddell: all those people saying nice things about you too :)
[14:25] <Riddell> I've had two job offers in the last hour :)  [not wanting to take them]
[17:59] <Jesdisciple> I have two revisions numbered 1, local and remote, and the local is the "real" one.  It was actually derived from the remote, but I wrestled with bzr and had to make a new repo with the old code.
[17:59] <Jesdisciple> How can I merge?  I can't find anything about how to specify a "base revision"
[18:00] <Jesdisciple> what I have been trying: bzr merge lp:chaos2d --revision 1
[18:17] <LarstiQ> Jesdisciple: why not just `bzr merge lp:chaos2d`?
[18:20] <Jesdisciple> LarstiQ, $ bzr merge lp:chaos2d
[18:20] <Jesdisciple> Enter passphrase for key '/home/chris/.ssh/id_rsa':
[18:20] <Jesdisciple> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[18:20] <LarstiQ> Jesdisciple: aha
[18:20] <Jesdisciple> ended up finding the solution here http://selfdocumentingcode.blogspot.com/2009/04/merging-unrelated-branches-in-bazaar.html
[18:21] <LarstiQ> Jesdisciple: right, that way you can get it done
[18:22] <LarstiQ> Jesdisciple: but since you're just starting out
[18:23] <LarstiQ> Jesdisciple: do you need the "old" one?
[18:23] <LarstiQ> Jesdisciple: if not, you could maybe just replace it with the new one and go from there
[18:23] <Jesdisciple> nope
[18:23] <Jesdisciple> how...?
[18:23] <LarstiQ> Jesdisciple: `bzr push lp:chaos2d --overwrite` should do it I think
[18:24] <Jesdisciple> (it's too late now, and I accidentally deleted the wrong half of the conflict... now rewriting one of those four files where I had made massive changes)
[18:24] <Jesdisciple> alright, thanks
[18:25] <LarstiQ> Jesdisciple: if you had everything committed, and the merge went wrong, you can use `bzr revert` to get back to the latest commit
[18:25] <Jesdisciple> sweet, thanks
[20:10] <idnar> is bzr-colo in core yet?
[20:11] <idnar> I found some mailing list traffic about something like but couldn't follow the discussion
[20:12] <idnar> ah I guess not
[20:12] <jelmer> idnar: hi
[20:13] <idnar> jelmer: hi :)
[20:13] <jelmer> idnar: there is some degree of colocated branch support in core nowadays
[20:13] <jelmer> idnar: in 2.5 onwards
[21:58] <edakiri> I set global ignores in ~/.bazaar/ignore , but do not see them with 'bzr ignore --default-rules' .  Ideas why?  Strace tells me  ~/.bazaar/ignore is never accessed.
[22:03] <Kamping_Kaiser> edakiri: is your version of bzr new enough to use it?
[22:03] <edakiri> Kamping_Kaiser: Bazaar (bzr) 2.5.0dev6
[22:04] <edakiri> The docs i am looking at are for 2.5.0dev1 , so I figure the version of bzr i have should be new enough.
[22:05] <jelmer> edakiri: I think --default-rules just prints the hardcoded list in bzr itself that it will write out if there is no ~/.bazaar/ignore file
[22:25] <edakiri> I think that is so.
[22:47] <thomi> Hi - qbzr's diff app has an option to ignore whitespace changes. Is there a way to do that with straight 'bzr diff' as well?
[22:54] <jelmer> thomi: hi
[22:54] <thomi> hi jelmer
[22:54] <jelmer> thomi: I think something like "bzr diff --diff-options -w"
[22:56] <thomi> jelmer: ahh, thanks
[23:02] <jelmer> thomi: anytime :) are you having fun in unity land?
[23:03] <thomi> jelmer: yeah, it's good fun. Working from home takes a bit of getting used to though, but once you learn to avoid distractions it gets easier
[23:03] <thomi> I need to get out of the house more though - some weeks I hardly go outside during the day...
[23:53] <lifeless> wgz: hey
[23:53] <lifeless> wgz: so I found a bug in your testtools encoding detection code; triggers implicit decode if the linecache has unicode contents in it
[23:53] <lifeless> \o/


[00:00] <nacc> xnox: i'll see if that's doable and if not just disable the test for now so it can propogate
[00:00] <xnox> yeah, and there is reboot command support in dep8 as well, if you want to like 1) [ -z "$ADT_REBOOT_MARK" ] && setup disks, and then later [ -n "$ADT_REBOOT_MARK" ] && check that daemon is autostarted and running.
[00:00] <xnox> with reboot between the two.
[00:01] <nacc> xnox: thanks, that's handy
[00:01] <xnox> nacc, we can override the test results for open-iscsi to propagate, but that's best to have a fixed test....
[00:04] <nacc> xnox: ack, i'll try and get it fixed by EOW
[00:12] <xnox> mwhudson, there are now smart ExecStartPre= shell script in the systemd unit to bail out when not-needed / setup
[00:12] <xnox> slangasek, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1708313
[00:12] <xnox> not I ?! =)
[00:24] <sergiusens> slangasek: long shot, but can I get snapcraft 2.33 into xenial-updates and zesty-updates? the armhf test failure for snapcraft proper is just timeouts (ran twice already, squid.internal timeout in different tests) and the ubuntu-image ones are test errors in ubuntu-image proper (sil mentioned those are fixed in 1.1)
[00:43] <slangasek> sergiusens: xenial-updates is currently frozen for point release; snapcraft seems safe since it shouldn't impact images but I'll just highlight infinity to double-check
[00:44] <slangasek> checking ubuntu-image; I'm going to re-test with -proposed u-i + snapcraft so it's clear from the log
[00:44] <slangasek> xnox: why should PrivateNetwork fail there?  it's just containers
[00:49] <sergiusens> thanks slangasek
[00:59] <xnox> slangasek, it is a good point. but also i don't know how our armhf infra is setup.
[00:59] <xnox> slangasek, is it priviledged or unpriviledged lxc1? what is the host? are there any config overrides that punch things through?
[01:00] <slangasek> hmm
[01:00] <xnox> at the moment i setup straight up lxc1 artufl armhf container on an artful arm64 host
[01:00] <slangasek> all good questions
[01:00] <xnox> but i suspect the host may not be xenial, and i'm debugging obsolete software not matching production.
[01:00] <slangasek> "may not be xenial" - I would expect it is. don't the logs report the kernel version?
[01:01] <xnox> the logs report armhf kernel....
[01:01] <slangasek> the armhfness is a lie
[01:01] <xnox> testing everything in lxc1 on an old kernel/host with new binaries inside makes a lot of sense when one is developing that for the arm64 android phones.
[01:01] <slangasek> I don't know if it fakes the version?
[01:01]  * xnox wants armhf testing to move to lxd
[01:02]  * xnox wants arm64 lxd testing added, given we do have arm64 hosts hooked up in adt
[01:02]  * xnox wants arm64 kvm testing added - but this might be trickier to do
[01:03] <xnox> slangasek, given we are not doing as much phone testing, i am suspecting our armhf and arm64 testing went downhill.
[01:04] <slangasek> I haven't seen evidence of this in general
[01:04] <slangasek> arm64 will be VMs, not containers, when the RTs finish
[01:04] <xnox> ok.
[01:05] <xnox> moving armhf from lxc to lxd?
[01:05] <xnox> that should be easy, given how reliable s390x lxd is.
[01:05] <xnox> no?
[01:06] <slangasek> that part I don't know
[01:12] <slangasek> xnox: on the autopkgtest side, the infra believes it is using lxd for armhf, not lxc.  kernel is 4.4 on xenial.
[01:14] <xnox> slangasek, how old/new lxd? from release and/or backports?
[01:15] <slangasek> xnox: 2.0.9
[01:16] <slangasek> which I guess means we're a little behind
[01:16] <xnox> slangasek, so trusty?
[01:16] <slangasek> xnox: no, xenial-updates-1
[01:17] <xnox> ah, ok.
[01:23] -queuebot:#ubuntu-release- New: accepted gcc-7-cross-ports [amd64] (artful-proposed) [3ubuntu2]
[01:23] -queuebot:#ubuntu-release- New: accepted node-libs-browser [amd64] (artful-proposed) [2.0.0-1]
[01:23] -queuebot:#ubuntu-release- New: accepted syslog-ng [arm64] (artful-proposed) [3.10.1-3ubuntu1]
[01:23] -queuebot:#ubuntu-release- New: accepted syslog-ng [i386] (artful-proposed) [3.10.1-3ubuntu1]
[01:23] -queuebot:#ubuntu-release- New: accepted syslog-ng [s390x] (artful-proposed) [3.10.1-3ubuntu1]
[01:23] -queuebot:#ubuntu-release- New: accepted gcc-7-cross-ports [i386] (artful-proposed) [3ubuntu2]
[01:23] -queuebot:#ubuntu-release- New: accepted syslog-ng [armhf] (artful-proposed) [3.10.1-3ubuntu1]
[01:23] -queuebot:#ubuntu-release- New: accepted syslog-ng [amd64] (artful-proposed) [3.10.1-3ubuntu1]
[01:23] -queuebot:#ubuntu-release- New: accepted syslog-ng [ppc64el] (artful-proposed) [3.10.1-3ubuntu1]
[01:28] <xnox> slangasek, on artful host, launching artful armhf lxd container says armv8l in uname -a
[01:36] <xnox> slangasek, about stalled amd64/i386 systemd adt tests - can i get a juju log? or like nova console log of the instances running the test?
[01:36] <xnox> or ssh backdoor into them? i think pitti did open up a connection into those machines by hand before.
[01:36] <xnox> running adt tests here on xenial host, with qemu runner, using artful cloud-image as base - passes.
[01:36] <xnox> did that with amd64, todo with i386.
[01:38] <xnox> ..
[01:39] <xnox> i just got hashsum missmatch in ftpmaster.internal
[01:39] <xnox> http://paste.ubuntu.com/25230244/
[01:39] <xnox> this is wow.
[01:41] <slangasek> xnox: sorry, it's dinner time here.  I can look at this later in the evening
[01:41] <xnox> i should sleep too
[01:41]  * xnox goes to drink some tea to calm down
[02:35] <infinity> xnox: Our buildds and autopkgtest hosts are booted with 'compat_uts_machine=armv7l' on the cmdline.
[02:37]  * apw had forgotten that thing exists
[02:38] <infinity> apw: If we could come up with a sane way to boot armv7 images in scalingstack, we could ditch the silly hack.
[02:38] <infinity> Maybe I should find some "free time" (ha ha ha) for that.
[02:38]  * apw giggles at infinity
[02:41] <infinity> jbicha: ubuntu-gnome/xenial seems to have 0 testing so far.
[02:44] <stgraber> xnox: hmm, uname -m not showing the right personality is weird, we don't see that behavior on x86
[02:51] <stgraber> ah, just found apw's kernel patch. Feels pretty weird that linux32 on aarch64 otherwise gives you the exact same as linux64...
[02:51] <jbicha> infinity: sorry, I'll take a look in the morning
[02:52] <apw> stgraber, i thought it gave you something else, just the 32bit form of the hardware, not the form our 32bit images are optimised for
[02:53] <stgraber> oh, it does indeed
[02:53] <stgraber> you get aarch64 for 64bit and armv8l for 32bit
[02:53] <stgraber> root@1ss-arm64:~# uname -a
[02:53] <stgraber> Linux 1ss-arm64 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:48 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
[02:53] <stgraber> root@1ss-arm64:~# setarch linux32 -- uname -a
[02:53] <stgraber> Linux 1ss-arm64 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:48 UTC 2017 armv8l armv8l armv8l GNU/Linux
[02:54] <apw> right, just unfortuantly we are armv7 optimised
[02:54] <infinity> Has less to do with optimisation.
[02:54] <apw> s/optimised/targetted/
[02:55] <infinity> And more to do with Stupid Software doing Stupid Things when building and seeing a uname it doesn't know.
[02:55] <stgraber> it can get even more confusing though :)
[02:55] <infinity> This is why i686 "stalled" on i686 too.
[02:55] <infinity> Despite us now being up to i786 (or i868 for Core, I've lost track) according to Intel.
[02:55] <stgraber> root@blah:~# uname -a
[02:55] <stgraber> Linux blah 4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:07:09 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
[02:55] <infinity> 886...
[02:55] <stgraber> root@blah:~# setarch linux32 -- uname -a
[02:55] <stgraber> Linux blah 4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:07:09 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
[02:55] <stgraber> that's on an arm64 system that doesn't support the 32bit personality
[02:56] <infinity> stgraber: Right, and that's correct.
[02:56] <infinity> Well, more correct would be setarch bubbling up a "that personality no exist" error, but whatever.
[02:56] <stgraber> yeah, I'd expect an error :)
[02:57] <stgraber> oh, the kernel does do the right thing, it's just setarch being useless :)
[02:57] <stgraber> personality(PER_LINUX32)                = -1 EINVAL (Invalid argument)
[02:57] <infinity> Right.
[02:58] <infinity> I still think it was a mistake for ARM to not require v7 compat in v8, but oh well.
[02:59] <infinity> It's an even larger headache than v7 not requiring NEON.
[02:59] <infinity> Mistakes, though, why learn from them?
[03:20] <slangasek> sergiusens: ubuntu-image+snapcraft looking a bit better now in zesty, two passes, two xfails, and one fail (ppc64el)
[03:21] <slangasek> infinity: how frozen is xenial-updates, could snapcraft be released or no?
[03:21] <slangasek> (non-image-affecting)
[03:21] <infinity> slangasek: non-image-affecting is fine.
[04:16] <xnox> infinity, about that. to get "armhf" images booting in scaling stack, all we need is a regular arm64-uefi-firmware image with arm64 kernel and armhf userspace and compat_uts_machine=armv7l. slap together and done. we will still not be able to test armhf kernels in adt, but at least we will gain all the isolation-machine tests
[04:17]  * xnox assumes arm64 images are uefi images in scaling stack. if not mimic whatever arm64 images have for a bootloader.
[04:17] <xnox> basically use multiarch technology and tools
[04:19] <wgrant> xnox, infinity: You can also construct an armhf image that boots an armhf kernel directly, without using UEFI, but it's a bit messy.
[04:20] <slangasek> yes, arm64 images are uefi
[04:20] <wgrant> Last time I tried it it required using images that masqueraded as AMIs and AKIs, so I got ovmf working instead, but direct kernel boot does work on bos01.
[04:25] <infinity> xnox: My point wasn't to boot armhf-on-arm64, I want armhf-on-armhf.  But I'd rather drop armhf entirely, given a perfect world.
[04:48] <xnox> infinity, sure. armhf-on-arm64 kvm is better than lxd for adt testing. armhf-on-armhf does sound backwards.
[04:48] <xnox> to kill armhf, do we need an armv8l port then? or whatever the tag is?
[04:58] <xnox> also what is the point of i386 if joules edison and galileo got axed, and even that were 64-bit capable.
[04:59] -queuebot:#ubuntu-release- New binary: behave [amd64] (artful-proposed/universe) [1.2.5-1ubuntu1] (no packageset)
[06:16] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.3] has been marked as ready
[06:16] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.3] has been marked as ready
[06:23] -queuebot:#ubuntu-release- New binary: te923con [i386] (artful-proposed/universe) [0.6.1-1ubuntu1] (no packageset)
[06:23] -queuebot:#ubuntu-release- New binary: te923con [s390x] (artful-proposed/universe) [0.6.1-1ubuntu1] (no packageset)
[06:23] -queuebot:#ubuntu-release- New binary: te923con [ppc64el] (artful-proposed/universe) [0.6.1-1ubuntu1] (no packageset)
[06:24] -queuebot:#ubuntu-release- New binary: te923con [amd64] (artful-proposed/universe) [0.6.1-1ubuntu1] (no packageset)
[06:29] -queuebot:#ubuntu-release- New binary: te923con [arm64] (artful-proposed/universe) [0.6.1-1ubuntu1] (no packageset)
[06:29] -queuebot:#ubuntu-release- New binary: te923con [armhf] (artful-proposed/universe) [0.6.1-1ubuntu1] (no packageset)
[07:57] <sil2100> infinity: let me pick up netboot amd64 images now for some testing
[07:59] <infinity> sil2100: Not super concerned about netboot testing, it's not really coupled to the ISOs and point release (despite evidence to the contrary).
[08:01] <sil2100> infinity: ok, I'll move to -GNOME then
[08:23] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.3] has been marked as ready
[08:23] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.3] has been marked as ready
[08:51] <sil2100> Ubuntu GNOME looking fine on amd64, giving a quick spin of i386 now
[10:15] <LocutusOfBorg> hello, not sure if tsimonq2 already requested that, but please force badtest
[10:15] <LocutusOfBorg> fpc/3.0.2+dfsg-2 on amd64 (zesty)
[10:16] <LocutusOfBorg> libreoffice/1:5.3.1-0ubuntu2 i386 (zesty=
[10:16] <LocutusOfBorg> we tried them with themself as trigger
[10:16] <LocutusOfBorg> and the failed
[10:18] <tsimonq2> LocutusOfBorg: I didn't say something yet, thank you :)
[10:25] <infinity> LocutusOfBorg: libreoffice failing might be a kernel issue.
[10:26] <infinity> apw: There was some talk that those fixes for the fixes for the fixes still didn't fix libreoffice, right?
[10:27] <tsimonq2> infinity: But it's not a gtk+2.0 issue, correct? (that's what triggered the test)
[10:27] <infinity> tsimonq2: Sure, but force-badtest would also be a lie.
[10:27] <infinity> tsimonq2: You can say "this shouldn't hold up gtk" without saying "please ignore the test forever".
[10:27] <tsimonq2> infinity: "this shouldn't hold up gtk" :P
[10:27] <LocutusOfBorg> infinity, yes, I agree, I'm following the Debian bug too
[10:28] <tsimonq2> infinity: Regardless, the point in asking is to make sure that the SRU can migrate properly.
[10:28] <LocutusOfBorg> ok, well, so ignore it only once is the correct request? I agree this shouldn't be forced forever
[10:29] <LocutusOfBorg> I see libreoffice blacklisted on s390x not sure what does it mean
[10:29] <tsimonq2> infinity (cc apw): This isn't just a Zesty issue from what I can tell, it seems to be a Xenial issue as well.
[10:29] <infinity> LocutusOfBorg: Nah, just informing an SRU team member that it's not a gtk regression should be fine.   :P
[10:43] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.3] has been marked as ready
[10:43] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.3] has been marked as ready
[10:43] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.3] has been marked as ready
[10:43] -queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.3] has been marked as ready
[10:43] -queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.3] has been marked as ready
[10:43] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.3] has been marked as ready
[10:43] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.3] has been marked as ready
[10:44] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.3] has been marked as ready
[10:44] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.3] has been marked as ready
[10:45] -queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.3] has been marked as ready
[10:45] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.3] has been marked as ready
[10:45] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.3] has been marked as ready
[10:45] -queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.3] has been marked as ready
[10:45] -queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.3] has been marked as ready
[10:45] -queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.3] has been marked as ready
[10:45] -queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.3] has been marked as ready
[10:49] <sil2100> infinity: GNOME i386 looks good as well, marked as so some minutes ago
[10:49] <infinity> sil2100: Shiny.
[10:49] <sil2100> infinity: anything else needs testing? I don't see anything that's not-touched besides netboot
[10:52] <infinity> sil2100: I think we're getting down to just paperwork and me asking computers to do things that take a very long time.
[10:53] -queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (artful-proposed/universe) [17.10] (no packageset)
[11:03] <sil2100> infinity: sweet, the changes for .3 look ok or should I work some more on those?
[11:04] <infinity> sil2100: I'll look in a bit.
[11:04] <infinity> sil2100: But if it looks kinda like a list of bugs, I'll probably not have complaints.
[11:06] <infinity> sil2100: Looks reasonable to me.
[11:07] <sil2100> infinity: if there's anything I can help, just poke! We'll be going out for lunch in a moment but I'll be back soonish
[11:13] -queuebot:#ubuntu-release- New binary: ganeti [i386] (artful-proposed/universe) [2.15.2-10] (no packageset)
[11:15] -queuebot:#ubuntu-release- New binary: ganeti [ppc64el] (artful-proposed/universe) [2.15.2-10] (no packageset)
[11:16] -queuebot:#ubuntu-release- New binary: ganeti [amd64] (artful-proposed/universe) [2.15.2-10] (no packageset)
[11:22] -queuebot:#ubuntu-release- New binary: ganeti [s390x] (artful-proposed/universe) [2.15.2-10] (no packageset)
[11:24] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.3] has been marked as ready
[11:24] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.3] has been marked as ready
[11:30] <apw> sil2100, do you want these ubuntu-image things in the queue accpted over what is in -proposed ?
[11:57] -queuebot:#ubuntu-release- New binary: ganeti [arm64] (artful-proposed/universe) [2.15.2-10] (no packageset)
[12:19] -queuebot:#ubuntu-release- New: accepted behave [amd64] (artful-proposed) [1.2.5-1ubuntu1]
[12:19] -queuebot:#ubuntu-release- New: accepted ganeti [amd64] (artful-proposed) [2.15.2-10]
[12:19] -queuebot:#ubuntu-release- New: accepted ganeti [i386] (artful-proposed) [2.15.2-10]
[12:19] -queuebot:#ubuntu-release- New: accepted ganeti [s390x] (artful-proposed) [2.15.2-10]
[12:19] -queuebot:#ubuntu-release- New: accepted te923con [arm64] (artful-proposed) [0.6.1-1ubuntu1]
[12:19] -queuebot:#ubuntu-release- New: accepted te923con [i386] (artful-proposed) [0.6.1-1ubuntu1]
[12:19] -queuebot:#ubuntu-release- New: accepted te923con [s390x] (artful-proposed) [0.6.1-1ubuntu1]
[12:19] -queuebot:#ubuntu-release- New: accepted budgie-wallpapers [amd64] (artful-proposed) [17.10]
[12:19] -queuebot:#ubuntu-release- New: accepted ganeti [ppc64el] (artful-proposed) [2.15.2-10]
[12:19] -queuebot:#ubuntu-release- New: accepted te923con [armhf] (artful-proposed) [0.6.1-1ubuntu1]
[12:19] -queuebot:#ubuntu-release- New: accepted ganeti [arm64] (artful-proposed) [2.15.2-10]
[12:19] -queuebot:#ubuntu-release- New: accepted te923con [ppc64el] (artful-proposed) [0.6.1-1ubuntu1]
[12:19] -queuebot:#ubuntu-release- New: accepted te923con [amd64] (artful-proposed) [0.6.1-1ubuntu1]
[13:17] <doko> looking at gcc-7-cross-ports in update_excuses.html: why is the ppc64el build listed as missing
[13:17] <doko> and the cross compilers seem to be installable as well
[13:32] <infinity> doko: The uninstallable stuff might be component mismatches.  Not sure about the ppc64el thing.
[13:33] <doko> ahh, yes, demoting
[13:33] <doko> gcc-7-cross-ports is kept in main because of the need of powerpc on ppc64el
[13:34] <infinity> doko: Erm, the ppc64el thing is because you didn't bump versions.
[13:35] <infinity> Why the second one didn't fail to upload is a mystery I'd rather not think about.
[13:35] <doko> hmm, I removed the binaries before uploading the second one ...
[13:35] <infinity> That would be why it didn't fail to upload.
[13:35] <infinity> Also, ick.
[13:35] <doko> anyway, doing the 7.2 release candidate today
[13:35] <infinity> doko: Binaries (and sources) should never, ever, ever re-use versions in the archive.  Things go nutty.
[13:36] <infinity> Totally an LP bug that it even let that happen.
[13:37] <infinity> cjwatson: ^
[13:40] <cjwatson> I'm pretty surprised that was allowed, certainly.  Please file.
[13:40] <cjwatson> And don't pull that sort of binary-removal stunt again.
[13:40] <infinity> doko: Yes.  Pretty please don't remove a file because it conflicts with another you want with different contents. :P
[13:41] <infinity> doko: Files in the history of an archive must be unique.
[13:42] <cjwatson> I guess it's possible we only explicitly check that for sources.
[13:43] <doko> infinity: ack
[13:45] <infinity> cjwatson: Things fail to upload all the time for that reason.  Or does it maybe only check published binaries, rather than all of history?
[13:45] <cjwatson> infinity: Do you happen to remember an example?
[13:46] <infinity> I suspect doko's own package is an example (though, not sure how far back I'd have to go to find it).
[13:46] <infinity> But yes, we get builds failing to upload due to binary version conflicts (and also version downgrades).
[13:46] <cjwatson> Version conflicts are different.
[13:47] <infinity> Different than... A version conflict?
[13:47] <cjwatson> I'm not saying there are no checks on binary uploads, just that I suspect the same-version-different-contents check is absent.
[13:47] <infinity> We may be saying the same thing, sort of?
[13:48] <infinity> I mean, a build with a version already published will reject.  Unless it's a copy (thus same contents).  But a build with a version that's historically been used but not currently published will, apparently, accept.
[13:48] <infinity> Or, that seems to describe what I've seen.
[13:49] <cjwatson> Does it actually reject, or just crash during publication?
[13:49] <cjwatson> I see plenty of "Version older than that in the archive" rejections in recent history, but nothing that's obviously a version-conflict rejection.
[13:50] <infinity> I think doko's gcc-cross packages have rejected in the past for this same reason.
[13:50] <infinity> Cause they really should encode more version info than they do.
[13:50] <infinity> It's entirely possible this one rejected and he did the removal and then retried the build. :P
[13:51] <cjwatson> Ah, https://launchpad.net/ubuntu/+source/gcc-6-cross-ports/20ubuntu4/+build/12555755 is an example.
[13:52] <infinity> Yup.
[13:53] <cjwatson> Missed it because it's done in lp.soyuz.model.queue:PackageUpload rather than in archiveuploader.
[13:53] <cjwatson> So right, that's basically a last-ditch check against stuff that hasn't been removed.
[13:54] <cjwatson> Might be interesting to see what would break if we just removed the "AND bpph.dateremoved IS NULL" condition from that query.
[13:54] <cjwatson> Possibly a performance disaster, not sure.
[13:56] <cjwatson> So yeah, removal successfully hammered the upload through to the point where it failed later.  And it might have failed even more disastrously depending on how it interacted with https://bugs.launchpad.net/launchpad/+bug/238826 ..
[13:57] <infinity> cjwatson: It's almost certainly failed pretty hard already, because a-f cache.
[13:57] <infinity> (as in, the sums in Packages are probably for the old files)
[13:57] <cjwatson> Quite possibly.
[13:57] <infinity> Because a-f makes the entirely reasonable assumption that archive members are unique. :P
[13:58] <cjwatson> doko: Is this a thing you've done in the past?  Because if so we may need to audit the archive.
[13:59] <doko> cjwatson: no, afaicr. in the past we had failing builds on one or two archs, whith other archs succeeding, and then the version skew for the binaries
[13:59] <doko> for the next upload
[14:00] <doko> the skew goes away with the next gcc-7 upload, and all cross builds succeeding
[14:00] <cjwatson> I don't understand why that would result in version skew.  Wouldn't you bump all the versions in sync?
[14:01] <doko> no, it's looking at the binaries found in the archive
[14:01] <doko> if I hardcode that, then I usually forget to bump the number for a new upload :/
[14:01] <infinity> doko: It really needs to tack on the version of the gcc-cross package as well, so it remains unique per build.
[14:01] <cjwatson> Ah, so retrying -cross-ports with a different base toolchain or something
[14:02] <infinity> doko: As in, the "cross1" at the end could be "cross20ubuntu5" or something for gcc-6-cross-ports_20ubuntu5
[14:02] <doko> infinity: yeah, but then you had a version number like -12ubuntu1cross5ubuntu2 ...
[14:02] <doko> ugly
[14:02] <infinity> doko: Shorten "Ubuntu" to "u" and it's not the worst.
[14:02] <infinity> I mean, they're ugly regardless. :P
[14:03] <infinity> And shorten "cross" to "c" or "x"
[14:03] <infinity> -12ubuntu1x5u2
[14:03] <apw> and it looks like a disk name in solaris
[14:03] <infinity> In Debian, it's be a nice short -12x5
[14:03] <infinity> Hahaha.
[14:11] <sil2100> apw: yes :)
[14:14] <xnox> what is solaris?
[14:14] -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.3] has been marked as ready
[14:14] -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.3] has been marked as ready
[14:21] <doko> the kiosk seed is pulling in qtubuntu. is this expected?
[14:21] <doko> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:23] <jbicha> doko: looks like yes: https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.artful
[14:24] <doko> jbicha: but all the -cpp packages are unmaintained, aren't they?
[14:24] <infinity> I was under the impression pretty much that whole dep tree is unmaintained.
[14:24] <doko> xnox: ^^^
[14:25] <xnox> doko, yes kiosk seed pulling in qtubuntu is expected.
[14:25] <xnox> and alan_g is on the hook to minimise deps.
[14:25] <xnox> (alan_g and co)
[14:26] <xnox> they have requested that in a bug report, mentioned in the seed text.
[14:27] <alan_g> Saviq: FYI ^^
[14:28] <xnox> the graph is nice: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg this may be a useful guide on as to what to drop.
[14:28] <Saviq> we're cutting off at platform-api
[14:28] <xnox> whoop whoop =)
[14:28] <Saviq> as in, we won't depend on that, soon
[14:28] <Saviq> so that graph will look much nicer
[14:28] <xnox> doko, infinity ^
[14:29] <Saviq> the other fruit is content-hub, which we need to cut off in qtubuntu, too, and are already on it
[14:48] <doko> looks like the debian perl team is busy updating everything ...
[14:53] <xnox> doko, helpful. stop the importer?! =)
[15:09] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.3] has been marked as ready
[15:09] -queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.3] has been marked as ready
[15:09] -queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.3] has been marked as ready
[15:09] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.3] has been marked as ready
[15:16] -queuebot:#ubuntu-release- Builds: 39 entries have been added, updated or disabled
[15:35] -queuebot:#ubuntu-release- New binary: fwupd [ppc64el] (artful-proposed/main) [0.9.6-0ubuntu1] (desktop-core)
[15:37] -queuebot:#ubuntu-release- New binary: fwupd [amd64] (artful-proposed/main) [0.9.6-0ubuntu1] (desktop-core)
[15:38] -queuebot:#ubuntu-release- New binary: fwupd [s390x] (artful-proposed/main) [0.9.6-0ubuntu1] (desktop-core)
[15:38] -queuebot:#ubuntu-release- New binary: fwupd [i386] (artful-proposed/main) [0.9.6-0ubuntu1] (desktop-core)
[15:41] -queuebot:#ubuntu-release- New binary: fwupd [arm64] (artful-proposed/main) [0.9.6-0ubuntu1] (desktop-core)
[15:43] -queuebot:#ubuntu-release- New binary: fwupd [armhf] (artful-proposed/main) [0.9.6-0ubuntu1] (desktop-core)
[15:50] -queuebot:#ubuntu-release- New binary: linux [s390x] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
[15:57] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-90.98] (core, kernel)
[15:57] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-30.34] (core, kernel)
[15:57] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-30.34]
[15:58] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-90.98]
[16:00] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.11.0-13.19~16.04.1] (kernel)
[16:00] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-89.112] (core, kernel)
[16:01] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-89.112~14.04.1] (kernel)
[16:01] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-30.34~16.04.1] (kernel)
[16:02] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.11.0-13.19~16.04.1]
[16:02] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-89.112]
[16:02] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-30.34~16.04.1]
[16:02] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-89.112~14.04.1]
[16:17] -queuebot:#ubuntu-release- New binary: linux [ppc64el] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
[17:27] -queuebot:#ubuntu-release- New source: mozjs52 (artful-proposed/primary) [52.2.1-1~git1]
[19:11] <teward> is there a reason https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1595096 has just sat on the sponsoring list for eternity and never been looked at?
[19:11] <teward> in queue as of 3/25/2017
[19:11] <teward> jgrimm: ^ cc
[19:14] <nacc> teward: not especially
[19:14] <nacc> teward: i think the sponsorship queue is a bit behind for server
[19:14] <nacc> i believe i have a pilot session next week
[19:14] <teward> nacc: "behind" I think is an understatement - this is 5 months since last activity... just saying.
[19:15] <teward> (and this is breaking my experimenting with postfix heh)
[19:15] <teward> i'll do a power user hack for now and compile an updated package in a PPA, but...
[19:15] -queuebot:#ubuntu-release- New binary: linux [i386] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
[19:15] <teward> (at least NGINX updates get handled real quickly... oh wait, that's my uploads... nevermind :P)
[19:15] <nacc> teward: feel free to bump in the bug and we should see it in the triage rota
[19:16] <teward> bumped :p
[19:20] <nacc> teward: thanks
[19:20] <nacc> teward: i'm guessing hte debdiff probably needs updating too, but that's ok
[19:33] -queuebot:#ubuntu-release- New binary: linux [arm64] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
[19:35] <teward> nacc: indeed, but I'm happy to do that if needed.
[19:35] <teward> because i want this working :P
[19:35] <nacc> teward: :)
[19:46] <jgrimm> teward, nacc.  as far i know its ready to go, had just been waiting for sponsors to get around to it
[19:46] <nacc> jgrimm: +1 agreed
[19:46] <teward> which is "never" if you don't prod them every so often :P
[19:47] <jgrimm> template including how to test for sponsor so should be easy enough nacc. let me know if you have questions
[19:47] <teward> 5 months is infinite lagtime.
[19:47] <jgrimm> teward, :)
[19:47] <teward> (in the IT world anyways)
[19:47] <nacc> jgrimm: yep, i saw that
[19:47] <teward> jgrimm: I had a habit before I got PPU rights - I always bothered sponsors every week until they uploaded my things, esp. if it's critical.  Now for nginx, I just upload and wait for the SRU teams :P
[20:55] -queuebot:#ubuntu-release- New binary: linux [amd64] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
[21:42] -queuebot:#ubuntu-release- Unapproved: nvme-cli (xenial-proposed/universe) [0.5-1ubuntu0.1 => 0.5-1ubuntu0.2] (no packageset)
[22:12] -queuebot:#ubuntu-release- New binary: linux [armhf] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
[23:10] -queuebot:#ubuntu-release- New binary: git-lfs [ppc64el] (artful-proposed/none) [2.2.1-1] (no packageset)
[23:10] -queuebot:#ubuntu-release- New binary: golang-github-approvals-go-approval-tests [amd64] (artful-proposed/none) [0.0~git20170712.0.c1e747e-1] (no packageset)
[23:10] -queuebot:#ubuntu-release- New binary: golang-github-chzyer-readline [amd64] (artful-proposed/none) [1.4-1] (no packageset)
[23:10] -queuebot:#ubuntu-release- New binary: lua-mode [amd64] (artful-proposed/universe) [20151025-2] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: golang-github-aliyun-aliyun-oss-go-sdk [amd64] (artful-proposed/none) [1.5.0+dfsg1-1] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: golang-github-hashicorp-go-rootcerts [amd64] (artful-proposed/none) [0.0~git20160503.0.6bb64b3-1] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: golang-github-cheekybits-is [amd64] (artful-proposed/none) [0.0~git20150225.0.68e9c06-1] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: git-lfs [amd64] (artful-proposed/none) [2.2.1-1] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: git-lfs [s390x] (artful-proposed/none) [2.2.1-1] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: inflection [amd64] (artful-proposed/none) [0.3.1-1] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: org-mode [amd64] (artful-proposed/universe) [9.0.9+dfsg-3] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: git-lfs [i386] (artful-proposed/none) [2.2.1-1] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: more-itertools [amd64] (artful-proposed/none) [3.2.0-2] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: golang-github-glendc-gopher-json [amd64] (artful-proposed/none) [0.1.0+git20170414.0.dc47430-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: backdoor-factory [amd64] (artful-proposed/none) [3.4.2+dfsg-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: golang-github-gophercloud-gophercloud [amd64] (artful-proposed/none) [0.0~git20170728.0.0118feec-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: golang-github-tdewolff-test [amd64] (artful-proposed/none) [0.0~git20170115.0.a7cf99a-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: ruby-declarative-option [amd64] (artful-proposed/none) [0.1.0-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: golang-github-denverdino-aliyungo [amd64] (artful-proposed/none) [0.0~git20170721.0.80ceb80-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: golang-gopkg-go-playground-validator.v8 [amd64] (artful-proposed/none) [8.18.1-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: golang-github-opentracing-opentracing-go [amd64] (artful-proposed/none) [1.0.2-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: ruby-rash-alt [amd64] (artful-proposed/none) [0.4.3-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: astral [amd64] (artful-proposed/none) [1.4-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: ruby-uber [amd64] (artful-proposed/none) [0.1.0-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: ruby-errbase [amd64] (artful-proposed/none) [0.0.3-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: ruby-test-xml [amd64] (artful-proposed/none) [0.1.8-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: ruby-declarative [amd64] (artful-proposed/universe) [0.0.9-1] (no packageset)
[23:45] -queuebot:#ubuntu-release- New: accepted astral [amd64] (artful-proposed) [1.4-1]
[23:45] -queuebot:#ubuntu-release- New: accepted golang-github-denverdino-aliyungo [amd64] (artful-proposed) [0.0~git20170721.0.80ceb80-1]
[23:45] -queuebot:#ubuntu-release- New: accepted golang-github-tdewolff-test [amd64] (artful-proposed) [0.0~git20170115.0.a7cf99a-1]
[23:45] -queuebot:#ubuntu-release- New: accepted ruby-declarative [amd64] (artful-proposed) [0.0.9-1]
[23:45] -queuebot:#ubuntu-release- New: accepted ruby-rash-alt [amd64] (artful-proposed) [0.4.3-1]
[23:45] -queuebot:#ubuntu-release- New: accepted ruby-uber [amd64] (artful-proposed) [0.1.0-1]
[23:45] -queuebot:#ubuntu-release- New: accepted backdoor-factory [amd64] (artful-proposed) [3.4.2+dfsg-1]
[23:45] -queuebot:#ubuntu-release- New: accepted golang-gopkg-go-playground-validator.v8 [amd64] (artful-proposed) [8.18.1-1]
[23:45] -queuebot:#ubuntu-release- New: accepted ruby-test-xml [amd64] (artful-proposed) [0.1.8-1]
[23:45] -queuebot:#ubuntu-release- New: accepted golang-github-opentracing-opentracing-go [amd64] (artful-proposed) [1.0.2-1]
[23:45] -queuebot:#ubuntu-release- New: accepted ruby-errbase [amd64] (artful-proposed) [0.0.3-1]
[23:46] -queuebot:#ubuntu-release- New: accepted git-lfs [amd64] (artful-proposed) [2.2.1-1]
[23:46] -queuebot:#ubuntu-release- New: accepted git-lfs [ppc64el] (artful-proposed) [2.2.1-1]
[23:46] -queuebot:#ubuntu-release- New: accepted golang-github-aliyun-aliyun-oss-go-sdk [amd64] (artful-proposed) [1.5.0+dfsg1-1]
[23:46] -queuebot:#ubuntu-release- New: accepted golang-github-cheekybits-is [amd64] (artful-proposed) [0.0~git20150225.0.68e9c06-1]
[23:46] -queuebot:#ubuntu-release- New: accepted golang-github-glendc-gopher-json [amd64] (artful-proposed) [0.1.0+git20170414.0.dc47430-1]
[23:46] -queuebot:#ubuntu-release- New: accepted golang-github-hashicorp-go-rootcerts [amd64] (artful-proposed) [0.0~git20160503.0.6bb64b3-1]
[23:46] -queuebot:#ubuntu-release- New: accepted lua-mode [amd64] (artful-proposed) [20151025-2]
[23:46] -queuebot:#ubuntu-release- New: accepted org-mode [amd64] (artful-proposed) [9.0.9+dfsg-3]
[23:46] -queuebot:#ubuntu-release- New: accepted git-lfs [i386] (artful-proposed) [2.2.1-1]
[23:46] -queuebot:#ubuntu-release- New: accepted golang-github-approvals-go-approval-tests [amd64] (artful-proposed) [0.0~git20170712.0.c1e747e-1]
[23:46] -queuebot:#ubuntu-release- New: accepted golang-github-gophercloud-gophercloud [amd64] (artful-proposed) [0.0~git20170728.0.0118feec-1]
[23:46] -queuebot:#ubuntu-release- New: accepted more-itertools [amd64] (artful-proposed) [3.2.0-2]
[23:46] -queuebot:#ubuntu-release- New: accepted git-lfs [s390x] (artful-proposed) [2.2.1-1]
[23:46] -queuebot:#ubuntu-release- New: accepted inflection [amd64] (artful-proposed) [0.3.1-1]
[23:46] -queuebot:#ubuntu-release- New: accepted golang-github-chzyer-readline [amd64] (artful-proposed) [1.4-1]
[23:46] -queuebot:#ubuntu-release- New: accepted ruby-declarative-option [amd64] (artful-proposed) [0.1.0-1]


[05:05] <mup> Bug #1979338 changed: Refresh KVM (Virsh) host returns error "Failed talking to pod: invalid literal for int() with base 10 '-' "  <MAAS:Invalid> <https://launchpad.net/bugs/1979338>
[05:23] <mup> Bug #1979338 opened: Refresh KVM (Virsh) host returns error "Failed talking to pod: invalid literal for int() with base 10 '-' "  <MAAS:Invalid> <https://launchpad.net/bugs/1979338>
[05:26] <mup> Bug #1979338 changed: Refresh KVM (Virsh) host returns error "Failed talking to pod: invalid literal for int() with base 10 '-' "  <MAAS:Invalid> <https://launchpad.net/bugs/1979338>


[14:32] <snap-l> Good morning
[14:41] <brousch> says you
[15:14] <brousch> hm, found a native android python2.7
[15:14] <brousch> botbrew
[15:14] <brousch> like homebrew for android
[15:15] <brousch> d00d, it works
[15:16] <snap-l> nice!
[15:21] <brousch> if it can run pip i may need a tissue
[15:36] <brousch> omg pip is installing virtualenv
[15:41] <brousch> hm, ok, so the "source" command doesn't seem to exist. might have to do without virtualenv
[15:44] <brousch> but, pip works with root permissions
[16:07] <brousch> i pip installed django, and it runs
[16:19] <jrwren> what shell?
[16:19] <jrwren> source is a shell builtin
[16:19] <jrwren> try the . alias.
[16:19] <jrwren> . {venv}/bin/activate
[17:03] <brousch> actually i wonder if it's a problem with the fat32 file system
[17:03] <brousch> i think the symlinks are failing
[17:03] <jrwren> fat32 doesn't have symlinks.
[17:03] <snap-l> brousch: Yeah, not sure how Linux handles links on fat32
[17:04] <snap-l> my gut feeling is "it doesn't"
[17:04] <brousch> i think the internal file system is something else. i'll see if it works there
[17:08] <brousch> different error there
[17:09] <brousch> anyways, pip works fine
[17:11] <brousch> https://bugs.launchpad.net/virtualenv/+bug/442780
[17:13] <rick_h_> brousch: just skip the source activate and just hit the things in bin/ itself
[17:14] <rick_h_> that's what I do with my Makefile stuff in bookie now and I rarely need to activate the venv any more
[17:15] <jrwren> but then your makefile is aware of your venv?  does that scale to other people on your team?
[17:17] <rick_h_> jrwren: well, when you run make install, it sets up the venv in the project dir
[17:17] <rick_h_> so from there on it just references commands in bin/*
[17:17] <rick_h_> heh, my team is me for now, I'll find out I guess if I can get other people involved in bookie
[17:18] <jrwren> oh cool.
[17:20] <brousch> i get permission denied when trying to create a virtualenv. apparently virtualenv links to the system python and then runs it. it is failing at the run
[17:21] <rick_h_> yea
[17:23] <brousch> yeah, won't let me symlink
[17:47] <brousch> hehe, i pinged ian bicking on google+. this should be fun
[18:44] <snap-l> btw: Excel is a crackwhore
[18:44] <snap-l> That is all
[18:45] <rick_h_> hah!
[18:46] <brousch> is that a good thing or a bad thing these days? isn't crack a compliment now?
[18:48] <snap-l> brousch: If you can come up with a complimentary reference for crack whore, please be my guest. ;)
[18:49] <greg-g> aside from the obvious?
[19:24] <brousch> rick_h_: did you see my earlier comments about BotBrew? it lets you have real Vim on your android
[19:26] <rick_h_> brousch: ah, saw the link but didn't see the vim stuff
[19:27] <brousch> one of the many things available
[19:27] <Scott_firebeta> can you run irssi?
[19:29] <brousch> Scott_firebeta: i don't see it, but you can compile your own packages too
[19:33] <brousch> https://github.com/jyio/botbrew#readme
[19:38] <_stink_> greg-g: +1
[19:41] <brousch> hm, no comments or answers on my SO question after 2 hours
[19:51] <greg-g> _stink_: :)
[20:16] <snap-l> If you're all looking for something to get me for Christmas: http://www.youtube.com/watch?v=y6QS-3w0ZQw
[20:18] <snap-l> http://www.youtube.com/watch?v=2KQAtN4XF8o <- This will do as well
[20:47] <brousch> ah ha! the sdcard is mounted with noexec!
[20:47] <brousch> now i get a different error, but it's progress
[23:51] <snap-l> Hello from the back room at CHC
[23:52] <rick_h> woot!
[23:52] <rick_h> howdy CHC folks
[23:52] <rick_h> sorry to be missing
[23:57] <jcastro> too busy drinking
[23:58] <rick_h> woot!
[23:58] <rick_h> jcastro: that was funny with the hangout, I'm like "wtf"
[23:58] <jcastro> rick_h, ok, windows-m
[23:58] <jcastro> have her try that
[23:58] <jcastro> super-m
[23:58] <rick_h> jcastro: yea, sent her the keys
[23:58] <jcastro> you know what I mean, then windows key
[23:58] <jcastro> oh ok, she sorted it then?\
[23:59] <rick_h> guess so, sent her the keys and she asked wtf 'meta/windows' was and once I told her windows key I havne't heard back
[23:59] <jcastro> so haven't heard back as in she fixed it?
[23:59] <jcastro> or haven't heard back as in we're in trouble?
[23:59] <rick_h> haven't heard back in hopefully she fixed it else I'll be fixing it tomorrow :)