[06:29] <didrocks> good morning
[06:31] <didrocks> ok, gnome-shell .92 is now a valid candidate, pomodoro went in and glibc is ok
[06:32] <didrocks> only blocked by its extensions now:     * amd64: gnome-shell-extension-dash-to-panel, gnome-shell-extension-multi-monitors, gnome-shell-extension-taskbar
[06:32] <duflu> Morning didrocks
[06:33] <didrocks> hey duflu
[06:34] <didrocks> none of the 3 are updated in Debian though
[06:34] <didrocks> Trevinho: when you merged with debian with those Breaks, were you involved in getting them updated?
[07:00] <oSoMoN> good morning desktoppers
[07:00] <duflu> Hi oSoMoN
[07:00] <oSoMoN> hey duflu
[07:13] <didrocks> salut oSoMoN
[07:13] <oSoMoN> salut didrocks
[07:19] <seb128> lut oSoMoN didrocks
[07:19] <seb128> good morning desktopers
[07:19] <seb128> hey duflu
[07:19] <duflu> Hello seb128
[07:20] <oSoMoN> salut seb128
[07:21] <didrocks> salut seb128
[07:31] <Nafallo> morning guys :-)
[07:34] <didrocks> hey Nafallo
[07:41] <didrocks> (btw, doing gdm3 and gnome-session)
[07:42]  * didrocks still waits for anyone with debian upload rights to sponsor my mutter & gnome-shell branches (see scrollback from yesterday evening) so that we can sync mutter and I can push my gnome-shell merge
[07:44] <seb128> didrocks, speaking of those, the backlog was not clear, you mentioned salsa yesterday but you didn't push anything to it?
[07:45] <seb128> didrocks, https://salsa.debian.org/didrocks-guest has no recent activity
[07:46] <didrocks> seb128: I pushed them to launchpad, that's the link I referenced
[07:47] <didrocks> I can push them to salsa if people don't want just to pull/push
[07:47] <didrocks> (with with the finalize changelog commit that I needed for gnome-shell, having a merge is weird IMHO)
[07:48] <seb128> didrocks, well, it would increase the chance to avoid someone on the Debian side not knowing you did the work and redoing it
[07:48] <seb128> I mentioned it to jbicha yesterday, but he was busy updating the world and started arguing that you did push to Debian since you didn't push to salsa
[07:49] <didrocks> seb128: but if I propose a merge with the finalize commit that I needed to prepare the ubuntu branch, that's not giong to work
[07:49] <seb128> maybe L_aney can pick them up when he gets online
[07:49] <seb128> you mean?
[07:49] <didrocks> well, I needed to prepare ubuntu/master as well
[07:49] <didrocks> for gnome-shell
[07:49] <didrocks> to test it
[07:50] <seb128> mutter is in sync, so if you did that one it should be no issue
[07:50] <didrocks> for this, you git merge from debian
[07:50] <didrocks> but if you do a merge instead of a pull/push, the history differs
[07:50] <didrocks> (a merge in salsa)
[07:50] <seb128> and gnome-shell I would expect the update to be done in debian, including changelog/tagging
[07:50] <didrocks> so, your "rebase" is lying
[07:50] <seb128> and then we merge on top?
[07:50] <didrocks> yeah, but it means, that I have to redo it a second time
[07:50] <didrocks> once it's merged
[07:51] <didrocks> and I couldn't test on ubuntu without merging my WIP debian work
[07:51] <seb128> I see
[07:51] <didrocks> so, basically, we are doing twice the work, and adding delays
[07:52] <didrocks> this is really not motivating
[07:52] <seb128> well, hopefully Laney can review/upload/commit that when he gets online in 10 min
[07:52] <didrocks> that's why I just asked for a pull/push
[07:52] <didrocks> instead of a merge
[07:52] <didrocks> yeah, let's see
[07:52] <seb128> you could probably ask that on salsa as well if you have a merge request
[07:52] <seb128> hopefully people would read and pull instead of just pressing the merge button :p
[07:52] <seb128> but yeah, let's wait for Laney
[07:53] <didrocks> you think people are reading? I'm unsure ;)
[07:53] <didrocks> but yeah, we could try next time
[07:53] <didrocks> anyway, let's see, if we can't pull/push, that means I have to redo the work
[07:53] <didrocks> and so, that the process is even more cumbersome
[08:00] <willcooke> morning gang
[08:01] <duflu> Zoinks
[08:01] <duflu> Morning willcooke
[08:02] <Laney> yo
[08:02] <duflu> sup Laney?
[08:02] <didrocks> hey willcooke, Laney
[08:02] <seb128> hey willcooke Laney, how are you today?
[08:03] <Laney> alright
[08:03] <Laney> what is the argument?
[08:04] <didrocks> I need someone to pull/push my branches for mutter/gnome-shell to salsa
[08:04] <didrocks> as I already prepared the gnome-shell branch for ubuntu, I would prefer a pull/push to not have to redo the work when remerging the debian package for ubuntu
[08:05] <didrocks> (so, the finalize commit for g-s is already in the branch)
[08:06] <Laney> some complaints about whether the eventual commits in salsa end up different?
[08:06] <Laney> in that case, what problem would another git merge be?
[08:06] <didrocks> it looks weird though via history
[08:06] <didrocks> you say "based on <…>", and then, you remerge from debian with the same version
[08:07] <Laney> right, based on proposed state in debian, that state changes, you merge in those additional changes
[08:07] <Laney> I don't think that's a problem personally
[08:07] <Laney> actually it seems like the right representation of the history
[08:07] <didrocks> sounds like a hard to read history to me
[08:07] <Laney> ok, sorry but I don't want another git argument
[08:09] <seb128> oh git, we should write songs about it ;)
[08:10] <didrocks> Laney: still able to sponsor though?
[08:10] <Laney> can look
[08:10] <didrocks> thx!
[08:11] <didrocks> the branches are on launchpad, I can push them on salsa if you prefer and copy paste what I wrote
[08:12] <Laney> I am really clear in saying that there is no 'redo the work' in case I change anything or even merge the commits with a merge commit though, you simply merge an additional time and the history is correct in describing what happened
[08:12] <Laney> this is what I advised andyrock to do actually when preparing updates on both sides
[08:12]  * Laney takes a look
[08:12] <Laney> actually let me finish gtk3 first, I started that one yesterday
[08:13] <didrocks> sure
[08:16] <andyrock> seb128: in https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1786344 what's simpliefied english?
[08:16] <andyrock> *Simplified English
[08:17] <andyrock> maybe he meant Simplified Chinese?
[08:17] <seb128> yes, I think he does
[08:17] <seb128> I put the chinese description in google translator
[08:17] <seb128> "18.10 Mirror (2018.8.7) Select Simplified Chinese to boot, unable to input Chinese. "
[08:17] <seb128> so yeah, translations error :)
[08:17] <seb128> and hey andyrock!
[08:18] <andyrock> hey :D
[08:18] <andyrock> I was also taking a look to gnome-screenshot 3.30
[08:18] <andyrock> do we still need to carry out the patches for unity?
[08:18] <andyrock> *carry
[08:18] <seb128> "need"
[08:19] <seb128> if we can it's nicer to the unity users
[08:19] <seb128> but it's too much work then we can argue it's not worth the effort
[08:19] <seb128> so depends how difficult it is to rebase those
[08:19] <andyrock> should not be difficult
[08:19] <seb128> better to keep them then I would say
[08:20] <andyrock> now I need to understand which chinese is the simpliefied in the boot menu
[08:20] <andyrock> :D
[08:22] <seb128> I don't think it matter
[08:22] <seb128> the problem is probably true on any locale that requires ibus
[08:22] <seb128> or I would guess that to be the case
[08:24] <andyrock> seb128: but I'm able to type Chinese selecting Intelligent Pinyin in a live
[08:24] <andyrock> let me check how it works in Bionic
[08:24] <seb128> andyrock, well I think the bug is that you shouldn't to go select it, that should be the default
[08:24] <seb128> activated on login
[08:26] <seb128> andyrock, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1786344/comments/10 has a bit more details
[08:50] <willcooke> jibel, do you vnc any desktop machines?
[08:50] <willcooke> gnome shell specifcally
[08:58]  * didrocks reboots with new gnome-session & gdm
[09:09] <jibel> willcooke, I don't
[09:09] <jibel> willcooke, why this question?
[09:11] <willcooke> jibel, well...  when ever I try to VNC in to my 18.04 desktop which is running as a server, I just get a black screen.  It always "just worked" before 18.04.  I did some google and found similar problems, but no obvious solution yet
[09:12] <willcooke> jibel, when you get a sec, and you  test?  Someone said it might be caused by the video drivers
[09:12] <willcooke> oh, I might be able to test on my other laptop
[09:12] <willcooke> which is intel
[09:12] <willcooke> I'll do that
[09:13] <didrocks> hum, various imports of upstream/laste and pristine-tar then doesn't match with our launchpad branch… :/
[09:13] <didrocks> some fusion conflicts even
[09:14] <didrocks> seb128: I wonder if that's not related to your merge in https://code.launchpad.net/~ubuntu-desktop/ubuntu/+source/gnome-session/+git/gnome-session
[09:14] <seb128> didrocks, :-/
[09:15] <seb128> talk to Trevinho about it maybe?
[09:15] <seb128> afaik I just pushed what he had submitted
[09:15] <didrocks> yeah, but I guess the issue is that we imported the same version than debian
[09:15] <didrocks> but then moved forward
[09:15] <didrocks> before reimported
[09:15] <didrocks> so both sides have new commits (with different version), and so, different content
[09:15] <seb128> we did the update in Debian first
[09:15] <didrocks> and git can't know which side to pick
[09:15] <seb128> then merges
[09:15] <didrocks> hum
[09:15] <seb128> iirc
[09:16] <seb128> but maybe Trevinho had both side ready at the same time
[09:16] <seb128> and it got merged using the salsa web ui or something in debian and that created divergence
[09:16] <seb128> I don't remember now
[09:16] <willcooke> jibel, yeah works fine on this other machine.  So I think it could be nouveau
[09:16] <didrocks> could be, anyway, this is a real pb we can get (even if it's maybe a different one this time) ^
[09:17] <seb128> right
[09:17] <seb128> the handle of those branches is a bit tricky
[09:17] <didrocks> I'm going to do a merge --this (or whatever the syntax is) to say to prefer the current version
[09:17] <didrocks> yeah
[09:17] <seb128> unsure at this point how we could improve that though
[09:17] <didrocks> it wasn't done for having different distros using the same branch IMHO
[09:18] <didrocks> but we can't switch in and out
[09:18] <didrocks> tricky
[09:18] <willcooke> jibel, correction - it's Radeon
[09:19] <willcooke> jibel, which rather scuppers my plans to try a different driver
[09:23] <duflu> willcooke, are you using gnome-shell's native remote desktop or a legacy VNC server? If the latter then it probably won't work in (X)Wayland sessions, and will show all black
[09:25] <duflu> Because no external VNC server can read/see the desktop in Wayland, probably
[09:26] <willcooke> duflu, I tried both
[09:26] <willcooke> and I'm using the X session
[09:26] <willcooke> I now think that it's not "a black screen"
[09:26] <duflu> Very dark grey?
[09:27] <willcooke> I ran xev and moved the mouse around on the whole screen and xev saw nothing at all
[09:27] <willcooke> duflu, lol
[09:27] <willcooke> I might have to get a screen out of the loft and plug it in, maybe there is something on the screen like "do you want to allow...."
[09:29] <duflu> Actually I don't even know if gnome-shell's native remote desktop support is finished/enabled/built yet
[09:29] <duflu> When I build mutter myself it always says "no"
[09:29] <willcooke> It works using the built in one on my intel based laptop
[09:30] <duflu> Cool. I am probably just missing build-deps
[09:30] <jamesh> does VNC send mouse movement when no buttons are pressed?  It's been ages since I've looked at the protocol
[09:30] <willcooke> jamesh, erm, yes I think so, but I will confirm
[09:31] <willcooke> well, I can see the mouse moving around on the laptop when I move it via vnc, so I would assume yes
[09:31] <jamesh> that'd be client related rather than server related, either way
[09:32] <willcooke> ah right
[09:32] <duflu> I doubt it. The client would be able to detect any local errors. The client can't detect the difference between a server that's meant to be reporting a black screen and one that's not
[09:37] <Trevinho> didrocks: mhmh... Normally to avoid this I always made sure debian side merged through same thing then merging with Ubuntu... But it's possible that some diversion happens and it's why I wanted some time ago wanted to discuss how to handle it
[09:38] <didrocks> Trevinho: yeah, it's an annoying thing we didn't anticipate
[09:38] <didrocks> Trevinho: btw, did you see my questions about the 3 extensions, were there any coordination (apart from the bug filing) in debian side to update the extensions?
[09:39] <didrocks> as right now, .92 is stuck in proposed due to this (breaks: other-extensions)
[09:39] <didrocks> (pomodoro is synced btw, and the autopkgtest works)
[09:53] <Trevinho> didrocks: nope, I didn't do anything on extensions... Maybe I should had 😢
[09:54] <Trevinho> And that problem... I did anticipate but I was blamed for trying to handle the problems before they were a reality
[09:54] <didrocks> hum, I hope that those 3 upstreams we are blocked on released patches
[09:54] <didrocks> but we need to package it, and it's in sync in debian
[09:54] <didrocks> would be quicker for someone to do it directly in Debian and upload
[09:55] <didrocks> rather than diverging (or waiting for Debian to review the patches, waiting with gnome-shell blocked in -proposed meanwhile…)
[10:08] <Laney> it would be an option to kick them out to proposed
[10:35] <Laney> hmm, I can't type compose characters into my terminal
[10:35] <Laney> this is a problem for certain of my passphrases that I need to be able to type to upload /o\
[10:36] <Laney> ok, I can paste them, but still ;_;
[10:37] <Laney> didrocks: I think they wanted 3.30 to go to unstable, so do you want to update the branch for that or should I do it?
[10:37]  * Laney has done mutter already
[10:38] <Laney> but not gnome-shell (yet)
[10:56] <Trevinho> Laney: didier had https://code.launchpad.net/~didrocks/ubuntu/+source/gnome-shell/+git/gnome-shell/ but from what I see there was no patches refresh yet, or did I miss the commit?
[10:57] <Laney> probably no updates were needed
[10:57] <Laney> those are the best kind of updates
[10:58] <Laney> I'll just get to work on merging exp into master for debian
[11:16] <Laney> https://git.launchpad.net/~laney/ubuntu/+source/gnome-shell <- that's ubuntu/master with the new debian/master merged in
[11:17] <Laney> only difference is the commit I made to update references to exp branch & watch file
[11:19] <xnox> jibel, what are the rules around utah? whoever spots a bug, gets to fix it?
[11:20] <xnox> i see this change: https://bazaar.launchpad.net/~utah/utah/dev/revision/1126
[11:20] <xnox> however in https://platform-qa-jenkins.ubuntu.com/view/Desktop/job/ubuntu-cosmic-desktop-amd64-smoke-default/88/console
[11:20] <xnox> I see
[11:20] <xnox> UTAH exception: initrd file does have have gz or lz extension: /var/lib/utah/vm/utah_vm_G1kh05lzIYOIe4qu/tmpf2NIif/initrd
[11:21] <xnox> i wonder if UTAH is getting confused by are multi-initrd which has initrd, intel microcode, and amd microcode archives.
[12:08] <didrocks> Laney: sounds good, thanks!
[12:08] <didrocks> Trevinho: yeah, no patch refresh needed
[12:14] <jibel> xnox, this one is fixed but there is another issue where the image fails to reboot after installation
[12:14] <jibel> xnox, heber is on it
[12:41] <Trevinho> didrocks: ah, ok... as I thought something went in, but I guess it's post .30 then
[12:42] <Trevinho> didrocks:  can you merge this in the mean time https://code.launchpad.net/~3v1n0/ubuntu/+source/gnome-shell/+git/gnome-shell/+merge/354321?
[12:42] <Trevinho> I don't want to do the release now though, just leave unreleased as I prefer to wait 3.28.4
[12:43] <Trevinho> or maybe we can do  an upload just with the search fixes? seb128 mentioned that, but if we go with an official point release is quite easy to verify anyway
[12:46] <xnox> ok
[12:48] <didrocks> Trevinho: well, we need first to be released to cosmic
[12:49] <didrocks> your patch*
[12:49] <Trevinho> didrocks: yeah, sure but for the VCS we can still merge, then in case we change there, I mentioned just not to do back and froth with branches around, but as you prefer
[12:49] <didrocks> Trevinho: sure, I meant, in case you want to release it
[12:50] <Trevinho> sure sure... Although seb mentioned sometimes that is fine when a things i "on the way for sure", but I'm not rushing on releasing
[12:50] <didrocks> I guess there is no urgency, let me just merge it
[12:51] <Trevinho> exactly no urgency... just prefer not to loose track of things
[12:51] <Trevinho> I'm preparing other components too, while for calculator I'm also updating to .2
[12:51] <didrocks> Trevinho: done
[12:52] <Trevinho> ta
[13:17] <Laney> didrocks: do you want me to upload gnome-shell?
[13:17] <Trevinho> didrocks: for gnome-calculator, the SRU can I merge on debian 3.28.2-1 first (no feature changes https://paste.ubuntu.com/p/T3wQfD7wnf/) and then apply that patch or I should just merge with updated upstream and do the versioning side alone? As since debian didn't really change anything I guess i can proceed this way, no?
[13:17] <didrocks> Laney: to debian? Please do, I can handle the mutter sync + gnome-shell upload to cosmic
[13:18] <didrocks> Trevinho: agreed, if the diff are minor and fix issues, I see no reason to separate your fix and the maintenance release upload
[13:19] <Laney> didrocks: no, to cosmic, since I re-merged, but feel free to handle
[13:19] <Laney> unstable is done done done
[13:20] <Trevinho> didrocks:  need to do the classic merged with debian line though, right?
[13:20] <didrocks> Laney: oh, feel free to upload if you prefer
[13:20] <didrocks> I have no strong opinion :)
[13:21] <didrocks> Trevinho: unsure what is the classic merged? ;)
[13:21] <Trevinho> remaining changes...
[13:22] <didrocks> Trevinho: depends on the release team, they don't really like extra diff not fixing bugs, but if you can convince them…
[13:22] <Laney> should probably wait for the accepted emails from dak
[13:23] <didrocks> Laney: still unsure, you are handling it? (I'm fine with that, you did the commits on top…)
[13:23] <didrocks> ok yaru snap "fixed" ;)
[13:23] <Laney> sure!
[13:23] <didrocks> thx ;)
[13:23] <didrocks> next upstream release -> I'll sync a cosmic upload before UIF
[13:23] <Laney> yaruuuuuuuuuuuuuuuuUuuuuuuuuUUUUUUUUUUUUUUUuuuu
[13:24] <Laney> autopkgtest for autopilot-gtk/1.4+15.10.20150826-0ubuntu1: amd64: Regression ♻ , arm64: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: Regression ♻ , s390x: Regression ♻
[13:24] <Laney> :<
[13:26] <didrocks> flaky tests for sure and you just got unlucky :p
[13:26] <didrocks> (or should play to $$$ game)
[13:27] <Laney> http://autopkgtest.ubuntu.com/packages/a/autopilot-gtk/cosmic/amd64
[13:27] <Laney> really unlucky!
[13:28] <didrocks> 0, 1… it's quite close still!
[13:28] <Laney> still stuck behind glibc anyway
[13:28] <didrocks> are you sure? gnome-shell doesn't show it being stuck anymore by it
[13:29] <Laney> oh no glib2.0
[13:29] <didrocks> ah ;)
[13:29] <Laney> but I didn't sync that so I'm not feeling too responsible for getting that to go in right now :-)
[13:30] <didrocks> heh
[13:30] <didrocks> wdyt we should do for gnome-shell?
[13:30] <didrocks> (regarding extensions)
[13:30] <Laney> kill them to cosmic-proposed
[13:31] <didrocks> it means that if we didn't look at it, there are some chances that dashtopanel and other aren't installable
[13:31] <Laney> they won't be in the release, that's right
[13:31] <Laney> same as what'll happen in debian
[13:31] <didrocks> (I don't know if people are using the extension websites or packages)
[13:31] <didrocks> oh, debian may remove them?
[13:31] <Laney> they'll be auto removed from testing
[13:31] <Laney> https://tracker.debian.org/pkg/gnome-shell-extension-dash-to-panel
[13:31] <Laney> see the note there
[13:32] <didrocks> interesting
[13:32] <didrocks> ok, so removing them in the release pocket (and not -proposed), yeah mean?
[13:32] <Laney> there's a script demote-to-proposed or something
[13:32] <didrocks> not in ~ubuntu-archive
[13:32] <Laney> which copies to cosmic-proposed and delete from release
[13:33] <Laney> it's in lp:ubuntu-archive-tools
[13:33] <didrocks> oh, I didn't add it to my $PATH one this laptop…
[13:33]  * didrocks fixes
[13:33] <Laney> should block them in proposed-migration too otherwise they might get copied straight back
[13:33] <didrocks> ok, I'll do that, makes sense
[13:33]  * Laney does
[13:33] <didrocks> oh right ;)
[13:36] <Laney> there
[13:36] <Laney> now it should pick copying gnome-shell rather than the extensions
[13:36] <didrocks> ok, I'm running demote-to-proposed now
[13:37] <Laney> winning
[13:37] <Laney> I'll push gnome-shell to git, will upload once the new one moves over
[13:37] <didrocks> and done! yeah, sounds good to wait for the new one moving now
[13:37] <didrocks> thx Laney
[13:39] <Trevinho> didrocks: spotted another small thing https://code.launchpad.net/~3v1n0/ubuntu/+source/gnome-calculator/+git/gnome-calculator/+merge/354328
[13:40] <Laney> hmm there's already an ubuntu/3.30.0-1ubuntu1 tag there but that's a bit different to what I'm going to upload
[13:40] <Laney> shall I la la la and delete it?
[13:41] <didrocks> Laney: yeah, that was my thing about "need to be redone or pending review in debian", but that's fine, just delete and replace it
[13:41] <Laney> alright
[13:42] <didrocks> Trevinho: merged
[13:43] <didrocks> interesting, I didn't work on calculator, but I see that git push is failing on pristine-tar and upstream/latest and there are conflicts :p
[13:43] <didrocks> weird though, because it seems people used -f rather than merging, it's puzzling
[13:44] <Laney> O_O
[13:50] <Trevinho> didrocks: thanks, also this branch needs to be pulled to ~ubuntu-desktop as there's not a an ubuntu/bionic yet:
[13:50] <Trevinho> https://code.launchpad.net/~3v1n0/ubuntu/+source/gnome-calculator/+git/gnome-calculator/+ref/ubuntu/bionic
[13:52] <didrocks> Trevinho: can't we create one so that I can see the diff? ;)
[13:52] <Trevinho> didrocks: yep, just do it with `git checkout -b ubuntu/bionic ubuntu/1%3.28.1-1ubuntu1`
[13:52] <Trevinho> didrocks: so I can prepare the MP
[13:53] <Laney> Trevinho is on the path to upload rights, I like it
[13:54] <Trevinho> not sure I want them :D
[13:54] <didrocks> Trevinho: ubuntu/bionic branch create
[13:54] <didrocks> created*
[13:54] <Trevinho> cool
[13:55] <Trevinho> I could have put the gbp and control commits before the merge... but meeh, I'm lazy now to rebase :)
[13:56] <Trevinho> lots of diff, but actually debian/ diff is small
[13:57] <didrocks> Trevinho: did you have a script for generating the Yaru changelog?
[13:57] <Trevinho> didrocks: mhmhmh, wait
[13:57] <Trevinho> didrocks: `gbp dch` just that
[13:58] <didrocks> interesting ;)
[13:58] <Laney> you have to re-order the entries because it doesn't group by person
[13:58] <didrocks> works well indeed
[13:58] <Laney> bit annoying
[13:58] <didrocks> ah ok Laney
[13:58] <didrocks> thx for mentionning!
[13:58] <Laney> like if it's Laney didrocks Laney, you get two [ Laney ] bits
[13:58] <Trevinho> yep..
[13:58] <didrocks> yep, got you
[13:59] <Trevinho> I mentioned the same last day... need to fix that upstream, laney I saw you already sent a patch to Guido, so you're the good one to ask for fixing that too :)
[14:00] <Laney> nah, bus factor is bad 😌
[14:00] <Trevinho> I think I screwed things in calculator... let me redo it
[14:01] <jbicha> gbp dch --multimaint-merge   you can probably set that in debian/gbp.conf to
[14:01] <jbicha> too
[14:02] <Laney>     --multimaint-merge  Merge commits by maintainer, default is 'False'
[14:02] <Laney> yes
[14:02] <Laney> I just found that :>
[14:03] <Laney> ALSO https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881467
[14:03] <Laney> the tip in there is going to change my life
[14:04] <Trevinho> oh, lovely... `dch dch debian` for life
[14:04] <Trevinho> s/dch/gbp/
[14:04] <Laney> I've been manually deleting those entries
[14:22] <Trevinho> didrocks: mhmh so https://code.launchpad.net/~3v1n0/ubuntu/+source/gnome-calculator/+git/gnome-calculator/+merge/354330 is the merge, but... there's lot of "garbage" because i think debian introduced to the VCS pre-compiled files, so the issue... however `git diff  debian/3.28.2-1` is what you might look at or `git diff ubuntu/1%3.28.1-1ubuntu1 debian` as the rest is just garbage happened on merging with upstream that is not anymore in
[14:22] <Trevinho> debian/master but was there in debian/3.28.2-1 tree
[14:23] <Laney> ah, interesting, autopilot was relying on some defaults in ambiance
[14:23] <Trevinho> ambiance won't ever change! :)
[14:23] <didrocks> Laney: so, failing for quite a while? But I guess nothing triggered it
[14:23] <didrocks> Trevinho: ok, I'll have a look (maybe later though, testing Yaru for now)
[14:23] <Laney> it fails now that Yaru is default I guess
[14:24] <Trevinho> didrocks: sure, waiting new fresh look :)
[14:24] <Laney> but really it should be setting properties if it wants to test them, not assuming the theme is static
[14:24] <didrocks> waow, the over-amplification is interesting
[14:24]  * didrocks prefers it to default upstream one
[14:24] <didrocks> Laney: yeah, on the other side, they want to test on the default
[14:24] <Trevinho> Laney: what pkgs?
[14:25] <didrocks> what are they relying on?
[14:25] <Laney> assuming some border width is 5
[14:25] <didrocks> ah, yeah, so that's more debatable :)
[14:26] <Laney> it's like "give me all the boxes with this width" to test if selecting works
[14:26] <Laney> but the only reason they had that width was because of the theme
[14:26] <Laney> test's .ui file should set it
[14:27] <didrocks> right
[14:28] <Laney> 👍
[14:38] <Laney> SHELLLLLLLLLLLLLLLlllllllllllllll
[14:44] <seb128> tjaalton, thanks for the xorg minor update, I'm still going to annoy you a bit by mentioning that libxss has a minor update available (https://gitlab.freedesktop.org/xorg/lib/libxscrnsaver/tags/libXScrnSaver-1.2.3) and libinput/wayland would be nice to update :)
[15:27] <didrocks> taking gnome-getting-started-docs, brain is fried ;)
[15:35] <Laney> was waiting ages for the autopilot-gtk build to finish, turned out my ssh connection to home had frozen /o\
[15:38] <didrocks> "waow, that touch command was taking ageesssssss"
[15:39] <Laney> it was just after starting the testsuite
[15:39] <Laney> which sometimes doesn't output stuff for ages
[15:39] <didrocks> ok, easy to get missed then
[15:39] <Laney> terrible timing :P
[15:39] <didrocks> yep
[15:44] <Laney> 😸 (ok, can paste emoji, new gnome-characters works enough)
[15:52] <willcooke> :)
[15:59] <Trevinho> seb128: do you remember you should redo the upload of https://code.launchpad.net/~3v1n0/ubuntu/+source/nautilus/+git/nautilus/+merge/350174 ? :)
[16:08] <seb128> Trevinho, yes, I asked you the other day if you could amend the vcs to have the right version if you remember?
[16:09] <Trevinho> seb128: ah, I forgot that bit... But release was fine with such version eventually, no?
[16:12] <seb128> no since they rejected asking to change and reupload
[16:14] <Trevinho> seb128: yes, but then sil corrected: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1782681/comments/3
[16:24] <tjaalton> seb128: the problem with libxss for instance is that it's lacking six years of janitorial pkg maintenance, and the upstream changes are worthless
[16:25] <tjaalton> one manpage typo fix, five autogen cleanup commits, one warning fix
[16:25] <tjaalton> libinput 1.12rc is in a staging ppa, final expected next week
[16:37] <tomreyn> hi, i noticed there is http://cdimage.ubuntu.com/bionic/daily-live/current/ - but the name seems to be misleading, it was last built in july.
[16:38] <tomreyn> was this meant to be just a temporary build, is it going to go away soon, or will there likley be dailies, and the build scripts just dont work out, yet?
[16:38] <Laney> They are promoted to that directory when they pass automated testing - I think the QA guys are looking into why it's failing
[16:38] <Laney> the raw daily images end up in http://cdimage.ubuntu.com/bionic/daily-live/pending/
[16:39] <tomreyn> thanks Laney!
[16:39] <Laney> no problemo 🤠
[16:46] <seb128> tjaalton, k, thanks, fair enough for libxss I'll mark to ignore for our report (and good to know for libinput)
[16:50] <seb128> Trevinho, reuploaded nautilus bionic
[16:56] <popey> willcooke: kenvandine Wimpress I added a spreadsheet link to our desktop doc we were in. It has some screenshots for some of the apps
[16:56] <kenvandine> popey, thx
[17:07] <willcooke> thanks popey
[17:09] <willcooke> popey, can we get edit rights?
[17:13] <willcooke> on that note, quittin time.  Night all
[17:56] <Trevinho> seb128: thanks
[17:57] <tjaalton> seb128: wayland uploaded
[18:38] <Laney> looks like my autopilot didn't work properly
[18:38] <Laney> despite having run the autopkgtests locally
[18:38] <Laney> WAH
[18:39] <Laney> oh yeah, it'll need the new gtk :/
[19:20] <seb128> tjaalton, great :)


[00:12] <rowinggolfer> I've just done my first dput.
[00:12] <rowinggolfer> how long before I see the good stuff in my ppa?
[00:13] <wgrant> rowinggolfer: You'll receive a message within 5 minutes if you signed it properly.
[00:14] <wgrant> If it's accepted, it'll appear on your PPA page and start building within five seconds.
[00:14] <wgrant> And be visible to apt within five minutes of the build completing successfully.
[00:15] <rowinggolfer> ah... I got a rejection.
[00:15] <wgrant> Of what variety?
[00:16] <rowinggolfer> I got the path wrong :(
[00:16] <wgrant> rowinggolfer: Ubuntu Jaunty and above don't need manual configuration.
[00:16] <wgrant> Just 'dput ppa:username/ppa blah_source.changes'
[00:17] <rowinggolfer> I did this
[00:17] <rowinggolfer> dput ppa:rowinggolfer/ppa openmolar_0.1.2-0ubuntu1_source.changes
[00:18] <wgrant> What was the error?
[00:19] <rowinggolfer> ould not find a PPA named 'openmolar' for 'rowinggolfer'.
[00:20] <rowinggolfer> I think my .dput.cf was incorrect
[00:20] <wgrant> You don't need anything in your .dput.cf.
[00:21] <rowinggolfer> ah.
[00:26] <rowinggolfer> wgrant - I think this needs updating then ??
[00:26] <rowinggolfer> https://help.launchpad.net/Packaging/PPA/Uploading
[00:27] <wgrant> rowinggolfer: Indeed, although there are now instructions directly on the PPA page.
[00:27] <rowinggolfer> true that.
[00:28] <wgrant> Jaunty is only a few months old, so it's not terribly surprising that the page hasn't been updated.
[00:30] <rowinggolfer> ok, so i _think_ I've uploaded it correctly
[00:30] <rowinggolfer> but nothing back yet.
[00:30] <rowinggolfer> no news is good news?
[00:31] <wgrant> Wait another few minutes.
[00:31] <wgrant> You probably just missed the last upload processor.
[00:32] <rowinggolfer> ok.
[00:32] <rowinggolfer> I wondered if I'd stuffed up because this is a new package?
[00:33] <rowinggolfer> missed some random "initial upload" variable off somewhere
[00:33] <wgrant> If you got a rejection message the first time, you should get something this time.
[00:33] <wgrant> THere's nothing like that.
[00:33] <rowinggolfer> ok. I'll go put the kettle on.
[00:33] <rowinggolfer> thanks wgrant
[00:36] <wgrant> rowinggolfer: Still nothing :(
[00:43] <rowinggolfer> wgrant: nope :(
[00:44] <wgrant> rowinggolfer: No email?
[00:44] <rowinggolfer> no.
[00:44] <rowinggolfer> and if I try uploading again, I get this
[00:44] <rowinggolfer> neil@neil-12inch:~/openmolar$ dput ppa:rowinggolfer/ppa openmolar_0.1.2-0ubuntu1_source.changes
[00:44] <rowinggolfer> Already uploaded to ppa on ppa.launchpad.net
[00:44] <rowinggolfer> Doing nothing for openmolar_0.1.2-0ubuntu1_source.changes
[00:45] <wgrant> rowinggolfer: That's just a local check; give dput '-f' to override.
[00:45] <rowinggolfer> ok
[00:54] <rowinggolfer> wgrant: getting there
[00:54] <rowinggolfer> different rejection message :(
[00:55] <wgrant> Section this time?
[00:57] <rowinggolfer> no, my changelog was duff
[00:57] <wgrant> Ah.
[00:57] <rowinggolfer> openmolar (0.1.2-0ubuntu1) unstable; urgency=low
[00:58] <wgrant> Are you using 'dch' to edit the changelog?
[00:58] <rowinggolfer> a little bit of debian in there ;)
[00:58] <rowinggolfer> my app is pretty agnostic
[00:58] <rowinggolfer> works on hardy and jaunty
[00:58] <rowinggolfer> do I have to be specific though?
[01:02] <wgrant> rowinggolfer: You do. But you would normally give the lowest series -- in this case 'hardy'
[01:02] <rowinggolfer> thanks.
[01:03] <wgrant> It gets a bit more complicated than that, but we'll get to that later.
[01:05] <rowinggolfer> ok, uploading again.
[01:13] <wgrant> rowinggolfer: What went wrong this time?
[01:14] <rowinggolfer> openmolar_0.1.2-0ubuntu1.dsc: Unknown section 'office'
[01:14] <rowinggolfer> grr
[01:14] <wgrant> Do you know where to find the list of valid sections?
[01:15] <rowinggolfer> nope
[01:16] <wgrant> rowinggolfer: Bottom of section 2.4 at http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
[01:17] <rowinggolfer> just found that
[01:17] <rowinggolfer> gonna plump for "misc"
[01:18] <wgrant> Hard to say :(
[01:20] <rowinggolfer> I should be sectioned.
[01:20] <rowinggolfer> this is a chore.
[01:26] <rowinggolfer> accepted :)
[01:27] <wgrant> But will it build?
[01:28] <rowinggolfer> good question indeed.
[01:28] <rowinggolfer> wee clocky icon is spinning
[01:32] <wgrant> rowinggolfer: Did you try building the package locally?
[01:35] <rowinggolfer> yes
[01:36] <rowinggolfer> but success or fail, I need to get to bed.
[01:36] <rowinggolfer> thanks for your help again wgrant
[01:37] <rowinggolfer> (bum - it failed)
[01:37] <rowinggolfer> goodnight
[06:32] <poolie> is staging meant to be down?
[06:37] <wgrant> It has been down quite a bit lately :(
[06:38] <wgrant> Updates were off for three days, and it just updated for the first time a couple of hours ago, so something was up.
[06:54] <poolie> i guess it's no emergency
[07:55] <gour> recently i read  http://changelog.complete.org/archives/1123-free-software-project-hosting review which is git-oriented, i.e. looking for a hosting with good git support. i was playing a lot with bzr wanting to migrate (from darcs) but returned back and, considering there are no real hosting solutions with darcs-supported, wonder if LP could be a good one by using darcs-fast-export(import) which is recently merged into bzr-fastimport
[07:55] <gour> plugin?
[08:04] <gour> any chance of darcs-support be added to LP's import considering that darcs-fast-export(import) is now bundled?
[08:33] <gour> i.e. any chance that https://bugs.launchpad.net/launchpad-code/+bug/44455 gets higher priority?
[08:34] <spiv> gour: my guess is, simply because there isn't much demand for it.  You could do the conversion yourself and push the result to Launchpad, of course.
[08:35] <spiv> "my guess is no", I meant :)
[08:35] <spiv> (Clearly I should be avoiding my laptop on weekends!)
[08:35] <gour> spiv: yeah, i'm aware of it...still having automatic import would be nice, especially considering that darcs support is now bundled in bzr-fastimprt plugin
[08:36] <gour> it's kind of catch-22...there is no demand 'cause the feature isn't there...
[08:37] <gour> similar to support for other DVCS & other project hostings...e.g. SF got some support to late :-)
[08:37] <spiv> Well, there's also far fewer projects using darcs than cvs, svn and probably git.
[08:37] <gour> s/to late/too late
[08:38] <spiv> Also, it sounds like you want two-way conversions, not just one-way?
[08:38] <gour> that's right, but doesn't having fast-import support greatly simplifies the task
[08:39] <gour> well, darcs-fast-export(import) give opportunity for 2-way, but just having ability to push from darcs repo and provide public bzr branches on LP would be nice as well
[08:39] <spiv> It might, but I'd have to check with the guys that actually implement the vcs imports in Launchpad before assuming that the existence of the fastimport plugin is the bulk of the work.
[08:40] <spiv> I think 2-way would be a bit problematic unless roundtripping is 100% accurate.
[08:40] <gour> thank you for considering it. :-)
[08:40] <spiv> Well, it's not up to me :)
[08:42] <gour> vmiklos did a great work with his darcs-fast-export and ian bundled it - https://bugs.launchpad.net/bzr-fastimport/+bug/232177
[12:03] <rowinggolfer> I'm struggling to get a working deb of my project following the instructions https://wiki.ubuntu.com/PackagingGuide/Python
[12:03] <rowinggolfer> not sure where to look for help.
[12:04] <rowinggolfer> it seems to me that there are so many ways to bake a *.deb
[12:04] <rowinggolfer> that a lot of the information around online is contradictory.
[12:04] <rowinggolfer> that howto suggests python-central scripts in the debian/rules
[12:04] <ripps> Is the launchpad buildfarm frozen? I've had a package that takes about 5 minutes to build in there for almost 30 minutes
[12:05] <rowinggolfer> ripps: the launchpad guys are quite good at putting a warning in the room topic if that happens.
[12:05] <rowinggolfer> I don't see one there at the moment
[12:05] <rowinggolfer> although perhaps I broke the farm with my attempts??
[12:07] <micahg> I noticed the Add Comment button missing on edge
[12:07] <ripps> rowinggolfer: I doubt it, I've sent over 80 packages there in a matter of minutes it handle it without a problem
[12:18] <happyaron> PPA building machines seems not working properly
[12:41] <micahg> is an update happening on edge
[12:42] <micahg> I can no longer see subscribers or the Add Comment button
[12:44] <wgrant> cprov: Can you kick buildd-manager?
[12:45] <wgrant> It seems to have been dead for an hour, right after ripps' builds were dispatched.
[12:46] <wgrant> micahg: edge hasn't updated for many days, and is working fine for me.
[12:47] <micahg> ugh, so maybe my session is messed up?
[12:49] <happyaron> my small package is building for over an hour, it usually takes no more than 15 minutes
[12:51] <wgrant> happyaron: Right, things are broken.
[12:51] <wgrant> micahg: More likely your browser.
[12:52] <happyaron> wgrant: what we can do is just wait and wait, :)
[12:53] <wgrant> happyaron: I'm afraid so.
[13:01] <micahg> wgrant: restarted my browser and all is well
[13:08] <lfaraone> Would LP's distro functionality work for a mini-distro that used RPMs?
[13:11] <micahg> are the tags for bugs supposed to show all tags in other tags or just certain ones?
[13:16] <wgrant> lfaraone: No. LP both doesn't really support other distros at the moment, and certainly not RPM-based ones.
[13:16] <wgrant> micahg: In the tags list on the right of the bug listing?
[13:16] <micahg> yep
[13:16] <micahg> there are official tags
[13:16] <micahg> and other tags
[13:16] <micahg> I would expect other tags to show all other tags
[13:17] <wgrant> micahg: It only shows the most popular i-forget-how-many.
[13:17] <wgrant> micahg: It used to show all of them, but Ubuntu has many many thousands of tags.
[13:17] <micahg> 10
[13:17] <wgrant> So it was very, very unwieldy and long.
[13:18] <micahg> wasn't one of the new features of 2.2.7 to be able to search for tags with +tag in the search boxz?
[13:18] <wgrant> micahg: No. But 2.2.5 or 2.2.6 brought advanced tag searches. Let me find the blog post..
[13:19] <wgrant> http://blog.launchpad.net/bug-tracking/searching-bugs-with-tags-now-with-wings
[13:21] <micahg> ugh
[13:21] <micahg> I can't do *tag
[13:22] <micahg> I still have to use advanced search to search for a specific tag
[13:22] <wgrant> Or click on the link down the side.
[13:22] <micahg> yes, but they're not all down the side
[13:22] <micahg> is it possible to make tag* an official tag
[13:22] <wgrant> tag*?
[13:22] <micahg> like if I wanted fixed-*, is that possible?
[13:23] <wgrant> No. * is not a partial wildcard. *blah isn't possible.
[13:23] <micahg> how about at the end
[13:23] <micahg> fixed-*
[13:25] <wgrant> I don't think so.
[13:29] <micahg> is it possible to custommize how many tags I see on the side?
[13:29] <wgrant> No, but it will show you as many official tags as exist.
[13:34] <micahg> should I mark a bug confirmed if I have the same problem in malone?
[13:34] <wgrant> micahg: You should mark the bug as affecting you.
[13:34] <micahg> ok
[13:35] <micahg> did that already
[13:35] <micahg> that reminds me of another bug :)
[13:35] <lfaraone> Does apport require users to create a launchpad account?
[13:36] <lfaraone> I'm thinking of deploying it in an enviornment when it wouldn't be realistic for each user to have their own LP account. (collecting information on a product used in primary schools)
[13:37] <wgrant> lfaraone: apport's Launchpad backend does, but its backends are pluggable.
[13:48] <lfaraone> wgrant: Well, I'd want to use launchpad with apport.
[13:49] <wgrant> lfaraone: Then yes, each user needs a Launchpad account.
[13:49] <wgrant> So it is not well-suited to your situation.
[13:57] <cprov> wgrant: uhm, is buildd-manager still broken ? I've just seen a bunch of job dispatched.
[14:01]  * cprov brb
[14:01] <wgrant> cprov: A whole lot of buildds just reappeared, and things seem to be moving again.
[14:01] <wgrant> So somebody is poking around.
[14:01] <happyaron> wgrant: yes, I get three build failed mail, :(
[14:02] <cprov> wgrant: they is always someone using the builders shared with 'enablement' services.
[14:02] <cprov> anyway, I will be online again in 10.
[14:03] <wgrant> cprov: So, it all seems resolved, but it might be nice to look at why it was hung for a couple of hours.
[14:03] <happyaron> cprov: there will be chromium daily build, and it use up almost all resource in a time
[16:51] <rowinggolfer> wgrant: I am "dput-ing" again, and confident the thing will build this time.
[16:51] <rowinggolfer> but we all know that confidence comes before a fall :(
[18:34] <intellectronica> hi micahg
[18:35] <micahg> hi intellectronica
[18:35] <intellectronica> micahg: so, why do you think subscribing people automatically can be a problem? I think that it's quite rare for someone to comment on a bug and not want (or need) to stay in the discussion
[18:35] <micahg> well, because the person might already be subscribed to bug mail for that project/package
[18:36] <intellectronica> micahg: so? in that case nothing special will happen. they will still receive mail
[18:36] <micahg> yes, but the headers and reasons why they are subscribed will change
[18:36] <intellectronica> we just have to make sure that the headers reflect that. i'm pretty sure they already do
[18:37] <micahg> yes, but the user might not want that
[18:37] <micahg> user might already have filters set up
[18:37] <intellectronica> micahg: if they do change, then i think it's something we should fix. if you're subscribed to bug mail for a project, that should take precedence over a header for subscribing to an individual bug
[18:38] <micahg> no
[18:38] <intellectronica> ?
[18:38] <micahg> I think the current behavior is fine
[18:38] <micahg> and proper
[18:38] <micahg> I use individual bug subscription to show that I'm active in the bug
[18:39] <micahg> but my comment might not mean I'm active necessarily
[18:39] <micahg> what's wrong with 2 buttons?
[18:39] <intellectronica> micahg: too complicated. not very user friendly
[18:39]  * micahg liked the checkbox with submit
[18:40] <intellectronica> also, i have a bit of a problem with people commenting without subscribing. i think that it's extremely rare for someone to want to comment but not be aware of future discussion
[18:41] <micahg> yes, but if a person is getting thousands of e-mails a day and only NEEDS to see comments on a few, and the filters are set up to do that, this would trash their system
[18:41] <intellectronica> micahg: well, what i'm suggesting is quite similar, behaviour-wise, to what we had before. by default you subscribe to the bug, but if you don't want that, unsubscribing is one additional click
[18:41] <micahg> i.e. team leads in Ubuntu
[18:42] <micahg> intellectronica: you'd be adversely affect people that already don't have time for the extra click
[18:42] <intellectronica> micahg: but that's just like it used to be. people who wouldn't have time for an extra click wouldn't have had time for an extra click when it was a checkbox
[18:43] <micahg> exactly
[18:43] <micahg> and they didn't want it checked
[18:43] <intellectronica> also, it's better to incovenience a few users than to inconvenience most users
[18:43] <micahg> it's not the same to click while on the way down to submit, then to wait for the postback and click
[18:43] <micahg> intellectronica: you're talking about inconveniencing the heaviest users of LP
[18:43] <intellectronica> micahg: but it was checked by default. they would have had to make an extra click to not get subscribed
[18:44] <intellectronica> micahg: yes, that's definitely something to take into consideration. also, because i don't use filtering by headers (i use gmail) it's sometimes hard for me to get a feel for how people use them
[18:45]  * micahg uses it to separate passive and active bugs
[18:45] <intellectronica> micahg: still, i don't see how that in any way would be worse than what we used to have, which seems to have been working quite well
[18:45]  * micahg subscribes to bugmail for 4 or so packages in ubuntu
[18:46] <intellectronica> a refinement of that idea would be to provide a global, per-user, option. "[x] Automatically subscribe me to bugs I comment on"
[18:47] <micahg> intellectronica: much better
[18:47] <micahg> and you can enable that by default
[18:47] <intellectronica> i hate doing that, though. i think that ideally we should have one behaviour that works as best as possible for everyone
[18:47] <micahg> then it's one click for the maintainers
[18:47] <micahg> intellectronica: people use the system differently
[18:47]  * micahg used to have 1 bug folder
[18:47]  * micahg now has 2 bug folders
[18:48] <micahg> heavier users needs to filter whereas normal users do not
[18:49] <intellectronica> another thing we could do is provide the header twice. once for your structural subscription and once for the direct subscription. then it's up to you to set up the filters that work best for you
[18:50] <micahg> well, that would confuse current filters and make filtering more complicated
[18:50] <intellectronica> micahg: but still, what i don't manage to understand is how what i'm suggesting would be any worse than what we already have. in both cases you get subscribed by default and need one single additional click if you rather not subscribe
[18:51] <micahg> it's where the click is
[18:51] <micahg> one is before the postback and in the flow
[18:51] <micahg> one is after the postback and requires scrolling back up
[18:52] <intellectronica> ah no, i'm not suggesting you have to scroll back. i'm suggesting something like "Thank you for your comment. You have been subscribed to mail notifications for future comments on the bug. Click here to unsubscribe."
[18:53] <hggdh> that might work as well, micahg
[18:53] <micahg> again, you have to wait for another postback
[18:54] <intellectronica> micahg: not really, since it can use XHR the interaction will be very fast
[18:55] <hggdh> and, in fact, although Status and Importance are now ajaxable, Assigned is not, and the option to add a comment and subscribe is there
[18:55] <micahg> post a comment now takes a few seconds to show up
[18:55] <intellectronica> hggdh: setting assignee (and changing bug target) will be ajaxified very shortly (as in, sometime early next week)
[18:56] <intellectronica> micahg: i know. there's a bug for that. it will most definitely be improved
[18:57] <intellectronica> it's because of a limitation of how we do rendering on the server and getting it using the webservice api. we know how to solve that but haven't gotten to it yet
[18:57] <intellectronica> anyway, gotta go
[18:58] <micahg> intellectronica: I suggest you talk to some of the package managers in ubuntu
[18:58] <micahg> they'll know best how they use it
[18:58] <intellectronica> micahg: if it's ok with you, i'd like to paste the above into the bug. i don't have time to summerisze right now and i think it was a very useful discussion
[18:58] <intellectronica> micahg: indeed, that's a good idea
[18:58]  * micahg doesn't need to speak for people that have no problem stating their own opinions :)
[23:11] <dsprenkels> Hello?
[23:23] <thumper> Hello
 there was a bug in reporting the bug
 so there was a timeout error
 forget it
[23:35] <exarkun> * jericho has quit (giving up on an attempt to help improve free software)
[23:36] <exarkun> hth, hand
[23:40] <wgrant> Probably the dupefinder, as usual...