[00:37] -queuebot:#ubuntu-release- Unapproved: snapd-glib (disco-proposed/main) [1.47-0ubuntu1 => 1.47-0ubuntu2] (desktop-core)
[01:24] -queuebot:#ubuntu-release- Unapproved: openjdk-lts (disco-proposed/main) [11.0.3+4-1ubuntu1 => 11.0.3+4-1ubuntu2] (core)
[01:34] <Trevinho> anyone in the SRU team could review syncs for unity in bionic and xenial? https://code.launchpad.net/~3v1n0/ubuntu-archive-tools/sru-review-bileto-support/+merge/364193
[01:34] <Trevinho> use this tool to review if you want to the process in classic way :)
[02:08] <bluesabre> Does it look like we're going to have any respins, or do the current images look like they'll be the beta release images?
[02:14] <valorie> we found very few bugs so far in kubuntu
[02:15] <bluesabre> nice, xubuntu likewise seems A-OK. Planning to mark it ready when I get up tomorrow.
[03:14] -queuebot:#ubuntu-release- Unapproved: collectd (bionic-proposed/universe) [5.7.2-2ubuntu1 => 5.7.2-2ubuntu1.1] (no packageset)
[04:23] -queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (disco-proposed) [1.47-0ubuntu2]
[05:42] -queuebot:#ubuntu-release- New sync: r-cran-lwgeom (disco-proposed/primary) [0.1-5+repack-1]
[06:21] <handsome_feng> Hi, could anyone in release team help to upload ukui-greeter which fix LP: #1822014 before beta release?
[06:21] <ubot5`> Launchpad bug 1822014 in Ubuntu Kylin "ukui-greeter failed to launch on ubuntukylin 19.04 beta iso" [Critical,Confirmed] https://launchpad.net/bugs/1822014
[06:23] <handsome_feng> The new version of ukui-greeter is stored at: https://launchpad.net/~ubuntukylin-members/+archive/ubuntu/1904updates
[06:33] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (disco-proposed) [11.0.3+4-1ubuntu2]
[06:35] <doko> ginggs: I'm moving the tracker. Don't want to drop gcc-7 before we get the bionic update in place
[07:40] -queuebot:#ubuntu-release- Unapproved: spirv-llvm-translator (disco-proposed/universe) [8.0.0-3 => 8.0.0+git20190314-0ubuntu1] (no packageset)
[07:41] -queuebot:#ubuntu-release- Unapproved: accepted spirv-llvm-translator [source] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
[07:45] -queuebot:#ubuntu-release- New binary: spirv-llvm-translator [amd64] (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1] (no packageset)
[07:45] -queuebot:#ubuntu-release- New binary: spirv-llvm-translator [ppc64el] (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1] (no packageset)
[07:45] -queuebot:#ubuntu-release- New binary: spirv-llvm-translator [i386] (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1] (no packageset)
[07:45] -queuebot:#ubuntu-release- New binary: spirv-llvm-translator [s390x] (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1] (no packageset)
[07:50] -queuebot:#ubuntu-release- New binary: spirv-llvm-translator [arm64] (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1] (no packageset)
[07:51] -queuebot:#ubuntu-release- New binary: spirv-llvm-translator [armhf] (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1] (no packageset)
[08:31] -queuebot:#ubuntu-release- Unapproved: openjdk-12 (disco-proposed/universe) [12.0.0-2 => 12.0.0-3] (no packageset)
[08:35] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-12 [source] (disco-proposed) [12.0.0-3]
[08:50] -queuebot:#ubuntu-release- Unapproved: ukui-screensaver (disco-proposed/universe) [2.0.4-1 => 2.0.5-0ubuntu1] (ubuntukylin)
[08:51] -queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [amd64] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
[08:51] -queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [armhf] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
[08:51] -queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [ppc64el] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
[08:51] -queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [arm64] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
[08:51] -queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [s390x] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
[08:51] -queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [i386] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
[09:12] <acheronuk> handsome_feng: without that ukui-greeter fix, your beta iso will be useless?
[09:13] <handsome_feng> acheronuk: Yes... :(
[09:14] <acheronuk> vorlon apw infinity ^^
[09:14] <acheronuk> Other release team are away I think?
[09:15] <willcooke> heh, I was just going to say that.  Thanks for picking it up acheronuk
[09:16] <handsome_feng> acheronuk, willcooke : Thank you all!
[09:45] -queuebot:#ubuntu-release- Unapproved: gdcm (disco-proposed/universe) [2.8.8-7ubuntu1 => 2.8.8-9ubuntu1] (kubuntu)
[09:51] -queuebot:#ubuntu-release- Unapproved: ruby2.5 (disco-proposed/main) [2.5.3-4ubuntu1 => 2.5.5-1ubuntu1] (ubuntu-desktop, ubuntu-server)
[09:59] <LocutusOfBorg> yay!!! ruby CVE fixes ^^
[10:03] -queuebot:#ubuntu-release- Unapproved: cups-filters (disco-proposed/main) [1.22.2-1 => 1.22.3-1] (desktop-core, ubuntu-server) (sync)
[10:05] -queuebot:#ubuntu-release- Unapproved: openjdk-lts (disco-proposed/main) [11.0.3+4-1ubuntu2 => 11.0.3+4-2ubuntu1] (core)
[10:05] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (disco-proposed) [11.0.3+4-2ubuntu1]
[10:11] -queuebot:#ubuntu-release- Unapproved: ant (disco-proposed/universe) [1.10.5-2ubuntu1 => 1.10.5-3] (no packageset)
[10:12] -queuebot:#ubuntu-release- Unapproved: accepted ant [source] (disco-proposed) [1.10.5-3]
[10:18] <jdstrand> hi! apparmor was granted it's FFe by infi nity a couple days ago. after some iterations on its new-in-Ubuntu, Debian-introduced autopkgtests, it is now migratable
[10:18] <jdstrand> it isn't migrating due to "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)"
[10:19] <doko> afaik it's beta release today
[10:19] <jdstrand> I was gonna say I thought I remembered that
[10:20] <doko> jdstrand: did you see the firewalld autopkg test regressions?
[10:21] <jdstrand> doko: yes and I filed a bug for the desktop team: https://bugs.launchpad.net/ubuntu/+source/firewalld/+bug/1821596
[10:21] <ubot5`> Ubuntu bug 1821596 in firewalld (Ubuntu) "firewalld ipset autopkgtest failures" [High,Confirmed]
[10:21] <jdstrand> basically it failed for two reasons: 1.8.2 iptables and it needs newer ipset
[10:22] <doko> ahh, ok
[10:23] <jdstrand> I did the updates to firewalld so it didn't require iptables, but knew that it would still fail for ipset. seb128 already was working on the ipset bits, so handed back off to him
[10:23] <jdstrand> (didn't require iptables 1.8*)
[10:26] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Disco Beta] has been marked as ready
[10:35] <acheronuk> handsome_feng: by the way, "fix committed" in a bug usually means it's been uploaded to the archive but not migrate to release pocket yet. So probably not good to set that status until its really done, as at a glance people will just assume it doesn't need sponsoring any more
[10:41] <handsome_feng> acheronuk: Thanks, I will change the status now
[10:43] <handsome_feng> Oh, acheronuk has done that, Thanks acheronuk!
[10:49] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Disco Beta] has been marked as ready
[10:49] -queuebot:#ubuntu-release- Unapproved: gigolo (disco-proposed/universe) [0.4.90-1 => 0.4.91-0ubuntu1] (ubuntustudio, xubuntu)
[10:51] <bluesabre> I didn't see the all flavors beta release note anywhere, but here's the Xubuntu release note in case I'm not around later today: https://wiki.xubuntu.org/releases/19.04/release-notes
[11:50] -queuebot:#ubuntu-release- Unapproved: ant (cosmic-proposed/universe) [1.10.5-2ubuntu1~18.10 => 1.10.5-3~18.04] (no packageset) (sync)
[11:51] -queuebot:#ubuntu-release- Unapproved: accepted ant [sync] (cosmic-proposed) [1.10.5-3~18.04]
[12:14] -queuebot:#ubuntu-release- Unapproved: ukui-biometric-auth (disco-proposed/universe) [1.0.2-1 => 1.0.3-2] (ubuntukylin) (sync)
[12:14] -queuebot:#ubuntu-release- New source: intel-opencl-clang (disco-proposed/primary) [8.0.0-0ubuntu1]
[12:34] -queuebot:#ubuntu-release- Unapproved: gcc-8-cross (disco-proposed/main) [26ubuntu1 => 27ubuntu1] (ubuntu-desktop)
[12:34] -queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (disco-proposed/universe) [19ubuntu1 => 20ubuntu1] (no packageset)
[12:36] -queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [source] (disco-proposed) [20ubuntu1]
[12:36] -queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [source] (disco-proposed) [27ubuntu1]
[13:03] -queuebot:#ubuntu-release- Unapproved: python-intervaltree-bio (disco-proposed/universe) [1.0.1-3 => 1.0.1-3ubuntu1] (no packageset)
[13:04] -queuebot:#ubuntu-release- Unapproved: accepted python-intervaltree-bio [source] (disco-proposed) [1.0.1-3ubuntu1]
[13:19] -queuebot:#ubuntu-release- Unapproved: openjdk-lts (cosmic-proposed/main) [11.0.2+9-3ubuntu1~18.10.1 => 11.0.2+9-3ubuntu1~18.10.2] (core) (sync)
[13:20] -queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.5 [source] (xenial-proposed) [9.5.16-0ubuntu<IP_ADDRESS>]
[13:26] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (cosmic-proposed) [11.0.2+9-3ubuntu1~18.10.2]
[13:40] -queuebot:#ubuntu-release- Unapproved: openjdk-lts (bionic-proposed/main) [11.0.2+9-3ubuntu1~18.04.1 => 11.0.2+9-3ubuntu1~18.04.2] (ubuntu-desktop) (sync)
[13:41] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (bionic-proposed) [11.0.2+9-3ubuntu1~18.04.2]
[13:41] -queuebot:#ubuntu-release- Unapproved: hovercraft (disco-proposed/universe) [2.6-2 => 2.6-2ubuntu1] (no packageset)
[13:42] -queuebot:#ubuntu-release- Unapproved: accepted hovercraft [source] (disco-proposed) [2.6-2ubuntu1]
[13:47] -queuebot:#ubuntu-release- Unapproved: accepted postgresql-10 [source] (bionic-proposed) [10.7-0ubuntu<IP_ADDRESS>]
[13:48] <rbasak> ^ I'm just working through postgresql MREs that I didn't finish on my shift yesterday
[13:52] -queuebot:#ubuntu-release- Unapproved: accepted postgresql-10 [source] (cosmic-proposed) [10.7-0ubuntu<IP_ADDRESS>]
[13:53] -queuebot:#ubuntu-release- Unapproved: mesa (disco-proposed/main) [19.0.0-1ubuntu1 => 19.0.1-1ubuntu1] (core, xorg)
[14:39] -queuebot:#ubuntu-release- Unapproved: boost1.67 (cosmic-proposed/main) [1.67.0-7 => 1.67.0-7ubuntu0.1] (core)
[14:42] -queuebot:#ubuntu-release- Unapproved: accepted boost1.67 [source] (cosmic-proposed) [1.67.0-7ubuntu0.1]
[14:50] -queuebot:#ubuntu-release- Unapproved: node-external-editor (disco-proposed/universe) [2.0.4+dfsg-1 => 2.0.4+dfsg-2] (no packageset) (sync)
[14:50] -queuebot:#ubuntu-release- Unapproved: node-opencv (disco-proposed/universe) [6.0.0+git20180416.cfc96ba0-2 => 6.0.0+git20180416.cfc96ba0-3] (no packageset) (sync)
[14:50] -queuebot:#ubuntu-release- Unapproved: node-jschardet (disco-proposed/universe) [1.6.0+dfsg-1 => 1.6.0+dfsg-3] (no packageset) (sync)
[14:50] -queuebot:#ubuntu-release- Unapproved: accepted node-external-editor [sync] (disco-proposed) [2.0.4+dfsg-2]
[14:51] -queuebot:#ubuntu-release- Unapproved: accepted node-opencv [sync] (disco-proposed) [6.0.0+git20180416.cfc96ba0-3]
[14:51] -queuebot:#ubuntu-release- Unapproved: accepted node-jschardet [sync] (disco-proposed) [1.6.0+dfsg-3]
[14:51] -queuebot:#ubuntu-release- Unapproved: libdatetime-timezone-perl (disco-proposed/universe) [1:2.23-1+2018i => 1:2.23-1+2019a] (kubuntu, mythbuntu) (sync)
[14:51] -queuebot:#ubuntu-release- Unapproved: ruby-carrierwave (disco-proposed/universe) [1.3.1-1 => 1.3.1-2] (no packageset) (sync)
[14:51] -queuebot:#ubuntu-release- Unapproved: ruby-colorator (disco-proposed/universe) [1.1.0-1 => 1.1.0-2] (no packageset) (sync)
[14:51] -queuebot:#ubuntu-release- Unapproved: ruby-classifier (disco-proposed/universe) [1.3.4-2 => 1.3.4-3] (no packageset) (sync)
[14:51] -queuebot:#ubuntu-release- Unapproved: accepted ruby-carrierwave [sync] (disco-proposed) [1.3.1-2]
[14:51] -queuebot:#ubuntu-release- Unapproved: accepted ruby-colorator [sync] (disco-proposed) [1.1.0-2]
[14:51] -queuebot:#ubuntu-release- Unapproved: ruby-doorkeeper-openid-connect (disco-proposed/universe) [1.5.2-1 => 1.5.5-1] (no packageset) (sync)
[14:52] -queuebot:#ubuntu-release- Unapproved: accepted ruby-classifier [sync] (disco-proposed) [1.3.4-3]
[14:52] -queuebot:#ubuntu-release- Unapproved: ruby-coveralls (disco-proposed/universe) [0.8.22-1 => 0.8.22-2] (no packageset) (sync)
[14:52] -queuebot:#ubuntu-release- Unapproved: ruby-globalid (disco-proposed/universe) [0.3.6-2 => 0.4.2-1] (no packageset) (sync)
[14:52] -queuebot:#ubuntu-release- Unapproved: ruby-openssl (disco-proposed/universe) [2.1.1-2 => 2.1.2-1] (no packageset) (sync)
[14:52] -queuebot:#ubuntu-release- Unapproved: ruby-model-tokenizer (disco-proposed/universe) [1.0.1-1 => 1.0.1-2] (no packageset) (sync)
[14:52] -queuebot:#ubuntu-release- Unapproved: ruby-version-sorter (disco-proposed/universe) [2.1.0+dfsg-1build2 => 2.2.4-1] (no packageset) (sync)
[14:53] -queuebot:#ubuntu-release- Unapproved: accepted ruby-coveralls [sync] (disco-proposed) [0.8.22-2]
[14:53] -queuebot:#ubuntu-release- Unapproved: accepted ruby-globalid [sync] (disco-proposed) [0.4.2-1]
[14:53] -queuebot:#ubuntu-release- Unapproved: accepted ruby-openssl [sync] (disco-proposed) [2.1.2-1]
[14:53] -queuebot:#ubuntu-release- Unapproved: accepted ruby-doorkeeper-openid-connect [sync] (disco-proposed) [1.5.5-1]
[14:53] -queuebot:#ubuntu-release- Unapproved: accepted ruby-version-sorter [sync] (disco-proposed) [2.2.4-1]
[14:53] -queuebot:#ubuntu-release- Unapproved: accepted ruby-model-tokenizer [sync] (disco-proposed) [1.0.1-2]
[15:07] -queuebot:#ubuntu-release- Unapproved: openjdk-lts (bionic-proposed/main) [10.0.2+13-1ubuntu<IP_ADDRESS> => 11.0.2+9-3ubuntu1~18.04.2] (ubuntu-desktop) (sync)
[15:08] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (bionic-proposed) [11.0.2+9-3ubuntu1~18.04.2]
[16:23] <infinity> handsome_feng: Why were you looking for a release team member to sponsor your package?  Literally any MOTU can upload that package. :/
[16:27] <handsome_feng> emm, because it is beta freeze? and I need the package to get into the archive before beta release
[16:28] <infinity> handsome_feng: If you found a sponsor last night, then asked the release team for an FFe to let it in, it would have gone faster. :)
[16:28] <infinity> handsome_feng: Well, and it's bugfix-only, so no need for an FFe.
[16:29] <infinity> handsome_feng: Anyhow, since no one else seemed to catch on to that detail and upload for you, I've just done so.
[16:30] <infinity> handsome_feng: Hopefully, you'll be able to test a respin in a couple of hours?
[16:30] -queuebot:#ubuntu-release- Unapproved: ukui-greeter (disco-proposed/universe) [1.1.7-2 => 1.1.8-0ubuntu1] (ubuntukylin)
[16:31] <handsome_feng> infinity: Thank you so much, I will test it! even i am sleepy...
[16:31] -queuebot:#ubuntu-release- Unapproved: accepted ukui-greeter [source] (disco-proposed) [1.1.8-0ubuntu1]
[16:32] <infinity> handsome_feng: I'll respin for you when it migrates.
[16:33] <handsome_feng> infinity: Thanks a looooooooot!
[16:50] <Eickmeyer> Found a nasty little UX bug in Ubiquity for Studio. Not a complete show stopper, but definitely something I'd like to get fixed before final. (bug 1822134)
[16:50] <ubot5`> bug 1822134 in Ubuntu Studio "Ubuntu Studio Installation - Black Text on Dark Gray" [High,Confirmed] https://launchpad.net/bugs/1822134
[17:11] <infinity> Eickmeyer: You say bug, I say hard-mode installer.
[17:11] <infinity> Eickmeyer: For the hardcore gamer in your life.
[17:11] <Eickmeyer> infinity: HAHAHAHAHAHA!!!!
[17:12] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Disco Beta] has been marked as ready
[17:13] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Disco Beta] has been marked as ready
[17:14] <Eickmeyer> It's not impossible to use, just a little inconvenient for looking at the header & footer. ;)
[17:22] -queuebot:#ubuntu-release- Unapproved: mongodb (bionic-proposed/universe) [1:3.6.3-0ubuntu1 => 1:3.6.3-0ubuntu1.1] (mozilla)
[17:25] -queuebot:#ubuntu-release- Unapproved: mongodb (cosmic-proposed/universe) [1:3.6.3-0ubuntu1 => 1:3.6.3-0ubuntu2.1] (mozilla)
[17:55] -queuebot:#ubuntu-release- Unapproved: netplan.io (disco-proposed/main) [0.96-0ubuntu2 => 0.96-0ubuntu3] (core)
[18:00] -queuebot:#ubuntu-release- Unapproved: netplan.io (cosmic-proposed/main) [0.96-0ubuntu<IP_ADDRESS> => 0.96-0ubuntu<IP_ADDRESS>] (core)
[18:09] <handsome_feng> infinity: Can I request a rebuild now? I see ukui-greeter has migrated to release in https://launchpad.net/ubuntu/+source/ukui-greeter
[18:10] <infinity> handsome_feng: Rebuild is already in progress.
[18:10] <handsome_feng> oh, thanks!
[18:10] <infinity> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/disco/ubuntukylin/+build/160475
[18:11] <handsome_feng> Got it, :)
[18:14] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Disco Beta] has been marked as ready
[18:29] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Disco Beta] has been marked as ready
[18:37] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Disco Beta] has been updated (20190328)
[18:37] <infinity> handsome_feng: ^
[18:37] -queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (disco-proposed) [0.96-0ubuntu3]
[18:38] <handsome_feng> \o/, I will download it now and then have a test
[18:39] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (disco-proposed) [19.0.1-1ubuntu1]
[18:42] -queuebot:#ubuntu-release- Unapproved: accepted qtwebkit-opensource-src [source] (disco-proposed) [5.212.0~alpha2-21ubuntu1]
[18:43] -queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (disco-proposed) [1.1.1+bzr982-0ubuntu21]
[18:44] -queuebot:#ubuntu-release- Unapproved: accepted libglvnd [source] (disco-proposed) [1.1.1-0ubuntu1]
[18:48] -queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.96-0ubuntu<IP_ADDRESS> => 0.96-0ubuntu<IP_ADDRESS>] (core)
[18:57] <bdmurray> LocutusOfBorg: which libunistring do you really want reviewed for cosmic?
[19:21] -queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (bionic-proposed) [0.96-0ubuntu<IP_ADDRESS>]
[19:21] -queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (cosmic-proposed) [0.96-0ubuntu<IP_ADDRESS>]
[19:30] -queuebot:#ubuntu-release- Unapproved: netplan.io (disco-proposed/main) [0.96-0ubuntu3 => 0.96-0ubuntu4] (core)
[19:32] -queuebot:#ubuntu-release- Unapproved: netplan.io (cosmic-proposed/main) [0.96-0ubuntu<IP_ADDRESS> => 0.96-0ubuntu<IP_ADDRESS>] (core)
[19:36] -queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.96-0ubuntu<IP_ADDRESS> => 0.96-0ubuntu<IP_ADDRESS>] (core)
[20:04] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Disco Beta] has been marked as ready
[20:04] <handsome_feng> infinity, acheronuk: Thank you all! and good night! :)
[20:21] <acheronuk> infinity: yeah, I know I could have just put that kylin upload in the queue as a new MOTU, but am I being a bit cautious with the new permissions ;)
[20:22] <acheronuk> <handsome_feng: I see you left the room, but for the log, you are welcome :)
[21:01] <tsimonq2> acheronuk: msttcorefonts merge next? ;)
[21:11] <Eickmeyer> acheronuk picked a heck of a week to become MOTU. XD
[21:22] <valorie> ha!
[22:24] <Eickmeyer> Question: is there a separate artwork freeze? If it's not too late (even after beta goes out), I'd like to add a wallpaper I made to ubuntustudio-look: http://ubuntustudio.org/wp-content/uploads/2019/03/1fe8/ubuntustudio_disco_dingo_1080.jpg
[22:29] <tsimonq2> Eickmeyer: There is no such freeze.
[22:29] <valorie> that is a rock 'em sock 'em wallpaper!
[22:30] <tsimonq2> https://wiki.ubuntu.com/DiscoDingo/ReleaseSchedule
[22:30] <Eickmeyer> tsimonq2: Does it fall under UI feeze then?
[22:30] <tsimonq2> Nope.
[22:30] <Eickmeyer> \o/
[22:30] <tsimonq2> It falls under the same exception that has allowed flavors to push Ubiquity slideshows several days before release. :P
[22:30] <Eickmeyer> When I get home, that's getting added to the ubuntustudio-look package as part of ubuntustudio-wallpaper
[22:31]  * Eickmeyer should also update the Ubiquity slideshow
[22:31] <tsimonq2> (Disclaimer: I'm not a member of the release team.)
[22:31] <Eickmeyer> tsimonq2: Understood, but you've got your finger on the pulse.
[22:31] <tsimonq2> heh
[22:38] <Wimpress> infinity: Are you waiting on the Ubuntu Desktop testcases to be completed and the image marked ready?
[22:49] <infinity> Wimpress: Also scratching my head over a source ISO generation issue, but mostly your thing, yes.
[23:17] <Wimpress> infinity: I chatted with Will Cooke, he says the Ubuntu Desktop images can be marked ready.
[23:17] <Wimpress> Kindly requests you mark them ready on his behalf.
[23:35] <infinity> Wimpress: Mmkay.
[23:35] <Wimpress> Thanks.
[23:37] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Disco Beta] has been marked as ready
[23:37] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Disco Beta] has been marked as ready
[23:37] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Disco Beta] has been marked as ready


[10:40] <ktt___> Hello. I experimented 19.10 with VirtualBox 6.0, under both Linux and Windows. On Linux (Lubuntu 18.04), the installation crashes so severely, that it takes the whole VirtualBox with it.
[10:41] <ktt___> On Windows then, the installation goes through well. On both sides, I defined 4GB memory, 40 GB disk and 4 processors.
[10:42] <lotuspsychje> ktt___: at wich point did it crash, and was it the 19.10 beta iso you tested?
[10:42] <ktt___> Yes, 19.10 beta, downloaded today.
[10:42] <lotuspsychje> allright
[10:42] <ktt___> It was on "Filling up filesystems", on 18%.
[10:43] <lotuspsychje> ktt___: did you compare with a live session, instead of the install?
[10:43] <ktt___> On the Linux side, with VirtualBox 5.0, the virtual machine just crashed. But when I installed VirtualBox 6.0, it took the whole machine with it for about 5 minutes.
[10:43] <ktt___> The live session works just about ok.
[10:44] <lotuspsychje> !info virtualbox bionic
[10:44] <lotuspsychje> ktt___: did you install vbox from a ppa?
[10:44] <ktt___> The 5.0 was from Lubuntu 18.04 ppa, and the 6.0 was from Virtualbox own ppa
[10:45] <ktt___> virtualbox-6.0/unknown,now 6.0.12-133076~Ubuntu~bionic amd64 [installed]
[10:45] <lotuspsychje> ktt___: we cannot support packages from external ppa, and we highly reccomend using package versions specific for your ubuntu version
[10:45] <ktt___> Yes, with the 5.0 version, from the 18.04 repo, it crashed also.
[10:45] <lotuspsychje> ktt___: could you check if you get crashes from the 18.04 vbox?
[10:45] <lotuspsychje> ok tnx
[10:45] <ktt___> yes
[10:46] <ktt___> On the 18.04 repo version, the crash was "better" as it did not freeze the host machine.
[10:46] <lotuspsychje> ktt___: how about you reach the live session first, then open a bunch of debug methods, like: journalctl -f
[10:46] <ktt___> On which version, 6.0 or 5.0?
[10:46] <ktt___> Virtualbox I mean
[10:47] <lotuspsychje> ktt___: try also starting vbox from a terminal in lubuntu, maybe we can catch useful errors
[10:47] <ktt___> That is what I have done
[10:47] <lotuspsychje> ktt___: we can only support you with the official package versions
[10:47] <lotuspsychje> 5.2 for bionic
[10:47] <tomreyn> there's #vbox also which is virtualbox's support channel
[10:47] <ktt___> OK, I'll get back to the official PPA version
[10:48] <ktt___> This is more like 19.10 issue, as I have used the VirtualBox (18.04 PPA version) happily for many other purposes, including runnign Windows 10.
[10:48] <lotuspsychje> ktt___: lets find out on the journal logs, maybe its soemwhere in ubiquity
[10:49] <lotuspsychje> the more you can pastebin us, the better volunteers can take a look/debug
[10:49] <tomreyn> i'm using virtualbox's upstream packages with a 19.10 beta just fine, but as lotuspsychje pointed out, that's off topic here.
[10:49] <ktt___> Yes. Just a while, I'll get back to 18.04 ppa version.
[10:50] <lotuspsychje> ktt___: your harddisk doesnt have IO warnings on the physical install for example?
[10:50] <ktt___> I'm not able to make physical install on the 19.10 beta
[10:51] <lotuspsychje> ktt___: can you also give us info about what kind of partitioning you chosen?
[10:51] <ktt___> The default i.e. everything to installation
[10:51] <lotuspsychje> ktt___: no what i mean is, your 18.04 physical install was lubuntu right? your hd isnt failing or so?
[10:52] <tomreyn> when you say "18.04 ppa version", do you mean the version of virtualbox that is part of ubuntu (universe repository, so not a PPA)?
[10:52] <lotuspsychje> just brainstorming what could freeze your setup
[10:52] <ktt___> My computer is having 18.04 physical install yes. There are no HDD or other HW related problems.
[10:52] <lotuspsychje> ok tnx
[10:53] <ktt___> By the "18.04 ppa" version I mean, that I'm just using the Ubuntu normal repository, no any external PPA
[10:53] <ktt___> sorry aobut that
[10:54] <tomreyn> no problem, i'm just making sure i understand your setup
[10:55] <tomreyn> a PPA is really just what's hosted on ppa.launchpad.net, other repositories we call either 'ubuntu archives' (the official ones) and 'third party repositories'
[10:58] <tomreyn> i rmemeber now i also had some issues installing the 19.10 amd64 desktop beta on vbox 6.0 running on ubuntu 18.04 amd64 (5.0 HWE kernel) initially. what i did to make it work was to enable 3d acceleration and increase vram above 64 MB
[10:58] <ktt___> Now I have VirtualBox 5.2.32_Ubuntu r132056 installed. The virtual machine has again 4GB RAM, 40 GB HDD, 4 processors, and CD-ROM was mounted as Lubuntu 19.04beta (eoan-desktop-amd64.iso, md5sum 22a86982e86962d1907e9f785172e6a7, downloaded today)
[11:00] <tomreyn> hmm this mad5sum matches neither yesterdays' nor todays' daily-live
[11:01] <tomreyn> i'm looking at http://cdimage.ubuntu.com/daily-live/ and more specifically at http://cdimage.ubuntu.com/daily-live/20191007/MD5SUMS and http://cdimage.ubuntu.com/daily-live/20191006/MD5SUMS
[11:01] <ktt___> It was downloaded from here: https://lubuntu.me/downloads/ --> 19.10 Eoan Ermine Dailies, Desktop 64-bit
[11:01] <tomreyn> oh *l*ubuntu
[11:02] <lotuspsychje> oh..
[11:02] <ktt___> Yes
[11:02] <ktt___> I'm using L ubuntu as I still hate the new Gnome
[11:02] <lotuspsychje> ktt___: you should have mentioned it was a lubuntu daily
[11:02] <ktt___> Yes I mentioned :)  on the first coment
[11:02] <ktt___> sorry not in this channel, I was first on the #ubuntu channel.....
[11:02] <ktt___> from there I was instructed to come here
[11:03] <lotuspsychje> ktt___: you say there you were 'on linux lubuntu 18.04'?
[11:03] <ktt___> Yes. The host computer is Linux Lubuntu 18.04.
[11:03] <tomreyn> http://cdimage.ubuntu.com/lubuntu/daily-live/20191006/MD5SUMS matches your MD5SUM
[11:04] <tomreyn> have you also tried the beta?
[11:04] <tomreyn> since the dailies are untested snapshots
[11:05] <tomreyn> beta downloads as found on https://lubuntu.me/downloads/ : http://cdimage.ubuntu.com/lubuntu/releases/19.10/beta/lubuntu-19.10-beta-desktop-amd64.iso http://cdimage.ubuntu.com/lubuntu/releases/19.10/beta/MD5SUMS
[11:06] <ktt___> Ok, not yet. On the Download page, it was mentioned, that dailies are recommended. :)  I'll check the beta.
[11:06] <ktt___> Do you need some information from the virtual machine instance?
[11:06] <tomreyn> oh right, it says "recommended"
[11:07] <tomreyn> ...for the dailies
[11:07] <lotuspsychje> i wonder why they say that?
[11:08] <tomreyn> the only situation i can think of is that they tested the beta and found it to be broken
[11:08] <lotuspsychje> right
[11:13] <ktt___> I'll try to configure this live image instance so, that it redirects its syslog to my host computer, so we would get the syslog from the moment of crash.
[11:13] <lotuspsychje> ktt___: use journalctl -f instead
[11:14] <ktt___> No use, as when the installation crashes, the VirtualBox window disappears.
[11:14] <lotuspsychje> or maybe start ubiquity setup from a terminal aswell
[11:15] <ktt___> Ok now the syslog streams to my host computer
[11:17] <tomreyn> i'm just installing using the same image you used (matching md5), using upstream virtualbox Version 6.0.12 r133076, host is ubuntu 18.04.3 (fully patched) with kernel 5.0 (from LTSE). guest specifications are: BIOS installation, 1 GB RAM, 10 GB storage (dynamic allocation), everything else is default.
[11:17] <tomreyn> it was also very busy at the 18% step but got past it
[11:17] <lotuspsychje> tnx for testing tomreyn
[11:17] <tomreyn> so the 18% step is when the storage buffer runs full and the host actually gets to shell it out to disk, i guess.
[11:17] <tomreyn> namely much I/O is going there.
[11:18] <ktt___> Ok, now I have enabled openssh server on the live CD, so I get the journalctl output to host machine also
[11:18] <ktt___> What else would you want to be streamed?
[11:19] <tomreyn> as long as you catch the host and guest kernel and vbox logs that's probably good enough
[11:19] <tomreyn> there's probably also an installer log at /var/log/installer on the guests' installer target device
[11:20] <tomreyn> but if the VM process crashes this is probably not so relevant.
[11:21] <tomreyn> did you install in bios or uefi mode?
[11:22] <tomreyn> ktt___: ^
[11:24] <ktt___> Bios most likely
[11:24] <ktt___> I'm just selecting default settings from Virtualbox
[11:24] <tomreyn> yes bios would be default
[11:25] <tomreyn> i'll retry with 4 cpu cores and 4 gb ram as you did
[11:26] <ktt___> Now the installation started. It reached 18%, on the logs it says, that it mounted sda with EXT4-fs.
[11:26] <ktt___> My Lubuntu host computer is now frozen.
[11:27] <ktt___> And now the virtual machine crashed and died.
[11:28] <tomreyn> oh even the host freezes, i hadn't seen this mentioned. then #lubuntu or #ubuntu would actually be the right place to discuss this part (but i also dont want to chase you around more)
[11:29] <ktt___> The last log lines from the Virtual client are:
[11:29] <ktt___> Oct  7 11:25:40 lubuntu kernel: [ 1768.943132]  sda:
[11:29] <ktt___> lubuntu kernel: [ 1770.010583] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[11:29] <ktt___> thread 1610 of process 1549.
[11:30] <ktt___> After the "Demoted 3 threads" the virtual client froze, it just hogged all resources. The host killed the process.
[11:30] <tomreyn> good job, host.
[11:30] <ktt___> I need to go for lunch now.... I'll get back here after 30 minutes or so.
[11:31] <tomreyn> so it seems the issue you're seeing is really with virtualbox.
[11:31] <tomreyn> my second installation worked fine, too.
[11:31] <ktt___> And specificly, on Linux virtualbox. On WIndows host, it worked.
[11:31] <ktt___> Hmm, I could test on another host, also having Lubuntu 18.04. I'll check that after lunch.
[11:35] <tomreyn> good plan, could be buggy firmware bug, defective hardware etc.
[11:36] <tomreyn> s/bug,/,/
[12:05] <ktt___> Now the installation is proceeding on another Lubuntu 18.04 host. It is running the same VIrtualbox version as the other one. Installation went past 18% happily.
[12:07] <ktt___> This kind of randomness is annoying. :(
[12:09] <ktt___> And the installation went through fine.
[12:27] <tomreyn> ktt___: do a firmware (bios/uefi) upgrade on the system where it fails, might fix it if it's an issue with the VT-x / AMD-V implementation there.
[14:11] <Sbur3> I'm back with the upgrade issues.  Did a partial upgrade to 19.10. Now the system refuses to run.  I have a Live CD running. Where the keyboard didn't permit me to go into shell in the broken system, it works in the Live CD. The question is "Can I recover and repair the system with my Live CD?"
[14:12] <Sbur3> I see that TJ- and tomreyn are there
[14:12] <Sbur3> from yesterday
[14:14] <Sbur3> TJ-: Hi, how are you doing ... and can you have patience with me today?
[14:14] <Sbur3> tomreyn: Same question for you
[14:19] <tomreyn> https://help.ubuntu.com/community/LiveCdRecovery#Update_Failure
[14:32] <jatt> on eon upgrade I'm getting http://dpaste.com/33PHJ6N
[14:32] <jatt> is this a known issue?
[14:34] <tomreyn> it's probably just what it suggests it could be, a mirror sync in progress.
[14:35] <tomreyn> you could try a different mirror server in the meantime.
[14:35] <jatt> ok thanks will try later then
[14:36] <tomreyn> https://launchpad.net/ubuntu/+archivemirrors
[18:28] <Aavar> When is a good time to upgrade to 19.10 to minimize the possibility of a failure? Im a keen to upgrade, but not if it breaks my system :)
[18:29] <lordcirth_> Aavar, after it releases? Depends on your threshold.
[18:29] <Aavar> lordcirth_: Yeah, but should I wait longer that that?
[18:30] <Aavar> I'm on 19.04 now.
[18:30] <lordcirth_> A week or two, maybe.
[18:30] <Aavar> lordcirth_: ok, thanx :)
[19:52] <denza252> Hi, will *ubuntu 19.10 have support for Zen2?
[19:52] <denza252> specifically the 3700U if that makes any difference
[19:52] <lordcirth_> denza252, Zen2 has been supported at least since kernel 4.21
[19:52] <lordcirth_> Or 5.0, as it was released as.
[19:53] <denza252> ah ok, and the RX Vega 10?
[19:53] <denza252> I assume that too is supported but i just want to make sure
[19:55] <lordcirth_> It looks like support for that came out a while ago.
[19:57] <denza252> Alrighty, thank you. I am looking forward to putting Kubuntu 19.10 on my shiny new lappy. Good luck with the release and such!
[20:07] <tomreyn> denza252: you can try the beta or a daily already, if you already have the hardware
[20:08] <denza252> it's en route, i think it'll come a day or two before the release and such
[20:09] <tomreyn> ah nice, have a nice early christmas eve (or whatever similar event you may have there) ;)
[20:10] <denza252> Thank you


[23:43] <Ark74> helllo!
[23:44] <Ark74> any idea of why could I be getting mate-time-admin all options disabled (greyed out )
[23:44] <Ark74> and how could I fix the issue, I'm on mate 1.26


[22:37] <mup> Issue operator#679 opened: harness does not raise the same exception as ops when `list_files` is not found <Created by dstathis> <https://github.com/canonical/operator/issues/679>


[03:01] <mshadle> sure enough, uninstall debconf and reinstall and im fine
[03:06] <mshadle> so something with di-tools, systemimager, or something else corrupted my debconf when i removed it
[09:34] <cjwatson> evand: 320 is probably actually closer, but we wanted to be conservative in a few places and said 384
[10:38] <tjaalton> cjwatson: did you discuss console-setup with gravity at FOSSCamp?
[10:38] <tjaalton> and if, what was the outcome
[10:38] <tjaalton> +so
[10:40] <cjwatson> erm, what about it?
[10:40] <cjwatson> we did talk a bit, though I forget the exact details; if you remind me which bit you care about, I may remember ...
[10:41] <tjaalton> well, our xkb layout configuration depends on it
[10:41] <tjaalton> but debian uses something different
[10:41] <cjwatson> Debian will be moving to console-setup in time
[10:41] <tjaalton> oh
[10:41] <cjwatson> and our XKB layout configuration does not depend on console-setup
[10:41] <cjwatson> it's the other way round
[10:42] <cjwatson> well, though it does fish its initial value out of what console-setup did in the installer, true
[10:42] <tjaalton> yes
[10:42] <tjaalton> I just did some thinking about how to get the values for hal
[10:42] <tjaalton> and how to keep them in sync
[10:43] <cjwatson> http://wiki.debian.org/DebianInstaller/ConsoleSetupSwitch
[10:43] <tjaalton> oh
[10:43] <tjaalton> goal for lenny, sweet
[10:45] <cjwatson> I think in practice sorting out console-setup layout/variant names i18n is the hardest problem
[10:45] <cjwatson> bryce said he'd help out with that for hardy
[10:45] <cjwatson> anyway, do go on regarding hal?
[10:46] <tjaalton> right.. so AIUI it was decided that hal should ship a script that maintains the fdi-file
[10:47] <tjaalton> or do it in config/postinst
[10:47] <tjaalton> but that would mean running dpkg-reconfigure when doing a change
[10:50] <tjaalton> so I was thinking, if console-setup is the "master" place to store the data (I can't think of a situation where you'd have different layout on the console), there could be a "update-kbdlayout" or similar that would update the fdi
[10:51] <tjaalton> console-setup seems to store the information in debconf
[10:52] <cjwatson> debconf should never be the canonical place to store anything
[10:52] <cjwatson> console-setup stores it in /etc/default/console-setup
[10:52] <cjwatson> agreed that there needs to be a simple command to change it
[10:52] <cjwatson> editing XML by hand is not good
[10:52] <tjaalton> yes, I know that "debconf should not be a database" :)
[10:52] <cjwatson> I don't think either console-setup or X needs to be the "master", if it's being kept in hal ...?
[10:53] <cjwatson> but it doesn't hugely matter, I guess
[10:53] <tjaalton> well, console-setup doesn't need hal, although they are both installed on every system..
[10:54] <cjwatson> yes, that could be a sticking point in Debian
[10:54] <cjwatson> it would mean committing to having hal in the base system
[10:54] <cjwatson> for that matter, I don't think hal is part of Ubuntu's base system
[10:54] <cjwatson> it's priority optional
[10:55] <tjaalton> so it seems..
[10:55] <tjaalton> hmm
[10:55] <cjwatson> right now, it's part of desktop
[10:55] <cjwatson> server installs don't have it
[10:55] <cjwatson> could hal fish it out of a non-fdi file?
[10:55] <tjaalton> yep, didn't bother to check :)
[10:55] <cjwatson> like /etc/default/console-setup?
[10:56] <tjaalton> it could
[10:56] <cjwatson> I think that might be better
[10:56] <cjwatson> if it fetched it dynamically at run-time
[10:56] <cjwatson> the console setup is the sort of thing you need to edit with very few tools, and having it as a simple text file seems like a win
[10:57] <cjwatson> having it in hal (the protocol) seems more important than having it in hal's native file format
[10:57] <tjaalton> how to do that in runtime?
[10:58] <cjwatson> not my problem
[10:58] <cjwatson> ;-)
[10:58] <tjaalton> haha
[10:58] <cjwatson> hal has plenty of scripts that it calls to figure stuff out
[10:58] <cjwatson> e.g. for power management
[10:58] <cjwatson> I'm not saying it's trivial but it ought to be possible
[10:58] <tjaalton> so you mean it's better to have the information only in one place (on disk) and read that on fly?
[10:59] <cjwatson> it feels better
[10:59] <tjaalton> sounds more consistent
[11:00] <tjaalton> for us it's simple to rely on console-setup, and then Debian can add code to get the information from current xorg.conf or whatever
[11:00] <tjaalton> until they use console-setup
[11:01] <cjwatson> or migrate it from xorg.conf once-only into an fdi file if they prefer
[11:01] <tjaalton> yeah, that could be done in some postinst
[11:02] <cjwatson> so what will the gnome keyboard layout thing do?
[11:02] <cjwatson> presumably it can't set the value in hal, since it's per-user not system-wide
[11:02] <tjaalton> right
[11:02] <cjwatson> I guess it just carries on doing what it's doing now
[11:02] <tjaalton> it should let the user change the layout if he needs to
[11:02] <tjaalton> but, there are bugs
[11:03] <tjaalton> at least now that the default is us. If I add fi to the list, I can't make it default (on my session) until I remove us
[11:03] <cjwatson> ugh
[11:03] <tjaalton> then if I plug in another keyboard, it uses us, and the moment I type with it the whole session uses "us"
[11:04] <tjaalton> :P
[11:04] <tjaalton> corner cases, but still
[11:06] <tjaalton> hmm, /usr/lib/hal/scripts has stuff that should help
[11:06] <tjaalton> ..figuring out how to do it
[11:07] <tjaalton> oh, just echo the values.. cool
[11:07] <tjaalton> dead simple :)
[11:07] <tjaalton> how the hell no-one thought of this before
[11:09] <tjaalton> now something completely different: has it been discussed if we could use 'relatime' mount option by default?
[11:09] <tjaalton> Fedora8 does that
[11:10] <tjaalton> currently even every read from the cache forces a write to the disk
[11:11] <cjwatson> yes, it has
[11:11] <cjwatson> partman now (hardy) supports relatime, but doesn't yet support the concept of default mount options
[11:12] <cjwatson> so that needs to be added first
[11:12] <tjaalton> cool
[11:12] <cjwatson> but I think it would be a good plan
[11:12] <tjaalton> there is a spec about noatime, but relatime is better
[11:12] <tjaalton> since some apps have problems with noatime
[11:12] <tjaalton> https://blueprints.edge.launchpad.net/ubuntu/+spec/noatime
[11:13] <tjaalton> hmm, it would be nice to see directly when a spec has been created
[11:14] <cjwatson> sigh @ spec proliferation
[11:14] <tjaalton> yeah..
[11:19] <tjaalton> should I draft a spec about it, and then later mark the noauto-spec as superceded?
[11:20] <tjaalton> hog
[11:20] <tjaalton> uh
[11:20] <tjaalton> "oh"
[11:20] <tjaalton> cjwatson: didn't notice your comment that a spec is not necessary :)
[11:21] <cjwatson> it's yet another case where a simple bug would be perfectly fine
[12:36] <twb> cjwatson: is partman-auto/purge_lvm_from_device supposed to work under gutsy's d-i?
[12:36] <twb> I get "Volume group name already in use".
[12:37] <cjwatson> sorry, I don't know offhand
[12:37] <twb> AFAICT I can't make an automated lvm-using install idempotent.
[12:37] <twb> I got that entry from the Sid install guide, so it may not be applicable to gutsy.
[12:37] <cjwatson> I don't know why it wouldn't work
[12:37] <cjwatson> it's there
[12:38] <twb> Hmm.
[12:38] <cjwatson> perhaps some stupid device name difference
[12:38] <twb> I'm also using oem-config, if that makes a different.
[12:38] <twb> *difference
[12:38] <cjwatson> no
[12:39] <twb> I don't know how to analyse the problem.
[12:40] <twb> Oh, this VM isn't using DEBCONF_DEBUG, lemme reboot
[14:44] <cjwatson> evand: did you get my mail about clock-setup?
[14:44] <cjwatson> in reply to your merge requests
[14:44] <evand> indeed, I'm working on it as we speak
[14:45] <cjwatson> ok, thanks
[14:46] <cjwatson> localechooser done, console-setup imported into bzr and nearly done, hw-detect imported into bzr and done, elilo-installer synced
[14:47] <evand> awesome
[14:47] <evand> was ntp previously handled by a different component?
[14:54] <cjwatson> it wasn't done at all
[14:55] <evand> ah, that clears things up, thanks
[15:05] <soren> Just FYI: mathiaz has done the ntp merge, I just need to review it.
[15:21] <cjwatson> console-setup uploaded, os-prober synced
[15:22] <CIA-4> oem-config: cjwatson * r383 oem-config/ (7 files in 2 dirs): * Convert to python-central.
[15:24] <CIA-4> oem-config: cjwatson * r384 oem-config/ (debian/changelog scripts/localechooser-apply):
[15:24] <CIA-4> oem-config: * Adjust for localechooser 1.39:
[15:24] <CIA-4> oem-config:  - Don'\''t edit /etc/environment unless it already contains LANG or
[15:24] <CIA-4> oem-config:  LANGUAGE settings.
[15:25] <CIA-4> oem-config: cjwatson * r385 oem-config/ (debian/changelog lib/components/language.py):
[15:25] <CIA-4> oem-config: * Adjust for localechooser 1.40:
[15:25] <CIA-4> oem-config:  - Cope with localechooser asking countrychooser/country-name rather than
[15:25] <CIA-4> oem-config:  countrychooser/shortlist.
[15:25] <CIA-4> ubiquity: cjwatson * r2360 ubiquity/ (debian/changelog ubiquity/components/language.py):
[15:25] <CIA-4> ubiquity: * Adjust for localechooser 1.40:
[15:25] <CIA-4> ubiquity:  - Cope with localechooser asking countrychooser/country-name rather than
[15:25] <CIA-4> ubiquity:  countrychooser/shortlist.
[15:28] <CIA-4> ubiquity: cjwatson * r2361 ubiquity/ (debian/changelog scripts/install.py):
[15:28] <CIA-4> ubiquity: * Remove the pregenerated snakeoil certificate and reconfigure ssl-cert so
[15:28] <CIA-4> ubiquity:  that each system gets a unique snakeoil certificate.
[15:32] <cjwatson> evand: I think we should skip apt-setup for alpha 1; it requires new apt, new pkgsel, and new di-utils
[15:32] <cjwatson> which is all kind of a pain to get in place by Thursday
[15:33] <evand> indeed
[15:34] <twb> What happens on Thursday?
[15:34] <evand> cjwatson: http://people.ubuntu.com/~evand/upload/clock-setup_0.92ubuntu1.dsc
[15:34] <evand> http://people.ubuntu.com/~evand/bzr/clock-setup/
[15:34] <evand> that should address the issues you raised
[15:34] <evand> I looked over it a few times just to be sure, but you might want to review it one more time, just in case
[15:35] <cjwatson> twb: alpha 1 planned to be released then
[15:36] <cjwatson> evand: thanks, looking
[15:36] <cjwatson> evand: could you please merge my changes? bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/clock-setup/ubuntu/
[15:36] <cjwatson> err
[15:37] <cjwatson> I didn't make any changes there; did you throw away and start over?
[15:37] <evand> indeed, it seemed cleaner to do it that way.  Should I not have?
[15:37] <cjwatson> please don't in future, it's confusing
[15:37] <evand> I figured you hadn't merged from me
[15:37] <evand> ok
[15:37] <evand> sorry about that
[15:38] <cjwatson> hmm, I wonder what LP will do if I uncommit
[15:38]  * cjwatson goes to look that up
[15:38] <evand> probably explode
[15:39] <cjwatson> I don't think so, it does branch.pull(self._source_branch, overwrite=True)
[15:39] <cjwatson> so I'll just uncommit back to 0.16ubuntu1 and pull again
[15:40] <cjwatson> generally not good to uncommit on a published branch though, but in this case I guess it's the easiest recovery path
[15:40] <evand> ok
[15:41] <cjwatson> evand: this time you seem to have dropped the UTC question *and* its changelog entry
[15:41] <cjwatson> I sort of meant to keep the question instead
[15:41] <cjwatson> (due to bug 28961)
[15:42]  * evand checks
[15:49] <evand> ah, I misread and thought that they had merged that bit
[15:49] <evand> though on further inspection, no, they have not
[15:49] <evand> fixing now
[15:51] <cjwatson> thanks
[15:53] <evand> ok, pushed
[15:56]  * evand crosses fingers
[16:34] <cjwatson> looks good
[16:35] <evand> great.  Shall I move on to base-installer, or are you already working on that?
[16:35] <cjwatson> I am not
[16:36] <evand> ok
[16:36] <cjwatson> clock-setup uploaded, thanks, sorry for the long back-and-forth :)
[16:36] <cjwatson> I'm working on the rather epic task of importing debian-installer's history into bzr
[16:36] <evand> sorry for messing it up three times :)
[16:37] <evand> yikes
[16:37] <cjwatson> took a while to find all the tarballs I had from warty ...
[16:37] <cjwatson> I want to have the aid of bzr for the merge though
[16:37] <evand> haha
[16:39] <cjwatson> urgh, bzr-svn doesn't seem to have done the right thing with $Id$ expansions
[16:41] <cjwatson> https://blueprints.launchpad.net/bzr/+spec/bzr-keyword-expansion, sigh, guess I'll just ignore those conflicts
[16:42] <cjwatson> maybe I should use tailor instead ...
[16:57] <twb> I wouldn't trust tailor for more than a one-off migration of data from one SCM to another
[17:00] <cjwatson> I've used it before with moderate success, and in this case I have already tried everything else that I know to be available
[17:00] <cjwatson> plus I have some checks and balances available to me on an ongoing basis, so I'm not worried
[17:01] <cjwatson> that said, tailor isn't working for me either at the moment
[17:01] <twb> You've used it successfully for two-way bzr svn interaction?
[17:01] <cjwatson> I don't need two-way
[17:01] <twb> Oh, OK
[17:02] <cjwatson> I'm just working around the fact that a cscvs bug means that Launchpad can't import this particular Subversion repository into bzr as yet
[17:04] <cjwatson> looks like I'm stuck with bzr-svn's bugs though
[21:01] <evand> cjwatson: http://people.ubuntu.com/~evand/bzr/base-installer/ and http://people.ubuntu.com/~evand/upload/base-installer_1.85ubuntu1.dsc
[21:01] <evand> Not entirely sure if I did kernel/tests/sparc/niagara-t1-* correctly.  I was going to bump the kernel version, but linux-image-2.6.22-14-sparc64 doesn't exist according to p.u.c.
[21:03] <knowmad> Hi, is this an appropriate channel for discussing usplash customization issues?
[21:04] <evand> knowmad: #ubuntu-devel might be more appropriate.  My usplash knowledge is somewhat limited.
[21:05] <knowmad> evand: thanks! i'm being challenged by it at the moment myself.
[21:22] <cjwatson> evand: ok, I'll look tomorrow morning
[21:22] <cjwatson> thanks
[21:22] <cjwatson> the kernel versions in tests aren't too important
[21:35] <evand> ah, thanks


[02:17] <NealRame> anyone else had this issue where occasionally a whole application window gets faded-out? Only try-untray or close/relaunch fixes it. Kubuntu 21.10 but the same issue was happening on 21.04
[02:18] <NealRame> faded out as in darkened, barely visible, as if kwin added a misplaced effect on it
[02:21] <omegatron> I would consider myself lucky, if such a thing would be my only issue with kubuntu 21.x ...  -_-
[03:05] <NealRame> omegatron: heheh, yeh it's not the worst and is quite rare
[03:06] <NealRame> I remember modifying some kwin/compositing settings such as switching it to se OpenGL 3 instead of 2, etc
[04:27] <user|51> Hello, someone plese help. I have an issue on xsane. When I try to scan the program closes
 then apply? (re @milesdredd: )
 i solved it (re @blinkengine: then apply?)
[13:56] <BluesKaj> Hi folks
[13:56] <user|80> hello
[13:57] <user|80> i have installed kubuntu but after install show black screen.
[13:57] <user|80> how to fix this problem.
[13:59] <user|80> i have installed kubuntu but after install show black screen. please tell me how  will i solve this problem.
[14:00] <oerheks> user|80, what videocard do you use?
[14:01] <user|80> 1050ti
[14:02] <oerheks> try this fix: edit grub and add nomodeset >> https://itsfoss.com/fix-ubuntu-freezing/
[14:02] <user|80> ok i am checking..
[14:03] <oerheks> common nvidia issue..
[14:05] <user|80> Thank you very much for inform me .
[14:21] <kubuntu> hello
[14:23] <kubuntu> hello
[14:23] <kubuntu> hello
[14:23] <kubuntu> hello
[14:23] <kubuntu> hello
[14:23] <kubuntu> hello
[14:24] <user|80> yes
[14:25] <user|80> which linux is good for nvidia
[14:32] <oerheks> kubuntu ofcourse
 hey , while using it normally ,
 it says unexpectedly plasma has stopped
 and this happening every time when i open spectacle (screenshot app)
[15:54] <Maik> @milesdredd search for bug reports, if none then create one
 oky
[15:59] <omegatron> hmm ... kubuntu 21.04 here ... can I change somewhere the behaviour when just the 'meta' key is pressed ? I want to define it to actually do ctrl-F5 for forced reload in firefox, but the default behaviour of popping up the kubuntu main panel with the search field is in my way (don't need that anyway)
[16:11] <leaftype> omegatron: IIRC the meta key (by itself) can't be assigned to anything directly. The ability to open up the launcher is kinda hacked in
[16:11] <omegatron> *sigh*
[16:13] <leaftype> omegatron: let met duckduck fo ra second though, I'm sure it's been tried before
[16:13] <omegatron> =D
[16:17] <leaftype> .. MAYBE if you set it to alt+f1
[16:17] <leaftype> most of the things i'm seeing are old
[16:23] <omegatron> in the keyboard layout settings ?
[16:28] <omegatron> I have to admit, I have already set my keyboad layout to "German (Macintosh, no dead keys)" and i'm trying to tune the key settings in a way, where it's like I'm used to it from Mac OS X and Apple Keyboards ... so, from left to right:  ctrl - alt - cmd/meta - space - cmd/meta - alt - (dead key) - ctrl
[16:28] <omegatron> therefore, I already have swapped left ctrl and left alt, but the other things are quite hard to tune ..
[17:02] <omegatron> but thanks anyway!
[17:18] <Dragnslcr> Yeah, I think the Meta key still gets mapped to Alt-F1
[17:19] <Dragnslcr> At least in 20.04. I haven't tested 21.10.
[17:20] <omegatron> ah I see -  alt+f1 also opens up that panel/menu (never used it)
[19:35] <matcz> hello all :)
[19:43] <matcz> quick question, why kdewallet or network-manager wont remember my wifi password?


[03:42] <EdDeAlmeida> Hi everybody.
[03:43] <EdDeAlmeida> I was looking for a good distro for my 3 years old son and read this article here: https://opensource.com/article/17/9/linux-kids
[03:44] <EdDeAlmeida> It says Edubuntu is about to disapear for having no maintainers.
[03:46] <EdDeAlmeida> I'd like to know if this is true. It would be a shame to allow such a project to disapear.
[03:48] <EdDeAlmeida> I am a old Linux developer. Already contributed to the kernel for sometime back in the 90's and I'd be pleased in helping Edubuntu to continue.
[03:49] <EdDeAlmeida> Please write me at<EMAIL_ADDRESS>to let me know how may I help.


[00:01]  * RenatoSilva is very confused
[00:02] <lifeless> the terminal should encode the unicode string to your code page
[00:08] <thumper> Yay pipelines (bzr-pipeline) they rock!
[00:09]  * LarstiQ wonders what they are
[00:09] <lifeless> poolie: call?
[00:10] <lifeless> LarstiQ: topgit for bzr; no versioning of the structure, its wysiwyg, and uses regular branch objects
[00:10] <thumper> LarstiQ: I'll be blogging about them soon
[00:10] <poolie> um
[00:10] <LarstiQ> lifeless: stgit:topgit :: looms:pipelines?
[00:10] <LarstiQ> thumper: cool
[00:10] <lifeless> LarstiQ: I haven't reviewed how they would work for e.g. ubuntu packages, but certainly should be nice and easier for local patch creation
[00:10] <thumper> LarstiQ: so look out in planet bzr :)
[00:11] <lifeless> LarstiQ: yes
[00:11] <thumper> LarstiQ: hopefully today, but if not, the weekend
[00:11]  * LarstiQ might have a look at them, now that the regular conference part of EuroPython is done
[00:11] <LarstiQ> (tomorrow/weekend)
[00:12] <poolie> lifeless: sure, give me a call
[00:21] <RenatoSilva> bug 394943
[00:44] <igc> morning all
[00:48] <LarstiQ> morning ian
[01:05] <mthaddon> I just tried upgrading bzr to 1.16 per https://edge.launchpad.net/~bzr/+archive/ppa and now I get "bzr: ERROR: The API for "<module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'>" is not compatible with "(1, 13, 0)". It supports versions "(1, 15, 0)" to "(1, 16, 1)"." on a bzr branch operation
[01:05] <mthaddon> anyone have any ideas?
[01:08] <Peng_> mthaddon: Yes. Upgrade whichever plugin is whining about it.
[01:09] <mthaddon> that's the only output - I don't know what plugin it's whining about
[01:11] <Peng_> mthaddon: Yeah, I know. There *might* be a traceback in ~/.bzr.log
[01:14] <a_c_m> can you change your parent branch -- switch doesnt seem to do it ?
[01:17] <mthaddon> http://pastebin.ubuntu.com/208656/ is the traceback (I think)
[01:18] <lifeless> mthaddon: bzr-gtk likely
[01:19] <mthaddon> lifeless: I don't have that installed
[01:20] <james_w> mthaddon: bzr-svn
[01:20] <lifeless> oh, traceback - bzr-svn
[01:21] <mthaddon> thx, that did it!
[01:25] <lifeless> mathrick: re Integration - whats confusing?
[01:27] <mathrick> lifeless: you present a bunch of different options, but you don't explain in which the integration happens. And then there's "For projects that do 'releases', the contents of a series could be much more mutable with no ill effects." which I completely fail to get
[01:30] <poolie> lifeless: just to check i understood, did you say last night that spiv would necessarily need to fix bug 368921 as part of his current work?
[01:31] <lifeless> yes, and he has already
[01:31] <lifeless> its in his branch
[01:33] <lifeless> mathrick: so the integration section is largely definitional
[01:35] <lifeless> mathrick: projects that branch off for each release, like bzr does, can do history edits outside of releases without affecting the ability to do archaeology across releases
[01:36] <mathrick> lifeless: humm, I'm afraid I still don't see what the integration is defined as. Is that the process of accumulating the code in branches? Or carving out a single 'release' out of them? (But then, why do you mention those that never do 'releases')
[01:37] <lifeless> its the process of integrating code from developers
[01:37] <lifeless> getting code from my branch to bzr.dev is integration
[01:37] <mathrick> ah
[01:38] <lifeless> if, for instance, we rebased integration it wouldn't affect bzr 1.16 at all
[01:38] <lifeless> s/integration/bzr.dev
[01:38] <mathrick> right
[01:38] <mathrick> although it'd introduce certain confusion potentially
[01:43] <lifeless> right
[01:43] <lifeless> but we could do a history-preserving edit to cleanup something in bzr.dev much more safely than doing it to 1.16
[01:43] <lifeless> because bzr.dev has no releases
[01:45] <mathrick> lifeless: to be precise, history-preserving is defined as "trees will still merge properly afterwards"?
[01:45] <lifeless> yes
[01:48] <mathrick> and what kind of edits can you do where that holds?
[01:48] <mathrick> I thought bzr only had the notion of complete states, so any change whatsoever morphs the state into something new and incompatible, no?
[01:55] <lifeless> so a history preserving edit is broadly a new commit that refers to the old one in some way
[01:55] <lifeless> e.g. as a parent
[01:55] <lifeless> or perhaps we can add some other annotations
[01:56] <mathrick> ah, this way
[01:57] <mathrick> so you mean alter the presentation, but not the contents
[01:57] <lifeless> yes
[01:58] <lifeless> FSVO yes
[01:58] <lifeless> the manifesto tried to capture goals and motivations, not implementations
[02:00] <mathrick> sure, I'm just trying to see what you had and hadn't in mind
[02:00] <lifeless> I wanted to try and get a cohesive view of /why/, so that when people talk about how, they don't need to debate merits of motivation
[02:01] <lifeless> without a rationale that supports e.g. rebase, history discarding edits are very contentious
[02:01] <lifeless> I didn't have particular implementations in mind
[02:02] <mathrick> right
[02:35] <RenatoSilva> join #python
[02:35] <RenatoSilva> join #python
[03:18]  * igc lunch
[03:40] <amanica> how do I resubmit a merge-proposal of a branch on launchpad?
[03:41] <amanica> (I commited more stuff as per review, but I don't know how to get the diff to update)
[03:42] <Peng_> Euhhh. People do it all the time, but i have no clue how.
[03:42] <amanica> https://code.edge.launchpad.net/~amanica/bzr/mv_after/+merge/6733
[03:43] <Peng_> Maybe what you do is use https://code.edge.launchpad.net/~amanica/bzr/mv_after/+register-merge again.
[03:43] <Peng_> I really don't know.
[03:44] <Peng_> I've seen people do it, but I don't know how.
[03:44] <amanica> I tried
[03:44] <amanica> but it wont allow me
[03:44] <amanica> it sais the branch already has a merge proposal
[03:44] <amanica> thanks in any case
[03:44] <Peng_> Can you change the status of the current proposal to superseded and then do it?
[03:44] <Peng_> I'm really just guessin' here.
[03:44] <amanica> I looksee
[03:47] <amanica> I'll just add a comment for now, maybe one of the subscribers will be able to help me. thx again for trying.
[03:54] <amanica> anyways, need to get an hour or two of sleep now before I have to go to work. goodnight/goodmorning.
[04:04]  * spiv -> lunch
[04:28] <sidnei> ooooh
[04:28] <sidnei> vila, jam: ping?
[06:14] <poolie> sidnei: hi
[06:14] <poolie> sidnei: you know vila's been working on a buildbot too?
[06:14] <sidnei> poolie: hey, i was heading to bed and heard a bit :)
[06:14] <poolie> he should be here soon
[06:14] <sidnei> beep even
[06:14] <poolie> well
[06:14] <poolie> by all means sleep
[06:14] <sidnei> poolie: i saw a mention somewhere, but thought it was for something else
[06:14] <poolie> is it 2am there?
[06:15] <sidnei> poolie: yep
[06:15] <sidnei> poolie: anyway, the client part is setup on kerguelen, we just need to find a proper master.
[06:15] <sidnei> poolie: mine is running off a nokia n810 :)
[06:16] <poolie> full points for style
[06:16] <sidnei> hehe
[06:17] <sidnei> alright, have a good erm... day :)
[06:17]  * sidnei hits bed
[06:18] <sidnei> poolie: maybe fwd my message to vila, and i will sync up with him
[06:24] <poolie> night
[06:26] <poolie> lifeless: just remembered, did you file an rt re tmpfs for pqm?
[06:26] <lifeless> poolie: no, got sidelined, sorry. Doing now.
[06:26] <poolie> np
[06:26] <poolie> i just wanted the number
[06:26] <poolie> it's not urgent
[06:27] <lifeless> actually
[06:27] <lifeless>  I can't
[06:27] <lifeless> evolution crashes when I click to change the 'from' address for mail.
[06:27] <poolie> :)
[06:27] <lifeless> \o/ karmic
[06:27] <lifeless> could you file it please?
[06:27] <poolie> i don't believe in evolution :)
[06:28] <poolie> sure
[06:36] <lifeless> poolie: popping out quickly, need to catch the bank before they close
[06:41] <poolie> np
[06:59] <RAOF> lifeless: Yeah, that's everyone's favourite Karmic GTK bug, I believe.
[07:12] <lifeless> RAOF: hmm, maybe I should take the time to fix it :P
[07:12] <lifeless> RAOF: is there a smaller test case than evo?
[07:13] <RAOF> lifeless: Pretty much every GTK app will do something like that _eventually_.  Evo seems to be the best at reproducing the particular phase of the moon required, though.
[07:14] <lifeless> evo is fantastic at it
[07:14] <lifeless> btw, turn up anytime
[07:17] <RAOF> lifeless: Hm.  It seems my laptop wants me to go now :)
[07:17] <RAOF> I was planning to get to the station at about 6ish; if I should be there earlier, I can do so.
[07:18] <lifeless> I live close by
[07:18] <lifeless> you can couch camp till its time to go
[07:19] <RAOF> OK.  I'll check that my phone has absorbed sufficient electrons for the evening and depart.
[07:32] <vila> hi all
[07:35] <igc> hi vila
[07:35] <vila> hi Ian
[07:36]  * vila shudders... At least the sound is back in my VM !
[07:46] <vila> Is there some reviewer around for https://code.launchpad.net/~vila/bzr/394190-osx-test-failures/+merge/8138 ?
[07:46] <vila> Whoever you are, I'll be grateful :-)
[08:17]  * igc heads off for a week of well deserved (in his opinion) vacation
[08:18] <igc> see everyone in a week's time
[08:48] <poolie> vila, i might do that
[08:49] <vila> poolie: that will allow me to reach a significant milestone for by build farm: having all instances fully pass the whole test suite. From there we can decide about the next step.
[09:58] <jml> who wants to review a small UI brancH?
[10:06] <jml> https://code.edge.launchpad.net/~jml/bzr/verbose-lp-login-bug-217031/+merge/8172
[10:11] <jml> bzr branch bzr://truth.local/bzr.dev
[10:11] <vila> jml: reading it right now
[10:11] <jml> vila, thanks.
[10:13] <vila> jml: I don't think 'jml' is meta enough to be used in tests, other than that: approve :D
[10:15] <jml> vila, thanks. will fix, add a NEWS entry & submit
[10:29] <vila> jml: oops, it was a joke ! Feel free to use whatever you see fit, it's refreshing to work with jml instead foo, bar<EMAIL_ADDRESS>[10:29] <jml> vila, hah. it's too late now :)
[10:30] <vila> jml: on the other hand, since it's your real handle, that may be risky if some leak occurs for an obscure reason, but that's a bit paranoiac :)
[10:31] <vila> jml: Now that I think about it, I should re-read these tests more carefully, maybe you're trying to take over every user that is running the test suite...
[10:31] <jml> haha
[10:34] <jml> next step: make bzr use launchpadlib
[10:53] <Kinnison> Is launchpadlib packaged nicely?
[11:00] <jml> Kinnison, I think it's in ubuntu & I think PyPI as well
[11:01] <jml> so... I'm thinking that lp-login should do the launchpadlib oauth authentication
[11:52] <bialix> perhaps I'
[11:53] <bialix> perhaps I'm missing something: does merge requests in bzr ML still supported?
[11:53] <bialix> or should I push my fix to LP as mandatory step?
[11:53] <bialix> vila: hi?
[12:01] <spiv> bialix: they're still supported AFAIK
[12:01] <bialix> ok
[12:01] <bialix> it's just BB is often down
[12:05] <jml> semslie, bzr ls -VR --kind=file --null | xargs -0 grep -In %s
[12:06] <jml> bialix, you can 'bzr send' to LP
[12:06] <jml> bialix, it'll create the branch for you.
[12:23] <bialix> jml: I can *send* to LP?
[12:23] <bialix> how?
[12:24] <jml> bialix<EMAIL_ADDRESS>[12:24] <jml> bialix, I think detailed instructions are on help.launchpad.net/Code
[12:25] <bialix> there is nothing about sending
[12:26] <amanica> Peng: I figured out how to resubmit in launchpad: just click on the merge proposal status and change it to resubmit
[12:28] <bialix> amanica: hi, how are you?
[12:29] <amanica> hi bialix, I'm great, and you?
[12:29] <amanica> long time no see
[12:29] <bialix> I'm fine, planning vacation
[12:29] <amanica> ah, I'm still recovering from mine :)
[12:30] <bialix> :-)
[12:30] <amanica> where are you going?
[12:30] <amanica> South Africa perhaps?
[12:30] <bialix> IIUC there is winter, right?
[12:30] <bialix> :-)
[12:31] <amanica> yes, but it doesn't snow here
[12:31] <amanica> not much anyways
[12:31] <bialix> although here is too hot, but I'd like to go to the sea with family
[12:31] <amanica> ah ok, enjoy
[12:31] <bialix> :-)
[12:32] <jml> bialix, https://help.launchpad.net/Code/Review
[12:32] <bialix> did you saw new Bazaar Explorer?
[12:32] <amanica> I still need to try it out - too many things on my todolist, but I'm very exited about BE
[12:33] <bialix> jml: there is certainly some black magic under the hood, how I should specify project?
[12:33] <amanica> I'ms tutorial with pictures looks very nice
[12:33] <amanica> /I'ms/Ians/
[12:33] <bialix> jml: I suspect it still require to have the branch on LP beforehand
[12:34] <bialix> it's not problem per se though
[12:34] <jml> bialix, well, the trunk branch needs to be on Launchpad
[12:34] <bialix> amanica: and you can translate it to Afrikaans ;-)
[12:34] <jml> bialix, if the public url of the submit branch is known to Launchpad, Launchpad will use the project of that branch
[12:34] <jml> bialix, lots of awesome magic.
[12:35] <bialix> jml: ok, will try
[12:36] <amanica> bialix:  I thought about that, but then I think its not that important for Afrikaans-speaking people since our English is generally good
[12:36] <bialix> I know, it was joke
[12:36] <amanica> especially for programmers, since our work is mostly english
[12:36] <bialix> ok ok
[12:36] <bialix> :-)
[12:36] <amanica> :-)
[12:37]  * bialix bbl
[12:49] <jml> poolie, you around?
[13:15] <Peng_> amanica: Ah, thanks. :)
[13:16] <amanica> Peng_: cool, I'm glad I found it
[13:26] <vila> bialix: hi !
[13:26] <bialix> vila: hi
[13:27] <bialix> does jam will be here?
[13:27] <vila> I second jml, it's not mandatory, but we now prefer merge proposals on LP
[13:27] <vila> bialix: nope
[13:27] <bialix> should I re-send my patch?
[13:27] <bialix> can I persuade you to review patch for set_hidden_attr?
[13:27] <vila> I will be better yes, can you add a  test ?
[13:27] <bialix> test for what?
[13:28] <vila> One that really handle a path *under* the directory, the one you have it handling the directory itself,
[13:28] <vila> certainly fine, but no harm in adding one that is described in the comment :)
[13:28] <bialix> ok
[13:29] <vila> I will leave jam approve and land it though as I'm a bit hesitant to land a patch that I can't test myself (yes, yes, setting up a windows VM is still on the list :-/)
[13:32] <bialix> oho! you really surprise me!
[13:38] <vila> bialix: about what ? Nor approving or not having a windows dev VM set up ?
[13:46] <bialix> about your intent to setup windows VM
[13:50]  * bialix tries to send to LP
[13:53] <vila> bialix: I had one in my previous life, but for perl-based dev, I never found the time since to set up one for python (but I briefly used bzr on windows at one point)
[13:55] <vila> I feel a vergence in the force... is jelmer starting to work on releasing bzr-gtk ? :-)
[13:56] <fullermd> No, that was just me...   I had beans for lunch.
[13:57]  * bialix found bug in bzr send @ win32
[13:57] <bialix> what is 'vergence'?
[13:57] <jelmer> vila, :-)
[13:57] <vila> jelmer: if not and I can help to, lpease ask
[13:58] <jelmer> vila, first step is to clear up all bug reports, hopefully a release after that
[13:58] <vila> bialix: no idea, I'm repeating what I heard in Star Wars ;-D
[13:58] <vila> awesome
[13:58] <fullermd> I don't think it's actually a word, at least in any sense like it was used there.
[13:59]  * bialix never seen Star Wars in English
[13:59] <vila> fullermd: your use or Obi-Wan use ?
[14:00] <fullermd> I think it springs from the Star Wars Rule; if it {looks,sounds,tastes} cool, it doesn't matter if it's imaginary or impossible, it's in.
[14:01] <bialix> vila: ha-ha, got it!
[14:01] <bialix> "I feel vergence in the force"
[14:01] <bialix> LOL
[14:02] <bialix> after translating it to Russian I can see your joke
[14:02] <bialix> :-D
[14:02] <vila> bialix: the context in Star Wars was that something was happening, but nobody knows how it will turn out in the end
[14:03] <vila> bialix: and of course paranormal powers are absolutely required for such predictions
[14:05] <bialix> I've always thought they talked about Power or Force (see capitalization), but it seems it's just force :-(
[14:06] <bialix> rats! bzr can't see my default e-mail client. something broken
[14:07] <bialix> again
[14:09] <bialix> ha ha
[14:09] <bialix> I can't send merge request to LP
[14:10] <bialix> it says: All emails to<EMAIL_ADDRESS>must be signed with your OpenPGP key.
[14:10] <bialix> very nice, I don't have one right now
[14:10] <bialix> heh
[14:10] <vila> rats :-/
[14:11] <vila> bialix: you know that lp created stacked branches now though, did you try bzr push lp:~bialix/... recently ?
[14:11] <bialix> old good push should help me
[14:11] <bialix> I have good channel right now, so I'm pushing
[14:11] <vila> ok
[14:11] <bialix> but I'm just wanna see magic
[14:12]  * bialix cries
[14:13]  * fullermd pulls a rabbit out of vila.
[14:13] <bialix> the branch pushed but not scanned yet
[14:13] <fullermd> Voila!
[14:13] <bialix> interesting, can I make merge request regardless?
[14:14] <vila> bialix: it usually takes a few seconds, minutes at worst
[14:14] <vila> bialix: by the way, the push was quick, you *do* have a good connection right now :0D
[14:14] <bialix> I did it! https://code.launchpad.net/~bialix/bzr/hidden_attr_on_unicode/+merge/8181
[14:15] <bialix> but send to ML was very nice thing
[14:15] <vila> bialix: want a cute one, try: 'bzr push ; bzr lp-open' :-D
[14:16] <vila> bialix: You can also request another review from jameinel from the URL above
[14:16] <bialix> C:\work\Bazaar\bzr-repo\hidden_dot_bzr_unicode>bzr lp-open lp:~bialix/bzr/hidden_attr_on_unicode
[14:16] <bialix> Opening https://code.edge.launchpad.net/~bialix/bzr/hidden_attr_on_unicode in web browser
[14:16] <bialix> bzr: ERROR: No module named webbrowser
[14:16] <bialix> You may need to install this Python library separately.
[14:16] <bialix> :-P
[14:16] <bialix> jml: why lp-open tries to open edge???
[14:16] <bialix> it's not fair!
[14:17] <vila> bialix: because, Yes You Can :)
[14:17] <vila> I thought webbrowser was part of the standard python library, are you using bzr.exe ?
[14:18] <bialix> what is Review type?
[14:18] <bialix> of course I'm using bzr.exe
[14:19] <bialix> vila: new test is OK for you?
[14:19] <vila> bialix: then file a bug against bzr.exe for not including a standard package used by a standard plugin :-D
[14:20] <bialix> it should be there, hmmm... another regression?
[14:20] <vila> bialix: yup
[14:20] <vila> bialix: it's imported lazily, could that explain it ?
[14:20] <bialix> yes
[14:20] <vila> hmm, tricky
[14:23] <bialix> yes
[14:26] <bialix> hm, does default e-mail client is editor?
[14:31] <vila> jelmer: can you update me about https://bugs.edge.launchpad.net/bzr/+bug/107169 ? Is it fixed upstream ? How ? Will it find its way in jaunty (since I hit it once after every reboot) ? Didn't Silvester had a work-around (swallowing the exception ?) ? Etc ? :D
[14:42] <jml> bialix, because it uses the edge xmlrpc service, because xmlrpclib handles redirects badly
[14:42] <bialix> I don't understand
[14:42] <jml> bialix, it gets the url from launchpad
[14:42] <jml> bialix, but it gets it from _edge_ launchpad
[14:43] <jml> bialix, so it's an edge url
[14:43] <bialix> non-edge lp can't do this?
[14:43] <jml> bialix, it can, but it will try to redirect anyone in launchpad-beta-testers
[14:44] <bialix> ok, it's too complex for me.
[14:49] <vila> bialix: are you a launchpad-beta-testers member ?
[14:49] <bialix> no
[14:50] <vila> ha, it's a bug then :)
[14:50] <bialix> in me?
[14:51] <vila> bialix: that too :-)
[14:51] <bialix> :-P
[14:52] <vila> no in lp, if you're not part of l-b-t, you shouldn't be redirected to edge, jml ? Am I correct ?
[14:52] <jml> vila, you're half right.
[14:52] <jml> vila, if you are not l-b-t, you are not redirected to edge
[14:52] <jml> but that's not what's happening here
[14:52] <jml> the bzr plugin has made a conscious decision to use edge
[14:53] <jml> because if we don't use edge, then people who are members of l-b-t get terrible errors
[14:53] <jml> because _some_ Python standard libraries don't support redirects.
[14:53] <jml> ZOMG it wasn't 200 it must be an error
[14:55] <vila> jml: ZOMG :) This one can be read in french as is :-D
[14:55] <jml> heh
[14:56] <jml> does l'Académie Française know about that?
[14:59] <vila> jml: pfff ;-P We have what we have and we do what we can with it :) whwwhawdwecwi sounds like mwhahahaha to me...
[15:00] <vila> I always Quebecers were better are defending French, but I was recently told I was wrong...
[15:00] <vila> I always thought Quebecers were better are defending French, but I was recently told I was wrong...
[15:00] <vila> L'Académie Française is good about defending herself though
[15:01] <jml> heh
[15:03] <vila> It's not that I don't like French, I like it very much thank you, but some of translations of words that never existed even in english are just a bit too much for my taste. Some are very nice at capturing the true meaning of the new word, but they are the exceptions. Some are just stupid like mel for mail which is just English with a strange accent ;-)
[15:05] <vila> déverminateur for debuger never made it for me, I was already a addicted bug hunter when they coined it though...
[15:05] <jml> heh
[15:08] <vila> For a good translation, I quite like ordinateur better than computer, but both are a bit out-dated now...
[15:08] <bialix> vila: can you run `bzr selftest -s bt.test_win32utils` on Linux? with LANG=C? please? s'il vous plait?
[15:08] <bialix> (for my patch)
[15:08] <pilky> anyone know what time zone martin pool is in, just wondering when he'd be on IRC
[15:09] <jml> pilky, Sydney.
[15:09] <pilky> ok thanks
[15:10] <vila> bialix: ha, *with* your patch ?  My word, what is your TZ ?
[15:12] <sidnei> vila: GMT-3
[15:13] <bialix> jam is right, but I think I need to check OS rather than Unicode
[15:13] <pilky> sidnei: -3? Is that Iceland?
[15:13] <vila> sidnei: oh, cool
[15:13] <sidnei> brazil actually
[15:13] <AfC1> lots of rat storms
[15:14] <vila> hmm, I feel like missing a joke about rats and storms, can someone kindly explain ? :-}
[15:14] <pilky> oh, I thought -3 was mid atlantic, ah well
[15:14] <pilky> "vila: rats, storm here, need to close windows"
[15:14] <AfC1> otherwise the rats will get in
[15:15] <sidnei> vila: so what can you tell me about your effort with buildbot?
[15:15] <vila> LOL, I thought 'rats' was kind of metasyntactic curse :)
[15:15] <vila> sidnei: anything you want to know :-)
[15:15] <bialix> vila: can I use TestSkipped or I should introduce OSWindowsFeature to skiup windows-specific tests?
[15:16] <sidnei> vila: what's the plan, basically. i know nothing about it ;)
[15:16] <vila> bialix: Using a feature is better so you get the number of tests skipped in the summary after a selftest run
[15:16] <vila> sidnei: did you see my mail from a couple of hours ago ?
[15:16] <bialix> vila: they'are already there: http://paste.ubuntu.com/209036/
[15:17] <sidnei> vila: maybe not, checking again
[15:17] <vila> bialix: then reuse it or define a new one
[15:17] <vila> bialix: let me have a closer look
[15:17] <bialix> vila: reuse TestSkipped?
[15:18] <vila> bialix: no, the features, circa line 58 in test_win32utils.py
[15:19] <bialix> there is no required module
[15:19] <bialix> even if win32file is not available, the code still works
[15:20] <vila> bialix: then look at bzrlib.test.Feature definition class and all classes that derive from it
[15:21] <bialix> let's say another time: does OS Windows is feature?
[15:22] <vila> bialix: if win32file is not available then I think jam remark is appropriate, use self.requireFeature(tests.UnicodexxxxFeature)
[15:22] <bialix> I can't find one
[15:22] <vila> I don't think OS windows is a feature (no pun intended :-D)
[15:22]  * vila is such a liar
[15:23] <vila> bialix: one sec
[15:25] <vila> bialix: bah, you even have two ! UnicodeFilename and UnicodeFilenameFeature
[15:25] <bialix> hm
[15:25] <bialix> ok, from the name it seems I need the latter
[15:25] <vila> right, UnicodeFilenameFeature is the one to be used, the former sounds like dirt to me
[15:27] <bialix> ok, I've fixed this. pushed on LP. jam already approved.
[15:27] <sidnei> vila: so you have a buildbot master setup yet?
[15:27] <bialix> vila: do you have the power to merge it, oh great master?
[15:28] <vila> sidnei: yes, on jaunty, with three slaves: jaunty, OSX tiger, OSX Leopard
[15:28] <vila> bialix: since jam approved, yes, did you update your branch ?
[15:28] <sidnei> vila: so can we point the buildbot client on kerguelen to it?
[15:28] <bialix> revno.4509
[15:29] <vila> sidnei: if you set up a slave to run the tests certainly
[15:29] <bialix> vila: yes, LP already got it
[15:29] <sidnei> vila: i've got it ready for building the installer, tests would be next step
[15:31] <vila> sidnei: hmm, I'm not sure I understand the logic here, my master ask the slaves to run the tests, not to build an installer
[15:31] <sidnei> vila: i guess you don't understand the master then :)
[15:31] <bialix> sidnei: is that you made zc.build patch?
[15:31] <sidnei> vila: you can configure the master to build many projects
[15:31] <sidnei> bialix: yes
[15:31] <vila> sidnei: ha, then I miss that part
[15:32] <bialix> sidnei: what the goal?
[15:32] <vila> sidnei: and associate only some slaves to some builders ?
[15:32] <sidnei> vila: so, in buildbot terms, you can have many 'builders', those are the different projects. and each 'builder' can have many slaves
[15:32] <sidnei> vila: exactly
[15:32] <vila> oh great
[15:33] <vila> so you mean I will be able to ask kerguelen whatever I want in addition to building the windows installers ?
[15:33] <sidnei> vila: correct
[15:33] <vila> woohoo
[15:33] <sidnei> bialix: automate fetching the build dependencies for the installer.
[15:33] <bialix> and?
[15:33] <vila> bialix: automate running the test suite against bzr.dev once a day and collect the results
[15:34] <vila> bialix: kerguelen is a windows machine in case you didn't notice
[15:34] <bialix> vila: I know
[15:34] <vila> bialix: do I surprise you again ? :-D
[15:35] <bialix> I don't understand why for "automate fetching the build dependencies for the installer." is needed? It's not target per se but mean. Yes? What's the target?
[15:35] <bialix> vila: no :-P
[15:35] <bialix> I was aware about kerguelen
[15:35] <bialix> this name is pun
[15:36] <sidnei> bialix: and there's a ton of dependencies scattered all over the place. you could have a plain python script or even a .bat file to fetch the dependencies, but using zc.buildout there are existing dedicated recipes for doing things like 'download this zip file and unpack in directory X' and 'checkout branch Z from this url'
[15:36] <vila> bialix: looking at your patch in context: self.requireFeature() perfect: http://paste.ubuntu.com/209051/
[15:36] <bialix> vila: thanks
[15:37] <vila> sidnei: do you know if the zope license is compatible with the GPL  ?
[15:37] <bialix> sidnei: are you aware about Bug 388790
[15:38] <bialix> sidnei: if you can solve python-vased install with your zc.build patch this will be Great Target. No?
[15:38] <vila> bialix: does your patch fixes #335362 or is it only a partial fix (i.e. should I --fixes lp:335362)
[15:38] <sidnei> vila: im almost sure it is, but why the question? there's no ZPL code there
[15:38] <vila> sidnei: I think the file you added is under zope license
[15:39] <bialix> vila: not really
[15:39] <sidnei> vila: ah, bootstrap.py might be
[15:39] <vila> sidnei: yes maybe that one
[15:39] <bialix> vila: it was discovered by Naoki while discussing that bug.
[15:39] <vila> bialix: of so, no --fixes
[15:39] <sidnei> vila: http://www.zope.org/Resources/ZPL
[15:40] <bialix> I prefer no fixes
[15:40] <sidnei> "This license has been certified as open source. It has also been designated as GPL compatible by the Free Software Foundation (FSF)."
[15:40] <vila> sidnei: great
[15:41] <sidnei> bialix: i wasn't aware of that bug. in fact, im not supposed to be working on the installers per se, only automating the build.
[15:41] <bialix> automating for what or for who?
[15:42] <vila> bialix: -m '(bialix) Setting hidden attribute on win32 should never fail (and OS locks must die, but I diverge).' ok ?
[15:42] <bialix> perfect!!!
[15:43] <bialix> :-D :-D :-D
[15:43] <sidnei> bialix: having a buildbot that builds each installer every day, so that it requires no manual intervention other than telling buildbot when new versions are released.
[15:43] <bialix> sidnei: so, it can/should be used instead of build_release.py?
[15:43] <vila> bialix: naaaah, they will die, no need for that :)
[15:44] <bialix> rats!
[15:45] <vila> sidnei: so what needs to happen ? You send me your master.cfg file and I send you my build master host/port address ?
[15:45] <vila> sidnei: and you nokia can take some rest ? :0D
[15:46] <sidnei> bialix: supposedly yes. to make it clear, build_release.py expects you to manually get all the bits and pieces like the svn dev binaries and tortoiseoverlays. the new stuff fetches the svn dev binaries and tortoise overlays and all the different bzr branches of the plugins for you, then there's a 'build-installer.bat' that does just the core of what build_release.py does.
[15:47] <sidnei> vila: correct, that's the plan.
[15:47] <vila> sidnei: ok
[15:47] <sidnei> vila: if you can put *your* master.cfg on a branch, and then i send you a merge proposal, that would be perfect actually
[15:47] <sidnei> vila: i like that idea of keeping the passwords external to it though
[15:48] <sidnei> vila: so we should do that
[15:48] <vila> sidnei: ok, I let you know as soon as it is done
[15:48] <bialix> sidnei: one suggestion then: can you start the process from root dir, will be nice as `make xxx` and put all installers there?
[15:48] <sidnei> bialix: sounds good to me
[15:49] <sidnei> bialix: i will do that
[15:53] <jml> Python 2.6.2+ (release26-maint, Jun 19 2009, 15:16:33)
[15:53] <jml> [GCC 4.4.0] on linux2
[15:53] <jml> Type "help", "copyright", "credits" or "license" for more information.
[15:53] <jml> >>> from bzrlib.transport import get_transport
[15:53] <jml> >>> t = get_transport('bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk')
[15:53] <jml> >>> t.base
[15:53] <jml> 'bzr+ssh://bazaar.launchpad.net/%7Ebzr/bzr/trunk/'
[15:53] <jml> >>>
[15:54] <LarstiQ> right
[15:54] <jml> what the hell is escaping the tilde
[15:59] <vila> jml: damn ! It's not as if noone landed a patch to avoid precisely that ! :-)
[16:00] <sidnei> bialix: so where the installers should be put? at the root dir?
[16:01] <jml> vila, :)
[16:05] <bialix> sidnei: it will be nice, though the last word should be from jam
[16:05] <sidnei> bialix: ok, thanks!
[16:06] <bialix> sidnei: from the rule: don't break what is working today
[16:07] <sidnei> bialix: yeah, i tried to avoid that as much as possible, hopefully it will be fine.
[16:18]  * mgedmin sighs
[16:18]  * bialix sighs
[16:18] <LarstiQ> mgedmin: can I help you?
[16:18]  * mgedmin doesn't know
[16:19] <mgedmin> do you know why in jaunty I cannot use bzr viz?
[16:19] <mgedmin> I get an internal error
[16:19] <mgedmin> I have no plugins in ~/.bazaar
[16:19] <LarstiQ> bzr-gtk and bzr are both from jaunty?
[16:19] <mgedmin> are there plugins in jaunty that are incompatible with bzr in jaunty?
[16:19] <mgedmin> yes they are
[16:19] <mgedmin> no PPAs
[16:19] <LarstiQ> mgedmin: I would hope not
[16:19] <mgedmin> bzr 1.13.1-1, bzr-gtk 0.95.0+bzr629-1ubuntu1
[16:20] <mgedmin> the error is ... gone!
[16:20]  * LarstiQ blinks
[16:20] <mgedmin> it was DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 0
[16:20] <mgedmin> I hadn't thought to simply re-run the command again
[16:20] <LarstiQ> ah
[16:21] <mgedmin> should I file a bug?
[16:21] <LarstiQ> that sounds like a bzr-dbus thing
[16:21] <LarstiQ> mgedmin: hmm, maybe check if there is already one
[16:22] <jelmer> mgedmin, IIRC this was a seahorse bug
[16:23] <jelmer> mgedmin, the first time seahorse is contacted over dbus it breaks and doesn't reply
[16:24] <mgedmin> seahorse.py is in the traceback, yep
[16:24] <mgedmin> I'm at a sprint and we'll be kicked away from here in 30 minutes, so I don't have time to search launchpad for bugs now
[16:24] <mgedmin> but thanks for the explanation
[16:28] <mgedmin> hey, actually my working dir is clean and I won't have time to start a new task
[16:29] <mgedmin> oh no, I closed the terminal with the traceback
[16:58] <vila> mgedmin: try again, for me that bug happens only once after each reboot
[17:01] <mgedmin> I'm most definitely not going to reboot just to reproduce a bug, sorry
[17:01] <mgedmin> reboots in ubuntu *suck*
[17:05] <dash> huh. more than in something else?
[17:05] <dash> oh he left
[17:06] <dash> so i guess i can't tell him about http://www.ksplice.com/
[17:07] <vila> dash: LOL
[17:08] <vila> Well my point was to give him the work-around not asking to reproduce :)
[18:15] <johnskulski> I am working with a svn repository that I bzr branched. So when I merge changes, commit and push all the commits come from me and not the people who actually committed. Is there a work flow around this?
[18:43] <Peng_> lifeless: Ya know, lp:bzr-guess is branch 6, even though it uses a 2a repo. :D
[18:43]  * SamB still doesn't understand what the --incremental option to svn-import does
[18:44] <Peng_> SamB: If 'bzr svn-import' was 'bzr branch', 'bzr svn-import --incremental' would be its 'bzr pull'.
[18:45] <SamB> hmm. so why doesn't the help for svn-import say anything to that effect?
[18:46] <Peng_> SamB: I dunno. Maybe I'm wrong, eh? :D
[18:46] <SamB> and why not make it the default?
[18:46] <Peng_> SamB: I dunno. Ask jelmer.
[18:47] <SamB> hmm, I'm pasting this IRC conversation into a bug, okay?
[18:47] <Peng_> Okay.
[18:47] <SamB> thanks ;-)
[18:49] <Peng_> Seconds after I installed bzr-guess, I typed "bzr missung", and it worked. :)
[18:56] <SamB> hmm, too bad that john dude left :-(
[19:15] <SamB> Peng_: okay, it's bug 395266
[19:16] <Peng_> SamB: Yeah, I just saw the bugmail. :D
[19:17] <SamB> Peng: ah.
[19:17] <SamB> didn't know who all was on the team or whatever
[19:17] <SamB> hmm, should I have used your real name instead of your IRC nick?
[19:18] <Peng_> SamB: I'm not, but I subscribe to a lot of bugmail.
[19:18] <Peng_> SamB: Eh, doesn't matte.r
[19:20]  * Peng_ gets killed by ghosts.
[19:21] <Peng_> How do you find if a certain revision ID exists in a repo, without knowing the specific branch?
[19:23] <SamB> oh, that reminds me
[19:24] <SamB> I need to complain about bzr-gtk not supporting visualization of entire repositories, or at least of all branches that can be found within them
[19:24] <Peng_> Oh, never mind, I had just messed something up.
[19:25] <gioele> SamB: use "bzr explore" (from the Bazaar Explorer plugin)
[19:25] <SamB> doesn't that need qbzr?
[19:25] <gioele> SamB: yes it does
[19:26]  * SamB checks if he has that, and if not why not
[19:27] <gioele> SamB: there is a PPA for latest qbzr
[19:27] <SamB> hmm, reason seems to be that it pulls in 65 megabytes of qt4-related dependencies
[19:28] <SamB> stupid gigantic python-qt4 package :-(
[19:29] <Peng_> See? 640k and the CLI should be enough for everyone. :D
[19:35] <gioele> SamB: ask the python-qt4 packagers to split the package into qt4-like sub-modules
[19:37] <SamB> you think they'd listen?
[19:38] <SamB> the libc maintainer was really not keen on splitting the debug info into multiple packages -- not even a seperate one for x86_64 :-(
[19:39] <gioele> SamB: well, libqt4 packages are split in Ubuntu
[19:46] <SamB> libqt4 packages themselves are split here, too
[19:48] <Peng_> What the... How can pulling a bunch of branches from one repo to another leave the new repo with more revisions than the old one?  :D
[19:51] <jh> hi, I have an outdated local repository with some uncommitted changes. now I want to pull a new copy from the global repository. but with "bzr pull --overwrite" I encounter several conflicts... how is that possible?
[19:53] <Peng_> jh: I guess your uncommitted changes conflict with some upstream changes?
[19:54] <jh> but I said --overwrite
[19:54] <SamB> jh: that's not what overwrite does
[19:54] <jh> what does overwrite?
[19:54] <jh> and what does what I want? =)
[19:55] <gioele> jh:  overwrite means "ignore that I have something to merge upstream"
[19:55] <SamB> what --overwrite does is it disregards whether the revision your tree is currently based on is an ancestor of the one you would be pulling in
[19:55] <SamB> normally, it refuses to pull when your revision isn't an ancestor of the one to be pulled in
[19:56] <jh> hm, bzr pull --overwrite + bzr revert does what I want
[19:56] <SamB> I don't think you should pass --overwrite
[19:57] <SamB> it doesn't do what you want, and might do something you don't want
[19:59] <jh> I just want the current revision from the global repo in my working copy
[19:59] <jh> ignoring everything else
[19:59] <jh> how should I do that?
[20:00] <gioele> bzr update?
[20:01] <gioele> oops, I meant, "make it bound thatn bzr update"?
[20:01] <gioele> s/thatn/then/
[20:01] <jh> "make it bound"?
[20:02] <gioele> bzr reconfigure --bind-to
[20:04] <jh> k, thx
[20:04] <jh> will try that next time
[20:09] <Peng_> Isn't there a bug about Bad Things happening to the dirstate when upgrading to rich roots?
[20:25] <ndurner> Hi
[21:30] <fta> james_w, i have a problem with bzr-builddeb in karmic: http://paste.ubuntu.com/209269/
[21:34] <james_w> fta: ouch
[21:35] <fta> james_w, i have that quite often, and the tarball is always fine. dpkg-buildpackage has no problem dealing with it directly.
[21:37] <fta> started a few weeks ago
[21:37] <james_w> gzip: stdout: Broken pipe
[21:37] <james_w> so tar is dying?
[21:37] <james_w> no, clearly not
[21:37] <james_w> but gzip is failing to write to it
[21:39] <Peng_> I just "bzr pack"ed a 2a repo down 9 KB. Awesome! :D
[21:41] <fta> james_w, as i said, the tarball file is just fine, but bzr-builddeb can't use it, for some reason. looks like a short pipe to me, one end closing too early. as it's gzip complaining, it's either tar or python
[21:42] <james_w> tar I think
[21:43] <fta> but tar in cli has no problem
[21:43] <james_w>                 ret = subprocess.call(['tar','-C',tempdir,'-xf',tarball])
[21:45] <james_w> so I don't see what is different there
[21:45] <james_w> can you reproduce with something like that in a python prompt
[21:45] <james_w> does it happen every time?
[21:51] <Peng_> But then repacking made something else 16 KB larger. So much for that.
[21:51] <Peng_> Shouldn't "bzr pack" be deterministic?
[21:52] <Peng_> Or, well, uh, not changing every time you run it?
[21:54] <fta> james_w, http://paste.ubuntu.com/209289/
[21:55] <Peng_> Err, bytes, not KB.
[22:53] <james_w> fta: I've no idea really why that would be happening
[22:58] <fta> james_w, http://paste.ubuntu.com/209301/
[22:58] <fta> strange, every few days, it's a different tarball. asac is also experiencing that on his side
[22:59] <james_w> how do you "fix" it?
[22:59] <james_w> it happens every time for that tarball once it starts?
[22:59] <james_w> could you add a "v" to the command to see if that gives any clues?
[23:00] <fta> i straced it, it's trying to write on a closed fd
[23:08] <james_w> fta: could you pastebin the strace please?
[23:09] <fta> james_w, http://paste.ubuntu.com/209340/
[23:15] <james_w> so it seems to finish, and then keep trying to write more data
[23:15] <james_w> it is odd
[23:16] <james_w> I wonder if it could be http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009/07/02#2009-07-02-python-sigpipe
[23:21] <fta> james_w, sorry, i know a lot of languages but close to nothing in python.. http://paste.ubuntu.com/209345/
[23:22] <fta> i can give you the tarball if you like, it's 100% reproducible here
[23:24] <james_w> you can just add preexec_fn=subprocess_setup to the original call by my reading
[23:24] <james_w> otherwise that works for me
[23:25] <fta> http://www.sofaraway.org/ubuntu/tmp/songbird_1.3.0~a~svn20090703r14148.orig.tar.gz
[23:28] <james_w> thanks


[00:12] <PrivateVoid> hello - anyone home?
[00:13] <LaserJock> PrivateVoid: what's up?
[00:13] <PrivateVoid> just curious what the status of the project on this page is -- https://wiki.ubuntu.com/education
[00:14] <LaserJock> PrivateVoid: have a look at http://www.ubuntu.com/education
[00:15] <PrivateVoid> is that the same as the link I posted?
[00:15] <LaserJock> not the same, no
[00:16] <LaserJock> but I think that's perhaps what is being talked about on that page
[00:17] <PrivateVoid> yeah... to a certain extent...
[00:17] <PrivateVoid> I was hoping to see some specific blueprints for deploying Linux (Ubuntu) in a K-12 environment
[00:18] <PrivateVoid> how to replace Windows / OS X
[00:18] <PrivateVoid> how to replace AD / OD / NDS
[00:19] <LaserJock> that's sort of a hard thing to give blueprints for
[00:19] <LaserJock> as there are a lot of ways to do those things
[00:20] <PrivateVoid> hard or not... we need to develop a few rough blueprints IMHO
[00:20] <LaserJock> sure
[00:20] <PrivateVoid> there may be a few hundred ways to do it, but we need to lay that out so K-12 institutions can attempt to do it
[00:20] <LaserJock> right
[00:20] <PrivateVoid> i did not know if people were working on that or not...
[00:21] <LaserJock> off hand the best thing i can think of is asking the edubuntu-users mailing list
[00:21] <LaserJock> not currently that I know of unfortunately
[00:21] <PrivateVoid> I intend to travel down that road in the next 6-12 months and if people are not working on it I can take some extra time to document more completely my experiences and results
[00:22] <LaserJock> I'm sure that people would both love to see that and would probably love to help you along
[00:25] <PrivateVoid> awesome
[00:26] <PrivateVoid> I am a Sys Admin for a K-12 and budget constraints finally have the bean counters paying attention to my discussion of FOSS
[00:26] <LaserJock> PrivateVoid: I would ask on edubuntu-users first though
[00:26] <LaserJock> I know some people have been doing a fair amount of documentation
[00:26] <LaserJock> but I don't think I've seen a  complete "blueprint" as you're talking about
[00:29] <PrivateVoid> I will ask... thanks...
[00:29] <PrivateVoid> you are talking about the mailing list - right?
[00:29] <LaserJock> yes
[00:29] <LaserJock> that's a lot better than asking just me :-)
[00:32] <PrivateVoid> Yet, you have been very helpful and I am most appreciative
[00:33] <LaserJock> no problem
[00:33] <LaserJock> I very much appreciate you being interested
[00:33] <LaserJock> we are sorely lacking "manpower"
[00:33] <LaserJock> so any  help is very much welcome
[00:42] <Ahmuck> this is the same issue i've encountered
[00:43] <Ahmuck> to gain wide adoptions "it just has to work" (tm)
[00:48] <PrivateVoid> Ahmuck, it doesn't just have to work...
[00:49] <PrivateVoid> but it can not be vodoo science with no 'best practice'
[00:49] <PrivateVoid> there is a large chasm between the two
[15:13] <sbalneav> Morning all
[15:23] <Ahmuck> *streches* ... good morning
[17:42]  * PrivateVoid waves
[17:55] <HedgeMage> hi :)
[17:56]  * Ahmuck bugs nubae
[18:09] <PrivateVoid> hello Ahmuck and HedgeMage
[18:10] <PrivateVoid> HedgeMage, I have some potions you might be interested in :-)
[18:10] <HedgeMage> greetings, PrivateVoid
[18:10] <HedgeMage> lol
[18:10] <PrivateVoid> you still do any roleplaying?
[18:11] <HedgeMage> Not really -- this isn't a good location for getting a group together.  Most of my friends are a significant drive out of town.
[18:11] <PrivateVoid> I know the feeling...
[18:11] <HedgeMage> I may consider getting an ED game together after I move, but that depends on how much time I have, and what else I'd like to spend it on.
[18:11] <PrivateVoid> after roleplaying was such a large part of my life (for entertainment) I no longer play...
[18:12] <PrivateVoid> started in 1976 and played my final game five years ago... been thinking of doing a mud or some such
[18:13] <HedgeMage> I don't know that it was ever a huge part of my life...I played a bit in college, then got more into it after I started a family -- it was a good, cheap form of entertainment that I could enjoy at home with the munchkin around.
[18:13] <HedgeMage> Though, my nick actually isn't an RP reference... it's a reference to my being self-taught at many things.
[18:14] <PrivateVoid> like so many of us... I am self-taught as well.
[18:14] <HedgeMage> :)
[23:57] <nubae> Ahmuck: I'm here now