[09:30] <teddy-dbear> Morning peoples
[18:33] <pleia2> I know it's a bit of a ghost town here these days, but our gallery stopped working a long time ago, so I've moved all the images here: https://ubuntupennsylvania.org/images/albums/
[18:33] <pleia2> this came up because, in case you haven't heard the news, jedijf passed away unexpectedly on Tuesday night :'(
[18:33] <pleia2> so I've been looking for photos
[18:46] <pleia2> https://ubuntupennsylvania.org/images/albums/jedijf/


[14:58] <bdmurray> o/
[14:58] <jawn-smith> o/
[14:59] <sil2100> o/
[14:59] <ginggs> o/
[14:59] <slyon> o/
[14:59] <mclemenceau> o/
[14:59] <dbungert> o/
[15:00] <bdmurray> #startmeeting Weekly Ubuntu Foundations team
[15:00] <meetingology> Meeting started at 15:00:19 UTC.  The chair is bdmurray.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:00] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:00] <bdmurray> #topic Lightning Round
[15:00] <bdmurray> echo $(shuf -e vorlon bdmurray doko sil2100 mwhudson juliank waveform slyon jawn-smith dbungert xypron ginggs schopin)
[15:00] <mclemenceau> o/
[15:00] <bdmurray> waveform mwhudson schopin doko sil2100 xypron ginggs dbungert jawn-smith bdmurray vorlon juliank slyon
[15:01] <schopin> o/
[15:01] <waveform> * Testing focal .3 daily test images on Pi models (wifi working on first boot \o/ ... but iffy on arm64?)
[15:01] <waveform> * Still testing kernel fix for USB storage issues on Pi (LP: #1930629) (USB3 appears fixed; USB2 isn't; possibly caddy related?)
[15:01] <waveform> * Working on ubuntu-release-upgrader quirk for migration away from u-boot (LP: #1936401)
[15:01] <waveform> * Some pibootctl work related to this ^^
[15:01] <waveform> * Sponsored u-boot for jawn-smith (LP: #1934791, LP: #1923162)
[15:01] <waveform> * More work on Sense HAT packaging for upstream
[15:01] <waveform> * Pi meetings
[15:01] <waveform> * Marked take-home test
[15:01] <waveform> (done)
[15:02] <bdmurray> schopin:
[15:02] <schopin> * netplan: carried PRs #217 & #218 across the merging line (LP #1901836)
[15:02] <schopin> * pam: use needrestart on upgrade instead of self-written logic (LP #1935972)
[15:02] <schopin>   + uploaded, in -proposed
[15:02] <schopin> * s390-tools: new upstream version 2.17.0 (LP #1934988)
[15:02] <schopin>   + uploaded, in -proposed
[15:02] <schopin> * openssl: started preparing an openssl3 package in a PPA
[15:02] <schopin> (done)
[15:03] <bdmurray> doko:
[15:03] <doko> v
[15:03] <doko> - i386 fun after the binutils updated, cross build related
[15:03] <doko> - GCC updates
[15:03] <doko> - openjdk discussions with product management
[15:03] <doko> - binutils and gdb release candates
[15:03] <doko> (done)
[15:04] <sil2100> - Very short week due to holidays
[15:04] <sil2100> - SRU reviews and releases
[15:04] <sil2100> - Ubuntu Core meeitngs
[15:04] <sil2100> - TB meeting
[15:04] <sil2100>   * Started drafting the OEM archive summary
[15:04] <sil2100> - Grading tests
[15:04] <sil2100> - 20.04.3 status meeting
[15:04] <sil2100> - More looking into the simplestreams spec
[15:04] <sil2100> - Preparing a fix and sponsoring libmbim bits for the HWE team (libqmi done by Brian I think!)
[15:04] <sil2100> - ESM britney:
[15:04] <sil2100>   * Finally got everything (including the firewall) set up to get esm-excuses tested
[15:04] <sil2100>   * Fixed some bugs, got things working
[15:04] <sil2100>   * Switched to ESM PPAs for one more experimental run, still waiting for staging tests to run
[15:04] <sil2100> - Filling in some cards in the backlog for UC and WSL cdimage work
[15:04] <sil2100> - Looking into core18 builds stuck in moderation, suspicious changes seen there
[15:04] <sil2100> (done)
[15:04] <bdmurray> xypron:
[15:06] <xypron> #1936170 blender: building on RISC-V fails
[15:06] <xypron> https://github.com/sergeyvfx/libNumaAPI/pull/3 - accepted
[15:06] <xypron> https://developer.blender.org/D11910
[15:06] <xypron> Try building V8 on RISC-V
[15:06] <xypron> Patches
[15:06] <xypron> https://chromium-review.googlesource.com/c/v8/v8/+/3024338
[15:06] <xypron> https://chromium-review.googlesource.com/c/v8/v8/+/3024340
[15:06] <xypron> https://chromium-review.googlesource.com/c/v8/v8/+/3026704
[15:06] <xypron> Upstream bugs created
[15:06] <xypron> https://bugs.chromium.org/p/v8/issues/detail?id=11975
[15:06] <xypron> eom
[15:06] <bdmurray> ginggs:
[15:07] <ginggs> * looked further at fuse2-fuse3 transition, sent an update to ubuntu-devel
[15:07] <ginggs> * looked at switching s390-tools to fuse3, sent (untested) patch upstream
[15:07] <ginggs> * now testing grub2 patch
[15:08] <ginggs> * another failed attempt at canonistack
[15:08] <ginggs> (done)
[15:08] <dbungert> * ubuntu-desktop-installer vs subiquity - more integration issues.  Subiquity
[15:08] <dbungert> was wanting to locate resource files relative to the directory specified by
[15:08] <dbungert> SNAP, but that got weird with the ubuntu-desktop-installer snap, and worse
[15:08] <dbungert> curtin was doing the same thing but expecting a different value.  Work thru
[15:08] <dbungert> plan that made curtin and subiquity happy, in both the server and desktop
[15:08] <dbungert> cases, which mw_hudson improved upon further.  Also, curtin couldn't find the
[15:08] <dbungert> right version of the python executable, so point it to the correct one, again
[15:08] <dbungert> by environment variable.  Working thru these fixed 3 integration issues
[15:08] <dbungert> total, which was enough to get a u-d-i snap that images to disk.  Gave
[15:08] <dbungert> suggestions on steps to finish the install.
[15:08] <dbungert> Ubuntu-desktop-installer can now image a device!
[15:08] <dbungert> * subiquity - CI failed due to some new timezones, so change the CI check to be
[15:08] <dbungert> robust against a timezone list that can change over time
[15:08] <dbungert> * LP: #1821412 - fix X11 version of this problem.  Wayland has additional fixes
[15:08] <dbungert> required.  Pending MP review.
[15:08] <cpaelzer> ginggs: if there is no response and you think you need one of our ibm-nudge-people to help pushing for s390x-tools then ping fheimes internally
[15:08] <dbungert> https://code.launchpad.net/~dbungert/update-notifier/+git/update-notifier/+merge/405628
[15:08] <dbungert> * LP: #1936310 - fix dryrun escape, looking at further feedback from u-d-i
[15:08] <dbungert> (done)
[15:08] <jawn-smith> * Investigate the golang side of LP: #1935063, resulting in https://github.com/golang/go/issues/47100
[15:08] <jawn-smith> * LP: #1927078 we all agreed on requirements, so I implemented them
[15:08] <jawn-smith>     * Also did SRU's for focal and hirsute - awaiting verification
[15:08] <jawn-smith> * RISC-V:
[15:08] <jawn-smith>     * u-boot and u-boot menu have landed in focal-proposed
[15:08] <jawn-smith>     * With these changes, unmatched focal images should boot in qemu. Kernel update still needed for hardware
[15:08] <jawn-smith>     * Working on SRU verification and testing u-boot on all pi hardware possible
[15:08] <jawn-smith> * Re-write ubuntu-image in go
[15:09] <jawn-smith>     * Pushed new commits to make state machine more modular/flexible
[15:09] <jawn-smith>     * Tests not implemented yet for new state machine, and old tests are broken
[15:09] <jawn-smith>     * Will fix tests if sil2100 agrees with implementation
[15:09] <jawn-smith> * Interviews
[15:09] <jawn-smith> [done]
[15:09] <sil2100> \o/
[15:09] <bdmurray> worked on running bionic version of the Error Tracker in PS5
[15:09] <bdmurray> special sru review of modemmanager et al, systemd
[15:09] <bdmurray> updated git branch of u-r-u for hirsute w/ autopkgtest fixes
[15:09] <bdmurray> resurrected an ubuntu-archive-tools MP from 2012 (updated and tested)
[15:09] <bdmurray> playing / modifying an old ubuntu-archive-tools MP w/ bileto diff support
[15:09] <sil2100> jawn-smith: \o/ will look at it ASAP after the meeting
[15:09] <bdmurray> uploaded hirsute SRU for LP: #1916651
[15:09] <bdmurray> built and uploaded a new Intel IoT image
[15:09] <bdmurray> investigation into usrmerge and some bugs associated with it
[15:09] <bdmurray> painting a bike shed
[15:09] <bdmurray> sponsored pam for schopin
[15:09] <bdmurray> ✔ done
[15:10] <bdmurray> juliank:
[15:10] <juliank> * sponsored networkd-dispatcher to Debian
[15:10] <juliank> * worked on apt support for retry back-off
[15:10] <juliank> * autopkgtest-cloud: multiple workers: implemented a rabbitmq-based distributed mutex to use for coordinating image building
[15:10] <juliank> * uploading shim 15.4-0ubuntu7, currently arm64 signing tarball does not seem to appear to builders
[15:10] <juliank> (done)
[15:10] <slyon> - Interviews & Take-home tests
[15:10] <slyon> - Some systemd vs LXD vs network-manager investigation
[15:10] <slyon>   * prepared netplan 0.102-0ubuntu6 upload, to mitigate the problem
[15:10] <slyon>   * reported NetworkManager regression LP: #1936312
[15:10] <slyon> - Analyzing systemd cgroup v2 failures in Bileto
[15:10] <slyon>   * https://bileto.ubuntu.com/excuses/4602/impish.html
[15:10] <slyon> - Sponsored shadow for jawn-smith, bug #1927078
[15:10] <slyon>   * Impish, Hirsute, Focal
[15:11] <slyon> - Sponsored s390-tools & s390-tools-signed for schopin, bug #1934988
[15:11] <slyon>   * Needs AA queue review for impish/NEW
[15:11] <slyon> - Fixed networkd-dispatcher + SRU (HH/FF) + Debian + upstream, bug #1884248
[15:11] <slyon> - Reported generic accessibility problem of canonical websites:
[15:11] <slyon>   * https://github.com/canonical-web-and-design/cookie-policy/pull/123
[15:11] <slyon> [15:11] <slyon> - Review & merged gateway warning for schopin, bug #1901836, PR#217
[15:11] <slyon> - some discussions around "gateway" consolidation schema, PR #216
[15:11] <slyon> (done)
[15:11] <pleia2> ginggs: do you have a link to that s390-tools patch?
[15:12] <bdmurray> are there any other questions on status?
[15:13] <ginggs> pleia2: https://github.com/ibm-s390-linux/s390-tools/pull/117
[15:13] <pleia2> ginggs: thanks
[15:14] <bdmurray> juliank: there's a double upload of shim-signed in the focal queue. Is there one that you prefer?
[15:14] <juliank> bdmurray: the first one misses the 1.40.5 entry and should go away
[15:15] <bdmurray> sil2100: Could you merge this? https://code.launchpad.net/~3v1n0/ubuntu-archive-tools/sru-review-bileto-support/+merge/364193
[15:16] <sil2100> o/
[15:16] <sil2100> Oh man, this thing
[15:16] <bdmurray> It works great
[15:17] <bdmurray> #topic Release Incoming Bugs
[15:17] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ii-incoming-bug-tasks.html#foundations-bugs
[15:17] <sil2100> Okay, I'll merge it since it's better than nothing, I didn't originally like it that much since I prefered us to support diffing all syncs
[15:17] <bdmurray> bug 1935659
[15:18] <juliank> this was carded already
[15:18] <mclemenceau> this one was discovered during ginggs fuse3 transition review
[15:18] <bdmurray> okay, I'll target it
[15:19] <bdmurray> bug 1935666
[15:20] <sil2100> ls
[15:20] <sil2100> ...wrong terminal
[15:21] <bdmurray> let's go ahead and target that and card it
[15:21] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-hh-incoming-bug-tasks.html
[15:21] <bdmurray> empty
[15:21] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html
[15:21] <bdmurray> also nothing for us!
[15:22] <bdmurray> #topic Team proposed-migration report
[15:22] <bdmurray> #link http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:24] <bdmurray> I believe openldap is still blocked by desktop stuff
[15:24] <bdmurray> slyon: what is going on with netplan.io?
[15:25] <doko> wasn't ceph blocking?
[15:25] <dbungert> FYI this was said in #ubuntu-devel
[15:25] <slyon> its a network-manager thing, I opened an update-excuse bug about it today
[15:25] <dbungert> 09:07 <sergiodj> seb128: FWIW openldap has been blocked waiting on gnome-shell to become installable again; that's why it's still in -proposed :(
[15:25] <slyon> my latest netplan upload should mitigate that
[15:25] <slyon> (but it still affects systemd)
[15:25] <dbungert> and it says update-manager is blocking gnome-shell
[15:25] <bdmurray> Okay, I'll fix update-manager
[15:25] <doko> and apache2
[15:26] <sergiodj> doko: ceph was blocking openldap, but the issue has been resolved IIUC
[15:26] <sergiodj> doko: bryce is on the apache2 failures, I think they're just flaky
[15:26] <doko> ahh, ceph was in NEW. just accepted
[15:27] <sergiodj> there was a FTBFS on ceph amd64 as well
[15:28] <bdmurray> was anybody looking at aptdaemon? juliank?
[15:28] <juliank> no, but latest retry fixed that
[15:29] <bdmurray> okay
[15:30] <bdmurray> I think that's everything then. Are there any other packages to look at doko?
[15:30] <doko> pam?
[15:30] <doko> casper?
[15:30] <doko> systemd?
[15:31] <bdmurray> schopin and I'll look at pam
[15:31] <slyon> I'm working the systemd issues
[15:32] <bdmurray> great
[15:33] <dbungert> I'll take a look at casper
[15:33] <bdmurray> okay, I think that's it then
[15:33] <bdmurray> #AOB
[15:33] <slyon> I'll be off tomorrow
[15:34] <jawn-smith> I'll be out for a while Friday afternoon
[15:34] <juliank> Can we get a card to fix the reports for https?
[15:34] <juliank> rls-*-incoming one
[15:35] <juliank> or just do it, two lines or so need s/http/https/
[15:35] <bdmurray> Could you remind me?
[15:35] <bdmurray> That sounds like a fix it friday thing
[15:35] <juliank>         <link title="light" rel="stylesheet" href="http://people.canonical.com/~kernel/reports/css/light-style.css" type="text/css" media="print, projection, screen" />
[15:35] <juliank>         <script type="text/javascript" src="http://people.canonical.com/~kernel/reports/js/jquery-latest.js"></script>
[15:35] <juliank> stuff like that needs to be https
[15:36] <bdmurray> will do
[15:37] <bdmurray> thanks everybody
[15:37] <bdmurray> #endmeeting
[15:37] <meetingology> Meeting ended at 15:37:15 UTC.  Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-07-15-15.00.moin.txt
[15:37] <dbungert> o/
[15:37] <slyon> \o
[15:38] <sil2100> o/
[15:38] <mclemenceau> o/
[15:39] <schopin> o/
[15:52] <juliank> oOOOOOOOOOOOOOOOOOOOOOOO
[15:52] <juliank> o/


[14:46] <trijntje> What is the procedure for getting upstream translations for packages in universe into ubuntu?


[00:07] <micahg> chrisccoulson: fennec failed to build because of a build-dep, would you like me to take a look later?
[00:07] <chrisccoulson> micahg - yeah, i saw that.
[00:07] <chrisccoulson> feel free to look at it if i've not done it before i go to bed
[00:07] <chrisccoulson> i guess it needs --disable-notify rather than the build-depend adding
[00:08] <micahg> chrisccoulson: does fennec not have notifications?
[00:09] <chrisccoulson> it doesn't matter really, the libnotify stuff is only part of the toolkit, so that check is bogus :)
[00:09] <chrisccoulson> and xulrunner is already built with libnotfiy support
[00:09] <micahg> chrisccoulson: ah, ok, I'll add a note then if I do it
[00:09] <chrisccoulson> i had to do the same for lightning too. it might be worth just copying the extra build flags i added there :)
[00:10] <micahg> ok, we should probably upstream at some point the checks that should be disabled with --with-system-libxul
[12:44] <magcius> Is there any chance the Firefox daily builds can work again soon?
[12:45] <DeeVee> 2nd that :-P
[12:45] <DeeVee> the one from 20th has some weird repainting problem on some sites
[13:01] <magcius> As said before, I'd offer to fix it.
[13:02] <magcius> But I can't, because I can't fix the broken patch, because the patch won't apply
[13:02] <magcius> So I can't make a new patch.
[13:57] <micahg> magcius: DeeVee: yes, I'll fix it tonight if chrisccoulson doesn't get to it first
[13:58] <DeeVee> cool
[16:06] <dupondje> Firefox upgrade removes cache ?
[16:19] <chrisccoulson> dupondje, "removes cache"?
[16:20] <chrisccoulson> dupondje, if you're referring to the lack of confirmation on close, that's deliberate i'm afraid
[17:00] <dupondje> chrisccoulson: it moved places.sqlite to places.sqlite.corrupted
[17:00] <dupondje> :s
[21:20] <chrisccoulson> wow, abrowser has been broken in natty since before christmas, and not a single bug report so far
[21:20] <chrisccoulson> needs to die :)
[21:20] <chrisccoulson> clearly, nobody uses it
[21:22] <micahg> heh
[21:22]  * micahg still thinks it should be built from xulrunner like Debian
[21:23] <chrisccoulson> i think we should just kill it entirely
[21:23] <chrisccoulson> :)
[21:23] <micahg> well, the only benefit is testing FF-on-XR, but I guess there's no point anyway
[21:23] <chrisccoulson> i need to talk to the people that i know still do use it first though
[21:24] <jdstrand> chrisccoulson: hey, curious if anything has happened with bug #677551?
[21:24] <ubot2> Launchpad bug 677551 in firefox "pressing Enter in a large textarea is very CPU intensive with Firefox 4.0" [Undecided,New] https://launchpad.net/bugs/677551
[21:24] <chrisccoulson> jdstrand, no, not yet ;)
[21:24] <jdstrand> today's firefox is no better
[21:25] <chrisccoulson> i'll take another look next week though, i've been playing catch up this week after spending all my time on globalmenu work
[21:25] <jdstrand> cool, thanks
[21:25] <chrisccoulson> right, nightlies should work again now :)
[21:25] <chrisccoulson> time to do tbird 3.1.8 for natty and get the crashreporter on
[21:27] <micahg> cool
[21:27] <micahg> I need to finish with the locales this weekend
[21:39] <chrisccoulson> jdstrand, actually, would you mind sending bug 677551 upstream? i'll still look at it next week, but perhaps somebody else already has an idea ;)
[21:39] <ubot2> Launchpad bug 677551 in firefox "pressing Enter in a large textarea is very CPU intensive with Firefox 4.0" [Undecided,New] https://launchpad.net/bugs/677551
[21:51] <jdstrand> chrisccoulson: is there a wiki page for properly forwarding mozilla bugs?
[21:51] <jdstrand> chrisccoulson: like there is for gnome?
[21:55] <micahg> jdstrand: https://wiki.ubuntu.com/Bugs/Upstream/Mozilla, probably a little out of date
[21:58] <chrisccoulson> heh, i wasn't aware of that ;)
[21:58] <chrisccoulson> jdstrand, if you forward it upstream, Core - Layout is probably an appropriate place to report it
[21:58]  * micahg has roots in the bugsquad ;)
[22:00] <jdstrand> micahg, chrisccoulson: thanks
[22:00] <jdstrand> micahg: and hi! :)
[22:00] <micahg> hi jdstrand :)
[22:00] <chrisccoulson> jdstrand, also, please subscribe me :)
[22:00] <chrisccoulson> i'm not subscribed to all upstream bugs ;)
[22:01]  * micahg is following chrisccoulson upstream and will be implicitly subscribed
[22:01] <chrisccoulson> lol
[22:02] <micahg> chrisccoulson: it's the only way I can keep track of the GNOME3/global menu stuff without subscribing to everything :)
[22:03] <chrisccoulson> heh :)
[22:03] <chrisccoulson> oh no, updated indicator stack now
[22:04] <chrisccoulson> i wonder if everything will break again ;)
[22:04] <chrisccoulson> it did on the friday afternoon of the sprint!
[22:04] <chrisccoulson> perhaps i'll upgrade in the morning
[22:05] <micahg> Well, I'll probably be on natty in a couple weeks
[22:05] <chrisccoulson> you're not on it already?
[22:05] <chrisccoulson> tut tut, you'll need to be more hardcore than that ;)
[22:05] <micahg> chrisccoulson: nope
[22:05] <chrisccoulson> i'm on natty+3 already!
[22:05] <chrisccoulson> :)
[22:05]  * micahg still needs a guaranteed working system ATM :)
[22:05] <chrisccoulson> lol
[22:06] <chrisccoulson> i could do with that sometimes too
[22:06] <micahg> when I get my new laptop, I'll upgrade it to natty
[22:06] <chrisccoulson> cool!
[22:07] <jdstrand> chrisccoulson: https://bugzilla.mozilla.org/show_bug.cgi?id=597627
[22:07] <ubot2> Mozilla bug 597627 in Layout: Text "Adding and removing lines in big textareas is really slow" [Normal,New]
[22:07] <chrisccoulson> thanks :)
[22:07] <jdstrand> chrisccoulson: added that to the LP bug
[22:08] <jdstrand> chrisccoulson: looks like they are really keen on fixing it
[22:08] <jdstrand> [hardblocker]
[22:08] <micahg> yeah, but that still could be 3 weeks out
[22:08] <jdstrand> that is fine by me
[22:10] <jdstrand> chrisccoulson: would you mind subscribing yourself to the upstream bug if you want? not sure what address you want
[22:47] <jdstrand> chrisccoulson: wow, I don't think I realzed how cool the LP <-> mozilla bugzilla integration was
[22:47] <jdstrand> s/was/is/
[22:47] <chrisccoulson> jdstrand, oh, what has it done?
[22:47] <jdstrand> chrisccoulson: it imported 109 comments and allows me to respond to the mozilla bug
[22:47] <jdstrand> cia LP
[22:47] <jdstrand> via
[22:48] <chrisccoulson> ah, i haven't noticed that yet. does that mean i have 109 e-mails? ;)
[22:48] <jdstrand> I wonder how it does that, since I need to be logged in over there...
[22:48] <jdstrand> chrisccoulson: heh, no-- just one saying it happened
[22:48] <jdstrand> I am logged in over there... hmm
[23:52] <magcius> Wait, why aren't you running FF on xulrunner currently?
[23:52] <chrisccoulson> fta - mozilla bug 629544
[23:52] <ubot2> Mozilla bug 629544 in Blocklisting "Blocklist moonlight plugin on linux." [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=629544
[23:52] <chrisccoulson> magcius, we haven't done for ages, why you ask?
[23:52] <magcius> chrisccoulson, it makes more sense to do that for me
[23:52] <magcius> however mozilla-central is indeed a mess
[23:53] <chrisccoulson> why? you're free to build it on XR if you like, but we're not going to do that any more ;)
[23:53] <magcius> I hope some day they'll split out into the main gecko stuff, and have app/browser and all of that into a simple broject project
[23:53] <magcius> chrisccoulson, I'm curious why not
[23:53] <chrisccoulson> firstly, that configuration is totally unsupported
[23:54] <chrisccoulson> our builds are also pretty close to upstream builds now as well
[23:54] <chrisccoulson> which means we can do things like - send our crash reports to mozilla ;)
[23:54] <magcius> Ah.
[23:54] <magcius> I swore that upstream built it separately.
[23:55] <magcius> Not doing it that way seems stupid, but I have to ask upstream them.
[23:55] <magcius> then
[23:55] <chrisccoulson> also, certain features in ffox 4.0 don't work with ff-on-xr
[23:55] <chrisccoulson> eg, omni.jar
[23:55] <chrisccoulson> (unless that has been changed recently)
[23:56] <chrisccoulson> our source package supports building ff-on-xr btw
[23:56] <magcius> Right, I was under the impression that XULRunner contained the platform (gecko layout, libmozjs), and that FF was purely an application on top
[23:56] <chrisccoulson> just by flipping a bit in debian/rules
[23:57] <chrisccoulson> not sure if it still works though ;)
[23:58] <magcius> I'm sure you know by now that your pkg-config files are completely useless because /usr/lib/xulrunner-V/ isn't in ld.so.conf
[23:59] <magcius> But can you add another tally to that bug for me?
[23:59] <chrisccoulson> hmmm, no, that's deliberate
[23:59] <magcius> Why?
[23:59] <chrisccoulson> why should that directory be in ld.so.conf? applications shouldn't be directly linking against them
[23:59] <magcius> It makes gjs completely impossible to run, outside of LD_LIBRARY_PATH hacks


[09:01] <baptistemm> hello
[09:02] <baptistemm> is there a know bug which could prevent me to boot. I don't have gdm started (not starting sound neither) and display stays black
[09:02] <baptistemm> with lucid
[09:13] <RAOF> baptistemm: Could be intel and vga16fb fighting over framebuffers
[09:13] <baptistemm> I do have an intel chip yes
[09:13] <baptistemm> RAOF, do you have a bug number and/or a fix
[09:18] <RAOF> baptistemm: Sorry, I don't have a bug number, and it seems to have been fixed for me; alternatively, you can just delete /lib/modules/2.6..../kernel/.../vga16fb.ko & run update-initramfs.
[09:18] <RAOF> Or just blacklist.
[23:33] <chrisccoulson> awalton - there? i think i remember you saying some time ago that you were doing some work on libnotify so that it caches server capabilities. did i remember correctly, or have i got the wrong person?


[18:16] <mup> Issue operator#682 opened: Harness: `add_relation` or realtion joined do not emit "relation changed" <Created by sed-i> <https://github.com/canonical/operator/issues/682>
[22:38] <mup> PR operator#683 opened: docfix: mention `add_relation_unit` in the docstring for `add_relation` <Created by sed-i> <https://github.com/canonical/operator/pull/683>


[00:06] <jduggan> m_tadeu: see imdb.pl in the contrib folder
[00:08] <m_tadeu> jduggan: is there a way through the myth environment?
[00:08] <jduggan> yes get the imdb info
[00:09] <jduggan> i think in mythvideo setup
[00:09] <m_tadeu> thanks :) gonna check that out
[00:40] <zabwtf> i wish i could just pipe a bugreport from here :)  ... "1) Nova T-500 IR gives thousands of 'dib0700: Unknown remote controller key 9 3F' in syslog, -- need to recompile v4l with patch, 2) Mythfront replaces lcd-clock with LCDproc default status page on startup, 3) xfce panel sensors plugin has horrible colors and magically reverts changes to configfile"
[00:42] <whoDat_> how do i change the title of a recording
[01:01] <zabwtf> hmm, another bug .. /dev/dsp1 isn't there (sound for my analog tv-card)
[01:04] <setite> hey all
[01:04] <setite> anyone who can help me create .deb
[01:05] <setite> im trying debuild -us -uc but im getting an error in debian/rules
[01:34] <superm1> yo kirkland
[01:34] <superm1> what's up?
[01:34] <kirkland> superm1: hiya, i merged mythtv-status today, was looking for a sponsor
[01:34] <superm1> sure
[01:34] <kirkland> superm1: but i noticed someone else had done so also
[01:34] <superm1> post a debdiff somewhere?
[01:35] <kirkland> superm1: i'm not sure what the protocol is, but i don't want to hijack anyone's merge ;-)
[01:35] <superm1> well was it a complex merge?
[01:35] <kirkland> superm1: yeah, on set
[01:35] <superm1> and did you do a better job?
[01:35] <kirkland> superm1: no, very very simple
[01:35] <kirkland> superm1: different verbage in the changelog
[01:36] <superm1> well whom ever's sounds better than i say
[01:36] <kirkland> superm1: https://bugs.edge.launchpad.net/ubuntu/+source/mythtv-status/+bug/243205
[01:36] <kirkland> superm1: he's got a debdiff in that bug, I have a pointer to http://people.ubuntu.com/~kirkland/mythtv-status/
[01:37] <superm1> kirkland, how about this...
[01:37] <superm1> send the guy in debian an email
[01:37] <superm1> to have him depend on mythtv-perl | libmyth-perl
[01:37] <superm1> so that we can drop the delta
[01:38] <kirkland> superm1: sure
[01:38] <superm1> kirkland, although he might have trouble with that i realize now since neither is formally in debian
[01:38] <superm1> maybe if he can make them recommends
[01:38] <superm1> if not, then i'll sponsor one of your two merges
[01:39] <kirkland> superm1: sure, sounds good
[01:40] <superm1> thanks
[05:26] <adefa> is there an easy way to stop the mythfrontend and backend from loading automatically?
[05:36] <tgm4883_laptop> rhpot1991, you can come back you know
[08:35] <jasperbg> hey, anyone know the status of the mythbuntu 0.22-trunk PPA?
[08:35] <jasperbg> https://launchpad.net/~mythbuntu-trunk-0.22/+archive
[09:33] <illunie1> Hi! I am just curious now, I would like to use and MCE just as a Video/Audio/Photo server not as a PVR is that possible with MythBuntu? I tried it before and i couldn't seem to get the video to work although sounds were fine.
[16:26] <cypherdelic> Please help me: Cinergy T USB XE suddenly doesn't work anyome. DMESG: http://pastebin.com/m38c3ef17
[16:29] <cypherdelic> i didn't changed anything. i dont know why it doesnt work anymore
[17:13] <zabbadapp> turn it off, then on again? so the firmware is reloaded
[19:12] <Helloboy> HI
[19:13] <Hellobay> how can i stop the frontend to start automatically at boot. the button in the mcc doesn't work anymore. (8.04
[19:26] <zabbadapp> Hellobay: the gui-settings for autostart seems to be gone in mythbuntu 8.04? Atleast for me (i did an upgrade from 7.10) ... anyway, in ~/.config/autostart/ you can find it
[19:27] <Hellobay> thank you but i already tried deleting that link but with the next boot it is there again
[19:53] <m_tadeu> hi everyone
[20:05] <thedarkone> hellobay use synapic
[20:05] <thedarkone> and hit search type in autostart
[20:16] <m_tadeu> how can I set music art stuff?
[20:32] <jphillip> m_tadeu I believe you drop an image in the directory
[20:33] <m_tadeu> jphillip: ok...thanks
[20:34] <Frans-Willem> Bah, just ripped out my videocard out of my backend and it's still booting (although it's giving some loud beeps doing so)
[20:34] <Frans-Willem> Only problem is that now VNC isn't working anymore :(
[20:49] <m_tadeu> i'm trying to search videos on youtube, using mythbrowser...but I can't insert a space in the search box
[20:58] <laga> Frans-Willem: oh. yeah. VNC is brought up together with X.  :)
[20:58] <laga> and X is not going to come up with a video card
[20:58] <laga> so just run vncserver?
[21:08] <Frans-Willem> Got X11 forwarding running now with Cygwin
[21:08] <Frans-Willem> I could bring up xterm
[21:08] <Frans-Willem> only downside is, I can't bring up the menu :/
[21:10] <Frans-Willem> Any ideas to that ?
[21:13] <laga> what menu?
[21:13] <Frans-Willem> The start menu, the one I launch apps from :p
[21:13] <laga> oh my god. ;)
[21:13] <Frans-Willem> top left
[21:14] <Frans-Willem> What :p?
[21:14] <Frans-Willem> Yeah, I could try and find out what the command lines to some are, but it's easier to have all those things just in a menu :/
[21:14] <Frans-Willem> what's the mythbuntu equivalent of C:\windows\start menu ;)?
[21:20] <Frans-Willem> ... :/
[21:20] <laga> no clue actually. i guess you could start xfce.
[21:20] <Frans-Willem> Command not found :(
[21:22] <jphillip> Frans-Willem the way I recall it is that you ssh'd in and launched an app that used x and then it would run in cygwin
[21:22] <Frans-Willem> Yeah, that works
[21:22] <Frans-Willem> running xterm works fine
[21:22] <jphillip> I'm not sure you can run the desktop
[21:22] <Frans-Willem> but I'd like to see (for example) the MythBuntu Control Center
[21:22] <Frans-Willem> and I'd love to be able to find out where it is
[21:22] <jphillip> so just run it?
[21:22] <Frans-Willem> But if you tell me the command line, I'll only know how to launch the MCC, and next time I need a specific app I'll have to ask again :p
[21:23] <Frans-Willem> So I'd rather find out where the default start menu is stored, so I can peek and find out for myself :)
[21:23] <laga> you can just guess commands?
[21:24] <laga> eg type
[21:24] <laga> mythbuntu TAB TAB
[21:24] <laga> and it will show you
[21:24] <Frans-Willem> Oooh, that's nice :)
[21:26] <m_tadeu> can I resize the subtitle font size?
[21:30] <jphillip> yes tab complete is a lifesaver
[21:31] <laga> so is david hasselhoff
[21:32] <jphillip> knightrider hasselhoff or baywatch hasselhoff?
[21:34] <Frans-Willem> Ok, so seriously, this X forwarding is a mess :(
[21:34] <Frans-Willem> I need to hack around to enter my sudo password in that X session (it's hidden :/), and on top of that running the control center for the diskless clients just crashes on me
[21:35] <Frans-Willem> Someone mentioned vncserver, any instructions on how to set it up properly? I've alreayd installed te tightvncserver package, but running vncserver starts a screen on :1 with just a terminal, nothing els
[21:35] <jphillip> you can try nxserver as well, though I don't like the way it works with xfce
[21:37] <Frans-Willem> Hah! nvm, got it myself :)
[21:38] <Frans-Willem> Needed to edit /home/frans-willem/.vnc/xstartup
[21:38] <Frans-Willem> removed the termianl and default WM
[21:38] <Frans-Willem> and replaced it with xfce4-session
[21:51] <jphillip> it still does annoying stuff like spawns a mythfrontend like that I think
[22:16] <MythbuntuGuest76> anyone using a 7100/630i over HDMI?
[22:42] <jasperbg> laga: ping?
[23:18] <MythbuntuGuest76> laga: ping?
[23:18] <MythbuntuGuest76> why does my diskless client have different packages to my server?
[23:19] <Frans-Willem> MythbuntuGuest76: Because it's not a clone, it's a seperate image
[23:19] <MythbuntuGuest76> Frans-Willem, how do i update it?
[23:20] <MythbuntuGuest76> Frans-Willem, in MCC?
[23:20] <MythbuntuGuest76> Frans-Willem, DOH!
[23:20] <MythbuntuGuest76> Frans-Willem, im a dumbass!
[23:20] <Frans-Willem> Mythbuntuguest76: Go into the MCC, then go to the diskless tab and click the MCC button there, that spawns an MCC in the image
[23:20] <Frans-Willem> Just run synaptic or anything else from there
[23:22] <MythbuntuGuest76> Frans-Willem, did my updates and launched synaptic...still out of date
[23:23] <Frans-Willem> Did you commit the changes to the image ?
[23:24] <MythbuntuGuest76> yes
[23:24] <MythbuntuGuest76> Frans-Willem, sources.list?? thats prob it
[23:25] <Frans-Willem> That or the overlay :/
[23:27] <MythbuntuGuest76> overlay? should i clean the whole thing out? been trying not to use it...only for nvidia and xorg really
[23:28] <Frans-Willem> Well I personally always clean the overlay after major changes to the image
[23:28] <MythbuntuGuest76> will do! thanks frans, might need to try it tomorrow though
[23:28] <MythbuntuGuest76> nite all


[00:01] <lifeless> igc: hai
[00:09] <igc> morning all
[00:09] <igc> hi lifeless
[00:10] <poolie> hi igc
[00:10] <igc> hi poolie, jam
[00:11] <lifeless> igc: have you used netbeans as a datasource for benching?
[00:12] <igc> lifeless: no
[00:12] <lifeless> igc: I ask, because one of the drizzle folk was bemoaning the lack of a bzr scm module
[00:12] <lifeless> so I pulled the thing... 1.7GB, 90K files
[00:12] <lifeless> 133K commits
[00:13] <igc> lifeless: as in an addon for NetBeans?
[00:13] <lifeless> yeah
[00:13] <lifeless> their addons are all in tree
[00:13] <lifeless> _pain_
[00:13] <igc> lifeless: yuk
[00:14] <igc> lifeless: it was nice to see qbzr-eclipse 0.7 out overnight
[00:14] <igc> and I'm pretty sure there's someone working on a C++ Builder/Delphi integration along those same lines
[00:15] <igc> lifeless: http://bazaar-vcs.org/IDEIntegration/Guide
[00:16] <igc> lifeless: I'm pretty sure nick put together the original qbzr-eclipse integration in around 2 days
[00:17] <igc> lifeless: so it's typically easy to get *something* useful going
[00:18] <igc> lifeless: my main reluctance with doing an integration myself is ongoing ownership - it's better if someone using a given IDE everyday owns it IMO
[00:20] <lifeless> igc: I agree; I don't really like the different UI that qbzr-* gives though
[00:20] <ronny> igc: are you Ian Clatworthy?
[00:21] <igc> roony: yes
[00:21] <igc> ronny: ^
[00:21] <ronny> igc: great, well, what do people do that do api-level integration instead of subprocess levle integration :P
[00:22] <igc> ronny: I'm not sure I understand the question ...
[00:23] <igc> ronny: you can always call into bzrlib and into qbzr itself if you want
[00:23]  * ronny is the author of anyvc, a vcs abstraction lib, i just import bzr instead of calling to it
[00:23] <igc> though the qbzr API has no stability guarantees
[00:25] <igc> ronny: the point behind using the qbzr applets is to same the engineering time required to design, develop and test 30-40 dialogs
[00:25] <ronny> igc: well, does it have version metadata, and some more convience tools for common ops than bzrlibs?
[00:26] <ronny> igc: im not sure if qbzr wil lbe that helpfull for me, as i need the dialogs for other vcs's, too
[00:28] <igc> ronny: right. Down the track. I'd hope to see qbzr working in combination with bzr-svn, etc. to provide a common GUI over multiple VCSs but it sounds like you're solving a different problem
[00:29] <ronny> igc: yup, i'll probably have to support the svn integrations anyway at some point
[00:33] <jelmer> fwiw the combination of qbzr and bzr-svn should already work
[00:33] <jelmer> John Szakmeister did quite a bit of testing with it and reported bugs
[00:40] <lifeless> igc: hg fastexport is kinda slow :(
[00:41] <igc> lifeless: yep
[00:42] <igc> lifeless: on packs, so it bzr-fast-export; 2a is a much happier place for bulk data export/import
[00:42] <igc> s/it/is/
[00:43] <lifeless> yeah
[00:43] <lifeless> I should hope so :P
[00:48] <poolie> igc, so i liked your wishlist blog postn
[00:49] <poolie> but i think we need to distinguish "things that will actually block 2.0" from "things we'd like to do" :-/
[00:49] <poolie> because that list is pretty incompatible with hitting karmic
[00:50] <igc> poolie: yep
[00:51] <poolie> 2.0 is kind of trying to be two different things
[00:51] <poolie> the release that makes 2a the stable format
[00:51] <poolie> and the "everything's great and finished" release
[00:53] <fullermd> It's also trying to be the "Crap, we have to hit karmic" release...
[00:54] <igc> poolie: no, it's not the later
[00:54] <igc> poolie: 2.0 is trying to be 2.0
[00:55] <igc> poolie: that does mean a new format
[00:55] <igc> poolie: it also means "now's a god time to take another look at Bazaar if you're not using it"
[00:55] <igc> good
[00:55] <poolie> sure
[00:56] <poolie> i guess i'm glad you're raising these things but the week we're trying to freeze the code is a
[00:56] <poolie> well, maybe not a great time
[00:57] <poolie> :/
[00:57] <igc> poolie: that's not totally fair ...
[00:57] <igc> I've been raising better packaging for weeks and weeks now on multiple email lists
[00:57] <poolie> that's true
[00:58] <poolie> -> phone
[01:28] <flacoste> if I use bzr-svn to merge a svn branch onto the trunk, will svn grok the merge?
[01:28] <lifeless> jelmer: ^
[01:29] <flacoste> i was talking with a guy last week at Agile2009 who use git-svn
[01:29] <flacoste> on windows
[01:29] <flacoste> he finds it painfully slow
[01:29] <flacoste> and that was another pain point for him
[01:29] <flacoste> i want him to have another try at bzr
[01:29] <flacoste> he try it out last year
[01:30] <lifeless> bbs fooding
[01:46] <igc> hi jelmer
[01:47] <igc> jelmer: I think qbzr is working over bzr-svn
[01:47] <igc> jlemer: I wonder if we need some tweaks though, e.g. a gui way of doing a dpush" or whatever name we selected for that operation
[01:48] <igc> jelmer: ^^^
[02:11] <lifeless> jelmer: ping
[02:27] <igc> bbiab
[02:39] <poolie> spiv: hi, late call?
[02:42] <spiv> poolie: sure
[02:42] <poolie> will call in 2m
[03:00] <spiv> Hmm, jam's mail server is bouncing mail.
[03:44] <rbelem> anyone knows which command in !bzr shows just the changes from a given revision?
[03:44] <bob2> what is !bzr?
[03:44] <rbelem> bob2, ops... typo
[03:44] <rbelem> :D
[03:45] <fullermd> The logical counterpart of ~bzr
[03:45] <rbelem> ehehehe
[03:46] <bob2> bzr diff -c xxx
[03:47] <rbelem> bob2, that was exactly what I was wanting
[03:47] <rbelem> thanks a lot!
[03:52]  * rbelem leaving
[03:56]  * igc lunch
[04:50] <andrewks> is there a way to make bzr missing walk up a sequence of branches?
[05:06] <AfC> up?
[05:08] <tbradshaw> LarstiQ: a status update:.  After recompiling subvertpy, I was able to get things to commit properly to the svn repo!  Thanks again for your help earlier today.
[05:41] <andrewks> AfC: transitive relationships.  the parent of the parent branch, etc
[05:45] <AfC> andrewks: so, to my knowledge, no, that's not built in. But it wouldn't be _that_ hard to [shell] script, especially if you assume that branches are sanely set-up, and that `bzr diff -r ancestor:` does what you want it to in each branch. Or you could parse `bzr info` output. etc
[05:45] <andrewks> yes, I'm going with sane locations for now.    It's probably too late for anything I say to be worth listening to today...
[06:00] <AfC> fullermd: hm. Not so sure about that: `bzr status -r ancestor:ancestor:` just now didn't work
[07:20] <vila> hi all
[07:43] <poolie> hi vila
[07:43] <vila> hey !
[07:46] <lifeless> https://bugs.launchpad.net/bzr/+bug/422403
[07:46] <lifeless> hi vila
[07:48] <vila> add --forward to that and we should be quite close to the slowest possible context
[07:49] <lifeless> he runs this all the time
[07:49] <lifeless> to see what he has pulled
[07:49] <vila> I think Ian answer makes sense, drop -n0
[07:49] <vila> drill down only when needed
[07:50] <vila> that's the only work around I can think of
[07:50] <poolie> spm: actually maybe we should talk here
[07:50] <spm> poolie: heh. indeed. just reading now.
[07:50] <poolie> vila: well, it can be an open bug still
[07:50] <poolie> let's make sure it's deduped and clear: takes too long to start showing revisions for indented less
[07:50] <vila> until we are able to calculate revnos lazily, that bug will remain open... lol, fully agree poolie :)
[07:50] <poolie> sure
[07:51] <spm> poolie: err. I'm not sure I can do that - I think I fail on the "friendly sysadmin" part???
[07:51] <poolie> saying it depends on the other bug is ok
[07:51] <poolie> damn
[07:51] <poolie> need 3 wise men too
[07:51] <lifeless> [he didn't tell me he used -0 :P]
[07:51] <vila> lifeless: they just love to trick us :-)
[07:52] <poolie> it might be worth drilling into why he's doing this
[07:52] <poolie> is it that he really wants to see all the history and -n0 is the best way
[07:52] <spm> poolie: yeah, that looks fairly straight forward. shall I start to make it so?
[07:53] <poolie> well, i guess you'll still need incremental revnos
[07:53] <poolie> spm, yes, how about turning off pqm first
[07:53] <poolie> at least for that branch, or globally
[07:53] <poolie> and let's make an extra adhoc backup of it, then run check
[07:53] <spm> globally for bzr, yes. backups is good.
[07:55] <vila> poolie: we have incremental revnos if we display mainline revisions only :-) We start at the top and decrement, easy.
[07:55] <vila> s/top/tip/
[07:57] <poolie> right
[07:59] <spm> poolie: lifeless: I can't help but feel I'm missing something really obvious here. the master location is (pqm config) /home/pqm/archives/thelove/bzr/2.0 but that's only a 44Kb directory. 1.18 etc are the same. ??
[08:00] <poolie> spm, that's probably a bzr branch with no working tree
[08:00] <poolie> what does bzr info show you?
[08:00] <spm> poolie: it is; would it really be that small tho?
[08:00] <vila> spm: and a shared repo above it
[08:01] <spm> right. yes.
[08:01] <spm> shared repository: /home/pqm/archives/thelove/bzr
[08:01] <spm>   repository branch: .
[08:02] <vila> spm: 44Kb now sounds even too much :)
[08:02] <lifeless> spm: cd to /home/pqm/archives/thelove/bzr
[08:02] <lifeless> spm: upgrade *that*
[08:02] <spm> vila: heh. well a sum total of 570Mb is more the ballpark I was expecting.
[08:02] <lifeless> spm: same as launchpad, shared repo.
[08:02] <poolie> ok
[08:02] <poolie> so tar up the whole thing before starting?
[08:02] <poolie> and then run check in there
[08:03] <poolie> oh also we should check what version of bzr you're using there
[08:04] <vila> not sure, it will make a difference when run locally, but upgrading the test slaves, I noticed huge differences in performances between 1.17, 1.18 and 2.1dev, I think 2.0rc1 at least is needed here (or did spiv patch regarding IDS landed in bzr.dev only ?)
[08:04] <spm> so tarball: ~/archives/thelove/bzr-backup-2.0.tar fwiw
[08:05] <spm> we have bzr 1.17 locally; I can moderately easy create a special bzr of any version needed?
[08:05] <poolie> using 2.0rc1 would be good
[08:05] <poolie> or the ppa nightly
[08:05] <spm> ppa's is hard. build from source/branch is easy
[08:06] <spm> amusingly :-)
[08:06] <vila> lp:bzr/2.0 then
[08:06] <vila> hmm, wait
[08:06] <poolie> yes, that'd be good
[08:07] <lifeless> vila: need 2.0 on launchpad before it will be fast :P
[08:07] <lifeless> poolie: re conversion performance: this is what spiv and I meant by 'very slow without network deltas'
[08:08] <lifeless> poolie: its not hanging, its doing millions of little round trips on the VFS
[08:08] <vila> lifeless: it already makes a difference when pulling from lp
[08:08] <poolie> lifeless: it's not doing any network io
[08:08] <poolie> as observed by trace
[08:08] <lifeless> poolie: oh, thats extremely odd
[08:08] <poolie> strace*
[08:09] <vila> poolie: but didn't you have CPU consumed ?
[08:09] <lifeless> did you try ctrl-\ and inspect?
[08:09] <poolie> yes, that's the bug i filed
[08:09] <lifeless> ok
[08:09] <poolie> now i'm fixing bug 341535 :)
[08:09] <lifeless> looks like a server bug of some sort
[08:09] <lifeless> hmm
[08:10] <vila> I didn't comment on the bug, but I had symptoms pretty close to yours (poolie) except my pulls finished...
[08:12] <vila> spm: so, lp:bzr/2.0 is already a bit more than 2.0rc1, nothing to be worried about I think, but if you keep notes on the upgrade it will be good to note the revno you used
[08:13] <spm> vila: 'kk
[08:14] <spm> btw. "Setting ssh/sftp usernames for launchpad.net." how do I stop bzr from doing that? it creates that )(*^)*(&^(%^&%$&*%^$*&%ing authentication.conf file and hence fails to connect. I assume by not using lp:bzr/blah syntax
[08:15] <vila> err, how do you connect ?
[08:15] <vila> you use bzr-pqm user right ?
[08:15] <vila> on lp I mean
[08:15] <spm> bzr branch bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.0 bzr-2.0 <== works; bzr branch lp:bzr/2.0 bzr-2.0 <== fails
[08:15] <spiv> Why is the existence of the authentication.conf a problem?  Because it's putting in 'spm' rather than 'bzr-pqm'?
[08:16] <spm> spiv: tbh, I don't precisely know, but using that lp:bzr breaks it totally. it's bzr-pqm, I'm sudo'd as the pqm user.
[08:16] <vila> sudo doesn't matter, what is you $HOME ?
[08:16] <spm> oh that's right - we have aliases "somewhere" that map users keys to branches or somesuch.
[08:17] <vila> authentication.conf is such a map !
[08:17] <spm> .ssh/config
[08:17] <vila> also
[08:17] <vila> but looked at after :)
[08:18] <spm> ISTR that the issue is around the *other* accesses that this uid has; all with diff keys
[08:18] <vila> spm:  what is your $HOME ?
[08:18] <spm>  /home/pqm
[08:19] <vila> what is /home/pqm/.bazaar/authentication.conf  content?
[08:20] <vila> LOL, I never went to https://edge.launchpad.net/~bzr-pqm before :D
[08:21] <spm> vila: [Launchpad] host = .launchpad.net ;; scheme = ssh ;; user = launchpad-pqm
[08:22] <vila> so launchpad-pqm should be bzr-pqm ? Oooooooh, that's the problem ! It's used for launchpad and bzr right ?
[08:23] <spm> vila: launchpad no, but other projects yes.
[08:24] <spm> sorta.
[08:24] <vila> spm: and they need that launchpad-pqm identity ?
[08:24] <spm> heh. they have their own. like bzr-pqm :-)
[08:24] <spiv> The same PQM instance is used for multiple projects?
[08:24] <spm> yeha. what spiv said. thanks andrew :-)
[08:25] <spiv> That seems strange to me, no wonder we're having trouble :)
[08:26] <vila> haaa, I think I get it, the lp directory service  is the one that create auth.conf, so that explains the difference
[08:26] <poolie> nice image for pqm :)
[08:26] <vila> poolie: made me LOL yes :)
[08:26] <spm> huh. default balleny doesn't have pyrex installed, just the bzr pqm chroot does.
[08:27] <poolie> vila, so on bugs like the pqm speed one, can we change the description/subject to something reflecting the general bug?
[08:28] <vila> spm: strictly speaking the lp dir. service is wrong here, it shouldn't create an auth.conf file because... using different users to connect to the same host is not a case that auth.conf can handle (I think(
[08:29] <vila> poolie: pqm speed bug ? # ?
[08:29] <poolie> sorry, i meant log speed
[08:29] <spm> vila: fair enough
[08:30] <vila> spm: the bad news is that the only work-around I can think of is 1) stop using  lp: shortcuts, 2) always mention<EMAIL_ADDRESS>in urls
[08:31] <spiv> Or set BZR_HOME differently for each pqm 'instance', as a substitute for having different system users.
[08:31] <spm> vila: heh. 1, we'd kinda figured out, if not enunciated clearly. 2. ?
[08:31] <spm> spiv: ahhh. that's easily doable I 'spect
[08:32] <vila> spm: spiv idea is better :)
[08:33] <vila> spm: same effect: the user is explicit so auth.conf is not injecting a bad one anymore
[08:33] <spm> vila: spiv is more than just a teddy bear; you heard it here first.
[08:33] <vila> dropping bear ?
[08:33] <spm> vila: ah. right.
[08:35] <spm> vila: so the upgrade/check. /srv/pqm.ubuntu.com/chroot-amd64/home/pqm/bzr-2.0/bzr revno /srv/pqm.ubuntu.com/chroot-amd64/home/pqm/bzr-2.0 ==> 4647
[08:38] <poolie> seems about right
[08:39] <poolie> we should try check on it?
[08:39] <spm> is running atm. just "/.../bzr check"  yes?
[08:40] <spm> err.. in /home/pqm/archives/thelove/bzr to be more precise
[08:40] <poolie> right
[08:41] <poolie> and did you tell pqm to stop processing mails?
[08:41] <poolie> thanks for doing it today btw, i know it's getting late
[08:43] <spm> poolie: aye, processing bzr ones at any rate. is cool, I had to work later today anyway.
[08:43] <vila> we can't 'bzr log' without showing any revnos at all ? Did we lose that or did I dream it ?
[08:43] <poolie> i don't recall having that
[08:43] <poolie> it might be useful
[08:43] <vila> I thought --show-ids was doing that but no
[08:49] <vila> poolie: I think you should create a 2.1 milestone,
[08:49] <poolie> good idea
[08:50] <vila> creating 2.1 release branch may wait though
[08:50] <poolie> vila, it should be something different, like --no-revnos
[08:50] <vila> poolie: I agree
[08:50] <poolie> vila, do you want me in particular to do it?
[08:50] <poolie> i don't mind, but don't you have access?
[08:51] <poolie> lifeless: i'm trying a conversion here and getting
[08:51] <vila> oh no, it was just that I wanted to check with you first (you may have had (sp ?) a reason for not creating it)
[08:51] <poolie> bzr: ERROR: The file id "mpregen-20070411063203-5x9z7i73add0d6f6-1" is not present in the tree <bzrlib.inventory.CHKInventory object at 0x4372650>.
[08:53] <vila> poolie: it was also mentioned in https://code.edge.launchpad.net/~vila/bzr/releasing-clarified/+merge/10854 and really that's a new *series* that should be created :)
[08:53] <poolie> right, it should be both
[08:53] <poolie> though, um
[08:53] <vila> :)
[08:53] <poolie> actually i'm not sure how this will interact and whether the milestone should be on trunk or on the 2.1 series
[08:54] <poolie> probably the second, for the final release
[08:54] <poolie> were you wanting to target something now?
[08:54] <vila> no
[08:54] <vila> but someone want, and in principle, since bzr.dev now says 2.1dev, 2.1 should exist
[08:55] <vila> that's why I repeat the "create milestone" mantra several times in releasing.txt, because that's the one that is the most often forgotten
[08:55] <vila> but no urgency, just something I wanted to get out of my mind and onto the RM shoulders :)
[08:56] <vila> (that's the famous: "you can sleep now, that's not *your* problem anymore" joke :)
[08:58] <poolie> :)
[08:58] <vila> poolie: bzr-gtk create milestones in the trunk series, I'm not sure that's better, but just have a look at https://edge.launchpad.net/bzr-gtk/+series
[09:00] <spm> fyi: bzr check still running. just going afk for a bit; will be back in 10.
[09:00] <poolie> vila, they may not branch for releases?
[09:02] <poolie> vila, my point about the bug title is: don't mention "1233 revisions" or "on mysql" unless it really is specific to that case
[09:02] <vila> indeed. I did the last two releases, but I just followed the existing practice. In retrospect, I'm almost sure it wasn't really a conscious decision, just a simplification that lp allowed
[09:02] <poolie> users always make them specific but i'm sure it's clearer if we make them as general as is appropriate
[09:02] <poolie> helps with removing dupes etc
[09:02] <poolie> i'll do a 2.1 series now
[09:02] <poolie> the little diagram is interesting
[09:03] <vila> poolie: good point
[09:04] <vila> yes, that's why I pointed you there
[09:04] <lifeless> poolie: when did you last check your repo ;)
[09:04] <jml> lifeless, "Handing over to a machine to do CI is just as expensive as handing to a colleague." -- Handing over to a machine is probably a little cheaper
[09:04] <vila> it captures the release process amazingly
[09:04] <lifeless> vila: the other thing forgotten is 'create NEWS headers'
[09:04] <poolie> lifeless: just now :-O
[09:04] <jml> (advogato sucks for replies)
[09:04] <vila> lifeless: I mentioned it in the cover letter
[09:04] <lifeless> jml: for you, not for the machine :)
[09:05] <vila> I thought you read it there first, but that's just more telepathy obviously :)
[09:05] <vila> oh, no *create*, yes, I forgot that, I thought you were referring to NEWS header ordering with overlapping releases
[09:06] <vila> but both are tied anyway
[09:06] <lifeless> :P
[09:07] <poolie> lifeless: i'm just checking it again now in a clean local branch
[09:07] <jml> lifeless, when you hand off to humans, you almost always have to transfer knowledge. that's less commonly true for machines.
[09:07] <lifeless> poolie: also are you upgrading with the latest ?
[09:07] <jml> although there's probably an argument-by-different-definition to be made there
[09:07] <poolie> yes, trunk as of today
[09:07] <poolie> i might use 2.0 instead though
[09:08] <lifeless> jml: How about this: When you hand off to a human, you can stop worrying, but the act of handing costs more. When you hand off to a machine, you know its coming back to you if it fails, so there is some cognitive load.
[09:08] <lifeless> jml: And I'm asserting that these, while different, are approximately the same
[09:09] <lifeless> jml: what blog site did you end up using?
[09:10] <jml> lifeless, I use blogger.
[09:10] <lifeless> what would you like to see them improve?
[09:10] <jml> lifeless, I think I'll use wordpress for my next project though.
[09:10] <lifeless> hosted or self-run?
[09:10] <jml> lifeless, ease of pasting code samples :)
[09:11] <lifeless> and why wordpress?
[09:11] <jml> lifeless, I host my own blogs currently, blogger sftps them to my site
[09:11] <lifeless> interesting; and does your feedback too?
[09:11] <lifeless> to your site, or from your site?
[09:12] <jml> blogger uploads to my site
[09:12] <lifeless> nice
[09:12] <jml> I actually have no idea how comments work, but they do work.
[09:12] <jml> lifeless, wordpress because it seems to have the biggest community and all the blogs I see that look good & use free software seem to use wordpress
[09:13] <poolie> lifeless: i just reproduced this failure on a fresh branch of bzr from lp into a fresh directory :/
[09:13] <jml> it's also quite flexible.
[09:13] <lifeless> poolie: \o/ dogfooding
[09:13] <lifeless> jml: and you'll self host again?
[09:14] <jml> how do I get pqm-submit to not care about the fact that I lack a local copy of the branch I want to submit?
[09:14] <jml> lifeless, probably.
[09:14] <lifeless> though I understand that for wordpress that means more than it did/does for blogger
[09:14] <lifeless> jml: patch it
[09:14] <lifeless> jml: its on my 'do it the next time it annoys me' list.
[09:15] <vila> jml: what are you submitting then ? pqm-submit is more or less supposed to ensures that *you* are submitting *this*
[09:16] <jml> vila, I'm submitting a patch on someone else's behalf.
[09:17] <vila> jml: irrelevant :) In principle you still need to "sign" *this*, where is *this* ?
[09:17] <lifeless> vila: nah, thats recent
[09:17] <lifeless> vila: pqm-submit is 'tell pqm what to do'
[09:17] <lifeless> vila: there is no good reason to prevent clueful use being convenient.
[09:18] <vila> lifeless: I know, hence my "in principle" and "more or less"
[09:18] <lifeless> vila: I'm arguing the principle is unclear :)
[09:18] <lifeless> like the bug on switch. boy that hurt :(
[09:18] <jml> here's what I want
[09:19] <vila> We agree :) I'm trying to avoid popularizing a hole I dislike in pqm-submit :-)
[09:19] <jml> (as a hacker of Launchpad)
[09:19] <lifeless> a fast test suite
[09:19] <jml> a way of submitting an approved merge to land, conditional on tests passing
[09:19] <lifeless> a great user experience
[09:19] <vila> lifeless: :D
[09:19] <poolie> i'm posting a reproduction on bug 422423
[09:19] <jml> a way of submitting an approved merge to land
[09:19] <poolie> it's just a tarball from lp
[09:19] <jml> lifeless, those too.
[09:20] <poolie> i have to go out with S now, but i'll come back and look at this
[09:20] <poolie> spm, we'd probably better not proceed until we get to the bottom of it
[09:20] <lifeless> jml: please, its pretty obvious; take the code, opportunistically fix it. Use it and submit a merge.
[09:20] <lifeless> jml: (like I did for removable :P)
[09:20] <jml> lifeless, suree.
[09:20] <lifeless> jml: by obvious I mean that the code is small and simple.
[09:22] <jml> lifeless, yeah, I'll do it the next time I get a chance
[09:22] <jml> but I don't have any more time to hack this evening
[09:22]  * igc dinner
[09:22] <jml> and if I did, I really ought to use it to pack, not hack.
[09:25] <spm> poolie: ok, at this stage the check actually failed.
[09:26] <poolie> interesting
[09:26] <poolie> so
[09:26] <poolie> we should probably reenable pqm, and not proceed further until we know what's causing this
[09:26] <spm> https://pastebin.canonical.com/21673/
[09:26] <spm> oki
[09:27] <spm> bzr pqm re-enabled
[09:29] <poolie> thanks
[09:29] <poolie> i'm going to look at it tomorrow, or at most later tonight
[09:29] <poolie> spm is that pastebin before it failed??
[09:29] <poolie> it has no errors
[09:30] <vila> found error:Internal check failed: revno does not match len(mainline) 1649 != 1674
[09:30] <spm> I'm not sure how serious an error that is? recommendations to RTFM will be ignored. :-)
[09:34] <vila> that's a bit strange, and I can't see if it's for 0.8 or 1.8... 1.8 has 3766 revisions in the mainline anyway...
[09:39] <vila> spm: ok, 0.8 has 1674 revisions so that's the one
[09:41] <vila> spm: I'm pretty sure reconcile will fix that
[11:05] <spirov92> I have 2 branches in the same directory, let's say branch1 and branch2, with a similar file structure. Can I copy branch1/lib/some_file.php to branch2/lib/some_file.php using bzr?
[11:19] <emmajane> ping poolie
[13:45] <johnf> abentley: will you be doing a 2.0.0 release of bzrtools?
[13:45] <abentley> johnf: Yes.
[13:46] <johnf> jelmer: same question for bzr-svn :)
[13:46] <jelmer> johnf: I'm going to release a bzr-svn matching bzr 2.0, probably bzr-svn 1.0
[13:46] <jelmer> johnf: not sure yet for bzr-git
[13:57] <jelmer> has anybody seen james_w recently?
[15:03] <igc> night all
[15:22] <CameronP> HI there!
[15:22] <CameronP> I just installed bzr!
[15:23] <CameronP> Trying to merge my first lot of changes back to main branch - through tortoise bzr , i cant find a way to merge
[16:13] <jam> is anyone else seeing launchpad be a bit slow to load today?
[19:50] <Kobaz> how do you perminantly remove something from a branch
[19:51] <luks> you can't
[19:51] <Kobaz> aww, i thought i remember reading something somewhere that you could
[19:52] <jelmer> you can remove a revision from a *branch* by using "bzr uncommit"
[19:52] <Kobaz> uncommit only removes from the head it seems
[20:08] <garyvdm> Kobaz: You can do it, by branching it to a new branch, and deleting the old branch. This won't remove it from other branches that may have the revision.
[20:08] <Kobaz> k
[20:09] <Kobaz> so if you like, delete stuff, and then branch?
[20:09] <Kobaz> or do uncommits, and then branch?
[20:09] <garyvdm> Hi jelmer
[20:11] <garyvdm> jelmer: was going to ask if you knew of any code that uses ui.get_username, other than bzr-svn, but I see that bzrlib/config.py uses it.
[20:14] <garyvdm> do uncommits, and then branch
[20:57] <lifeless> moin
[21:00] <lifeless> jam: ping
[21:00] <jam> morning lifeless
[21:00] <lifeless> howzitgoing?
[21:03] <jam> pretty good
[21:03] <lifeless> jam: so, recompressing
[21:05] <jam> I'm trying to evaluate real-world effect. but making branching from scratch significantly slower isn't a real gain, IMO
[21:05] <jam> if it was only incremental, then maybe
[21:06] <lifeless> Without this we will still fragment
[21:06] <lifeless> sue to incremental pushes to common repos
[21:06] <lifeless> s/sue/due/
[21:07] <jfroy|work> jelmer: wasn't there a way to see the svn revision associated with a particular bzr revision? I can't seem to find that info anywhere.
[21:07] <lifeless> now, I desire us to have a hybrid, but its not clear to me that we should block 2.0 on having a hybrid
[21:08] <jam> lifeless: incremental pushes will eventually autopack
[21:08] <jam> so we won't fragment in the same way that we were
[21:09] <lifeless> jam: yes, but that argument applies to the prior code too
[21:09] <lifeless> there were two causes of fragmentation: separate push events, and group filtering
[21:10] <lifeless> there is currently one cause of combining - pack
[21:10] <jam> lifeless: sure, though the latter was a much bigger portion of it
[21:10] <jam> lifeless: well, autopack combines
[21:10] <lifeless> jam: yes
[21:10] <jam> so incremental push /pulling has a chance to pack everything but the initial stuff
[21:10] <lifeless> jam: I'm not classing autopack as fundamentally different
[21:11] <lifeless> jam: except that the user doesn't /choose/ it
[21:11] <lifeless> jam: right
[21:11] <lifeless> so an initial pull of LP, with large amounts of history, is going to take ages before the next auto-complete-pack
[21:12] <lifeless> but the data that was pulled will be read from many many times
[21:12] <lifeless> wow! hg fast export has sbeen running for 24 hours now
[21:12] <lifeless> still not finished
[21:12] <jam> lifeless: exporting what?
[21:12] <lifeless> netbeans
[21:13] <lifeless> 40G stream so far
[21:13] <lifeless> I was looking at the chance of quick-hack to make an hg plugin for it
[21:14] <lifeless> sadly way to high a cost to fit in opportunistic coding time
[21:14] <lifeless> but having done hg branch (1.6G ofdata, 90K files, 133K revs), I figured I may as well get a test case for 2a from it
[21:14] <jam> lifeless: do you mean a bzr plugin for netbeans ?
[21:15] <lifeless> yes
[21:15]  * lifeless adds caffeine
[21:16] <jam> argh.... with a fresh windows install, I decided to try py26, overall nice, but now pycrypto spewes 2 deprecation warnings everytime I connect via ssh :(
[21:16] <lifeless> urgh
[21:16] <lifeless> rmeinds me
[21:16] <jam> I think there is an open bug about pycrypto and python2.6
[21:17] <lifeless> I should send the python 2.6 fixes to pyrex upstream
[21:17] <jam> but they haven't released a new pycrypto yet
[21:17] <jam> lifeless: the Exception issues?
[21:17] <lifeless> yeah
[21:17] <jam> lifeless: I'd rather we switched to cython :)
[21:17] <lifeless> jam: I want us to reevaluate our external deps
[21:18] <lifeless> I'd like cython, testresources, testscenarios, subunit, sphinx, all to become hard build deps
[21:18] <lifeless> We also need to start versioning the output of cython so we can build it on pqm
[21:18] <lifeless> and elsewhere
[21:19] <lifeless> have you converted mysql-server into 2a?
[21:19] <jam> lifeless: not recently, but I did do testing in the past w/ mysql
[21:20] <lifeless> I'm going to talk focusedly at drizzle today
[21:20] <lifeless> mtaylor: ^
[21:20] <beuno> mwhudson, +1 to upgrade loggerhead to 2a?  it's alrady 1.9-rr anyway...
[21:20] <jam> lifeless: so I think there is distinctly several possible tradeoff points for the balance between recompression on the fly none, some, all. I think unordered + none is a better tradeoff today than all, and we can write a 'some' implementation for the next release.
[21:21] <mtaylor> lifeless: ola
[21:21] <jam> lifeless: http://bazaar-vcs.org/Roadmap/BrisbaneCore/Details scroll down to: $ du mysql-5.1-test
[21:21] <lifeless> mtaylor: drizzle should upgrade to 2a
[21:21] <jam> mysql 5.1 at that stage went from 501MB => 170MB on disk
[21:22] <mtaylor> lifeless: it's ready for us to convert all of our branches?
[21:22] <lvh> apparently so!
[21:22] <lvh> dash is doing it for twisted
[21:22] <lvh> and twisted is super important
[21:22] <jam> lvh: launchpad itself has been using it for a while
[21:23] <lifeless> mtaylor: the bug you encountered on libcpuinfo is fixed
[21:23] <mtaylor> ok. cool
[21:23] <lvh> jam: yeah, apparently my fears of pre-release non-default repo formats eating my data is unfounded
[21:23] <mtaylor> lifeless: what's the version of bzr that it requires?
[21:23] <lvh> s/is/are/
[21:23] <lifeless> 2.0rc1 should be pretty damn solid, even though we have landed more bug fixes since
[21:23] <lvh> mtaylor: 1.16 or something.
[21:23] <lifeless> mtaylor: I suggest 2.0rc1
[21:23] <lvh> mtaylor: it's been around for a few releases
[21:24] <lvh> 2, I believe
[21:24] <lifeless> mtaylor: 1.16 and up can read-write it
[21:24] <lifeless> mtaylor: but there are bugs in those versions that make it desirable to upgrade all the way
[21:24] <mtaylor> so, I have to get about 50 people to upgrade their bzr ... so I need to be real specific. do I need to have them upgrade to 1.16? or to 2.0rc1?
[21:24] <lvh> lifeless: if I want to use 2a for my branch I have to wait until the maintainer for the main project updates everything to 2a first, right?
[21:24] <mwhudson> beuno: sure
[21:25] <lifeless> lvh: if they are on a rich-root format, you can upgrade early and send bundles
[21:25] <lifeless> lvh: if they aren't on a rich root format, you have to wait
[21:25] <lvh> I think they are.
[21:25] <beuno> Peng_, upgrading LH to 2a
[21:26] <jam> lifeless: it seems the bazaar wiki will lock you out if you hit Preview too frequently... :(
[21:26] <lifeless> jam: lol
[21:26]  * mtaylor now considers whether to upgrade all of our branches to 2a while brian is at burningman
[21:27] <lifeless> mtaylor: let me get an estimate for drizzle
[21:27] <jam> and, of course, it doesn't tell you how long the lockout period is, and it warns that submitting too soon may increase the lockout time...
[21:27] <jam> is it seconds, minutes, an hour?
[21:27] <jam> argh
[21:27] <lifeless> #is
[21:28] <lifeless> 8-way machines <3
[21:28] <lifeless> hah, conversion error
[21:29] <mtaylor> heh.
[21:29]  * mtaylor will wait until that is fixed :)
[21:29] <beuno> anyone know how to remove a backup.bzr dir from LP?  hitchhiker tracebacks when using rm
[21:29]  * lifeless reconciles drizzle
[21:30] <beuno> abentley, ^ any ideas?
[21:30] <lifeless> beuno: whats the traceback?
[21:30] <lifeless> beuno: also, I know that lftp works
[21:30] <mtaylor> beuno: lftp
[21:30] <abentley> beuno: rmtree.
[21:30] <beuno> wow
[21:30] <beuno> that's it, rmtree
[21:30] <beuno> thanks abentley
[21:30] <beuno> and lifeless and mtaylor
[21:30] <abentley> beuno: np
[21:31] <beuno> we really need to fix this to smoothen upgrades
[21:31]  * mtaylor AGREES
[21:31] <abentley> beuno: See also: https://answers.edge.launchpad.net/launchpad/+faq/675
[21:31]  * mtaylor would sort of love it if there were a button on launchpad that said "upgrade"
[21:31] <beuno> mtaylor, rockstar had that on his plate for a while
[21:31] <beuno> I even got a nice icon for him
[21:31] <beuno> but something... happened
[21:32] <mtaylor> hewh
[21:32]  * rockstar looks up
[21:32] <mtaylor> rockstar: bzr branch upgrade button ftw?
[21:32] <lifeless> mtaylor: There is a bug. Put it in your wishlist for lp :)
[21:32] <lifeless> unless you've done one already
[21:33] <mtaylor> lifeless: prolly have :)
[21:33] <mtaylor> lifeless: I think around the time I upgraded drizzle to 1.9
[21:33] <lifeless> mtaylor: there is a thread on lp-users
[21:33] <lifeless> mtaylor: about 3 wishes for lp
[21:34] <lifeless> mtaylor: it is to that that I refer
[21:34] <mtaylor> oh, right
[21:35] <lifeless> I'm getting 6 GB of ram for this machine today
[21:35] <lifeless> \o/
[21:35] <rockstar> mtaylor, so, the work is basically done, except that we need to actually upgrade the branch without blocking your work.
[21:35] <lifeless> rockstar: really?
[21:35] <lifeless> rockstar: I would have thought blocking there work was expected
[21:35] <rockstar> lifeless, you were there when Mark told us we need to.
[21:36] <rockstar> (it was at lunch at AllHands)
[21:36] <lifeless> rockstar: oh right. sadness
[21:36] <rockstar> lifeless, it's not a big deal, and actually an excellent point.  However, then we got other things.  I'm sure we'll get back to it soon after 3.0
[21:37] <lifeless> rockstar: well if its easy to go great, its obviously better than blocking. OTOH I still think that most projects are so small they wouldn't notice or care
[21:37] <lifeless> s/to go/to do/
[21:38] <lifeless> jam: I want to use knowngraph in reconcile/check
[21:38] <lifeless> jam: can you think of any gotchas?
[21:38] <rockstar> lifeless, I think the most difficult thing to worry about is the chicken and egg upgrading of stacked branches.
[21:38] <lifeless> rockstar: we've fixed that upstream
[21:39] <lifeless> rockstar: bzr upgrade URL_of_stacking_branch just works now
[21:39] <lifeless> you can't use the branch till thats done - so lp should do a reverse graph walk and fix them up
[21:40] <rockstar> lifeless, oh, awesome.  I think I have some projects to upgrade then.
[21:40] <lifeless> use 2.0rc1
[21:40] <jam> lifeless: I don't know of any specific gotchas, other than you need to have the whole graph, but you should have that for check/reconcile
[21:40] <lifeless> not because its strictly needed for that
[21:40] <lifeless> but it has the most fixes
[21:40] <jam> It doesn't currently expose a way to get the individual parents
[21:40] <jam> but garyvdm put together a patch for that
[21:41] <lifeless> bugger :( reconciled drizzle fails to upgrade too.
[21:41]  * lifeless bugginates
[21:41] <garyvdm> Hi jam and lifeless
[21:41] <jam> so garyvdm, was the code you were using already using iter_merge_sort?
[21:41] <jam> (the code you 'improved' to start using KnownGraph)
[21:42] <jam> I believe it is Branch.iter_merge_sorted_revisions()
[21:42] <jam> as if you want to look for a perf improvement, it iter_merge_sorted_revisions was updated to use KnownGraph internally
[21:42] <garyvdm> jam: let me have a look
[21:42] <jam> so you may need to compare between versions of bzr, rather than qbzr w/ vs w/o KnownGraph support
[21:44] <garyvdm> jam: I we were previously using bzrlib.tsort.merge_sort
[21:44] <garyvdm> Not Branch.iter_merge_sorted_revisions, because we have to handle multiple branches
[21:44] <jam> ah, ok
[21:46] <garyvdm> jam: If you are intrested: lp:~garyvdm/qbzr/knowngraph
[21:46] <garyvdm> jam: I need so time to profile it in detail to see why it is not faster.
[21:46] <jam> garyvdm: taking a look
[21:50] <jam> garyvdm: so... the *biggest* improvement you could get is switching to the find_ancestry stuff, which doesn't yet support multiple sources
[21:50] <jam> merge_sort itself is probably at most a second or so of your runtime
[21:51] <garyvdm> Jam: I agree
[21:52] <garyvdm> jam: I also can only initialy load the mainline. That would be a big win.
[21:55] <jam> garyvdm: you might try something like this: http://paste.ubuntu.com/263407/
[21:56] <jam> and see if that gets you somewhere nice
[22:12] <lifeless> hi garyvdm
[22:17] <lifeless> jam: https://bugs.edge.launchpad.net/bzr/+bug/422849
[22:17] <jam> lifeless: I don't know anything offhand other than: https://bugs.launchpad.net/bugs/422423
[22:18] <jam> which Martin just reported
[22:18] <lifeless> I'll track this one down
[22:18] <lifeless> and see if it fixes martins after that
[22:18] <lifeless> could be a common cause with different visible effects
[22:19] <jam> obviously the guess is that there is a problem with the computation of the delta
[22:19] <lifeless> :)
[22:20] <lifeless> I'll be getting more conversion timing data
[22:20] <lifeless> as well
[22:22] <jam> istr converting mysql took about 2 days on a rather old machine
[22:23] <lifeless> typo
[22:23] <lifeless> I meant 'fetch timing'
[22:23] <lifeless> I will be doing this netbeans repo test conversion
[22:24] <lifeless> partly to say to the sun folks how great it is :)
[22:24] <lifeless> and also to see how we do: 1G of 1.7G are manifests.
[22:24] <emmajane> poolie, morning
[22:24] <poolie> hello emmajane, lifeless
[22:25] <lifeless> hi poolie
[22:25] <lifeless> poolie: 'Slack' is highly entertaining. I think I'm an eve :P
[22:25] <poolie> hm
[22:25] <poolie> i don't recall that bit, is that one of the personas?
[22:26] <lifeless> poolie: yes, the first one
[22:26] <lifeless> seeks growth & challenge
[22:30] <lifeless> poolie: so you know, drizzle isn't converting to 2a either
[22:31] <lifeless> I'm investigating now. It may have a common cause with the error you had yesterday. Or maybe not.
[22:31] <poolie> because, not yet, or because?
[22:31] <poolie> oh i see
[22:31] <lifeless> 'fails to convert'
[22:31] <poolie> i was going to work today with igc on content filtering
[22:31] <poolie> anyhow breakfast first
[22:31] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/422849
[22:31] <lifeless> Once I know the cause I'll target it etc
[22:32] <lifeless> still gathering details/assessing
[22:34] <poolie> hm
[22:34] <poolie> i tested mysql a little while ago
[22:34] <poolie> i could retest it, which would narrow the problem to whatever time window that was
[22:34] <poolie> i was thinking i
[22:34] <lifeless> drizzle != mysql though, different history
[22:34] <poolie> ... well i was but i'll tell you later
[22:34] <poolie> true
[22:35] <beuno> HPSS calls: 8670 (8668 vfs)
[22:35] <beuno> \o/
[22:35] <beuno> (upgrading LH to 2a)
[22:35] <lifeless> WTB: network upgrade.
[22:35] <beuno> :)
[22:40] <beuno> mwhudson, Peng_, lh is on 2a
[22:41]  * mwhudson runs upgrade locally
[23:47] <lifeless> mtaylor: drizzle only drops 14MB in 2a
[23:47] <lifeless> mtaylor: what do you have in there..binaries?
[23:49] <lifeless> found the bug
[23:54] <igc> morning
[23:59] <mtaylor> lifeless: nope. no binaries for us!
[23:59] <lifeless> spiv: what tests would be the closest ones to the ones you changed in your ids-only-necessary-texts for bug 422849
[23:59] <mtaylor> lifeless: why don't we drop more?
[23:59] <lifeless> mtaylor: I don't know yet


[06:59] <immaozhou> Launchpad can not build ddeb package, how to solve it ?
[07:42] <immaozhou_> Launchpad can not build ddeb package, how to solve it ?


[00:25] <tsimonq2> agaida: bump the bug report with my patch then
[00:25] <tsimonq2> agaida: and talk to Julien!
[00:25] <agaida> we have one problem - julien think he is right
[00:26] <agaida> and this is more important for him than easy maintainance and possible bugs
[00:27] <agaida> so what should i do? I'm only a outsider with a very strong opinion - and the plan was that we do the things upstream and they go into the repository unchanged
[00:28] <agaida> and to be honest - every not really needed change is bullshit and error prone - and that for a reason
[00:28] <tsimonq2> sorry
[00:28] <tsimonq2> but I see
[00:29] <tsimonq2> I'll bump it
[00:29] <tsimonq2> thank you for bringing this up to me, I'll get it handled
[00:29] <agaida> if one without this special knowledge import upstream - without the changes - this will create havoc
[00:30] <agaida> and this is happend in the past and ever will happen again
[00:31] <agaida> so we had two bets - a) we will do everything to make julien happy or b) we will do what we think is the best
[00:32] <agaida> (we as debian upstream) - please guess what we will do
[00:32] <tsimonq2> I see
[00:33] <agaida> and we are happy if bugs - or patches come from ubuntu - this is happend in the past from vorlon (architectural changes and symbol changes) and we merged them without any problems
[00:34] <tsimonq2> vorlon \o/
[00:34] <agaida> because the changes make sense for both parties
[00:34] <tsimonq2> I see
[00:35] <agaida> yeah - steve is a good one - and i will never forget that he was the cause that i'm fixed systemd on a silvester evening :D
[00:36] <agaida> so we have no problems with good changes - but i think we have a problem with bikeshedding and such things
[00:38] <tsimonq2> yeah
[00:39] <agaida> and to be true - i have some problems with the two remainig changes - both on central points: the changes in lxqt-session is great to shoot on or both feets - in it will happen sooner or later
[00:42] <agaida> and we talked about liblxqt - best bet would be to take debian unchanged - and if this cause problems, solve these problems in debian (like eventually needed breaks and replaces)
[00:42] <agaida> and another word regarding the session thing - julien is right, it's not clever and his solution is better - in theory
[00:42] <tsimonq2> alright
[00:43] <tsimonq2> yeah I saw the solution
[00:43] <tsimonq2> it was something I didn't want to touch
[00:43] <agaida> but it is not clever as it will break when we clean up this mess in LXQt - and that will be happen some weeks or month after the release
[00:43] <agaida> but it will happen
[00:45] <tsimonq2> agaida: ping me when the breakage is about to happen and I'll talk with Julien
[00:45] <tsimonq2> ask him why
[00:45] <agaida> the session/common mess is long standing - no one clean up this shit after the merger razorqt/lxde
[00:45] <tsimonq2> yeah
[00:46] <agaida> and this was introduced because in the beginning the whole razor was one big repository
[00:47] <agaida> so after the merge the repos was splitted up and the rest that no one take care or becomes common - long story short
[00:47] <agaida> s/or/of
[00:49] <agaida> but i think we will find a clean solution and a clean upgrade path - and we should not make things more complicated
[00:49] <agaida> in the meantime
[00:51] <tsimonq2> yeah
[00:52] <tsimonq2> wxl: re: broken torrents, this is why it's good to read Reddit comments... https://www.reddit.com/r/Lubuntu/comments/4txypi/lubuntu_16041_lts_has_been_released/d5nrwhs
[00:53] <tsimonq2> agaida: a Reddit user reported that the Lubuntu torrents are broken and indeed they are, yay...
[00:53] <agaida> and i destroyed today the gogs database for siduction - that was cool
[00:54] <tsimonq2> \o/
[00:54] <tsimonq2> :P
[00:54] <agaida> 100+ git repositories to migrate by hand
[00:54] <tsimonq2> O__O
[00:54] <agaida> a fucking typo in a script
[00:54] <Unit193> tsimonq2: Or, you could update the link to the torrent for the point release too...
[00:54] <agaida> but its done
[00:54] <tsimonq2> Unit193: I don't have the permissions
[00:54] <tsimonq2> Unit193: but I pinged infinity
[00:56] <Unit193> And infinity can update lubuntu.net how?
[00:57] <tsimonq2> Unit193: lubuntu.net is NOT our website
[00:58] <tsimonq2> Unit193: lubuntu.me is
[00:58] <Unit193> Yeah yeah, same thing.  Used to real TLDs, same statement applies to .me.
[00:59] <tsimonq2> well that's actually a good idea, I should updated that
[00:59] <tsimonq2> *update
[00:59] <tsimonq2> Unit193: but regardless, that torrent doesn't work
[00:59] <Unit193> Try the correct torrent?
[01:00]  * tsimonq2 tries
[01:01] <Unit193> It's pretty darn normal when a point release is out, the prior point (or pointless) release isn't on the tracker...
[01:01] <tsimonq2> works fine
[01:02] <tsimonq2> Unit193: but regardless...it's broken
[01:02] <Unit193> Define 'it'.
[01:03] <tsimonq2> the torrents for 16.04
[01:03] <tsimonq2> Unit193: it's also a pretty major thing because we didn't release PPC for 6.04.1 but we did for 16.04
[01:03] <tsimonq2> *16.04.1
[01:03] <tsimonq2> some people still might want PPC
[01:10] <tsimonq2> Unit193: there, updated
[01:10] <tsimonq2> http://lubuntu.me/downloads/
[10:14] <kalxas> hi all, I am looking for the build scripts that are used to generate the Lubuntu iso images. Can someone please point me to the source code?
[10:16] <tsimonq2> kalxas: hey
[10:16] <kalxas> hi tsimonq2
[10:16] <tsimonq2> kalxas: infinity in #ubuntu-release linked it to me the other day
[10:16] <tsimonq2> now that I have time, I'll search my IRC logs :)
[10:16] <kalxas> cool, thanks :)
[10:17] <kalxas> I did find some source code in launchpad yesterday, but that was until utopic
[10:18] <kalxas> http://bazaar.launchpad.net/~lubuntu-desktop/+junk/lubuntu-tools/view/head:/iso/lubuntu-build.sh
[10:18] <kalxas> so I am looking specifically for xenial sources
[10:19] <kalxas> the reason is to find the difference
[10:19] <kalxas> it seems that the usb-creator util is now doing a plain dd copy of the iso to the usb key, so I need to figure out how boot loader is handled
[10:21] <tsimonq2> bingo
[10:21] <tsimonq2> lp:~ubuntu-cdimage/debian-cd/ubuntu
[10:21] <tsimonq2> kalxas: ^
[10:23] <kalxas> thanks tsimonq2 !
[10:23]  * kalxas looking
[10:31] <kalxas> tsimonq2, still, there is no lubuntu branch in there
[10:31] <kalxas> actually there is one which is outdated
[10:43] <tsimonq2> kalxas: it's not a Lubuntu-specific branch you are looking for
[10:43] <tsimonq2> you need to know how the images are built
[10:43] <tsimonq2> daily and daily-live
[10:46] <kalxas> I am obviously not aware of the process :)
[10:47] <kalxas> thank you for your patience
[10:50] <kalxas> is this also being used? it seems up to date:
[10:50] <kalxas> http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/files
[10:51] <tsimonq2> well if I remember correctly, that calls the server that runs lp:~ubuntu-cdimage/debian-cd/ubuntu
[10:52] <kalxas> ah, cool
[10:53] <kalxas> tsimonq2, any idea how long has this code base being used?
[10:53] <tsimonq2> long time
[10:54] <kalxas> I will have to browse history then to figure out what happened with the boot loader
[10:54] <kalxas> ok, thank you very much for your help


[02:06] <xubuntu96w> I am trying to install Ubuntu on an old Celeron D processor desktop with 512 MB RAM and get an error with Ubuntu 10.4 "Kernel requires a x86-64 CPU, but only detected an i686 CPU. "
[02:07] <xubuntu96w> I am considering installing xubuntu now, sice some posts on the internet indicated that xubuntu will be better suited for such an old machine
[02:08] <xubuntu96w> Can some one suggest the appropriate version of xubuntu to use?
[07:54] <Regor> memory is so cheap nowadays . its better to upgrade ..
[16:02] <deadrom> hi. had xub16.04LTS, then 18.04LTS for years on a Thinkpad T530 with 2 monitors on a docking station. I suspend-to-RAM when machine is not in use. worked fine for ages.
[16:04] <deadrom> then replace the T530 with a Dell M4800 mobile workstation, migrated the SSD over and so far it works really good but: when waking up from suspend all sort of things happen with the monitor setup. sometimes 2 mirrors 1, sometimes I lose one monitor, sometimes 1 gets stretched to 3840x1200, and the "config displays" thing pops up
[16:06] <deadrom> http://paste.ubuntu.com/p/msFNSy9QtH/ this script *mostly* sets things back ok, but I think it's an issue with how the docking station powers up. I think the ports are powered up too late so xubunut forgets, then rediscovers the monitors after resume. any idea what to do about that?
[16:15] <brainwash> deadrom: does it happen when screen locking is disabled?
[16:15] <deadrom> brainwash: is disabled.
[16:16] <brainwash> Xfce 4.14 has improved disabled handling, but it's only available in 19.10 or via PPA for 18.04
[16:16] <brainwash> ehm
[16:17] <brainwash> display handling
[16:17] <diogenes_> deadrom, you could try to setup monitors with xorg instead of user settings.
[16:17] <deadrom> diogenes_: https://xkcd.com/963/
[16:18] <deadrom> but good point, I never checked xorg.conf for old cruft from the Thinkpad era...
[16:18] <deadrom> brainwash: stable PPA?
[16:19] <brainwash> https://launchpad.net/~xubuntu-dev/+archive/ubuntu/staging
[16:19] <diogenes_> deadrom, https://www.youtube.com/watch?v=lhiLWxJgiAo&list=PL_SzaGshm1xfgTnMtW9A50ff2JokazGZx&index=4&t=0s
[16:19] <brainwash> I guess you can call it stable
[16:21] <deadrom> brainwash: gonna try
[16:21] <brainwash> Xfce 4.14 allows you to save and restore display profiles
[16:21] <brainwash> but still, it's not guaranteed that it solves your problem
[16:21] <brainwash> and installing 4.14 may bring in new issues too
[16:23] <brainwash> (whiles fixing many others obviously)
[16:24] <deadrom> diogenes_: http://paste.ubuntu.com/p/KJzCnXqMJv/  <- that's some old cruft there from my last machine... the 5400M, the display names espacially.
[16:24] <deadrom> maybe I go clean up there first
[19:44] <xubuntu76w> Hi, good afternoon
[19:44] <xubuntu76w> It's ok to use Xubuntu with AMD Ryzen 3 2200g?
[19:48] <tomreyn> hi xubuntu76w, i don't see why not. you may want a recent kernel, though
[20:14] <genii> tomreyn: AFAIK there are still no GPU drivers for it
[20:28] <tomreyn> genii: i think DCN1.0 is supported since linux 4.16, but 5.0, 5.2 and 5.4 may have improved upon it.
[20:29] <genii> Hm
[20:30] <tomreyn> i dont have first hand experience though


[15:24] <hannie> hi crhrabal glad you can attend the meeting
[15:24] <crhrabal> yeah i'll be there hannie :-)


[14:26] <iduck> bazhang: 肏你妈
[14:27] <iduck> !ops
[14:27] <Pici> iduck: Whats up?
[14:27] <Pici> not much I guess.
[14:28] <Myrtti> icesword, judging from Modus Operandi
[14:28] <bazhang> icesword as we live and breathe
[14:28] <bazhang> still the same stale insults
[14:43] <ikonia> @mark #ubuntu-offtopic iduck removed icewords for long term trolling the ubuntu name space, raising request to IRCC for perm ban
[16:29] <k1l_> !lag
[16:29] <Pici> hm
[16:29] <Pici> !paste
[16:29] <k1l_> didnt join #ubuntu
[16:29] <Pici> I'll poke it
[16:29] <Pici> give it a sec ;)
[16:43] <k1l_> hmm, its the time when people can upload a screenshot but cant upload to a pastebin?