[03:27] <infinity> tsimonq2, wxl: Fixed.
[03:28] <infinity> (Or, will be on the next build)
[03:28] <infinity> And no, it had nothing to do with participation in .6
[03:29] <infinity> It had to do with someone archiving .5 ISOs and not removing them from the manifest, that's all.
[03:29] <infinity> Timing would have been the deciding factor in some failing and others now.
[03:29] <infinity> s/now/not/
[03:29] <infinity> fossfreedom: ^
[04:46] <tsimonq2> Thanks.
[07:37] <acheronuk> logs say kubuntu iso succeeded 2 hrs ago, but no sign @ http://cdimage.ubuntu.com/kubuntu/daily-live/
[07:39] <acheronuk> sil2100: morning. logs say kubuntu iso succeeded 2 hrs ago, but no sign @ http://cdimage.ubuntu.com/kubuntu/daily-live/
[07:40] <acheronuk> qa tracker link is 'not found'
[07:41] <acheronuk> today's ubuntu-mate iso is the same
[07:42] <acheronuk> oh. mate was pre infinity's fix
[07:53] <sil2100> acheronuk: hey! Looking
[07:54] <acheronuk> sil2100: ty
[07:55]  * acheronuk notes ubuntu job is now running
[07:56] <sil2100> acheronuk: ok, everything seems to look correct on nusakan, I manually forced a mirror sync
[07:56] <sil2100> Maybe now it'll be visible
[07:57] <sil2100> Let's give it some time
[07:57] <sil2100> 20190310  20190311  current  pending
[07:57] <sil2100> That's on nusakan itself
[07:58] <acheronuk> sil2100: yeah. ok I have to go for 30 mins anyway, so will re-check in a bit. thanks :)
[08:44] <acheronuk> sil2100: how long does this normally take to show up?
[08:52] <sil2100> acheronuk: hm, usually it's 'almost' instant, this is weird
[09:31] -queuebot:#ubuntu-release- Unapproved: apt (cosmic-proposed/main) [1.7.3 => 1.7.4] (core)
[09:31] <juliank> sil2100: ^ can you reject that, I messed up the changelog a bit
[09:31] <juliank> I'd like to reupload it
[09:32] <juliank> I gotta change gbp dch at some point
[09:33] -queuebot:#ubuntu-release- Unapproved: apt (cosmic-proposed/main) [1.7.3 => 1.7.4] (core)
[09:33] <juliank> And here's the fixed one
[09:36] -queuebot:#ubuntu-release- Unapproved: apt (bionic-proposed/main) [1.6.9 => 1.6.10] (core)
[09:40] -queuebot:#ubuntu-release- Unapproved: rejected apt [source] (cosmic-proposed) [1.7.4]
[09:40] <apw> juliank, ^
[09:40] <juliank> thanks apw
[09:48] <acheronuk> sil2100: indeed. still no sign my end
[09:49] <acheronuk> ubuntu images are likewise missing
[09:52] <sil2100> Let me poke is about that
[09:53] <acheronuk> ok. ty
[10:41] <LocutusOfBorg> hello, can anybody please update debci hint to 2.0 too?
[12:21] <sil2100> acheronuk: should be fixed, do you see the images now?
[12:22] <acheronuk> sil2100: nope
[12:23] <sil2100> acheronuk: did you try to hard-refresh? Or check in a different browser/tool (like even curl)
[12:23] <sil2100> e.g. curl http://cdimage.ubuntu.com/kubuntu/daily-live/ just to see if it's not the browser cache
[12:23] <acheronuk> 1st 2 of thsoe
[12:24] <acheronuk> sil2100: now just appeared
[12:25] <acheronuk> looks like we are good. thanks
[12:26] <acheronuk> what? on another refresh they are gone.
[12:27] <acheronuk> partial mirroring?
[12:29] <acheronuk> and they are back again. fun!
[12:30]  * acheronuk zsyncs quickly...
[12:33] <acheronuk> sil2100: must be only partially mirrored, as sometime I get a stale one on refresh on the same browser tab, where a min before I had the latest
[12:35] <LocutusOfBorg> doko, ^^ can you please ask to accept them?
[12:37] -queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.18-dfsg-3~ubuntu18.04.2 => 5.2.18-dfsg-3~ubuntu18.04.3] (no packageset)
[12:37] -queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.18-dfsg-2~ubuntu18.04.3 => 5.2.18-dfsg-2~ubuntu18.04.4] (ubuntu-cloud)
[12:51] <LocutusOfBorg> please accept them ^^ to unblock java
[12:52] <LocutusOfBorg> sil2100, https://launchpad.net/ubuntu/+source/virtualbox-hwe/5.2.18-dfsg-3~ubuntu18.04.2
[12:52] <LocutusOfBorg> you won't find bug numbers, they are build fixes because the previous version didn't build correctly due to new java
[13:25] -queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.18-dfsg-3~ubuntu18.04.3]
[13:25] -queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (bionic-proposed) [5.2.18-dfsg-2~ubuntu18.04.4]
[13:25] <doko> LocutusOfBorg: no, has to be built with security only. will upload to a ppa
[13:35] <ddstreet> sil2100 good morning/afternoon!  wondering if you have a chance today, can you release systemd for x/b/c, and resolvconf for b/c?
[13:54] <doko> LocutusOfBorg: https://launchpad.net/~openjdk-11-transition/+archive/ubuntu/stage5/+build/16483297  Missing build dependencies: xserver-xorg-dev-hwe-18.04
[13:56] <LocutusOfBorg> doko, you need proposed too
[13:58] <LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox-hwe/+bug/1816386
[14:00] <LocutusOfBorg> doko, https://launchpad.net/ubuntu/+source/xorg-server-hwe-18.04
[14:00] <LocutusOfBorg> you need to enable bionic-updates
[14:06] <doko> LocutusOfBorg: I'll see what we will do. is this dependency absolutely required?
[14:12] <halves> sil2100 hey there! could you please approve upload in X for qemu (LP: #1818880)? (cc'ing slashd)
[14:17] <LocutusOfBorg> doko, yes, it is, otherwise the -hwe stack won't be used, and virtualbox-hwe exists only for that reason :)
[14:18] <doko> will ask security how they want to handle that
[14:26] <sil2100> halves: hey! Will try o/
[14:26] <sil2100> ddstreet: ok o/
[14:32] <halves> sil2100 thanks man o/
[14:37] <LocutusOfBorg> doko, the reason for that package is only for people with -updates pocket enabled, so if you enable that one for vbox-hwe there would be no issue wrt archive consistency
[14:39] <slashd> sil2100, hope I'm saying it right "dzięki" ;)
[14:45]  * sil2100 starts his SRU shift just now
[15:34] <vorlon> Eickmeyer, cyphermox: 'lintian -I' has a lot to say about carla's debian/copyright
[16:09] <cyphermox> Eickmeyer: do you want to fix that please? ^
[16:10] <Eickmeyer> cyphermox, vorlon: I'll get on that after 1) the current meeting in progress, and 2) getting my son to school (which is already late).
[16:10] <Eickmeyer> Timinig on the meeting was going to lead to that, so I was prepared.
[16:10] <cyphermox> Eickmeyer: the meeting is not even close to done though
[16:57] -queuebot:#ubuntu-release- Unapproved: virtualbox-lts-xenial (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu<IP_ADDRESS>~14.04.5 => 4.3.36-dfsg-1+deb8u1ubuntu<IP_ADDRESS>~14.04.6] (no packageset)
[16:57] -queuebot:#ubuntu-release- Unapproved: virtualbox (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu<IP_ADDRESS> => 4.3.36-dfsg-1+deb8u1ubuntu<IP_ADDRESS>] (ubuntu-cloud)
[16:58] <LocutusOfBorg> sil2100, ^^ please accept them, klebers needs to do testing for the kernel in proposed
[16:58] <LocutusOfBorg> I syncd the security update on lts-xenial, now they are back in sync
[16:59]  * sil2100 still in a very heated meeting
[16:59] <LocutusOfBorg> (also bionic when you can please!)
[17:00]  * LocutusOfBorg quits
[17:39] <klebers> LocutusOfBorg, were there new uploads for these packages? At least virtualbox-lts-xenial currently in trusty-proposed already had the build fix.
[18:06] <Eickmeyer> vorlon, cyphermox: Workng on Carla now.
[18:16] <cyphermox> Eickmeyer: thanks. ping me when you need sponsoring
[18:22] <Eickmeyer> cyphermox: I have a question. It looks like lintian is calling-out some issues in the copyright file for files that are only used when building for Windows or Mac (it's a cross-platform utility). Should those be a lintian-overrides or completely removed since packaging for Debian would never use those files?
[18:23] <Eickmeyer> vorlon: If you can speak to this as well. ^
[18:23] <vorlon> Eickmeyer: the lintian call-out is because static analysis of the source package shows no files exist that match the glob
[18:24] <Eickmeyer> vorlon: Okay, if that's the case I'll remove those paragraphs.
[18:24] <vorlon> (and if they are platform-specific tools that are pulled in from somewhere other than the source tarball on other platforms, there's no reason to list them in debian/copyright)
[18:24] <Eickmeyer> As they are.
[18:47] -queuebot:#ubuntu-release- Unapproved: libpdfbox-java (bionic-proposed/universe) [1:1.8.13-2 => 1:1.8.16-2~18.04] (no packageset) (sync)
[18:47] -queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.18-dfsg-2~ubuntu18.04.3 => 5.2.18-dfsg-2~ubuntu18.04.5] (ubuntu-cloud) (sync)
[18:47] -queuebot:#ubuntu-release- Unapproved: mongo-java-driver (bionic-proposed/universe) [3.6.2-1 => 3.6.3-2~18.04] (no packageset) (sync)
[18:47] -queuebot:#ubuntu-release- Unapproved: openhft-chronicle-threads (bionic-proposed/universe) [1.1.6-1 => 1.1.6-2~18.04.1] (no packageset) (sync)
[18:53] <vorlon> LocutusOfBorg: hi, chatting w/ doko about virtualbox-hwe, we discussed its prior reject from -proposed and concur that it should be uploaded to -proposed and built there; however it seems there is no bug linked from the changelog which is a problem for the SRU process, could you please correct this and reupload?
[18:56] <sil2100> halves: accepted (sorry it took so long)
[18:56] -queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.35]
[18:56] <Eickmeyer> vorlon, cyphermox: Latest commit fixes copyright errors.
[18:57] <Eickmeyer> (to carla)
[18:57] <halves> sil2100 no worries man, thank you for the help!
[18:58] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (bionic-proposed) [5.2.18-dfsg-2~ubuntu18.04.5]
[18:58] <Eickmeyer> I was unclear as to if it should have a new version number since it never made it out of the queue.
[18:59] -queuebot:#ubuntu-release- Unapproved: accepted libpdfbox-java [sync] (bionic-proposed) [1:1.8.16-2~18.04]
[19:01] <cyphermox> Eickmeyer: same version number is okay; so you'd want to git push --force or whatnot
[19:01] -queuebot:#ubuntu-release- Unapproved: accepted mongo-java-driver [sync] (bionic-proposed) [3.6.3-2~18.04]
[19:01] -queuebot:#ubuntu-release- Unapproved: accepted openhft-chronicle-threads [sync] (bionic-proposed) [1.1.6-2~18.04.1]
[19:02] <cyphermox> Eickmeyer: (if you had previously committed a release and tagged and all)
[19:04] <Eickmeyer> cyphermox: Not seeing it. :/
[19:04]  * Eickmeyer forgot to tag it
[19:05] <cyphermox> I was speaking generally
[19:05] <cyphermox> I'm finishing up with something and then I'll review what's in your git tree
[19:07] <Eickmeyer> Okay, sounds good. I just pushed the tag.
[21:47] -queuebot:#ubuntu-release- Unapproved: cloud-init (cosmic-proposed/main) [18.5-21-g8ee294d5-0ubuntu1~18.10.1 => 18.5-45-g3554ffe8-0ubuntu1~18.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[21:47] -queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.5-21-g8ee294d5-0ubuntu1~18.04.1 => 18.5-45-g3554ffe8-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[21:48] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [18.5-21-g8ee294d5-0ubuntu1~16.04.1 => 18.5-45-g3554ffe8-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[21:51] <Odd_Bloke> infinity: If you have time to put your SRU hat on and look at those cloud-init uploads, it would be much appreciated; we have a couple of hot items in there and would like to get our validation process started ASAP. :)
[21:58] -queuebot:#ubuntu-release- New source: carla (disco-proposed/primary) [1.9.13-0ubuntu1]
[22:03] -queuebot:#ubuntu-release- Unapproved: grub2 (disco-proposed/main) [2.02+dfsg1-12ubuntu2 => 2.02+dfsg1-12ubuntu2] (core)
[22:15] <Eickmeyer> cyphermox: I'm guessing it looked much better? ^
[22:15] <acheronuk> ooooh \o/
[22:19] -queuebot:#ubuntu-release- Unapproved: grub2 (disco-proposed/main) [2.02+dfsg1-12ubuntu2 => 2.02+dfsg1-12ubuntu2] (core)
[22:21] -queuebot:#ubuntu-release- New: rejected carla [source] (disco-proposed) [1.9.13-0ubuntu1]
[22:21] <Eickmeyer> :(
[22:22] <vorlon> that's the previous upload ;)
[22:22] <Eickmeyer> Ohhhh....
[22:24]  * Eickmeyer is mobile and can't tell
[22:27] -queuebot:#ubuntu-release- Packageset: 109 entries have been added or removed


[06:03] <ScottK> Archive is open.  First autosync is running.
[07:54] <lordievader> Good morning.
[10:27] <BluesKaj> Howdy folks
[10:27] <soee_> hi BluesKaj
[10:27] <BluesKaj> hey soee_
[13:16] <shadeslayer> Quintasan: http://m.imgur.com/TzfyPaJ
[13:16] <Quintasan> from left
[13:16] <Quintasan> good
[13:17] <Quintasan> good
[13:17] <Quintasan> good
[13:17] <Quintasan> good
[13:17] <Quintasan> very good
[13:17] <Quintasan> soplica pigwowa - wtf why would you even
[13:17] <Quintasan> biscuits - 10/10 would eat
[13:17] <Quintasan> I have no idea what it is but the hat is awesome
[13:18] <shadeslayer> XD
[13:18] <Quintasan> but bloody hell
[13:19] <Quintasan> soplica orzech laskowy (hazelnut) is brilliant
[13:19] <shadeslayer> Haha
[13:19] <shadeslayer> I shall sample some
[18:44] <lfaraone> Is there an analogue of sni-qt for qt5?
[18:50] <kubotu> ::workspace-bugs:: [1313170] systemsettings > Display Configuration shows bogus monitor @ https://bugs.launchpad.net/bugs/1313170 (by Christian A. Reiter)
[19:05] <debfx> lfaraone: afaik not yet. Qt 5.3 will contain the necessary interfaces and KDE frameworks will surely provide an SNI plugin.
[19:21] <kdeuser56> yofel: how do I get kde-telepathy video calls get to work ... I have already install kde-telepathy-call.-ui and restarted, but the options are still greyed out
[19:25] <ghostcube> sooo project 14.04 kubuntu on an old inspiron 8600 dell has been completed
[19:25] <ghostcube> :D
[19:25] <ghostcube> smooth maschine state
[19:29] <lfaraone> debfx: ah, okay. So there's not really a story for Unity AppIndicators in Qt yet?
[19:29] <lfaraone> *Qt5
[19:59] <debfx> lfaraone: don't think so
[20:34] <ghostcube> new kidz auf p7
[20:34] <ghostcube> ;D#
[20:34] <ghostcube> der neue jagoar is schon geil
[20:34] <ghostcube> u
[20:54] <kubotu> ::workspace-bugs:: [1313193] Missing "$" in /usr/bin/startkde @ https://bugs.launchpad.net/bugs/1313193 (by Rafael Jesus Alcantara Perez)


[01:40] <_habnabit> http://www.habnabit.org/bzr-graph3.png <- out of curiosity, why is it that most of the merged revisions are numbered 85.[1-5].X? Merging from trunk (which is what it's clustered around) doesn't seem to reset it.
[01:40] <_habnabit> I'm unclear on how revision numbers are assigned from a merge.
[01:45] <_habnabit> (My guess it it's using the earliest shared parent revision contained in the branch.)
[01:47] <maxb> _habnabit: <mainline revno branched from>.<sequential numbering of branches off that mainline point>.<position on that branch>
[01:48] <_habnabit> maxb, so the only way to reset the first number is to make a new branch?
[01:48] <maxb> yes.... though it's just an arbitrary number, does it matter?
[01:48] <_habnabit> I'm just curious.
[01:48] <_habnabit> I don't care about it.
[01:50] <lifeless> _habnabit: if you pull from trunk, it will reset all your local revnos to be identical to those in trunk
[01:50] <_habnabit> Aha.
[01:50] <lifeless> but you can only do that after trunk has merged from you
[01:50] <_habnabit> Right.
[01:56] <maxb> wtf, we have an intermittent test failure in bzr 2.3b4 in bzr-beta-ppa :-(
[01:56] <spiv> maxb: :(
[02:02] <maxb> list emailed
[02:02] <maxb> I'm baffled
[03:25] <jubei__> is there a way to check if there are changes to a repository before running bzr pull ?
[03:26] <bob2> bzr missing
[03:33] <jubei__> awesome, thanks
[03:58] <rocky> is it possible to create branch X from a subdir in mybranc?  say mybranch has subdirs sd1 and sd2 and i want to produce a branch that only consists of sd1 stuff...
[03:59] <bob2> you can branch, delete, move.  or there's the split stuff, but I don't know how usable that is atm
[04:08] <spiv> maxb: replied; known issue, fixed upstream and workaround just landed in lp:bzr
[04:12] <maxb> gosh
[04:12] <maxb> how obscure
[04:14] <spiv> maxb: on the plus side, it wasn't our fault ;)
[07:22] <vila> hi all
[07:31] <vila> poolie: hey ! the poolie_droid sounded like a definitive SSD failure :-}
[07:33] <vila> maxb: fix landed, I filed bug #686008 as soon as I saw the daily builds failures, sorry I didn't think to warn you explicitly
[07:35] <vila> maxb: ... obscure it not fair for this, it's far worse than that (and my English is not good enough to find the fait word there ;)
[07:35] <vila> s/fait/fair/
[07:37] <vila> maxb: even knowing what was happening and why I couldn't write a *reliable* reproducing test :-/ See https://code.edge.launchpad.net/~vila/bzr/686008-spurious-https-failure/+merge/42969 for details
[07:59] <vila> poolie: ping
[08:01] <poolie> hi vila
[08:02] <vila> poolie: was your _droid suffix related to your SSD issues ? :-}
[08:02] <poolie> haha
[08:02] <poolie> not right at the moment
[08:29] <fullermd> vila: (brief moment of lucidity) I pulled in your changes and did somsethingorother yesterday.
[08:30] <vila> fullermd: yup, I saw that ! Thanks ! Take care
[08:30]  * fullermd tries to get another 2 hour block of sleep...
[09:24] <ronny> hi
[09:24] <ronny> where is bzrlib.bzrdir gone?
[09:26] <vila> ronny: it seems to be present in all my bzr branches, may be you can be more specific ?
[09:29] <ronny> vila: im testing agains what is pip/easy_install-able
[09:29] <ronny> it recently broke
[09:29] <ronny> its quite annoying that bzr breaks the anyvc builds every few weeks in such unexpected ways
[09:30] <vila> I can understand your frustration but I still have no idea what failure you're talking about
[09:31] <vila> bzrlib/bzrdir.py is quite a significant piece and it won't disappear without notice
[09:32] <ronny> vila: the testing process currently download whatever bzr version is pip installable, and tests agaist that
[09:32] <ronny> (there is no way to sanely link to older ones)
[09:33] <vila> I have no idea what pip installable means but I can give you links for many bzr versions including the stable ones
[09:33] <ronny> vila: its quite useless if pip install bzr==version does not work
[09:33] <vila> ...
[09:34] <vila> you're talking chinese as far as I'm concerned
[09:34] <mgz> it's one of those setuptools based html scraping things.
[09:35] <mgz> because installing stuff from random bits downloaded over http is always such a great idea.
[09:35] <vila> ronny: are you telling that you don't have a bzrlib/bzrdir.py file ?
[09:36] <vila> ronny: if that's the case, the way you acquire bzr is seriously broken
[09:37] <vila> ronny: being the bzr release manager these days, I can assure you that *all* recently releases version *includes* this file
[09:37] <ronny> hmm, it actually exists
[09:37] <vila> ha, we're making progress
[09:37] <ronny> vila: well, why the hell is NONE of them propperly availiable on pypi
[09:37] <ronny> pretty much everything else i use just does that, and i can just get any version i want by package==version
[09:38] <ronny> only bzr makes me work extra
[09:38] <ronny> like always
[09:38] <vila> may be we can focus on concrete problems and how to solve them rather than ranting ?
[09:38] <ronny> ok, sorry
[09:40]  * ronny finishes the local reproducing
[09:40] <vila> what OS are you using ? I maintain quite a few flavours but *NONE* of them requires to use easy_install and I'm not familiar with how this works
[09:41] <ronny> vila: im using tox to create virtualenvs with all requirements for the test runs
[09:41] <ronny> its using pip to grab the requirements
[09:41] <ronny> (and falls back to easy_install if necessary)
[09:41] <vila> what is pip and what is tox ?
[09:41] <vila> bah, nvm
[09:42] <vila> where are you getting bzr and in which form ? tar.gz ? .deb ?
[09:42] <ronny> tarball, installing it in a virtualenv after all
[09:43] <vila> where is this tarball coming from ?
[09:43] <vila> and what OS are you using (no, really) ?
[09:44] <ronny> im on the latest ubuntu, the test box is on a gentoo, its all linux
[09:44] <ronny> the thing pip currenly grabs is  bzr-2.3b4.tar.gz
[09:44] <vila> so both of them provides stable releases AFAIK
[09:44] <mgz> vila, as I was saying, it scrapes html, and has broken in the past from <https://launchpad.net/bzr/+download> changing format.
[09:45] <vila> ronny: if you're using betas instead, then you are *expected* to encounter problems and give us feedback, that's the point of betas
[09:45] <ronny> vila: well, the issue for me is simple - bzr cannot propperly be installed by the python package installer
[09:46] <vila> ronny: this is as useful as bug reports saying: 'Does not work'
[09:46] <mgz> it just gets the first likely link on that page.
[09:47] <ronny> vila: i requested pushing all releases to pypi as well some times now
[09:47] <vila> ronny: afaik the python installer is used in Ubuntu and there is even *daily* builds exercising it, so surely you encounter something more specifi
[09:47] <vila> ronny: right, may be you teach us how to do that then
[09:48] <ronny> vila: python package installers are pip and easy_install
[09:48] <spiv> ronny: python package installers are "python setup.py install", really.
[09:48] <vila> ronny: don't they rely on setup.py ?
[09:48] <ronny> vila: yes, but they have to grab the package from soemwhere first
[09:48] <ronny> and in bzr's case, the only link they ever can get is the latest tarball out
[09:49] <spiv> Or did pip/easy_install get integrated into the standard Python distribution since I last checked?
[09:49] <vila> ronny: is there a way to fix that on http://pypi.python.org/pypi/bzr ?
[09:49] <ronny> the usual way is to just push the tarballs there
[09:49] <spiv> (I agree it would be nice to work well with pip etc, though)
[09:49] <ronny> usually people upload after a sdist
[09:50] <vila> ronny: as far as I know, the instructions say: 'python setup.py register' which I did for 2.2.2
[09:50] <mgz> I'm not even sure that's enough, because bzr has build dependencies that it doesn't declare using the setuptools machinary.
[09:50] <ronny> vila: that only tells pypy there is a project with that version
[09:51] <mgz> so virtualenv installs may break even if tarballs get uploaded.
[09:51] <vila> ronny: that's why I mention it, what should be done is what I'm asking
[09:51] <ronny> mgz: tarballs ship with c files, dont they?
[09:51] <mgz> ah, so they do.
[09:51] <ronny> vila: upload after sdist
[09:51] <vila> upload
[09:51] <vila> -bash: upload: command not found
[09:51] <mgz> and I guess you don't care about running selftest.
[09:52] <ronny> vila: its a distutils command
[09:52] <vila> distutils upload
[09:52] <vila> -bash: distutils: command not found
[09:53] <mgz> as in setup.py vila.
[09:54] <vila> python setup.py upload
[09:54] <vila> running upload
[09:54] <vila> error: No dist file created in earlier command
[09:54] <mgz> +setuptools specifc.
[09:54] <vila> and yes, I'm in the right directory from which 2.2.2 was released
[09:55] <mgz> basically, the problem is we don't use setuptools.
[09:55] <mgz> which I think isn't something we want to change.
[09:55] <vila> ronny: here it goes ^
[09:56] <ronny> vila: doesnt matter
[09:56] <vila> ronny: if you care about it, a patch against bzr making your life easier will certainly be considered, failing that, may be you should think of a better way to select your bzr source
[09:56] <ronny> vila: pip/easy_install force setuptools on any setup.py
[09:57] <ronny> vila: just upload the dam tarballs to pypi
[09:57] <ronny> pip/easy_install will do the rest
[09:59] <vila> ronny: one last time: I don't know how to do that nor do I have the time to investigate, you obviously know better and are certainly in a better position to propose a patch which can be as little as explaining which commands need to be run when
[10:01] <ronny> vila: python setup.py sdist upload
[10:01] <spiv> ronny: i.e. a patch to our doc/developers/releasing.txt
[10:01] <spiv> Anyway, this really doesn't sound like the cause of your bzrlib.bzrdir problem.
[10:01] <spiv> Can you give more details about that?
[10:03] <vila> ronny: done. test and feedback welcome and for an additional bonuses a merge proposal updating the document spiv mentioned above
[10:03] <spiv> Because there's nothing about grabbing the 2.3b4 tarball rather than the 2.2.2 tarball that seems relevant to that.
[10:05] <ronny> hmm, seems likepip still prefers the latest ones, but i think i can fix that
[10:05] <mgz> I'm curious about that too spiv, but reckoned setuptools was just breaking something else.
[10:07] <mgz> vila: I think one upshot of putting a tarball up there is breaking anyone on windows trying to easy_install bzr (if it worked before, that is)
[10:07] <vila> hmm and this command doesn't seem to include the generated C files, so most likely the result will not be the expected one
[10:07] <vila> nor the docs ones
[10:08] <vila> ronny: and how do we remove this broken tarball now ?
[10:08] <ronny> vila: pypi has a web ui for that
[10:09] <vila> done
[10:10] <mgz> I'm failing to find any documentation on how to actually interface with pypi to upload stuff we want from our build scripts.
[10:10] <vila> the web page allowing removing the tarball seems to allow manual upload too
[10:10] <ronny> mgz: distutils includes a uploader
[10:10] <mgz> no, ronny, no, it doesn't.
[10:10] <mgz> *setuptools* does.
[10:10] <vila> ronny: which produces the bogus behaviour above
[10:11] <mgz> which as vila just found, is broken.
[10:12] <ronny> mgz: distutils includes one for sure, setuptools is not required
[10:14] <mgz> hm, ported across in some version.
[10:15] <ronny> starting with 2.5
[10:17] <vila> ronny: I've update the Download URL at pypi, can you try again ?
[10:17] <vila> s/update/updated/
[10:20] <ronny> pip tries http://launchpad.net/bzr/2.2/2.2.2/+download/bzr-2.2.2.tar.gz, gets a http 404, then grabs the rest of the download list and grabs the latest one
[10:21] <vila> it shouldn't get a 404 since that's the url *all* packagers are using
[10:23] <ronny> it would be appreciated if the redirect target wouldnt trick browsers into display as text
[10:23] <vila> https://edge.launchpad.net/bzr/+download clearly states that 662 people succeeded to download it with this link
[10:25] <vila> ronny: file a bug
[10:26] <vila> ronny: but try to focus on your actual problem, we've been at it for an hour now and you still haven't explained what the problem was about bzrlib.bzrdir
[10:27] <ronny> it missing was in part caused by the venv getting messed up
[10:28] <ronny> i did a messy fox for the build issue, to get it propper i need to kill the problems with grabing specific bzr versions as source tarballs
[10:30] <vila> ronny: does this means updating the Download URL on pypi doesn't address your problem then ?
[10:31] <vila> mgz: does the proper tarball on pypi address your concern about windows people ?
[10:31] <ronny> it should, right now pip/easy_install still select thr wrong one for reasons unknown to me
[10:31] <ronny> (weird stuff only happens for stuff thats not propperly uploaded to pypi)
[10:32] <vila> ronny: we're back to 'does not work' being useless to make progress
[10:33] <ronny> vila: im trying t figure why pip fails to take the download link into account, but i cant exactly give a detailed description i dont have
[10:34] <vila> ronny: right, that's exactly my point: there is nothing we can't fix if we don't know what we do wrong
[10:36] <ronny> vila: im working on the details, but the basics are your tarballs are at locations that are awfully inaccessible for pip/easy_install
[10:36] <vila> s/awfully/standard http but/
[10:39] <vila> ronny: why you insist on getting around packaged versions provided by the OSes you use while not wanting to use a source *branch* despite working with DVCS tools is a bit behind my understanding though...
[10:39] <vila> But that probably explain why you're the first one to report such problems...
[10:40] <vila> ronny: gentoo for example backported a patch from our trunk to the 2.2.2 stable branch which you will never get by working with tarballs
[10:41] <vila> ronny: if you're using python-2.7 (targeted  by the backported patch) you're on your own
[10:45] <vila> mgz: did I mention I uninstalled launchpadlib from the 10.6 babune slave ? Leading to 3 remaining failures
[10:45] <ronny> vila: these day thats the common way to set up isolated python envs for test runs
[10:48] <vila> ronny: GIGO (garbage in, garbage out), if your test inputs are wrong, so do your tests outputs
[10:49] <vila> ronny: if you're interested about how bzr is tested: http://babune.ladeuil.net:24842/
[10:49] <vila> this is a hudson setup that use the bzr trunk on various platforms
[10:58] <ronny> time to drop the bzr variation of my CI i guess
[14:43] <didrocks> hey
[14:44] <didrocks> so, I'm trying to merge between two branches, I have conflicts. (a lot of them). When trying to bzr resolve --take-others --all, I get:
[14:44] <didrocks> bzr: ERROR: Tree transform is malformed [('duplicate id', 'new-74', 'new-1')]
[15:06] <jelmer> didrocks: hi
[15:06] <jelmer> didrocks: I believe there's an open bug about that
[15:06] <vila> didrocks: bzr version ?
[15:07] <vila> jelmer: hey :)
[15:07] <vila> jelmer: remind where I should check in debian to see if bzr-2.3b4 is there ?
[15:07] <vila> s//me/ !
[15:07] <jelmer> vila: Good arvo
[15:08] <jelmer> vila: http://qa.debian.org/bzr
[15:08] <jelmer> sorry, http://packages.qa.debian.org/bzr
[15:08] <jelmer> I haven't packaged/uploaded b4 yet
[15:08] <didrocks> vila: Bazaar (bzr) 2.3b3
[15:08] <didrocks> jelmer: is it fixed in trunk? I can't do the unity release because of it right now
[15:09] <vila> bug #646691
[15:09] <vila> bug #646961
[15:09] <didrocks> I found that weird, right :)
[15:10] <vila> hmm
[15:10] <didrocks> ok, fixed in trunk then
[15:10] <vila> not sure it's the same one but...
[15:10] <didrocks> oh right, doesn't seem
[15:10] <vila> didrocks: where did you get your bzr ? ppa ?
[15:11] <didrocks> vila: lp:~unity-team/nux/nux and lp:~unity-team/nux/packaging
[15:11] <didrocks> vila: you can try without merge-upstream, just merge nux in packaging. We get a whole bunch of conflicts
[15:12] <didrocks> (not sure why btw… It's just a one-line change in most of files)
[15:12] <vila> didrocks: I meant where is your bzr-2.3b3 coming from ? source ? ppa ?
[15:12] <didrocks> I assume there was something with merge-upstream and missing file in tarball
[15:12] <didrocks> vila: oh, from natty
[15:15] <vila> didrocks: #638451
[15:15] <vila> bug #638451
[15:16] <vila> didrocks: more like it no ?
[15:16] <didrocks> vila: exactly :) so I should definitively pull trunk
[15:16] <didrocks> vila: do I have to mess up with PYTHON_LIBRARY path?
[15:16] <vila> didrocks: feedback *highly* appreciated there
[15:17] <vila> didrocks: not sure what you mean, but if you run the right *bzr* script, the right bzrlib should be selected (or file a bug)
[15:17] <didrocks> vila: ok, let's see how it goes
[15:17] <vila> didrocks: if you run from source, don't forget to run 'make' first
[15:18] <vila> didrocks: note that you're using a quite recent addition there that will handle the *text* conflicts by *forcing* the OTHER version (with --take-other)
[15:19] <vila> didrocks: i.e. all changes that could be otherwise merged cleanly are thrown away
[15:19] <jelmer> didrocks: alternatively you can use the nightly builds
[15:19] <vila> didrocks: make sure you read 'bzr help conflict-types' there
[15:20] <vila> jelmer: I read the emails related to the failures, but not always the associated logs, is there a place which summarizes the status of the builds ?
[15:21] <jelmer> vila: https://code.launchpad.net/~bzr/+recipes has a list of all the recipes, each recipe has an overview of the resulting builds
[15:21] <vila> jelmer: ha, 2.3b4 not yet packaged, ok
[15:21] <jelmer> vila: there's also https://code.launchpad.net/~bzr/+archive/daily/+packages
[15:23] <vila> jelmer: thanks, I keep forgetting +packages
[15:23] <vila> meh, didrocks, don't leave without feedback !!!
[15:23] <vila> . o O (reboot did he ?)
[15:30] <vila> jelmer: should https://code.launchpad.net/~bzr/+recipe/bzr-daily mention beta5 instead of beta4 ?
[15:31] <jelmer> vila: no, as we're using "beta4+bzr" - note the + which means this version comes /after/ beta4
[15:31] <vila> jelmer: %-} ooook
[15:31] <jelmer> vila: Alternatively we could use beta5~bzr if we knew we were going to do a beta5
[15:31] <jelmer> (~ sorts before empty string, + sorts after empty string)
[15:32] <vila> right, so you did this change at freeze or at release time ?
[15:32] <jelmer> vila: yep
[15:32] <vila> a or b: yes... :D
[15:33] <vila> any ?
[15:33] <vila> yeah, any, sorry, thinking aloud ;D
[15:34] <vila> haaa, he's back :D
[15:34] <vila> didrocks: so ?
[15:34] <didrocks> vila: sorry, seeems that I was disconnected :/
[15:34] <didrocks> 16:25:42 didrocks | vila: are you sure it's taking the right bzrlib? like if I try ~/sandbox/bzr/bzr resolve --all --take-other (~/sandbox/bzr is where I branched bzr from)
[15:34] <didrocks> 16:26:23 didrocks | oh right   bzrlib: /home/didrocks/sandbox/bzr/bzrlib
[15:34] <didrocks> 16:26:32 didrocks | so ok… it's not fixed :/
[15:34] <didrocks> I have 2.3.0dev5 from --version
[15:35] <vila> file a bug
[15:36] <didrocks> vila: what do you need as needed info in addition to the branch and the error output?
[15:36] <jelmer> vila: Sorry :-) I changed it after the release
[15:36] <vila> didrocks: reproducing recipe
[15:36] <didrocks> vila: can I workaround in some way (downgrade or such)? I think that I can't delay the unity release anymore :)
[15:37] <vila> didrocks: try resolving in several steps
[15:37] <didrocks> there are 50 conflicts… will write a shell script then
[15:38] <vila> didrocks: meh, is that a private branch ?
[15:38] <didrocks> vila: it's not, you can't check it out?
[15:38] <vila> no, got not a branch
[15:39] <didrocks> let me check, I maybe made a typo
[15:39] <vila> s!/nux!/trunk! ?
[15:39] <didrocks> vila: oh sorry, the trunk is at trunk, right
[15:40] <didrocks> or lp:nux
[15:40] <vila> yup, better
[15:40] <didrocks> the packaging branch is good :)
[15:41] <vila> ouch, 62 conflict
[15:41] <vila> ouch, 62 conflicts
[15:41] <didrocks> vila: yeah, I'm not sure why there are there… upstream just changed the email in every files
[15:41] <didrocks> vila: so I think something happened between bzr merge-upstream / the tarball / trunk
[15:42] <didrocks> well, we try to ship every files in the tarball to avoid conflicts as we had at some point
[15:42] <vila> no, there are a bunch of content conflicts which means different file-ids probably so parallel import ?
[15:42] <didrocks> vila: weird, bzr merge-upstream did that?
[15:42] <vila> no idea
[15:42] <didrocks> like it added other file ids?
[15:46] <didrocks> filed as bug #688101
[15:47] <vila> didrocks: I'm digging the history of both branches
[15:47] <didrocks> vila: thanks, it will be way easier for you I guess to find what happened than I ;)
[15:48] <vila> didrocks: hopefully :-}
[15:49] <didrocks> (I was the CSM administrator in my previous company, so I digged a lot in that to support developers, I don't want to do that anymore :p)
[15:49] <vila> didrocks: so far the only suspicious bit is revno 138 (New upstream release _ cherry pick latest commit)
[15:50] <vila> didrocks: di you change your workflow somehow between now and then ?
[15:51] <didrocks> vila: I've already done that in the past for unity itself. I just bzr merge from trunk what's interested
[15:51] <didrocks> so it should pick upstream file-id if there are new, isn't it?
[15:51] <vila> didrocks:  if you started your packaging branch from trunk ,yes
[15:52] <didrocks> vila: right, it is started from trunk
[15:52] <vila> and that seems to be the case (revno 113)
[15:52] <didrocks> that's all the benefit of merge-upstream and this workflow, cherry-picks :)
[15:52] <didrocks> (no more debian/patches/…)
[15:53] <didrocks> and it went well in the past in bamf/unity/dee… (I'm used to do that since May I would say)
[15:56] <vila> right, so comparing the inventories on both tips, sounds fine, all common files have the same file-ids, but it seems the conflicting ones are new in trunk... weird
[15:58] <didrocks> vila: not only the new ones (it can't add the directory it seems), but also ones where the email name was changed, isn't it?
[16:04] <vila> didrocks: hmm, doing 'bzr qlog trunk packaging' shows that you *never* merged since 0.9.1
[16:05] <vila> no wrong
[16:05] <didrocks> vila: is that what bzr log trunk packaging tells me?
[16:06] <didrocks> bzr: ERROR: Path "/home/didrocks/work/unity/nux/ubuntu" is not a child of path "/home/didrocks/work/unity/nux/nux"
[16:06] <vila> of course you never merge packaging in trunk, you do the opposite, sorry
[16:06] <didrocks> right :)
[16:06] <vila> *q*log
[16:06] <didrocks> didn't know that command, it's coming from which package/plugin?
[16:06] <vila> qbzr
[16:07] <didrocks> no gtk equivalent? ;)
[16:07] <vila> best way to look at branch histories (especially to see how they interact)
[16:07] <vila> bzr viz, but I don't remember if it accepts multiple branches
[16:07] <didrocks> I've always used with once, let's see how it work with 2
[16:08] <vila> well, yes it does, but it still lacks the ability to hide merges
[16:08] <vila> a good chunk of the qlog backend is in a mp for bzr, once it lands, viz could reuse it
[16:08] <didrocks> oh nice, yeah, it's easier to see the history this way
[16:13] <vila> didrocks: eeerk, never ever use 'resolve --all' all this does is deleting the conflicts file
[16:13] <vila> didrocks: on the other hand, I just did that and that may be shortcut you're after...
[16:13] <didrocks> vila: well, I haven't done that. I just noticed it this time
[16:14] <didrocks> vila: on bzr resolve --all --take-other should take all .OTHER, isn't it?
[16:14] <vila> didrocks: no, that's a bug, --all and --take-other shouldn't be allowed together
[16:14] <didrocks> vila: oh ok :)
[16:15] <vila> didrocks: try 'bzr resolve --all' alone and look at the result but don't commit !
[16:15] <fullermd> Yeah, 'resolve --all' is a "mark that things are done", "--take-whatever" is a "do things".  Kinda a wart that one command does both.
[16:15] <didrocks> fullermd: oh right!
[16:15] <didrocks> vila: yeah, confirmed
[16:15] <vila> didrocks: if you're happy with the result: do 'bzr revert --forget-merges' and then and only then commit
[16:16] <vila> didrocks: if you weren't in a hurry I won't recommend that *at all*
[16:17] <vila> ha, bah, no good, bunch of .OTHER all over the place
[16:17] <didrocks> vila: hum, so what should I use? bzr merge && bzr revert --forget-merges? but that will prevent me taking new upstream version, isn't it?
[16:17] <vila> didrocks: no, that would be a huge cherry-pick
[16:17] <vila> didrocks: but forget it, bad idea
[16:18] <didrocks> vila: ok, I still have some time :)
[16:19] <vila> jam: ping
[16:20] <vila> jam: I don't have news from gary and we still haven't installers for bzr-2.2.2, can you help ?
[16:26] <LeoNerd> bzr add   silently adds container directories. This is helpful.   bzr mv    doesn't add new path containers, gets upset. Possibly it should?
[16:26] <LeoNerd> Well, not silently. Automatically.
[16:27] <LeoNerd> Strikes me if 'add' does it, so should 'mv'
[16:28] <fullermd> Devil's advocate: You call mv to move a file from one place to another; having it also add stuff is unexpected.
[16:28] <LeoNerd> Devil's Counter-advocate; You call add to include one new file; having it also add other stuff is unexpected.
[16:29] <vila> didrocks: ok, the problems started at revno 139 in trunk
[16:29] <LeoNerd> Or make it non-default?  bzr mv --add-parents oldname newname
[16:29] <vila> LeoNerd, fullermd: very good, put that in a bug !
[16:29] <LeoNerd> Then people who want it can just alias
[16:29] <didrocks> vila: looking
[16:29] <fullermd> Perhaps, but it's at worst "do more than expected", not "do something else too".  I'd be shocked at 'add' moving stuff around; perhaps less so, but still somewhat, at 'mv' adding stuff.
[16:30] <fullermd> We're not ready for a bug, we're still rehearsing!
[16:30] <LeoNerd> Well.. currently it complains and dies
[16:30]  * Torne is more surprised by mv failing just because he didn't add the directory
[16:31] <didrocks> vila: weird, it's modified but the whole file content is removed and then added
[16:31] <didrocks> vila: oh "fix end of line" -> \r\n -> \n ?
[16:32] <vila> yeah, so the file-ids shouldn't be modified then
[16:33] <didrocks> right
[16:34] <Torne> fullermd: bzr add adds the parent directories because otherwise the operation would have to fail, and failing an operation with a perfectly logical intent would be silly. I don't think that mv is different just because "mv" and "add" are different commands.
[16:36] <jam> hi vila, I might be able to dig something out, but I honestly haven't worked closely with Garyvdm on the last couple of builds
[16:36] <vila> jam: :-/ do you know if he at least pushed its last related branches ?
[16:37] <jam> he should have, but no, I don't know that for sure
[16:56] <didrocks> vila: so, do you have any suggestion? I can drop the packaging branch and setup one again… but that will be a pity :/
[16:57] <vila> didrocks: whatever works for you :-/ I'm still digging and won't have a fix shortly sry :-/
[16:57] <didrocks> vila: ok, can you keep the branch somewhere? I'll surely --overwrite
[16:57] <vila> didrocks: but my feeling is that the prolem is in merge not in resolve, the later being a symptom
[16:58] <vila> didrocks: I have both branches there
[16:58] <didrocks> vila: ok, I'll maybe scratch them then. Hope that the use case can be solvable for you :)
[16:59] <vila> me too
[17:21] <vila> didrocks: that's the first time you're using 'bzr resolve --take-other' right ?
[17:22] <vila> didrocks: there seems to be mutiple bugs there when the same file is involved in several conflicts
[17:23] <vila> didrocks: the workaround seem to be to resolve the conflicts manually
[17:23] <didrocks> vila: I never used it before, right
[17:23] <vila> didrocks: I'm halfway
[17:23] <vila> didrocks: ha good, so I think it will not have give you the expected result
[17:23] <vila> didrocks: is  NuxGraphics/GraphicsDisplayWin.h windows specific ?
[17:24] <didrocks> vila: yeah, Nux is multi-plateform
[17:24] <vila> didrocks: and you deleted it from the packaging branch. Using --take-other means take it again
[17:25] <didrocks> vila: no, it was not disted in make dist tarball
[17:25] <didrocks> vila: so bzr merge-upstream deleted it
[17:26] <vila> didrocks: meh, I didn't use merge-upstream
[17:29] <didrocks> vila: I mean, that's why some files were deleted there in some commits
[17:31] <vila> didrocks: right, anyway, that's why you have Content Conflicts (one side deleted, the other modified)
[17:32] <didrocks> vila: yes, just a pity there is no way to solve that in one command :)
[17:32] <vila> didrocks: indeed
[17:33] <vila> didrocks: but your specific use case here is tricky, you want a mix of --take-this and --take-other
[17:34] <vila> well, not even, you don't want --take-other, you want to keep your deletions and cleanly merge the rest I think
[17:34] <didrocks> vila: exactly :/ in any case, there are some workflow issues with merge-upstream for such cases
[17:34] <didrocks> right
[17:34] <vila> didrocks: any way, summary:
[17:35] <vila> - thanks for the bug, I should fix it,
[17:35] <vila> - --take-other is not what you want: you need to resolve them in smaller chunks but not at all once, one by one in the worst case
[17:36] <vila> - merging more often will help, as usual :D
[17:36] <didrocks> vila: I'm merging once a week :)
[17:37] <didrocks> vila: but yeah, this use-case is an issue with merge-upstream workflow
[17:37] <didrocks> at least, we know why there are conflicts, which is good
[17:41] <vila> didrocks: well, more often can also mean merging less revisions (which is what I'm doing)
[17:45] <vila> didrocks: I'm lost now, revno 144 produces 58 conflicts and I have no clue about how to resolve them
[17:45] <didrocks> vila: right, but with 25 upstream branch without making a release… once a week is already a lot :)
[17:46] <vila> didrocks: of course, that's a bug, I'm only talking about workarounds here, the last item had a smiley ;D
[17:46] <didrocks> right :)
[17:47] <vila> and when I say one.. probably several
[17:50] <vila> didrocks: bactracking to your ', it was not disted in make dist tarball' where is this defined ?
[17:59] <didrocks> vila: sorry, I'm currently on the unity release, hard to be responsive :)
[17:59] <vila> didrocks: no worries, am I right if I guess from Mafile.am files ?
[17:59] <didrocks> vila: this is definied in the dist target of all the Makefile.am
[17:59] <didrocks> yeah
[17:59] <didrocks> (there are multiple)
[18:00] <vila> to yeah, this is taking shape, you're suddenly confronted with a bunch of conflicts (deleted/modified), so what you really want is some way to attach merge options to files or directories
[18:01] <vila> and this became more obvious *because* a change was made to *all* files
[20:56] <poolie> hi jam
[22:10] <spiv> Good morning.
[23:09] <poolie> hi spiv


[09:03] <Aleksa> Merhaba! I was trying to find some turkish channel on this freenode server so I tried #turkish, #turkce and even #ubuntu-tr-offtopic. These channels do not exist. May I ask my question here? It's related to turkish language.
[09:03] <Aleksa> What exactly does 'aman zaman' mean?


[00:11] <chrisccoulson> fta - this is a reproducer for the chromium/breakpad issue btw - http://paste.ubuntu.com/580859/
[02:51] <micahg> fta: chromium seems to work fine on natty
[03:04] <LLStarks> chrisccoulson, is the search popover supposed to cover the status popover?
[03:05] <LLStarks> *statusbar
[03:07] <LLStarks> nvm
[15:14] <fta> micahg, [03:51] <micahg> fta: chromium seems to work fine on natty <= uh? did you expect it not to? I need more context..
[15:14] <fta> asac, ping
[15:24] <asac> fta: hoh
[15:24] <fta> how are you?
[15:24] <fta> any update on the arm board(s)?
[15:26] <asac> sorry, that dropped off my busy schedule ... /me hits himself
[15:26] <asac> let me add that to next week tech lead agenda
[15:26] <asac> monday i will know more
[15:27] <asac> done
[15:27] <asac> will not be forgotten
[15:27] <asac> https://wiki.linaro.org/EngineeringUnits/Management/Meetings/2011-03-21
[15:36] <fta> bug 735877
[15:36] <ubot2> Launchpad bug 735877 in chromium-browser "Illegal instruction in chromium on startup on armel" [Undecided,New] https://launchpad.net/bugs/735877
[15:36] <fta> asac, ^^
[15:39] <asac> right
[15:39] <asac> i had folks staring on this today
[15:39] <asac> fta: is that a patch of mine?
[15:40] <asac> otherwise he is probably right ... vfpv3-d16
[15:40] <fta> nope, it's from upstream
[15:40] <fta> no idea what that vfpv3-d16 is, and how i should know about it. is it documented somewhere?
[15:40] <asac> hmm
[15:45] <davidgiluk> fta: Hi
[15:45] <asac> fta: meet davidgiluk
[15:45] <asac> he wants to help you discuss upstream if needed ;)
[15:45] <fta> hi
[15:45] <davidgiluk> http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?view=diff&r1=40698&r2=40699
[15:46] <asac> so i guess question is if we want to make the point upstream to use -d16 for maximum compatibility
[15:46] <asac> or if we just want to set this for ubuntu
[15:46] <asac> https://wiki.ubuntu.com/ARM/Thumb2
[15:46] <asac> this is still the default set of flags that we expect
[15:46] <asac> was decided to be maximum compatible while getting most benefit of most armv7
[15:47] <davidgiluk> fta: So my understanding is that there are 2 semi-separate chip features; Neon, and the number of vector registers;   some chips have no neon, and have only 16 vector registers - and that's what we default to
[15:47] <asac> so in ubuntu - unless there is runtime detection for things like neon - -mfpu=vfpv3-d16  is the default we have to use
[15:48] <fta> davidgiluk, that particular changeset is not the real change, it just moved the flag from a hardcoded value to a variable, which i can change in my package
[15:49] <davidgiluk> fta: Hmm true
[15:49] <fta> so it seems i need to pass arm_fpu=vfpv3-d16 too now
[15:49] <davidgiluk> fta: Yes
[15:49] <davidgiluk> fta: What concerns me is why has this changed - or has it always been brokwn?
[15:49] <davidgiluk> e
[15:49] <fta> i will discuss with upstream. they mostly want arm for chrome-os, not sure what h/w they target
[15:50] <davidgiluk> fta: The Tegra2 chip is the case it broke for Ramana which is non-neon and as I understand it d16
[15:50] <fta> it didn't change in a while, but i used to have a bogus test in my packaging, leading to armv7=0
[15:50] <fta> i fixed it in ch10
[15:50] <davidgiluk> fta: IMHO it would be best not to pass any flag at all and leave it to the compiler defaults
[15:51] <fta> no, the chromium build system overrides most system defaults
[15:51] <davidgiluk> ok
[15:51] <ramana> fta: well then in that case we (or they) have to be building for the lowest common denominator which is vfpv3-d16
[15:52] <ramana> I believe that's the reason why we ended defaulting to vfpv3-d16
[15:52] <asac> right
[15:52] <asac> thats why we do that in ubuntu
[15:52] <asac> similar to overriding the neon=1 default hat chromium has
[15:52] <davidgiluk> but has this ever worked on the ac100?
[15:52] <asac> its interesting ... seems noone cared even though we got bashed that our qt crashed on ac100 ;)
[15:53] <fta> most probably, it's just that i'm not well aware of those arm specificities. ubuntu  vs debian vs chrome-os, all have different targets in mind
[15:53] <asac> and we had to backout NEON
[15:53] <ramana> davidgiluk: well michaelh1 recommended I tried chromium-browser on my ac100 over firefox.
[15:53] <asac> fta: right ... just add vfpv3-d16 for now. then all is fine
[15:53] <ramana> so I gave that a shot and that's how it showed up
[15:53] <asac> we are working on runtime detecting neon for chromium/skia
[15:53] <ramana> so I think he's got it working .
[15:53] <asac> upstream is not responsive though :(
[15:54] <davidgiluk> ramana: OK
[15:54] <fta> ok, i'm fine with arm_fpu=vfpv3-d16
[15:54] <asac> fta: thanks!!
[15:54] <fta> will land that in the next stable update
[15:54] <ramana> with an older package ofcourse.
[15:54] <ramana> fta: Thanks.
[15:56] <davidgiluk> fta: Can you take bug 735877 then?
[15:56] <ubot2> Launchpad bug 735877 in chromium-browser "Illegal instruction in chromium on startup on armel" [Undecided,New] https://launchpad.net/bugs/735877
[15:56] <fta> so by default, i'll have: arm_thumb=1 arm_neon=0 arm_fpu=vfpv3-d16.  and armv7=1 only for maverick onward
[15:56] <fta> is that correct?
[15:57] <davidgiluk> yeh I think so - I don't know the pre-maverick world
[16:14] <fta> davidgiluk, ramana, asac: here is when the vfpv3 value 1st appeared: http://codereview.chromium.org/660067
[16:18] <davidgiluk> fta: Looking at ffmpeg it has a configure flag you can pass that would cause it to pass a -mfpu=vfpv3 but it doesn't look like the default
[16:19] <fta> (it's an old patch)
[18:17] <micahg> did i connect twice or once?
[18:19] <jdstrand> micahg:
[18:19] <jdstrand> 13:07 -!- micahg [~quassel@ubuntu/member/micahg] has joined #ubuntu-mozillateam
[18:19] <jdstrand> 13:14 -!- micahg [~quassel@ubuntu/member/micahg] has quit [Remote host closed  the connection]
[18:19] <jdstrand> 13:17 -!- micahg [~micahg@ubuntu/member/micahg] has joined #ubuntu-mozillateam
[19:51] <fta> micahg, would you be able to help with the chromium bugs? because i'm really bad with this due to lack of time. most should go upstream anyway
[19:55] <micahg> fta, sure, stuff related to regressions I can definitely help with idr if I have an upstream account
[19:56] <micahg> fta, where's the upstream tracker again?
[19:56] <fta> http://code.google.com/p/chromium/issues/list
[20:05] <micahg> fta, is #chromium a good place for me to idle/ask questions as well?
[20:07] <fta> micahg, sure, but it's purely a dev channel, so they hate end user questions, which should go to the support channels, cf /topic
[20:07] <micahg> fta, ok
[20:21] <chrisccoulson> heh, this looks a bit like the chrome release schedule: http://people.mozilla.com/~sayrer/2011/temp/process.html
[20:21] <chrisccoulson> "This proposal makes security updates occur along with Firefox releases, meaning we'll no longer be maintaining old branches."
[20:21] <chrisccoulson> oh, fudge
[20:22] <chrisccoulson> i guess we're screwed with all browsers now ;)
[20:22] <micahg> :(
[20:22]  * micahg needs to talk to upstream
[20:23] <chrisccoulson> fta - you have a separate nightly PPA for each channel of chromium don't you?
[20:23] <chrisccoulson> and you don't make them parallel installable?
[20:24] <fta> correct
[20:24] <fta> http://people.ubuntu.com/~fta/ppa-dashboard/chromium-daily.html
[20:24] <chrisccoulson> fta - i'm wondering whether that might be a better approach for firefox too, given the proposals for the release process
[20:24] <fta> i should not have used "daily" in the name
[20:24] <chrisccoulson> as there's going to what looks like 4 active channels
[20:30] <fta> chrisccoulson, looking at chromium, most users will end up using either the stable builds or the dailies, not much users in between
[20:41] <fta> jcastro, is the scroll wheel supposed to work in the dash now?
[20:41] <fta> i had it working a few days ago at work, but never at home
[20:41] <fta> similar setups
[20:41] <jcastro> I am not sure
[20:41] <jcastro> ah yeah
[20:41] <jcastro> it works for me
[20:44] <jcastro> fta: new compiz upload, see if this one helps
[20:44] <fta> jcastro, also is it possible to filter out the "Recents" in the dash? mine is filled with stuff i don't need in there, like mp3.. i have rhythmbox playing all day long
[20:44] <jcastro> fta: there's a blacklist thing you can do in zeitgeist
[20:45] <fta> where? how?
[20:45] <jcastro> however I've not looked into it, I think you want to search for blacklisting, zeitgeist, and gnome-activity-journal
[20:45] <jcastro> seiflofty on #ayatana can sort you out probably
[20:55] <fta> upgrading...
[20:55] <fta> jcastro, any update for the ch webapps since yesterday?
[20:55] <jcastro> fta: trevino's going to look at it on friday, he's on holiday right now
[20:58] <fta> k
[23:30] <fta> jdstrand, [ 9012.547609] type=1400 audit(1300318178.116:20): apparmor="DENIED" operation="file_mmap" parent=4945 profile="/usr/bin/evince-thumbnailer" name="/usr/lib/i386-linux-gnu/gconv/UTF-16.so" pid=4946 comm="evince-thumbnai" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0


[23:55] <valorie> did anyone make it to the flavors meeting?
[23:55] <valorie> I was otherwise occupied