[00:02] <bluesabre> ali1234: yeah, if you have indicator-application, the indicator plugin is going to randomly steal or duplicate some app indicators
[00:02] <ali1234> cpufreq isn't showing up anywhere now
[00:03] <bluesabre> shows up in status notifier for me
[00:03] <ali1234> it did in my old session but not in my new one
[00:03] <ali1234> let me try restarting...
[00:06] <ali1234> doesn't work in the old session either now
[00:06] <ali1234> oh wait there it is
[00:06] <ali1234> it might be because the new user isn't in the right groups
[00:08] <Unit193> bluesabre: But that doesn't explain why dropbox shows up fine in indi but not sn-plug!
[00:11] <ali1234> it probably isn't an appindicator
[00:11] <bluesabre> Unit193: I think dropbox used one of the older libind* libraries
[00:12] <ali1234> like indicator-messages
[00:19] <Unit193> bluesabre: Considering no other libs were changed?  I'd presume not.
[00:19] <bluesabre> Unit193: I can't explain it either way :D
[00:26] <ali1234> does dropbox show a text label next to the icon?
[00:27] <Unit193> It is indeed an appindicator.  And no, only hover.
[00:28] <ali1234> i just copied over one of my custom appindicators and it doesnt show up at all
[00:30] <ali1234> hmm i added another sn-plugin and it shows up
[00:30] <ali1234> but with the wrong icon and no text label
[00:49] <ali1234> huh... that wrong icon is probably a bug in my code
[00:59] <Unit193> bluesabre: You ever figure menulibre stuff out?
[01:00] <Unit193> ali1234: I had the same thing, actually.  https://anonscm.debian.org/cgit/debian-edu/pkg-team/veracrypt.git/commit/?id=c5c017eb4aea859694c765a3255222c6920b64f1
[01:00] <ali1234> weird, my bug is the opposite
[01:01] <ali1234> the icon name is correct in the _new call but sn-plugin ignores that and always displays the attention_icon instead, which indicator-application ignores
[01:01] <ali1234> i had a completely wrong icon set in that, but i've never seen it before
[01:03] <bluesabre> Unit193: I did, just waiting for one of the debian-python sponsors to upload
[01:03] <Unit193> bluesabre: If you wanted to screw around with db, just add 'XFCE' in with Budgie in about http://paste.openstack.org/show/701591/
[01:03] <Unit193> Ah nice.
[01:32] <ali1234> Unit193: this may be the dropbox problem: https://bugs.launchpad.net/ubuntu/+source/xfce4-statusnotifier-plugin/+bug/1756627
[01:35] <Unit193> Huh, I start things after all the time.  I guess I could try that.
[01:35] <ali1234> for me it does not work
[01:36] <ali1234> like, at all
[01:37] <ali1234> i'll retest this on a fresh install tomorrow
[01:38] <ali1234> i've tested with the example code, indicator-cpufreq, and classicmenu-indicator
[01:38] <ali1234> none of them appear until theplugin is restarted
[01:38] <ali1234> note that two of those start on startup - in that case they will show up
[01:38] <ali1234> but immediately after installing them, they won't
[01:38] <ali1234> not even if you run them manually
[01:40] <Unit193> Huh, those aren't xfce4-indicator-plugin ones?  Weird.
[01:41] <ali1234> no, they are all appindicators
[01:42] <ali1234> but indicator-plugin might steal them if you have the other appindicator stuff installed
[01:42] <ali1234> but not in this case, they don't show up there either
[01:43] <ali1234> i have to wonder why we are replacing the perfectly working indicator-plugin with sn-plugin which appears to be completely broken along with not supporting the full feature set
[01:45] <Unit193> DB is the only thing I've had issues with, otherwise it's less finicky for me than -application.  Killing sn-plug (it autorespawns) didn't bring DB up.
[02:14] <ali1234> the wrong light/dark variant thing is a bug in indicator-cpufreq
[02:14] <ali1234> it sets a bogus icon theme path, which causes the fallback icons to be used instead of the correct ones
[02:17] <ali1234> not convinced that behaviour is correct either tbh
[02:58] <donofrio> so can I use the devel repo's for normal ubuntu 18.04?
[06:12] <flocculant> ochosi ali1234 - frame is off by default
[08:19] <ochosi> flocculant: yeah, ali was using a non-default session/panel config
[08:20] <flocculant> ochosi: ok - didn't manage to read it well at stupid o'clock then :p
[08:21] <flocculant> anyway - added bugs to bp
[08:52] <ali1234> flocculant: i can't report the bugs against ubiquity because i dont have ubiquity installed
[08:53] <tracker8> hello
[08:54] <tracker8> all idots dead
[08:54] <tracker8> bye
[08:56] <willem> morning all
[08:57] <willem> In my panel there are two network icons at times. I'd like to investigate. Any pointers where to start?
[08:57] <ali1234> check which plugins own each icon
[08:58] <ali1234> since there is currently three plugins that can put icons in the panel
[08:58] <ali1234> and for some reason icons can end up in any of them depending on what you have installed
[08:58] <ali1234> those three plugins are called "notification area", "indicator plugin" and "status notifier plugin"
[08:59] <willem> ali1234, thanks! I'll try and get going with this. I'm a newby, so it'll take some effort.
[09:09] <ali1234> flocculant: ubiquity bugs: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1756650
[09:09] <ali1234> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1756651
[09:09] <ali1234> also put them on the iso tracker
[09:12] <flocculant> ali1234: re the remove media bug - is that hardware or vm?
[09:14] <flocculant> and the welcome page issue - not sure what you're expecting to see - I slight difference when choosing between Try or Install
[09:21] <ali1234> flocculant: hardware
[09:24] <ali1234> and with the welcome page i expect to see the name and version of the software i am installing at a bare minimum
[09:25] <ali1234> and a message saying "select language"
[09:26] <willem> ali1234, flocculant I thought I'd try and reproduce the "no welcome" issue with the daily in a VM.
[09:26] <flocculant> ali1234: just checking here - but you mean the ubiquity slideshow and not our one once installation's started?
[09:26] <willem> In this case I did not get the graphical install screen, but the "old" version with a simple "dos" screen
[09:26] <ali1234> flocculant: i mean this page: https://launchpadlibrarian.net/361087303/IMG_20180318_084240.jpg
[09:27] <ali1234> it's literally the first thing you see when you boot directly to the installer
[09:27] <flocculant> ali1234: ack
[09:27] <ali1234> or the first thing you see if you click the "install" icon on the live desktop
[09:27] <ali1234> that big empty space with nothing in it
[09:27] <ali1234> it should say something
[09:28] <flocculant> ali1234: just let me boot live
[09:28] <ali1234> like "you are about to install xubuntu 18.04. select the language for installer and click continue. or click here for the release notes"
[09:29] <flocculant> it definitely says release note - assuming network capability - just booting vm with no network
[09:29] <ali1234> what does?
[09:29] <ali1234> you mean live desktop mode?
[09:30] <willem> ali1234, I restarted the VM and now I'm in the graphical installer. It's telling me that I'm about to try or install Xubuntu.
[09:31] <flocculant> from the try/install dialogue - try gets desktop, install from there gets a language selector with quit/back/continue - no release note link > no network on vm
[09:31] <flocculant> with network same as that plus release note
[09:32] <ali1234> right
[09:32] <ali1234> that's not enough
[09:32] <ali1234> it's not nearly enough
[09:32] <flocculant> but nothing about what you're installing - and it's the same for a long time
[09:32] <ali1234> i haven't installed ubuntu since 16.04
[09:32] <flocculant> 16.04.4 doesn't show it
[09:33] <flocculant> not got 16.04.0 atm - but will grab it shortly and see what that does
[09:33] <ali1234> actually i might not have installed it since 14.04. i think i upgraded
[09:33] <flocculant> the try/install dialogue tells you you're installing Xubuntu
[09:33] <ali1234> i dont see that
[09:33] <ali1234> i am using a UEFI laptop
[09:34] <ali1234> it displays a grub menu with tiny writing
[09:34] <flocculant> aah
[09:34] <ali1234> so the first thing you actually see is that empty dialog
[09:34] <flocculant> you don't see this even on uefi? https://i.imgur.com/eiAPgzm.png
[09:34] <ali1234> right
[09:34] <ali1234> hang on i'll do a screenshot of what you see instead
[09:35] <flocculant> ali1234: I know what the uefi grub screen looks like - I hit that accidentally now and again
[09:36] <flocculant> brb - booting usb
[09:36] <ali1234> okay
[09:36] <ali1234> well, the try/install screen is exactly what i mean
[09:36] <ali1234> it has that short piece of text at the bottom that explains what the installer is
[09:38] <flocculant> uefi didn't want to boot
[09:38] <flocculant> did you get screenshot?
[09:40] <ali1234> https://photos.app.goo.gl/M5oEm4n5fcMpy5vX2
[09:40] <ali1234> if you select the second option on that menu, the other screenshot is the very first interactive dialog you will see
[09:41] <ali1234> the first one drops you directly at the live desktop
[09:41] <flocculant> ok - so from install from grub you see the lp image you gave - did the laptop have network at that point?
[09:42] <ali1234> no
[09:42] <ali1234> wireless config is later in the installer
[09:42] <flocculant> ok - so that's why the release note bit is missing from that screen
[09:42] <ali1234> okay
[09:43] <ali1234> it should still say what version of ubuntu it is going to install
[09:43] <flocculant> but as for the dearth of information - it's been as sparse as that for a fair while
[09:43] <flocculant> just grabbing the 16.04.0 to see what that's like
[09:43] <ali1234> the same afaict
[09:43] <flocculant> that will be the same for any flavour
[09:44] <flocculant> you do get at least the flavour name on non-uefi on the try/install dialogue
[09:44] <ali1234> yes
[09:44] <flocculant> I don't disagree with you here btw ;)
[09:44] <ali1234> here's a really old installer https://www.dedoimedo.com/images/computers_new_1/ubuntu-install-begin-install.jpg
[09:45] <flocculant> ack - yea not looked like that for a long time
[09:45] <ali1234> here's 16.04 http://pinet.org.uk/assets/images/image3.jpeg
[09:47] <flocculant> 16.04 for non-uefi gets the try/install dialogue - install goes straight to the preparing page, installl from desktop and I see the welcome page - dearth type one
[09:49] <flocculant> trying to do a uefi vm and I get an issue
[09:51] <flocculant> for this we're in the lap of Canonical - pretty sure that this would be the same for anyone
[09:51] <ali1234> sure
[09:52] <flocculant> not sure whether it'll get looked at this side of release either
[09:53] <flocculant> so re the remove media issue - I did a hardware test at beta and I saw it, later today I'll have another go and see what happens
[09:54] <flocculant> I know on vm's it can be an issue
[09:54] <flocculant> back a bit later
[11:42] <flocculant> bluesabre: am I going nuttier? I swear I read something by you about x-pulse plugin allowing greater than 100% volume?
[11:42] <bluesabre> flocculant: only when using the slider in the menu
[12:05] <flocculant> bluesabre: ok - was thrown there :) mouse scolls down from +100% but won't go past it
[14:49] <ochosi> bluesabre, flocculant actually i've been pondering on how to reflect that in notifyd...
[14:49] <ochosi> currently it just goes to 100
[14:50] <bluesabre> ochosi: there's a patch available for pa-plug to allow the 100+% with keyboard keys
[14:50] <bluesabre> but I think I want to tweak it further so holding it down goes only to 100%, then you have to let go and do it again to go beyond
[16:01] <flocculant> ochosi: right - that'd be nice - not sure how it would work though
[16:02] <flocculant> bluesabre: and while that patch would be good - the tweak would be useful, having had a system in the past where it just went on and on
[16:36] <willem> Still testing 18.04: Is this something I should report somewhere? http://i.imgur.com/p44nbl3.png
[16:37] <willem> Update-manager and "software" can't seem to agree whether or not there are any updates.
[16:46] <flocculant> probably related to the fact that software never sees everything in the repository - tbh given things I've reported against gnome software have been ignored I'd not waste my time
[16:47] <flocculant> I wish we didn't even seed the thing
[17:08] <knome> bluesabre, ochosi: do you plan updating panel for 16.04? i suppose not because 18.04 is so close and there isn't an awful long time for 16.04 EOL, but... you might want to tell the person on -devel mailing list
[17:24] <flocculant> 13 months is more than a third of the time it's supported for ;)
[17:24] <knome> sure
[17:24] <knome> i don't think a redraw bug is critical though
[17:24] <knome> it can be annoying but...
[17:25] <flocculant> no - wasn't saying that - just that I don't totally agree with 'awful mong time' :p
[17:25] <flocculant> sigh
[17:25] <knome> haha
[17:25] <knome> a year passes like nothing nowadays :/
[17:25] <flocculant> ha ha ha
[17:25] <flocculant> yea - I find that for sure
[17:26] <flocculant> right - bbl
[17:48] <knome> not important enough to get all of you pinged, but team: i just updated the voting GUI with an additional link to the original sized image so you can easily preview and download that for evaluation purposes
[17:49] <knome> (other than that, continue voting)
[18:08] <willem> flocculant, thanks. I'll leave it as it is then.
[18:27] <ochosi> bluesabre: yeah, i was more wondering how to catch exactly those cases in notifyd and also how to visualize it
[18:27] <ochosi> without breaking all themes
[21:15] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-settings 4.12.3 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-settings-4-12-3-released-tp50837.html (by Sean Davis-6)
[21:16] <knome> oh yes, that sean davis-6 guy
[21:28] <bluesabre> strange guy
[21:28] <bluesabre> works too much
[21:37] <knome> all bugs aren't fixed yet
[21:37] <knome> so clearly too little :P
[21:38] <bluesabre> :D
[22:04] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-settings 4.13.2 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-settings-4-13-2-released-tp50839.html (by Sean Davis-6)


[07:37] <homebrewcider> hi there, I have mythbuntu installed in a 2 pc setup frontend for 1 room, backend in another. I have tuned the tuners in the backend, however when I start mythtv frontend I think it wants the backend to be on the same machine. I am lost, can someone help please
[13:21] <homebrewcider> hi, how can I delete ONE capture card, and not the other?
[14:30] <zcutlip> There seem to be a variety of ways to disable update manager from popping up over top the MythTV interface.  Is there an official/semi-official/recommended way?
[14:34] <zcutlip> homebrewcider: I don't think there's a way in the GUI to delete only one tuner/capture card.  I'm not sure why.  This can probably be accomplished front he MySQL command line if your'e up for that, though.


[00:39] <tsimonq2> RAOF: Can I also get lubuntu-meta and lubuntu-default-settings released at the same time?
[00:40] <tsimonq2> (apologies if you're already doing that)
[00:40] <RAOF> You can indeed.
[00:41] <tsimonq2> Thanks.
[00:51] <slangasek> LocutusOfBorg: ah, a re-test of libpoe-component-client-dns-perl against release pocket on ppc64el showed the same SIGUNUSED failure, so hinting that through
[00:53] <slangasek> this leaves only the ppc64el/valgrind issue, which we may want to ignore
[01:17] <slangasek> LocutusOfBorg: I've satisfied myself that this doesn't point to perl itself being broken (the valgrind suppressions generated match the failure output, so something else is going on, and I'll override the failure to not block perl indefinitely.
[01:25] <tsimonq2> slangasek: Hello, would you be able to let spinx migrate given that mailman3-core is the only rdep autopkgtest failure and it isn't relevant to the new Sphinx (and is an issue in Debian as well)?
[01:27] <slangasek> tsimonq2: "happens in Debian" is not a reason to ignore an autopkgtest regression. "happens in the release pocket" would be.
[01:27] <tsimonq2> slangasek: Note that my point is not to let mailman3-core in, I'm still working to fix that, but to let sphinx in because that's the only blocker and it's irrelevant.
[01:28] <slangasek> tsimonq2: and the autopkgtest history shows that it's rather busted for reasons unrelated to sphinx, yeah; marking badtest
[01:29] <slangasek> (done)
[01:29] <tsimonq2> Thanks.
[01:31] <tsimonq2> What I don't get though, is how to solve this problem. It seems to me that it needs postgresql set up but that fails due to it installing it in a non-interactive way.
[01:32] <tsimonq2> Or... dbconfig-common?
[01:34] <tsimonq2> I don't know, suggestions welcome.
[06:59] -queuebot:#ubuntu-release- Unapproved: qemu (artful-proposed/main) [1:2.10+dfsg-0ubuntu3 => 1:2.10+dfsg-0ubuntu3.1] (ubuntu-server, virt)
[08:15] <ginggs> would someone please update vorlon's hints file 'force-badtest cacti/1.1.18+ds1-1/armhf cacti/1.1.27+ds1-2' -> 'force-badtest cacti/1.1.18+ds1-1/armhf cacti/1.1.27+ds1-3/armhf'  and note the /armhf
[08:23] <apw> ginggs, looking
[08:33] <apw> ginggs, done
[08:39] <ginggs> apw: ta!
[08:41] -queuebot:#ubuntu-release- Unapproved: ubuntu-themes (artful-proposed/main) [16.10+17.10.20171012.1-0ubuntu1 => 16.10+17.10.20171115-0ubuntu1] (core) (sync)
[09:13] <LocutusOfBorg> slangasek, sorry, but I don't think our internal kde* discussions should go in release :) I don't want to spam  here uselessly. e.g. splitting work or rebuilds, is something I don't think should belong to this chan :)
[09:14] <LocutusOfBorg> thanks slangasek :)
[09:14] <LocutusOfBorg> for perl!
[09:14] <LocutusOfBorg> lets see if perl is candidate now
[09:24]  * LocutusOfBorg triggered an evil plan to make perl candidate, by increasing the three missing autopkgtests priority
[09:28] <Laney> LocutusOfBorg: by queueing the same thing multiple times?
[09:29] <LocutusOfBorg> yep, I abused a 3-4 minutes of the infrastructure time :/
[09:29] <LocutusOfBorg> this is why it was evil
[09:29] <Laney> no
[09:30] <Laney> *you* queued multiple runs of the same thing
[09:31] <LocutusOfBorg> do you have an explanation about how this can be possible?
[09:31] <LocutusOfBorg> you are right, I use vipe to check the output... I don't understand
[09:32] <Laney> dunno, run it again and see what you see in the output
[09:32]  * LocutusOfBorg checks
[09:33] <LocutusOfBorg> just to make you aware, this is the command I run
[09:33] <LocutusOfBorg> ./retry-autopkgtest-regressions --all-proposed --state RUNNING --max-age 20 | grep perl | vipe | xargs -rn1 -P10 wget --load-cookies ~/.cache/autopkgt
[09:33] <LocutusOfBorg> est.cookie -O-
[09:34] <LocutusOfBorg> it takes eons to load on my little tethering phone that command, this is why I'm mostly sure I didn't run it twice :)
[09:34] <LocutusOfBorg> http://paste.ubuntu.com/25966448/
[09:34] <LocutusOfBorg> result seems legit
[09:34] <mwhudson> so i've uploaded a bunch of go packages that stop building shared library packages
[09:35] <mwhudson> do i need to get an AA to remove the shared library packages from bionic RELEASE before they will migrate?
[09:35] <LocutusOfBorg> I will blame myself, maybe when I closed the window some shortcuts made copy-paste I don't like nano :(
[09:37] <tjaalton> apw: I've updated https://bugs.launchpad.net/ubuntu/+source/xorg-server-hwe-16.04/+bug/1716203 with regression potential in the packages
[09:38] <tjaalton> still need mesa in -proposed soon, also the point-release for artful so that radeon vulkan driver would work again (after dropping mir vulkan patch)
[09:38] <tjaalton> infinity: ^
[09:38] <Laney> don't think all-proposed was needed either
[09:38]  * Laney just tried with libclass-mixinfactory-perl
[09:39] <Laney> anyway, thx for making it go in (assuming it does)
[09:40] <LocutusOfBorg> Laney, I also think it wasn't needed, but some of the failures were related to hard-coded 5.26.0 ABI
[09:41] <LocutusOfBorg> I had to do a 5 packages transition
[09:41]  * LocutusOfBorg has to switch network, fingers crossed!
[11:05] <LocutusOfBorg> autopkgtest for astroml/0.3-6: amd64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Ignored failure, s390x: Ignored failure
[11:05] <LocutusOfBorg> can we please kick astroml out from release? it is RC buggy in Debian, out of Buster, and needs anyway a sourceful upload
[11:06] <LocutusOfBorg> nobody seems to be caring of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877161 so far
[11:31] <LocutusOfBorg> hello, question: python-scipy loves to fail on i386 from time to time, due to precision issues (new glibc, new gcc and so on)
[11:32] <LocutusOfBorg> what we do is "relax" the precision bits on i386, test pass and we live happy
[11:32] <LocutusOfBorg> what about instead forcing it bad? i386 is even going away, and we are never fixing the underlying precision issue, but rather hiding it
[11:32] <LocutusOfBorg> (and upstream confirms this is not an issue BTW)
[11:33] <LocutusOfBorg> ginggs, ^^ you did that many times, please confirm if you agree :)
[11:47] <Laney> mitya57: hey, any idea about pyqt5 apparently breaking qscintilla2 (tests) on ppc64el/s390x?
[11:47] <Laney> at least I think it's pyqt5
[11:58] -queuebot:#ubuntu-release- New binary: ldns [s390x] (bionic-proposed/main) [1.7.0-3ubuntu1] (ubuntu-server)
[11:59] -queuebot:#ubuntu-release- New binary: ldns [ppc64el] (bionic-proposed/main) [1.7.0-3ubuntu1] (ubuntu-server)
[12:00] -queuebot:#ubuntu-release- New binary: ldns [i386] (bionic-proposed/main) [1.7.0-3ubuntu1] (ubuntu-server)
[12:01] -queuebot:#ubuntu-release- New binary: ldns [amd64] (bionic-proposed/main) [1.7.0-3ubuntu1] (ubuntu-server)
[12:01] <Mirv> if anyone is interested in looking at logs, my earlier ldns sponsoring upload simply disappeared - no e-mail, not in any queues. rm *.upload and dput again and here we go.
[12:01] <Mirv> no need to look for me, but if you're curious what happened
[12:05]  * Laney is poking a bit at the big transition
[12:05] <Laney> konqueror needs looking at too - acheronuk, are you aware of that one? (guessing so)
[12:06] <acheronuk> Laney: yes, but not sure what the issue is, and won't have a chance today
[12:08] -queuebot:#ubuntu-release- New binary: ldns [arm64] (bionic-proposed/main) [1.7.0-3ubuntu1] (ubuntu-server)
[12:12] <ginggs> LocutusOfBorg: I did that once, but it has been done in the past, yes.
[12:13] <ginggs> debian bug #758022
[12:17] -queuebot:#ubuntu-release- New binary: ldns [armhf] (bionic-proposed/main) [1.7.0-3ubuntu1] (ubuntu-server)
[12:17] <ginggs> LocutusOfBorg: forcing it bad will make i386 no worse than armhf, ppc64el and s390x where the tests have always failed
[12:55] -queuebot:#ubuntu-release- New binary: ruby2.5 [s390x] (bionic-proposed/universe) [2.5.0~preview1-1ubuntu2] (no packageset)
[12:57] -queuebot:#ubuntu-release- New binary: ruby2.5 [ppc64el] (bionic-proposed/universe) [2.5.0~preview1-1ubuntu2] (no packageset)
[13:00] -queuebot:#ubuntu-release- New binary: ruby2.5 [i386] (bionic-proposed/universe) [2.5.0~preview1-1ubuntu2] (no packageset)
[13:01] -queuebot:#ubuntu-release- New binary: ruby2.5 [amd64] (bionic-proposed/universe) [2.5.0~preview1-1ubuntu2] (no packageset)
[13:18] -queuebot:#ubuntu-release- New binary: ruby2.5 [armhf] (bionic-proposed/universe) [2.5.0~preview1-1ubuntu2] (no packageset)
[13:31] -queuebot:#ubuntu-release- New binary: ruby2.5 [arm64] (bionic-proposed/universe) [2.5.0~preview1-1ubuntu2] (no packageset)
[13:34] -queuebot:#ubuntu-release- New: accepted ldns [amd64] (bionic-proposed) [1.7.0-3ubuntu1]
[13:34] -queuebot:#ubuntu-release- New: accepted ldns [armhf] (bionic-proposed) [1.7.0-3ubuntu1]
[13:35] -queuebot:#ubuntu-release- New: accepted ldns [ppc64el] (bionic-proposed) [1.7.0-3ubuntu1]
[13:35] -queuebot:#ubuntu-release- New: accepted ruby2.5 [amd64] (bionic-proposed) [2.5.0~preview1-1ubuntu2]
[13:35] -queuebot:#ubuntu-release- New: accepted ruby2.5 [armhf] (bionic-proposed) [2.5.0~preview1-1ubuntu2]
[13:35] -queuebot:#ubuntu-release- New: accepted ruby2.5 [ppc64el] (bionic-proposed) [2.5.0~preview1-1ubuntu2]
[13:35] -queuebot:#ubuntu-release- New: accepted ldns [arm64] (bionic-proposed) [1.7.0-3ubuntu1]
[13:35] -queuebot:#ubuntu-release- New: accepted ldns [s390x] (bionic-proposed) [1.7.0-3ubuntu1]
[13:35] -queuebot:#ubuntu-release- New: accepted ruby2.5 [i386] (bionic-proposed) [2.5.0~preview1-1ubuntu2]
[13:35] -queuebot:#ubuntu-release- New: accepted ldns [i386] (bionic-proposed) [1.7.0-3ubuntu1]
[13:35] -queuebot:#ubuntu-release- New: accepted ruby2.5 [s390x] (bionic-proposed) [2.5.0~preview1-1ubuntu2]
[13:35] -queuebot:#ubuntu-release- New: accepted ruby2.5 [arm64] (bionic-proposed) [2.5.0~preview1-1ubuntu2]
[14:29] <LocutusOfBorg> please ignore python-scipy/i386 and python-bayespy that seems to be regressed in release (looking at ppc64el)
[14:31] <LocutusOfBorg> and kick astroml out of testing (see above)
[14:31] <LocutusOfBorg> Laney, ^^ this should unblock a bunch of stuff, and perl is now ready to migrate
[14:33] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (artful-proposed) [1:20171114.1-0ubuntu<IP_ADDRESS>]
[14:33] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (zesty-proposed) [1:20171114.1-0ubuntu<IP_ADDRESS>]
[14:33] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20171114.1-0ubuntu<IP_ADDRESS>]
[14:33] <LocutusOfBorg> ffmpeg seems a sad stuff
[14:34] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20171114.1-0ubuntu<IP_ADDRESS>]
[14:38] -queuebot:#ubuntu-release- Unapproved: mailman (trusty-proposed/main) [1:2.1.16-2ubuntu0.2 => 1:2.1.16-2ubuntu0.3] (ubuntu-server)
[15:01] -queuebot:#ubuntu-release- Unapproved: pulseaudio (xenial-proposed/main) [1:8.0-0ubuntu3.4 => 1:8.0-0ubuntu3.7] (core)
[15:04] <doko> astroml removed, node-mapnik demoted
[15:06] -queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.7]
[15:19]  * sil2100 re-ran the sphinxcontrib-websupport tests for sqlalchemy as those are no longer failing
[15:29] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.28.5 => 2.29.3] (desktop-core, ubuntu-server)
[15:30] -queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.28.5+17.10 => 2.29.3+17.10] (desktop-core, ubuntu-server)
[15:31] -queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.28.5+17.04 => 2.29.3+17.04] (desktop-core, ubuntu-server)
[15:31] -queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.28.5~14.04 => 2.29.3~14.04] (no packageset)
[15:32] -queuebot:#ubuntu-release- Unapproved: libvirt-python (xenial-proposed/main) [1.3.1-1ubuntu1 => 1.3.1-1ubuntu1.1] (ubuntu-server)
[16:38] <Trevinho> rbasak: hey could you please approve this https://bileto.ubuntu.com/#/ticket/3002 in the artful queue?
[16:39] <rbasak> Trevinho: I'm pretty much EOD now, sorry.
[16:39] <Trevinho> rbasak: ah, ok sorry... no worries
[17:10] -queuebot:#ubuntu-release- New binary: libstorj [ppc64el] (bionic-proposed/none) [1.0.2-1] (no packageset)
[17:10] -queuebot:#ubuntu-release- New binary: superlu-dist [s390x] (bionic-proposed/none) [5.2.2+dfsg1-1] (no packageset)
[17:10] -queuebot:#ubuntu-release- New binary: superlu-dist [ppc64el] (bionic-proposed/none) [5.2.2+dfsg1-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: libstorj [arm64] (bionic-proposed/none) [1.0.2-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: libstorj [s390x] (bionic-proposed/none) [1.0.2-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: superlu-dist [arm64] (bionic-proposed/none) [5.2.2+dfsg1-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: libstorj [armhf] (bionic-proposed/none) [1.0.2-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: superlu-dist [armhf] (bionic-proposed/none) [5.2.2+dfsg1-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: python-xlrd [amd64] (bionic-proposed/universe) [1.1.0-1] (no packageset)
[17:13] -queuebot:#ubuntu-release- New binary: minetest-mod-character-creator [amd64] (bionic-proposed/none) [1.0-1] (no packageset)
[17:13] <sil2100> Trevinho: I can look now
[17:14] <Trevinho> sil2100: nice, thanks! :)
[17:14] -queuebot:#ubuntu-release- New binary: minetest-mod-quartz [amd64] (bionic-proposed/none) [1.0.0-1] (no packageset)
[17:14] -queuebot:#ubuntu-release- New binary: yapf [amd64] (bionic-proposed/universe) [0.19.0-1] (no packageset)
[17:14] -queuebot:#ubuntu-release- New binary: recon-ng [amd64] (bionic-proposed/none) [4.9.2-1] (no packageset)
[17:14] <sil2100> That's a lot of bugs linked!
[17:14] <sil2100> ;)
[17:15] -queuebot:#ubuntu-release- New binary: superlu-dist [i386] (bionic-proposed/none) [5.2.2+dfsg1-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: tryton-modules-account-eu [amd64] (bionic-proposed/none) [4.6.0-1] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: normaliz [amd64] (bionic-proposed/universe) [3.4.1+ds-1] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: superlu-dist [amd64] (bionic-proposed/none) [5.2.2+dfsg1-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: libbarcode-datamatrix-perl [amd64] (bionic-proposed/none) [0.09-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: normaliz [i386] (bionic-proposed/universe) [3.4.1+ds-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: libstorj [amd64] (bionic-proposed/none) [1.0.2-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: libstorj [i386] (bionic-proposed/none) [1.0.2-1] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: normaliz [armhf] (bionic-proposed/universe) [3.4.1+ds-1] (no packageset)
[17:34] <sil2100> Trevinho: I suppose I should discard the previous upload? ;)
[17:34] <sil2100> Trevinho: since I see one from 21 hours ago and one from 8 hours ago
[17:34] <Trevinho> sil2100: mh, which one? there was another one?
[17:34] <Trevinho> mhmh... I thought it failed
[17:34] <Trevinho> as I was requested to rebuild it by bileto
[17:34] <sil2100> Yeah, from a deleted PPA, so I guess it's invalid
[17:34] <Trevinho> but yeah, just get the last one
[17:35] <Trevinho> they should be 1:1
[17:35] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-themes [sync] (artful-proposed) [16.10+17.10.20171113-0ubuntu1]
[17:37] <sil2100> Trevinho: ok, approved
[17:37] <Trevinho> thanjs
[17:37] <Trevinho> ks*
[17:37] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (artful-proposed) [16.10+17.10.20171115-0ubuntu1]
[18:19] -queuebot:#ubuntu-release- New: accepted minetest-mod-character-creator [amd64] (bionic-proposed) [1.0-1]
[18:19] -queuebot:#ubuntu-release- New: accepted python-xlrd [amd64] (bionic-proposed) [1.1.0-1]
[18:19] -queuebot:#ubuntu-release- New: accepted yapf [amd64] (bionic-proposed) [0.19.0-1]
[18:19] -queuebot:#ubuntu-release- New: accepted minetest-mod-quartz [amd64] (bionic-proposed) [1.0.0-1]
[18:20] -queuebot:#ubuntu-release- New: accepted recon-ng [amd64] (bionic-proposed) [4.9.2-1]
[18:20] -queuebot:#ubuntu-release- New: accepted libbarcode-datamatrix-perl [amd64] (bionic-proposed) [0.09-1]
[18:20] -queuebot:#ubuntu-release- New: accepted tryton-modules-account-eu [amd64] (bionic-proposed) [4.6.0-1]
[18:21] -queuebot:#ubuntu-release- New: accepted libstorj [amd64] (bionic-proposed) [1.0.2-1]
[18:21] -queuebot:#ubuntu-release- New: accepted libstorj [armhf] (bionic-proposed) [1.0.2-1]
[18:21] -queuebot:#ubuntu-release- New: accepted libstorj [ppc64el] (bionic-proposed) [1.0.2-1]
[18:21] -queuebot:#ubuntu-release- New: accepted superlu-dist [amd64] (bionic-proposed) [5.2.2+dfsg1-1]
[18:21] -queuebot:#ubuntu-release- New: accepted superlu-dist [armhf] (bionic-proposed) [5.2.2+dfsg1-1]
[18:21] -queuebot:#ubuntu-release- New: accepted superlu-dist [ppc64el] (bionic-proposed) [5.2.2+dfsg1-1]
[18:21] -queuebot:#ubuntu-release- New: accepted libstorj [arm64] (bionic-proposed) [1.0.2-1]
[18:21] -queuebot:#ubuntu-release- New: accepted libstorj [s390x] (bionic-proposed) [1.0.2-1]
[18:21] -queuebot:#ubuntu-release- New: accepted superlu-dist [i386] (bionic-proposed) [5.2.2+dfsg1-1]
[18:21] -queuebot:#ubuntu-release- New: accepted libstorj [i386] (bionic-proposed) [1.0.2-1]
[18:21] -queuebot:#ubuntu-release- New: accepted superlu-dist [s390x] (bionic-proposed) [5.2.2+dfsg1-1]
[18:21] -queuebot:#ubuntu-release- New: accepted superlu-dist [arm64] (bionic-proposed) [5.2.2+dfsg1-1]
[19:27] -queuebot:#ubuntu-release- New binary: trilinos [ppc64el] (bionic-proposed/universe) [12.12.1-1] (no packageset)
[19:40] -queuebot:#ubuntu-release- New binary: trilinos [s390x] (bionic-proposed/universe) [12.12.1-1] (no packageset)
[21:33] <sergiusens> slangasek hey, wrt adt; if I add a package to Suggests, would that trigger reverse depends tests?
[21:33] <slangasek> sergiusens: no
[21:34] <slangasek> sergiusens: suggests not being installed by default
[21:34] <sergiusens> slangasek so it would need to be Recommends at the minimum or not even?
[21:34] <sergiusens> btw, is #ubuntu-release the right channel to talk about adt?
[21:35] <slangasek> sergiusens: I believe we trigger autopkgtests on reverse-recommends, but I was trying to check the code to see and it's eluding me.  Yes, this is the right channel, that's managed by the release team
[21:37] <slangasek> sergiusens: ok, I don't see anything in the code that does this for reverse-recommends either.  However, what you could do is add this to the package as a *test* dependency (debian/tests/control) and then it would
[21:38] <slangasek> of course, I'm asserting this is done but now I can't find where that exists in the source either
[21:38] <slangasek> basically, I am useless in following the britney code; but at least you're in the right channel
[21:39] <slangasek> sergiusens: and https://bugs.launchpad.net/britney/+bug/1593148
[21:42] <sergiusens> slangasek ok, we have snapd in debian/tests/control but I don't see it ever got triggered http://autopkgtest.ubuntu.com/packages/snapd/xenial/amd64
[21:42] <slangasek> hmm
[21:42] <slangasek> then I guess I'm lying about that too, even though there's no open bug on britney about it
[21:47] <sergiusens> slangasek heh, lack of bug might be no one asked for it, I guess this is your implicit way of telling me to log a bug :-)
[21:50] -queuebot:#ubuntu-release- New binary: trilinos [amd64] (bionic-proposed/universe) [12.12.1-1] (no packageset)
[21:51] <slangasek> sergiusens: might be useful if you did ;)  but I did seriously think we had already landed this, so <shrug>
[21:57] <sergiusens> There, LP: #1732545
[22:33] <juliank> sergiusens: slangasek: What infinity (I think) told me about debian/tests/control deps is that they should work, but the tooling to build the .dsc needs to be recent enough to add Testsuite-Triggers to the dsc file.
[22:33] <juliank> should work for triggering purposes, that is
[22:34] <slangasek> ah
[22:34] <juliank> I think that's 16.10 and newer
[22:34] <juliank> So if you build the dsc in xenial, you're lost
[22:35] <slangasek> indeed
[22:35] <juliank> https://bugs.launchpad.net/britney/+bug/1491145
[22:35] <slangasek> sergiusens: I confirm that if I grab latest snapcraft from LP, and rebuild the source package, I get a Testsuite-Triggers line
[22:35] <slangasek> so don't upload from 16.04, that's aaaancient
[23:03] -queuebot:#ubuntu-release- New binary: libbarcode-datamatrix-png-perl [amd64] (bionic-proposed/universe) [0.04-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: xerces-c [ppc64el] (bionic-proposed/universe) [3.2.0+debian-2] (kubuntu)
[23:14] -queuebot:#ubuntu-release- New binary: revolt [amd64] (bionic-proposed/universe) [0.0+git20170627.3f5112b-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: xerces-c [s390x] (bionic-proposed/universe) [3.2.0+debian-2] (kubuntu)
[23:17] -queuebot:#ubuntu-release- New binary: xerces-c [amd64] (bionic-proposed/universe) [3.2.0+debian-2] (kubuntu)
[23:19] -queuebot:#ubuntu-release- New binary: xerces-c [arm64] (bionic-proposed/universe) [3.2.0+debian-2] (kubuntu)
[23:24] -queuebot:#ubuntu-release- New binary: xerces-c [i386] (bionic-proposed/universe) [3.2.0+debian-2] (kubuntu)
[23:27] -queuebot:#ubuntu-release- New binary: xerces-c [armhf] (bionic-proposed/universe) [3.2.0+debian-2] (kubuntu)
[23:51] <sergiusens> slangasek it is an LTS though; I think I started doing that because during one series that was in dev I couldn't go to an earlier series with the dsc that was built in a future release
[23:51] <sergiusens> but point taken, if it works, I'll do that


[00:31] <Logan_> Does a package that previously FTBFSed in Ubuntu require an FFE, if the package wasn't previously published in Raring due to the FTBFS? The new Debian version builds properly, and there is a sync request for it.
[00:33] <micahg> Logan_: If it's got new features, yes
[00:33] <Logan_> Well, I mean, the binary wasn't published in Raring previously due to the FTBFS.
[00:33] <micahg> Logan_: which package?
[00:33] <Logan_> And the only fix in Debian is for the FTBFS, so now the binary would be published.
[00:34] <Logan_> https://bugs.launchpad.net/ubuntu/+source/libio-async-loop-glib-perl/+bug/1154211
[00:34] <Logan_> I tested the Debian version in my amd64 pbuilder, and it didn't FTBFS.
[00:35] <micahg> ah, it's grandfathered into the release pocket, please sync to raring + SRU to quantal if it works
[00:36] <Logan_> So no FFE is required?
[00:36] <micahg> no, it's just fixing something broke ATM
[00:36] <Logan_> kk
[00:36] <micahg> generally binary new requires FFe, but that's when you're adding/restructuring
[00:37]  * micahg is trying in a 32 bit chroot for kicks
[00:37] <micahg> Logan_: do you have 32 bit chroots?
[00:38] <Logan_> Just amd64 pbuilder.
[00:38] <Logan_> Tends to be a good indicator, though.
[00:38] <micahg> yeah, catches most things
[00:38] <Logan_> If it's a complex package, I usually push it to my PPA to see if it works on i386, etc.
[00:38] <micahg> was fine in 32 bit raring FWIW
[00:38] <Logan_> synced
[00:39] <micahg> so, if you feel like SRUing, that would be great
[00:40] <micahg> hrm, seems like the build  chroots are stale, it's taking over a minute on i386 just to update the chroot
[00:42] <Logan_> I don't think I should SRU, as I don't have a quantal pbuilder
[00:43] <micahg> seems to build fine there (I don't have -updates enabled in my chroot though)
[00:44] <micahg> Logan_: I'd be happy to upload if you'll do the paperwork :)
[00:44] <Logan_> oh lord :P
[00:47] <Logan_> I actually have to be AFK for a bit, so I'll probably deal with it later or tomorrow, unless you want to handle the paperwork ;)
[00:50] <micahg> Logan_: nah, I'm about to run off myself
[00:56] <xnox> Logan_: there will be about 150 more uploads of no code change, just email change from the same maintainer. Watch out, we generally don't merge if there are no code changes.
[07:19] <dholbach> good morning
[07:20] <ESphynx> 'morning :)
[13:31] <mdeslaur> ScottK: think you could pull the trigger on LP: #1154581 please?
[13:32]  * ScottK looks
[13:35] <ScottK> mdeslaur: Uploaded.
[13:35] <mdeslaur> ScottK: awesome, thanks!
[13:39] <ScottK> mdeslaur: It got rejected.  Sent you mail.
[13:41] <mdeslaur> ScottK: oh, how odd...ok, let me upload, one sec
[13:41] <ScottK> Thanks.  Just give me a ping when it's done.
[13:47] <mdeslaur> ScottK: uploaded
[13:48]  * ScottK looks.
[13:48] <ScottK> mdeslaur: Accepted.
[13:48] <mdeslaur> ScottK: thanks
[13:49] <ScottK> You're welcome.
[20:19] <ESphynx> good morning ;)
[21:37] <evck> Hi, I'm interested in packaging something, and I don't believe it's in Universe. It's the gcc-arm-none-eabi toolchain (https://answers.launchpad.net/gcc-arm-embedded). I'm not sure if it should be part of the gcc-defaults-armel-cross package, which includes the toolchain for Linux (gcc-arm-linux-gnueabi) targets, or a new package. Any advice?
[21:41] <ScottK> infinity: ^^^ You might know ...
[21:41] <Laney> or hrw
[21:43] <infinity> evck: It could potentially be built from the current cross packages, yes.  Patches welcome.
[21:45] <evck> infinity: So this would be a patch to the gcc-defaults-armel-cross package that builds gcc-arm-none-eabi in addition to gcc-arm-linux-gnueabi?
[21:46] <infinity> evck: That would seem like a sane way to go, if gcc-arm-none can be built from our current GCC sources.
[21:47] <infinity> evck: Alternately, you could do another source package that just builds gcc-arm-none (again, pulling in gcc-4.7-source, ideally), but if it needs a bootstrap to get there, you may end up duplicating a lot of what the other cross source does.
[21:48]  * infinity isn't particularly familiar with how to build the -none- targets, as he doesn't do any bare-metal/embedded work.
[21:48] <evck> infinity: Ok, I have a bit to learn about the packaging process, but I'll take a look into it.
[21:49] <infinity> evck: Well, a good first step isn't packaging-related at all, but confirming that you can actually build gcc-arm-none-eabi from the gcc-4.7-source sources.
[21:50] <infinity> evck: ie: if this requires an patching from a source other than upstream GCC or the Linaro branch, we'd need to sort that out.
[21:50] <infinity> s/an/any/
[21:50] <infinity> evck: If it's just a matter of passing some configure flags and bundling up the results, it's likely fairly trivial to bolt than on to the current cross builds as another pass.
[21:50]  * infinity hand waves enough to appear to be flailing.


[14:42] <asido> is bzr a distributed scm?
[14:44] <Peng> yes
[14:48] <fullermd> (depending on where you stand on the scm-vs-vcs semantic argument, anyway)
[14:49] <Peng> there's a semantic argument?
[14:49] <fullermd> Hey!  Stop poking, and put down that stick!   :p
[14:50] <Peng> Should I put the petrol back, too?
[14:50] <fullermd> There are people for whom the terms mean very different things, and boy will they get steamed when they ask a scm question and you try and give a vcs answer...
[14:50] <Peng> I did not know.
[14:50] <Peng> I always use "VCS".
[14:52] <fullermd> Aegis tends more toward the scm side, for examples (at least in most uses of the terms distinctively.  There's not even universal agreement among the nutcases as to what flavor the nuts should have ;)


[15:12] <Bluefoxicy> well.
[15:12] <Bluefoxicy> update-manager -c -d doesn't work
[15:12] <Bluefoxicy> do-release-upgrade -d does.


[00:31] <slaine> hey folks
[00:31] <slaine> anyone about at this late hour ?
[00:32] <tdr112> yo
[00:33] <slaine> I should really be going to bed, but i've a problem with my mythbuntu install and thought I'd ask a question here.
[00:34] <slaine> I want to boot up off the live cd image and chroot into the hdd install and run update-manager from there to see if I can get my box updated and working
[00:34] <slaine> I mounted the the partition, and bind monted /proc /sys, /dev etc. into the chroot
[00:34] <slaine> but I was getting errors displaying to the xserver
[00:34] <slaine> what am I missing
[00:37] <tdr112> not sure on that one
[00:37] <slaine> ah, it's too late to sort it now, I'll have another go tomorrow
[00:37] <slaine> night
[00:37] <tdr112> heading to bed myself too , night
[08:57] <daxroc> Morning
[09:21] <Belserusk> Can someone explain these 2 options? http://i.imgur.com/hCffn.gif
[09:23] <czajkowski> Belserusk: do you want them ro run before you check what they are
[09:23] <czajkowski> or do you wnat to check them and then deccide what is best
[09:24] <Belserusk> Hi czajkowski. Do you refer to running file such as .sh and .bin files?
[09:25] <czajkowski> yes
[09:26] <Belserusk> czajkowski, So for opening normal .txt files; it is irrelevant as to which option I choose?
[09:28] <czajkowski> yes
[09:28] <tdr112_> airurando: do you need a pc for your talk tonight
[09:29] <airurando> Hi tdr112: Nad I'll bring my laptop.  I'll definately need help setting it up though.
[09:30] <tdr112> no prob
[09:30] <Belserusk> Thank you czajkowski.
[09:30]  * airurando is still busily working on the talk but definately getting there
[10:07] <Belserusk> Is there a alternate way to open the Nautilus Preferences Window (http://i.imgur.com/hCffn.gif)? I cannot open it via Edit -> Preferences (the option is not there).
[10:10] <cduffin> Try pressing alt-e and then press n
[10:38] <tdr112> i got the gohead to give out ubuntu cds next week atthat event
[10:38] <Belserusk> cduffin, I can access the Edit menu in Nautilus. The preferences option is not there though.
[10:38] <czajkowski> tdr112: which event
[10:39] <tdr112> the-business-value-of-open-source-software he aloso asked if i want to do a tog table at it
[10:41] <czajkowski> sweet
[10:41] <czajkowski> dave rocks
[10:43] <tdr112> he does
[10:44] <czajkowski> he uses Ubuntu at home as well
[10:44] <czajkowski> or did
[10:45] <tdr112> he was very quick getting back to me
[10:46] <czajkowski> yes he is good like that
[10:46] <czajkowski> with some stuff
[14:22]  * ebel has just ordered a HTC Desire from emobile
[14:34] <cduffin> ebel, would you not wait for the Desire HD?
[14:36] <davem> ebel: good choice, I <3 mine
[14:36] <ebel> cduffin: i saw that one, but it'll be expensive for the mo
[14:36] <ebel> also I've waited ages for one :P
[17:06] <czajkowski> tdr112: Cds are now sent
[17:12] <tdr112> cool , how long do that take
[17:13] <czajkowski> could be there tomorrow or friday
[17:13] <tdr112> ok let hope friday , i will be home then
[17:14] <czajkowski> okioe dokie
[19:17] <Belserusk> Do text files ever need to be executable?Is it possible to keep gridlines with a background color in OpenOffice Spreadsheets? http://i.imgur.com/W1cgA.gif
[19:17] <Belserusk> Is it possible to keep gridlines with a background color in OpenOffice Spreadsheets? http://i.imgur.com/W1cgA.gif


[00:14] <jam> hi poolie
[00:14] <jam> turns out the EINTR bug was very shallow
[00:15] <poolie> hi jam, i saw your mail, and i'm happy to hear that
[00:15] <poolie> did you talk to aaron at all?
[00:17] <jelmer> maxb: merged, thanks.
[00:17] <jam> poolie: I haven't yet. For some reason I got hives last night, and couldn't sleep for the itchiness, so I ended up starting a bit late
[00:18] <jam> I think it was an allergic reaction to something, but I have no idea what
[00:18] <jam> I didn't eat anything different, etc
[00:19] <jam> I did write up most of the decisions I've taken
[00:19] <jam> so I'm pretty close to getting feedback time
[00:20] <mgz> poolie: have you seen <http://babune.ladeuil.net:24842/job/selftest-freebsd/183/> ?
[00:21] <mgz> it may well not be anything to do with your change,
[00:22] <mgz> I've seen that sort of failure on a bunch of different cases when poking things
[00:23] <mgz> right, bed for me.
[00:59] <eydaimon> If I do bzr revert -r -11  is there some easy way to get what revno I've reverted to? I tried bzr revno --tree but didn't work
[01:01] <fullermd> No, revert doesn't change the revno of anything, it just edits files.  It's not really any different from `bzr diff -r-11 | patch -R`.
[01:03] <poolie> jam that's great
[01:04] <poolie> mgz no i hadn't, thanks for pointing it out
[01:07] <poolie> mgz, that's interesting it didn't fail on ubuntu
[01:07] <poolie> the scope replacer thing ought to be platform-independent
[01:12] <jam> poolie: would it be a python 2.7 thing?
[01:12] <poolie> maybe
[01:13] <jam> I believe mgz is known for random python versions :)
[01:30] <poolie> hi spivvo
[01:36] <spiv> Hi poolie
[01:37] <poolie> hey there, how are you?
[01:53] <spiv> Pretty good.  Mary's got a new laptop, new enough to be giving her mild grief with video driver issues :/
[01:53] <poolie> oh, what kidn?
[01:54] <spiv> A 13" Dell Vostro
[02:05] <poolie> spiv, actually, would you mind investigating the scopereplacer?
[02:05] <poolie> it may have been my landing that broke it but i don't think it's especially related to anything i know
[02:05] <poolie> http://babune.ladeuil.net:24842/job/selftest-freebsd/183/testReport/junit/bzrlib.tests.blackbox.test_branch/TestBranchStacked/test_branch_stacked_from_smart_server/
[02:11] <poolie> actually nm
[02:13] <spiv> Heh.
[02:13] <poolie> >> Greetings To You,
[02:13] <poolie> On behalf of the OBAMA'S FOUNDATION and UNITED NATIONS,
[02:13] <poolie> we wish to notify you as a beneficiary of $900,000.00 USD in compensation of
[02:13] <poolie> scam victims.
[02:13] <poolie> mm i bet
[02:15] <lifeless> rotfl
[02:37] <mtaylor> hey all - I know fuckall about fedora - is there a "more sensible" way to get recent bzr on fedora12?
[02:37] <lifeless> 'debtakeover'
[02:38] <mtaylor> hehe
[02:38] <lifeless> there's a fedora maintainer
[02:38] <lifeless> why do you ask?
[02:38] <mtaylor> lifeless: and if I remember correctly, this is a known bug that's fixed in 2.2, right: http://hudson.drizzle.org/view/Drizzle-build/job/drizzle-build-drizzleslap/593/console?
[02:38] <mtaylor> lifeless: well, because I've got a fedora box with 2.0.5 on it, and I believe I'm suffering from a bug fixed by upgrading...
[02:38] <lifeless> mtaylor: that looks like a fs fail to me
[02:39] <mtaylor> lifeless: there's 112G available on the box...
[02:39] <lifeless> what fs
[02:39] <mtaylor> ext4
[02:39] <lifeless> when did it last crash/power down unexpectedly
[02:40] <mtaylor> oh! recently apparently
[02:40] <mtaylor> poo
[02:40] <mtaylor> lifeless: so my solution here is kill repo and re-pull, yes? or can I just kill that file?
[02:40] <lifeless> uhm
[02:40]  * lifeless hands you over to a bzr person
[02:40] <lifeless> spiv: ^
[02:40] <mtaylor> lifeless: I think you qualifiy still as a bzr person even if that's not your job title ;)
[02:43] <lifeless> its more that
[02:43] <lifeless>  - the answer is complex
[02:44] <lifeless>  - you need to dig a bit to get the actual answer on a case by case basis
[02:44] <lifeless>  - we should make that more automated
[02:51] <spiv> Sorry, my net connection dropped out, so I missed the start of the conversation.  Which file is damaged?
[02:51] <spiv> (Then, apparently unrelated, my wireless router needed to be restarted too...)
[02:51] <lifeless> 13:38 < mtaylor> lifeless: and if I remember correctly, this is a known bug that's fixed in 2.2, right: http://hudson.drizzle.org/view/Drizzle-build/job/drizzle-build-drizzleslap/593/console?
[02:53] <spiv> mtaylor: just deleting the file won't help; bzr will still expect that file to exist.  Simplest fix is to delete and recreate that repo, yes.
[03:03] <glyph> so, I am running this command here
[03:03] <glyph> $ bzr dpush
[03:03] <glyph> Using saved location: svn+ssh://svn.twistedmatrix.com/svn/Twisted/branches/strports-endpoints-4473
[03:03] <glyph>   8817kB    38kB/s | pushing revisions:generating file id map 0/1
[03:03] <glyph> why have I dpushed almost 10M of data for a couple of tiny diffs?  (you can see them at twistedmatrix.com/trac/timeline, they are not big)
[03:06] <lifeless> the 10M includes local disk IO rewriting your history.
[03:36] <jbowtie> Is there an easy way to query for all the documentation bugs in Launchpad?  I can't remember how to do that.
[03:37] <poolie> jbowtie, all the bzr doc bugs, or all altogether?
[03:37] <poolie> the easiest way is to click 'doc' in the tag cloud
[03:38] <poolie> jbowtie: which will take you to https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=doc
[03:38] <jbowtie> I meant the bzr doc bugs, those are the ones I want to work on.
[03:38] <poolie> that would be excellent
[03:38] <jbowtie> poolie: Thanks for that, will hopefully send through a bunch of patches the next few days.
[03:39] <jbowtie> poolie: Just remember that when I apply for Ubuntu Developer status.
[03:39] <jbowtie> :)
[03:41] <jbowtie> It's a shame that all the Canonical positions require you to be in the American or European timezones, I'd apply for job so I could work on Bazaar/Launchpad full time.
[03:44] <spiv> jbowtie: http://webapps.ubuntu.com/employment/canonical_BSE/ (in /topic) doesn't require those timezones AFAIK
[03:45] <wgrant> Lots of positions don't.
[03:46] <jbowtie> spiv: You're right, I hadn't seen that one!  Looks like I will be applying when I get home tonight.
[03:47] <jbowtie> wgrant: I suppose so, but every time I see one it has the timezone requirement attached.
[03:48] <poolie> jbowtie: definitely apply
[03:50] <jbowtie> poolie: Oh, I will. Though I suspect you just want to make sure I actually write those documentation patches.  :P
[03:50] <poolie> it will help :)
[03:50] <poolie> i'm reading cvs now as it happens but i don't expect the gate will close for another week or so
[04:03] <vila> poolie: just passing around, don't bang your head too much on the scopereplacer thing, I've seen it a few times, it has always been transient
[04:03] <poolie> oh, hi
[04:03] <poolie> how strange
[04:04] <vila> poolie: often triggered for smart server test so it may be related to some thread ordering differences in turn triggering different import ordering
[04:04] <vila> not worth the effort until it happens too often
[04:08] <poolie> :/
[04:08] <poolie> ok, thanks
[04:18] <vila> poolie: last occurrence was http://babune.ladeuil.net:24842/job/selftest-freebsd/98/testReport/junit/bzrlib.tests.blackbox.test_branch/TestBranchStacked/test_branch_stacked_from_smart_server/
[04:18] <vila> jun 14
[04:19] <vila> run #184 just succeeded, transient again
[04:19]  * vila back to bed
[04:53] <glyph> lifeless: I guess I can rebase first, then dpush?
[04:56] <glyph> Hmm.
[04:56] <glyph> Is there a way to construct bzr+ssh URLs to be $HOME-relative?
[04:56] <glyph> like, I can 'scp foo bar:' and it'll just drop 'foo' into my home directory on bar
[04:58] <spiv> glyph: yes
[04:58] <spiv> glyph: bzr+ssh://host/~/foo
[04:59] <spiv> (requires bzr 2.1 or newer on the server)
[05:01] <poolie> maybe we should just add $host:
[05:04] <spiv> And make trailing slashes significant? ;)
[05:09] <poolie> oh like rsync? :)
[05:11] <mwhudson> hnnnnnnnnngh
[05:11] <glyph> spiv: hey good idea!
[05:11] <glyph> whoops typo
[05:11] <glyph> what I meant was
[05:11] <glyph> "spiv: die in a fire"
[05:11] <mwhudson> the only way i ever get rsync command lines right is if they're in my shell history
[05:11] <glyph> Thanks a lot though!  I will be using "~" a lot now! :)
[05:11] <poolie> :)
[05:12] <glyph> mwhudson: how do you get the rsync command lines you typoed out of your shell history
[05:12] <mwhudson> glyph: it's a mystery
[05:12] <mwhudson> well, actually trial and error i guess
[05:14] <poolie> it is actually a bit logical
[05:14] <poolie> "a" means "the thing a", and "a/" is "everything inside a"
[05:15] <poolie> that's what ayn rand was talking about
[05:15] <poolie> 'a is a and a/ is not a'
[05:15] <mwhudson> haha
[05:17] <glyph> poolie: as a source it makes sense to me.  the problem is when you put it on the destination
[05:17] <glyph> 'sync a with remote:a' and 'sync everything in a with remote:a'
[05:17] <glyph> like... what does that mean?
[05:17] <poolie> it makes no difference to the destination
[05:17] <poolie> rsync a remote:b
[05:18] <poolie> and you will end up with remote:b/a/...
[05:18] <poolie> rsync a/ remote:b and you'll end up with remote:b/... containing what was in a
[05:18] <poolie> the fact that it looks like it might do something does make it confusing of course
[05:34] <lifeless> glyph: it will still do the same work
[05:34] <lifeless> glyph: the point is that the 8M doesn't represent 'network IO'
[05:35] <lifeless> it represents 'IO'
[05:37] <spiv> lifeless: I didn't think we included local IO in the transport activity reporting
[05:37] <spiv> lifeless: a quick grep suggests I'm right...
[05:37] <lifeless> I was moderately sure we did
[05:37] <lifeless> if we don't its arguably a bug (NFS etc)
[06:33] <poolie> we don't include localtransport io
[06:34] <poolie> i don't know what bzr-svn may be doing for its own io
[06:34] <poolie> lifeless: the reasoning is that for the common base case of branching from lp to localhost, it would naively double the data transferred and the rate
[06:34] <poolie> obviously you can account for stuff to make that even out but maybe yagni
[06:41] <glyph> https://bugs.launchpad.net/bzr-mac-installers/+bug/621446
[06:42] <glyph> Can somebody poke the responsible parties there?  the 2.2.0 mac installer on bazaar.canonical.com still has 1.0.4dev.
[06:43] <poolie> glyph: can you send a mail? i don't see them online atm
[06:44] <glyph> Send a mail to whom?  Do you mean put a comment on the bug?
[06:45] <poolie> hm, so i thought that 1.0.4dev would have this fixed
[06:45]  * poolie looks
[06:45] <poolie> but there is now a 1.0.4 final
[06:46] <glyph> Mmmm... it may have been due to the old buggy repository.  Let me try again.
[06:47] <glyph> Nope, reconfirmed outside of the shared repo.  Very, very definitely affects the 1.0.4dev in the current bzr mac installer.
[06:58] <glyph> poolie: thanks
[07:06] <poolie> and 1.0.4 works?
[07:06] <poolie> does 'bzr plugins -v' confirm you're using the plugin from the installer?
[07:30] <zaas[1]> i have a question about branches and git and it's differences, who could possibly help me?
[07:36] <fullermd> Probably a number of people, but only after you ask the question   :>
[07:39] <zaas[1]> ok :) I am trying to decide between Git and Bzr and i favor git a little bit because of it's branch support. However, i work with 2 windows developers and have avarage repositories < 30Mb of php & images
[07:39] <zaas[1]> i find bazaar far more clearly
[07:40] <zaas[1]> but i fear that local branching might be a breaking drawback
[07:40] <zaas[1]> am i right to think this or is this not something that will likely bother me? Git and bzr both seem to do their basics well
[07:41] <zaas[1]> but git evangelists love their index, cheap branching and the tree-eating monster
[07:41] <zaas[1]> and i am confused what to pick
[07:41] <zaas[1]> (not to much text i hope?) :)
[07:43] <fullermd> Well...   those are pretty broad points.  Hard to give a specific answer, since there's no real specific question...
[07:43] <fullermd> Certainly the branch representations are rather different, so they have different advantages and drawbacks.
[07:44] <fullermd> And one drawback of the bzr way is that some minor setup is required to share history among local branches, and rather more setup and ongoing care to share a single working tree among them git-style.
[07:44] <zaas[1]> ah, can you name a bazaar advantages? I know git's: 1 tree and easy push
[07:44] <fullermd> Contrarily, an advantage is that it's way easier and less hackish to have working trees of multiple branches at once with shared history.
[07:45] <fullermd> And it's also somewhat easier and more obvious to push only a particular branch around.
[07:45] <zaas[1]> in my case branches will normally be about bugfixes or small features that need to be merges later on
[07:46] <fullermd> Me, I find that multiple WT's on the different branches make a lot of things a lot easier.  It sounds like you're doing web stuff, and it's handy to be able to have a browser tab on one branch, and another on another branch, at the same time, rather than having to switch back and forth one at a time.
[07:47] <fullermd> I don't think there's always a clearcut winner on which method is better, even in some specific cases; certainly in general it's all over the place.
[07:48] <fullermd> I would lay good odds that bzr grows a native and robust variant of git-style before git grows a native and robust variant of bzr-style.
[07:48] <fullermd> Though AFAIK neither is right around the corner, so that's more of a longer-term thing.
[07:50] <zaas[1]> this is very true. bzr to git is much better then the other way around. also i am fearing the windows developers (2) will not like the git-hassle
[07:51] <zaas> oops
[07:51] <zaas> @fullermd but you love bzr over git i assume?
[07:52] <fullermd> Oh, yes.  That's why I'm here   :)
[07:52] <zaas> i guess for simple vcs is does not really matter and bzr seems the safer choice
[07:53] <zaas> why did you go for bzr?
[07:53] <fullermd> Oh, mostly for dumb and superficial reasons.  But I stayed because I found better reasons.
[07:54] <fullermd> There are things git has that I wish bzr did (and that multiple-branches-in-one-tree thing is a big one).
[07:54] <fullermd> But, I think bzr can grow those capabilities without changing or compromising any of the advantages of the way it currently does things.
[07:54] <fullermd> And I don't think git can do the complement; it would be a much bigger change in their model of things to support side-by-side branches and WT's with shared history.
[07:56] <fullermd> I also particularly like bzr's exploitation of merge asymmetry.  I've seen git-using projects go to a lot of trouble to try and avoid situations that that makes a non-issue.
[07:56] <vila> hi all !
[07:56] <zaas> haha, my initial choice for git was it's hardcore status and the tree-eating monster on their homepage... but i find it hard to justify my choices now with bzr having API support and git does indeed seem to remain git
[07:57] <zaas> it was made for large speed-needing many devvers projects like linux
[07:58] <zaas> hi vila
[07:59] <fullermd> Sure, I expect there will always be performance/resource-usage advantages you can point at for git.  How much they matter in a relative or absolute sense, probably less clear.  And certainly for small projects, I don't think it matters what you pick at this point perf-wise.
[11:22] <bialix> ~~~
[11:28] <vila> bialix: hi ! You're on the beach looking at waves ~~~ ?
[11:29] <bialix> bonjour vila!
[11:29] <bialix> not on the beach unfortunately
[12:28] <poolie> hello vila, bialix
[12:28] <poolie> won't be here for long
[12:30] <vila> poolie: yeah, *you* are on your way to the beach ;)
[12:30] <vila> oh my, already 13:30, time for lunch
[14:23] <bialix> vila: ping
[14:23] <vila> bialix: pong
[14:23] <bialix> do you by any chance know what's the difference between wt format 5 and 6?
[14:24] <bialix> 1.14 format creates wt5 and 2a creates wt6
[14:26] <vila> bialix: let me check, in the meant time, why do you care ?
[14:26] <bialix> I have format1 plugin to avoid 2a as default; wanna update it to 1.14
[14:27] <vila> bialix: from the docstrings, wt6 supprot views
[14:27] <bialix> ah
[14:27] <bialix> ok, thank you
[14:27] <vila> wt5 support content filtering
[14:28] <bialix> ok
[14:28] <vila> bialix: by the way, you still need this plugin ? poolie didn't add a config option for it ?
[14:29] <bialix> I dunno. I have several machines with bzr 1.18 .. 2.1.2 on them, so I'd better safe than sorry
[14:29] <bialix> still can't upgrade to 2.2 because of problems with bzr.exe and bundled pyqt
[14:29] <bialix> waiting for 2.2.1
[14:30] <vila> right, so I'm supposed to release that tomorrow ;)
[14:30] <jml> I'm using workingtree.list_files to go through files in a checkout
[14:30] <bialix> vi-la! vi-la! vi-la!
[14:30] <jml> I'd like to inspect the contents of these files
[14:31] <jml> should I just use normal Python facilities to open the file or is there some more efficient bzr-like way?
[14:32] <bialix> there is method to get the content regardless of workingtree/revisiontree
[14:32] <bialix> also this method supposedly should normalize the file if content filters defined, I guess
[14:33] <vila> jml: there is get_file_text that you can use with the file_id IIRC + what bialix said
[14:34] <vila> jml: so it won't be especially more efficient, but easier for you to code I presume
[14:35] <james_w> using the bzr APIs makes it easier to support things like acting against the tip revision of a remote branch, if that would ever be useful to you
[14:38] <bialix> vila: as I understand you will pair with poolie on release tomorrow morning your time? I will hope to see that tomorrow, as fan
[14:41] <vila> bialix: yeah, that's the plan, I will now go prepare my branches and notes to be ready ;)
[14:41] <jml> thanks guys :)
[14:43] <mgz> I have a vision of vila bearing bundles of sticks.
[14:43] <mgz> And possibly marching on a castle.
[14:44] <vila> ...with a big black tower ?
[14:46] <bialix> ... while poolie sneaks with the ring?
[14:46] <mgz> ehhehe.
[14:46] <vila> my preciouuuus ! That's where it was !
[14:46] <bialix> :-D
[16:02] <knittl> am i understanding a testament correctly? it only signs the current tree (or of any given revision) but not its history?
[16:03] <mgz> I believe so, you can find more from jam I think on the mailing list.
[16:04] <jam> knittl: correct
[16:04] <knittl> ok, thanks
[16:06] <mgz> yup, under the topic "security", dated 2009-11-05
[16:06] <knittl> can you paste a link? :)
[16:06] <mgz> I'm using gmail search, google is a bit crap about indexing the https list archives
[16:06] <mgz> so.. one sec
[16:07] <mgz> https://lists.ubuntu.com/archives/bazaar/2009q4/064053.html
[16:07] <knittl> great, thanks a lot
[16:10] <GaryvdM> Hi all
[16:10] <mgz> hey gary.
[16:31] <bialix> Heya GaryvdM !
[16:31] <GaryvdM> Hi bialix
[16:31] <bialix> GaryvdM: have you asked jam about PyQt
[16:31] <bialix> ?
[16:31] <bialix> PyQt downgrade for 2.2.1
[16:31] <GaryvdM> No - Thanks for the reminder
[16:32] <mgz> also, for 2.2.1, should look at the manifest thing
[16:32] <mgz> probably just want to put the dll in a subfolder and add magic xml.
[16:33] <GaryvdM> jam: We would revert to an older version of pyqt. Please could you install it on the ec2 machine.
[16:33]  * GaryvdM goes to find the bug an download url.
[16:35] <mgz> I've got several old versions locally, which do you want?
[16:36] <bialix> GaryvdM: http://bialix.com/python/PyQt-Py2.6-gpl-4.5.2-1.exe + http://bialix.com/python/PyQt-Py2.6-gpl-4.5.2-1.exe.asc
[16:36] <bialix> mgz: right, manifest
[16:36] <GaryvdM> Ah - thats it :-)
[16:37] <bialix> I haven't tested it locally yet for simple application. should test tonight
[16:37] <GaryvdM> and bug 632501
[16:38] <mgz> http://www.no-ack.org/2010/09/complete-guide-to-py2exe-for-pygtk.html <- perhaps a little interesting
[16:38] <bialix> btw, Gary, I'm a bit worried about this one: https://bugs.launchpad.net/bugs/640082
[16:39] <GaryvdM> bialix: Are you able to reproduce that. I wonder if bzrw.exe is causing that?
[16:40] <mgz> that sounds like a good theory gary.
[16:40] <bialix> Gary, no, I did not try
[16:40] <bialix> why?
[16:40] <bialix> mgz, GaryvdM : ^
[16:40] <mgz> the standard streams don't point anywhere with WinMain rather than main
[16:41] <bialix> it seems like the bug from Gordon is not involved bzrw.exe
[16:42] <bialix> mgz: I'm sure we should invoke the subprocesses as bzr.exe
[16:42]  * bialix is checking
[16:42] <mgz> yeah, could be something else.
[16:43] <bialix> mgz: yep, we're forcing bzr.exe even if initial GUI invoked with bzrw.exe
[16:44] <bialix> I did it long ago when I first time started to play with bzrw.exe idea
[16:47] <GaryvdM> bialix: I just tested. The bug happens with bzrw qpull, but not bzr qpull
[16:47] <bialix> bam
[16:47] <bialix> bad
[16:47] <GaryvdM> I have an idea to fix this.
[16:48] <bialix> yes?
[16:48] <GaryvdM> Let me try do a installer build without tbzr (thats where I got stuck...)
[16:49] <bialix> this is just silly: http://lists.sourcegear.com/pipermail/veracity-users/2010-September/000033.html
[16:49] <GaryvdM> Rather than blackhole the std(out/err), just leave them
[16:50] <bialix> GaryvdM: I don't follow
[16:51] <Glenjamin> bialix: what's veracity?
[16:51] <bialix> Glenjamin: new DVCS
[16:51] <Glenjamin> ah yes, thats what the world needs.
[16:51] <bialix> is it sarcasm?
[16:52] <Glenjamin> yes
[16:52] <Glenjamin> also their google-fu sucks
[16:52] <bialix> ok
[16:53] <mgz> didn't they have a non-d vcs already?
[16:53] <bialix> my point not about veracity, but about claim that fast 'hg verify' is what user want to run often
[16:53] <mgz> and yeah, that post is silly, but says something about the different projects
[16:53] <bialix> mgz: yes, replacement for some silly vcs by m$
[16:53] <GaryvdM> mgz: Yes - it was called Vault. I used it for a while
[16:53] <Glenjamin> i think it was more that the poster cares about the results, and if his users wont ever run it then that VCS is ruled out as an option
[16:55]  * bialix is trying to read the article mgz gave about py2exe, black page background kills his eyes
[16:55] <MTecknology> Any idea what's up with this?  Unable to copy ownership from '/home/S6B5B28EB.s' to '/home/S6B5B28EB.s/.bazaar': IOError: [Errno 1] Operation not permitted: '/home/S6B5B28EB.s/.bazaar'.
[16:55] <mgz> turn off author style then bialix :)
[16:56] <bialix> mgz: how
[16:56] <GaryvdM> bialix: In Firefox: View > Page Style > No Style
[16:56] <mgz> ...depends on your browser?
[16:56] <MTecknology> hrm.. I just clobbered permissions and it's working now ;)
[16:56] <bialix> mgz: chrome
[16:57] <bialix> copy-pasting to OOo may help...
[16:58] <mgz> er... chrome doesn't seem to make it easy.
[16:58] <mgz> bialix, the last section talks a bit about manifests, doesn't sound completely correct to me, but might be a starting point.
[16:58] <bialix> ack
[16:59] <GaryvdM> Hmm veracity is free (Apache License).
[17:01] <bialix> mgz: IIRC manifest should be in the same directory as exe
[17:01] <bialix> crazy
[17:03] <mgz> it's changed at least twice since the last time I needed to actually ship any compiled code, so I really have no idea
[17:12] <Glenjamin> So there's only two things veracity does that current tools dont it seems, cross platform C and repo user accounts
[17:13] <bialix> ,gz: http://py2exe.org/index.cgi/Tutorial section 5.2.1
[17:13] <bialix> mgz: http://py2exe.org/index.cgi/Tutorial section 5.2.1
[17:13] <maxb> Python is written in cross platform C.... :-)
[17:13] <Glenjamin> their words: "We love Python too, but C is a lowest common denominator that can be ported or integrated everywhere we need to go."
[17:14] <bialix> mgz: or we should add to installer redistributable installer
[17:14] <Glenjamin> i don't quite see how that doesn't apply to python - the only actual argument is speed i'd have thought. but meh
[17:14] <mgz> no, we want the bundled + manifest way
[17:14] <Glenjamin> does bzr use pyrex/pysco at all?
[17:17] <jam> Glenjamin: we do use pyrex, we don't use psyco
[17:18] <bialix> mgz: then we have to make sure ec2 build host has proprely licensed msvc 2008?
[17:18] <bialix> and then copy required dll as part of py2exe run, oh my...
[17:18] <mgz> I think it did? jam at least had full versions of the compilers I think.
[17:19] <jam> ec2 has the full versions of the compilers
[17:19] <bialix> jam: can I have access to ec2 when GaryvdM will build an installer?
[17:19] <Glenjamin> i'd imagine throwing pscyo at long running operations might speed them up a bit
[17:20] <bialix> at least read-only?
[17:20] <jam> bialix: fine with me, I'll need your ip address
[17:20] <jam> Glenjamin: we rarely have a long running bzr process
[17:20] <jam> at least from the command line point of view
[17:21] <jam> and IIRC, psyco doesn't save state between runs
[17:21] <bialix> jam: my ip address... I don;t have dedicated one
[17:21] <Glenjamin> bzr check springs to mind
[17:21] <bialix> it depends on the i-net provider
[17:22] <jam> bialix: I could potentially use a range, but I can always just set the one you have right now
[17:22] <jam> I'll also need a username/pass for you, but I can generate that
[17:23] <bialix> I see
[17:23] <bialix> I need to get in sync with Gary
[17:25] <bialix> bye for today
[17:34] <Glenjamin> can anyone suggest a good letter to abbreviate the --no-backup option to revert?
[17:37] <mgz> Ω
[17:48] <Glenjamin> UnicodeEncodeError: 'ascii' codec can't encode character u'\u03a9' in position 17: ordinal not in range(128)
[17:48] <Glenjamin> :(
[17:49] <Glenjamin> optparse wigs out on unicode it seems
[17:53] <GaryvdM> Hi roryy. I see you are from South Africa. Where are you base?
[17:53] <GaryvdM> I'm in Randburg.
[17:53] <roryy> hi GaryvdM.  In Centurion
[17:53] <GaryvdM> Oh cool.
[17:53] <roryy> not too far :)
[17:54] <mgz> roryy is the one who fixed two bugs in bzr the other day without changing any code at all
[17:54] <roryy> yers.  look out for my new book, "zen coding"
[17:54] <GaryvdM> roryy: Are you coming to sfd?
[17:55] <roryy> i don't know what sfd is
[17:55] <GaryvdM> Software Freedom day  - I'll find a link with the details .
[17:56] <roryy> ah-ha
[17:57] <roryy> google suggests softwarefreedomday.org
[17:57] <GaryvdM> http://wiki.softwarefreedomday.org/2010/Africa/South%20Africa/Pretoria
[17:59] <roryy> hrm, this w/e
[17:59] <GaryvdM> Yes
[18:01] <roryy> ah - you're doing a python talk
[18:01] <roryy> you work at csir?
[18:02] <GaryvdM> No - I work for lsd.co.za
[18:03] <roryy> an ex-colleague now at csir thinks numpy is awesome
[19:04] <knittl> hm. it says in the source code of testament.py 'indented-text form similar to log; human readable'
[19:04] <knittl> what text?
[20:05] <vila> ping LOSA
[20:06] <mbarnett> hello vila
[20:07] <vila> mbarnett: 2.3b1 will be released tomorrow, sorry for the late query :-(
[20:07] <vila> mbarnett: I need a pqm branch and the corresponding instance
[20:07] <vila> mvo: I just filed a RT ticket for it
[20:07] <vila> mvo: sry, bad Xchat :-/
[20:08] <vila> mbarnett: I just filed a RT ticket for it
[20:08] <mbarnett> what is the RT #?
[20:08]  * vila checks mail
[20:09] <vila> mbarnett: #41434
[20:14] <mbarnett> vila: hmm, this is a non trivial change and I am neck deep in another problem.  Let me see if I another losa might have time to work on this.
[20:15] <mthaddon> vila: what time tomorrow will it be released?
[20:16] <vila> mthaddon: hopefully before 16:00 UTC
[20:16] <mthaddon> vila: ok, in that case I can do it tomorrow before then
[20:16] <mbarnett> yay!
[20:16] <vila> mthaddon: great ! ping me if you need more info
[20:17] <vila> mbarnett: thanks for the chase !
[20:17] <mbarnett> np
[20:17] <vila> mthaddon: one thing I failed to mention is: which branch should you start with
[20:17] <mthaddon> vila: ok, please add that to the RT
[20:18] <vila> mthaddon: I have a question first: can you push this branch later (once) so we start with the "right" revision ?
[20:19] <mthaddon> vila: I'm not sure I understand the question - can you frame it another way for me?
[20:19] <vila> mthaddon:
[20:20] <vila> mthaddon: AIUI, you need to install a pqm instance (handwaving, I've no idea what it requires) including a branch of bzr itself, *and* push this branch to lp
[20:20] <vila> mthaddon: from there we send requests to the pqm instances to merge new revisions
[20:21] <mthaddon> vila: let's back up a bit - I was asking about what you mean by "can you push this branch later (once) so we start with the "right" revision" - I understand how to setup a new branch in PQM
[20:21] <vila> mthaddon: my question is: can you run a 'bzr pull --overwrite' and a 'bzr push lp:2.3' on this branch ?
[20:22] <mthaddon> vila: this is a new branch, so what am I pull --overwriting?
[20:22] <vila> mthaddon: a new branch, yes, but with a content
[20:22] <mthaddon> vila: I'm not sure what  that means...
[20:22] <vila> mthaddon: What I want to avoid is to have to revert some revisions or add fake merges
[20:23] <vila> mthaddon: what will be the revno of lp:bzr/2.3 once you create it ?
[20:23] <mthaddon> vila: so which branch and revision number do you want lp:~bzr-pqm/bzr/2.3 created from
[20:24] <vila> mthaddon: I don't know yet, maybe the current bzr.dev tip, maybe before, maybe after
[20:25] <mthaddon> vila: well I can't really do anything until you tell me that
[20:25] <vila> mthaddon: if you can modify the branch *before* we start using it, the precise revno doesn't matter that much and I can tell you later to modify it
[20:26] <vila> mthaddon: you can duplicate the bzr.dev instance to start with
[20:26] <mthaddon> but I have to create the branch somehow...
[20:26] <mthaddon> ok
[20:27] <vila> mthaddon: that's why I want to know if we can modify it ! So I can tell you either: start with bzr.dev@5430 *or* start with bzr.dev@5420 and we'll fix it later
[20:28] <mthaddon> vila: you can always modify it - it's just a bzr branch
[20:28] <vila> mthaddon: *I* don't have access to this branch :-)
[20:28] <mthaddon> vila: ok, when I say "you" I mean "someone"
[20:29] <mthaddon> i.e. a losa
[20:29] <vila> mthaddon: ok, we are in violent agreement then, I'll update the ticket
[20:36] <lifeless> vila: whats up?
[20:37] <roryy> is there any reason that "aptitude install python-testtools" doesn't give me the package from the bzr PPA?  The package doesn't seem to be listed in http://ppa.launchpad.net/bzr/ppa/ubuntu/dists/karmic/main/binary-i386/Packages (don't know if it should be?)
[20:37] <vila> lifeless: receiving support from losa to create the 2.3 pqm instance :)
[20:37] <lifeless> vila: what do you mean 'instnace'
[20:38] <lifeless> vila: do you mean 'please make a new branch for 2.3' ?
[20:38] <mthaddon> lifeless: he means a PQM managed bzr branch for the 2.3 series
[20:38] <vila> lifeless: whatever setup needed to get a lp:bzr/2.3 branch
[20:38] <lifeless> vila: not an instance, new branch, documented in losa procedures.
[20:38] <lifeless> mthaddon: I was scared for a second :)
[20:38] <mthaddon> heh
[20:38] <vila> lifeless: oh thanks, let me read that, oh wait :)
[20:38] <lifeless> mthaddon: its just branch, push & update the config.
[20:39] <lifeless> vila: you can I believe.
[20:39] <lifeless> IMBW
[20:39] <mthaddon> lifeless: yep
[20:39] <lifeless> mthaddon: great, you may resume sucking eggs at any time ;)
[20:39] <vila> mthaddon, lifeless : sorry guys, RM noob here ;)
[20:39] <mthaddon> :)
[20:41] <mthaddon> vila: have set it up branched off lp:bzr
[20:41] <vila> mthaddon: wow, you rock :)
[20:42] <vila> mthaddon: excellent, I see it on lp
[20:43] <vila> mthaddon: some people than bzr.dev can send their requests there right ? Or should I read those procedures before asking yet another silly question but in that case where ? :)
[20:43] <vila> s/some/same/ of course, the typo
[20:44] <mthaddon> vila: yep, set up with the same group as all other PQM-managed bzr branches
[20:45] <mthaddon> vila: well, it's the bazaar_releasemgr vs. the bzr group: https://pastebin.canonical.com/37310/
[20:45] <vila> mthaddon: great !
[21:54] <GaryvdM> jam: I'm struggling with a problem trying to build the win32 installer on my own host. I seem to remember getting the same error on the ec2 host, and you helped me fix it, but I can't remember how.
[21:54] <GaryvdM> Here is the error: http://pastebin.ubuntu.com/494940z
[21:55] <GaryvdM> sorry: should be http://pastebin.ubuntu.com/494940/
[21:56] <GaryvdM> That file is located here: (sorry - copy paste broken, but I know were the file is on the disk)
[21:57] <jam> GaryvdM: I don't remember fixing that off-hand
[21:57] <jam> did we document it?
[21:57] <jam> we *do* want to bundle that file, right?
[21:57] <jam> we may need to adjust PATH to include it?
[21:58] <GaryvdM> jam: I believe so, let me check if it was in the prev installers
[22:00] <GaryvdM> jam: In the 2.2.0 installer, we have MSVCR90.dll (apposed to MSVCP90.dll
[22:06] <jam> GaryvdM: from what I can tell, MSVCP90.dll is the C++ runtime, which I didn't think we use anywhere
[22:06] <jam> ah, maybe qt needs it?
[22:07] <GaryvdM> jam: Yes - if I py2exe without qbzr, it works - so I think it is a qt dependency.
[22:08] <GaryvdM> I'm going to try copy it to C:\Python26\DLLs
[22:08] <jam> GaryvdM: I would say look for wherever MSVCR90.dll is found
[22:08] <jam> you may also need stuff like MSVCPRT.dll, etc.
[22:08] <NightDog> Hi. From what I can read from bug 109114 bzr kind of has some problems with big(ish) binary files. Is there any way to increase some parameters to keep it from crashing due to out of memory? I got 16Gig RAM on this maching. Ubuntu 10.04, bzr version 2.2.0. Thanks
[22:09] <mgz> I don't see it linked in the process when I run a qbzr command with 2.2 though
[22:09] <mgz> isn't our qt built using mingw?
[22:09] <GaryvdM> Ah - that worked.
[22:10] <GaryvdM> I don't think it gets copied into the installer, just py2exe wants to see it.
[22:11]  * GaryvdM trys a full install build.
[22:11] <vila> GaryvdM: I'm marginally more happy than if you said: "Ha - that failed", but not knowing what 'that' is I refrain myself :)
[22:11] <GaryvdM> vila: that = "I'm going to try copy it to C:\Python26\DLLs"
[22:12]  * GaryvdM puts that in the build host doc
[22:12] <vila> Oh, I missed that one :)
[22:12] <mgz> can you try blacklisting them? I really think you only need the c runtime.
[22:13] <vila> I'm off, tomorrow is release day and I'll start early, good nitght all
[22:13] <mgz> night vila.
[22:13] <GaryvdM> mgz: I don't think it ends up in the installer, but I'm going to dbl check..
[22:13] <GaryvdM> night vila.
[22:19] <GaryvdM> mgz: Do you know what bialix wanted to do re the manifest file?
[22:19] <mgz> yeah, see: http://py2exe.org/index.cgi/Tutorial#Step52
[22:25] <jam> mgz: only 52 steps in? not bad :)
[22:25] <jam> wait
[22:29] <zsquareplusc> i'm going to ask something silly ;-) is it possible to clean up the history, e.g. would it be possible to say it should throw away all logs before a date?
[22:29] <zsquareplusc> i know i can do it with fast export/import at the expense of loosing the ability to compare the old and new tree. but some easier to use frontend/plugin in bzr itself would be practical.
[22:29] <zsquareplusc> maybe something like a "rebase" that merges all changes before a date to create a new base version.
[22:29] <zsquareplusc> i'm aware that such operations do not work well when different versions of the branch are published.
[22:30] <GaryvdM> mgz: We are excluding MSVCP90.dll in setup.py
[22:30] <GaryvdM> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/setup.py#L691
[22:31] <GaryvdM> But py2exe needs to be able to find it else it errors :-(


[05:22] <share> hello?
[07:19]  * willcooke -> packing
[07:20] <seb128> good morning desktopers
[07:20] <seb128> willcooke, good luck with that!
[07:20] <willcooke> seb128, :?
[07:20] <willcooke> seb128, :/
[07:20] <seb128> when is your flight?
[07:21] <willcooke> erm,
[07:21] <willcooke> I'm leaving here at 1pm
[07:21] <willcooke> so I've got enough time
[07:21] <willcooke> as long as I dont have to do washing first
[07:22] <seb128> yeah, a bit late for that!
[07:22] <desrt> pitti: the more containers talks i go to the more i become convinced that we made some sort of mistake by not having a microkernel...
[07:22] <willcooke> have you been drinking desrt ?
[07:22] <willcooke> ;)
[07:23] <desrt> willcooke: there are a whole class of kernel problems that for years have been considered 'not really a problem' since they require root in order to do things
[07:23] <desrt> but now you have root in your container for purposes of that container, and are able to exploit this whole class of bugs
[07:23] <desrt> things like filesystem driver bugs
[07:24] <desrt> "only root can mount filesystems, so intentionally corrupted filesystems are not a security concern"
[07:25] <willcooke> hmm
[07:25] <willcooke> I see the issue
[07:28] <Noskcaj> Can someone plz look at https://code.launchpad.net/~noskcaj/libgweather/bugfix/+merge/238660
[07:29] <pitti> hey seb128
[07:29] <seb128> hey pitti, wie gehts?
[07:30] <seb128> Noskcaj, what about the first half of the patch, why is it not upstream?
[07:30] <pitti> seb128: gut, danke! I'm in the LXC track right now, and will go back to the systemd hacking in the afternoon
[07:30] <seb128> nice
[07:31] <seb128> pitti, when do you fly to washington?
[07:34] <Noskcaj> seb128, It is, sorry i worded it porrly
[07:34] <pitti> seb128: Sunday noon, 11:40 to 15:15
[07:34] <Noskcaj> *poorly
[07:34] <pitti> seb128: with desrt
[07:34] <seb128> pitti, k
[07:34] <seb128> Noskcaj, I don't understand the "second half" part then
[07:34] <pitti> seb128: but you are most likely on a different flight?
[07:34] <seb128> pitti, yeah, I'm flying on saturday
[07:36] <Noskcaj> We have https://git.gnome.org/browse/libgweather/commit/?h=gnome-3-12&id=89de9f95660f2fcdaf8ffc4ebe3c7c192d42f464 , but still need https://git.gnome.org/browse/libgweather/commit/?h=gnome-3-12&id=6fed603e51538c10ebdbbbda857e94b352169056
[07:37] <seb128> Noskcaj, does it mean the sru which was done is incomplete/not working?
[07:38] <Noskcaj> yeah
[07:38] <Noskcaj> I'll make a branch for it when this is in utopic
[07:39] <seb128> k
[07:44] <seb128> Noskcaj, can you reply to my comment on the merge request?
[07:49] <seb128> Noskcaj, ?
[08:04] <seb128> Noskcaj, ...
[08:06] <Laney> hey hey, happy friday!
[08:08] <seb128> hey Laney, happy friday:
[08:08] <seb128> !
[08:08] <seb128> how are you?
[08:08] <seb128> Sweetsha1k, hey, could you review https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1342175 ?
[08:11] <Laney> oh no, debian-vote
[08:15] <pitti> Laney: :( just got aware of that too
[08:20] <darkxst> pitti, Laney, gnome-terminal can probably go straight to 3.14, the only problem is the alternate screen scroll patch, but I don't see how that is currently working in 3.12, vte_terminal_set_alternate_screen_scroll is just a stub
[08:21] <Laney> we dropped that one
[08:23] <darkxst> Laney, its still in the packaging branch
[08:28] <Laney> oh yes that's just the UI
[08:28] <seb128> Laney, what are they voting on?
[08:36] <seb128> willcooke, thanks for the note about the calendar/meetings
[08:36] <Sweetshark> seb128: already on my todo list
[08:37] <seb128> Sweetshark, hey, happy friday! great
[08:37] <willcooke> seb128, nw - I might be about to invite you to some more I'm afraid
[08:38] <seb128> willcooke, sure, np, can you get me to "desktop" on monday afternoon?
[08:38] <Sweetshark> seb128: happy friday to you too! ;) -- upstream has tagged LibreOffice <IP_ADDRESS> this week, so we should be able to SRU both in one turn ...
[08:38] <willcooke> seb128,  that's the fella :)
[08:38] <seb128> Sweetshark, great
[08:38] <seb128> willcooke, ;-)
[08:39] <seb128> willcooke, there is also a "desktop convergence" on tuesday
[08:39] <seb128> willcooke, I guess I'm just going to come sit and listen in some of the sessions anyway
[08:39] <seb128> just to know what's going on
[08:45] <seb128> Laney, could you look at gtk in the utopic queue?
[08:45] <Laney> I look at everything in the queue regularly :-)
[08:45] <Laney> but fixing eds first
[08:46] <Laney> damn those poodles
[08:46] <Laney> also: https://lists.debian.org/debian-vote/2014/10/msg00001.html
[08:46] <seb128> Laney, well, gtk is a one liner and I wanted to maybe have it ready for willcooke before he takes off for the airport, but alright
[08:47] <Laney> I'll just be 5 minutes
[08:47] <seb128> thanks
[08:47] <seb128> more init system fun
[08:47] <seb128> "nice"
[08:51] <willcooke> Laney, seb128 don't worry, my U8 laptop is packed now
[08:51] <willcooke> :)
[08:52] <seb128> willcooke, k, well I still would like the Mir backend to be working in utopic, and I would like the update to be available over the w.e if we want to do a demo on monday or something
[08:52] <seb128> so if that can go in today still a good thing to have
[08:52] <willcooke> that would be awesome!
[08:52] <willcooke> but don't rush on my account
[08:53] <seb128> well, I don't, I uploaded
[08:53] <seb128> I just used your name to get a bumped priority for review :p
[08:53] <seb128> or tried
[08:53] <seb128> you just ruined that ;-)
[08:54] <Laney> naughty
[08:54] <Laney> I think we've provided reasonable service this freeze
[08:54] <seb128> see, now Laney is downscoring me for trying to play with the system!
[08:54] <seb128> yeah, I can't complain
[08:55] <seb128> I more pinged as a fyi in case you didn't plan to do a review shift this morning, not because it has been waiting long
[08:55] <Laney> sure
[09:04] <darkxst> Laney, no the ui was already dropped
[09:05] <Laney> what do you mean already?
[09:06] <darkxst> 51_alternate_screen_scroll.patch
[09:06] <darkxst> adds a gsettings key and calls a vte function that is a stub in 4.12 and removed in 3.14
[09:06] <darkxst> ^3.12 even
[09:07] <Laney> 'already' meaning in the vcs
[09:07] <Laney> I'm not sure what your point is
[09:07] <Laney> we obviously have to stop using that API and do the upstream thing, but I'm not sure how you call that atm
[09:07] <darkxst> Laney, vcs is based on 3.12 right?
[09:07] <Laney> yes
[09:07] <darkxst> so that patch does nothing
[09:08] <Laney> so it has to be fixed, what's your point?
[09:08] <Laney> it is staged, not uploaded, nobody said it was finished
[09:08] <darkxst> Laney, as I said, can go straight to 3.14, but either way that needs to be fixed
[09:09] <Laney> are you offering to do it?
[09:10] <darkxst> I already have a 3.14 package, but I don't know how to fix that patch
[09:11] <Laney> they added a control sequence but I'm not sure how you're supposed to make use of it
[09:11] <Laney> you could go ask
[09:11] <Laney> I'm not hugely interested in supporting the feature
[09:11] <darkxst> yes I saw that
[09:14] <darkxst> I could ask but upstream are pretty grumpy with ubuntu
[09:16] <pitti> Sweetshark: hm, does that "free(): invalid pointer" crash in the LO test ring a bell?
[09:16] <larsu> darkxst: it's getting better. What's the problem?
[09:18] <darkxst> larsu, how to send the control sequencence that does the equivalent to vte_terminal_set_alternate_screen_scroll (which is removed)
[09:18] <Laney> I think it's only chpe and the others are fine to be fair
[09:19] <larsu> darkxst: what's alternate screen scroll? And why do we need it but upstream doesn't?
[09:19] <larsu> Laney: right
[09:21] <darkxst> Laney, yeh chpe is
[09:21] <darkxst> larsu, it modifies the scroll wheel behaviour for certain shell apps I think, no I idea why we need it really though
[09:22] <GunnarHj> Hi Laney!
[09:22] <darkxst> I would be happy to just drop it
[09:22] <larsu> darkxst: if we don't know why we need it, let's drop it until someone complains with a use case...
[09:22] <larsu> Laney: are you ok with that? ^
[09:24] <Laney> If you read the bugs you find that people like to set it
[09:24] <Laney> I don't understand why they took the escape sequence and what you're supposed to do with it and I would like to find that out
[09:25] <GunnarHj> Laney: Does "NotShowIn=GNOME" refer to Ubuntu GNOME only, or is Xubuntu, Lubuntu etc. included?
[09:27] <darkxst> GunnarHj, GNOME is only GNOME3 sessions
[09:27] <GunnarHj> darkxst: So the answer is yes?
[09:28] <darkxst> yes, so basically just gnome-shelll
[09:28] <Sweetshark> pitti: /me tries to get context from backlog
[09:28] <GunnarHj> darkxst: Great, thanks!
[09:29] <Sweetshark> pitti: so "free(): invalid pointer" doesnt ring a bell right away here.
[09:31] <pitti> Sweetshark: the LO tests, i. e. https://jenkins.qa.ubuntu.com/job/utopic-adt-libreoffice/336/ARCH=amd64,label=adt/console
[09:36] <Sweetshark> pitti: ah! so I dont think that is a regression. The forms_* tests are unfortunately not 100% stable, just mostly stable (IIRC e.g. debian disables them in when they run them in check on package build).
[09:37] <GunnarHj> pitti: Hi Martin!
[09:37] <GunnarHj> pitti: Two things:
[09:37] <GunnarHj> pitti: Do you have two minutes to review comment #17-21 at bug #678421?
[09:37] <GunnarHj> pitti: Are you about to release new base langpacks?
[09:37] <Sweetshark> pitti: I left them in on the autopkgtests to see if there are any other issues there. On autopkgtests they dont block as much as in a check-phase in package build (which would throw away a day of libreoffice building).
[09:49] <seb128> ok, need to go for some errands and lunch
[09:49] <seb128> back a bit later than usual
[09:49] <seb128> bbl
[11:31] <pitti> Sweetshark: ack, retrying
[14:03] <seb128> kenvandine, hey
[14:03] <kenvandine> hey seb128
[14:03] <seb128> kenvandine, do you know what's the status/plan for settings landing?
[14:03] <seb128> seems like we have a bunch lines and other important fixes not lined up yet
[14:04] <seb128> like ted has one for the messaging changes
[14:04] <seb128> you have one for the flight mode in rtm
[14:04] <kenvandine> waiting for the landings to open up again
[14:04] <seb128> the custom ringtone needs to land, as apparently do some others
[14:04] <seb128> you can do utopic landings
[14:04] <seb128> just not rtm
[14:04] <kenvandine> yeah, but i'm worried about landing in utopic first :)
[14:04] <kenvandine> been bitten to many times
[14:05] <seb128> ?
[14:05] <kenvandine> seb128, and the critical/high landings we need, are really needed in rtm
[14:05] <kenvandine> the delta
[14:05] <tedg> seb128, Do you know anyone using Evo? Getting an issue with GPG signed messages.
[14:06] <seb128> well, just do a landing with the rcs
[14:06] <kenvandine> landings in utopic go faster than rtm
[14:06] <kenvandine> so if we get a few landings in utopic
[14:06] <seb128> tedg, what issue? ogra_ does, Laney has it installed (so do I)
[14:06] <tedg> seb128, Also when sending the GPG signature area is full of debug messages.
[14:06] <kenvandine> and then we get held up in rtm, fails qa, etc
[14:06] <kenvandine> it's really hard to unwind stuff and get them in sync again
[14:06] <tedg> seb128, I'm curious if I'm missing a component as I don't have GPG settings in preferences anymore either.
[14:06] <seb128> kenvandine, just put "qa not needed" ;-)
[14:06] <kenvandine> ha
[14:06] <seb128> tedg, let me try
[14:09] <seb128> tedg, what sort of issues do you have reading gpg signed emails?
[14:09] <seb128> I get the banner "signature exists but require a public key"
[14:10] <tedg> seb128, They never open. When I select another message it gets replaced with: "Error verifying signature: Operation was cancelled"
[14:10] <seb128> or "signature valide, but impossible to verify sender"
[14:10] <seb128> urg
[14:10] <seb128> no, that works for me
[14:10] <tedg> seb128, Do you have encryption settings in your preferences?
[14:10] <seb128> trying on ubuntu-devel e.g with some emails from slangasek or pitti
[14:11] <pitti> seb128: are you sure that they are from me? :-)
[14:11] <seb128> pitti, :-)
[14:11] <pitti> damn you gpg and your undeniable signatures
[14:12] <tedg> seb128, Which evolution packages do you have installed? http://paste.ubuntu.com/8579320/
[14:12] <seb128> tedg, utopic
[14:12] <seb128> tedg, the settings are in the accounts' details
[14:12] <seb128> like first tab of preference
[14:12] <seb128> double click on an account
[14:12] <seb128> bottom section
[14:12] <seb128> "security"
[14:13] <tedg> Ah, so those just moved.
[14:23] <GunnarHj> pitti: ping?
[14:24] <pitti> GunnarHj: sorry, need to run, I have a train to catch
[14:25] <pitti> GunnarHj: conference, attention etc. -- can you please mail?
[14:25] <GunnarHj> pitti: Sure, I can mail. Happy journey!
[14:54] <ogra_> tedg, no issies here
[14:54] <ogra_> *issues
[14:55] <tedg> Hmm, it must be something else installed or not installed.
[14:55] <tedg> Haven't been able to figure it out :-(
[16:35]  * Laney is taking off now
[16:36] <Laney> see some of you soon
[16:41] <seb128> Laney, have a safe travel, see you in Washington!
[16:41] <Laney> you too!
[16:45] <seb128> Laney, when do you get there? sunday?
[17:30] <ogra_> Laney, dont forget to carry a clipboard with you ... i heard that protects from certain deseases
[19:55] <Laney> seb128: yeah sunday 8.30pm ish
[19:55] <Laney> save me a welcome drink ;-)


[16:01] <TheLordOfTime> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1064483  <-- erm, why would an update ask you where to install Grub2?  Wouldnt that have already been installed...?
[16:01] <ubot2> Ubuntu bug 1064483 in grub2 "Grub 2 update install bug" [Undecided,New]
[16:33] <mitya57> TheLordOfTime: looks like a duplicate of bug 1009294
[16:33] <ubot2> Launchpad bug 1009294 in Ubuntu Precise "Grub update breaks automated dist-upgrade scripts on AMI images" [High,Fix released] https://launchpad.net/bugs/1009294
[16:34] <TheLordOfTime> mitya57, i'm going to post to the bug asking whether they're on an AMI image or not
[16:35] <mitya57> TheLordOfTime: that may affect not only AMI images
[16:35] <TheLordOfTime> mitya57, should've been fixed, then, no?
[16:35] <TheLordOfTime> if itsi a dupe, the orig is fix released, that'd mean the bug wouldn't exist, no?
[16:36] <mitya57> TheLordOfTime: maybe it can happen during upgrade from the old (not-fixed) version
[16:37] <TheLordOfTime> possibly, i think we'd need more info
[16:37] <TheLordOfTime> but atm, i'm focusing on the server team stuffs, since i can :p
[16:37] <TheLordOfTime> that, and php5 on my system imploded
[16:37] <TheLordOfTime> so i have to fix that :p
[16:39] <mitya57> TheLordOfTime: it seems I'm wrong — that bug is about /etc/default/grub change prompt, not about where-to-install prompt
[16:39] <mitya57> the latter should never happen
[16:39] <TheLordOfTime> that's what i thought :P
[16:39] <TheLordOfTime> the only time i could forsee it happening...
[16:39] <TheLordOfTime> is update-via-iso in the GUI live environment
[16:40] <TheLordOfTime> i.e. using the livecd or ISO to upgrade an already-installed system
[16:40] <mitya57> TheLordOfTime: I think you should ask cjwatson on #ubuntu-devel
[16:41] <TheLordOfTime> i might
[16:41] <TheLordOfTime> ... later :P
[16:41] <mitya57> well, I can do that myself
[16:42] <TheLordOfTime> mitya57, *shurgs*
[16:55] <mitya57> TheLordOfTime: cjwatson says this could happen on hardware changes, I've asked the reporter if that was the cause.
[16:55] <TheLordOfTime> wonderful :0
[16:55] <TheLordOfTime> :)
[16:55] <TheLordOfTime> less work for me!  :P