[10:40] <fabbione> doko_: ping?
[10:41] <doko_> fabbione: pong
[10:41] <fabbione> doko_: what gcc do you expect for feisty?
[10:41] <fabbione> i have glibc-2.5 almost done
[10:44] <doko_> currently 4.1; 4.2 is not released, and probably will take longer.
[10:44] <fabbione> doko_: so the same gcc we have now in edgy?
[10:44] <doko_> so we have to backport the relevant binutils changes
[10:44] <fabbione> or are you adding extra patches and stuff like that?
[10:44] <fabbione> we will need a very new binutils to get hppa back in the game
[10:44] <fabbione> AFAIK Jeff is looking at it
[10:44] <doko_> fabbione: no, extra patches, long double 64->128 bit ABI change on powerpc and sparc
[10:44] <fabbione> doko_: ok, can you please let me have a source to build before monday?
[10:44] <doko_> fabbione: unreleased? an alternative might be the HJ Lu binutils for feisty
[10:44] <fabbione> or if you have it done.. now
[10:44] <fabbione> doko_: yes unreleased..
[10:44] <fabbione> dunno.. i hate binutils from the bottom of my heart
[10:44] <fabbione> it freaks me out...
[10:44] <doko_> it's not my toy package either
[10:45] <fabbione> eheh
[10:45] <fabbione> what i am done up till now is to merge all the packaging bits for glibc. i will need help from Jeff to review debian/patches
[10:45] <doko_> I'll prepare gcc either over the weekend or today
[10:45] <fabbione> and that's basically done
[10:46] <fabbione> but i want to simulate a bootstrap over all my machines
[10:46] <fabbione> build gcc with old gcc
[10:46] <fabbione> build gcc
[10:46] <fabbione> build kernel (that i know is going to suck)
[10:46] <fabbione> rebuild glibc and gcc and kernel again for fun and profit
[10:46] <fabbione> that would be lovely.. thanks
[10:47] <fabbione> if we can have at least part of the toolchain ready before we open feisty that will be great
[03:46] <jbailey> fabbione: Yeah, what you said.
[03:46] <jbailey> =)
[03:46] <fabbione> ehe
[03:47] <fabbione> i was saying that my target now is to 2.5 out for opening
[03:47] <fabbione> then we can cleanup as much as we want
[03:47] <jbailey> Yup.
[03:47] <fabbione> afaict the only thing missing now for an upload is debian/patches/ubuntu from 2.4 to 2.5
[03:47] <jbailey> I need to merge in ports stuff for hppa/
[03:47] <jbailey> And get the TLS patches in for binutils.
[03:47] <fabbione> and decide if we want NPTL or LT for hppa...
[03:47] <jbailey> The nice part is that I now feel comfortable enough with BFD to do that.
[03:48] <jbailey> No LT.
[03:48] <fabbione> ok
[03:48] <fabbione> i can fix that easily
[03:48] <jbailey> Our .orig.tar.gz shouldn't even have the tar.bz2 in there.
[03:48] <fabbione> well it has for now..
[03:48] <jbailey> But just in general.
[03:48] <fabbione> should we kill it?
[03:48] <fabbione> yeah
[03:48] <jbailey> We're not Debian, we don't drag corpses behind us chained to the bumper.
[03:49] <fabbione> ahah
[03:49] <fabbione> there are a few entries in debian/changelog marked as (requires testing) or (requires review)
[03:49] <fabbione> that's because i am not 100% of the reason why that stuff is there
[03:52] <jbailey> The only thing that I see in there off hand is that some of the changes done directly to control.in/{main,opt} might be best done in sysdeps/depflags.pl
[03:52] <jbailey> I *hate* sysdeps/depflags.pl
[03:52] <jbailey> That was about where I ran out of steam redoing the packages for Debian in 2003.
[03:53] <jbailey> What I think it should be is a tab delimited table or something like that which sits in control.in
[03:54] <jbailey> Maybe a few different files, conflicts, depends, etc.
[03:54] <jbailey> ARCH\tPACKAGE\tVERSION
[04:00] <fabbione> imho we could simplify the packaging a lot with a set of shell scripts
[04:01] <fabbione> or start eliminating tons of .mk stuff
[04:01] <jbailey> There's a surprising amount of this that *can't* be simplified once you start to look at what it does.
[04:01] <jbailey> But certainly half of rules.d/debhelper.mk can go.
[04:02] <jbailey> I thought quilt provided a rules snippet to include, so I'm not sure why we have our own.
[04:08] <doko_> the tarball approach can go again; it was for the binutils-source package, elmo did prefer to have patched sources in this patch, so we can revert that again.
[04:08] <doko_> but keeping the binutils-source package
[04:09] <jbailey> doko_: I've wondered a few times if it's better to use the upstream binutils releases or HJ Lu's snapshots, since his snapshots tend to include extra optimisation instructions and such.
[04:10] <jbailey> But are still sort of crack-of-the-moment.
[04:10] <jbailey> With his snapshots, we'dhave the HPPA TLS stuff already.
[04:10] <jbailey> Otherwise we'll have to backport them to get hppa working.
[04:13] <doko_> jbailey: yes, I was thinking about it as well. but then, how switch back to FSF binutils without having any regressions?
[04:14] <jbailey> Dunno.  I've never understood why the binutils release cycle is so slow.
[04:15] <jbailey> The changes that tend to go in there seem to be consistantly just opcode adds, etc.
[04:17] <doko_> if we can track these changes in a separate branch?
[04:18] <jbailey> I don't think we have the bodies on toolchain to do that sort of work.
[04:18] <jbailey> Since that drags the QA responsibility for those things onto us.
[04:18] <jbailey> I think it just wouldn't get done in the end.
[04:21] <fabbione> jbailey: i am getting a feisty amd64 chroot on ronne. the debs look good
[04:22] <fabbione> jbailey: at least debdiff did spot only 2 changes.. one i knew about but we don't care (it's ppc only) and the other one it's just an extra file that needs investigation
[04:34] <jbailey> We don't care about ppc anymore? =/
[04:35] <fabbione> it's already fixed in bzr.. i didn't feel restarting the builds for a ppc thingy
[04:35] <fabbione> but at least i know it is fixed properly
[04:39] <fabbione> dh_install: libc6-dev missing files (debian/tmp-libc/usr/lib/nptl*), aborting
[04:39] <fabbione> GRRRRRRRRRRRRRRR
[05:06] <jbailey> Right, debhelper 5 broke that construct, sadly.
[05:06] <jbailey> I pouted at Joey for it.
[05:06] <jbailey> foo* doesn't resolve to empty set in a glob anymore.
[05:08] <fabbione> i don't think we ship anything with that name anyway
[05:09] <fabbione> i386/ia64 did fail
[05:09] <fabbione> amd64 is rebuilding and waiting sparc/ppc
[05:10] <fabbione> we might as well chop it away if it's not required
[05:17] <fabbione> (feisty-libc)fabbione@ronne:/lib$
[05:17] <fabbione> well.. they seem to work on amd64 at least
[05:25] <jbailey> whee =)
[05:26] <fabbione> waiting for all the builds to complete.. then i will respin with that postinst fix and the nptl fix
[05:26] <fabbione> i am sure locales are broken
[05:27] <fabbione> because we need to port the patch for belocs and the other search path from 2.4
[05:27] <fabbione> but at least we know that we can run
[06:56] <Dvalin> fabbione: what gcc do you guys use to build kernel?
[06:56] <fabbione> gcc-4.1
[06:56] <Dvalin> okay
[06:56] <fabbione> Dvalin: doko is our gcc god here
[06:56] <Dvalin> yes
[06:56] <Dvalin> that's why I ask in here ;)
[06:57] <Dvalin> I have this weird issue
[06:57] <fabbione> yeah but you are building on *mandriva*
[06:57] <fabbione> you have issues.. no matter :
[06:57] <fabbione> :P
[06:57] <Dvalin> with the atyfb driver, I tried recompiling the same old kernel where it was working
[06:57] <Dvalin> with current toolchain, not what I compiled it at that time
[06:58] <fabbione> oh you are suspecting a gcc breakage?
[06:58] <Dvalin> otherwise everything being the same, and problem exist in the same kernel release which previously worked (even with the same config)
[06:58] <Dvalin> yes
[06:58] <fabbione> Dvalin: i suggest you try with -O0 and check the asm output
[06:59] <fabbione> in theory it should be the same
[06:59] <Dvalin> I'm thinking about trying to build with gcc 4.0.3 which I built last working kernel with..
[06:59] <Dvalin> fabbione: okay, good tip, for checking the asm output.. I think you overestimating me ;)
[06:59] <fabbione> Dvalin: nah.. that was a trick doko handed to me
[07:00] <Dvalin> checking the asm output? or -O0?
[07:00] <fabbione> asm output
[07:00] <fabbione> and -O0 ;)
[07:00] <fabbione> both
[07:01] <Dvalin> okay
[07:01] <Dvalin> I'm not competent at asm stuff.. ;p
[07:02] <Dvalin> but I did score 100% at a simple asm asisgnment at an exam last spring ;)
[07:02] <Dvalin> harrharr
[07:02] <Dvalin> I think that landed me the C in stead of E which otherwise would be the final grade :p
[07:03] <infinity> You don't need to write asm fluently to be able to compare it.
[07:03] <Dvalin> ah
[07:03] <infinity> (Thank god, too, because my i386 asm is less than perfect)
[07:03] <Dvalin> I see your point :)
[07:04] <infinity> Useless architectures, like m68k, powerpc, hppa, and sparc.  Sure, they're easy. :P
[07:04] <infinity> i386, not so much.
[07:05] <Dvalin> hehe
[07:05] <Dvalin> "useless"
[07:05] <Dvalin> quite a bombastic statement, no? ;)
[07:05] <infinity> Yes, that belonged in quotes.  I missed adding the irony. :)
[07:28] <jbailey> infinity: hppa can be annoyingly hard to read.  It appears to be able to unable to load 32 bits into a register in a single operation.
[07:29] <fabbione> jbailey: ia64 glibc are good
[07:29] <fabbione> if i could only get sparc to complete the testsuite without a kernel crash
[07:29] <fabbione> jbailey: i am uploading all the debs here: http://people.ubuntu.com/~fabbione/glibc-2.5/
[07:29] <jbailey> Joy.
[07:29] <fabbione> amd64 is good too
[07:29] <jbailey> Does it crash in a consistant place?
[07:29] <fabbione> i386 will test tomorrow
[07:29] <fabbione> it's a kernel problem..
[07:30] <fabbione> it lockups on high load
[07:30] <fabbione> i need to downgrade to edgy kernel
[07:30] <jbailey> Any idea if Ben is going to target 2.6.19 or 2.6.20 for fiesty?
[07:31] <fabbione> .19 afaik
[07:31] <fabbione> 9391 fabbione  21   0  5088  448  304 D  300  0.0   9:22.63 ld-linux.so.2
[07:31] <fabbione> now i have a process on 400 of CPU
[07:32] <jbailey> fabbione: Any idea when we're targetting to open the next one?
[07:32] <jbailey> I remember that edgy had some hitches, openning up.
[07:32] <fabbione> the kernel is already in git
[07:32] <fabbione> we need to get a few important things fixed
[07:32] <fabbione> like that headers issue i was mentioning
[07:32] <fabbione> otherwise we won't even be able to rebuild the kernel
[07:32] <jbailey> Headers issue?
[07:33] <fabbione> yes.. build .19
[07:33] <fabbione> install linux-libc-dev
[07:33] <fabbione> and you are doomed: )
[07:33] <fabbione> you can't even rebuild the kernel with that stuff
[07:33] <fabbione> it's totally broken
[07:33] <jbailey> Err.
[07:33] <fabbione> no.. this is worst
[07:33] <jbailey> Kernel builds with -nostdinc.
[07:33] <jbailey> Nothing in /usr/include should matter in the slighjtest.
[07:33] <fabbione> not the scripts/*
[07:33] <fabbione> and you need those
[07:34] <fabbione> like.. hmmmm modpost?
[07:34] <jbailey> I don't think I know about those.
[07:34] <fabbione> you use them all the time.. you just don't know that :)
[07:34] <jbailey> Can you toss a build failure into a pastebin?
[07:34] <fabbione> jbailey: sure.. in a minute
[07:34] <jbailey> No worries.
[07:35] <fabbione> no actually i can't.. i don't have the deb handy..
[07:35] <fabbione> but i can show it here by memory
[07:35] <fabbione> #include <errno.h>
[07:35] <fabbione> #include <sys/socket.h>
[07:35] <fabbione> int main() {
[07:35] <fabbione> return -EINVAL;
[07:36] <fabbione> return -SOL_SOCKET;
[07:36] <fabbione> }
[07:36] <fabbione> you can't build that one
[07:36] <jbailey> Right, but I'm curious about the actual failure.
[07:37] <fabbione> it's an include order issue
[07:37] <fabbione> either SOL_SOCKET or EINVAL is not defined
[07:37] <fabbione> if you swap the include's at the top, you get the other error
[07:37] <doko_> gcc-4.1_4.1.1-17ubuntu1 is on ronne:~doko/gcc/4.1/
[07:38] <fabbione> doko_: cool.. there is a feisty-libc chroot (amd64) on ronne
[07:38] <fabbione> doko_:
[07:38] <doko_> enabling long-double-128 on powerpc and sparc, configuring with --enable-secureplt on powerpc
[07:38] <fabbione> you can build there if you like
[07:38] <fabbione> it has glibc-2.5 installed
[07:38] <fabbione> doko_: i will do ia64/ppc/sparc/i386 tomorrow
[07:38] <fabbione> i am just too tired today to do it
[07:38] <fabbione> actually.. i could do ia64 overnight
[07:39] <fabbione> ii  libc6.1        2.5-0ubuntu1   GNU C Library: Shared libraries
[07:41] <jbailey> doko_: Do you happen to know what binutils FC6 is shipping with?  I remember that they have the GNU HASH lookups for the PLT stuff as one of their features.
[07:41] <jbailey> But I think that requires a new binutils snapshot.
[07:42] <doko_> http://cvs.fedora.redhat.com/viewcvs/devel/binutils/
[07:42] <doko_> 2.17.50
[07:43] <doko_> <IP_ADDRESS>.6, the version number smells like beeing the HJ stuff ...
[07:44] <fabbione> doko_: gcc-4.1 building on ia64
[07:44] <fabbione> doko_: do you want to ask B-D on feisty-libc chroot or should I? i can do the others locally
[07:45] <doko_> they were installed
[07:45] <doko_> currently building on feisty
[07:45] <fabbione> hmm ok
[07:45] <fabbione> good
[08:15] <jbailey> Hmm, here's going to be an interesting question.
[08:15] <jbailey> Some of the libc tests probably need corresponding kernel functions to pass.
[08:15] <fabbione> jbailey: ?
[08:15] <jbailey> What do the buildds run for a kernel>
[08:15] <fabbione> oh yes.. i already noticed that
[08:16] <fabbione> 2.6.17 basically everywhere
[08:16] <fabbione> i saw a bunch of test failures
[08:16] <fabbione> but i didn't track them down yet
[08:16] <fabbione> and i don't think for bootstrapping we care too much
[08:16] <jbailey> If you toss those into a pastebin somewhere, I might be able to offer you opinions on them.
[08:17] <fabbione> jbailey: ronne:/home/fabbione/{i386,amd64}/
[08:17] <fabbione> ppc is on davis
[08:17] <fabbione> i can upload sparc and ia64 later
[08:18] <fabbione> davis is still building FYI
[08:19] <fabbione> oh acutally i did build ia64 with .19
[08:20] <jbailey> make[3] : bug-atexit3-lib.cc: Command not found
[08:20] <jbailey> make[3] : *** [/home/fabbione/i386/glibc-2.5/build-tree/i386-i686/dlfcn/bug-atexi
[08:20] <jbailey> t3-lib.os]  Error 127
[08:20] <jbailey> Eh, weird.
[08:20] <jbailey> Oh, no G++ installed.
[08:21] <fabbione> scp glibc-2.5.tar.bz2 chinstrap.ubuntu.com:glibc-2.5-ia64-log.tar.bz2
[08:22] <fabbione> jbailey: uh? i did use dpkg-buildpackage.. do we miss a B-D ?
[08:23] <jbailey> checking for g++... g++
[08:23] <fabbione> hmmm
[08:24] <fabbione> i readded the CXX patch from you...
[08:24] <fabbione> could that be related?
[08:24] <jbailey><PHONE_NUMBER><PHONE_NUMBER>
[08:24] <jbailey> ls
[08:24] <jbailey> BAH
[08:24] <fabbione> 0wn3d
[08:29] <Dvalin> mm/filemap.c: In function ?__generic_file_aio_write_nolock?:
[08:29] <Dvalin> mm/filemap.c:1830: sorry, unimplemented: inlining failed in call to ?generic_write_checks?: function body not available
[08:30] <Dvalin> mm/filemap.c:2133: sorry, unimplemented: called from here
[08:30] <Dvalin> fabbione: are you sure you actually can compile the kernel with -O0?
[08:30] <fabbione> Dvalin: i am pretty sure you can
[08:31] <Dvalin> hmm
[08:31] <Dvalin> then I don't get why I get that error when compiling with -O0
[08:31] <Dvalin> will try again with -O2 to see if it reproduces
[08:31] <fabbione> i usually compile only the bits i need with -O0
[08:31] <Dvalin> okay
[08:32] <Dvalin> so in other words, you don't know for sure that the *whole* kernel can be compiled with -O0?
[08:32] <fabbione> no but it should be able to
[08:32] <Dvalin> soo
[08:32] <Dvalin> the error I got, a bug in kernel?
[08:34] <fabbione> or gcc
[08:35] <fabbione> it really depends what you are experimenting with
[08:35] <jbailey> fabbione: It's entirely possibly that the kernel relies on optimiser tricks for correct code.
[08:35] <jbailey> You can't compile glibc at -O0 for instance.
[08:35] <fabbione> you are working on both at the same times so that makes it impossible to track easily
[08:35] <Dvalin> fabbione: I got the same error with the "old" compiler
[08:35] <fabbione> jbailey: it's a possibility..
[08:35] <Dvalin> I reverted back to last known good compiler
[08:35] <Dvalin> 4.0.3
[08:36] <Dvalin> which I'm using now
[08:40] <jbailey> fabbione: You didn't use debuild to build this?
[08:40] <fabbione> dpkg-buildpackage -rfakeroot -uc -us -b
[08:40] <fabbione> as i always do
[08:41] <jbailey> debuild actually logs the whole build (as well as cleans some pieces of the environment)
[08:41] <jbailey> So just "debuild -uc -us -b" is the equivalent.
[08:41] <fabbione> hmm ok
[08:42] <fabbione> we still shouldn't really on debuild.. it should just work...
[08:43] <fabbione> if we need to sanitize the ENV that should happen in debian/rules
[08:43] <jbailey> eh, what do you mean?
[08:43] <fabbione> sbuild doesn't call debuild or dpkg-buildpackage
[08:43] <jbailey> No - sometimes I set external environment varilables to change what's happening intentionally.
[08:43] <fabbione> ok.. those are well defined things to trigger certain behavious
[08:43] <jbailey> Sucks to be sbuild.  If the buildds don't use what all the developpers use then I consider the buildd broken.
[08:43] <fabbione> but i don't set anything in my env other than ccache
[08:44] <jbailey> Right, I don't know that it's a problem or not.  Just that debuild is handy for that.
[08:44] <jbailey> Mostly what I'm wishing for is the .build file.
[08:44] <jbailey> The logs that the glibc build produces on its own start logging too late.
[08:44] <fabbione> jbailey: actually.. no.. i disagree.. according to policy you should be able to call ./debian/rules $target and it should work.   But I was asking that you consider using debuild since it just always produces a log file.
[08:48] <fabbione> i will try.. i need to get used to type it :)
[08:48] <fabbione> oh  my wife made dinner!
[08:48] <fabbione> bbl
[08:48] <jbailey> enjoy! =)
[08:48] <fabbione> thanks
[08:48] <jbailey> bah!  no source package! =)
[08:55] <jbailey> echo "CXX = "   >> build-tree/i386-libc/configparms
[08:55] <jbailey> that would be the bug. =)
[08:57] <jbailey> Need s BUILD_CXX line in debian/rules
[08:57] <jbailey> Although more I wonder how much we care about the cross-compilation case.
[08:58] <jbailey> echo "CXX = g++-4.1 -fno-stack-protector"       >> build-tree/i386-libc/configpa
[08:58] <jbailey> Better.
[08:58] <jbailey> doko_: Any idea if upstream gcc is going to integrate cleanly an option to enable the stack-protector by default?
[08:59] <fabbione> jbailey: yes.. in ~fabbione/
[09:00] <jbailey> fabbione: All good.  cp -a was my bitch. =)
[09:00] <fabbione> jbailey: so are you going to commit the fix?
[09:00] <jbailey> After I see a succesful test suite on i386, yes. =)
[09:01] <fabbione> jbailey: also note that the patch pristine from 2.4.. so it have been buggy in edgy too?
[09:02] <jbailey> I don't think these two tests existed in 2.4.
[09:02] <fabbione> ok
[09:02] <jbailey> So the only thing would've been the C++ abi test, we I never paid attention to anyway.
[09:02] <fabbione> see.. as i said.. harmless errors in the logs
[09:02] <fabbione> you should have trust me before :P
[09:03] <jbailey> I didn't say I didn't trust you.  =)  I merely offered my opinion.
[09:03] <jbailey> "wow, this is broken.  Here's the fix."  Easy opinions like that. =)
[09:04] <fabbione> ahah
[09:04] <fabbione> yeah yeah
[09:04] <jbailey> fabbione: There've got to be *some* advantages of staring at this package for 6 years. =)
[09:05] <fabbione> jbailey: like an extra discount for the super-pack offer from your shrink?
[09:05] <jbailey> Doesn't help much after the surcharge.
[09:05] <fabbione> 10 hours at the price of 8
[09:06] <jbailey> Something about my reality check bouncing...
[09:06] <fabbione> and if you are a glibc maintianer 10 hours at the price of 6!
[09:06] <fabbione> ehhe
[09:07] <doko_> jbailey: no idea ...
[09:10] <fabbione> doko_: you want to look at debian bug #391858
[09:10] <fabbione> doko_: it's not a glibc bug, but gcc.. the same we fixed in ubuntu not too long ago
[09:10] <fabbione> their fix is just wrong
[09:10] <fabbione> and they don't take into account other arches like sparc
[09:10] <fabbione> that does the same thing
[09:24] <doko_> Tags: experimental, fixed-in-experimental
[09:25] <fabbione> yes but still in glibc
[09:25] <fabbione> and you are the gcc maintainer so you might want to explain to them that it is wrong
[09:28] <doko_> fabbione: fixed-in-experimental, they did fix it already ;-p
[09:29] <fabbione> doko_: yes i know.. whatever.. our gcc is fine and will cope..
[09:30] <fabbione> jbailey: the ppc build seems to hang on a test suite
[09:30] <fabbione> i have a bunch of processes in Z on davis
[09:31] <jbailey> Joy.
[09:32] <fabbione> this is the second timei see this
[09:32] <fabbione> in the same build
[09:33] <fabbione> the first time did "unblock" itself
[09:37] <jbailey> fabbione: Can you tell which test?
[09:37] <fabbione> x/regex.h posix/wordexp.h posix/fnmatch.h posix/getopt.h posix/tar.h posix/sys/unistd.h posix/sched.h posix/re_comp.h posix/wait.h posix/cpio.h posix/spawn.h pwd/pwd.h resolv/resolv.h resolv/netdb.h resolv/arpa/nameser.h resolv/arpa/nameser_compat.h resource/sys/resource.h resource/sys/vlimit.h resource/sys/vtimes.h resource/ulimit.h rt/aio.h rt/mqueue.h setjmp/setjmp.h shadow/shadow.h signal/signal.h signal/sys/signal.h socket/sys/soc
[09:37] <fabbione> ket.h socket/sys/un.h stdio-common/printf.h stdio-common/stdio_ext.h stdlib/stdlib.h stdlib/alloca.h stdlib/monetary.h stdlib/fmtmsg.h stdlib/ucontext.h sysdeps/generic/inttypes.h sysdeps/generic/stdint.h stdlib/errno.h stdlib/sys/errno.h string/string.h string/strings.h string/memory.h string/endian.h string/argz.h string/envz.h string/byteswap.h sunrpc/rpc/auth.h sunrpc/rpc/auth_des.h sunrpc/rpc/auth_unix.h sunrpc/rpc/clnt.h sunrpc/r
[09:37] <fabbione> pc/des_crypt.h sunrpc/rpc/key_prot.h sunrpc/rpc/netdb.h sunrpc/rpc/pmap_clnt.h sunrpc/rpc/pmap_prot.h sunrpc/rpc/pmap_rmt.h sunrpc/rpc/rpc.h sunrpc/rpc/rpc_des.h sunrpc/rpc/rpc_msg.h sunrpc/rpc/svc.h sunrpc/rpc/svc_auth.h sunrpc/rpc/types.h sunrpc/rpc/xdr.h sunrpc/rpcsvc/bootparam.h sysvipc/sys/ipc.h sysvipc/sys/msg.h sysvipc/sys/sem.h sysvipc/sys/shm.h termios/termios.h termios/sys/termios.h termios/sys/ttychars.h time/time.h time/sys
[09:37] <fabbione> /time.h time/sys/timeb.h wcsmbs/wchar.h wctype/wctype.h > /home/fabbione/glibc-2.5/build-tree/powerpc-libc/begin-end-check.out
[09:37] <fabbione> this is all i can get
[09:38] <fabbione> or you need to remind me how to scroll back in screen
[09:40] <jbailey> C-a {
[09:40] <jbailey> err
[09:40] <jbailey> C-a [
[09:41] <jbailey> but I don't remember what begin-end-check.out is.
[09:41] <jbailey> I can look in my i386 build logs.
[09:41] <jbailey> Meh, they haven't started the test suite yet.
[09:42] <jbailey> I'm fighting doko for CPU time on ronne. =)
[09:43] <fabbione> jbailey: if we really need a running .17 to build glibc we need to talk to elmo for the buildd
[09:44] <jbailey> Shouldn't need it on ppc.
[09:44] <jbailey> Will certainly need it on parisc.
[09:45] <fabbione> what about i386/amd64/sparc?
[09:45] <fabbione> and ia64?
[09:45] <jbailey> Mainstream arches should all be fine.
[09:46] <fabbione> ok
[09:46] <jbailey> Have to check with Dave on sparc to be certain.
[09:46] <jbailey> But since their nptl port worked fine, I wouldn't expect that to change.
[09:46] <fabbione> no..
[09:46] <jbailey> The rest of the arches all had corporate funding for their ports, so they got done early.
[09:47] <fabbione> ok.. i killed the build on ppc.. waiting Znarl to kill some Zl processes leftover
[09:47] <fabbione> and restart with debuild
[09:50] <fabbione> jbailey: ppc will wait tomorrow
[09:51] <fabbione> i need to get some sleep
[09:52] <jbailey> fabbione: g'n! =)
[09:52] <fabbione> night
[09:53] <Dvalin> seems like I was right
[09:53] <Dvalin> building kernel with old gcc
[09:53] <Dvalin> made it work


[15:59]  * slangasek waves
[16:00] <mdeslaur> hi!
[16:00] <pitti> \o
[16:01] <slangasek> #startmeeting
[16:01] <meetingology> Meeting started Tue Jul  7 16:01:19 2015 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:01] <meetingology> Available commands: action commands idea info link nick
[16:01] <slangasek> [TOPIC] Apologies
[16:01] <slangasek> no apologies sent on the list
[16:01] <slangasek> kees, infinity appear to be absent
[16:02] <slangasek> but we nevertheless have a quorum, so carrying on :)
[16:02] <slangasek> [TOPIC] Action review
[16:02] <slangasek> ACTION: slangasek to forward complaint to Canonical legal
[16:02] <slangasek> carried over, again
[16:02] <slangasek> again, if anyone felt strongly about stealing this from me I wouldn't stand in their way, otherwise I'll keep it on my todo
[16:03] <pitti> FTR, stgraber is on holidays?
[16:03] <stgraber> no I'm not :)
[16:04] <mdeslaur> he just wishes :)
[16:04] <stgraber> :)
[16:04] <slangasek> nope, we're all still working, no matter how much our brains are overheating in this weather ;)
[16:05] <slangasek> [TOPIC] Mailing list archive
[16:05] <slangasek> there was a mail from apw this morning, which I just saw in the queue and approved through
[16:05] <slangasek> I'm guessing most people haven't read it yet
[16:05] <pitti> ah, I already wondered
[16:05] <slangasek> Subject: Ubuntu Fan Updates for Trusty and Vivid
[16:05] <pitti> I quickly read through it, but I'm not entirely sure about the impact yet
[16:06] <mdeslaur> I skimmed it, but I'd have to look at the patch to form an opinion
[16:06] <slangasek> for those who don't know, Ubuntu Fan is a clever stateless network multiplexer
[16:06] <slangasek> it's a useful feature to have on cloud instances running containers
[16:06] <slangasek> apw had approached me and asked me if it was SRUable
[16:06] <pitti> it sounds similar to IPv4LL and NAT, and all the other crazy things people do to avoid IPv6 :)
[16:07] <slangasek> and I expressed concern that this doesn't really fit our existing SRU policy, so should be discussed at a higher level
[16:07] <pitti> but AFAIUI this is mostly a new feature, ignoring some undocumented preview that was already in the trusty kernel
[16:07] <slangasek> vivid kernel
[16:07] <pitti> i. e. the regression potential is that someone made use of that in trusty, and it's going to change/break?
[16:07] <pitti> ah
[16:07] <pitti> so for trusty this is entirely new
[16:07] <slangasek> yes, the risk of regression potential is fairly low because it's a new feature
[16:08] <stgraber> my main concern is the changes to iproute2 and other core bits to support the feature
[16:08] <mdeslaur> is this upstream yet? what are the odds that it gets changed in an incompatible way while going upstream?
[16:08] <slangasek> however, the SRU policy has always been rather clear that new features don't belong in SRUs - with the exception of hardware enablement
[16:08] <pitti> yeah, that's my main gripe with it -- there's no indication of whether this has ever been reviewed by kernel developers, or proposed for inclusion
[16:08] <slangasek> we've moved the line a few times wrt hardware enablement, to accomodate cloud substrate requirements
[16:09] <stgraber> so last I heard, it's not upstream and we're not actively pushing for it to be upstreamed in its current shape, it also uses kernel identifiers for the tunnel type which may potentially be used by another in-kernel tunneling technology at some point, causing a clash
[16:09] <slangasek> but I don't think I can justify this under the current SRU policy, so I think there's a higher-level policy discussion to be had rather than just making exceptions
[16:09] <pitti> (wrt. security/quality review, and general sanity)
[16:10] <pitti> so while from a regresssion potential POV this seems manageable (assuming that iproute2 only gets new features, and no changed behaviour)
[16:10] <stgraber> so basically from my point of view: 1) ubuntu-fan package itself is fine and safe 2) changes to iproute2 may be risky 3) in-kernel non-upstream tunnel technology when needing unique IDs for netlink is a risk too
[16:10] <pitti> it feels like exposing millions of LTS users with a brand new and largely unreviewed kernel feature that will be exposed to the network is a bit premature
[16:11] <slangasek> so, I'd appreciate it if we could separate our SRU team hats from our TB hats here, difficult as that is :)
[16:11] <pitti> sure; this is all TB anyway, as it's clearly outside of SRU policy
[16:12] <slangasek> when I asked apw to refer it to the TB, it wasn't because I wanted the TB to analyze the risks of this specific SRU
[16:12] <slangasek> but to discuss whether the SRU policy should, or should not, allow for updates such as this
[16:12] <stgraber> ah, simple answer then, it shouldn't
[16:12] <pitti> personally I would never like to give out a blanket permit for things like this
[16:13] <slangasek> pitti: well, I have the opposite response: that we shouldn't give /exceptions/ for things like this :)
[16:13] <pitti> even with this concrete case I have some serious concerns, I don't see how to allow even more general cases
[16:13] <stgraber> backporting of a new major feature into a LTS release is very clearly out of scope for the normal SRU process and as it's not something I want to see abused, I don't believe it makes sense to have the SRU policy allow this
[16:14] <pitti> slangasek: that'ss a good point from the POV that general written-down policy is better than arbitrary exceptions that are handed to whoever shouts the loudest
[16:14] <slangasek> if it's justifiable in the specific case (which it may not be), I think that we should address that in the SRU policy.  The SRU policy currently says we don't allow new features in, this is a new feature: is the policy wrong, or is the SRU proposal one we should reject
[16:16] <slangasek> so I'd say that taking the pulse here suggests that we don't want this SRU
[16:16] <pitti> hm, so we could imagine how the fan proposal would have to look like in order for us to consider it acceptable
[16:16] <stgraber> do we really need to update the SRU policy to say that the TB can overule? to me it seems like its stating the obvious...
[16:16] <pitti> and then generalize that?
[16:16] <slangasek> shall we follow up on the mailing list?
[16:16] <slangasek> stgraber: uh?  I'm in no way talking about codifying "the TB can overrule"
[16:17] <mdeslaur> There is a lot of potential for abuse in letting new features in. Is having the power to rule on new features something the SRU team in interested in?
[16:18] <slangasek> speaking only for myself as an SRU team member: no
[16:18] <pitti> with my former SRU hat on: I wouldn't be
[16:18] <slangasek> because having the power to rule on it means we'll be constantly asked to rule on it
[16:18] <stgraber> so my point of view, is keep the SRU policy as is, no new features and have the SRU team reject anything that's a new feature. None of that prevents escalation through the TB for a specific exception as seems to be the case here.
[16:19] <pitti> processing SRUs is enough work without having to argue about new features all the time
[16:19] <pitti> I'd actually be okay with new features in LTSes under reasonable circumstances; we do it all the time already, after all
[16:19] <pitti> (new landscape or maas versions, etc.)
[16:19] <slangasek> stgraber: I would not be happy with the TB ever signing off on a specific exception to the new feature rule without being able to articulate a general principle
[16:20] <pitti> but they should have a reasonably low potential for introducing new bugs and security holes, which this particular proposal totally fails at
[16:20] <pitti> right -- e. g. for the HW enablement we have a generic justification in the policy
[16:21] <pitti> so if/once we agree to this particular proposal, we could then generalize it and see on which grounds we accept it
[16:22] <slangasek> fwiw my risk analysis of this particular SRU differs from yours - it's already in the vivid kernel, the vivid kernel will land in trusty as part of the hwe process, new kernels have a huge attack surface anyway for security holes and we have a kernel update cadence to deal with that
[16:23] <stgraber> yeah, the kernel side isn't a big concern of mine because we don't force those on our existing users
[16:23] <slangasek> I also think the SRU process is adequate for dealing with the risks of regression, and doesn't need direct TB involvement
[16:23] <stgraber> iproute2 however is a bit more problematic
[16:24] <slangasek> anyway, so far I'm hearing a pretty firm "no" - so I think the next steps are to take that back to the mailing list?
[16:24] <pitti> well, we wouldn't push/force it into trusty unless we were planning to actually use that feature, no?
[16:24] <pitti> i. e. in some cloud workload via iproute2?
[16:25] <stgraber> well, the feature can be used by anyone, cloud or not, it just shows up as a bridge that you can use with docker, lxc, lxd, ...
[16:25] <pitti> right, the normal kernel backporting process kind of gets us that through the backdoor, but it would be inert without userspace changes
[16:25] <pitti> so it's much less adding the new kernel feature, but rather making use of that by our default tools
[16:25] <stgraber> right, you need the ubuntu-fan package and tools to talk to iproute2 to talk to the new kernel netlink interface
[16:26] <slangasek> but it's also not as if this is going to be activated on existing systems automatically; someone has to invoke it to make use of it
[16:26] <pitti> in general I don't want to respond to these kinds of requests with a plain "no" (as there's usually a good use case behind it), but more with a "how"
[16:26] <pitti> slangasek: it's not? that's not at all clear to me
[16:27] <stgraber> yeah, as I said, I'm not too concerned about the kernel side of it. What I'm concerned with is modifying iproute2
[16:27] <stgraber> because if iproute2 breaks somehow, that means no network on the affected machine and that's kinda bad
[16:27] <mdeslaur> part of the issue here is this seems to be an ubuntu-specific feature
[16:27] <pitti> slangasek: it's very easy to accidentally or deliberately enable it on upgrades
[16:27] <slangasek> pitti: it certainly is not, it's a completely new bridge type
[16:27] <mdeslaur> it's not as if it's a backport of something present in a new version
[16:29] <slangasek> mdeslaur: it's a backport of something present in a new version of the package in Ubuntu.  I'm not sure from a policy perspective (as opposed to a risk analysis perspective) that we should distinguish between Ubuntu-specific vs. not
[16:29] <pitti> right, "ubuntu specific" doesn't belong into SRU policy, that should be general development policy
[16:29] <pitti> (FWIW, I really don't like having this in vivid either)
[16:30] <mdeslaur> slangasek: policy no, but it certainly has an impact on the risk. Even more so if there actually are plans to get it upstream and that turns into a compatibility nightmare for users.
[16:31] <pitti> so assuming it *was* a properly reviewed feature in vivid's kernel, I wouldn't have a problem with letting this migrate to trusty as well via the normal backport process
[16:31] <pitti> the "change userspace to make use of it" is what I'd like to understand more, as right now it sounds awfully dangerous
[16:32] <pitti> so the "how to make this palatable" would include an upstream review, plus a more detailled description of the current and planned userspace changes to iproute and other tools, and a regression potential analysis
[16:33] <pitti> all of which is really unrelated to SRUing this to trusty, but should retroactively be done for vivid too
[16:34] <slangasek> all of that still doesn't pass the SRU policy as it stands, and only supports making an exception?
[16:35] <slangasek> I'm against making an exception
[16:35] <pitti> as for the SRU policy, I think we can make an amendment for backporting features from stable releases to LTSes which have a negligible regression potential
[16:35] <pitti> it shoudl still be ack'ed individually IMHO, but it would be a guideline what the TB would look at
[16:36] <pitti> (TBH I have a bigger problem with the feature itself than with backporting it)
[16:38] <slangasek> ok; so you think that at least potentially this is something that we would want codified in the SRU policy as allowable
[16:38] <pitti> yes, I do
[16:38] <mdeslaur> pitti: acked by who, the SRU team or the tech board?
[16:38] <pitti> pitti | hm, so we could imagine how the fan proposal would have to look like in order for us to consider it acceptable
[16:38] <pitti> pitti | and then generalize that?
[16:38] <slangasek> I agree, though I'm not yet sure what shape it should take
[16:39] <pitti> mdeslaur: my feeling is "TB" at least initially
[16:39] <mdeslaur> ok
[16:39] <slangasek> but I think we're racking up exceptions at this point (maas, juju, proposal for fan) and we should consider whether the current SRU rules are still meeting their purpose
[16:39] <pitti> this shouldn't be a "toss over the fence" kind of thing, but similar to preliminary MREs
[16:40] <pitti> slangasek: right, that's a good point; now that we do have a lot of MREs we have some experience when we allowed them
[16:40] <slangasek> not just MREs :)
[16:40] <pitti> and most of the time the "interview" looked fairly similar: automatic/manual test plans and QA procedures, how to ensure that upgrades don't break, regression potential analysis
[16:41] <slangasek> [ACTION] slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases
[16:41] <meetingology> ACTION: slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases
[16:41] <pitti> slangasek: juju is on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[16:42] <slangasek> pitti: yes, but it's not actually an MRE so I'm going to move it :)
[16:42] <pitti> maas was proposed, but never got signed off because the interview wasn't finished
[16:42] <pitti> slangasek: ack
[16:42] <pitti> slangasek: I'm happy to look at our existing MacroReleaseExceptions and come up with a proposal for a policy amendment for next time
[16:43] <slangasek> so - next steps?  should we evolve this on the mailing list?
[16:43] <pitti> as I usually responded to the bulk of MRE requests on the ML anyway
[16:43] <pitti> I think there's two steps:
[16:43] <pitti> 1) amend the policy for new features in LTS (as that's clearly a direction we've gone in in the past years)
[16:44] <pitti> 2) respond to that concrete case with our gripes and request for more information about them
[16:44] <slangasek> pitti: do you want to drive #1?
[16:44] <pitti> slangasek: yes
[16:44] <mdeslaur> pitti: that sounds reasonable
[16:44] <slangasek> [ACTION] pitti to propose amendment to general SRU policy for new features in LTS
[16:44] <meetingology> ACTION: pitti to propose amendment to general SRU policy for new features in LTS
[16:45] <slangasek> [ACTION] all to respond to the Ubuntu Fan SRU proposal on list
[16:45] <meetingology> ACTION: all to respond to the Ubuntu Fan SRU proposal on list
[16:46] <slangasek> [TOPIC] community bugs
[16:46] <slangasek> https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard
[16:46] <slangasek> empty
[16:46] <slangasek> [TOPIC] Select a chair for the next meeting
[16:46] <slangasek> I believe that's stgraber, with infinity as backup, yes?
[16:47] <stgraber> yep
[16:47] <slangasek> [INFO] Next meeting 2015-07-21, 17:00 London time.  Chair: stgraber (next: infinity)
[16:48] <slangasek> anything else that I've missed?
[16:49] <pitti> nice to have a "real" meeting for a change :)
[16:49] <mdeslaur> hehe, yes :)
[16:49] <pitti> nothing else from me
[16:49] <slangasek> :)
[16:49] <slangasek> #endmeeting
[16:49] <meetingology> Meeting ended Tue Jul  7 16:49:58 2015 UTC.
[16:49] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.2015-07-07-16.01.moin.txt
[16:50] <slangasek> thanks, all!
[16:50] <mdeslaur> thanks slangasek, thanks all
[16:50] <pitti> thanks everyone
[16:50] <stgraber> thanks
[16:50] <pitti> et bonne nuit !
[16:51] <stgraber> :)


[00:19] <Jay2k1> hey there, i just upgraded from 0.23.1 on 9.04 to 0.24 on 10.10 (fresh install + db restore)
[00:19] <Jay2k1> now my remote doesn't work as suspected
[00:20] <Jay2k1> the installer asked me for my remote, i said it's a hauppauge nova-t 500
[00:20] <Jay2k1> i copied my old lirc config files over to the new installation
[00:20] <Jay2k1> now, when lirc runs, every button press is recognised twice
[00:21] <Jay2k1> but the weirdest part is, when i stop lirc, the remote still works
[00:24] <Jay2k1> a few buttons do not work though, that was the reason i tried my old configs, but i just can't understand how the remote can work if there is no running lirc instance
[00:30] <mrand> Jay2k1: the kernel in 10.10 supports remotes
[00:30] <mrand> for the most part, anyway ;-)
[00:30] <Jay2k1> yeah just found out
[00:30] <Jay2k1> arrows and such
[00:30] <Jay2k1> but not "back/exit" apparently... what a pita
[00:31] <Jay2k1> looking through `ps` over and over and not finding anything IR related...
[00:31] <mrand> I have not had time to dig into it myself to see what works and doesn't work on my remotes.  You can disable the in-kernel support if it isn't working right for you
[00:31] <Jay2k1> i'd love to do that
[00:37] <Jay2k1> you know how? :S
[00:43] <mrand> Jay2k1: I've not done it myself, but I think you blacklist mceusb, describe in option 2 here: http://ubuntuforums.org/showthread.php?p=9984844#post9984844
[00:43] <Zinn> [ubuntuforums.org] [SOLVED] Issues with Generic Mceusb receiver after upgrade to 10.10 - Ubuntu Forums
[00:53] <Jay2k1> well, the thing is, it's not mceusb since it's a hauppauge remote, not media center, so i don't know what module it is... but i suspect it's "ir_common", gonna test that
[01:03] <mrand> /var/log/messages (or dmesg) may tell you
[01:03] <mrand> bbl


[07:05] <ara> morning :-)
[07:34] <jpds> Good morning ara
[07:34] <ara> morning jpds
[08:31] <davmor2> Morning everyone.... How's things?
[08:49] <schwuk> Morning
[09:51] <davmor2> morning nand
[09:51] <nand> davmor2: mooorning!
[10:19] <davmor2> schwuk: you about?
[10:47] <schwuk> davmor2: yup
[13:01] <vadi2> Hi, I have a test case where I upgraded from 8.04 to 8.10 and Ubuntu's GDM got broken. I reported a bug, but nobody's replied for several days now, and I don't know what to do - the laptop is hosed, it can't do anything. But if I try to reinstall / install again, won't I be later asked to provide more info on the bug etc?
[13:08] <persia> vadi2: Which bug?
[13:08] <vadi2> https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/256452
[13:09] <persia> vadi2: Join me in #ubuntu-bugs, and let's see if we can get this bug triaged (I don't know much about GDM)
[13:14] <persia> vadi2: As you see, that's often the best way if you need to reformat or reinstall :)
[13:15] <vadi2> Okay thanks, I'll go there directly in the future
[13:15] <persia> Don't use it for every test bug (or people may stop listening), but it's good for test cases, etc. where you don't know what information you need to include.
[13:16] <vadi2> Will do
[14:18] <asac> hi
[14:18] <asac> daily liveCDs?
[14:18] <asac> currently usable? which link should I include in NM announcement?
[14:22] <davmor2> asac: is this the nm announcement that has gone out twice?
[14:22] <asac> davmor2: right ;)
[14:23] <asac> i dont know why my blog duplicated the entry
[14:23] <asac> i removed the second psot and hope that planet.ubuntu notices this
[14:23] <davmor2> http://cdimages.ubuntu.com/daily-live/20080811/
[14:23] <davmor2> and then choose the 32bit or 64 bit cd
[14:23] <asac> davmor2: ok. is NM 0.7 on those already?
[14:24] <davmor2> I'm about to test that it works on a standard install.
[14:24] <asac> it entered the archive on thursday... so i guess yes?
[14:24] <davmor2> 2 secs I'll tell you
[14:24] <asac> thx
[14:25] <asac> davmor2: is there no link to "latest-daily" ?
[14:25] <davmor2> asac: there is
[14:26] <asac> anyway. i think ill just post the top level dir
[14:26] <asac> e.g. http://cdimages.ubuntu.com/daily-live/
[14:26] <davmor2> you can just link to the current folder but it is always going to be a day behind in reality
[14:27] <asac> davmor2: ok. let me know if NM is on that disc please ;)
[14:27] <asac> then i'll hit "save/send"
[14:28] <davmor2> booting now
[14:33] <davmor2> asac: hang on issue with live I'll ping you in a second
[14:35] <davmor2> that's okay seems to be working this time.  Phew
[14:36] <davmor2> asac: 20080811 has indeed got NM applet 0.7.0
[14:38] <davmor2> is there anything else you need asac?
[14:40] <asac> davmor2: good
[14:40] <asac> and the network-manager package likewise i guess?
[14:42] <asac> davmor2: ?
[14:43] <davmor2> asac: everything with network-manager in is 0.7~~svn something
[14:43] <asac> ok great
[14:43] <davmor2> np's
[14:48] <stgraber> asac: hmm, is it known that nm0.7 doesn't use /etc/dhcp3/dhclient.conf ?
[14:48] <stgraber> it breaks my setup here as I need to set some flags to get the right IP and force the domain name
[14:49] <asac> stgraber: i think its known ... though it just runs dhclient
[14:49] <asac> stgraber: please file a bug ;)
[14:49] <asac> (with 0.7 in the summary so i can better filter them out)
[14:49] <stgraber> asac: it uses dhclient but not /etc/dhcp3/dhclient.conf
[14:50] <stgraber> /sbin/dhclient -d -sf /usr/lib/NetworkManager/nm-dhcp-client.action -pf /var/run/dhclient-eth0.pid -lf /var/run/dhclient-eth0.lease -cf /var/run/nm-dhclient-eth0.conf eth0
[14:50] <stgraber> it uses -cf /var/run/nm-dhclient-eth0.conf instead :(
[14:50] <stgraber> ok, will file a bug
[14:50] <asac> whats in the /var/run conf?
[14:57] <persia> Note that /var/run isn't guaranteed across reboots: the source configuration is likely somewhere else.
[14:58] <persia> Err, actually, specificially /var/run is guaranteed *not* to be stored across reboots.
[16:35] <stgraber> asac: nm-dhclient-eth0.conf is empty
[16:35] <stgraber> asac: I'll file a bug report in an hour or so (when I have time)
[16:36] <davmor2> stgraber: can you quickly confirm bug 256989
[16:38] <stgraber> sure, looking at it
[16:39] <stgraber> oh, you have it on standard hardware too ?
[16:39] <stgraber> I thought it was a VM only one
[16:40] <davmor2> no
[16:40] <davmor2> two different sets of hw too
[16:42] <asac> stgraber: maybe try the latest from ~network-manager PPA
[16:42] <asac> its a mroe recent snapshot and probably has a bunch of bugs fixed
[16:42] <stgraber> ok, confirmed
[16:44] <stgraber> ok, will give it a try later
[16:50] <asac> cool
[16:58] <davmor2> asac: I don't have 3g so can't check :(
[17:02] <asac> davmor2: you can check other connectivity things
[17:03] <davmor2> they seem alright 0.7.0 has been in for a few days and I've been smoke testing daily
[17:03] <asac> like: static ip, dhcp with manual nameserver, dhcp,
[17:03] <asac> wireless
[17:03] <asac> and system-settings
[17:03] <asac> (which should work without applet)
[17:06] <davmor2> asac: not wireless I got to use ndis for mine and it's not connecting up at the moment but that could be an issue with ndis but wired works fine
[17:09] <davmor2> I can try a live cd in my wifes Ubuntu/dell and see it that works :)
[17:14] <davmor2> stgraber: can you also try an oem install of Kubuntu and see if it works fine till you restart for end user?
[17:14] <davmor2> bug 251634
[17:14] <davmor2> bot is dead :(
[17:16] <jpds> No, I don't think I set it to look up bug things.
[17:19] <jpds> ubot5: bug 251634
[17:34] <davmor2> shame that was a useful feature :)
[17:40] <jpds> It just needs to be properly configured.
[21:12] <davmor2> stgraber: ping
[21:25] <pitti> hi
[21:25] <davmor2> hello :)
[21:25] <pitti> did anyone happen to test today's desktop CDs? They just hang for me on starting X, but I haven't done any debugging yet
[21:25] <davmor2> pitti on live?
[21:25] <pitti> yes
[21:26] <davmor2> It happened once so I rebooted every time I tried after that it worked fine
[21:28] <davmor2> pitti I can try again for you if you want?  Are you on vm though?
[21:29] <pitti> davmor2: I tried in vmware (amd64 CD) and kvm (i386 CD) on two different computers
[21:29] <pitti> will test on real iron tomorrow, but can't do today
[21:29] <davmor2> Might be vm issue we've had a few
[21:30] <davmor2> I can test on hw again for you if you want
[21:30] <pitti> that would be great
[21:31] <davmor2> 2 ticks
[21:36] <davmor2> pitti: desktop up and running slowly but up and running
[21:36] <pitti> davmor2: ah, thanks; could you try something for me, please?
[21:36] <davmor2> yes
[21:37] <pitti> davmor2: please open a Terminal and do "ls -l /proc/$$/exe"
[21:37] <pitti> davmor2: what's the result, "/bin/bash"?
[21:38] <davmor2> /proc/7698/exe -> /bin/bash
[21:38] <pitti> yay
[21:38] <pitti> that means that this unionfs bug doesn't apply to aufs, and we can drop that mono hack
[21:38] <pitti> davmor2: thanks
[21:39] <davmor2> anything else while it up and running?
[21:41] <davmor2> pitti: ^
[21:41] <pitti> davmor2: not now, thanks a lot!
[21:41] <davmor2> No probs


[22:39] <ianorlin> any obvious typos in this?
[22:40] <ianorlin> https://wiki.ubuntu.com/VividVervet/Beta2/Lubuntu
[22:40] <darthrobot> Title: [VividVervet/Beta2/Lubuntu - Ubuntu Wiki]
[22:42] <nhaines> ianorlin: "Instr uctions for burning the image to a DVD..." has a line break in the middle of "Instructions".
[22:43] <ianorlin> nhaines: thanks
[22:44] <nhaines> You're welcome.  A quick skim through in LibreOffice didn't unveil any others.


[08:10] <seb128> goood morning desktopers!
[13:01] <jbicha> good morning
[13:54] <KGB-2> mutter signed tags 979ee47 Jeremy Bicha ubuntu/43.2-5ubuntu1 * mutter Debian release 43.2-5ubuntu1 * https://deb.li/3zIjA
[13:57] <KGB-2> mutter signed tags 89a6701 Jeremy Bicha ubuntu/43.2-6ubuntu1 * mutter Debian release 43.2-6ubuntu1 * https://deb.li/33HMe
[13:57] <KGB-0> mutter ubuntu/master 3e49de7 Jeremy Bicha * pushed 13 commits (first 5 follow) * https://deb.li/iOvR0
[13:57] <KGB-0> mutter ubuntu/master 2a88fc1 Daniel van Vugt debian/patches/debian/Support-Dynamic-triple-double-buffering.patch * Update Support-Dynamic-triple-double-buffering.patch * https://deb.li/i7sle
[13:57] <KGB-0> mutter ubuntu/master 0e98be5 Daniel van Vugt debian/patches/ series cursor-renderer-native-Workaround-broken-arm64-drivers.patch * cursor-renderer-native: Workaround broken arm64 drivers * https://deb.li/UwBM
[13:57] <KGB-0> mutter ubuntu/master a93c7fd Jeremy Bicha debian/changelog * releasing package mutter version 43.2-5 * https://deb.li/37Ihj
[13:58] <KGB-0> mutter ubuntu/master a5fbbd4 Jeremy Bicha debian/ changelog patches/debian/Support-Dynamic-triple-double-buffering.patch * Merge tag 'debian/43.2-5' into ubuntu/master * https://deb.li/mDi4
[13:58] <KGB-0> mutter ubuntu/master 0adda0c Jeremy Bicha debian/changelog * releasing package mutter version 43.2-5ubuntu1 * https://deb.li/3avcD
[13:58] <KGB-0> orca ubuntu/master b4beefb Jeremy Bicha * pushed 34 commits (first 5 follow) * https://deb.li/rv0g
[13:58] <KGB-0> orca ubuntu/master f586977 Joanmarie Diggs src/orca/generator.py * Add null check in _generateColumnHeaderIfToggleAndNoText * https://deb.li/SYsv
[13:58] <KGB-0> orca ubuntu/master 9f217b6 Colomban Wendling src/orca/orca_bin.py.in * Fix finding the Python module with automake >= 1.16.4 * https://deb.li/3ziFn
[13:58] <KGB-0> orca ubuntu/master a4b1d73 Nart Tlisha po/ab.po * Update Abkhazian translation * https://deb.li/3gsUs
[13:59] <KGB-0> orca ubuntu/master 09ecde9 Joanmarie Diggs src/orca/speech_generator.py * Don't present ancestry of newly-selected page tabs * https://deb.li/3IwCl
[13:59] <KGB-0> orca ubuntu/master c304c94 Joanmarie Diggs src/orca/ script_utilities.py speech_generator.py * Fix repetition of text elements during SayAll in web content * https://deb.li/Mu2x
[16:59] <KGB-2> gdm Marco Trevisan 378348 * commented commit d6c6947 * https://deb.li/ksv0
[17:07] <KGB-0> gdm Marco Trevisan 378349 * commented commit d6c6947 * https://deb.li/3LYnn
[18:51] <Eickmeyer> ogra: Figured out an inconvenient truth with the Firefox snap. The native messaging support doesn't work in KDE Plasma. Removing "env" from the "Exec=" line makes it work.
[18:52] <Eickmeyer> (in the .desktop file)
[18:53] <ogra> Eickmeyer, iirc there were known issues with native messaging in some combos (and i think i remember there were kde bits involved) where you need flatpak to grant the portal permissions
[18:53] <KGB-0> gdm Simon McVittie 378365 * commented commit d6c6947 * https://deb.li/3JdmC
[18:53] <Eickmeyer> That's.... very odd.
[18:54] <Eickmeyer> I'd hate to seed flatpak.
[18:54] <ogra> i could remember that wrongly though ... the discussion was sadly spread between discourse.u.c and forum.snapraft.io
[18:54] <KGB-2> gdm Simon McVittie 378366 * commented commit d6c6947 * https://deb.li/nhPh
[18:55] <ogra> yeah we need to solve that anyway, can't be that you need to install fatpak to set two settings in the portal
[18:55] <ogra> +l
[19:09] <Eickmeyer> ogra: Coincidentally, just had a really nice xdg-desktop-portal crash that might be related. bug 2004192
[19:09] -ubottu:#ubuntu-desktop- Bug 2004192 in xdg-desktop-portal (Ubuntu) "xdg-desktop-portal crashed with SIGSEGV in start_thread()" [Undecided, New] https://launchpad.net/bugs/2004192
[19:12] <ogra> ouch
[22:40] <GunnarHj> Hi jbicha! Do you know the reason why we delay the transition from /etc/fonts/conf.avail to /usr/share/fontconfig/conf.avail ?
[23:11] <jbicha> GunnarHj: hi, by looking through changelogs, I think that was done with https://launchpad.net/ubuntu/+source/fontconfig/2.10.1-0ubuntu1
[23:12] <jbicha> and we never got around to looking at doing the transition later. We just want things to keep working
[23:12] <jbicha> You're welcome to do the transition if you believe things will still work correctly afterwards :)
[23:16] <jbicha> unusually for me, it looks like I only touched the package once, for bionic :)
[23:24] <GunnarHj> jbicha: That's an old upload... I don't really see which the details are which need to be sorted. :) What matters is /etc/fonts/conf.d, and as long the symlinks point at /usr instead of /etc all should be fine. I may make an attempt in a PPA to start with. Doing it will make future merges a bit simpler.


[09:37] <huats> morning
[13:00] <aday> mpt: hey :) get back ok?
[13:00] <mpt> Hello hello
[13:00] <mpt> Hi aday
[13:01] <mpt> hi andreasn
[13:01] <andreasn> hi!
[13:01] <humphreybc> hey
[13:01] <thorwil> hi all!
[13:01] <aday> andreasn is here. a new recruit!
[13:01] <aday> hi all
[13:01] <andreasn> recruit?
[13:02] <andreasn> I am?
[13:02] <andreasn> :)
[13:02] <mpt> I invited andreasn
[13:02] <mpt> andreasn, are you on the mailing list?
[13:02] <mpt> hi humphreybc, hi thorwil
[13:02] <andreasn> uh, maybe
[13:03] <andreasn> I got a mail from<EMAIL_ADDRESS>so I think I am
[13:03]  * humphreybc is trying out jolicloud
[13:04] <aday> shall we use mpt's mail as an agenda?
[13:05] <mpt> okie dokie
[13:05] <thorwil> "Starting new design projects. There are various small things in Ubuntu that we know need redesigning: for example, Appearance
[13:05] <thorwil>     settings, display settings, the screenshot utility. How could we organize people to work together on these designs?"
[13:06] <humphreybc> hold a gun to their head and force them?
[13:06] <mpt> Places like the Ayatana mailing list have plenty of small ideas, but hardly any sustained efforts
[13:06] <humphreybc> hello ivanka :)
[13:07] <thorwil> first thing could be to have a list of those various things
[13:07] <aday> it would be great to have something like design hub for this
[13:07] <thorwil> be it on a wiki page, or tickets
[13:08] <thorwil> aday: that's what i have been saying. the problem is: who's gonna write that and set it up and maintain it?
[13:08] <aday> thorwil: it was in development, but it seems to have stalled :(
[13:09] <humphreybc> :(
[13:09] <mpt> After five years I'm automatically skeptical of any solution to any problem that involves Yet Another Web Site
[13:10] <mpt> Are there ways we could reuse the communications methods we already have?
[13:10] <aday> mpt: i'm sure there are. we've been trying to use live.gnome.org/Design to do something like this
[13:10] <wers> hello
[13:10] <mpt> Maybe I could just post to ayatana@ and say "It would be cool if people had a go at redesigning these things" and see what happens :-)
[13:10] <mpt> hi wers
[13:10] <thorwil> mpt: like i said: for a list or projects and some minimal tracking: wiki page or LP tickets
[13:10] <wers> hi mpt aday thorwil
[13:10] <thorwil> hi wers
[13:10] <aday> wers: hi :)
[13:11] <mpt> humphreybc, how did that Weather Indicator get started?
[13:11] <andreasn> yeah, live.gnome.org/Design + bug reports seems to have been working pretty good so far
[13:11] <humphreybc> I think some people in #omg!ubuntu! decided to randomly start it
[13:11] <humphreybc> then they left the project
[13:11] <humphreybc> Ohso (our company) took over and it now has a developer working on it basically full time
[13:11] <humphreybc> so originally, bored people who saw a need?
[13:12] <vish> oh , whats up here!
[13:12] <vish> people in the meeting :D
[13:12] <andreasn> especially with the Designers and Developers columns, because that means someone is responsible
[13:12] <thorwil> vish: psst! don't ruin it!
[13:13] <mpt> hm
[13:13] <thorwil> mpt: if you'd just post to ayatana with a design task, how would you avoid a blown up "discussion"?
[13:13] <mpt> oh, there's little hope of avoiding that
[13:13] <mpt> The question is could we get anything else as well.
[13:14] <mpt> Actually, the three examples I gave are all generic Gnome stuff, so they could go on live.gnome.org/Design
[13:14] <andreasn> well, a lot of the noise is drive by comments, right?
[13:14] <andreasn> for all sorts of things
[13:14] <mpt> yep
[13:15] <andreasn> assigning people to stuff and have them be responsible for that full time might work?
[13:15] <andreasn> so some kind of "commitment to fix something, or be silent" agenda maybe
[13:16] <aday> mpt: we're planning to have weekly gnome design office hours - that could be a good forum for this kind of discussion (for the gnome-specific stuff, at least)
[13:16] <humphreybc> I've noticed that a lot of people are willing to work, they just need direction.
[13:16] <thorwil> regarding responsibility, small package size and high chance of exacting implementation would help with motivation
[13:16] <mpt> aday, where would that be, and who's "we" in that context?
[13:17] <vish> mpt: aday's secret hideout , in #gnome-design ;)
[13:17] <mpt> ah
[13:17] <aday> mpt: 'we' - anybody who wants to participate :)
[13:17] <thorwil> note #gnome-design on gimpnet
[13:18] <vish> thorwil: iirc mpt knows but just forgets to login there since recently ;p
[13:18] <andreasn> and I think there are people like Thomas Wood who are interested in fixing the Appearance applet, as long as he gets some direction
[13:19] <andreasn> or, well, we'll see what happens to that one specifically
[13:19] <mpt> It's because "Add to Favorites" is completely broken in XChat, that's why
[13:20] <aday> mpt: you know about gnome-design on gitorious too? we're using sparkleshare to share mockups
[13:20] <mpt> I did not
[13:20] <thorwil> nah, the Network List is a master piece!!
[13:20] <mgunes>  hi all, sorry to be late. I'll try to catch up with the remainder of the meeting.
[13:21] <aday> mpt: http://gitorious.org/gnome-design/gnome-design
[13:21] <andreasn> mpt, I keep forgetting channels as well.
[13:21] <mpt> I particularly love the tooltip that says "Channels to join, separated by commas, but not spaces!"
[13:21] <andreasn> mpt, :)
[13:22] <andreasn> oh, there is also a right click menu if you click the channel list, this is in xchat-gnome though
[13:22] <andreasn> ok, drifting off from topic a bit :)
[13:23] <vish> moving on...
[13:23] <humphreybc> you all should use pidgin
[13:23] <humphreybc> works like a charm
[13:23] <vish> mpt: there is one person , who i think would be interested in working on screenie
[13:24] <vish> what are the requirements? what language is preferred[i believe he is good in python]?
[13:24] <wers> vish, ooh. screenie is alive?
[13:24] <mpt> andreasn, Pongo is currently Python, right?
[13:24] <vish> wers: well , it was in mpt's agenda
[13:24] <thorwil> right, 3rd point. not 2nd! ;)
[13:25] <wers> vish, oh. the log isn't updated so I wasn't able to catch up
[13:25] <andreasn> mpt, yeah, and it's, hm, works in funny ways sometimes
[13:25] <andreasn> mpt, but I was surprised Jan actually found use for it
[13:26] <humphreybc> be back in a bit
[13:26] <mgunes> in case some of you haven't heard of it: ClutterSmith looks like it might be a useful tool for animated mockups, among other things. I have yet to get it to compile at this point though.
[13:26] <mpt> vish, so could you point him/her to the project page and suggest adding a graphical interface?
[13:26] <andreasn> cool!
[13:27] <andreasn> mpt, and let this person know that a rewrite is fully possible
[13:27] <andreasn> err... that was to vish
[13:28] <vish> mpt: sure , but i dont see a specs page , not sure where to point him to , and oddly i cant find the existing code o.0
[13:28] <andreasn> hbons trick to "trow something horrible together so that others will fix it for you" probably works great for Pongo too :)
[13:28] <mpt> andreasn, is http://www.andreasn.se/blog/images/pongo.py the latest version?
[13:28] <vish> oh wait ! lp was just fooling me! found it
[13:28] <mpt> ok
[13:29] <andreasn> I think Jan might have done some fixes
[13:29] <andreasn> checking with him now
[13:29] <mpt> Who's Jan?
[13:29] <wers> Jan-Christoph
[13:29] <andreasn> Borchardt
[13:29] <mpt> ok, Charline is out at lunch, but I will ask her about how we should research personas
[13:29] <wers> we're pursuing the open usability lab. he's been playing with pongo
[13:29] <andreasn> the dude who is doing the testing on Shotwell
[13:30] <mpt> vish will see if he can find a Screenie contributor
[13:30] <andreasn> woohoo!
[13:30] <wers> http://bazaar.launchpad.net/~inquata/pongo/pongo/annotate/head:/pongo.py
[13:30] <mpt> aaaaaand I will post about live.gnome.org/Design to ayatana@, unless aday would like to do that instead
[13:31] <aday> mpt: i'm happy for you to do it :)
[13:31] <mpt> humphreybc, do you think perhaps godbyk would be interested in writing a user testing script template?
[13:31] <mpt> aday, ok
[13:31] <andreasn> what is a user testing script?
[13:31] <aday> mpt: i've been adding some resources to the usability project that the ayatana crowd might be interested in, btw
[13:32] <vish> gah! @ayatana ml :/
[13:32] <humphreybc> mpt: a user testing script template?
[13:32] <aday> mpt: http://live.gnome.org/UsabilityProject/GettingStarted  http://live.gnome.org/UsabilityProject/HeuristicEvaluation http://live.gnome.org/UsabilityProject/DoingResearch
[13:32] <mpt> andreasn, the thing you read from when conducting a user test. Including such vital sentences as "We're testing the software, not you."
[13:32] <andreasn> ooh, I was thinking of a shell script :)
[13:33] <humphreybc> ah
[13:33] <humphreybc> I think godbyk could definitely do that
[13:33] <humphreybc> he might already have
[13:33] <humphreybc> one
[13:33] <mpt> neat
[13:33] <aday> mpt: http://live.gnome.org/Pongo/Tutorial i never finished it though :(
[13:34] <mpt> Ok, I'm sorry I'm snowed under with other work today so I'll have to bow out now, but feel free to carry on without me. :-)
[13:34] <aday> actually, most of it's there
[13:34] <humphreybc> mpt: exciting work no doubt
[13:36] <aday> anything more to say about the testing stuff or shall we move on?
[13:36] <thorwil> maybe we could talk about the nice things we will do with our plenty of free time while mpt is snowed under now?
[13:36] <wers> Jan happens to be writing on the open usability lab Wave right now. You want me to tell him to join the meeting now?
[13:36] <aday> wers: i lost the link to that...
[13:37] <wers> aday, which one?
[13:37] <wers> I meant, he's currenly online and we're talking about the same project
[13:38] <aday> sorry, ignore me. yeah get him over here
[13:38] <aday> :)
[13:39] <mgunes> aday, was the UX advocates BoF at GUADEC recorded on video?
[13:40] <vish> aday: what's the latest about HIG update?
[13:40] <aday> mgunes: no, but i'm going to be sending a report to the usability list
[13:40] <vish> what is changing for HIG3
[13:40] <aday> vish: same! oh, and i'll be firing off a blog post later today
[13:40] <vish> cool..
[13:40] <mgunes> aday, alright, thanks!
[13:40] <andreasn> * HIG3 will be a pattern library
[13:41] <andreasn> * + some initial design principles
[13:41] <aday> mgunes: live.gnome.org/UsabilityProject/UXAdvocates
[13:41] <mpt> I wrote http://live.gnome.org/action/edit/UsabilityProject/HIG3/HandlingErrors while at Guadec
[13:41] <andreasn> http://live.gnome.org/UsabilityProject/HIG3
[13:41] <andreasn> more writers are needed!
[13:42] <aday> none of my patterns are finished yet!
[13:42] <aday> well, 'my' - i welcome contributions :)
[13:42] <andreasn> wasn't there an etherpad too somewhere?
[13:43] <aday> andreasn: http://pad.ubuntu-uk.org/ui-patterns
[13:43] <humphreybc> mpt: you have your own category on OMG! Ubuntu. Do you feel special?
[13:43] <andreasn> aday, ah, yes, thanks!
[13:43] <aday> we're off topic again. shall we move on to talk about personas?
[13:44] <humphreybc> ubuntu manual team has been working on personas
[13:44] <humphreybc> for use in the manual
[13:44] <humphreybc> not sure what's happening there atm
[13:44] <aday> hylke and garrett started some for gnome but there hasn't been any work done for a little while
[13:44] <andreasn> aday, ok if I link to the pad from the HIG3 wiki page?
[13:45] <aday> andreasn: it already is 'List of other potential patterns'
[13:45] <andreasn> ah, sweet!
[13:46] <aday> is there anybody out there who wants to spend some time on this?
[13:46] <aday> what kind of research do we want to do for the personas?
[13:47] <aday> i've drawn up an interview schedule for the gnome design ones, but finding time to do the interviews will be tricky
[13:48] <aday> some observation based research could also work though. what do people think?
[13:49] <JanCBorchardt> wers: hey :)
[13:49] <wers> JanCBorchardt, there you are. I didn't know they were also discussing at #gnome-design
[13:49] <aday> JanCBorchardt: hello there! :)
[13:50] <JanCBorchardt> aday: hey to you too ;)
[13:50] <aday> seems like the testing tools discussion has moved to #gnome-design :P
[13:50] <wers> yeah. lol
[13:51] <thorwil> aday: are the interviews something that could be spready, could you try a call for helpers?
[13:52] <JanCBorchardt> wers: aday: yes, I suggest we discuss about Pongo on gnome-design because it is not really Ubuntu-only. And work has been done on the wiki already
[13:52] <aday> thorwil: i think it needs to be done by at least one person to begin with - the schedule needs to be piloted, and it might evolve to begin with
[13:52] <wers> JanCBorchardt, that's right.
[13:53] <aday> thorwil: i'm wanting to do rather open-ended interviews - which are difficult to distribute
[13:53] <thorwil> ic
[13:53] <aday> which isn't to say that others couldn't help
[13:53] <aday> it would be great if people wanted to try out the schedule
[13:54] <JanCBorchardt> so who here is actually interested in the user testing stuff? (except for wers and aday ;)
[13:55]  * thorwil -> coffee
[13:56]  * aday -> cigarette
[13:57] <JanCBorchardt> aday: wers: did I miss anything here?
[14:05] <aday> JanCBorchardt: http://pastebin.com/Dd80bbvD
[14:06] <aday> JanCBorchardt: i wrote this for pongo. might be useful: http://pastebin.com/Dd80bbvD
[14:06] <aday> wrong link! http://live.gnome.org/Pongo/Tutorial
[14:07] <wers> aday, thanks for the  log
[14:08] <JanCBorchardt> aday: yep, have seen that. I was going to put that in the Guerilla testing blogpost
[14:08] <JanCBorchardt> and thanks for the log :)
[14:08] <andreasn> JanCBorchardt, what's the URL to your blog?
[14:08] <JanCBorchardt> andreasn: http://jancborchardt.wordpress.com/
[14:09] <JanCBorchardt> only an introduction as of now, I have some drafts of earlier writings
[14:12] <aday> shall we wrap things up for today? anybody fancy writing some notes for the list?
[14:13] <JanCBorchardt> I didn’t know of the meeting, is it every Thursday at 13 UTC?
[14:13] <aday> JanCBorchardt: yep. there's a launchpad team - ask mpt to add you
[14:15] <mgunes> aday, I can do the meeting notes.
[14:15] <JanCBorchardt> mpt: could you please add me to the Ayatana UX team? I just discovered I applied a while ago
[14:15] <aday> mgunes: awesome! i would but i'm snowed under right now
[14:15] <humphreybc> JanCBorchardt: I can add you
[14:15] <humphreybc> what's your launchpad thing?
[14:16] <mgunes> it will take some hours though; probably late tonight.
[14:16] <wers> humphreybc, he's already pending there
[14:16] <humphreybc> oh okay
[14:16] <humphreybc> i'll approve him now
[14:17] <humphreybc> done
[14:17] <aday> mgunes: no problem :)
[14:17] <JanCBorchardt> humphreybc: cool, thanks
[14:18] <mgunes> my suggestion is to use the mailing list for other things than meeting notes, by the way. let's get a bit chatty ;)
[14:18] <aday> mgunes: yes, we're not utilising it enough right now
[14:19] <humphreybc> right i'm off guys
[14:19] <humphreybc> catch you later :)
[14:19] <aday> me too
[14:19] <mgunes> aday, right, I prefer the discourse to be more spread out and asynchronous. we'll have to rely less on the meetings that way.
[14:20] <mgunes> me too. see you all.
[14:20] <aday> humphreybc: see you!


[00:30] <jaddi27> #startmeeting UGJ Mar 2012 - Wiki Jam
[00:30] <meetingology> Meeting started Sun Mar  4 00:30:51 2012 UTC.  The chair is jaddi27. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[00:30] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[00:31] <jaddi27> Hi everyone
[00:31] <jaddi27> I thought I would hold a Wiki Jam to clean up the ubuntu-au wiki pages
[00:31] <jaddi27> http://loco.ubuntu.com/events/ubuntu-au/1537/detail/
[00:32] <jaddi27> So, if you would like to join in, please feel free to do so
[00:32]  * benonsoftware forgot about it :D
[00:33] <jaddi27> I don't expect that many people to be here, especially due to the timing
[00:33] <benonsoftware> I should be here for all of the session
[00:35] <jaddi27> benonsoftware, I think to start off it would be good to go through pages and work out if they are still relevant, if they are in the right section, if they are up to date, etc
[00:35] <benonsoftware> Yep ok
[00:38] <benonsoftware> I don't know if this is a good idea but maybe have https://wiki.ubuntu.com/AustralianTeam/LocalCDDistribution sentence on a different page instead of taking up a whole page with the one sentence
[00:44] <jaddi27> benonsoftware, I agree with that. However, maybe leave it there for now, because once we get Localised ISOs, this page could be better utilised
[00:44] <benonsoftware> Ok
[00:47] <benonsoftware> jaddi27: Would you like me to fix https://wiki.ubuntu.com/AustralianTeam/IRC#Channel_Logs ?
[00:49] <jaddi27> benonsoftware, Yes, that would be good. It might be worth putting a link to the meeting logs there as well, for people who get to that page trying to find them
[00:49] <benonsoftware> Ok
[01:11] <jaddi27> I have updated the Meetings page (https://wiki.ubuntu.com/AustralianTeam/Meetings)
[01:11] <jaddi27> It now has information about where to find logs from meetingology, as well as how to add agenda items to l.u.c
[01:18] <head_victim> Morning :)
[01:18] <jaddi27> morning head_victim
[01:18] <benonsoftware> Morning head_victim
[01:26] <jaddi27> head_victim, You must enjoy getting all these notifications from wiki changes :P
[01:26] <head_victim> It's better than them being defaced and not knowing ;)
[01:28] <jaddi27> that is true
[01:38] <jaddi27> head_victim, Have you found that the header columns are a bit different in layout and spacing to what they used to be?
[01:43] <head_victim> Yeah, I wasn't sure if that coincided with a browser update or not though
[01:44] <jaddi27> head_victim, I have worked out the problem. The new CSS for the theme on the wiki forces tables to have padding and margins. I have changed the inline CSS to fix this up. I will ping you when I have finished to check if it looks alright still
[01:46] <jaddi27> head_victim, Can I add the Forum to the links column now? It is not that new any more
[01:48] <head_victim> Sure
[01:48] <head_victim> I was trying to keep the columns balanced so if we can find a way to do that (eg 4 in each or 5 in each....)
[01:49] <jaddi27> I think we could move the enAU translations to a new line to fix the first column, so we would just have to find something for the third column
[01:50] <jaddi27> The header is fixed up now. Looks a bit better now with positioning
[01:52] <head_victim> Maybe add an "events" button that links to the loco.u.c upcoming events?
[01:54] <jaddi27> Yes, that would be good. I will add them now
[02:03] <head_victim> I was going to get in and do it myself but 2 people editing the same wiki page = fail
[02:05] <jaddi27> Yes, that is one problem with editing wikis
[02:07] <jaddi27> Ok. Header editing is finished. See what you think
[02:07] <jaddi27> head_victim, benonsoftware
[02:08] <head_victim> Looks good
[02:08] <benonsoftware> Yep
[02:08] <head_victim> I wouldn't want to add many more to the bottom of the list so if we're contemplating adding more we'll need to consider dropping others
[02:10] <jaddi27> Yes, I agree with that. We could probably remove the Forum bulletin now that it has a link in the header
[02:12] <jaddi27> I think that is about it for the Wiki Jam. We got a fair bit cleaned up, so that is a good outcome
[02:12] <jaddi27> Thanks to everyone who attended
[02:12] <jaddi27> #endmeeting
[02:12] <meetingology> Meeting ended Sun Mar  4 02:12:15 2012 UTC.
[02:12] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-au/2012/ubuntu-au.2012-03-04-00.30.moin.txt
[02:12] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-au/2012/ubuntu-au.2012-03-04-00.30.html
[02:12] <head_victim> The meeting page is heaps better
[02:12] <jaddi27> head_victim, That is good. I thought it needed fixing up a bit (it still said that our meetings were on Tuesdays!)
[02:13] <head_victim> Yeah and needed to point to loco.u.c
[02:13] <jaddi27> Is your calendar looking any better? Mine still has the jams at the wrong times
[02:13] <sagaci> no point having the same information elaborated on two pages
[02:13] <head_victim> Yeah mine to
[02:13] <jaddi27> (on google)
[02:14] <head_victim> I use google as well
[02:14] <jaddi27> sagaci, When you created your event for the release party on l.u.c, what timezone did you use?
[02:14] <head_victim> sagaci: apparently the time zone issue was us not understanding the options properly. Apparently for historical reasons the +10 is actuall -10 and vice cersa
[02:43] <sagaci> head_victim, what's the point of -10?
[02:43] <head_victim> sagaci: apparently the ETC tz are reverse
[02:43] <sagaci> ah ok
[02:43] <head_victim> jaddi27: figured it out last night.
[02:44] <head_victim> He and I also noticed you used the EST timezone on your events but this is meant to be a -5 but shows up perfectly in our google calendars.
[02:44] <sagaci> that doesn't make sense
[02:44] <head_victim> That's what we're thinking ;)
[02:45] <head_victim> Have you been choosing EST or picking something else?
[02:46] <head_victim> bug 786022 explains the ETC part
[02:46] <sagaci> EST must be EST for America
[02:47] <head_victim> Supposedly, I know EST is a fairly common abbreviation used in at least the US and AU, maybe others.
[02:50] <sagaci> what about just setting the team time to Australia/QLD
[02:51] <head_victim> Yeah I was trialling ETC-10 for now but it hasn't seemed to have updated anything
[02:51] <head_victim> So I was going to put it to the list to see what the preferred location was. I was hoping to avoid location specifics to reduce complaints but if there's no other way to make it work then we'll have to
[02:52] <head_victim> But the sydney release party, was that scheduled for 21/04 at 2pm?
[02:53] <sagaci> yup
[02:53] <head_victim> jaddi27: look at http://loco.ubuntu.com/teams/ubuntu-au/events/history - the jams are all set up well.
[02:53] <head_victim> sagaci: and you picked EST for that?
[02:53] <head_victim> Ah no you didn't, you have set the venue to Sydney time so that's over riding. Cool
[02:53] <sagaci> yeah, I'll guess I'll change it to Australia/NSW or Australia/Sydney
[02:54] <head_victim> I think half the confusing thing is there is 3 different places you can change a timezone in loco.u.c. There is the overall team default, the event time and the venue time
[02:55] <sagaci> yeah
[02:55] <sagaci> event comes up as EST
[02:55] <sagaci> venue is in australia/sydney/nsw
[02:55] <sagaci> confusing
[02:55] <head_victim> So I'm thinking we need to set a default for the team and use that for all IRC events, and then all the real world events just set up local time.
[02:57] <head_victim> I was hoping the etc-10 will work so we'll leave that until we'
[02:57] <head_victim> we've made more events. If that works we'll leave that as the team and IRC defaults
[02:58] <head_victim> And it keeps dropping you 2 as admins :/
[03:00] <head_victim> bug 792475
[03:03] <head_victim> Ahhh it pulls from lp the admin status.
[03:03] <head_victim> I'll make you both admin on lp and see if that holds it then
[03:10] <head_victim> Anyway, I gotta run an ddo some mowing, I'll be back later to see if it held
[03:10] <sagaci> my launchpad account is wrongly connected to the jpickett2 username on l.u.c so I need to change that to jpickett
[03:57] <jaddi27> head_victim, sagaci: I worked out last night that when a time is set to 'Australia/Brisbane' or 'Australia/Sydney', the timezone text will show up as 'EST'
[03:57] <jaddi27> So this means that when it says EST for events under the Australian loco, it would be referring to the Australian EST, not the EST in America
[03:58] <jaddi27> However, if you select 'EST' from the timezone list, that is referring to the American timezone
[04:00] <jaddi27> So basically it means that the timezone can be set to Australia/Brisbane, or sydney or melbourne, and they will all come up as being EST, which is not really location specific
[04:01] <jaddi27> Also, I don't think it says anywhere but on the settings page that the Team timezone is set to Australia/Brisbane, so people should only see EST next to times
[05:45] <head_victim> jaddi27: Ah, weird, but good to konw
[13:21] <jaddi27_> sagaci, head_victim: Something I have been working on for a while. Finally found time to get a version working
[13:21] <jaddi27_> http://joeladdison.com/ubuntu/translation/oneiric/en_AU
[13:21] <jaddi27_> http://joeladdison.com/ubuntu/translation/precise/en_AU
[22:58] <bradm> interesting, moving workspaces seems to be back to being ctrl-alt-arrow in precise


[03:08] <IOU> does anyone find the 2.6.24-12 kernel slower than the 2.6.24-11 ?
[17:03] <soulc> anyone alive?
[19:44] <enarxe0> buenas
[19:44] <enarxe0> hi
[22:30] <tannewt> any ideas how I should integrate apple-like multitouch into X?
[23:00] <Amaranth> tannewt: already done
[23:12] <tannewt> Amaranth: you mean MPX?
[23:12] <Amaranth> yes
[23:13] <tannewt> Amaranth: it seems overly complex for what I'd like to do
[23:13] <Amaranth> that's kind of the point :)
[23:13] <tannewt> Amaranth: I dont need to worry about multiple points and multiple focii
[23:13] <Amaranth> it can do everything, it's up to the app creator (or library creator) to define what to do
[23:15] <tannewt> Amaranth: right, I'd rather integrate into normal X though so it works with everything now
[23:15] <Amaranth> err, it already does?
[23:16] <Amaranth> that was a key thing in the design
[23:16] <Amaranth> and if you're not worried about multiple points then you're not doing multitouch
[23:16] <tannewt> Amaranth: doesn't it require a different version of X?
[23:16] <Amaranth> no
[23:16] <Amaranth> it just requires one that hasn't been released yet
[23:16] <tannewt> Amaranth: right, I'm doing apple's version of multitouch
[23:17] <tannewt> Amaranth: when is it slated for release?
[23:17] <Amaranth> apple doesn't have their own version of multitouch...
[23:17] <Amaranth> they have some gestures defined
[23:17] <Amaranth> MPX probably won't be in a public Xorg release until the end of the year
[23:18] <tannewt> right, gestures dependent on multiple points, 1-11 supported
[23:18] <Amaranth> you just said you didn't need multiple points
[23:18] <Amaranth> but it's up to an application or library to define these gestures, X doesn't do policy
[23:20] <tannewt> Amaranth: right, I was thinking of writing a daemon/driver to do the gesture stuff and pass those events onto X
[23:20] <Amaranth> that'll never be accepted in Xorg
[23:21] <tannewt> Amaranth: doesn't need to be
[23:21] <tannewt> Amaranth: it can be separate
[23:21] <Amaranth> good luck then
[23:21] <tannewt> Amaranth: is there a way for a desktop daemon to send X events?
[23:21] <Amaranth> You can't just make up new events
[23:22] <tannewt> Amaranth: what about ones already defined?
[23:22] <Amaranth> there are none already defined that fit what you're trying to do
[23:22] <Amaranth> but you can use XTest to fake events
[23:23] <tannewt> well, I'm saying I'll run code which understands the gesture stuff and sends events like right clicks and scrolls
[23:23] <Amaranth> then you have to modify applications to know to do multitouch things with those
[23:24] <tannewt> but at that point it doesn't matter if it was a usb mouse or a gesture


[00:02] <CIA-45> ubiquity: superm1 * r5084 ubiquity/ (debian/changelog scripts/plugininstall.py): Properly build the manifest used for remove oem extras.
[00:04] <cjwatson> ev: FYI ubiquity did build in the end
[02:46] <CarlFK> d-i passwd/username string juser; d-i preseed/late_command ... chroot /target /tmp/late.sh; su juser -c "gsettings set org.gnome.desktop.screensaver idle-activation-enabled false
[02:47] <CarlFK> boot system, juser@kasp:~$ gsettings get org.gnome.desktop.screensaver idle-activation-enabled;
[02:47] <CarlFK> true
[02:48] <CarlFK> how do I run gsettings so it does what I want? :)
[07:42] <ev> cjwatson: woohoo
[07:42] <ev> thanks for chasing that
[08:19] <cjwatson> CarlFK: could you ask the desktop people, please, and point out to them that dbus isn't running in the relevant context
[11:10] <CIA-45> partman-ext3: cjwatson * r1055 ubuntu/ (76 files in 3 dirs): merge from Debian 66
[11:12] <CIA-45> partman-ext3: cjwatson * r1056 ubuntu/debian/changelog: releasing version 66ubuntu1
[12:47] <CarlFK> cjwatson: installer syslog:`dbus-launch --autolaunch=23ebe9869679dfd4566f95c5000004f5 --binary-syntax --close-stderr' exited with non-zero exit status 1: Autolaunch error: X11 initialization failed.\n
[12:48] <CarlFK> oh, you are in #desktop too... ill take this there
[12:50] <cjwatson> I'm not a good person to ask about this
[12:50] <cjwatson> anything that involves launching dbus is a non-starter - you need a way to set gsettings policy without involving dbus
[12:50] <cjwatson> but somebody other than me needs to answer this for you.  that's why I directed you to #ubuntu-desktop
[17:17] <CIA-45> debian-installer-utils: cjwatson * r1145 ubuntu/ (72 files in 3 dirs): merge from Debian 1.85
[17:18] <CIA-45> debian-installer-utils: cjwatson * r1146 ubuntu/debian/changelog: releasing version 1.85ubuntu1
[17:20] <CIA-45> clock-setup: cjwatson * r227 ubuntu/debian/ (74 files in 2 dirs): merge from Debian 0.109
[17:22] <CIA-45> clock-setup: cjwatson * r228 ubuntu/debian/changelog: releasing version 0.109ubuntu1
[21:55] <CIA-45> choose-mirror: cjwatson * r1166 ubuntu/ (73 files in 3 dirs): merge from Debian 2.39
[21:59] <CIA-45> choose-mirror: cjwatson * r1167 ubuntu/ (3 files in 2 dirs): Switch to precise by default.
[22:00] <CIA-45> choose-mirror: cjwatson * r1168 ubuntu/Mirrors.masterlist: update Mirrors.masterlist to Debian 2.38
[22:02] <CIA-45> choose-mirror: cjwatson * r1169 ubuntu/ (5 files in 2 dirs): Add armhf support.
[22:03] <soren> Where does the installer log file live while the installer is still running?
[22:03] <cjwatson> /var/log/syslog
[22:04] <soren> Oh, that's what gets renamed to /var/log/*something-installer-ish*?
[22:05] <soren> cjwatson: Cool, thanks.
[22:05] <CIA-45> choose-mirror: cjwatson * r1170 ubuntu/debian/changelog: releasing version 2.39ubuntu1
[22:05] <cjwatson> /var/log/installer/syslog, yes
[22:39] <CIA-45> cdrom-detect: cjwatson * r908 ubuntu/debian/ (cdrom-detect.templates changelog): Set cdrom/suite default to precise; drop dapper.
[22:41] <CIA-45> cdrom-detect: cjwatson * r909 ubuntu/debian/changelog: releasing version 1.39ubuntu2
[22:47] <CIA-45> iso-scan: cjwatson * r550 ubuntu/debian/ (71 files in 2 dirs): merge from Debian 1.36
[22:48] <CIA-45> iso-scan: cjwatson * r551 ubuntu/debian/ (changelog iso-scan.templates): Add precise to cdrom/suite Choices; drop dapper.
[22:49] <CIA-45> iso-scan: cjwatson * r552 ubuntu/debian/changelog: releasing version 1.36ubuntu1


[00:31] <holmanb> minimal: nice :) thanks for sharing
[00:33] <holmanb> meena: is there anything special about freebsd on ec2 that would warrant this being datasource specific behavior? https://github.com/canonical/cloud-init/blob/040090a31f483014ec78cd353bb55bfae121bebd/cloudinit/sources/DataSourceEc2.py#L130
[00:39] <meena> holmanb: what does a dhclient-script look like?
[00:40] <holmanb> meena: by default in cloud-init, it looks a lot like /bin/true ;)
[00:41] <holmanb> we use that as a hack to limit side-effects
[00:41] <meena> holmanb: then why does it need special-casing…?
[00:41] <holmanb> hrm?
[00:41] <holmanb> what do you mean by special-casing?
[00:41] <meena> or rather: What does it look like on EC2 that it needs special-casing?
[00:42] <holmanb> errr, I think you may be asking the same thing I am?
[00:42] <holmanb> I'm wondering why this behavior is specific to ec2
[00:43] <holmanb> the /bin/true reference: https://github.com/canonical/cloud-init/blob/main/cloudinit/net/dhcp.py#L150
[00:43] <minimal> cloudinit/net/dhcp.py also uses "-sf /bin/true"
[00:43] <minimal> snap :-)
[00:43] <holmanb> :)
[00:45] <minimal> holmanb: not directly related, but when I looked at the dhclient related stuff recently I was confused as to whether IPv6 is ever used (as then dhclient would need "-6" option)
[00:45] <meena> why use -sf then to begin with??
[00:45] <minimal> meena: i think he means to avoid any script being unexpectedly used
[00:46] <holmanb> yeah, avoiding using the default script is I think the end goal - there isn't a way to disable running the script, so it just uses /bin/true as a no-op
[00:46] <holmanb> minimal: I don't htink v6 is used yet
[00:46] <minimal> if you don't specify "-sf" at all then /sbin/dhclient-script is used if it exists
[00:47] <holmanb> and since avoiding calling /sbin/dhclient-script was the goal, which freebsd didn't support, I think that's why this freebsd-specific call ended up in the ec2 datasource
[00:47] <holmanb> looking at the commit history that's the story I'm seeing anyways
[00:47] <minimal> holmanb: ok, make sense. I was just starting to sketch out udhcpc and dhcpcd support and trying to understand current dhclient behavoiur as part of that
[00:48] <holmanb> minimal: +1 nice, udhcp and dhcpcd are the interesting ones on the ubuntu side as well
[00:49] <holmanb> however some sad news on the dhcpcd side
[00:49] <holmanb> the last post on the mailing list
[00:49] <minimal> let me check..........but I can guess what it is about
[00:50] <meena> either someone died, or they're ending development
[00:50] <holmanb> somewhere in between, yeah
[00:50] <holmanb> https://roy.marples.name/archives/dhcpcd-discuss/0003457.html
[00:50] <holmanb> :/
[00:51] <meena> oh gosh
[00:51] <holmanb> updated on github as recently as 3 months ago by Roy
[00:51] <minimal> oh yeah, I read that at the time, I thought something had happened recently
[00:53] <holmanb> not that I know of
[00:54] <meena> holmanb: so, to summarize: https://github.com/canonical/cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst . DHCP needs to move into distro.
[00:56] <meena> seeing as the Azure people are going to rip out their special-casing (blacklist_driver[s]), I'm going to focus on moving get_interfaces/get_interface(s)_by_mac() into distro. All the ground-work is now there in BSD.
[00:56] <meena> And I can probably happily ignore some weird Linux weirdnesses, especially where they are completely undocumented.
[00:56] <holmanb> undocumented weirdness is where the fun is at
[00:57] <meena> holmanb: aaaaaaand that's why i like BSD… if something is undocumented, it's a bug, but even so, at least the code is easy to read and understand… and FIND.
[00:58] <holmanb> heh :D
[00:59] <minimal> well what I was going to point out is that both dhclient and udhcpc handle IPv4 and IPv6 via two different binaries/cli calls ("dhclient" and "dhclient -6", "udhcpc" and "udhcpc6") whereas dhcpcd does/can do both via a single call
[00:59] <holmanb> minimal: yeah, that's one of the reasons for the dhcpcd preference on our side as well
[01:00] <minimal> that was why I was tryingf to figure out if existing dhclient code used "-6" or not, and if so in which situation/order
[01:00] <minimal> as dropping dhcpcd in "out of the box" would try both v4 & v6 unless configured othewise
[01:01] <holmanb> minimal: I'll be queuing up some time for provisional dhcpcd support within the next month or two
[01:01] <holmanb> minimal: I was just comparing the man pages side by side and noticed that as well :-)
[01:01] <holmanb> never used cd myself
[01:01] <holmanb> dhcpcd
[01:02] <minimal> yeah I've not had much time to do clound-init stuff recently, only got rid of other stuff yesterday so want to get some backlogged c-i changes out as PRs in the next week or so
[01:02] <holmanb> we have datasource-specific dhclient calls scattered about as well, which complicate the task a bit
[01:04] <minimal> holmanb: my brief look into udhcpc/dhcpcd was also why I started wondering about network-config v2 DHCP settings as well (and then how they'd appear in eni so I could check they'd then get acted upon correctly in Alpine)
[01:05] <minimal> ^ IPv6 DHCP related settings I mean
[01:05] <minimal> well IPv6 SLAAC/DHCPv6/RA etc
[01:06] <holmanb> :)
[01:07] <minimal> but 1st to get those other code changes out the door....
[01:14] <meena> I'm fairly certain, btw, that FreeBSD's dhclient can't do DHCPv6 out of the box. You'd need to install something else… which could turn into a chicken egg problm
[01:14] <minimal> meena: no "-6" option for it?
[01:15] <meena> minimal: nope
[01:15] <minimal> it's ISC dhclient isn't it?
[01:16] <meena> https://github.com/freebsd/freebsd-src/tree/main/sbin/dhclient
[01:16] <meena> good grief… /*	$OpenBSD: dhclient.c,v 1.63 2005/02/06 17:10:13 krw Exp $	*/
[01:17] <holmanb> goodness
[01:17] <meena> like, it's been updated, or at least secured, and all, but… brrrr…
[01:17] <minimal> .\" Copyright (c) 1997 The Internet Software Consortium.
[01:17] <minimal> so its based on ISC's code, perhaps a prehistoric version
[01:18] <meena> #include <sys/capsicum.h> ← "secured"
[01:18] <holmanb> ah, yeah there's a comment about capsicum on the manpage as well
[01:18] <holmanb> falls back to a chroot for sandboxing
[01:18] <minimal> so I guess they forked it before ISC added IPv6 support
[01:19] <meena> they forked it before IPv6 was standardized, minimal.
[01:20] <minimal> meena: doesn't make my statement incorrect though ;-)
[01:20] <holmanb> LOL
[01:20] <meena> imagine sifting thru 25 years of ISC dhcplient code to try add IPv6 support today.
[01:21] <minimal> wonder if there's some more recent "useful" DHCPv4 options not supported then
[01:25] <meena> other than -sf? 🤷🏻♀
[01:26] <meena> -1 seems useful…
[01:26] <minimal> well I'm guess it supports RFC3442
[01:26] <minimal> meena: yupe, the c-i code uses "-1" when it calls dhclient
[01:28] <minimal> it runs "/usr/sbin/dhclient -1 -v -lf /run/dhclient.lease -pf /run/dhclient.pid eth0 -sf /bin/true" on Linux
[01:29] <holmanb> I need to run
[01:29] <meena> i need to sleep
[01:29] <holmanb> seeya o/
[01:29] <minimal> cya
[15:58] <blackboxsw> aciba: ubuntu/devel branch merge to tip of main. I'm syncing it now, and will rekick integration test runners
[16:01] <aciba> blackboxsw: let's see the green color there :)
[16:27] <meena> minimal / holmanb: https://reviews.freebsd.org/D22012


[01:31] <valorie> Nothing like the Cult of Emacs tho.....
[01:33] <valorie> mparillo: linux tool wars in general are funny to me
[01:34] <valorie> all I need is kate
[01:34] <valorie> well, kate and konversation
[01:51] <arraybolt3> and element
[01:51] <arraybolt3> *ducks*
[03:13] <mmikowski> y
[03:14] <arraybolt3> n
[08:54] <tsimonq2> mmikowski, arraybolt3 https://bugs.launchpad.net/ubuntu/+source/calamares-settings-ubuntu/+bug/2060928
[08:54] -ubottu:#kubuntu-devel- Launchpad bug 2060928 in calamares-settings-ubuntu (Ubuntu) "First boot after OEM install should have a desktop icon installed for finishing setup" [Undecided, New]
[13:42] <Eickmeyer> sgmoore: I was trying to say before Matrix went down that the launchers tend to be intermittent whether they want to launch snaps or not (not just Firefox), so that might be the issue. So intermittent that I haven't been able to pinpoint a cause. Workaround: krunner
[13:44] <sgmoore> Sadly I found the issue. https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/2060970
[13:44] -ubottu:#kubuntu-devel- Launchpad bug 2060970 in kubuntu-meta (Ubuntu) "Kubuntu: Firefox does not launch..  not connected to the gnome-42-2204 content interface" [Undecided, New]
[13:45] <Eickmeyer> sgmoore: Oof, not having that issue in Ubuntu Studio. Fresh install.
[13:46] <sgmoore> I think anyone who uses calamares with pkgselect option and chooses Krita will be affected.
[13:46] <sgmoore> You don't use calamares as I understand
[13:47] <Eickmeyer> Correct.
[16:07] <mmikowski> Thanks tsimonq2!
[20:02] <valorie> arraybolt3: I've not yet tried element
[20:02] <valorie> one change at a time....
[20:03] <valorie> still hoping that konvi folds in matrix so I don't have to change softare; just update