[05:23] <mborzecki> morning
[05:32] <jamesh> mborzecki: hi.  I saw in a bug report that you'd been looking at the GNOME 3.38 Wayland incompatibility.  I've filed https://gitlab.gnome.org/GNOME/mutter/-/issues/1454 upstream to see if we can get things fixed there.  We could presumably do something on the snapd side too though.
[05:33] <mborzecki> jamesh: thanks, so the problem is mutter dropped the abstract socket for Xwayland completely?
[05:33] <jamesh> mborzecki: yes.
[05:34] <mborzecki> jamesh: heh, tough luck, since it's in fedora 33 now, and probably other distros that ship with 3.38
[05:34] <jamesh> like Ubuntu 20.10
[05:34] <mborzecki> oops, school run, back in a bit
[05:34] <jamesh> (although we don't default to a Wayland session)
[06:02] <mborzecki> re
[06:21] <mborzecki> jamesh: otoh, at least the yuzu snap that was tried in https://bugzilla.redhat.com/show_bug.cgi?id=1883621 should have picked up wayland socket?
[06:23] <jamesh> mborzecki: based on the output, it's skipping Qt's Wayland backend and using X11
[06:24] <jamesh> the rest of the message show it using the XCB backend, which is X11
[06:28] <mborzecki> jamesh: heh, so I tried setting QT_QPA_PLATFORM=wayland and it seems to have no effect
[06:28] <jamesh> the snap may not ship the Wayland plugin
[06:29] <mborzecki> jamesh: there's this message `Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.` but it's not clear whether those plugins were found, or whether that's some general list
[06:31] <jamesh> mborzecki: presumably it has its plugins in $SNAP/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms or something similar
[06:31] <mborzecki> jamesh: fwiw /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqwayland-generic.so exists in the snap
[06:34] <jamesh> mborzecki: this is kind of beside the point though: yes, any of those individual snaps could work if they were ported to Wayland.  No, that wouldn't solve the underlying problem
[06:35] <jamesh> mborzecki: I'd like to see this fixed upstream, but there's likely to be systems hanging around for a long time with broken X11 access
[06:36] <mborzecki> jamesh: hm wodnering whether there's anything in snapd we could do besides printing warning
[06:36] <jamesh> mborzecki: bind mount host system /tmp/.X11-unix into the sandbox
[06:36] <jamesh> which kind of breaks our "snaps can do anything with they private /tmp" promise
[06:37] <mborzecki> yeah, but maybe it's a legitimate exception
[06:38] <mborzecki> affected systems are those on recent enough mutter, so maybe not that many yet and we have a bit of time left
[06:38] <jamesh> Perhaps tie it to the interfaces that grant x11 access
[06:38] <jamesh> It's recent enough Mutter _and_ using Wayland
[06:38] <jamesh> I'm not sure if Fedora is Wayland by default yet
[06:38] <mborzecki> and there's gnome 38.1 coming too
[06:39] <mborzecki> iirc it is, and hopefully f33 doesn't ship until gnome 38.1?
[06:40] <mborzecki> reminds me i should update fedora packages to 2.47
[06:46] <mborzecki> jamesh: i'll ping zyga when he's around, we can always propose a fix on the snapd side too and then discuss with pedronis/mvo whether it should land
[06:46] <jamesh> sounds good
[06:47] <mborzecki> jamesh: hopefully it's fairly simple tweak in x11/wayland interfaces mount profiles
[06:47] <jamesh> mborzecki: I wouldn't think any change would be necessary in the wayland interface?
[06:49] <mborzecki> jamesh: don't remember which interface assumes the 'handling' of Xwayland
[06:50] <jamesh> mborzecki: It shouldn't care if it is talking to Xorg on bare metal or Xwayland
[06:51] <jamesh> If you're running a snapped Xwayland, you'd need an x11 slot for other snaps to connect to
[06:52] <jamesh> (of course, this is where things get complicated: if it isn't the implicit :x11 slot, what directory do you bind mount on the plug side?
[06:58] <pstolowski> morning
[06:58] <mborzecki> pstolowski: hey
[06:59] <mborzecki> need to take some paperwork to my accountant, i'll be online in a bit
[07:33]  * dot-tobias says morning
[08:09] <mborzecki> re
[08:27] <pedronis> zyga: hi, is there something I should re-review or review for you?
[08:35] <zyga> good morning
[08:35] <zyga> pedronis not yet, I will finish one or maybe both older branches
[08:35] <zyga> pedronis they are close but not yet
[08:35] <pedronis> ok
[08:35] <zyga> mborzecki, jamesh: hey guys
[08:35] <jamesh> hi zyga
[08:36] <zyga> are you talking about the xwayland change in mutter recently?
[08:37] <zyga> jamesh: is the bind mounted thing a socket?
[08:37] <zyga> we need apparmor permission for the socket original bind path
[08:38] <zyga> as bind mounting doesn't change that
[08:38] <jamesh> zyga: yeah.  Mutter/gnome-shell 3.38 no longer creates the abstract "\0/tmp/.X11-unix/Xn" socket
[08:38] <zyga> right
[08:38] <zyga> I read the bug thread in the morning
[08:39] <zyga> (I had some calls and mandatory walks)
[08:39] <zyga> is the abstract socket path a default value of some environment variable?
[08:39] <zyga> er
[08:39] <zyga> not abstract
[08:39] <zyga> could we set an environment variable and bind mount the non-abstract socket somewhere?
[08:39] <zyga> I would prefer not to bind mount it to /tmp
[08:40] <zyga> though not strongly, just feels dirty / old design
[08:40] <zyga> sockets go to run nowadays
[08:40] <mborzecki> zyga: hm yeah, good question, maybe we could overwrite the location somehow
[08:40] <zyga> worth checking what the libraries do
[08:40] <mborzecki> zyga: and if it was run, it should work out of the box without dirty tricks
[08:40] <zyga> I have some patches to finish from last night but it's something we could do for the next release for sure
[08:40] <mborzecki> (sans some apparmor policy tweaks)
[08:40] <zyga> mborzecki yeah
[08:42] <jamesh> zyga: if an app is run with e.g. DISPLAY=:0, it will attempt to connect to "/tmp/.X11-unix/X0" as an abstract namespace and regular socket (not sure which order it tries)
[08:42] <jamesh> DISPLAY=:1 would try .../X1, etc.
[08:43] <mborzecki> jamesh: right, the question is whether we can cantrol the /tmp/.. prefix with some env variable
[08:43] <mborzecki> or maybe it's a well known convention and here's no way around it
[08:43] <mborzecki> s/here/there/
[08:44] <jamesh> Xorg and Xwayland listen on both by default.  In the new Mutter, they're attempting to start Xwayland lazily: open the sockets, wait for someone to try and connect, then have Xwayland adopt the file descriptors
[08:45] <jamesh> they had this implemented with the two sockets, but it was only polling the abstract namespace socket.  This meant clients that connected to the regular socket before Xwayland started would hang
[08:45] <jamesh> To fix that, they just got rid of the abstract namespace socket
[08:45] <mborzecki> jamesh: if i understood zyga's idea correctly, we could try to bind /tmp/.X11-unix to some location under /run/<snap?>, and if possible set an env variable to redirect the app there, so as to avoid polluting /tmp inside the snap mount ns
[08:45] <jamesh> The bug I filed is proposing to revert that and just fix it to poll both sockets
[08:46] <zyga> mborzecki yes
[08:46] <zyga> jamesh right, I think that's totally fine as well
[08:47] <jamesh> I don't think there is any environment variable to redirect it from /tmp: if there was, I'm sure desktops would have started using it long ago
[08:48] <jamesh> so mounting elsewhere would require putting a symlink in /tmp
[08:49] <pedronis> mborzecki: hi, are you working on a follow up to #9443 to move key saving?
[08:50] <mborzecki> pedronis: yes, that and a followup to #9440 to replace lazy bootloader lookup with ForGadget() when creating observers (though i should open that in a short bit since the code is ready)
[08:51] <pedronis> mborzecki: thx
[08:53] <pedronis> pstolowski: hi, are you blocked on me atm?
[08:55] <jamesh> zyga: here's the code where it tries to open the display: https://gitlab.freedesktop.org/xorg/lib/libxcb/-/blob/master/src/xcb_util.c#L226 -- the socket path is hard coded.
[08:55] <pstolowski> pedronis: not really, but thanks for asking! do you intend to look at services PR (would be great), or are you ok if it lands with existing reviews? that will wait for 2.48 branch anyway, so not urgent, and not blocking
[08:56] <pedronis> pstolowski: I'll try to look at it but not this week
[08:56] <pedronis> pstolowski: I will try to re-review #9391 though
[09:04] <pstolowski> pedronis: i'm currently busy with the recent issues.. i think we need to think about undo of snap remove
[09:06] <pstolowski> and yes, landing #9391 would be nice
[09:09] <mborzecki> pstolowski: need reviews for that?
[09:11] <pstolowski> mborzecki: it got +1, but is missing review from Samuele at this point. but every review is welcome :)
[09:21] <pedronis> pstolowski: yes, I saw from the SU notes, that you are looking into some bugs :/
[09:23] <zyga> jamesh unfortunate
[09:23] <zyga> jamesh let's see what upstream response is
[09:29] <mborzecki> jamesh: thanks for finding that code
[09:30] <jamesh> mborzecki: there's similar code in libxtrans: I'm not actually sure which one usually gets run for modern apps.  In both cases, the paths are hard coded into the library
[09:33] <ijohnson> morning folks
[09:33] <ijohnson> #9471 and #9472 are both really simple and need 2nd +1s
[09:33] <ijohnson> :-)
[09:36] <mborzecki> ijohnson: thanks, did 9471, and 72 now too
[09:37] <mborzecki> ijohnson: have you heard back from hellsworth about dhcp & nm maybe?
[09:38] <zyga> ijohnson good morning!
[09:41] <ijohnson> Hey zyga and mborzecki
[09:41] <ijohnson> mborzecki thanks! I'm talking with hellsworth later today re nm ran out of time yesterday
[09:42] <mborzecki> ijohnson: great, thanks, i suspect we'll need to copy /var/lib/dhcp too, but better to have a confirmation
[09:42] <ijohnson> Yeah indeed
[09:42] <mborzecki> ijohnson: fwiw it's already listed in writable-paths too
[09:48] <ijohnson> yeah it's easy enough to add to that list later when we know it's needed, because we could need other things for example too
[09:54] <ijohnson> pedronis: hi, do you want to wait until after the sprint to discuss 9458 and exposing a way to build a testkeys trusting snapd snap for CI only?
[09:58]  * zyga reboots
[10:04] <ijohnson> oh zyga I forgot to ask how is your thumb doing!?
[10:05] <zyga> ijohnson still in one piece
[10:05] <ijohnson> that is a good thing
[10:05] <zyga> just a cut
[10:05] <zyga> the nail is the worst part
[10:05] <zyga> it heals so slowly
[10:05] <ijohnson> yeah that sounds really painful
[10:05] <zyga> brand new knife
[10:05] <ijohnson> knife works good though it sounds!
[10:05] <zyga> haha, yeah
[10:05] <ijohnson> so I assume the knife is okay too
[10:06] <ijohnson> my grandpa used to tell this story about this guy who worked on a farm wearing and cut his hand up while wearing gloves and he complained "my hand will grow back but this glove never will"
[10:07] <ijohnson> well presumably my grandpa still tells the story he's still around after all :-)
[10:08] <zyga> ijohnson that's a gruesome story :)
[10:08] <ijohnson> haha yeah
[10:15] <dot-tobias> hi ijohnson 👋
[10:16] <ijohnson> hey dot-tobias sorry I saw your message yesterday but didn't get a chance to finalize all the commands to debug your issue, will try to finish that after a little bit this morning
[10:17] <dot-tobias> ijohnson no worries, can image you're busy – appreciate any help whenever you have the time 😊
[10:17] <ijohnson> yes of course, we hope to be releasing soon so issues like this are important to work through and solve :-)
[10:28] <mborzecki> time to drive back home
[10:29] <mborzecki> back online in a bit
[10:29]  * zyga-x240 writes some tests
[10:37] <pedronis> ijohnson: yes
[10:37] <ijohnson> pedronis: ok
[10:52] <pedronis> ijohnson: I mean, I looked at it, I have opionions, but this week is probably not a good time to discuss them
[10:52] <ijohnson> that's fine, I assumed as much
[10:54] <ijohnson> zyga: +1 to 7614
[10:54] <zyga> ijohnson I spoke with mvo
[10:54] <zyga> it should land after core 20 releases
[10:54] <zyga> to stay on the safe side
[10:54] <zyga> I will add a label
[10:54] <zyga> thanks!
[10:54] <ijohnson> zyga: no problem, I guess it will live to see it's first birthday then
[10:56] <zyga> I've replied to the dprintf comment as well
[10:56] <zyga> there's a bit of function pointer thing coming up later, dprintf is used in v1 mode
[10:56] <zyga> v2 uses a different implementation with essentially the same idea (add this major:minor thing)
[10:56] <ijohnson> ah ok, I wasn't sure why but if that machinery will be changed, just seems that dprintf is more generically useful than just for udev
[10:57] <zyga> that's true
[10:57] <zyga> it's pretty neat actually
[10:57] <zyga> oh well, after core20 we can dust this off
[10:57] <zyga> thank you for the review
[10:57] <zyga> I hope I didn't miss anything, this branch survived a few small changes to the original code
[10:58] <ijohnson> yeah it all looks good to me, I look forward to the day we can get rid of the shell script based udev helper entirely :-)
[10:58] <zyga> well
[10:58] <zyga> me too :)
[10:58] <zyga> actually there are some things we could do that would also fix the udev raciness problem
[10:58] <zyga> but that's not close yet
[11:01] <ijohnson> mvo: pedronis: can we document resilience.vitality-hint for folks to use generically ? or is there more work that will come to that setting / feature that necessitates not mentioning it to the world yet
[11:02] <mvo> ijohnson: I think documenting this is a good idea
[11:02] <ijohnson> ok, I will try to write something maybe degville can take a look and integrate into the relevant area
[11:04] <mvo> \o/
[11:04] <mvo> thanks
[11:08]  * zyga coffee
[11:10] <zyga> perfect while spread runs :)
[11:10] <mborzecki> re
[11:18] <ijohnson> degville: I just made edits directly to the system-options page, can you review my proposed addition? It's a little awkward to phrase/explain the feature in a way that doesn't just say "when you set this setting then we set OOMScoreAdjust to this thing"
[11:18] <degville> ijohnson: yes, of course - thanks for making those updates.
[11:18] <ijohnson> thanks!
[11:19]  * ijohnson still thinks it's magic that changes to the forum get reflected on the snapcraft.io/docs page immediately
[11:33]  * zyga puts on his canadian pullover
[11:33] <zyga> that time of the year
[11:42] <ogra> ...when the lawn mowers magically turn into leaf blowers ...
[11:56] <zyga> at least they don't suck ;)
[11:57] <zyga> cachio: https://github.com/snapcore/snapd/pull/9475
[11:57] <zyga> ijohnson: if you have a moment ^ that's fairly short and simple
[11:58] <cachio> zyga, nice, thanks, I'll take a look
[11:59] <ijohnson> looking
[12:13] <pedronis> pstolowski: I reviewed #9391
[12:20] <pstolowski> pedronis: ty
[12:45] <zyga> brb, see you at standup
[14:20]  * zyga runs more tests and thinks of lunch
[14:20] <zyga> it's getting late
[15:37] <zyga-x240> a little bit more and things should work
[15:59]  * cachio lunch
[16:16] <vidal72[m]> why bind mounting /tmp/.unix-x11 would break "snaps can do anything with they private /tmp" promise?
[16:18] <vidal72[m]> they would still able to do anything except removing that dir but why someone would want to do that?
[16:19] <vidal72[m]> it's likely that nobody would even notice there is new dir there
[16:21] <zyga> vidal72[m] I think because /tmp was empty and had no meaningful content
[16:21] <zyga> now it does not
[16:22] <vidal72[m]> yeah but why it matters?
[16:23] <vidal72[m]> from user/developer perspective?
[16:24] <vidal72[m]> it's the same like you when add any other subpath elsewhere which didn't existed but exist now
[16:26] <vidal72[m]> for app this should be invisible change
[16:44] <zyga-x240> vidal72[m]: I think it's not that, it's just that we try to "tame" the system by defining some rules (any rules are good really)
[16:44] <zyga-x240> vidal72[m]: I think that by having a swarm of exceptions we revert back to the original moving zoo
[16:45] <zyga-x240> personally I would prefer if the X11 socket was configurable
[16:45] <zyga-x240> or if the location was more sensible
[16:48]  * zyga-x240 debugs more tests
[16:49] <vidal72[m]> but shouldn't the rules be backed by some reasoning? otherwise you end up with rules for the sake of rules which are disconnected for actual needs
[16:52] <zyga-x240> vidal72[m]: well, in this specific case, it's clear that /tmp is not a place for sockets
[16:52] <zyga-x240> it's not an accident we've been using /run for that for a long while now
[16:52] <zyga-x240> I realize X11 predates that
[16:53] <zyga-x240> vidal72[m]: just like we are evolving the stack to support containerized apps elsewhere, I don't see why changing the location of the X11 socket, over time, is out of the question
[16:56] <vidal72[m]> I think the expectation is x11 will die over time which is why such fundamental changes are unlikely
[16:56] <zyga-x240> vidal72[m]: well, I think that X11 will be with my grandchildren
[16:57] <zyga-x240> and that changing a socket path _location_ to include additional one is fairly trivial
[16:57] <zyga-x240> even if that has to be made across a few libraries
[16:57] <zyga-x240> that doesn't mean I think it should be done
[16:57] <zyga-x240> but I do think we should not size it as something it is not
[16:58] <vidal72[m]> even if it's done then it's not solution for urgent snap issue which occurs right now
[16:59] <zyga-x240> I think the current issue is easier to solve by reverting the change
[16:59] <vidal72[m]> reverting the change break flatpak
[16:59] <vidal72[m]> which is why it was done in first place
[16:59] <zyga-x240> I'm not an expert on those libraries but I believe it's possible to handle both locations, is it not?
[17:00] <zyga-x240> perhaps jamesh should discuss the details
[17:00] <vidal72[m]> and gnome devs are quite close to flatpak
[17:02] <zyga-x240> I'm sure all changes are done in good faith
[17:03] <vidal72[m]> I think gnome devs weren't aware that it affects snap but if they have to chose to support only one thing then...
[17:03] <zyga-x240> I really doubt in the software world there's no way to solve this
[17:04] <zyga-x240> I'm more surprised it's a change now
[17:04] <vidal72[m]> beside that snap requiring abstract socket is problem on its own and you didn't saw problem with fixing it on snap side back then https://forum.snapcraft.io/t/xorg-abstract-socket-is-mandatory-for-running-snaps/4580/9
[17:04] <zyga-x240> wasn't it a long-standing location
[17:04] <zyga-x240> or did it suddenly break now due to other changes?
[17:05] <zyga-x240> vidal72[m]: my opinion there was pure pragmatism, we can still bind mount to /tmp
[17:05] <zyga-x240> vidal72[m]: but I really would prefer not to, at least without considering the alternatives or a bigger framework that could track such hacks over time
[17:09] <vidal72[m]> it stopped working because gnome mutter disabled support for using xorg abstract socket for xwayland, they weren't aware someone is relying on it
[17:10] <zyga-x240> vidal72[m]: right, but was it a problem for flatpak just now or was this always broken in some way?
[17:10] <zyga-x240> you said it was done to fix flatpak somehow
[17:10] <vidal72[m]> always broken
[17:11] <zyga-x240> Guess not that many people run flatpak and wayland then
[17:11] <zyga-x240> perhaps by 2022 wayland is complete enough to switch over, I would really like that
[17:11] <zyga-x240> for 2020 the usability issues were too grave, IIRC
[17:12] <ogra> well, your prob is Xwayland, not wayland after all 😉
[17:12] <vidal72[m]> yes it;s xwayland + on-dmand launch gnome mutter feature which I think was experimental until recently
[17:13] <ogra> (i'm pretty sure native wayland apps will just run fine ... its just that there are so few still 🙂 )
[17:13] <vidal72[m]> it was long unfixed until gnome core dev hitted it :)
[17:13] <zyga-x240> very unusual ;-) (just kidding)
[17:13] <zyga-x240> I mean, it's just a bug
[17:14] <zyga-x240> people with the right experience will look at it
[17:14] <ogra> yeah
[17:14] <zyga-x240> from snapd point of view, we can always add hacks
[17:14] <zyga-x240> my entire point is that I'd love to have structure to those
[17:14] <ogra> james and daniel are already deeply in it it seems
[17:14] <zyga-x240> I would love some tea with milk
[17:14] <zyga-x240> I think so, the problem is in good hands
[17:18] <vidal72[m]> I would love to see this "hack" in snap as my system has x11 abstract socket disabled for increasing security
[17:19] <zyga-x240> vidal72[m]: perhaps I'm mistaken but I believe wayland is pretty much insecure until the entire transition is complete, including input, which is still years away
[17:19] <zyga-x240> so while good, the security situation is not terribly improved yet
[17:20] <ogra> people should just use mir ....
[17:20] <ogra> 😄
[17:21]  * zyga-x240 makes small progress on improving snapd test suite
[17:21] <vidal72[m]> zyga-x240: I don't use wayland at all, I mean I disabled xorg abstract socket
[17:21] <zyga-x240> vidal72[m]: oh, I misunderstood then, how is that better?
[17:23] <vidal72[m]> because restricting access to unix socket (which is just a file) is much easier that restricting access to abstract socket which needs new network namespace
[17:23] <zyga-x240> vidal72[m]: I see, that's true indeed
[17:24] <zyga-x240> in snapd, with apparmor, we can restrict both, I believe, but that applies to snap apps
[17:54] <cachio> zyga-x240, when you have some time, could you please take another look to #9425
[17:54] <cachio> tx
[17:54] <zyga-x240> sure
[17:55] <jdstrand> zyga-x240: we can do both provided we have the af_unix patch. without that, only named sockets (not abstract or anonymous)
[17:56] <zyga-x240> I see
[18:01] <zyga-x240> done
[18:01] <zyga-x240> cachio: ^
[18:01] <cachio> tx
[18:05] <zyga-x240> cachio: could you please look at https://github.com/snapcore/snapd/pull/9478
[18:05] <cachio> sure
[18:07] <jdstrand> zyga-x240: thanks for choosing 14 instead of 60 days for forcing a refresh. please also see https://forum.snapcraft.io/t/wip-refresh-app-awareness/10736/44
[18:07]  * jdstrand meant to comment on that sooner
[18:07] <zyga-x240> jdstrand: looking
[18:09] <zyga-x240> thank you, replied!
[18:10] <zyga-x240> jdstrand: I think that the best outcome is that this gathers interest of app developers and we can consolidate snapctl APIs into popular snaps, such as chrome, so that they can provide a more complete experience
[18:11] <jdstrand> zyga-x240: thanks! iirc, isn't the current feature no longer experimental in 2.47? does it make sense to mention that there as well? (since stable is still 2.46)?
[18:11] <zyga-x240> jdstrand: it will be experimental for at least one more release
[18:11] <zyga-x240> jdstrand: (after this one)
[18:11] <zyga-x240> jdstrand: we need --ignore-running switch to snap refresh, among others
[18:11] <jdstrand> zyga-x240: yes. snaps ideally would be involved because they know best what should happen and how to respond
[18:11] <zyga-x240> jdstrand: we need some selinux changes for the monitoring being on by default
[18:11] <zyga-x240> jdstrand: my thoughts exactly
[18:12] <zyga-x240> jdstrand: so it's not something we will enable yet but I hope that it can be done soon, now that core20 seemingly is close to release, and more review time is available
[18:12]  * jdstrand nods
[18:14] <jdstrand> I mean, there is always going to be cases where the snap publisher isn't the upstream and they don't really have the capacity to integrate with snapctl, etc as fully as perhaps is desired, so notifications will always be helpful (and a nice fallback for those snaps that do try to do something, but are buggy/etc)
[18:14] <zyga-x240> jdstrand: I was hoping that with the help of the desktop team
[18:14] <zyga-x240> jdstrand: we could have an action on the notification
[18:15]  * jdstrand nods
[18:15] <zyga-x240> jdstrand: and interacting with the action would send X11/wayland message asking the application to close gracefully
[18:15] <zyga-x240> jdstrand: (which would be done without any privilege escalation, locally in the session)
[18:15] <zyga-x240> jdstrand: but that has no guarantee to close the app, simply to ask it
[18:15] <jdstrand> that could be nice and would be a great improvement
[18:15] <zyga-x240> I had a look at that and had a depression
[18:15] <zyga-x240> :D
[18:16] <jdstrand> heh
[18:16] <zyga-x240> two decades ago I bought a windows petzold book on how winapi looks like
[18:16] <zyga-x240> and that had such message in first lesson
[18:16] <zyga-x240> X11 does not
[18:16] <zyga-x240> so ;)
[18:16] <zyga-x240> well, I'm sure the desktop team is more knowledgeable than I am
[18:16] <zyga-x240> and that something can be arranged
[18:17] <zyga-x240> (i was especially fond of recalling how windows coalesces messages that invalidate each other, before those are delivered to the application)
[18:17] <zyga-x240> anyway,
[18:17] <zyga-x240> :D
[18:18] <zyga-x240> cachio: one more but not priority: https://github.com/snapcore/snapd/pull/9479
[18:18] <zyga-x240> and this is really early code
[18:19] <jdstrand> I suspect you'd need shell help there rather than just taking it on. X11 should give you everything you'd need to do something (perhaps drastic), but I suspect there would be obstacles doing that on wayland. perhaps there are f.d.o apis for that...
[18:19] <cachio> zyga-x240, nice
[18:19] <cachio> I'll check that later
[18:19] <cachio> I need to go to the kinesiologist now
[18:20] <zyga-x240> kenvandine: ^ do you know if x11/wayland have a way to gracefully ask an application to quit, assume all we know is the PID
[18:20] <zyga-x240> cachio: that's allright, it's really early code
[18:20] <zyga-x240> kenvandine: something that might trigger an app to ask the user to save a document or confirm
[18:20]  * cachio afk -> kinesiologist
[18:21] <kenvandine> zyga-x240: yeah, there is
[18:21] <kenvandine> i don't recall what off hand though
[18:21] <zyga-x240> kenvandine: \o/
[18:21] <zyga-x240> kenvandine: if you recall I'd love to know
[18:21] <zyga-x240> I could really use that
[18:21] <kenvandine> but when the user logs out the session triggers all the apps to block until saving
[18:21] <zyga-x240> oooh
[18:21] <zyga-x240> that's perfec
[18:21] <zyga-x240> *perfect, I'll try to integrate that
[18:21] <kenvandine> :)
[18:22] <kenvandine> it used to be triggered by the gnome-session package
[18:22] <zyga-x240> I got lost in various standards and arcane specification
[18:22] <kenvandine> but i am not sure now how it works
[18:22] <kenvandine> probably some glib API
[18:23] <jdstrand> kenvandine: fyi, the libreoffice lzo change was merged in the review-tools. emi is working to get that in a store pull. we could do manual reviews for a while if needed
[18:23] <kenvandine> cool
[18:23] <kenvandine> hellsworth was waiting on that
[18:24] <kenvandine> but i'll tell her to go for it
[18:24] <jdstrand> kenvandine: oh, is she now taking care of libreoffice?
[18:24] <kenvandine> yeah
[18:26] <kenvandine> zyga-x240: gnome-session-quit does still seem to support it
[18:26] <jdstrand> kenvandine: hat's off to her
[18:26] <kenvandine> so look at what it does
[18:26] <kenvandine> jdstrand: indeed :)
[18:26] <kenvandine> jdstrand: she's also maintaining network-manager, tough
[18:26] <zyga-x240> apt-get source $(dpkg -S $(command -v gnome-session-quit))
[18:26] <zyga-x240> thanks!
[18:26] <jdstrand> ambitious. awesome :)
[18:28] <zyga-x240> I'm sad to report that using "devel" instead of groovy does not work for source packages
[18:31]  * zyga-x240 spawns a test and takes a break
[18:31] <zyga-x240> back in 30
[19:40] <zyga-x240> re
[19:40] <zyga-x240> that was not 30 :)
[19:57] <mwhudson> how do i see the base of a snap?
[19:59] <mwhudson> ah info --verbose
[20:23] <zyga-x240> one more iteration
[20:23] <zyga-x240> mwhudson: note that there are some weird edge cases
[20:23] <zyga-x240> like base: core16 being supplied by core
[20:24] <zyga-x240> not sure if that's handled there
[20:24] <mwhudson> zyga-x240: ah i don't really mind about taht
[20:24] <zyga-x240> yeah, I think core16 never really happened
[20:46] <rogpeppe> i don't know if anyone's around, but i've got an odd problem with a raspberry pi running ubuntu core. it's been running for ages without much more issue than the occasional reboot, but just recently (after a power cut), it came back up but its service didn't come up
[20:46] <rogpeppe> i've just investigated and there's no snap command any more!
[20:47] <rogpeppe> the file /usr/bin/snap exists but that's a symlink to /snap/snapd/current and that doesn't exist
[20:47] <zyga-x240> hmm
[20:47] <zyga-x240> rogpeppe: is that a core18 system?
[20:48] <rogpeppe> uname -a prints : Linux localhost 4.15.0-1041-raspi2 #44-Ubuntu SMP PREEMPT Wed Jul 3 15:47:01 UTC 2019 armv7l armv7l armv7l GNU/Linux
[20:48] <rogpeppe> zyga-x240: i've no idea what that means :)
[20:48] <zyga-x240> rogpeppe: ok, sorry,
[20:48] <zyga-x240> it's kind of late so my questions may be silly
[20:48] <zyga-x240> did any snaps fail mounting?
[20:48] <rogpeppe> zyga-x240: np. your interaction is appreciated!
[20:48] <rogpeppe> zyga-x240: how can i tell?
[20:49] <zyga-x240> systemctl --failed
[20:49] <zyga-x240> that may show what's wrong
[20:49]  * zyga-x240 -> shower
[20:49] <zyga-x240> rogpeppe: best to file a bug with the details you can collect
[20:49] <zyga-x240> I was about to go to sleep
[20:49] <rogpeppe> yup, looks like my service failed:
[20:49] <rogpeppe> rogpeppe@localhost:/snap/snapd$ systemctl --failed
[20:49] <rogpeppe>   UNIT                           LOAD   ACTIVE SUB    DESCRIPTION
[20:49] <rogpeppe> ● snap.hydroctl.hydroserver.service loaded failed failed Service for snap application hydroctl.hydroserver
[20:49] <rogpeppe> LOAD   = Reflects whether the unit definition was properly loaded.
[20:49] <rogpeppe> ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
[20:50] <rogpeppe> SUB    = The low-level unit activation state, values depend on unit type.
[20:50] <rogpeppe> 1 loaded units listed. Pass --all to see loaded but inactive units, too.
[20:50] <rogpeppe> To show all installed unit files use 'systemctl list-unit-files'.
[20:50] <zyga-x240> is snapd.service running?
[20:50] <zyga-x240> ls /snap/snapd/current/
[20:50] <rogpeppe> nope
[20:50] <zyga-x240> is snapd mounted?
[20:50] <rogpeppe> how can i tell?
[20:50] <zyga-x240> that ls command should help
[20:50] <rogpeppe> df, i guess
[20:50] <zyga-x240> current is either a link to a mount point
[20:50] <zyga-x240> or a dangling symlink
[20:51] <zyga-x240> df works too
[20:51] <rogpeppe> looks like it might be: https://paste.ubuntu.com/p/McFB3WDSbP/
[20:52] <rogpeppe> the /snap/snapd/current file doesn't exist
[20:53] <rogpeppe> that directory just has four directories in with numeric names
[20:53] <zyga-x240> next step is to check the status of the mount units
[20:53] <zyga-x240> systemctl status snap-snapd-$number.mount
[20:53] <zyga-x240> the one that current points to is the most relevant
[20:53] <rogpeppe> with the numbers in that dir?
[20:53] <zyga-x240> yes
[20:53] <rogpeppe> there is no "current" :)
[20:54] <zyga-x240> is the current symlink entirely gone?
[20:54] <zyga-x240> oh my
[20:55] <zyga-x240> pick the largest number
[20:55] <rogpeppe> https://paste.ubuntu.com/p/mwjp9bJ3Tt/
[20:55] <zyga-x240> but I suspect something very wrong happened
[20:55] <rogpeppe> yes, the symlink is entirely gone
[20:55] <zyga-x240> so they are all mounted
[20:55] <zyga-x240> that's so weird
[20:55] <zyga-x240> can you collect journal logs (if you have persistence)
[20:55] <zyga-x240> if not that's futile
[20:55] <zyga-x240> I'd re-create the symlink to the largest number
[20:55] <zyga-x240> and restart the system to see if things get back to shape
[20:56] <zyga-x240> though no guarantees
[20:56] <zyga-x240> if that works, snap changes output would be useful
[20:56] <rogpeppe> there was a power-cut FYI
[20:56] <zyga-x240> I see
[20:56] <zyga-x240> well, something to learn each time
[20:56] <rogpeppe> how should i get journal logs?
[20:56] <zyga-x240> journalctl --list-boots should tell you if you have persistent logging
[20:56] <zyga-x240> if there's one entry you do not
[20:57] <zyga-x240> following that journalctl can be coerced to render all logs as text
[20:58] <rogpeppe> looks like persistence is enabled: https://paste.ubuntu.com/p/2tRSFgP7bB/
[20:59] <rogpeppe> i can never remember how to use journalctl :) what's the right incantation to get logs out?
[20:59] <zyga-x240> rogpeppe: journalctl -b -1 should give you logs from the boot that died due to power cut
[20:59] <zyga-x240> please collect logs, I think we can learn a lot from this failure
[20:59] <zyga-x240> and to make the system more robust
[20:59] <zyga-x240> but to do that, we need to give this problem proper resources (awake developers)
[21:00] <rogpeppe> https://paste.ubuntu.com/p/7cTd6b8Yq4/
[21:00] <zyga-x240> if you re-create current and reboot, that's useful to know as well
[21:01] <rogpeppe> unfortunately the machine is a few hundred miles away from me, so i might have to wait before rebooting
[21:01] <zyga-x240> Oct 05 12:59:14 localhost kernel: FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[21:01] <zyga-x240> I see
[21:01] <zyga-x240> you don't have to reboot
[21:02] <zyga-x240> I'm just tired and I don't remember the right units to start
[21:02] <zyga-x240> you may want to fsck that
[21:03] <rogpeppe> ah, i'll try fsck. hopefully it'll be ok to run that live.
[21:03] <zyga-x240> rogpeppe: https://github.com/snapcore/core18/blob/master/static/usr/lib/core18/run-snapd-from-snap
[21:03] <zyga-x240> that's what we run on most systems with core18 + snapd snaps
[21:04] <rogpeppe> so after i've run fsck, i should try to run that?
[21:04] <zyga-x240> what is the status off this service? https://github.com/snapcore/core18/blob/master/static/lib/systemd/system/core18.start-snapd.service
[21:04] <zyga-x240> it's invoked from this systemd unit
[21:04] <zyga-x240> (that was the part I was not sure of)
[21:04] <rogpeppe> fsck refuses to run with the filesystem still mounted
[21:05] <zyga-x240> rogpeppe: you should be able to umount that briefly, that's boot and it is not used now
[21:07] <rogpeppe> fsck doesn't seem to like me:
[21:07] <rogpeppe> root@localhost:/snap/snapd# fsck /dev/mmcblk0p1
[21:07] <rogpeppe> fsck from util-linux 2.31.1
[21:07] <rogpeppe> what does it mean by "
[21:07] <rogpeppe> root@localhost:/snap/snapd# fsck /dev/mmcblk0p1
[21:07] <rogpeppe> fsck from util-linux 2.31.1
[21:08] <rogpeppe> what does it mean by "fsck from util-linux 2.31.1" ?
[21:08] <zyga-x240> hmmm
[21:08] <zyga-x240> not sure
[21:08] <zyga-x240> can you check the status of core18.start-snapd.service please
[21:08] <zyga-x240> last thing I'd like to know before going to sleep
[21:09] <rogpeppe> sorry, how do i do that?
[21:09] <zyga-x240> systemctl status $unit_name
[21:09] <zyga-x240> systemctl status core18.start-snapd.service
[21:09] <rogpeppe> ah, got it
[21:10] <rogpeppe> it's been too long
[21:10] <zyga-x240> no worries
[21:10] <rogpeppe> https://paste.ubuntu.com/p/5xTNkyqdqg/
[21:11] <zyga-x240> hmm
[21:11] <zyga-x240> ls -ld /var/lib/snapd/state.json
[21:11] <zyga-x240> (it should not be empty)
[21:11] <rogpeppe> -rw------- 1 root root 43119 Oct  7 15:11 /var/lib/snapd/state.json
[21:13] <zyga-x240> can you try one more thing:
[21:13] <zyga-x240> please run: /snap/snapd/(pick largest number)/usr/bin/snap debug state /var/lib/snapd/state.json
[21:14] <zyga-x240> that will tell us what happened
[21:14] <zyga-x240> it looks like snapd disabled itself somehow
[21:16] <rogpeppe> q .
[21:16] <rogpeppe> root@localhost:/snap/snapd# /snap/snapd/9169/usr/bin/snap debug state /var/lib/snapd/state.json
[21:16] <rogpeppe> ID   Status  Spawn  Ready  Label  Summary
[21:16] <zyga-x240> that's that? no output?
[21:16] <rogpeppe> yup
[21:16] <zyga-x240> !
[21:17] <zyga-x240> is /var/lib/snapd/state.json empty/corrputed
[21:17] <rogpeppe> i'd paste you the contents of state.json but it looks like it's got sensitive keys in it
[21:17] <zyga-x240> yeah, please dont
[21:17] <rogpeppe> it's valid json tho
[21:17] <zyga-x240> hmmhmm
[21:17] <zyga-x240> any nothing in /changes top-level key there?
[21:18] <zyga-x240> (inside the json that is)
[21:19] <rogpeppe> that's empty
[21:19] <zyga-x240> woah
[21:19] <zyga-x240> ok
[21:19] <zyga-x240> please report this
[21:19] <zyga-x240> I don't have a smoking gun at all
[21:19] <zyga-x240> we'd have to inspect the state of each snap (in the state)
[21:19] <zyga-x240> you could make a copy of state.json in case it changes, even on the device itself
[21:20] <rogpeppe> where should i report it?
[21:20] <zyga-x240> launchpad.net/snapd
[21:21] <rogpeppe> lol, launchpad :)
[21:21] <zyga-x240> indeed
[21:22] <rogpeppe> i've redacted everything that looks auth-related. i could paste the resulting json if you thought that would be useful.
[21:23] <zyga-x240> you can file a private bug
[21:23] <zyga-x240> and attach that to the bug report (works better for larger files)
[21:23] <rogpeppe> have you got a suggestion for what keywords would be good to use in the bug title?
[21:24] <zyga-x240> snapd lost current symlink, total system failure
[21:24] <zyga-x240> something to catch the eye
[21:24] <zyga-x240> we can change that later
[21:24] <rogpeppe> cool, that's useful, thanks
[21:25] <zyga-x240> thank you!
[21:27] <rogpeppe> zyga-x240: what other info would you suggest is useful to attach to the report?
[21:28] <zyga-x240> rogpeppe: hmm, maybe last time when you remember it working?
[21:34] <rogpeppe> ok, will do
[21:42] <rogpeppe> zyga-x240: https://bugs.launchpad.net/snapd/+bug/1898934
[21:43] <zyga-x240> is state.json there sanitized?
[21:43] <zyga-x240> I've made the bug private just in case
[21:43] <rogpeppe> zyga-x240: i will leave the system up and unchanged for a while, in case you want me to do any further investigation, but then i'll need to reinstall or something because this is running an important service (it's running my parents' house heating system!)
[21:43] <rogpeppe> zyga-x240: yes it is sanitized
[21:43] <zyga-x240> rogpeppe: let's chat tomorrow, I think we can recover it
[21:43] <zyga-x240> (remotely, without rebooting)
[21:44] <rogpeppe> zyga-x240: i can reboot if needed - my dad can reboot
[21:44] <rogpeppe> zyga-x240: one other odd thing: when the system crashes (which is does relatively regularly), it always takes two tries before it comes up properly
[21:45] <zyga-x240> right, I remember that
[21:45] <rogpeppe> zyga-x240: that's almost certainly entirely unrelated though
[21:45] <zyga-x240> really not sure why
[21:46] <rogpeppe> zyga-x240: i'm still intending to try running raspbian for a bit and see if it helps. i don't know if the issues are with ubuntu core or with the hardware itself
[21:46]  * zyga-x240 pushed one more bit to https://github.com/snapcore/snapd/pull/8573 and goes to bed


[21:30] <douglasawh-work> a view is a way of looking at the world
[21:31] <douglasawh-work> like, you look out the window and you have one view
[21:31] <douglasawh-work> then you look out another window and you have another view
[21:31] <douglasawh-work> people that didn't leave their IRC open over the weekend will likely be confused
[21:32] <douglasawh-work> the comments here answer a lot of questions: http://douglasawh.wordpress.com/2010/11/12/if-you-cant-say-anything-nice/
[21:33] <douglasawh-work> new subject though...is another a GDocs or OOo wizard? I am trying to do some stuff with dates
[21:35] <douglasawh-work> another ==anyone
[21:35]  * spikeb is not
[21:40] <douglasawh-work> I figured it out.  I did what I thought the instructions meant, not what it says...because I didn't know what it said existed
[21:40] <spikeb> haha


 trying to use a video wallpaper on kubuntu 22.04 but all it shows is a back screen, any reason why?
[13:45] <BluesKaj> Hi all
 hii ,
  hey
 yesterday i opened windows and updated it ,
 beside i have installed kde plasma
 , when i am able to see my hotspot device name but can't able to connect it ,
 also time is not correct in kubuntu and in bios .
 hii ,
  hey
 yesterday i opened windows and updated it ,
 beside i have already installed kde plasma
 , where i am able to see my hotspot device name but can't able to connect it ,
 also time is not correct in kubuntu and in bios .
 Try deleting wifi connection, then add it.
 @DarinMiller yea i did , but it didn't worked (re @DarinMiller: Try deleting wifi connection, then add it.)
[23:54] <SirLouen> hello, I was wondering currently Kubuntu 22.10 is using KDE 5.25.5 which is not recommended. Today I reported a bug in KDE.org bug tracker and they answered me with an automatic bot: "Please note that Plasma 5.25.5 is not supported for much longer by KDE; supported versions are 5.24, and 5.26 or newer.". May I assume that no updates will take place
[23:54] <SirLouen> until Kubuntu 23.04?
[23:56] <arraybolt3> SirLouen: Ubuntu handles backporting bug and security fixes to older verisons of software. Whether upstream supports it or not doesn't really matter much once it's accepted into Ubuntu. If there are problems that the Kubuntu developers are willing and able to fix in KDE, they will fix it.
[23:58] <SirLouen> arraybolt3 what means backporting bugs?
[23:59] <SirLouen> oh i understand what you mean now
[23:59] <arraybolt3> SirLouen: If a bug is discovered in a newer version of KDE and is fixed, the Kubuntu developers can take that fix and apply it to older versions of KDE, regardless of whether the KDE developers officially release that fix for the older version of KDE or not.
[23:59] <arraybolt3> Oh LOL, not backporting the bugs, backporting the fixes for the bugs :P
[23:59] <SirLouen> they wont support my kwin for sure :P i'm going to try to upgrade with backports ppa


[00:00] <jrwren> jcastro: good luck. i'm putting my kid to bed :)
[00:01] <jrwren> i wonder how long of a bike ride it is to lugwash.
[00:02] <jrwren> lugwash.org expired
[03:49] <snap-l> "Ubuntu to give puppies with every desktop. Critics complain some are allergic to dogs, and not everyone wants a puppy, and Canonical is evil for putting puppies in harms way"
[03:49] <snap-l> Every new feature, ever.
[13:04] <Wolfger> snap-l ++
[13:40] <jjesse> yay 135 updates for my new Windows 7 VM
[13:40] <jjesse> this is going to take most of the morning :(
[14:19] <brousch> jjesse: I recently installed Win7 pre-SP1 on a beastly computer. It took more than 3 hours to bring in the updates
[14:19] <brousch> It wasn't download time, it was install and reboot
[14:22] <jjesse> yeah it is pretty amazing how slow updates come
[14:23] <brousch> This was a quad core with SSD
[14:23] <brousch> i5 I think
[14:28] <rick_h_> party party
[14:37] <snap-l> Howdy.
[14:37] <snap-l> How's the morning?
[14:37] <rick_h_> good, getting ready to head out to see star trek and buying HL2 on steam
[14:37] <rick_h_> new video card is benchmarking quite nice, thanks for the suggestion. Left4Dead2 at full 1920 with most things set to high or very high quality
[14:39] <snap-l> Very cool
[14:39] <snap-l> We'll have to get you onto Xonotic at some point
[14:39] <snap-l> so Blazeix can show us how much we suck. :)
[19:49] <brousch> The awesome starts here http://www.youtube.com/watch?v=OPethpwuYEk&t=21m7s
[19:54] <greg-g> que?
[19:55] <brousch> Ubuntu on Glass
[19:56] <brousch> Bah, they don't show the GUI


[06:31] <dholbach> good morning
[22:30] <psusi> so I was using fscanf to extract some parameters from /etc/meminfo like this:
[22:30] <psusi> fscanf (info, "MemTotal: %*d kB MemFree: %d kB Buffers: %d kB Cached: %d kB"
[22:31] <psusi> it seems that at some point they added a new MemAvailable field between MemFree and Buffers and now this fails
[22:31] <psusi> how can I work around this?  i.e. specify that there may or may not be an additional string there, and I don't care whether it is or is not


[02:25] <lotuspsychje> good morning guys
[02:27] <pauljw> hi lotuspsychje :)
[02:27] <lotuspsychje> hey pauljw
[02:28] <lotuspsychje> you guys survived the winter yes?
[02:28] <pauljw> eh, we're not having one this year.  but we're surviving.
[02:29] <Bashing-om> what Winter ?
[02:29] <Bashing-om> Location: Heber Springs, AR ~ Temp: 52°F (11°C) ~ Cond: Overcast ~ Humid: 50% ~ Wind: 0 mph (0 km/h) ~ Time: 20:15
[02:30] <lotuspsychje> wow
[02:30] <lotuspsychje> 13 degrees also here
[02:30] <pauljw> north and east seem to be having some winter, but we in mid-west are just a bit too mild for my taste.  it was about 55F here today in S. Indiana.
[02:30] <lotuspsychje> something weird going on with seasons worldwide
[02:31] <pauljw> just cycles man...
[02:37] <lotuspsychje> !info linux-image-generic xenial
[02:37] <Bashing-om> We still got 60+ days before we can let the breath out .. Winter can bite real quick .
[02:40] <pauljw> i read somewhere that the tectonic plate shift that caused the tsunami that took out the reactors in japan caused the earth to shift several degs on it's axis.  if that's true, i would think that would have a huge effect on the jetstream paths across the earths surface.
[02:41] <lotuspsychje> doesnt make sense i didnt see snow like for years now
[02:41] <lotuspsychje> it has been proved already that temperatures are climbing up and ice is melting
[02:42] <Bashing-om> Yeah, I would think .. this ole planet takes a beating, and keeps on spinning . Bit there are conseqiences ,
[02:42] <lotuspsychje> some countrys cant stay/live because of the heat/dry
[02:45] <Bashing-om> The big brain guys have been warning us this was going to happen . The fix is not so easy to implement :(
[02:46] <lotuspsychje> Bashing-om: dont think so neither
[02:48] <Bashing-om> even birds are smart enough not to foul their nest !  What are our grand kids going to deal with ?
[02:49] <lotuspsychje> Bashing-om: we have seen nothing yet mate
[02:50] <Bashing-om> I am glad I chose to live where I am . Long range forcast a few years back was that this area would become arid .. fat chance now !
[02:52] <pauljw> are you saying the big brain guys were wrong?
[02:53] <lotuspsychje> au contraire
[02:53] <lotuspsychje> alot of stuff came out, the forespelled it
[02:54] <Bashing-om> That arid condition was in the very early stages of their calculations . Warm Winters and wet I can handle much better . Give the trees a drink of water !
[02:55] <lotuspsychje> lol
[02:58] <Bashing-om> Back in the 90's we had a 7 year drought .. lot of trees did not make it through ( me I had to change vocation ) . Then the weather patterns did change .
[03:05] <pauljw> i remember back when they were scaring us with the coming ice age, that didn't pan out, so then it was global warming, that didn't pan out, so now it's climate change.  that works because, guess what, the climate has been changing since the planet was created.  it's been much warmer and much colder and will be again.  cycles...
[03:08] <lotuspsychje> pauljw: ok i follow you mate, but everyone will agree how humans live now, it will influence our future and destroy things
[03:08] <lotuspsychje> there's nature cycles and human influences
[03:10] <Bashing-om> Mercuty poisoning from the garbage we dump in our oceans !
[03:11] <lotuspsychje> plastic soup yeah
[03:34] <pauljw> well guys, time to sleep, let me know how you fix all the worlds problems.
[03:34] <lotuspsychje> lol
[03:34] <pauljw> :)
[03:34] <lotuspsychje> nite nite mate
[03:34] <Bashing-om> nite nite .
[05:13] <Bashing-om> I'm out of here too .\
[06:07] <n4n0`> yar yar
[06:07] <n4n0`> and a bottle of rum
[07:41] <ducasse> morning all
[07:42] <EriC^^> morning ducasse o/
[07:42] <ducasse> what's up, EriC^^ ?
[07:43] <EriC^^> not much, just waking up
[07:43] <EriC^^> you?
[07:43] <ducasse> me too. really tired, hardly slept :-/
[07:44] <EriC^^> it's so cold these days
[07:45] <ducasse> here it's actually above zero now, so the snow is melting.
[07:45] <EriC^^> nice
[07:48] <ducasse> no intention of going out today, neither has the cat it seems :) raining, gray and generally unpleasant.
[07:48] <ducasse> but at least it's not below freezing :)
[07:48] <EriC^^> damn
[07:49] <EriC^^> yeah at least that
[07:50] <EriC^^> the weather is pretty good today here
[07:51] <EriC^^> it's sunny, it's been raining for the most part recently, it's been a cold year and full of rain
[07:52] <ducasse> it hasn't really been as cold as it usually gets here, except for a few days. lots of rain, though.
[07:53] <EriC^^> i have a huge urge to do magic tricks for some one
[07:54] <EriC^^> over the past 2 years or so i learned some card tricks cause i was curious, then i did them for my grandma, and i kept learning more of them, and she kind of developed a forgetfulness
[07:55] <ducasse> just walk out on the street and do them for strangers :)
[07:56] <EriC^^> and i kept learning more and more tricks and i keep doing them to her, she's not that surprised anymore though
[07:56] <EriC^^> i dont think know how well people would accept that kind of stuff here, nobody really does that here
[07:57] <EriC^^> i've never been approached by someone and said can i show you a trick? i think they'd be like wtf O.o
[07:57] <ducasse> probably :)
[07:58] <EriC^^> i could do them for friends i guess, i've kind of kept it for myself and my grandma haha
[07:59] <EriC^^> it's kind of a coping i think
[07:59] <EriC^^> like yeah she forgets a lot but i can do the same trick 40 times and she still goes wow O.O
[07:59] <EriC^^> i've gotten pretty incredible at the sleight of hand too xD
[08:01] <EriC^^> i guess i'll just leave it at that, i do wonder how others would react though
[08:01] <ducasse> my grandmother got a stroke, which made her a bit 'weird'. then she got another one, and that left her in a coma. appreciate them while you have them.
[08:01] <EriC^^> yeah
[08:02] <EriC^^> sorry about your grandma
[08:03] <ducasse> ok, the cat is now trying to get _under_ the laptop...
[08:03] <EriC^^> lol
[08:05] <ducasse> discovered why - there was a bag of cat treats hidden underneath :)
[08:06] <EriC^^> ah :)
[08:09] <ducasse> hehe, one of my neighbors insisted he had seen a lynx behind the house the other day. "yeeees, probably not..." :)
[08:10] <EriC^^> :D
[08:10] <ducasse> "i suspect others might have noticed that."
[08:11] <EriC^^> lol
[08:12] <ducasse> it would be cool to see one, though. beautiful animals.
[08:12] <EriC^^> yeah
[08:16] <ducasse> have you watched those 'mindfreak' shows, if you're into magic?
[08:18] <EriC^^> not much
[08:19] <EriC^^> that guy uses a lot of camera tricks and stuff like that
[08:19] <EriC^^> i started with a trick that were a little kind of 'mathematical' i guess in nature, which were kind of cool
[08:19] <ducasse> aha, i suspected as much. he also has a really abrasive personality, i can't stand him.
[08:20] <EriC^^> i appreciated that, then later i learned stuff that required sleight of hand and techniques and stuff like that
[08:20] <EriC^^> it's really very much like how we solve linux problems, there's techniques and ways you can do something
[08:21] <EriC^^> like you want to control a card to the top, you can use various methods to do that, and you want then do make it appear as if something, you can do that and this do achieve that effect, etc
[08:21] <EriC^^> you can come up with your own tricks and when you know the techniques you can tell what another magician is doing
[08:23] <EriC^^> the first trick i learned was i think a trick, you can try yourself it's a mathematical trick, you choose 3 cards, then make a pile of cards, 10 15 15 9 next to eachother, then place a card over pile 10, cut from 15 over 10, place on the 2nd pile, cut from 15 onto that, and same for 3rd pile
[08:23] <EriC^^> then you put the 9 cards over the 3rd column over 2nd over 1st, you count 4 cards from the top of the deck to the bottom and it's done
[08:24] <EriC^^> now you open one card face up and the other face down, and the spectator is supposed to say stop when he sees one of his cards, first round nothing shows up, you take the cards that were dealt face down and do the same, one face up one face down
[08:25] <EriC^^> in the end there will be only 3 cards left after several rounds, and they'll be his 3 cards
[08:30] <ducasse> sorry, but i've slept way too little to follow that :)
[08:31] <EriC^^> lol no problem
[08:32] <ducasse> do a lot of card tricks involve math?
[08:32] <ducasse> or just sleight of hand?
[08:32] <EriC^^> not really
[08:32] <EriC^^> yeah most involve sleight of hand
[08:51] <lordievader> Good morning.
[08:52] <ducasse> \o
[08:52] <lordievader> Hey ducasse, how are you?
[08:53] <ducasse> sleep-deprived :) i have a cunning plan of fixing that by sleeping an hour or two on the couch, though. :) you?
[08:55] <lordievader> Done with sleep, having coffee ;)
[08:58] <ducasse> i tried tea, but it didn't do the job :)
[09:08] <lordievader> Tea has less caffeine ;)
[09:10] <ducasse> i know, but i hate coffee ;)
[09:11] <lordievader> Too bad :P
[11:36] <lotuspsychje> Ben64: lol: http://www.benefitsofkayaking.com/fishing-kayak-how-to-speed-up-your-new-ebike-ve.html?ytid=ElTS-BVY3Vs&lvl=5&qs=Fishing+Kayak
[11:38] <lotuspsychje> Ben64: now im used to drive my bike, 25km/h gets a lil slow :p
[14:16] <BluesKaj> Hi all
[14:16] <daftykins> \o
[15:56] <EriC^^> hey daftykins
[16:55] <EriC^^> hey pauljw :)
[16:55] <pauljw> hey EriC^^ , how's it going? :)
[16:56] <EriC^^> fine thanks, you?
[16:56] <pauljw> all good here, thx.
[17:42] <daftykins> \o
[19:16] <Bashing-om> And ,, back ,... Let's see what we can do to make of it a better day in our neighborhood :)
[19:16] <daftykins> :D wb!
[19:18] <Bashing-om> I hit the deck running !


[00:21] <fta> mconnor, i don't really know, they grabbed the sources from trunk and built that god knows how. it's not in the official repos but there has been some blog posts about that.
[00:24] <mconnor> fta: hrm
[00:24] <mconnor> oh well
[00:24] <mconnor> legal can deal if so
[00:24] <fta> no need, i should have an experimental xul package rsn, for ff, i'm still not sure how to do it best. it's just a packaging problem
[00:37] <mconnor> fta: where's the patches directory for xulrunner, so I don't get angry trying to find it? :)
[00:37] <fta> mconnor, you want the branch or the patch site ?
[00:38] <mconnor> fta: I want the equivalent of http://bazaar.launchpad.net/~mozillateam/firefox/firefox-3.0.intrepid/annotate/180?file_id=series-20070321172126-hx4btlytc64jyo4n-28
[00:39] <fta> mconnor, so that's http://bazaar.launchpad.net/~mozillateam/xulrunner/xulrunner-1.9.intrepid/files/137?file_id=patches-20070825223227-dck53ndg2coetcqh-1
[00:39] <fta> mconnor, or http://bazaar.launchpad.net/~mozillateam/xulrunner/xulrunner-1.9.intrepid/annotate/137?file_id=series-20070825223227-dck53ndg2coetcqh-4
[00:39]  * mconnor weeps
[00:40] <mconnor> this is going to be a lot of work
[00:40] <mconnor> fortunately, I think I have like a week or two
[00:41] <mconnor> fta: uh, https://bugzilla.mozilla.org/show_bug.cgi?id=372826 got pulled into xulrunner?
[00:41] <mconnor> seriously?
[00:43] <fta> mconnor, hm, iirc, because it touches toolkit which is in xul, not in the files built in ff with xul-sdk
[00:44] <mconnor> oh, sure
[00:44] <fta> but it's ~2am here
[00:44] <mconnor> I don't care where
[00:44] <mconnor> but _why_?
[00:46] <fta> rewinding....
[00:46] <fta> Sep 19 23:18:28 <asac>  fta: https://bugzilla.mozilla.org/show_bug.cgi?id=372826
[00:46] <fta> Sep 19 23:18:36 <asac>  can you see if that applies in 1.9 xul?
[00:46] <fta> Sep 19 23:18:47 <asac>  i think attachment 337031
[00:46] <fta> rewinding more...
[00:47] <mconnor> man
[00:47] <mconnor> clearly I stopped whipping asac for too long
[00:48] <fta> hm, that week was tough, it was during the bug 269656 tournament
[00:48] <mconnor> wow
[00:49] <mconnor> nice summary
[00:49] <mconnor> sometimes I really hate FOSS zealots
[00:50] <mconnor> because seriously, all caps?
[00:50] <fta> well, asac asked me to land that out of nowhere, i guess when he was working on this bug. you'd better keep that question on the list
[00:51] <mconnor> yep
[00:51] <mconnor> damn straight
[00:51] <mconnor> there's... a lot of bzXXX in here
[00:51]  * mconnor sighs
[00:52] <fta> [reed], did you took some of those ?
[00:52] <fta> take
[00:53] <fta> *sigh* i'm tired
[00:53] <mconnor> fta: I'm about to take off and stop asking questinos
[00:54]  * mconnor sighs
[00:54] <mconnor> this isn't happy-making
[01:03] <fta> gosh, 119 tabs
[07:59] <gnomefreak> anyone here?
[08:00] <[reed]> nope
[08:18] <gnomefreak> !info firefox intrepid
[08:32] <gnomefreak> ok its 3:30 im going to bed.
[13:57] <gnomefreak> fta2: asac do either of you have time to push 4 extensions?
[14:10] <gnomefreak> anyone have the firefox about: using gecko version not firefoxes?
[14:55] <gnomefreak> i found it
[22:13] <fta> gasp, http://code.google.com/legal/individual-cla-v1.0.html
[22:22] <mconnor> fta: that's kinda... odd
[22:23] <mconnor> I mean, if you're contributing to chrome or something, sure
[22:23] <mconnor> but that seems rather weird
[22:23] <fta> mconnor, songbird has something very similar, which i didn't sign
[22:24] <fta> mconnor, so i can't post my patches in their bugzilla
[22:25] <mconnor> hmm
[22:25] <mconnor> Mozilla's is pretty sane
[22:26] <mconnor> yay
[22:26] <mconnor> its basically "must be licensed in a way that meets our public policy" aka "must be MPL tri-licensed"
[22:28] <mconnor> the irrevocable copyright license is weird to me, since that almost feels like "we can ignore the GPL"
[22:28] <mconnor> but IANAL
[22:29] <fta> it's bsd-style
[22:29] <mconnor> is it?
[22:29] <mconnor> I guess it is
[22:29] <mconnor> sort of?
[22:30] <mconnor> I mean, this seems parallel to GPL
[22:30] <mconnor> or whatever license you pick
[22:30] <fta> http://dev.chromium.org/developers/contributing-code
[22:31] <fta> http://code.google.com/chromium/terms.html
[22:31] <mconnor>  GPL
[22:31] <mconnor> 14:30 < mconnor> or whatever license you pick
[22:31] <mconnor> 14:30 < fta> http://dev.chromium.org/developers/contributing-code
[22:31] <mconnor> 14:31 < fta> http://code.google.com/chromium/terms.html
[22:31] <mconnor> gah, stupid terminal
[22:32] <mconnor> but, aiui, if you give google a perpetual and irrevocable license to use your code and sublicense etc, that means they can do whatever they want
[22:32] <mconnor> its not "subject to terms of the code license"
[22:35] <mconnor> from my reading, that agreement gives Google carte blanche to take anything you commit to their repo and do anything they want under any license they want
[22:41] <fta> i'll ask :)
 The CLA certainly grants google the right to license it however we want
 note however, our CLA is identical to apache's CLA, mysql's CLA, etc
 It's not like we are being different here
 You also retain copyright, so even if we did do something you didn't like, you culd still release and use the code however you wanted
[22:47] <fta> mconnor, ^^ from the lawyer
[22:49] <mconnor> fta: yeah, all makes sense
[22:49] <mconnor> I just don't like it
[23:04]  * mconnor takes another stab at looking at patches
[23:05]  * mconnor wishes he had some whiskey for this
[23:09] <fta> lol
[23:22] <mconnor> hmm
[23:22] <mconnor> --disable-updater doesn't hide the UI?
[23:22] <mconnor> fail


[07:39] <Kilos> morning Squirm inetpro Kerbero Webtrici- and all other lurkers
[07:39] <Kilos> and MaNI
[07:40] <MaNI> morning
[09:56] <melodie> hi
[09:57] <melodie> I need help to get this bug report find it's way up to the deciders, Debian packagers, Ubuntu packagers and so on:
[09:57] <melodie> https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1510709
[09:57] <melodie> "In Wily libgtk-3-common pulls in adwaita-icon-theme which in return pulls in ubuntu-mono" [Low,Confirmed]"
[09:57] <melodie> because it's the ennemy of our bandwidth and the enemy of economics and ecology as well
[09:58] <Kilos-> you are going to have to wait till the guys get back from saterday shopping and school sports melodie
[10:00] <melodie> Kilos- I have things to do in town too, just I am hoping you can relay the message, because if we don't do something about it, the next LTS will be the bloatest one since the beginning of the gnu/linux distributions
[10:00] <Kilos-> oh my
[10:00] <Kilos-> ill tell the guys to check yes
[10:07] <melodie> Kilos thank you
[10:08] <Kilos> anytime
[10:12] <melodie> Kilos during the whole coming week-end, if you can. :)
[10:12] <melodie> on your mailing list too, if possible
[10:12] <melodie> we need to struggle against un needed depends, it costs bandwidth, money, electricity is anti economics and anti ecologic
[10:16] <Kilos> whew
[10:17] <Kilos> why dont you go complain by the dev guys they the ones doing the developement
[10:17] <Kilos> maybe they have a reason for it
[10:19] <melodie> Kilos this is a bug report, this is where it's supposed to be, and there is only one possible reason : many apps complain "adwaita-icon-theme is not installed", but for one, that's harmless messages (I use my bento openbox each day and it works perfect without it!) and second, it should be in the recommands, not in the mandatory ring.
[10:20] <Kilos> ok
[10:22] <melodie> Kilos what you need to understand, is that icons are just images and a pack of icons, it's just an archive which is installed into /usr/share/icons. We users should be able to choose any icon theme as we like and not being forced into one or other set.
[10:22] <melodie> we can even get them from gnome-look.org or xfce-look.org or kde-look.org or box-look.org
[10:23] <melodie> and install them either in the system in /usr/share/icons for all users or in your .icons directory just for the current user
[10:23] <Kilos> what do all the lubuntu peeps say about this
[10:24] <melodie> that they don't care because they are moving to Qt :D
[10:24] <melodie> but I have sent a mail to gilir in case he will consider helping there, especially since the next Lubuntu will still be using the GTK environment
[10:25] <Kilos> ok
[10:25] <melodie> gilir : Julien Lavergne, the leader of the project
[10:25] <melodie> tech leader
[10:25] <melodie> I still think that all users for all African countries should add to this bug report, especially when it comes to saving bandwidth
[10:26] <melodie> the very last vesions of Bento Openbox are way under the 700MB
[10:26] <melodie> and soon I'll build a very small edition, one on which people will just install what they need, and choose their programs.
[10:26] <melodie> they will have a learning curve, but yet light enough
[10:27] <Kilos> nice
[10:28] <melodie> on #xubuntu, someone just told me the adwaita-icon-theme is also broken, and showed me this: http://i.imgur.com/ydvLUzG.png
[10:30] <Kilos> try get elacheche involved and lunapersa
[10:34] <melodie> they are not here at the moment right?
[10:35] <melodie> I discussed with elacheche yesterday and I think I don't know lunapersa yet
[10:35] <melodie> can you point to our discussion on your mailing list?
[10:35] <melodie> using the link to http://irclogs.ubuntu.com ?
[10:37] <Kilos> nope
[10:38] <Kilos> lets hear what superfly and inetpro say about it all
[10:38] <Kilos> but theyll only e here this evening most likely
[10:47] <melodie> I found the links, :D
[10:47] <melodie> http://irclogs.ubuntu.com/2015/11/28/%23ubuntu-africa.html
[10:47] <melodie> http://irclogs.ubuntu.com/2015/11/28/%23ubuntu-za.html
[10:47] <melodie> Kilos thanks for your help. We all are stronger together :D
[15:11] <Madmax247> Hello all, I'm new to Ubuntu and I hope to not bother you guys too often
[17:08] <Kilos> Maaz seen superfly
[17:08] <Maaz> Kilos: superfly was last seen 1 day, 2 hours, 33 minutes and 46 seconds ago in #ubuntu-za on freenode [2015-11-27 06:34:31 PST], and has been offline on freenode since 2015-11-28 06:59:52 PST
[17:08] <Kilos> Maaz seen inetpro
[17:08] <Maaz> Kilos: inetpro was last seen 19 hours, 15 minutes and 22 seconds ago in #ubuntu-za on freenode [2015-11-27 13:53:16 PST], and has been online on freenode since 2015-11-27 00:08:12 PST
[17:54] <squish101> what is the best way to dl tv series? is it still sabnzb and sickbeard?
[18:17] <Kilos> night all.sleep tight
[18:17] <magespawn> good evening
[19:10] <inetpro> .
[19:30] <inetpro> wb superfly
[19:30] <superfly> thanks -_-
[19:31] <superfly> my VPS's networking seems to die periodically, still not sure why
[19:31] <superfly> but it's in sore need of an update
[19:31] <superfly> *upgrade
[19:33] <inetpro> still using linode?
[19:33] <inetpro> or what was it again?
[19:37] <inetpro> superfly: what are your monthly rates these days?
[19:37] <superfly> yes, linode
[19:38] <superfly> still $20/month, but there's a cheaper $10/m option
[19:38] <inetpro> so that would be like almost R300 per month for 2GB?
[19:39] <inetpro> our rand really taking a dive these days
[19:43]  * inetpro should make plans to get monthly salary in USD or GBP now
[20:18] <magespawn> hi hi
[20:20] <magespawn> inetpro almost any of the major currencies would be good
[20:20] <inetpro> magespawn: eh, true
[20:21] <magespawn> there are ways, but most take time
[20:21] <inetpro> yep, I wish it was just a simple process to open a foreign account and pay foreign services from that account
[20:22] <magespawn> that will happen when the government looses interest in exchange control
[20:22] <inetpro> on the other hand, maybe we should look at local hosting now
[20:22] <inetpro> s/now/again/
[20:24] <magespawn> local hosting for?
[20:24] <inetpro> magespawn: need to make a plan for when the AWS thing runs out
[20:25] <magespawn> sign up for another one
[20:25] <inetpro> want to keep the QA bot running for oom kilos
[20:29] <inetpro> I see at www.vps.co.za you can get a 1GB RAM setup for R150pm and 2GB for R300
[20:31] <inetpro> the 1GB option is more than enough for the QA bot
[21:10] <inetpro> good night
[21:36] <squish101> i have a couple vps servers that arn't doing anything. real small ones
[21:37] <MaNI> government will never lose interest in exchange control, pay foreign services using bitcoin :p
[21:41] <squish101> i thought of moving money into SA with bitcoin, but the bitcoin -> bank rapes you
[21:43] <MaNI> bitcoin -> takealot -> gumtree -> bank
[21:43] <squish101> each one taking 2-3% of the value?
[21:45] <MaNI> moving money into the country is backward anyway
[21:45] <MaNI> everyone else is trying to get it out :p
[21:46] <MaNI> curiously bitcoin->zar on bitx usually fetches more than you would get if you converted bitcoin->usd->zar - so its possibly more feasible than you think
[21:47] <squish101> i got stuck with bitx with validating something
[21:48] <MaNI> like now bitcoin->usd->zar suggests that 1 BTC should be R5123 - but its actually R5265
[21:48] <MaNI> so you gain there and avoid the large cuts the banks usually take on usd->zar conversion
[21:49] <MaNI> would be interesting to see how competitive it is in practice
[21:49] <squish101> so $1000 -> zar would be?
[21:49] <squish101> I'll check with my normal way
[21:50] <squish101> R14,190.71
[21:53] <squish101> what would 2.811832189854909 bitcoins get me in the bank?
[21:56] <squish101> R14804.29 (plus any hidden charges... hmm may be worth it
[21:56] <squish101> HOLLY CRAP the exchange rate sucks
[22:03] <squish101> i wonder what standard bank will charge to receive bitcoin transfer from bitx? probably a zillion rand in bank charges
[22:06] <magespawn> good night all


[12:07] <BluesKaj> Hi all
[15:11] <sitter> anybody up for reviewing https://invent.kde.org/system/libqapt/-/merge_requests
[15:32] <RikMills> sitter: sadly I have a time/knowledge deficit that precludes me. maybe someone on debian (pino et al) might
[19:12] <santa_> good evening everybody
[19:13] <santa_> sitter: my knowledge of liqapt isn't good enough, and I have a fair amout of things to do piling up, I'm sorry
[19:13] <santa_> but thanks for the info
[19:14] <santa_> RikMills: misc news:
[19:14] <santa_> 1. I did test rebuilds for hirsute:
[19:15] <santa_> _staging: http://tritemio-groomlake.duckdns.org/build-status/buildstatus_ubuntu-exp3/
[19:15] <santa_> _archive: http://tritemio-groomlake.duckdns.org/build-status/buildstatus_ubuntu-exp2/
[19:16] <santa_> 2. I'm going to continue in the next days with the rework of iron hand, graphs and friends
[19:17] <santa_> on thing I'm planning to do is renaming kubuntu-retry-builds to ppa-retry-builds
[19:17] <santa_> and I would keep kubuntu-retry-builds as an alias/symlink to ppa-retry-builds
[19:18] <santa_> btw that program is broken in master but I would fix it after the rename
[19:18] <santa_> so...
[19:19] <santa_> RikMills: are you ok with the kubuntu-retry-buils -> ppa-retry-builds rename [y/n]?
[19:21] <santa_> s/on thing I'm planning to do/ONE thing I'm planning to do/
[19:24] <santa_> oh, and...
[19:24] <santa_> 3. we got KA working with deino, both in master and 2.3
[21:23] <RikMills> santa_: will the retry script no longer work on the archive then?
[21:24] <santa_> RikMills: oh, indeed
[21:24] <santa_> it works with the archive
[21:25] <santa_> hmm, nevermind then
[21:25] <RikMills> why rename to ppa- then?
[21:25] <RikMills> ok
[21:26] <santa_> nevermind. unless you would like to have archive-retry-builds and ppa-retry-builds
[21:26] <santa_> but let's just keep the name as it is
[21:26] <RikMills> agreed
[21:26] <santa_> I will simply fix it and make pylint clean
[21:26] <santa_> sorry for the brain fart XD
[21:26] <RikMills> np
[21:27] <santa_> btw I'm trying to finish the rework asap, I'm with ka-graph now
[21:35] <RikMills> :)


[12:22] <nottrobin> @webteam: I'm gonna do a www.ubuntu.com release if no-one objects
[12:23] <WillMoogle> Go for it!
[13:52] <nottrobin> sewaddle: merged: https://github.com/ubuntudesign/www.ubuntu.com/pull/901


[05:04] <zul> BenC: how so?
[05:12] <BenC> zul: I'm about 10 minutes from committing the custom build infrastructure for things like xen
[05:12] <BenC> all you have to do is put in a diff and create a couple trivial files to implement it :)
[05:13] <zul> BenC: neat..I could kiss you
[05:13] <zul> but not really..
[05:14] <BenC> Thanks, but I'll pass
[05:14] <BenC> some xen patches would be nice though :)
[05:14] <zul> Im working on it..shhhshh..
[05:15] <zul> although its an incentive now
[05:15] <BenC> $ ls *.deb
[05:15] <BenC> linux-headers-2.6.21-1-schedcfs_2.6.21-1.1_i386.deb
[05:15] <BenC> linux-image-2.6.21-1-schedcfs_2.6.21-1.1_i386.deb
[05:15] <BenC> that's my example build
[05:16] <zul> cool...Ill have a look when I get up tomorrow
[05:16] <BenC> $ ls -l debian/binary-custom.d/schedcfs.*
[05:16] <BenC> -rw-r--r-- 1 bcollins bcollins  72727 Apr 23 19:36 debian/binary-custom.d/schedcfs.config.amd64
[05:16] <BenC> -rw-r--r-- 1 bcollins bcollins  80542 Apr 23 18:07 debian/binary-custom.d/schedcfs.config.i386
[05:16] <BenC> -rw-r--r-- 1 bcollins bcollins 120459 Apr 23 14:59 debian/binary-custom.d/schedcfs.diff
[05:16] <BenC> -rw-r--r-- 1 bcollins bcollins     23 Apr 23 17:43 debian/binary-custom.d/schedcfs.mk
[05:16] <BenC> -rw-r--r-- 1 bcollins bcollins    209 Apr 23 18:03 debian/binary-custom.d/schedcfs.vars
[05:16] <BenC> and that's all I had to do to get it to build
[05:16] <BenC> there's a README in that subdir (debian/binary-custom.d/)
[05:16] <zul> does it have to be one diff or can it be many diffs?
[05:17] <zul> since I break down the xen diff to make it more manageable
[05:17] <ajmitch> BenC: sounds rather nice
[05:18] <BenC> zul: blob diff
[05:18] <zul> meh..
[05:18] <BenC> zul: too much work, and clutters things
[05:18] <zul> ok Ill work with that then
[05:19] <zul> now only if openvz would get off their butts and do 2.6.21 I really dont want to port 2 kernels
[05:19] <zul> anyways im off to bed night folks
[05:19] <ajmitch> seems like there's been a bit of pr about feisty supporting virtualisation
[05:19] <ajmitch> night zul
[05:20] <zul> eh?
[05:20] <zul> only if you have the right hardware :)
[05:32] <BenC> the vmware stuff doesn't require special hw
[05:32] <BenC> but kvm does, yes
[05:33] <BenC> debian/binary-custom.d/README and supporting build committed
[05:33] <BenC> Completely Fair Scheduler committed as an example (don't expect it to last through gutsy cycle)
[05:33] <ajmitch> nice
[05:36] <ajmitch> night
[05:37] <roh> hm.. which channel to ask x11/boot specific questions?
[05:40] <roh> the feisty desktop release xorg sig11 here, the 'beta' did not.
[06:06] <jdong> BenC: can I bug you for a quick sec about the standing tifm7xx1 bug?
[06:06] <jdong> bug 53923
[06:07] <jdong> it's been well identified and characterized; the ubuntu bundled tifm7xx1 does not work
[06:07] <jdong> but compiling upstream's stock drivers does work
[06:07] <jdong> so something about how it's bundled is making it break
[06:07] <jdong> I have this cardreader so I would be more than happy to test any patches, candidate kernels, etc.
[07:19] <dade`> if i change a module in /lib/modules .. then i run update-initramfs.. will the module iniside initramfs be updated too ?
[08:59] <dade`> BenC: works, with that patch \o/
[08:59] <dade`> i'm happy.
[08:59] <dade`> so it'll be fixed soon
[12:40] <calavera> 3c59x module doesn't work properly on Feisty (bug #78611). There are plans for correct this or we will have to wait for Gutsy?
[12:56] <zul> BenC: ping did you commit it last night?
[04:17] <dade`> BenC: did you read me ? :)
[04:17] <BenC> dade`: ah, I see your msg now :)
[04:17] <BenC> dade`: what's up?
[04:18] <dade`> works <- with that patch that disables the ata suspend function
[04:20] <BenC> that's interesting that suspend works when the function that's meant to enable it is disabled
[04:20] <BenC> mjg59: dade has a problem with suspend on a macbook and a patch he tried to basically comment out the suspend code in libata makes it work
[04:20] <BenC> ata_piix
[04:20] <dade`> no
[04:20] <dade`> libata
[04:21] <dade`> wait a sec
[04:21] <dade`><EMAIL_ADDRESS>[04:21] <dade`> see here, that guy did
[04:22] <BenC> dade`: I know the patch was for libata, but just pointing out that you are using ata_piix
[04:23] <dade`> ah ok, all macbooks use ata_piix
[04:23] <BenC> some use piix, depends on what chipset they have
[04:23] <dade`> mine used piix with older kernels
[04:23] <dade`> .18 serie
[04:24] <dade`> if i remember correctly
[04:25] <dade`> BenC: the -386 kernel is smp ?
[04:25] <BenC> dade`: no, it's UP
[04:25] <dade`> 'cause using the .386 kernel on macbook only enables one core.
[04:25] <dade`> ok
[04:25] <dade`> cool
[04:26] <dade`> brb
[04:41] <zul> BenC: what git patch level are we at for gutsy?
[04:42] <BenC> zul: huh?
[04:42] <zul> like 2.6.21-rc7-gitXX
[04:43] <BenC> um, we're at latest linux-2.6.git
[04:43] <zul> ok
[04:43] <BenC> there is no -gitXX
[05:15] <zul> BenC: couldnt we have sub-directories for the binary-custom.d to make it cleaner?
[07:23] <rtg__> BenC: +187 debian/rules.d/2-binary-arch.mk - unterminated macro, gutsy commit c215f0acae2632042df5a7bdf5b5d78acaf235d1
[07:23] <BenC> rtg__: re-pull, I fixed that this morning
[07:24] <rtg__> BenC: I guess I just missed your update.
[07:34] <zdzichuBG> this tifm card reader bug looks like chat, without any word on fix
[07:43] <BenC> zul: done in latest git
[07:43] <BenC> zdzichuBG: likely because we don't have a fix for it yet
[07:44] <zul> BenC: asante sana
[07:45] <BenC> you might have to pull from ubuntu-gutsy with --force or something
[08:45] <dade`> BenC: that fix seems to work only on -386
[08:45] <dade`> i'll try again a few hours to confirm
[08:46] <dade`> in a few
[08:59] <mjg59> BenC: Which suspend code in libata?
[09:01] <BenC> mjg59: Check with dade for the URL to the patch
[09:02] <mjg59> Eh. Works fine on an MBP, which has identical hardware.
[09:12] <dade`> works fine on a 2.0 macbook
[09:12] <dade`> wich is even more identical
[09:13] <dade`> which
[09:59] <dade`> ok. the same patch works with -generic kernel too
[10:00] <dade`> Now wifi sometimes give problems after wakeup
[10:17] <compengi> i have an issue, i got 3 programs running (xchat, gaim, xmms) but my memory is being eaten dunno why. i got 36.8% of 512MB memory used and 3.3% of 1G swap. and my pc is 4 hours up only, while on edgy i was running same programs but my system didn't use swap until my pc was up several days. does anyone knows what's going on?
[10:19] <fabbione> compengi: it means nothing.. do you notice slow downs or performance hit?
[10:20] <fabbione> might be a lot caching on what you are doing
[10:20] <fabbione> or buffering even
[10:20] <compengi> Mem:    515220k total,   508840k used,     6380k free,    34572k buffers
[10:20] <compengi> Swap:  1020116k total,    33964k used,   986152k free,   294036k cached
[10:20] <compengi> but it wasn't like that in edgy
[10:20] <fabbione> yeah you have over 300MB in cache/buffer
[10:20] <fabbione> do you notice performance hit?
[10:21] <fabbione> or any *real* problem+
[10:21] <fabbione> like applications are crashing?
[10:21] <compengi> not now but i'm 4 hours up still
[10:21] <compengi> in edgy my system started using swap when i was like several days up
[10:21] <fabbione> leave it running for a few days... see it won't do anything bad
[10:21] <fabbione> it doesn't matter what edgy did
[10:22] <fabbione> it's a different kernel
[10:22] <fabbione> they might have changed just the way in which memory is freed or cache released
[10:22] <fabbione> it's not of any relevance what you are reporting
[10:22] <fabbione> it will make sense IF it was source of problems
[10:22] <compengi> oh
[10:22] <compengi> okay
[10:24] <compengi> so you think that in later kernel releases it would be better?
[10:29] <JanC> fabbione: I can tell you if your system starts to swap when it didn't before, that *is* a performance problem  :)
[10:29] <fabbione> JanC: prove it with numbers
[10:29] <fabbione> then come back and tell me you have an issue
[10:30] <fabbione> it might have just been a crontab running to update the locatedb
[10:30] <fabbione> or anything
[10:30] <fabbione> numbers in there means nothing on how the machine is behaving or responding to you
[10:40] <JanC> fabbione: I've seen several people who have the impression that feisty needs more memory than edgy to run smoothly, but it's difficult to get hard numbers or find the cause (so it's not necessarily a kernel problem--it could be GNOME or GTK or Xorg or whatever)
[10:40] <JanC> and program versions have changed too of course
[10:42] <JanC> and some extra daemons & programs are running on a default desktop
[11:28] <bdmurray> Are hibernate / suspend buttons not working a kernel bug or keyboard bug?
[11:30] <bdmurray> The bug I am looking at has a keycode not not known message
[11:40] <ash211> bdmurray: I'd guess keyboard
[11:41] <ash211> if it works through the logout menu, then definitely keyboard
[11:42] <mjg59> ?
[11:42] <mjg59> bdmurray: hotkey-setup
[11:43] <bdmurray> mjg59: thanks
[12:02] <bdmurray> mjg59: do you have a priority preference for unknown keys?