 We had our first rain in months and a storm, so that was exciting.
[08:43] <duflu> How was yours, seb128?
[08:45] <didrocks> seb128: week-end was nice, indeed. Ready for hopefully a sunny week :) and you?
[08:47] <jpnurmi> hey duflu and seb128
[08:49] <jpnurmi> seb128, i had a very nice and extra long weekend, thanks :)
[08:51] <seb128> weekend was nice, we had friends over for dinner and nice weather on saturday, yesterday was windy and rainy so, sort of a long day stucked inside with children who needed to get some action
[09:32] <Nafallo> hi seb128 :-). just nice and relaxed weekend.
[09:32] <Nafallo> mostly hanging in the hammock watching videos :-P
[09:48] <seb128> :)
[09:48] <seb128> duflu, you sometime bisect kernels right, do we have some script to help there? do you build from ubuntu vcs or upstream?
[09:50] <duflu> seb128, no scripts, just git. In the past I found it most helpful to bisect our Ubuntu branches. But you can generally tell what to bisect by testing a couple of different kernels before you start
[09:51] <juliank> autopkgtest cloud is down for maintenance, see #ubuntu-release for details
[09:51] <juliank> should be back up very soon
[09:51] <juliank> oops, that was for #-devel
[09:55] <seb128> duflu, ack, thanks
[09:58] <duflu> seb128, I assume you're familiar with the 'git bisect' subcommands
[10:00] <seb128> duflu, yes, I've just not used it on the kernel so far :)
[10:03] <duflu> Remembering how to build a kernel and install it, then booting the right one to test, is the tricky part for me
[10:18] <seb128> duflu, right, which is why I asked if we have some script helping wit that :) at least there is wiki documentation
[10:57] <oSoMoN> RikMills, FYI I just filed bug #1960220, I'd appreciate your opinion
[10:58] <RikMills> oSoMoN: thanks. will sort that. I wondered the other day if we needed it!
[10:59] <didrocks> seb128: it seems ubuntu-desktop-advantage-daemon source and binary was never in universe despite https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-desktop-daemon/+bug/1954909/comments/6 (note that the source was not listed there). When I want to promote it, it says there is no team subscription, mind doing so?
[11:00] <didrocks> worse, if I git pull u-a-t, the last version doesn’t warn about no team subscription…
[11:02] <didrocks> ah no, it still does, but this is after acking for promotion, not before
[11:02] <didrocks> I don’t know why vorlon didn’t override the source package. I think this is why he missed the warning on due to no subscriber
[11:30] <seb128> didrocks, desktop-packages subscribed now
[11:35] <didrocks> thx
[11:46] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442186 (extract-source) stage: provisioning, status: created
[11:46] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442188 (build i386) stage: build, status: created
[11:46] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442187 (build) stage: build, status: created
[11:46] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442189 (build source) stage: build, status: created
[11:46] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442190 (test-build-any) stage: test, status: created
[11:46] <KGB-0> gnome-shell-extension-caffeine pipeline Simon McVittie 345577 * pending (build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created; extract-source: pending; build: created)
[11:46] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442191 (test-build-all) stage: test, status: created
[11:46] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442192 (test-crossbuild-arm64) stage: test, status: created
[11:46] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442193 (reprotest) stage: test, status: created
[11:47] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442194 (lintian) stage: test, status: created
[11:47] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442195 (autopkgtest) stage: test, status: created
[11:47] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442196 (blhc) stage: test, status: created
[11:47] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442197 (piuparts) stage: test, status: created
[11:47] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442186 (extract-source) stage: provisioning, status: running. Duration: no time
[11:47] <KGB-0> gnome-shell-extension-caffeine pipeline Simon McVittie 345577 * running (extract-source: running; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created; build: created)
[11:47] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442186 (extract-source) stage: provisioning, status: success. Duration: 1 minute and 22 seconds
[11:47] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442187 (build) stage: build, status: running. Duration: no time
[11:48] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442188 (build i386) stage: build, status: running. Duration: no time
[11:48] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442189 (build source) stage: build, status: running. Duration: no time
[11:49] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442189 (build source) stage: build, status: success. Duration: 1 minute and 44 seconds
[11:49] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442187 (build) stage: build, status: success. Duration: 1 minute and 48 seconds
[11:49] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442193 (reprotest) stage: test, status: running. Duration: no time
[11:49] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442194 (lintian) stage: test, status: running. Duration: no time
[11:49] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442195 (autopkgtest) stage: test, status: running. Duration: no time
[11:49] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442188 (build i386) stage: build, status: success. Duration: 1 minute and 52 seconds
[11:49] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442190 (test-build-any) stage: test, status: running. Duration: no time
[11:49] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442191 (test-build-all) stage: test, status: running. Duration: no time
[11:50] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442192 (test-crossbuild-arm64) stage: test, status: running. Duration: no time
[11:50] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442196 (blhc) stage: test, status: running. Duration: no time
[11:50] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442197 (piuparts) stage: test, status: running. Duration: no time
[11:50] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442190 (test-build-any) stage: test, status: success. Duration: 1 minute and 12 seconds
[11:50] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442196 (blhc) stage: test, status: success. Duration: 1 minute and 12 seconds
[11:50] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442192 (test-crossbuild-arm64) stage: test, status: success. Duration: 1 minute and 14 seconds
[11:50] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442194 (lintian) stage: test, status: success. Duration: 1 minute and 34 seconds
[11:51] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442191 (test-build-all) stage: test, status: success. Duration: 1 minute and 47 seconds
[11:51] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442193 (reprotest) stage: test, status: success. Duration: 1 minute and 55 seconds
[11:51] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442195 (autopkgtest) stage: test, status: success. Duration: 2 minutes and 24 seconds
[11:51] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-caffeine builds Simon McVittie * Build #2442197 (piuparts) stage: test, status: failed. Duration: 2 minutes and 28 seconds
[11:51] <KGB-0> gnome-shell-extension-caffeine pipeline Simon McVittie 345577 * [5 minutes and 46 seconds] failed (piuparts: failed; autopkgtest: success; reprotest: success; test-build-all: success; lintian: success; test-crossbuild-arm64: success; blhc: success; test-build-any: success; build i386: success; build: success; build source: success; extract-source: success)
[11:58] <popey> hello! I just did a dist-upgrade on 21.10 this morning, which pulled in linux-objects-nvidia-470-5.13.0-28-generic & linux-signatures-nvidia-5.13.0-28-generic which then *removed* the nvidia driver from my system. I am scared to reboot, because I suspect it's now broken. Is this a known bug / issue? https://pastebin.com/raw/Sw3P22Jj
[12:03] <popey> Possibly related: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-450-server/+bug/1957790
[12:11] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442248 (build) stage: build, status: created
[12:11] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442247 (extract-source) stage: provisioning, status: created
[12:11] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442249 (build i386) stage: build, status: created
[12:11] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442250 (build source) stage: build, status: created
[12:11] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442251 (test-build-any) stage: test, status: created
[12:11] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442252 (test-build-all) stage: test, status: created
[12:12] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442253 (test-crossbuild-arm64) stage: test, status: created
[12:12] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442254 (reprotest) stage: test, status: created
[12:12] <KGB-0> gnome-shell-extension-top-icons-plus pipeline Simon McVittie 345585 * pending (build: created; build i386: created; build source: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created; extract-source: pending; test-build-any: created)
[12:12] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442255 (lintian) stage: test, status: created
[12:12] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442257 (blhc) stage: test, status: created
[12:12] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442256 (autopkgtest) stage: test, status: created
[12:12] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442258 (piuparts) stage: test, status: created
[12:12] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442247 (extract-source) stage: provisioning, status: running. Duration: no time
[12:13] <KGB-0> gnome-shell-extension-top-icons-plus pipeline Simon McVittie 345585 * running (extract-source: running; build: created; build i386: created; build source: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created; test-build-any: created)
[12:13] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442247 (extract-source) stage: provisioning, status: success. Duration: 1 minute and 24 seconds
[12:13] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442248 (build) stage: build, status: running. Duration: no time
[12:13] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442249 (build i386) stage: build, status: running. Duration: no time
[12:13] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442250 (build source) stage: build, status: running. Duration: no time
[12:14] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442250 (build source) stage: build, status: success. Duration: 1 minute and 39 seconds
[12:14] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442248 (build) stage: build, status: success. Duration: 1 minute and 45 seconds
[12:14] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442254 (reprotest) stage: test, status: running. Duration: no time
[12:14] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442255 (lintian) stage: test, status: running. Duration: no time
[12:15] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442256 (autopkgtest) stage: test, status: running. Duration: no time
[12:15] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442257 (blhc) stage: test, status: running. Duration: no time
[12:15] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442249 (build i386) stage: build, status: success. Duration: 1 minute and 48 seconds
[12:15] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442252 (test-build-all) stage: test, status: running. Duration: 1 second
[12:15] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442251 (test-build-any) stage: test, status: running. Duration: no time
[12:15] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442253 (test-crossbuild-arm64) stage: test, status: running. Duration: no time
[12:15] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442258 (piuparts) stage: test, status: running. Duration: no time
[12:16] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442257 (blhc) stage: test, status: success. Duration: 1 minute and 12 seconds
[12:16] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442253 (test-crossbuild-arm64) stage: test, status: success. Duration: 1 minute and 13 seconds
[12:16] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442251 (test-build-any) stage: test, status: success. Duration: 1 minute and 15 seconds
[12:16] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442255 (lintian) stage: test, status: success. Duration: 1 minute and 37 seconds
[12:16] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442252 (test-build-all) stage: test, status: success. Duration: 1 minute and 43 seconds
[12:16] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442254 (reprotest) stage: test, status: success. Duration: 1 minute and 56 seconds
[12:17] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442256 (autopkgtest) stage: test, status: success. Duration: 2 minutes and 16 seconds
[12:17] <KGB-0> GNOME / shell-extensions / gnome-shell-extension-top-icons-plus builds Simon McVittie * Build #2442258 (piuparts) stage: test, status: failed. Duration: 2 minutes and 29 seconds
[12:17] <KGB-0> gnome-shell-extension-top-icons-plus pipeline Simon McVittie 345585 * [5 minutes and 45 seconds] failed (piuparts: failed; autopkgtest: success; reprotest: success; test-build-all: success; lintian: success; test-build-any: success; test-crossbuild-arm64: success; blhc: success; build i386: success; build: success; build source: success; extract-source: succ
[12:17] <KGB-0> shell-extensionsess)
[12:42] <KGB-0> deja-dup tags 75040fa Sebastien Bacher upstream/42.9 * Upstream version 42.9 * https://deb.li/3aqwc
[12:42] <KGB-0> deja-dup upstream/latest 552c0d1 Sebastien Bacher * pushed 21 commits (first 5 follow) * https://deb.li/yg2D
[12:42] <KGB-0> deja-dup upstream/latest 96e5fdf Michael Terry data/ (13 files in 2 dirs) * appdata: update metadata and screenshots for current recommendations * https://deb.li/3MEGz
[12:42] <KGB-0> deja-dup upstream/latest e7e67b8 Enrico Nicoletto help/pt_BR/pt_BR.po * Update Brazilian Portuguese translation * https://deb.li/IPil
[12:43] <KGB-0> deja-dup upstream/latest 653a64c Michael Terry deja-dup/main.vala monitor/monitor.vala * Fix a couple race conditions for automatic backups * https://deb.li/3eacI
[12:43] <KGB-0> deja-dup upstream/latest 8b04433 Goran Vidović po/hr.po * Update Croatian translation * https://deb.li/3f66d
[12:43] <KGB-0> deja-dup upstream/latest 4de4487 Dušan Kazik po/sk.po * Update Slovak translation * https://deb.li/Ma8F
[12:43] <KGB-0> deja-dup pristine-tar 3113943 Sebastien Bacher deja-dup_42.9.orig.tar.gz.delta deja-dup_42.9.orig.tar.gz.id * pristine-tar data for deja-dup_42.9.orig.tar.gz * https://deb.li/3kqhE
[12:45] <KGB-0> deja-dup signed tags b8a1bee Sebastien Bacher ubuntu/42.9-1ubuntu1 * deja-dup Debian release 42.9-1ubuntu1 * https://deb.li/iW6ye
[12:45] <KGB-0> deja-dup ubuntu/master 4b8fca0 Sebastien Bacher * pushed 26 commits (first 5 follow) * https://deb.li/paM0
[12:45] <KGB-0> deja-dup ubuntu/master 05c5676 Matej Urbančič po/sl.po * Update Slovenian translation * https://deb.li/ikjt1
[12:45] <KGB-0> deja-dup ubuntu/master e826bdf Michael Terry libdeja/ BackendLocal.vala BackendRemote.vala * backends: fix path parsing with glib 2.71+ * https://deb.li/7a0j
[12:45] <KGB-0> deja-dup ubuntu/master 80eef9f Michael Terry po/hr.po * Add license header to hr.po * https://deb.li/3rjCR
[12:45] <KGB-0> deja-dup ubuntu/master 7683032 Danial Behzadi po/fa.po * Update Persian translation * https://deb.li/3jjL2
[12:45] <KGB-0> deja-dup ubuntu/master 2147f1d Hugo Carvalho po/pt.po * Update Portuguese translation * https://deb.li/YgWi
[13:04] <jbicha> good morning
[13:11] <seb128> jbicha, hey, how are you? did you have a nice weekend?
[13:14] <jbicha> yes, the weather cooled off (no longer in the 80s F !) so feels more typical for a Florida February
[13:35] <oSoMoN> hey jbicha
[13:37] <jbicha> oSoMoN: ricotz: hi, we have a new poppler in Jammy, hope it doesn't cause any build problems for LibreOffice. This is the poppler release we'll stick with for 22.04
[13:37] <KGB-0> gnome-recipes signed tags 94ae70e Jeremy Bicha upstream/2.0.4 * Upstream version 2.0.4 * https://deb.li/iQaCE
[13:38] <KGB-0> gnome-recipes upstream/latest 4feaeb9 Jeremy Bicha * pushed 143 commits (first 5 follow) * https://deb.li/6gw1
[13:38] <KGB-0> gnome-recipes upstream/latest 72548f6 Matthew Leeds src/gr-recipe-exporter.c * exporter: Don't call g_list_length() on NULL * https://deb.li/iwEYN
[13:38] <KGB-0> gnome-recipes upstream/latest aab21f7 Matthew Leeds src/gr-recipe-exporter.c * Merge branch 'move-g-info-stmt' into 'master' * https://deb.li/KghR
[13:38] <KGB-0> gnome-recipes upstream/latest 429306b Matthew Leeds src/gr-utils.c * utils: Fix potential NULL pointer use * https://deb.li/3PEyv
[13:39] <KGB-0> gnome-recipes upstream/latest a4ea000 Matthew Leeds src/gr-utils.c * Merge branch 'check-dbus-proxy-error' into 'master' * https://deb.li/sjcz
[13:39] <KGB-0> gnome-recipes upstream/latest 5eadba5 Matthew Leeds src/gr-app.c * Merge branch 'fix-help-crash' into 'master' * https://deb.li/3nq4s
[13:39] <KGB-0> gnome-recipes pristine-tar e4cc42a Jeremy Bicha gnome-recipes_2.0.4.orig.tar.xz.delta gnome-recipes_2.0.4.orig.tar.xz.id * pristine-tar data for gnome-recipes_2.0.4.orig.tar.xz * https://deb.li/cqCI
[13:42] <didrocks> ricotz: seb128, libreoffice in proposed starts recommending epiphany, mind looking at this?
[13:47] <ricotz> jbicha, hi, there will be an 7.3.1 RC1 build later this week, poppler 22.01.0 got some upstream testing, so will we see how 22.02.0 will work out
[13:48] <ricotz> didrocks, hmm, I thought that "firefox-esr | epiphany-browser | konqueror | chromium | firefox" would do the right thing
[13:49] <jbicha> I think dependency order for Ubuntu seeding is complicated
[13:49] <ricotz> didrocks, is using "www-browser" or "gnome-www-browser" better?
[13:49] <ricotz> jbicha, I see
[13:49] <jbicha> I think poppler 22.01 had most of the big changes (but we didn't package that version)
[13:51] <didrocks> ricotz: isn’t firefox-esr a snap now and we don’t have a deb package in jammy? (I might be wrong)
[13:51] <didrocks> oSoMoN: ^
[13:51] <ricotz> jbicha, ok, no need for no-change rebuild of libreoffice, given the entangled transitions
[13:51] <oSoMoN> didrocks, firefox-esr isn't a thing in Ubuntu, only in Debian
[13:52] <ricotz> didrocks, it is a Debian package and for a Ubuntu a PPA package
[13:52] <jbicha> right, a libreoffice rebuild can wait until y'all are ready
[13:52] <oSoMoN> (sorry, I forgot about the PPA that provides it)
[13:52] <didrocks> ricotz: this is why the first alternative is then picked
[13:53] <didrocks> and so, it’s trying to pull epiphany-browser
[13:53] <didrocks> (it will be stuck and blocked in proposed due to that)
[13:54] <didrocks> oSoMoN: do we have anything providing www-browser in ubuntu-desktop right now?
[13:54] <ricotz> didrocks, ok, currently libreoffice won't go anywhere anyway due to python3.10
[13:55] <didrocks> ricotz: yeah, but we need to ack and keep the component mismatch list small, so better to get this fixed now (we have a long enough list of false positives…)
[13:56] <ricotz> didrocks, ok, thanks for pointing out, there will be a 7.3.1 RC1 release later this week
[13:57] <didrocks> ack
[13:57] <oSoMoN> didrocks, yes, https://paste.ubuntu.com/p/crz2xHBPBR/
[13:57] <ricotz> didrocks, so this upload will be Thursday or Friday
[13:58] <oSoMoN> didrocks, and gnome-www-browser is provided by firefox, epiphany-browser, chromium-browser
[13:59] <didrocks> ack, let’s switch to that then! thanks you both :)
[14:04] <jbicha> is gnome-www-browser provided by the snaps though?
[14:04] <RikMills> oSoMoN: is gnome-www-browser provide by the snap?
[14:04] <RikMills> ummm... SNAP
[14:04] <tseliot> popey, hey, maybe the kernel modules were not available yet when you did the upgrade.
[14:04] <jbicha> :)
[14:07] <oSoMoN> jbicha, RikMills: no, see https://forum.snapcraft.io/t/firefox-snap-cannot-be-set-as-default-browser/26636
[14:08] <oSoMoN> but when the firefox deb package becomes transitional and installs the snap, we can make sure the alternative pointing to the wrapper that invokes the snap is installed
[14:08] <RikMills> oSoMoN: so we don't want gnome-www-browser as a recommends at the moment either
[14:09] <oSoMoN> that would result in the firefox deb being installed, so I guess not, indeed
[14:09] <RikMills> yep
[14:09] <RikMills> as you say, when we have a transitional FF deb, it can
[14:12] <seb128> there is value to have the deb installed even once it's a snap installer
[14:13] <seb128> since we talked about providing the www-browser alternative cmd there, which we know some scripts rely on
[14:14] <jbicha> when are you planning to make the Firefox deb a transitional package?
[14:23] <seb128> oSoMoN, ^
[14:25] <oSoMoN> no firm date, but before feature freeze, which leaves about 2.5 weeks
[14:26] <RikMills> so libreoffice cannot recommend gnome-www-browser until then
[14:28] <ricotz> RikMills, recommending "www-browser" should be sufficient and is covered by konqueror too
[14:29] <RikMills> ricotz: I don't want konqueror pulled in either!
[14:29] <RikMills> I want the Firefox snap in Kubuntu, as I have now
[14:29] <ricotz> ah I see
[14:30] <RikMills> and no other browser trying to take over
[14:30] <ricotz> but "www-browser" would work for you?
[14:32] <RikMills> ricotz: it it would pull in the firefox, konqueror, or epithany deb until firefoxfox becomes a transition to the snap, then no it would not work
[16:09] <seb128> jbicha, the n-m autopkgtest, I had a glance earlier and it seems wpa_supplicant isn't getting installed, maybe a depends changed?
[19:24] <jbicha> ooh, a cdbs package, I haven't touched one of those in a while
[23:09] <ItzSwirlz> Hey desktop team. Two things
[23:09] <ItzSwirlz> 1) I want to report that the Ubuntu Pro promotions a) imo in my opinion should not be sent to Ubuntu desktop users and more importantly b) The Ubuntu Pro notification showed up on Ubuntu Cinnamon Remix 22.04
[23:10] <ItzSwirlz> *which is unneccesary since Ubuntu Pro doesn't support flavors right?*
[23:11] <ItzSwirlz> 2) https://discourse.ubuntu.com/t/ubuntu-welcome-application-concept/26555
[23:24] <lord_daemon> Goodnight. does anyone use termux + ubuntu + openvpn
[23:26] <sarnold> neither of these channels is for user support, try #ubuntu


[16:50] <coreycb> hello, if there's an archive admin still around, could python-os-win please be promoted to main?
[17:05] <infinity> coreycb: Maaaaybe.
[17:06] <coreycb> infinity, someone's here! :)
[17:07] <infinity> coreycb: iz done.
[17:07] <coreycb> infinity, thanks
[21:33] <cyphermox> could someone please promote mokutil? It's depended on by shim-signed
[21:59] <cjwatson> cyphermox: done
[22:00] <cyphermox> ta
[23:29] <cyphermox> cjwatson: how do you usually deal with the trailing broken stuff in a Perl transition? try to debug yourself or file bugs? removals?
[23:29] <cyphermox> from what I can gather looking at some of them there aren't any patches anywhere
[23:30] <cyphermox> libembperl-perl looks easy enough, and I think I have a grasp of what is going on with libdata-dump-streamer-perl
[23:51] <cjwatson> cyphermox: some combination of those, though only very rarely removals; may be worth coordinating with the Debian Perl team, they're generally pretty clued


[00:00] -BottyMcBotFace:#ubuntu-news- ::Planet:: The Fridge: Ubuntu Weekly Newsletter Issue 628 @ http://fridge.ubuntu.com/2020/04/27/ubuntu-weekly-newsletter-issue-628/
[01:06] -BottyMcBotFace:#ubuntu-news- ::OMG!Ubuntu:: Ubuntu 20.04 is Now Available from the Microsoft Store @ https://www.omgubuntu.co.uk/?p=175356 (by Joey Sneddon)
[02:30] -BottyMcBotFace:#ubuntu-news- ::Fridge:: Ubuntu Weekly Newsletter Issue 628 @ http://fridge.ubuntu.com/2020/04/27/ubuntu-weekly-newsletter-issue-628/ (by guiverc)
[06:52] -BottyMcBotFace:#ubuntu-news- ::Planet:: Andrea Corbellini: How to use the same DNS for all connections in Ubuntu (and other network privacy ... @ https://andrea.corbellini.name/2020/04/28/ubuntu-global-dns/
[15:57] -BottyMcBotFace:#ubuntu-news- ::OMG!Ubuntu:: Fedora 32 Released, Now Available to Download @ https://www.omgubuntu.co.uk/?p=175543 (by Joey Sneddon)
[19:24] -BottyMcBotFace:#ubuntu-news- ::Softpedia:: Ubuntu 20.04 Looking Like macOS Highlights the Linux Customization Power @ https://news.softpedia.com/news/ubuntu-20-04-looking-like-macos-highlights-the-linux-customization-power-529831.shtml (by Bogdan Popa, Microsoft News Editor)
[19:59] -BottyMcBotFace:#ubuntu-news- ::Softpedia:: LibreOffice 7.0 Will Finally Remove Adobe Flash Player Support @ https://news.softpedia.com/news/libreoffice-7-0-will-finally-remove-adobe-flash-player-support-529834.shtml (by Bogdan Popa, Microsoft News Editor)
[20:19] -BottyMcBotFace:#ubuntu-news- ::Softpedia:: Fedora 32 Officially Launched @ https://news.softpedia.com/news/fedora-32-officially-launched-529835.shtml (by Bogdan Popa, Microsoft News Editor)
[20:43] -BottyMcBotFace:#ubuntu-news- ::OMG!Ubuntu:: Regolith Linux 1.4 Released, Based on Ubuntu 20.04 LTS @ https://www.omgubuntu.co.uk/?p=175598 (by Joey Sneddon)
[21:59] -BottyMcBotFace:#ubuntu-news- ::Planet:: Josh Powers: Enhanced SSH 2FA in Ubuntu 20.04 LTS @ https://powersj.io/post/ubuntu-focal-enhanced-ssh/
[21:59] -BottyMcBotFace:#ubuntu-news- ::Planet:: Josh Powers: Updatable Ubuntu Server Live Installer @ https://powersj.io/post/ubuntu-focal-live-installer-update/
[22:31] -BottyMcBotFace:#ubuntu-news- ::OMG!Ubuntu:: BleachBit, the Open Source System Cleaner, Sees New Release @ https://www.omgubuntu.co.uk/?p=175542 (by Joey Sneddon)


[00:00] <ayan> i see.  i'm trying to map git concepts onto bzr.
[00:02] <ayan> how do i copy a repository with all of the associated history a la ``git clone''?
[00:02] <dash> ayan: i'd use tar, probably
[00:03] <dash> ayan: but usually, it's not necessary
[00:03] <dash> ayan: just use 'bzr clone' to get the branch you want
[00:03] <ayan> okay, thanks.  off to rtfm harder. :)
[00:21] <poolie> hi jelmer, all
[01:01] <spiv> Good morning.
[01:21] <mangojambo> Hi, I need a help here with osx bazaar: I'm  running bazaar explorer and I'm getting the follow error when I try to open Settings > Configuration > User Configuration :
[01:21] <mangojambo> QKqueueFileSystemWatcherEngine::addPaths: open: No such file or directory
[01:21] <mangojambo> QFileSystemWatcher: failed to add paths: /Users/mj/.bazaar/bazaar.conf
[01:21] <mangojambo> Please, how can I fix it?
[01:25] <maxb> Does /Users/mj/.bazaar/bazaar.conf exist?
[01:27] <mangojambo> maxb: no. But I creat a file ( touch ~/.bazaar/bazaar.conf) and the error stops, but nothing happens
[01:40] <maxb> mangojambo: Ok, that sounds fairly likely
[01:41] <maxb> This means that the "errors" you posted are not errors, but just informational notes, and the real problem is something else
[01:43] <mangojambo> so, how can I fix it, or just access user configuration to set my user, email, etc ?
[01:46] <maxb> I'm afraid I don't know enough about qbzr to suggest what the problem might be
[01:56] <mangojambo> maxb: ok, thanks man. I will keep trying here.
[01:56] <mangojambo> seeya
[02:06] <poolie_> hi spiv
[02:06] <poolie_> apparently search on the bzr web site is broken so i'm going to try to fix that now
[02:06] <poolie_> then do something about stale locks
[02:06] <poolie_> i hope you got back eventually
[02:07] <poolie_> and apparently i'm the pilot
[02:07] <spiv> Yes, I did get back eventually!  Very back row of the plane, but that arrives very shortly after the front so it was ok ;)
[02:07] <poolie_> :)
[02:08] <poolie_> slower exit, but greater survivability
[02:08] <spiv> Plus I got to watch the rest of the neverending press conference.
[02:08] <poolie_> everyone can have 30 minutes of fame if they ramble enough
[02:08] <spiv> And the gradually increasing groans and eyerolls from the people watching it waiting for the result.
[02:09] <spiv> The mood towards rambling could be summarised as: "don't they know some people have planes to catch?"
[02:09] <spm> hahah
[02:10] <spiv> As soon as the key bit arrived the suddenly 2/3rds of the people hanging around disappeared, or at least it felt like that.
[02:18] <jam> spiv: do you know why spawnProcess seems to return a 'Process' object that doesn't claim to implement IProcessTransport (though spawnProcess claims to return that type?)
[02:19] <spiv> jam: sounds like a bug (in either docs or implementation...)
[02:19] <spiv> jam: on windwos?
[02:19] <jam> spiv: PosixReactorBase
[02:20] <jam> spiv: twisted/internet/interfaces.py says thait IReactorProcess returns IProcessTransport
[02:20] <spiv> So the default reactor (select)?
[02:20] <jam> PosixReactorBase returns internet.process.Process directly
[02:21] <jam> spiv: I don't really know, but IOCPReactor does the same thing
[02:21] <jam> spiv: I'm trying to replace a spawnProcess call with my own stuff, but the details are a bit.. hazy
[02:21] <spiv> Well, Process is supposed to implement that IIRC
[02:21] <spiv> Certainly twisted.internet._dumbwin32proc.Process does
[02:22] <jam> spiv: well, I can't find it saying "implements()"
[02:22] <poolie> hello jam
[02:22] <jam> spiv: right, that is the only thing that *does* implement it
[02:22] <jam> hi poolie
[02:22]  * jam is digging into twisted internals right now
[02:22] <spiv> jam: please file a bug
[02:22] <jam> which isn't a whole lot of fun, but doesn't seem too bad
[02:22] <spiv> jam: I think it's just missing the implements declaration
[02:22] <jam> spiv: so my concern is whether implementing the minimal IProcessTransport will be enough
[02:23] <spiv> jam: AFAICS it does actually satisfy that contract
[02:23] <jam> spiv: Process probably does
[02:23] <poolie> jam, is this because the reviewers really wanted twisted rather than otherwise?
[02:23] <jam> *I* don't know if I need to implement more
[02:23] <poolie> or because you need to fix the conch server?
[02:23] <jam> poolie: the ssh daemon is a Twisted process
[02:23] <jam> poolie: right
[02:24] <jam> I need to connect up the ssh incoming with the spawned process
[02:24] <jam> IProcessTransport is pretty minimal, so it shouldn't be too bad
[02:24] <jam> the concern is that it also seems intermingled with IProcessProtocol
[02:24] <jam> and that is a much larger api
[02:25] <jam> spiv: for example, I don't think spawnProcess calls transport.makeConnection(proto)
[02:25] <jam> though I'm still wrapping my head around everythingf
[02:25] <spiv> Process.__init__ does that
[02:25] <spiv> IIRC
[02:26] <jam> spiv: yeah, in a try/except: loop, no less
[02:26] <jam> (bare except)
[02:27] <jam> I didn't see it originally because __init__ is quite long
[02:27] <jam> I *did* see it in the win32 one, and was trying to reconcile that
[02:27] <spiv> (I wonder if it would be clearer if ProcessProtocol didn't implement IProtocol, and instead was explicitly adapted...)
[02:27] <jam> I'm thinking about inheriting from one of the classes in the Process stack, to get some of the file handle polling stuff
[02:28]  * jam doesn't really know what IProtocol is, or where Protocol is different from something else
[02:28] <jam> spiv: and the docstring for IProcessTransport is: A process transport.
[02:28] <spiv> I think if you are trying to inherit from Process for anything other than implementing a new reactor you're probably not gelling with Twisted well.
[02:28] <jam> which is *mighty* helpful
[02:28] <spiv> Well, it's the transport for a process! :)
[02:29] <jam> Very true
[02:29] <spiv> IProtocol is very slim, take a look at it.
[02:29] <jam> spiv: so I'm spawning a process outside of the current process and connecting to it
[02:30] <jam> which is ~ a subclass of Process
[02:30] <jam> I have pipes to read / write to
[02:30] <jam> I have a PID
[02:30] <jam> etc
[02:30] <jam> it is a good fit for IProcessTransport
[02:30] <spiv> Just thinking of network services for a moment, Twisted has "protocols" and "transports": a transport is something like TCP or SSL (or a pipe...) that can convey a bytestream.  A protocol is something that can receive a byte stream.
[02:30] <jam> I also have to manage talking on several file descriptors, etc, which Process already implements
[02:30] <spiv> (and decode it into HTTP request objects or whatever the protocol is)
[02:30] <jam> I just don't want to call _fork
[02:31] <jam> I might inherit from BaseProcess, or _BaseProcess (which inherits from BaseProcess oddly enough...)
[02:31] <spiv> A IProcessTransport is a transport with some extra features like pid and the ability to send signals.
[02:32] <jam> spiv, poolie: Do you know if waiting for a pid that isn't a child just raises an error?
[02:32] <jam> (I can test it, but I figured I could ask first)
[02:34] <spiv> jam: that sounds like a reasonable fit for IProcessTransport too
[02:34] <spiv> s/that/I think that/
[02:35] <jam> spiv: I don't know how to submit bugs to twisted, and probably have to log in
[02:35] <jam> any chance you could submit one for me?
[02:35] <jam> Just a simple "internet.process.Process' does not implement IProcessTransport
[02:35] <jam> (though it is returned by spawnProcess, which claims to return one of those)
[02:35] <spiv> You do need to log in, it's a Trac instance: twistedmatrix.com/trac
[02:36] <jam> spiv: yeah, I know where it is, but have no user, and it isn't really worth signing up for a 2 line bug report :)
[02:36] <spiv> Ok, but if you're poking at Conch I can almost guarantee you'll have more bugs to file before you're done ;)
[02:36] <jam> spiv: well, I'm certainly trying to avoid poking at any twisted internals :)
[02:39] <mkanat> Why does it seem like committing to a remote bound branch is so much slower than committing locally and then pushing?
[02:39] <jam> mkanat: it is possible, time it and check
[02:39] <jam> it pretty much does exactly that internally
[02:39] <jam> but it is possible there is a different code path
[02:40] <poolie> mkanat: because we're compressing the things to store relative to things stored remotely, maybe?
[02:40] <jam> poolie: we write it locally, then push, then update the branch pointer
[02:40] <mkanat> poolie: That could be. It could also have to do with taking a lock on the remote repo, or something.
[02:40] <poolie> mkanat: also, if there's a difference, getting a -Dhpss log should make it obvious why
[02:40] <mkanat> poolie: Okay.
[02:40] <jam> and/or --lsprof-file foo.callgrind
[02:40] <jam> anyway, back to family time
[02:41] <poolie> jam i'll try to catch you tomorrow afternoon your time
[02:43] <spiv> jam: http://twistedmatrix.com/trac/ticket/4648
[02:58] <poolie> i think i'll delete the rendered html from the website branch
[02:59] <poolie> now we can generate it on the server it just seems to be noise
[03:06] <mkanat> poolie: Yeah, and probably confusing to anybody who checks it out, if by some chance it ever wasn't up to date with the source.
[03:06] <mkanat> We used to store compiled docs along with Bugzilla; we removed them many years ago. It was a good idea. :-)
[03:12] <poolie> ok, and i think site search is working again, can someone test it?
[03:49] <anteru> Hi, is anyone working on the Website?
[03:49] <poolie> i am
[03:49] <poolie> is it broken?
[03:49] <anteru> If so, are there specific requirements for it? I'm playing around with a new layout which moves bzr slightly closer to what git and hg have on their front-page.
[03:50] <poolie> ok
[03:50] <poolie> i think it could certainly be improved and clarified
[03:50] <poolie> do you mean a requirements doc, or technical requirements?
[03:50] <anteru> I.e. a prominent download link fed from Launchpad directly, and two boxes for quick start
[03:50] <poolie> the source is in lp:bzr-website
[03:50] <poolie> that would be gerat
[03:51] <anteru> poolie: Requirements as in what _has_ to be on it, and technical as in lib x must be used
[03:51] <anteru> I don't know if there is some requirement from canonical for instance
[03:51] <poolie> nup, both are negotiable
[03:51] <poolie> whatever makes sense
[03:51] <anteru> Ok
[03:51] <anteru> I assume it should work with Python 2.x?
[03:52] <poolie> yes
[03:52] <poolie> any dependencies for generation should ideally be packaged in ubuntu
[03:52] <poolie> but we can work that out o
[03:52] <anteru> All right, I'll keep on hacking then. As soon as I have some mockup done, I'll be back, but it might take some while.
[03:52] <poolie> also, i think it's nice to keep the current approach of static generation, if possible
[03:52] <poolie> that would be great
[03:52] <poolie> you could post some screenshots or urls to the list, or here
[03:53] <anteru> Sure, as soon as I'm happy with it :)
[03:53] <anteru> I just wanted to check if someone else already works on a redesign for the front-page.
[03:55] <jbowtie> Please send them to the list, I wanted to tweak the Sphinx template for the documentation to feel more integrated with the website.
[03:55] <poolie> that would be great too
[03:55] <poolie> also to make the wp blog consistent with the site
[03:55] <poolie> anteru: you can look at the canonical design standards for inspiration
[03:56] <poolie> which are probably linked from wiki.ubuntu.com
[03:56] <anteru> uh oh folks :) one at a time, maybe (:
[03:56] <poolie> but we don't have to stick to them
[03:57] <jbowtie> anteru: I'm putting my hand up to work on the Sphinx template, I just want to see what you're thinking so I head in the same direction. ;)
[03:57] <anteru> actually, I wanted to do some clean-slate CSS3 and modern web design stuff, and as the bazaar frontpage is only a single page, I thought this is a good victim. Especially as it has some problems right now (tiny fonts, too many links, difficult to navigate, outdated content.)
[03:58] <anteru> give me a minute, and I can show you the current hacky state, basically blocking out the layout/content
[04:04] <anteru> quick: screenshot tool for kubuntu?
[04:04] <anteru> got it
[04:05] <anteru> http://img13.imageshack.us/img13/2373/bildschirmfoto1vt.png
[04:07] <anteru> danger: ugly and work-in-progress
[04:07] <anteru> anything which looks remotely fancy is CSS3 shadow/rounded-borders/etc. so the amount of images is kept to a minimum and it should degrade gracefully
[04:13] <jbowtie> You're right about ugly.  :)
[04:14] <anteru> it's work in progress
[04:15] <jbowtie> I know, I was kidding, you should see my early designs. Actually better if you don't.
[04:16] <jbowtie> First impressions: better (already) than the existing site. somewhat text-heavy for a front page. shell scripts might scare off those looking for bzr explorer.
[04:16] <anteru> with some more context: http://img84.imageshack.us/img84/6872/bildschirmfoto2q.png
[04:17] <anteru> well, that's why I want to keep the image at the top, then the explanation, then I'll probably add a small breaker with projects currently using it, and then the shell scripts
[04:18] <anteru> it also needs a bit stronger colours IMAO
[04:19] <anteru> but the yellow logo means it will basically only go well with blue, or some orange-looking stuff
[04:20] <jbowtie> I'd lose those borders, makes it too blocky.
[04:20] <anteru> ok. I'm keeping them for now, as it eases layout a bit
[04:21] <jbowtie> If you make them a light grey you can still see your layout but get a better feel for what it looks like with just whitespace.
[04:22] <jbowtie> I'm thinking it would be nice to show both the command line and a close-up of the gui interface. Play to both audiences.
[04:22] <anteru> also need to move it into some grid, right now it's completely ad-hoc
[04:23] <jbowtie> Maybe those quick-start blocks could link through to more detailed instructions (in the gui case with step-by-step screenshots)
[04:24] <jbowtie> I think you could try recoloring the logo (and making it smaller). Or maybe we can come up with a better one.
[04:24] <anteru> hm, one possibility would be to have a jquery powered slide-show basically, showing you both step by step
[04:24] <anteru> I.e. you just click and you see a "focus" screenshot on the left and the corresponding shell instructions on the right
[04:25] <jbowtie> Worth experimenting with, might not work on the front page though with everything else that needs to be communicated.
[04:26] <anteru> but first things first, but current todo is to get a proper grid in place first, then get all the content onto the page, then fix colors, then do some real layout, and then get back to discussion
[04:26] <anteru> args, I need to learn to type :/
[04:27] <jbowtie> No worries, I'm supposed to be working anyway. Send it to the mailing list when ready, I don't spend a lot of time on IRC.
[04:27] <anteru> just for reference, my own website has lots of whitespace: anteru.net :P
[04:28] <anteru> Yeah, I actually have to do some graphics stuff as well ... but still good to get some early opinions.
[04:29] <anteru> graphics == opengl code, not the painting style
[04:32]  * anteru goes lurking again
[04:55] <JoshBrown> Where do I file a bug about launchpad documentation?
[05:11] <twb> I get a backtrace trying to branch a repository over bzr+ssh, with 2.2.0 on my end and 1.3.1 on their end.
[05:12] <twb> Is that expected?  Should I fall back to sftp: ?
[05:13] <JoshBrown> What does the backtrace say?
[05:13] <twb> Sorry, one moment
[05:13] <twb> http://paste.debian.net/88489/
[05:13] <twb> (I got distracted in another channel.)
[05:15] <twb> OK, and sftp fails with "EOF during negotiation"
[05:16] <twb> Note: I know that repo exists (I can see .bzr and such with ls -a on the far end), but I don't know if it's the repo I want, nor if bzr is actually working on the far end.
[05:16] <JoshBrown> twb: That suggests that is may be a more generic error
[05:16] <twb> bare ssh IS working
[05:16] <twb> Oh, maybe it's because these fucktards block ICMP, so MTU negotiation doesn't happen.
[05:16] <twb> Let me try dialing the MTU down to 1450 or so.
[05:17] <mkanat> twb: 1.3.0 is really old.
[05:18] <twb> mkanat: I'm not going to upgrade random stuff on a customer's production server.
[05:18] <mkanat> twb: That's certainly your prerogative.
[05:19] <twb> Thank you for understanding that :-)
[05:20] <JoshBrown> twb: He has a point, why can't you upgrade it?
[05:20] <twb> Because upgrading software, particularly out-of-band, tends to introduce bugs as well as features.
[05:21] <twb> Unless I *really truly NEED* a feature, I'm not going to go out of my way to upgrade things.
[05:23] <mkanat> twb: If you're using just ssh:// or sftp:// then you're not interacting with the bzr on the server at all.
[05:23] <mkanat> twb: So that would be something protocol related.
[05:23] <twb> Right; which is why I suspect MTU
[05:23] <mkanat> twb: Could be.
[05:24] <mkanat> twb: Are you on some network where MTU auto-negotiation actually happens?  So it would be odd for the server to have specified an MTU below the standard then, right?
[05:25] <twb> mkanat: it's a pptp vpn, unfortunately
[05:26] <mkanat> twb: Ohh.
[05:26] <mkanat> twb: So you might be hitting the problem before you even really get into their network.
[05:26] <mkanat> twb: But in that case, bzr+ssh wouldn't have worked at all, right?
[05:26] <twb> Why not?  ssh works over the VPN
[05:26] <mkanat> twb: If there was an MTU problem, I mean.
[05:27] <twb> IIRC MTU problems manifest only when you start shoving nontrivial data
[05:27] <twb> e.g. ssh works until you run "ls"
[05:27] <mkanat> twb: That could be.
[05:27] <mkanat> twb: You'd have to send a packet larger than the MTU, I suppose.
[05:27] <twb> FWIW, with an mtu of 1446 I still see the symptoms described above for sftp: and bzr+ssh:
[05:28] <twb> Right.
[05:28] <twb> (Larger than *their* MTU,  that is)
[05:28] <mkanat> Right.
[05:28] <mkanat> twb: Can you normally "ssh" or "sftp" to the server?
[05:31] <twb> Yeah
[05:32] <twb> My bzr URI syntax is right, right?
[05:32] <twb> I always fuck it up when using hg
[05:33] <twb> Ugh ugh ugh
[05:33] <twb> ssh works, sftp doesn't
[05:34] <twb> AFAICT someone has installed an sshd_config on this host that's not compatible with the version they're actually running.
[05:34] <spiv> twb: ugh, that's a regression
[05:34] <twb> spiv: let me clarify
[05:34] <twb> sftp bwired-dvmh-mgmt-01.bulletproof.net ==> subsystem request failed on channel 0 \n Couldn't read packet: Connection reset by peer
[05:35] <twb> i.e. sftp fails outside of bzr
[05:35] <spiv> twb: the traceback for 2.2.0 against 1.3.0 is the regression I'm referring to
[05:35] <twb> Oh right
[05:35] <spiv> (Possibly would happen with 2.1 as well?)
[05:36] <twb> So it looks like I can't actually clone this repo, since the regression happens for 2.2.0 vs. 1.3.0 on bzr+ssh, and sftp isn't available (though ssh and scp ARE)
[05:37] <twb> Re. sftp, the problem is *definitely* ssh, *not* bzr
[05:37] <twb> Sep  8 14:33:18 bwired-dvmh-mgmt-01 sshd[31333]: error: subsystem: cannot stat internal-sftp: No such file or directory
[05:38] <paul__> hi.  HELP!  rebase has stuffed my working branch in a very bad way,
[05:38] <paul__> https://bugs.launchpad.net/bzr-rewrite/+bug/632894
[05:39] <paul__> i've reported the bug, but now i need to fix the problem in a hurry
[05:39] <paul__> i assume the commits are still in the repo *somewhere*, how can i find and pull them?
[05:39] <mkanat> twb: Glad at least that you've got it figured out now, though.
[05:40] <spiv> twb: I think I can give you a workaround, just a sec
[05:40] <paul__> eg, i know when i do bzr uncommit, it tells me a magic thing i can type in to retrieve that commit back
[05:40] <paul__> how do i get a list of those?
[05:41] <fullermd> paul__: There's a 'head' command in bzrtools that digs through the repo and tells you what head revs there are.
[05:41] <spiv> paul__: bzr heads --dead-only
[05:41] <spiv> paul__: you'll need the 'bzrtools' plugin if you don't already have it
[05:41] <fullermd> It should be a short enough list that you can make a good stab at which you want.
[05:42] <paul__> oh god, thanks, there it is
[05:42] <fullermd> So you should be able to 'pull --overwrite -rwhatever .` to restore it in-place (or fiddle around with making a new branch at that rev if you prefer)
[05:42] <fullermd> (don't miss the '.' in that command line)
[05:43] <paul__> i'll do a branch to check first
[05:43] <paul__> if this doesnt work my only remaining copy is in my editor
[05:43] <paul__> there are quite a few heads, more than i thought there would be
[05:44] <paul__> and theres more than one for this particular checkin!
[05:44] <paul__> same timestamp
[05:44] <paul__> i only checked it in once, then i did a rebase which stuffed things up
[05:46] <paul__> can someone please check that bug?  if its real, then it could be a very serious problem to a lot of projects
[05:46] <fullermd> Well, you can check both.  It may take some rooting, but it's there.
[05:46] <twb> spiv: thanks, please stick a "twb:" in front when you have it, so my notification system wakes me up
[05:47] <spiv> twb: will do, sorry something else has come up right at this second, but I will get back to you soon I hope.
[05:48] <twb> No rush; I'm just gonna scp -r it across and look at the repo; I don't need to patch it just yet
[05:49] <twb> Is there an equivalent of "bzr viz" that works on the terminal (like "hg glog")?
[05:52] <spiv> bzr log -n0, to an extent.
[05:53] <twb> I meant for the little DAG down the side
[05:54] <spiv> Not that I know of, but it'd be nice to have.
[05:54] <twb> Oh well.  I'll xinit /usr/bin/bzr viz
[06:18] <spiv> twb: bzr branch lp:~spiv/+junk/bzr_ssh_v2_hack ~/.bazaar/plugins/
[06:24] <twb> spiv: Branched 0 revision(s).
[06:24] <spiv> Oh, gar.
[06:24] <spiv> I'll fix that :)
[06:25] <spiv> twb: ok, pull now (or delete and rebranch)
[06:26] <twb> Still fails
[06:27] <spiv> Details?
[06:27] <twb> Sorry
[06:28] <twb> http://paste.debian.net/88495/
[06:28] <spiv> I don't see bzr_ssh_v2_hack in your list of plugins there.
[06:28] <twb> That's because you told it to dl to plugins/ itself
[06:29] <spiv> Oh!
[06:29] <spiv> Sorry, that was careless.
[06:29] <twb> OK, now I did something bad
[06:30] <twb> ImportError: No module named bzrlib
[06:30] <spiv> Huh.  pastebin the traceback (add -Derror to the command line if it doesn't emit one)
[06:31] <twb> And now that error is gone agan
[06:31] <twb> I have no idea what happened there
[06:32] <spiv> Weird!
[06:35] <twb> spiv: bzr+ssh works after that plugin is cloned into a subdir of ~/.bazaar/plugins/
[06:36] <spiv> twb: great!  I'll work on fixing the bug properly for 2.2.1/2.3
[06:37] <twb> Will that branch remain available?
[06:37] <twb> I'd like to mention it in my ticket system
[06:39] <spiv> twb: sure
[06:39] <twb> Thanks for the prompt response
[06:43] <spiv> You're welcome, I'm glad the workaround worked.
[07:34] <vila> hi all !
[07:53] <poolie> hi there vila
[07:53] <vila> poolie: hey !
[07:53] <vila> poolie: Can you clarify your comment on bug #323111 ? Oh, you already did
[07:53] <poolie> :)
[07:54] <vila> yeah, I had that policy thing in mind too, I'm about to write the tests and code for that.
[07:55] <vila> Blueskying, a registry could be used to decide that based on a... config variable maybe ;)
[07:55] <vila> but I think it will be overkill for a first submission
[07:56] <vila> and there are some interactions with junk files we may want to address first too (though that's a bit more invasive, currently my patch modify TreeTransform only)
[08:00] <twb> $ /usr/bin/time bzr log --help >/dev/null ==> 2.73user 0.08system 0:02.81elapsed 99%CPU (0avgtext+0avgdata 84320maxresident)k
[08:00] <twb> Why does bzr need three seconds in the CPU even to print the help text?
[08:01] <twb> On the same host, "hg log --help" takes less than half a second of CPU time
[08:01] <fullermd> 0.090u 0.030s 0:00.12 100.0%
[08:01] <vila> 0.11user 0.00system 0:00.11elapsed 97%CPU
[08:01] <twb> The host in question is running bzr 2.2.0 on Debian sid.
[08:02] <fullermd> I tend to suspect my system isn't REALLY 20x as fast as yours...
[08:02] <spiv> twb: try with --no-plugins; the hack I gave you would have the side-effect of forcing the import of a bunch of often unnecessary code.
[08:02] <twb> spiv: with --no-plugins it's still 1.2s user
[08:02] <spiv> (As might some of the other plugins you have installed, I haven't looked at e.g. etckeeper's impact on load times)
[08:03] <spiv> Ok, well that's half the problem at least ;)
[08:04] <twb> I have bzrtools and python-paramiko installed, but not bzr-{doc,gtk,svn}, python-kerberos, python-pycurl or xdg-utils installed (the packages bzr suggests).
[08:04] <spiv> twb: that is pretty slow, though!  It's 0.096s user on my laptop.
[08:05] <spiv> twb: perhaps somehow the .pyc files are missing or stale in your install?
[08:05] <twb> About the only thing I can think of is "byte-compile = optimize" in /etc/python/debian_configuration
[08:05] <twb> But I would *hope* that it's only byte-compiling files once
[08:06] <spiv> Hmm, possibly.
[08:06] <twb> And in any case, if it was a python problem it ought to break hg, too
[08:06] <spiv> Yeah, unless the packaging is quite different or something.
[08:07] <twb> Oh, and I'm on an SSD, so probably my read speeds are good and my write speeds are bad.
[08:07] <vila> or unless bzr triggers something hg doesn't but it still python related :)
[08:07] <vila> twb: check your install for the .pyc files, if they aren't there python have to generate them at each run
[08:07] <spiv> twb: try 'python -v /usr/bin/bzr rocks'
[08:08] <twb> http://paste.debian.net/88516/
[08:08] <spiv> twb: if it is importing from .py files rather than .pyc/.pyo, and/or emitting a bunch of "can't create", that'd be a problem
[08:09] <spiv> twb: yep, it is looking for and failing to load .pyc files.
[08:09] <twb> That's stupid :-/
[08:09] <twb> I shouldn't have to run bzr as root to get pycs
[08:09] <spiv> twb: ah, because /usr/bin/bzr has "#!/usr/bin/python", which won't look for .pyo
[08:09] <twb> Stupid debian
[08:10] <spiv> twb: if you have "#!/usr/bin/python -O" it would look for .py
[08:10] <spiv> Er,
[08:10] <spiv> twb: if you have "#!/usr/bin/python -O" it would look for .pyo
[08:10] <spiv> That extra char matters :)
[08:10] <spiv> twb: Perhaps you should set byte-compile = standard, optimize in /etc/python/debian_config ?
[08:11] <vila> spiv: ETOOCLOSE(pyo, typo)
[08:11] <spiv> (if that works)
[08:11] <spiv> vila: hah
[08:12] <twb> spiv: hum, I'll try that.
[08:12] <spiv> twb: arguably the bzr deb package could check that config and adjust the #! line accordingly, it might be good to file a bug about that.
[08:13] <twb> You'd think that part would be done in some magical way for *all* packages
[08:14] <spiv> Yeah, it seems like something that python-central ought to help with.
[08:14] <spiv> Maybe it does, and the bzr package just doesn't use it?
[08:14] <twb> Damned if I know
[08:14] <spiv> I'm no expert in packaging :)
[08:14] <spiv> Definitely this counts as a bug in the packaging, though.  That's a pretty unpleasant result :(
[08:15] <spiv> Setting a config var to optimize shouldn't make programs go 10x slower :(
[08:15] <vila> Hopefully it doesn't disable the C extensions...
[08:15] <spiv> vila: on that count at least we ought to be safe.
[08:16] <vila> Is it conceivable to set -O from a running python script without spawning a new interpreter ? ....
[08:17] <twb> OK, after changing that to standard, optimize, and dpkg-reconfigure bzr bzrtools, I get 0.6s or 0.4s without plugins
[08:17] <twb> And with python -O it's 0.056s for both
[08:18] <vila> twb: more in line with hg then ?
[08:18] <twb> Yeah, thanks
[08:19] <vila> twb: would you mind filing a bug for that ?
[08:19] <vila> urgh, a raw 'bzr' tracebacks
[08:22] <vila> hmm, bad wikkid
[08:23] <twb> vila: against what, though?
[08:23] <twb> Last time I looked, the debian maintainers basically said "don't change /etc/python/debian_config or we will ignore you"
[08:24] <vila> err, you lost me here, do you mean the bug is triggered because you modify /etc/python/debian_config; ?
[08:25] <twb> vila: yes, I think so
[08:25] <twb> IIUC I accidentally said "make .pyo but not .pyc" when I should've said "make .pyo AND .pyc"
[08:25] <spiv> Right.
[08:25] <twb> And a more or less separate bug is that python programs in Debian ignore .pyo files
[08:26] <vila> twb: then file it at https://bugs.launchpad.net/bzr/+filebug and we'll see from there
[08:27] <vila> twb: I don't have such a setup but hopefully someone will be able to reproduce
[08:27] <vila> twb: and if nothing else, it will document your workaround
[08:27] <spiv> vila: it's a packaging issue, really, filing it against Debian is probably more appropriate
[08:28] <twb> spiv: so anyway, what I'm gonna do now is sudo sed -i '1s/^#!.*python$/& -O/' /usr/bin/* ;-)
[08:28] <vila> spiv: unless it's immediately triaged as WontFix as twb hinted
[08:29] <bialix> heya
[08:29] <spiv> twb: *shudder* :)
[08:29] <twb> Well, if it increases bzr's speed tenfold, it'll probably increase other stuff
[08:29]  * bialix waves hello at GaryvdM
[08:29] <GaryvdM> Hi bialix
[08:30] <vila> twb: I won't bet the increase will apply to every command...
[08:30] <bialix> thank you for new installer
[08:30] <spiv> twb: well, I'd expect optimised bytecode to have minimal impact on bzr over unoptimised.
[08:30] <GaryvdM> bialix: Does it fix the bug? Did not seam to work for me.
[08:31] <bialix> bug with russian characters? yes!!!
[08:31] <twb> spiv: it was 0.6 vs. 0.05
[08:31] <twb> spiv: for --help, anyway
[08:31] <spiv> twb: Strange.  I don't see that here.  I see basically no difference.
[08:32] <bialix> GaryvdM: I suspect you should test with accented characters instead of russian ones for your system
[08:32] <twb> spiv: did you make .pyo's for all your libraries and stuff?
[08:32] <spiv> twb: to be clear, I mean where the bytecode is precached for both cases (i.e. with .pyc and .pyo files)
[08:32] <spiv> twb: right
[08:33] <bialix> GaryvdM: I'm going to test PyQt 4.5.2 which I have in my archives re bug with frozen child window
[08:33] <GaryvdM> bialix: ok
[08:33] <bialix> GaryvdM: is there specific reasons for us to use the latest PyQt?
[08:33] <bialix> at least on windows
[08:33] <spiv> twb: forcing Python to recompile the bytecode every invocation is certainly going to hurt a lot, but at least for bzr the practical benefit of the -O optimisations should be negligible
[08:33] <twb> OK, I remeasured it and I can't see the difference anymore
[08:33] <twb> (pyo vs pyc)
[08:34] <spiv> -O is very, very mild in what it does.
[08:34] <GaryvdM> bialix: I was hoping to be able some new features. Does 4.5.2 support QVarent.toPyObject
[08:34] <spiv> There's also -OO, which possibly would help bzr a little bit if only by reducing the size of the bytecode to load by omitting most docstrings.
[08:34] <bialix> GaryvdM: I dunno
[08:35] <GaryvdM> *to be able to *use* some new features
[08:35] <bialix> yep, I understood
[08:35] <spiv> It's a nasty trap to have /etc/python/debian_config contain such an attractive option that actually means "please break me" :(
[08:39] <fullermd> Eh, it's just like a lava pit in Quake.  Just there to see if you're paying attention.
[08:39] <bialix> GaryvdM: about new features: IIRC we discussed this at UDS and decided to not break backward compatibility in 0.19; and 0.19 is our bzr 2.2 companion, right?
[08:39] <GaryvdM> bialix: Yes
[08:40] <bialix> I don't mind to change required PyQt for 0.20
[08:42] <bialix> GaryvdM: 4.5.2 works ok
[08:43]  * bialix re-testing with 4.7.2
[08:45]  * bialix wants qabout dialog as in Explorer to easily see the versions of used PyQt/Qt
[08:48] <bialix> GaryvdM: 4.7.2 is buggy.
[08:48] <bialix> GaryvdM: can we downgrade to 4.5.2? please? pretty pretty please?
[08:50] <GaryvdM> bialix: Ok - I'm busy building my own build host. If I get that to work, I'll do that. Else we are going to have to ask jam to do it for us.
[08:51] <GaryvdM> bialix: Please will you put the 4.5.2 installer somewhere I can download it.
[08:51] <bialix> bialix.com will be OK for you?
[08:52] <GaryvdM> That's cool
[08:53]  * bialix is uploading, installer is 17MB big
[08:59] <vila> GaryvdM: Can I ask you to document every single step so anybody can reproduce ?
[09:00] <GaryvdM> vila: I'm following jam document
[09:00] <vila> GaryvdM: then update and complete ;)
[09:00] <GaryvdM> bzr.dev/doc/developers/win32_build_setup.txt
[09:01] <bialix> oh, that will be awesome
[09:01] <GaryvdM> vila: sure. I've chosen to use msys rather than cygwin
[09:01] <vila> GaryvdM: great, any chance you're doing that in a fresh VM ?
[09:01] <GaryvdM> vila: So if that works, I'll note that.
[09:01] <bialix> GaryvdM: http://bialix.com/python/PyQt-Py2.6-gpl-4.5.2-1.exe + http://bialix.com/python/PyQt-Py2.6-gpl-4.5.2-1.exe.asc (gpg signature)
[09:01] <GaryvdM> vila: I am
[09:02] <GaryvdM> bialix: Thanks
[09:02] <bialix> when I will have a free week or so, I will try to re-create my build environment without cygwin/msys. Heh
[09:02] <vila> GaryvdM: Woohoo ! Make copies ! Argh, no, windows licenses :-(
[09:03] <vila> GaryvdM: anyway, make copies for you so you can restart from a clean state if needed
[09:03]  * bialix is trying PyQt 4.7.6 now
[09:04] <bialix> riverbank guys even don't have RSS for their news %( in which age they're living?
[09:07] <bialix> 4.7.6 -> nope, the same
[09:15]  * bialix bbl
[09:33] <fullermd> Still no bzrtools for 2.2?   :(
[09:38] <poolie> fullermd: does anything fail or does it just need a release?
[09:39] <fullermd> I'm not aware of anything failing, which doesn't mean much since I don't use much of anything from it.
[09:40] <fullermd> Though I'd offhand assume enough people use both stuff from it and have upgraded to 2.2 by now that we'd have heard about any major breakages.
[09:58] <maxb> erm, huh. If there's no bzrtools for 2.2, how do we have one in the PPA?
[09:59] <Ddorda> hey guys, how do i clean modifications i did on a branch?
[09:59] <Ddorda> i mean locally changes
[09:59] <maxb> fullermd: It's been tagged, apparently
[09:59] <maxb> Ddorda: bzr revert
[10:00] <Ddorda> maxb: awesome thanks
[10:28] <MacSlow> Greetings
[10:29] <MacSlow> Can someone tell me what happended to olive (of bzr-gtk)?
[10:29] <MacSlow> it doesn't seem to be installed with it anymore.
[10:31] <vila> MacSlow: is has been split off bzr-gtk
[10:31] <MacSlow> so there's no more stand-alone way to start it?
[10:31] <MacSlow> only bzr visualise?
[10:32] <vila> MacSlow: it's now at lp:olive
[10:32] <MacSlow> vila, ok thanks
[10:32] <vila> MacSlow: much of the activity around stand-alone GUI for bzr is around lp:bzr-explorer
[10:33] <vila> MacSlow: which use qbzr mainly (even if on eof its early goals was to remain toolkit agnostic so in theory it could also use a bzr-gtk back-end)
[10:34] <vila> s/on eof/one of/ funny typo
[11:42] <maxb> abentley: Hi, will you be releasing a bzrtools 2.2.0 tarball?
[12:48] <mangojambo> Hi, where do I report a small bug ?
[14:43] <mgz> bug 633180 is funny.
[15:18] <git__> hi
[15:19] <git__> how well does bzr do with image versioning?
[18:14] <nDuff> I vaguely recall y'all having some shiny, shiny toolage analyzing Bazaar's performance over time (and isolating specific changesets where performance regressions occurred). Not having much luck googling it, though -- is that all in my head?
[18:26] <jml> nDuff, bzr-usertest
[18:30] <nDuff> jml, ahh -- thanks!
[21:22] <ddaa> I noticed that bzr-git does not support push
[21:22] <ddaa> but a look at the code suggests that it does support commit-to-git with roundtripping.
[21:23] <ddaa> Meaning, a commit done directly on checkout based on a git foreign branch will store all the good metadata, but that feature is missing from push.
[21:24] <jelmer> ddaa: it supports push, too
[21:24] <ddaa> I am wondering, maybe "rebase" or "replay" can be used to produce essentially the same effect as push.
[21:24] <jelmer> ddaa: Just that roundtripping is still disabled at the moment.
[21:25] <ddaa> jelmer: obviously, it supports dpush
[21:25] <ddaa> what do you mean "the roundtripping is disabled"?
[21:25] <jelmer> ddaa: I'd like to make sure that we have a stable format before enabling roundtripping.
[21:25] <jelmer> ddaa: There are two mapping formats - 'v1' which doesn't support roundtripping and 'experimental', which does. v1 is the default.
[21:26] <ddaa> Oh.
[21:26] <ddaa> Any idea when experimental will become v2 and v2 becomes the default?
[21:28] <jelmer> when I finish my work to make the bzrlib testsuite run against foreign formats
[21:28] <ddaa> So, if I understand correctly, commit on git foreign checkout currently does not work?
[21:29] <jelmer> ddaa: It's got some issues - for example it won't use what's in the working tree but what's in the index.
[21:29] <ddaa> Oh, that's interesting.
[21:29] <jelmer> ddaa: and I don't think it will use the revision id that's specified by the caller of WorkingTree.commit, if any.
[21:29] <ddaa> That's actually not what I meant though :-)
[21:30] <jelmer> ddaa: Sorry
[21:30] <ddaa> I meant commit on a bzr branch bound to a git branch, or commit to a bzr lightweight checkout of a git branch.
[21:30] <jelmer> ddaa: I doubt that commit on a git foreign checkout will work; on a non-bound branch it might.
[21:30] <ddaa> Gotcha.
[21:30] <jelmer> commit to a lightweight branch *might* work
[21:30] <jelmer> uhm, lightweight checkout
[21:31] <ddaa> Once roundtripping is enable, that will all magically work, right?
[21:31] <jelmer> in theory, yep
[21:31] <jelmer> there will probably be minor things to fix up
[21:38] <glyph> does the bot here pipe up about bzr-svn bugs as well?
[21:39] <glyph> well, assuming it doesn't
[21:39] <jelmer> glyph: I don't think it tells us about bzr bugs either :-)
[21:39] <glyph> https://bugs.launchpad.net/bzr-svn/+bug/633522
[21:39] <glyph> dash: you broke the internet :(
[21:40] <dash> glyph: oh noooo
[21:40]  * jelmer fires off a clone of calendarserver
[21:41] <glyph> jelmer: please be kind, use a shared repo :)
[21:41] <dash> glyph: what, you guys don't have a giant svn server farm over there?
[21:41] <dash> ;)
[21:41] <glyph> dash: uh yeah, "us guys", sure
[21:41] <glyph> I think you are closer to the "cloud" than me :-P
[21:42] <dash> true
[21:46] <glyph> I'm sure there are ... servers
[21:46] <glyph> I just don't want to get the bill for all of them because all 111 people in #bzr decide to clone it from scratch :)
[21:54] <jelmer> glyph: If only a bug report would immediately get the attention of 111 developers...
[21:59] <glyph> jelmer: if only!
[21:59] <glyph> thanks for looking at it
[21:59] <glyph> can you repro?
[22:03] <jelmer> glyph: nope
[22:03] <jelmer> glyph: The branch that you're working in, did it or its repo exist before you switched to bzr-svn 1.0.4 ?
[22:03] <glyph> jelmer: I guess it probably did.
[22:04] <glyph> If I locally clone into a new repo, will I work around it, or do I need to do a fresh clone from the server?
[22:04] <jelmer> glyph: I suspect one of the older versions of bzr-svn that you used probably introduced broken data
[22:04] <glyph> and do I need to blow away my svn cache
[22:04] <jelmer> glyph: A local clone will just copy the broken data, so you'd need a fresh one from the svn server.
[22:05] <jelmer> I don't think the cache would be affected but it's quite quick to regenerate so I would recommend blowing it away.
[22:05] <dash> glyph: a lot of times i've had odd issues with bzr-svn on 'pull' or 'up' that have gone away if i do a fresh pull from the svn server into a different branch, then in the afflicted branch do a pull from the fresh one
[22:06] <jelmer> dash: can you still reproduce that sort of thing with 1.0. 4?
[22:06] <dash> jelmer: i haven't yet, IIRC
[22:06] <dash> jelmer: if i do, i will let you know. :)
[22:06] <jelmer> dash: thanks
[22:08] <glyph> dash: OK, I'll try that first, I guess :)
[22:08] <glyph> sooo slow :(
[22:20] <mgz> hm, if I want to do a cosmetic edit to someone else's branch before merging it with hydrazine, is there a way? or would that have to be a whole new mp?
[22:22] <jelmer> mgz: I think that would have to be a whole new MP
[22:22] <mgz> argh, and bugger, I can't merge to 2.2
[22:22] <jelmer> at least, I can't think of a way around that..
[22:22]  * glyph discovers hydrazine and becomes excited
[22:22] <glyph> is there a bug-reporting GUI?
[22:24] <mgz> ...I struggle to envision how that would improve on a web browser
[22:24] <mgz> generally people want bug reporting clis
[22:25] <jelmer> glyph: I think bughugger is a GUI for bugs (among other things) on Launchpad
[22:26] <glyph> screenshots plz
[22:26] <jelmer> heh, I don't use it.. but I'm sure Google can help.
[22:26] <dash> http://www.murraytwins.com/blog/?p=60
[22:26] <dash> eeenteresting
[22:30] <glyph> jelmer: qannotate works on a fresh pull
[22:30] <glyph> erm, annotate, too ;)
[22:31] <jelmer> great (-:
[22:31] <glyph> pulling the fresh pull into my existing repo blows up with a different traceback though
[22:31] <jelmer> so that would've been a bug in an older version of bzr-svn that's since been fixed
[22:31] <glyph> I've saved the broken branch (branching it produces the same error) in case you're interested in me pushing it somewhere later
[22:31] <jelmer> glyph: yes, that's to be expected tas your existing repo has some broken data
[22:32] <glyph> gotta run now
[22:32] <jelmer> glyph: I would recommend cloning your existing branches into the new repo and getting rid of the old one
[22:32] <jelmer> I'm not really interested in the broken repo - the fact you've just successfully used annotate means this is an old bug.
[22:32] <jelmer> 'morning mwhudson
[22:32] <mwhudson> hi jelmer
[22:33] <mwhudson> jelmer: btw, is importing from a local git repo known to be broken in bzr-git currently?
[22:33] <jelmer> mwhudson: it was earlier, perhaps I forgot to push my fixes
[22:40] <mwhudson> jelmer: i think that might be the case
[22:40] <mwhudson> (i did this a couple of days ago, but i don't think i've seen any lp:bzr-git changes since)
[22:41] <jelmer> I'll check
[22:41] <jelmer> it reminds me...
[22:41] <jelmer> https://dev.launchpad.net/FailingBzrSvnImports, https://dev.launchpad.net/FailingBzrGitImports
[22:41] <jelmer> with much thanks to maxb
[22:42] <mwhudson> nice
[22:43] <mwhudson> 1.0.4 will be deployed tomorrow, right?
[22:43] <jelmer> yep
[22:43] <mwhudson> a few to retry then
[22:44] <mwhudson> https://dev.launchpad.net/FailingBzrGitImports#Nested%20trees is a bit uh, well....
[22:46] <ddaa> when 2.3 is out, someone will have the joy to update cscvs to deal with those too :-)
[22:46] <ddaa> Or maybe not...
[23:08] <mwhudson> ddaa: weeeeeeeeeeeeeeeeeeeeeeeeeeeeellllllllllllllllllllllllllll
[23:09] <ddaa> is that the sound of you falling in one?
[23:09] <jelmer> ddaa: nested trees in CVS? Do I want to know?
[23:09] <ddaa> module references
[23:10] <jelmer> aha
[23:10] <ddaa> historically, the policy was "just ignore those, only import the root module"
[23:10] <ddaa> conceptually, it's not very tricky
[23:11] <ddaa> I think svn externals are worse, with their ability to refer to branches in other repositories
[23:13] <mwhudson> ddaa: oh right
[23:13] <mwhudson> ddaa: well, actually the current policy is "just ignore those, only import the root module, then blow up doing the validation cross check at the end"
[23:14] <ddaa> oh right :-)
[23:14] <jelmer> ddaa: the main issue with svn externals is that they can create implicit directories
[23:15] <ddaa> I remember the motivation for not fixing this one was that anyway, cvs repos using those are essentially useless without the module references.
[23:15] <mwhudson> ddaa: it's CVS's fault really, if you do cvs co compound-module, the CVS/Root file (i think it's that one) only references the root module
[23:15] <ddaa> jelmer: that sounds like an instance of "I can't decide whether it's a branch or a directory"
[23:15] <mwhudson> "conceivably versions something" indeed
[23:16] <ddaa> mwhudson: right, I guess fixing that would have involved touching the graph magic lifeless put there once, and that I was never able to make sense of.
[23:18] <mwhudson> fortunately the day when one can just ignore cvs is getting closer
[23:18] <bialix> mgz: around?
[23:18] <mgz> yo bialix
[23:19] <bialix> yo martin
[23:19] <bialix> are you using hydrazine to send merge requests?
[23:19] <mgz> I am, want a tutorial?
[23:20] <ddaa> mwhudson: btw, I was a bit amused at noticing the import failure at ~vcs-imports/cvs/trunk
[23:21] <ddaa> also, lp REALLY needs a new icon for ~vcs-imports
[23:21]  * mwhudson hadn't seen that one
[23:21] <ddaa> not only my artwork sucks, but it does not make sense anymore
[23:21] <bialix> mgz: no, just a confirmation you're using it from windows machine and it's possible to install it for mere mortals
[23:22] <ddaa> it dates back to the time this was called ~buttress
[23:22] <bialix> lol
[23:22] <mgz> yup, about the only windows-hostile thing I've run into is the script you want to run doesn't have '.py' on the end
[23:22] <bialix> oh
[23:22] <bialix> then
[23:22] <mgz> launchpadlib does mean having to deal with setuptools, but that's a pain everywhere
[23:23] <bialix> [01:20]	<mgz>	I am, want a tutorial?  --- YES!!!
[23:23] <mgz> and there's 2.5ism in one of the many launchpadlib dependencies that I put a mp up to fix some months ago and have heard nothing about, so still have to patch locally
[23:25] <bialix> because you prefer py2.4, as I remember
[23:25] <bialix> that's ok
[23:25] <bialix> so, can I have a cookie, err, short tutorial how you install it?
[23:26]  * fullermd ships bialix a cookie.
[23:26] <bialix> *crunch* *crunch* yummy!
[23:31] <mgz> bialix: something like http://paste.ubuntu.com/490588/
[23:32] <mgz> and... I misplaced an apostrophe again
[23:32] <bialix> mgz: yummy, awesome, thanks!
[23:33] <mgz> yell if I got anything wrong there or you run into anything else, I might polish this up and post somewhere
[23:33]  * ddaa refrains from making a bad jokes involving poles and ukrainians
[23:34] <bialix> ddaa: :-P
[23:34] <bialix> I think I know this joke
[23:34] <ddaa> that would not be "spiritual" :-P
[23:34] <bialix> please, don't
[23:35] <ddaa> tell me about it!
[23:36] <bialix> in Ukraine we're usually telling jokes about unkrainians and russians
[23:40] <ddaa> next time you see sabdfl, ask him about that Baikonour launch operator he saw the day before he took off :-)
[23:41] <bialix> I'll note
[23:42] <bialix> at uds I was too shy to talk with him
[23:44] <ddaa> you're not alone there, but it's all in your head. He's remarkably level headed.
[23:44] <ddaa> Actually, I find that somewhat disturbing.
[23:45] <jelmer> n
[23:45] <jelmer> n
[23:46] <jelmer> grr, wrong window has focus
[23:50] <poolie> good morning
[23:58] <fullermd> jelmer: No, it's n w.
[23:59]  * bialix waves hello at poolie


[00:09] <mmercer> when using preseed to configure disks,  what is the d-i partman options for NOT using lvm
[00:12] <powersj> mmercer, I like to refer to this doc when trying to create a preseed https://www.debian.org/releases/wheezy/example-preseed.txt
[00:13] <powersj> You will see the options for disk methods e.g. regular, lvm, crypto
[13:28] <rbasak> cpaelzer: "You said you don't want me to parse those keys at all"
[13:29] <cpaelzer> yep
[13:29] <rbasak> No, I meant I didn't want you to parse a simplestreams filter/query string
[13:29] <cpaelzer> ok, but still as I outlined none of the local context data has the keys I'd need
[13:29] <rbasak> Since that syntax is not strictly defined and the simplestream library handles parsing, and I didn't want an additional parser
[13:29] <cpaelzer> help me navigate it and I happily drop the re.search
[13:29] <rbasak> I understand - I'll look into that
[16:53] <lord4163> There is no way to make netplan rename the an interface but not bring it up?
[18:59] <kierank> Would there be a reason the "live" 18.04 server installer has a kernel module that the "alternate" one does not?
[19:01] <sarnold> kierank: it wouldn't surprise me, noi
[19:02] <kierank> Is it possible to preseed with the live variant?
[19:02] <kierank> or failing that use the alternate one with the kernel from live?
[19:02] <sarnold> what problem are you seeing?
[19:03] <sarnold> I wouldn't be surprised if the live system booted up with an overlayfs or something similar in place
[19:03] <kierank> SD card on Intel NUC isn't detected by alternate, but is with live
[19:03] <kierank> so I can't install with alternate
[19:03] <sarnold> ew. I wonder why
[19:06] <kierank> though actually the reason we use preseed is to get raid 1 but with a nuc I can just image the SD card
[19:06] <kierank> so not the end of the world per se
[20:07] <TJ-> kierank: I think the alternate runs the debian-installer directly, from .udebs, so likely it'd need the udeb that contains the missing kernel module. what module is it?
[20:17] <kierank> TJ-: rtsx_pci sd/mmc
[20:18] <kierank> rtsx_pci_sdmmc*
[20:28] <TJ-> kierank: missing... the sdhci_pci is in block-modules but not that one
[20:34] <kierank> TJ-: what does "live" do differently?
[20:34] <TJ-> kierank: it has a the full kernel images the same as an installed system
[20:35] <TJ-> kierank: which include all those modules
[20:35] <kierank> Ok
[20:36] <TJ-> kierank: debian-installer (d-i) relies on .udeb packages (smaller less capable versions of .deb packages). Some kernel modules are included in themed .udeb packages. The block-modules udeb has the main block device modules but not that rtsx* group
[20:37] <kierank> Makes sense, I've never had to install on a storage device that goes via pcie before
[20:37] <TJ-> kierank: in theory, if you have that/those modules handy from the same kernel version you can 'sideload' them from the d-i installer, it has an option to load drivers