[00:28] <lunks> Hey, I'm currently running hardy, and a previous workaround for black ttys on nvidias made vesafb load instead of nvidiafb and made it unable to start X from vesafb.
[00:28] <lunks> Just upgraded to hardy on this machine.
[00:34] <lunks> Got "/etc/gdm/failsafeXserver: line 47: [: too many arguments<break line>: error: this program does not know how to configure the "10<break line>shared/default-x-server doesn't exist" X server<break line>Warning: Could not generate /etc/X11/xorg.conf.failsafe for vesa driver
[00:43] <lunks> Got "/etc/gdm/failsafeXserver: line 47: [: too many arguments<break line>: error: this program does not know how to configure the "10<break line>shared/default-x-server doesn't exist" X server<break line>Warning: Could not generate /etc/X11/xorg.conf.failsafe for vesa driver
[00:43] <lunks> when starting x
[00:43] <Hobbsee> !repeat
[00:43] <ubotu> Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. You can search https://help.ubuntu.com or http://wiki.ubuntu.com while you wait. Also see !patience
[00:44] <lunks> Hobbsee: sorry.
[02:07] <bardyr> hey
[02:08] <bardyr> does http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=32a2128fde2b06c33cdd0f39354504c46ef3303f mean linux-2.6.24 is being pushed into the repos?
[02:10] <Hobbsee> it appears so
[02:10] <bardyr> :)
[02:31] <toby_> Is there an IRC for general IT questions?
[02:32] <toby_> really am stuck but they are not all Ubuntu related more IP internet and stuff i never hear of like:
[02:32] <toby_> What impact may Kazza have if running on a companies PC?
[02:34] <toby_> I guess that a no
[03:17] <bardyr> Tomcat_,  insecure network?
[04:29] <choudesh> !info dhcpd
[04:29] <ubotu> Package dhcpd does not exist in gutsy
[04:29] <choudesh> !info dhcp
[04:29] <ubotu> dhcp: DHCP server for automatic IP address assignment. In component universe, is optional. Version 2.0pl5dfsg1-20ubuntu1.2 (gutsy), package size 109 kB, installed size 300 kB
[04:30] <choudesh> !info dhcp hardy
[04:30] <ubotu> Package dhcp does not exist in hardy
[04:30] <choudesh> why isn't dhcp package in hardy?
[04:31] <bazhang> changed to something else, checking now
[04:31] <crdlb> !find dhcp hardy
[04:31] <ubotu> Found: dhcp3-client, dhcp3-common, dhcp3-dev, dhcp3-server, autodns-dhcp (and 12 others)
[11:06] <oxigen> hi, did anyone here tried to install Hardy 64bit yet?
[11:08] <pvandewyngaerde> oxigen:  i upgraded my gutsy 64
[11:08] <oxigen> pvandewyngaerde: did you have some problems?
[11:09] <pvandewyngaerde> some libc segfaults
[11:10] <oxigen> pvandewyngaerde: do you think it's better to install .iso instead of upgrade?
[11:14] <pvandewyngaerde> iso gives you a fresh install
[11:14] <pvandewyngaerde> and possibility to install it on another partition, and not mess up your current installation
[11:15] <oxigen> what they mean by "update without checking what is to be updated"
[11:16] <oxigen> pvandewyngaerde: yes, i have two hd's
[11:17] <pvandewyngaerde> i dont know what they mean
[11:18] <oxigen> hmm
[11:19] <oxigen> is available 64bit java and flashplayer perhaps?
[11:20] <pvandewyngaerde> not available, emulate 32 bit
[11:21] <oxigen> aha, ok, thanks pvandewyngaerde, i'll stop bothering now :)
[15:52] <Lunks> Is it possible to install Hardy from the daily livecd?
[15:53] <Tomcat_> Lunks: Yes.
[15:53] <Lunks> Ok, tnx
[17:27] <seisen> anybody testing Xubuntu in VirtualBox?
[17:40] <h3sp4wn> seisen: ask the real question (that is a poll not a question)
[17:45] <seisen> In Xubuntu the terminal is discolored and runs slow and BulletproofX has no options to select
[17:45] <seisen> *from
[18:26] <BUGabund1> hya guys
[18:26] <BUGabund1> where can I report X11 errors from hardy?
[18:29] <stdin> !bug | BUGabund1
[18:29] <ubotu> BUGabund1: If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.ubuntu.com/  -  Bugs in/wishes for the bots can be filed at http://launchpad.net/products/ubuntu-bots
[18:30] <BUGabund1> stdin: but I want some confirmation, before using LP
[18:31] <stdin> if you report it on LP then others will confirm if they have it. I haven't had any X problems so far..
[18:32] <BUGabund1> just some strange crashes with Firefox
[18:32] <BUGabund1> but seem related to X11
[20:45] <h3sp4wn> How can I easily get kde4 up and running (shouldn't have to do - aptitude install kde4$\~n\!~i) Or is all that stuff really 1270MB
[20:50] <FunnyLookinHat> h3sp4wn, well, even doing that won't give you much more than a developer sandbox
[20:50] <FunnyLookinHat> To be honest, the easiest way to get KDE4 up and running in a usable environment is through compiling the code via svn
[20:51] <h3sp4wn> FunnyLookinHat: that includes all the foo-kde4 apps
[20:51] <FunnyLookinHat> which are pretty essential to the desktop I would think
[20:51] <FunnyLookinHat> That's how KDE works, it's a big (somewhat bloated) package    :)
[20:51] <h3sp4wn> Exactly - aptitude install kde4$\~n\!~i (That gives me 1.2GB of kde4 stuff)
[20:52] <h3sp4wn> probably loads more than I need
[21:05] <cdm10> Has anyone run Hardy in VirtualBox? I can't seem to get the VBox Guest Additions for Linux to run properly.
[21:05] <cdm10> Also, my keyboard selection doesn't seem to stick
[21:19] <BUGabund1> question: how does one configure laptops touchpad using gsynaptics without xorg.conf??
[21:26] <BUGabundo> guys and gals how can I make my touchpad scroll work?
[21:47] <xorl_> Hey, what app manages ssh-keys in gnome?
[21:50] <BUGabundo> I use seahorse, xorl_
[21:59] <xorl_> well when I was running 7.10 I had my ssh-key in place.
[21:59] <xorl_> Now, when I ssh to stuff in hardy, it doesn't prompt me anymore and doesn't appear to be 'managing' my ssh-key
[22:00] <BUGabundo> yes, I've noticed that too
[22:00] <xorl_> but that is seahorse correct?
[22:00] <BUGabundo> I haven't been ask for my keyring pass naymore
[22:00] <BUGabundo> seahorse is not on the default install
[22:01] <xorl_> yeah, unfortunately, that's kinda of difficult
[22:01] <xorl_> i admin about 700 freebsd servers from my ubuntu machine and typing in my ssh-key password is a tad bit tedious
[22:01] <xorl_> lol
[22:02] <BUGabundo> I bet
[22:02] <BUGabundo> I have a script that mounts 4 servers via sshfs
[22:03] <BUGabundo> and now it just connects
[22:03] <BUGabundo> without asking for a pass
[22:04] <xorl_> hmm, my key is passworded so i have to type it in manually
[22:06] <BUGabundo> wait xorl_
[22:06] <BUGabundo> my lastest updates
[22:06] <BUGabundo> seem to popup a input box to insert pass
[22:06] <BUGabundo> but no keyring pass until now
[22:07] <BUGabundo> ahh you use pass! I use cert keys
[22:07] <xorl_> well i mean it would prompt me automatically for my ssh-key password without the keyring, but the keyring can't connect to it's daemon from a standard user it seems
[22:07] <xorl_> well my SSH keys are just ssh-keys with a password
[22:07] <xorl_> Nothing odd about that.
[22:08] <BUGabundo> pgp keys are really nice that way
[22:08] <BUGabundo> no need to use pass
[22:08] <xorl_> I just used to auth it once and the session manager (whatever it was previously called)
[22:08] <xorl_> well BUGabundo if someone gets your key, have fun with that lol
[22:09] <BUGabundo> i0ll have to revoke it
[22:09] <BUGabundo> and place a new one on the server
[22:09] <BUGabundo> same as a password
[22:09] <xorl_> that's exactly why i require passworded keys lol
[22:11] <humbolto> I heard the reason for Xen in gutsy sucking so much is, that gutsy's kernel version has not been patched by the xensource guys unlike the version debian etch is using for example.
[22:11] <humbolto> will hardy suck as much as gutsy as a Xen dom0?
[22:11] <humbolto> or is any help from xensource in sight?
[22:13] <Lunks> Can someone point me some website to know about that crypto stuff on /home etc.?
[22:13] <Lunks> I don't know how does it work, how to recover, how to set it up, but I'd like to know about it. :)
[22:14] <BUGabundo> do you mena the mounting of /home, Lunks?
[22:14] <Lunks> brb
[22:14] <Lunks> no, encrypt it
[22:14] <xorl_> BUGabundo: he probably wants to encrypt the /home partition yeah.
[22:14] <xorl_> Lunks: And recovery per say, if you nuke an encrypted partition that's like pandora's box
[22:15] <xorl_> lol
[22:17] <BUGabundo> I use encfs
[22:17] <BUGabundo> and even that I find it quite dangerous
[22:17] <BUGabundo> if something happens to the key or corruption
[22:18] <BUGabundo> i0ll never going to recover, what now I try to keep safe
[22:24] <Lunks> xorl_: that's the recovery stuff that bothers me
[22:26] <Lunks> the first and last time I tried using enc was on w2003 and after my hard disk started to failure, I didn't have another recovery agent than the administrator on the w2003 enviroment that failed, so I lost everything on the enc folder
[22:26] <Lunks> I mean, can I use encryption on Ubuntu so I can recover if something bad happens?
[22:37] <cafuego> Like say losing the password?
[22:44] <Lunks> cafuego: like I can't boot up on the ubuntu system I used /home
[22:44] <Lunks> I just have access to it from, say, a live cd
[22:45] <cafuego> Provided that livecd has the efs drivers, you *SHOULD* be fine.
[22:45] <Lunks> jok
[22:45] <cafuego> Honestly though, if it doesn't NEED to be encrypted, don't encrypt it.
[22:46] <Lunks> I don't know sh*t about encryption on Ubuntu, where should I look for info about it? =P


[17:06] <lotuspsychje> few weeks ago i could reproduce bug #2052879 but cant seem to make it hang/crash anymore now
[17:06] -ubottu:#ubuntu-next- Bug 2052879 in gnome-control-center (Ubuntu) "Ubuntu 24.04 gnome-control-center hang" [Undecided, Incomplete] https://launchpad.net/bugs/2052879
[17:07] <lotuspsychje> asks password when selecting system and continues working


[12:20] <coolthreads> no probs
[18:15] <android6011> what card type do I need to put for an em28xx chipset? analog v4l?
[21:16] <Guest17934> Hi, maybe someone is seeing this...
[21:18] <Guest17934> I have the following small problem with my lirc setup in my mythbuntu setup. In my /etc/lirc/hardware.conf there is an entryREMOTE_DEVICE="/dev/input/
[21:18] <Guest17934> event4
[21:19] <Guest17934> This seems to work OK, however when I re-boot the /dev/input/event4 must be changed to /dev/input/event5
[21:20] <Guest17934> Thus it seems the allocation to the device file is different from boot-up to boot-up.
[21:22] <Guest17934> I tried to change corresponding line to REMOTE_DEVICE="/dev/input/by-path/pci-0000:05:01.0-event-ir", which seems to be a symlink to /dev/input/event4 or 5... anyway it seems constant from boot to boot.
[21:24] <Guest17934> However, it seems that this "symlink" (/dev/input/by-path....) has not been set when the lirc daemon is started during the boot phase...
[21:27] <Guest17934> Are these lines making some kind of sense to any of you?


[00:56] <mup> PR snapcraft#2916 closed: status: implement using the new channel-map endpoint <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2916>
[01:53] <mup> PR snapcraft#2992 closed: [WIP] repo: ubuntu implementation refactoring with initial package-management <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2992>
[03:11] <mup> PR snapcraft#3006 closed: repo: always use host release and arch for Ubuntu <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3006>
[05:34] <mborzecki> morning
[06:13] <mborzecki> mvo: hey
[06:20] <mvo> mborzecki: good morning
[06:29] <mup> PR snapd#8410 closed: many: disentagle release and snapdenv from sandbox/* <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8410>
[06:31] <mup> PR snapd#8412 opened: httputil: increase httpclient timeout in TestRetryRequestTimeoutHandling <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8412>
[06:34] <mup> PR snapd#8404 closed: client: increase timeout in client tests to 100ms <Simple 😃> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8404>
[07:03] <pstolowski> morning
[07:05] <mvo> good morning pstolowski
[07:05] <zyga> good morning
[07:05] <zyga> hey mvo,
[07:06] <zyga> mvo: I noticed we have a small problem in debian
[07:06] <zyga> mvo: snapd doesn't build
[07:06] <zyga> dh_missing: warning: usr/bin/snap-preseed exists in debian/tmp but is not installed to anywhere
[07:06] <zyga> I think we have different ruleset there, and leftover binaries cause builds to fail
[07:06] <zyga> I'll see if I can use my shiny metal rights and actually help
[07:07] <jamesh> Had another CI run hit Travis's 50 minute limit: https://travis-ci.org/github/snapcore/snapd/builds/670392870
[07:07] <zyga> jamesh: I'll move travis jobs to actions today
[07:07] <zyga> I think it's time
[07:14] <mvo> good morning zyga
[07:15] <mvo> 8103 needs a second review, it's important for the encryption story and to unblock the TPM work
[07:16] <mvo> jamesh: thanks for letting us know, once we are slightly less busy we move to gh actions to get rid of this
[07:17] <mvo> jamesh: also thanks for your review on 8406, I really have no better idea unfortunately how to make this better, maybe we could increase the sleep to 100ms to have a bigger "window" of time to look at. yeah, over-committed CI systems are  very annyoing
[07:18] <mvo> (fwiw 8103 is not very long, hopefully quick review)
[07:24] <mup> PR snapd#8413 opened: interfaces: don't use the owner modifier for files shared via document portal <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8413>
[07:27] <mvo> jamesh: if 8406 looks ok enough please approve, if you feel it makes the test useless I could close and we just need to live with the errors
[07:28] <jamesh> mvo: I think the change looks good.  When run on an unloaded system, it should still verify that the timeout has been extended
[07:29] <mvo> zyga: session-tool fails on master https://api.travis-ci.org/v3/job/670441262/log.txt - could you please ahve a look?
[07:31] <zyga> Yes
[07:44] <mup> PR snapd#8406 closed: usersession: extend timerange in TestExitOnIdle <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8406>
[07:45] <jamesh> pedronis_: I think the extra spread test I added covers what you wanted in my user daemons PR
[07:46] <pedronis> jamesh: thanks
[08:17] <zyga> pedronis: thank you for the move yesterday!
[08:41] <mup> PR snapd#8414 opened: o/configstate: core config handler for persistent journal <Created by stolowski> <https://github.com/snapcore/snapd/pull/8414>
[08:41] <pstolowski> ogra: hi, this might be interesting for you ^ (feedback is welcome)
[08:54] <ogra> nice !
[08:54] <ogra> pstolowski, you are aware that etc/systemd/journald.conf.d/ is complete nonsense ?
[08:55] <pstolowski> ogra: heh, not, why?
[08:55] <ogra> pstolowski, all you need to do is to create the dir ...
[08:55] <pstolowski> ogra: you mean /var/log/journal ?
[08:55] <ogra> the builtin defaults are completely fine, if the dir exists journald writes the journal to disk ... if not it uses the ringbuffer ... there is no need to change the config
[08:56] <ogra> yeah
[08:56] <pstolowski> huh
[08:56] <ogra> i'D just make the code call a mkdir and be done ;)
[08:56] <pstolowski> mhm
[08:57] <ogra> (and rmdir if the option is unset)
[08:57] <pstolowski> ondra: is this consistent across systemd versions (core16, core18...)?
[08:57] <pstolowski> sorry, ogra ^
[08:57] <ogra> notsure what ondra thinks ... but it surely is for 16 and 18
[08:57] <ogra> :)
[08:58] <ogra> might be that 20 changed it though ... better test there .... for 16 and 18 it was always sufficient to just create the dir
[08:58]  * ondra agrees with anything ogra says, as long as it's not about partitions!
[08:58] <ogra> !
[08:59] <pstolowski> ogra: ok, that's interesting, thank you!
[09:00] <ogra> thank *you* for implementing it !!
[09:00] <ogra> :D
[09:03] <pstolowski> ogra: ah, i read the manualy again. so it appears that "auto" is the default behavior,  the existense of /var/log/journal controls the behavior
[09:03] <ogra> yep :)
[09:04] <pstolowski> ogra: thanks again for the enlightenment ;)
[09:17] <zyga> pstolowski, ogra: related review https://github.com/snapcore/snapd/pull/8414#pullrequestreview-387089711
[09:17] <mup> PR #8414: o/configstate: core config handler for persistent journal <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8414>
[09:18] <pstolowski> zyga: thanks. we might not need the conf file at all, i'm going to verify this
[09:18] <zyga> thanks
[09:18] <zyga> ping me for a re-review please
[09:36] <mup> PR snapd#8415 opened: cmd/snap-recovery-chooser: tweaks <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8415>
[09:45] <pedronis> mborzecki: I nitpicked a bit in #8415
[09:45] <mup> PR #8415: cmd/snap-recovery-chooser: tweaks <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8415>
[09:51] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8415#pullrequestreview-387112832
[09:51] <mup> PR #8415: cmd/snap-recovery-chooser: tweaks <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8415>
[09:52] <mborzecki> pedronis: zyga: thanks
[09:53] <zyga> I'll be back shortly, it's quite cold in the office and ought to make some warm tea
[10:00] <zyga> mborzecki: unit tests failed on that PR
[10:00] <mborzecki> waat?
[10:00] <zyga> https://www.irccloud.com/pastebin/NkNEOsNj/
[10:00] <zyga> not yours but meh
[10:00] <zyga> mvo: ^
[10:00] <zyga> is that another thing to adjust?
[10:01] <mborzecki> weird, that timeout is longer already
[10:01] <mborzecki> maybe a bug in the test/code?
[10:02] <mvo> zyga, mborzecki I thought I did push something there?
[10:02] <zyga> ah, perhaps maciek's branch is simply older
[10:02] <mvo> https://github.com/snapcore/snapd/pull/8412
[10:02] <mup> PR #8412: httputil: increase httpclient timeout in TestRetryRequestTimeoutHandling <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8412>
[10:02] <mborzecki> mvo: yes, https://github.com/snapcore/snapd/pull/8404 has landed already
[10:02] <mup> PR #8404: client: increase timeout in client tests to 100ms <Simple 😃> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8404>
[10:03] <mvo> mborzecki: this one is different, no? that's what 8412 is for
[10:03] <mvo> mborzecki: or am I misreading this?
[10:03] <mborzecki> pstolowski: mvo: i think there's a problem with persistent logs, /etc/machine-id isn't mounted from writable (at least on core20) so after reboot you get a new machine-id and a new journal
[10:03] <mborzecki> oh, w8, it is
[10:03] <mborzecki> so why did i get a new machine-id again?
[10:03] <pstolowski> mborzecki: works as expected on core18
[10:04] <pstolowski> (i rebooted)
[10:05] <mborzecki> hmmmm ├─/etc/machine-id  tmpfs[/machine-id]   tmpfs      ro,size=203112k,mode=75
[10:05] <zyga> yeah
[10:05] <mborzecki> pstolowski: mvo: ^^
[10:05] <zyga> why do we have machine-id on a tmpfs
[10:05] <zyga> mborzecki: we noticed this a while ago
[10:05] <zyga> in the review of mount-ns data
[10:05] <zyga> I guess we forgot to act
[10:06] <mborzecki> pstolowski: do you hav a core18 vm? can you check `findmnt /etc/machine-id` ?
[10:06] <pstolowski> mborzecki: yep, 1 sec
[10:06] <zyga> mborzecki: I do
[10:07] <zyga>  /etc/machine-id /dev/sda3[/system-data/etc/machine-id] ext4   rw,relatime,data=o
[10:07] <zyga> so that's weird
[10:08] <zyga> mborzecki: from pi4 /etc/machine-id /dev/mmcblk0p2[/system-data/etc/machine-id] ext4   rw,relatime
[10:08] <zyga> mystery
[10:08] <mborzecki> hm it's not listed in writable-paths, what sets it up?
[10:08] <zyga> maybe that's our test specific setup
[10:09] <mborzecki> zyga: anything in /etc/fstab or /run/image.fstab?
[10:10] <pstolowski> zyga: i see  /etc/machine-id /dev/sda3[/system-data/etc/machine-id] ext4 as well
[10:10] <zyga> what is /run/image.fstab?
[10:10] <zyga> where are writable paths set up
[10:10] <zyga> I mean
[10:10] <zyga> the list
[10:11] <pstolowski> zyga: and pi3 with core16 is the same as yours
[10:11] <zyga> I checked pi4 with core18
[10:11] <zyga> no clue
[10:11] <mborzecki> zyga: iirc it's from our initrframfs hooks
[10:11] <mvo> mborzecki: hm, this is all confusing, it looks like /etc/machine-id is not in the writable-path
[10:11] <mborzecki> zyga: https://github.com/snapcore/core20/blob/master/static/etc/system-image/writable-paths
[10:12] <zyga> hmm - +0:+0 /system-data/etc/machine-id /etc/machine-id rw,relatime shared:+1 - ext4 /dev/sda3 rw,data=ordered
[10:12] <zyga> that's from our own test data
[10:12] <zyga> wat?
[10:12] <zyga> check this out
[10:12] <zyga> https://www.irccloud.com/pastebin/0OxSdK9y/
[10:12] <mvo> mborzecki: so I remember that /var/lib/dbus/machine-id was the persistent place and an /etc/machine-id would make systemd fallback to the /var/lib/dbus/machine-id, maybe that changed? or maybe I misremember?
[10:12] <zyga> core 20
[10:13] <zyga> it's good on core16 and core18
[10:13] <zyga> mount-ns test is a bit like the os-release-zoo
[10:13] <zyga> anyway
[10:13] <zyga> brb
[10:13] <zyga> I'm so cold today
[10:13] <zyga> need to make that tea for real
[10:13] <mborzecki> core20 has different initramfs tho?
[10:14] <mvo> yeah
[10:15] <mborzecki> so in core build i see this:
[10:15] <mborzecki> 318:    mount -o bind "${rootmnt}/writable/system-data/etc/machine-id" "${rootmnt}/etc/machine-id"
[10:16] <mvo> mborzecki: right, I think we need to add the machine-id to the writable-path, I wonder if that will work, i.e. if systemd will be able to commit when it can't write it atomitcally
[10:16] <mborzecki> but it's not used in core20 world anymore right? it's only ubuntu-core-initramfs now?
[10:17] <mvo> mborzecki: but the man-page for machine-id talks about bind-mounting it, so *hopefully* that will work
[10:18] <mvo> mborzecki: I think that's right, sounds like we need to sync with dimitri with it. but maybe it's enough to just add it to the writble-path?
[10:24] <zyga> back
[10:24] <zyga> much better :)
[10:25] <zyga> shall I report this just in case we don't fix it today?
[10:26] <zyga> I need a 2nd review on https://github.com/snapcore/snapd/pull/8403 to make progress please
[10:26] <mup> PR #8403: sandbox/cgroup: avoid making arrays we don't use <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8403>
[10:26] <zyga> I will adjust the comment on the next pass, this is green now
[10:26] <zyga> mborzecki: simple-session tool improvement https://github.com/snapcore/snapd/pull/8416
[10:26] <mup> PR #8416: tests/session-tool: reset failed session-tool units <Created by zyga> <https://github.com/snapcore/snapd/pull/8416>
[10:27] <zyga> this avoids the need to use property only available on future systemd versions
[10:27] <zyga> and solves accumulation of leftovers
[10:27] <mup> PR snapd#8416 opened: tests/session-tool: reset failed session-tool units <Created by zyga> <https://github.com/snapcore/snapd/pull/8416>
[10:27] <xnox> mvo: Ubuntu strategy for machine-id is to be an empty file. Onboot, systemd maintains one in /run and eventually commits it to disk. So, yes it should be writable. And like Core20 snap must have it as an empty file.
[10:27] <xnox> mvo: bug report please.
[10:28] <zyga> xnox: on core20?
[10:29] <xnox>  zyga i don't understand your question. the systemd behaviour has been like that since the dawn of time in the ubuntu timeline.
[10:29] <zyga> xnox: "do you want me to report a bug on core20"
[10:30] <xnox> zyga:  yes
[10:30] <zyga> on it
[10:31] <zyga> xnox: https://github.com/snapcore/core20/issues/32
[10:31] <mup> Issue core20#32 opened: The machine-id file should be writable <Created by zyga> <https://github.com/snapcore/core20/issue/32>
[10:32] <xnox> tah
[10:34] <zyga> unit tests fail left and right, I guess travis containers are just as busy as launchpad lately
[10:38] <mvo> xnox: I can give you a PR if you want? or are you already on it?
[10:38] <xnox> mvo:  no, i'm not on anything. not serving interrupts, but doing things as they were queued up for me.
[10:42] <mvo> ok
[10:42] <mup> PR core20#33 opened: writable-path: make /etc/machine-id writable <Created by mvo5> <https://github.com/snapcore/core20/pull/33>
[10:46] <mborzecki> mvo: let me try to build a core20 snap and see if it works as expected
[10:52] <mvo> mborzecki: \o/
[10:58] <mup> PR snapd#8412 closed: httputil: increase httpclient timeout in TestRetryRequestTimeoutHandling <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8412>
[11:03] <mborzecki> hmm
[11:03] <mborzecki> /etc/machine-id /dev/mapper/ubuntu-data[/system-data/etc/machine-id] ext4   rw,relatime
[11:03] <mborzecki> /etc/machine-id tmpfs[/machine-id]                                   tmpfs  ro,size=203112k,mode=755
[11:03] <mborzecki> why 2 mounts tho?
[11:03] <zyga> mvo: I opened 7700 for a review
[11:04] <zyga> mvo: can you please look at what we could do for the upcoming sprint to be in the green
[11:04] <zyga> mvo: it's a RFC, not a final solution, I could use advise on where to go next
[11:04] <mborzecki> ok, on the first boot i had 2 mounts, but now after another reboot there's just one
[11:05] <zyga> oh, wait, I pushed without commiting
[11:06] <zyga> anyway, it doesn't change much
[11:06] <zyga> I've restarted the CLA check a few times and it's failing
[11:06] <zyga> https://travis-ci.org/github/snapcore/snapd/builds/669948734
[11:07] <mborzecki> yeah, looking good now
[11:07] <mborzecki> pstolowski: the persistent journal works now too
[11:08] <pstolowski> mborzecki: good, thanks. fwtw there is another issue with all this that I just described in my PR
[11:08] <pstolowski> mvo: ^ (sorry, I revoked your review)
[11:09] <mborzecki> pstolowski: hmm System Journal (/var/log/journal/bbac1383d2c640b3853c9f08d14e4116) is 32.0M, max 294.3M, 262.3M free, iirc he default is 10% of given block device size?
[11:10] <pstolowski> mborzecki: right, seems to match https://gist.github.com/JPvRiel/b7c185833da32631fa6ce65b40836887
[11:10] <zyga> I believe reviewing https://github.com/snapcore/snapd/pull/8416 helps, I cannot explain how though
[11:10] <mup> PR #8416: tests/session-tool: reset failed session-tool units <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8416>
[11:11] <zyga> apart from having fewer units after this test
[11:15] <zyga> https://github.com/systemd/systemd/issues/8672 is related
[11:15] <mvo> zyga: it looks reasonable
[11:15] <zyga> mvo: what should we do to take next steps?
[11:16] <mvo> pstolowski: what does that mean, should I review the pr again?
[11:17] <mvo> zyga: what is needed, can we just open this PR as is? I think samuele had a question in there but otherwise I think I'm ok with this as a first step for the UI
[11:17] <zyga> mvo: the PR is open, I addressed that question now
[11:17] <mvo> zyga: cool
[11:17] <zyga> mvo: ok, I'll pursue this a little more then
[11:17] <mvo> zyga: has the prereq landed?
[11:17] <mvo> zyga: if so we could target it for 2.45
[11:17] <zyga> mvo: close to it, if I can grab jamie for a moment today
[11:18] <zyga> mvo: I need to merge master after samuele's fixes again
[11:18] <mvo> nice
[11:18] <zyga> (the reorg)
[11:18] <pstolowski> mvo: no, please see the comment
[11:18] <pstolowski> mvo: we need to agree on what to do
[11:19] <mvo> pstolowski: I see now, thank you
[11:20] <mvo> pstolowski: this sounds to me like we want "yes/no/unset" and that maps to "persisent/disabled/auto", does that make sense?
[11:20] <mvo> (we want this as the possible config options?)
[11:21] <mvo> auto does not make that much sense on uc20 anymore though because something outside of the confinement would have to create it directly under /writable which is strange
[11:21] <mvo> otoh it's nice on the other releases :)
[11:25] <pstolowski> mvo: more less yes, maybe. but I fear this will be confusing. because if you say "unset" and it maps to "auto", that means that if it was "persisent" before it will still log into /var/log/journal (unless we or the user removes the dir).
[11:26] <mvo> pstolowski: good point
[11:28] <pstolowski> mvo: maybe we should simply override the default with persistent|none as soon as the option is ever set. but never remove /var/log/journal ?
[11:29]  * pstolowski lunch
[11:29] <pedronis> mvo: pstolowski: let's chat later
[11:31] <mup> PR snapcraft#3010 closed: cli: add progressive releases support to the release command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3010>
[11:31] <zyga> mvo: this fixes the cron issue with session-tool https://github.com/snapcore/snapd/pull/8417
[11:31] <mup> PR #8417: tests/session-tool: kill leaking closing session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8417>
[11:31] <mup> PR snapd#8417 opened: tests/session-tool: kill leaking closing session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8417>
[11:31] <zyga> mborzecki: is [ ! -e /proc/$pid ]; a good way to check if a process exists?
[11:45] <mvo> thanks zyga
[11:48] <mborzecki> zyga: in shell? hmm why not, kill -0 <pid> probably doesn't work
[11:48] <mborzecki> kill 0 ofc
[12:11] <zyga> I've seen this error a lot this week
[12:11] <zyga> 2020-04-03 12:01:56 Error executing google:ubuntu-core-16-64:tests/core/reboot (apr031118-002068) : kill-timeout reached after apr031118-002068 (google:ubuntu-core-16-64:tests/core/reboot) reboot request
[12:11] <zyga> reboot test fails
[12:12] <zyga> I wonder if that's something else impacting or is that something broken for real
[12:15] <pedronis> zyga: I re-reviewed #8123, not urgent by I left some questions and a remark there
[12:15] <zyga> looking
[12:15] <mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
[12:16] <zyga> pedronis: the hostfs change is not required because we reversed course on the ability to create directories that are absent on the host in response to interface connection
[12:16] <zyga> pedronis: so we will not create /var/lib/dhcp via hostfs
[12:16] <zyga> so no permissions or related cahnges
[12:17] <pedronis> ah, makes sense
[12:17] <zyga> I'll see for the comment in a moment
[12:17] <zyga> wrapping up some branches and I'd like to break before the call
[12:17] <zyga> thank you for the review, I think this will land soon :)
[12:20]  * zyga afk for some time, see you at the standup
[12:37] <cmatsuoka> cachio: I'm trying to run the encryption test on the nested backend, but got a git archive error, did you see this before?
[12:40] <cmatsuoka> ijohnson: good morning
[12:40] <cmatsuoka> ijohnson: I have a question about InitramfsUbuntuDataDir and friends
[12:42] <cmatsuoka> ijohnson: I see you moved the definitions from dirs to boot, but I need to reference the mountpoints from the target system and not initramfs. They're using the same path but they could potentially be different, so my feeling is that I should define UbuntuDataDir in dirs again
[12:47] <cmatsuoka> cachio: never mind, it was a local problem
[12:47] <ijohnson> hey cmatsuoka
[12:48] <ijohnson> cmatsuoka: for now it's probably fine to just use boot.InitramfsUbuntuDataDir from wherever you need it, even if it's not during the initramfs
[12:48] <ijohnson> cmatsuoka: we had this same issue with pedronis and mborzecki for the code that reboots into a particular system for the chooser
[12:48] <ijohnson> cmatsuoka: so the variable may get renamed eventually but for now it's fine to use it
[12:48] <mborzecki> hm hm?
[12:48] <cmatsuoka> ijohnson: right, that's how I implemented it so I'll leave it as is for now, thanks
[12:48] <ijohnson> hey mborzecki
[12:48] <mborzecki> ah right
[12:49] <mborzecki> crazy idea, hm maybe we could have automount units for that?
[12:54] <zyga> mborzecki: for what?
[12:54] <mborzecki> /run/mnt/ubuntu-{seed,boot,data}
[12:55] <pedronis> I am a bit missing how that would help?
[12:56] <mborzecki> pedronis: the mounts wouldn't need to be present all the time, we wouldn't need to call mount if we decide to mount them on deman
[12:56] <mvo> cmatsuoka: looks like 8103 is super close :) do you think you could  address the remaining comments from maciej and chris? I think then it's ready to land
[12:57] <pedronis> mborzecki: well we need them during initrams
[12:57] <pedronis> the question is what happens later
[12:57] <mborzecki> pedronis: right, but we don't need them all the time later
[12:57] <pedronis> mborzecki: who would write the units?
[12:57] <cmatsuoka> mvo: sure, working on that!
[12:57] <mborzecki> later == after switching the root
[12:57] <pedronis> there's no main partition after a while
[12:57] <pedronis> *after a while
[12:57] <pedronis> for a while
[12:58] <mborzecki> pedronis: iirc xnox had code that generates mount units for those in ubuntu-core-initramfs
[12:58] <mvo> cmatsuoka: thanks!
[12:59] <pedronis> mborzecki: there are issues, if they can come and go, any checks we do on them is problematic
[12:59] <mborzecki> yeah, that's true as well
[13:00] <pedronis> anyway at this point is all things to think about after beta
[14:13]  * zyga breaks to stretch a little
[14:13] <zyga> back hurts
[14:13] <roadmr> ouch :(
[14:16] <pedronis> ijohnson: I'm not sure I understand your comment about the switch
[14:16] <pedronis> I'm missing something
[14:16] <ijohnson> uh
[14:17] <ijohnson> pedronis: how can the caller set something on bsmark? what I did just now is have the caller pass in bsmark to the select function
[14:17] <ijohnson> here let me show you
[14:17] <pedronis> ijohnson: we return bsmark
[14:17] <pedronis> no?
[14:18] <ijohnson> yes, so how would the caller set properties on bsmark before calling the function ?
[14:18] <ijohnson> without passing in bsmark to the choose function ?
[14:18] <ijohnson> pedronis: https://pastebin.ubuntu.com/p/pDTXqbBsc4/
[14:18] <pedronis> it can set after
[14:19] <pedronis> the info is not really used inside the function
[14:19] <pedronis> afaict
[14:19] <pedronis> it's used in commit later I suppose
[14:20] <ijohnson> pedronis: the issue that all of this refactor is about is preventing us from loading bootenv multiple times i.e. calling ebl.Kernel() multiple times during a single instance of boot.MarkBootSuccessful
[14:20] <ijohnson> we only want to call loadBootenv once for boot.MarkBootSuccessful
[14:20] <pedronis> ijohnson: I understand, but maybe at this point is just easier for me to try what I have mind
[14:20] <pedronis> and see if it works
[14:20] <pedronis> I'm failing to explain myself it seems
[14:21] <ijohnson> yes, sorry I don't understand your suggestion
[14:21] <pedronis> it's very simple actually
[14:21] <pedronis> but maybe doesn't work
[14:21] <pedronis> let me see
[14:25] <pedronis> ijohnson: it works afaict
[14:26] <ijohnson> pedronis: can you show your code ?
[14:26] <pedronis> at least the tests still pass
[14:28] <pedronis> ijohnson: just this: https://paste.ubuntu.com/p/shzz4xgN3w/
[14:30] <ijohnson> ah okay sure that works fine
[14:31] <ijohnson> sorry I didn't understand that your suggestion was to do it after the choose* function
[14:32] <pedronis> well, I said it on irc, but not in the comment, it's actually the only way to make it work simply
[14:32] <pedronis> but as I commented the doc comment of the helper needs to clarify that it's possible/makes sense
[14:34] <ijohnson> yes that's fine
[14:36] <mup> PR snapd#8368 closed: github: goodbye travis <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8368>
[14:40] <mup> PR snapd#8418 opened: github: move static checks and spread over <Created by zyga> <https://github.com/snapcore/snapd/pull/8418>
[14:47] <pedronis> ijohnson: the problem with non managers_test.go  tests is that they don't check the logic triggered by ensureBootOk and the rest of the refresh undo
[14:48] <pedronis> but maybe you have thoughts about that?
[14:48] <ijohnson> pedronis: what other logic do we need to check in ensureBootOk ?
[14:48] <pedronis> ijohnson: we trigger a revert that will do a SetNextBoot , same with the undo
[14:48] <pedronis> that's where things intersect
[14:49] <ijohnson> mmm
[14:49] <ijohnson> this is slightly depressing that we need so many permutations of this kind of test now across 3 different packages :-/
[14:50] <pedronis> ijohnson: I'm open to think this through just saying that the chain of boot state changes
[14:50] <pedronis> ends with a SetNextBoot in the undo code
[14:50] <ijohnson> yes you're right there are more cases like that
[14:50] <pedronis> in some cases
[14:51] <pedronis> that's I think why we thought some cases would take care by themselves
[14:51] <pedronis> btw
[14:51] <pedronis> this logic on the undo path
[14:51] <pedronis> of a refresh
[14:53] <ijohnson> yes
[14:57] <pedronis> ijohnson: related to that the other important moving part is: snapstate.WaitRestart
[14:59] <mup> PR core20#33 closed: writable-path: make /etc/machine-id writable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core20/pull/33>
[15:00] <ijohnson> mborzecki: I will push up what I have on writing grub.cfg on ubuntu-boot from snapd so you can pick it up on monday if you have time
[15:00] <ijohnson> pedronis: yes indeed it's unclear where all we are currently covering the calls to boot from WaitRestart
[15:01] <pedronis> ijohnson: some of the managers_test should reach that
[15:01] <zyga> degville: [offtopic] did you finish the game?
[15:02] <ijohnson> pedronis: yes but I don't know if we have enough coverage of it is my point
[15:02] <mborzecki> ijohnson: going out now, please ping in the review
[15:02] <ijohnson> mborzecki: ack
[15:02] <ijohnson> have a nice weekend
[15:02] <mborzecki> ijohnson: thanks, you too!
[15:02] <degville> zyga: no, not yet. I've really been taking it slow, and playing it only on difficult, because I know it's not long.
[15:03] <zyga> degville: I'm very curious what's at the end
[15:03] <zyga> HL3 confirmed or what :D ?
[15:03] <zyga> but don't tell me
[15:03] <zyga> just tell me if it's worth that 1000 _once you know the ending_
[15:03] <degville> zyga: yeah, I've tried to skip all discussions about it so I don't know either.
[15:05] <pedronis> ijohnson: it's main API, is GetCurrentBoot so maybe related to looking more at state, what we need is all the state about this boot env state transitions to end up checking what that does return
[15:05] <degville> [off topic, cont.] I don't think there's any way it can warrant 1000 on its own. Despite being very good, it's an experiment in immersion more than anything. Which I think is the best VR can offer at the moment. But it is seeing City 17 from your own eyes, and totally convincing.
[15:08] <mup> PR snapd#8416 closed: tests/session-tool: reset failed session-tool units <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8416>
[15:10] <mup> PR snapd#8419 opened: Add libnvidia-rtcore as Nvidia library <Created by joedborg> <https://github.com/snapcore/snapd/pull/8419>
[15:10] <pedronis> ijohnson: the main chain  I think is always something like:  SetNextBoot -> bootloader cfg -> initramfs -> MarkBootSuccessful -> GetCurrentBoot (-> undo or revert SetNextBoot)
[15:11] <pedronis> ijohnson: that should be coverable from boot mostly, with a few managers_test on top to check actual integration
[15:12] <zyga> brb
[15:15] <pedronis> ijohnson: so maybe the first step is actually to add checks for GetCurrentBoot results in the significant places in all the TestHappy in boot_test.go
[15:18] <mup> PR snapd#8420 opened: httputil: increase testRetryStrategy max timelimit to 5s <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8420>
[15:27] <zyga> re
[15:35] <mvo> can someone do a second review for 8103 please?
[15:36] <zyga> mvo: I'm on it
[15:36] <zyga> mid way
[15:36] <mvo> zyga: \o/
[15:36] <mvo> zyga: thank you
[15:38] <mup> PR snapd#8419 closed: Add libnvidia-rtcore as Nvidia library <Created by joedborg> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8419>
[15:44] <mup> PR snapd#8329 closed: interfaces: allow raw access to USB printers <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8329>
[15:46] <mup> PR snapcraft#2987 closed: spread tests: set appropriate default base in snapcraft.yamls <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2987>
[15:53] <zyga> 7/9 files
[15:55] <zyga> https://github.com/snapcore/snapd/pull/8103#pullrequestreview-387367998
[15:55] <mup> PR #8103: snap-bootstrap: store encrypted partition recovery key <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8103>
[15:55] <zyga> I can +1 if somone will follow up
[15:56] <zyga> would +1 except for https://github.com/snapcore/snapd/pull/8103#discussion_r403103510
[15:56] <zyga> mvo: ^
[16:05] <ijohnson> pedronis: sorry was in meetings
[16:05] <ijohnson> pedronis: how much of these additional tests do you want in the open PR?
[16:06] <pedronis> ijohnson: should we have a quick HO?
[16:06] <ijohnson> pedronis: sure
[16:06] <ijohnson> SU?
[16:06] <pedronis> yes
[16:07] <ijohnson> cool I'm there
[16:08] <cmatsuoka> zyga: addressing that
[16:08] <zyga> thanks
[16:08] <zyga> I can +1 if you do
[16:12] <cmatsuoka> zyga: test "$(stat --printf='%u %a' /var/lib/snapd/device/fde/recovery-key)" = "0 600"
[16:12] <zyga> on focal this is my path
[16:12] <zyga>  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/var/lib/snapd/snap/bin
[16:12] <zyga> note the duplicate /snap/bin
[16:12] <zyga> and the non-ubuntu /var/lib/snapd/snap/bin
[16:12] <zyga> can anyone confirm?
[16:22] <ijohnson> zyga: I have the same
[16:22] <zyga> thanks
[16:22] <zyga> probably one-too-many helpers
[16:23] <ijohnson> to be clear, I have the duplicated /snap/bin and non-ubuntu /var/lib/snapd/snap/bin too
[16:23] <zyga> ack
[16:23] <pedronis> it's the same on bionic fwiw
[16:25] <zyga> fun
[16:25] <zyga> we must have done that earlier
[16:25] <zyga> I'll look on Monday
[16:25] <zyga> or maybe earlier
[16:25] <zyga> in our job interviews we should only have one question
[16:26] <zyga> How do you add one item to PATH
[16:26] <zyga> that will filter out everyone, including us
[16:26] <zyga> ;)
[16:26] <ijohnson> hooray
[16:33] <zyga> filed it just in case
[16:39] <zyga> mvo, cmatsuoka: https://github.com/snapcore/snapd/pull/8103#pullrequestreview-387413837
[16:39] <mup> PR #8103: snap-bootstrap: store encrypted partition recovery key <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8103>
[16:49] <cmatsuoka> zyga: fixed as suggested, thanks
[16:57] <zyga> https://github.com/snapcore/snapd/pull/8418/checks#step:8:9
[16:57] <mup> PR #8418: github: move static checks and spread over <Created by zyga> <https://github.com/snapcore/snapd/pull/8418>
[16:57] <zyga> govendor cannot build on go from xenial?
[17:05] <zyga> mvo: do you remember why we depend on 1.9 and not 1.10?
[17:10] <mvo> zyga: centos 7 iirc
[17:10] <zyga> I see
[17:10] <zyga> oh well
[17:10] <zyga> I'll do something
[17:10] <zyga> I solved the silly go in azure
[17:11] <zyga> they pre populate GIGs of software into the image
[17:11] <mvo> zyga: if we run a spread unittest task everywhere I think we are also good
[17:11] <zyga> including go 1.11+
[17:11] <zyga> I think we don't but I'll check
[17:11] <mvo> zyga, cmatsuoka thanks for working on 8103, looks like it's ready to go once tests have run
[17:11] <mvo> zyga: thanks!
[17:12] <zyga> heh
[17:12] <zyga> xenial cannot run our static checks
[17:12] <zyga> it's like moving in a maze
[17:12] <zyga> without lights
[17:12] <zyga> and knowing there are turds everywhere
[17:12] <mvo> zyga: xenial cannot run our static checks? why not?
[17:12] <zyga> https://github.com/snapcore/snapd/pull/8418/checks#step:10:18
[17:13] <mup> PR #8418: github: move static checks and spread over <Created by zyga> <https://github.com/snapcore/snapd/pull/8418>
[17:13] <zyga> because shellcheck in xenial is too old
[17:13] <zyga> we never noticed
[17:15] <mvo> zyga: woah, interessting
[17:15] <mvo> zyga: and sad
[17:15] <mvo> zyga: I thought travis would run those in xenial too - apparently not
[17:15] <zyga> everyone does custom shit
[17:15] <zyga> at least
[17:16] <zyga> and I really have to give them credit
[17:16] <zyga> github has excellent docs on what they do
[17:16] <zyga> and what's custom
[17:17]  * mvo nods
[17:17] <zyga> I wonder...
[17:18] <zyga> (insert harry potter mystery music)
[17:19] <zyga> mvo: check out https://github.com/snapcore/snapd/pull/8418/checks
[17:19] <mup> PR #8418: github: move static checks and spread over <Created by zyga> <https://github.com/snapcore/snapd/pull/8418>
[17:19] <zyga> wow :)
[17:20] <mup> PR snapcraft#3011 opened: repo: introduce install_source() and install_gpg_key() to Ubuntu <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3011>
[17:20] <zyga> mvo: snapd work in azure
[17:20] <mvo> zyga: nice
[17:20] <zyga> *snaps
[17:20] <mvo> zyga: looking
[17:20] <zyga> so shellcheck snap
[17:20] <mvo> zyga: yay
[17:20] <ijohnson> zyga: is it still a problem where "/" is owned by the vsts user or something
[17:21] <zyga> ?
[17:21] <zyga> vsts?
[17:21] <zyga> test
[17:21] <zyga> yes
[17:21] <zyga> snap-confine will refuse to work
[17:21] <ijohnson> :-(
[17:21] <ijohnson> but I found someone to talk to about that on MS side
[17:21] <zyga> can I help?
[17:22] <ijohnson> I can CC you on my email
[17:22] <ijohnson> the problem before was that we couldn't find anyone to talk to about who manages this on the github/microsoft side
[17:24] <mvo> zyga: fun (not!) - the travis run for 8103 has not even started yet
[17:25] <zyga> heh
[17:33] <pedronis> I pushed a comment there,  might need formatting in a follow up
[17:33] <zyga> it seems master is broken
[17:33] <zyga> https://api.travis-ci.org/v3/job/670608294/log.txt
[17:33] <zyga>     - google:ubuntu-core-20-64:tests/core/writablepaths
[17:33] <pedronis> https://github.com/snapcore/snapd/pull/8103/files#diff-13724d8f1f88168c790f24aafb4d2d13R137
[17:33] <mup> PR #8103: snap-bootstrap: store encrypted partition recovery key <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8103>
[17:33] <zyga> https://www.irccloud.com/pastebin/5FyicYVN/
[17:36] <mup> PR snapd#8421 opened: tests: enable unit tests on debian-sid again <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8421>
[17:39] <zyga> cachio: could you please review https://github.com/snapcore/snapd/pull/8418
[17:39] <mup> PR #8418: github: move static checks and spread over <Created by zyga> <https://github.com/snapcore/snapd/pull/8418>
[17:40] <cachio> zyga, sure
[17:40] <zyga> thanks!
[17:40] <zyga> this will unlock more chance to improve things
[17:40] <zyga> accelerate team-wide feedback
[17:41] <zyga> and get rid of the 50 minute limit
[17:47] <cachio> zyga, where are these going to run?
[17:47] <cachio> your box?
[17:47] <zyga> no
[17:47] <zyga> those run in azure
[17:47] <zyga> in the normal gh runners
[17:47] <cachio> ahh
[17:47] <zyga> btw, mvo: I got 16GB of ram into my box so we could easily run those 32 runners for extra overflow capacity
[17:48] <zyga> there's some cruft to shed
[17:48] <zyga> mainly to make it faster
[17:48] <zyga> but that's all _after_ this one
[18:08] <mup> PR snapcraft#3012 opened: plugins: install required apt sources and keys to system <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3012>
[18:13] <cachio> zyga, left you some questions in the PR
[18:14] <cachio> and closed it by mistake
[18:14] <cachio> then I reopened it
[18:16] <zyga> cachio: :D
[18:16] <zyga> cachio: I replied
[18:18] <zyga> cachio: remember that this is a long term game:
[18:18] <zyga> cachio: we get instant responsiveness
[18:18] <zyga> cachio: we get faster end-to-end
[18:18] <zyga> cachio: we get lower costs
[18:18] <zyga> cachio: if we cut rebuilds this is even faster
[18:18] <zyga> cachio: essentially boot into a system and start away
[18:19] <cachio> I think it is ok with this new workflow and if someone complains in the future we can revert to the run all the systems+ in parallel
[18:19] <zyga> yeah
[18:19] <zyga> I think this will be faster than old workflow already
[18:19] <cachio> the good part is that if some system fails, we just restart this one
[18:19] <zyga> we...
[18:19] <zyga> not yet
[18:19] <zyga> github has this but it's not released yet
[18:20] <cachio> ahh
[18:20] <cachio> well in the future well save that money too
[18:21] <cachio> +1
[18:21] <zyga> thanks!
[18:21] <zyga> let's improve it together
[18:23] <cachio> so far it worked very well
[18:23] <cachio> that's really possitive
[18:28] <mup> PR snapd#8422 opened: tests: skip "/etc/machine-id" in "writablepaths" test <Simple 😃> <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8422>
[18:29] <mvo> zyga: ^- this will unbreak master
[18:29] <zyga> ta
[18:29] <zyga> looking
[18:29] <mup> PR snapd#8417 closed: tests/session-tool: kill leaking closing session <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8417>
[18:30] <zyga> hmm
[18:31] <zyga> core20 tests
[18:31] <zyga> when do we run them
[18:31] <zyga> in first boot?
[18:34] <ijohnson> zyga: we run core20 tests during run mode after we reboot
[18:35] <zyga> mvo: ^
[18:35] <zyga> is this consistent with your patch?
[18:37] <ijohnson> zyga: yes "first boot" for uc20 -> first boot run mode
[18:37] <zyga> ahhh
[18:37] <ijohnson> there's also install mode, which is technically the "first" boot, but we don't call it that
[18:37] <ijohnson> install mode boot is more like the zeroth boot
[18:40] <mvo> zyga: yes
[18:40] <mvo> zyga: it's what maciej also saw, next reboot is fine for strange reasons
[18:41] <mvo> zyga: I think it happens when the /etc/machine-id is empty, then systemd gets confused somehow
[18:41] <zyga> systemd does have a first boot concept
[18:41] <zyga> not confuse
[18:41] <zyga> it's just a mode we never see in ubuntu
[18:41] <zyga> it's been normally used in fedora for a while IIRC
[18:41] <mvo> zyga: right, sorry, my wording was too strong
[18:41] <zyga> well
[18:41] <zyga> until now :)
[18:43] <zyga> https://www.freedesktop.org/software/systemd/man/systemd-firstboot.html
[18:43] <mvo> zyga: for 8418 I think we should try to also run go-latest unit tests in a GH runner and then remove the unit tests from travis entirely. but that is followup material it seems
[18:43] <zyga> go-latest? snap?
[18:44] <mvo> zyga: yes
[18:44] <mvo> zyga: sorry for being cryptic
[18:44] <zyga> sure thing
[18:45] <zyga> please don't apologize for anything :)
[18:45] <mvo> zyga: sorry
[18:45] <zyga> haha :)
[18:45] <mvo> :P
[18:45] <mvo> couldn't resist :)
[18:45] <zyga> After the machine ID is established, systemd(1) will attempt to save it to /etc/machine-id. If this fails, it will attempt to bind-mount a temporary file over /etc/machine-id. It is an error if the file system is read-only and does not contain a (possibly empty) /etc/machine-id file.
[18:45] <zyga> systemd-machine-id-commit.service(8) will attempt to write the machine ID to the file system if /etc/machine-id or /etc are read-only during early boot but become writable later on.
[18:46] <mvo> zyga: yeah, I think systemd is still a bit confused because it should be possible to save /etc/machine-id (unless it tries a save-and-atmoic-move
[18:46] <zyga> it may try too early perhaps?
[18:46] <zyga> I don't know
[18:46] <mvo> zyga: it still procceeds to the bind-mount step it seems
[18:46] <mvo> zyga: yeah, it's not clear from the docs, I am too lazy to look at the source
[18:46]  * mvo should probably do that still :(
[18:46] <zyga> maye not today
[18:47] <zyga> I think it's okay to EOD at 9PM on Friday
[18:50] <mvo> maybe, I still want a) master green b) recovery-key PR on master c) GH actions on master d) icecream!
[18:52] <zyga> mvo: e) pony
[18:52] <zyga> or pony ice cream, as you wish
[18:52] <mvo> zyga: nay, I'm vegetarian
[18:53] <zyga> it's like eating a very large lump of grass anyway
[18:53] <mvo> zyga: hahaha
[19:12] <zyga> I think gnome software is leaking
[19:12] <zyga> it's using more memory than FF does
[19:12] <zyga> the background service I don't even see
[19:47] <mup> PR snapcraft#3011 closed: repo: introduce install_source() and install_gpg_key() to Ubuntu <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3011>
[20:07] <mvo> zyga: I think travis defeated me for today, still no test run finished of my list of things I want so I will check back in my morning. have a good weekend
[20:07]  * mvo waves
[20:07] <zyga> o/
[20:42] <mup> PR snapd#8420 closed: httputil: increase testRetryStrategy max timelimit to 5s <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8420>
[20:43] <mup> PR snapd#8103 closed: snap-bootstrap: store encrypted partition recovery key <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8103>
[20:44] <King_InuYasha> kyrofa<EMAIL_ADDRESS>[20:50] <kyrofa> King_InuYasha, yeah I saw it. That's what I get for waiting to respond I suppose
[20:51] <kyrofa> I actually resolved the needinfo ping before he sent that email, as you can see from the activity log he provided in the email :P
[20:52] <kyrofa> King_InuYasha, I wasn't going to respond to the email though, unless I should
[20:53] <King_InuYasha> kyrofa: you probably should, just be cordial and explain what's going on ;)
[20:53] <kyrofa> So I need to respond in multiple places? Not the most efficient of processes
[20:54] <King_InuYasha> kyrofa: nah, just respond in the main email and close out the bugs accordingly
[20:57] <King_InuYasha> the main email is to let the rest of the community know you're alive :)
[21:11] <mup> PR snapd#8423 opened: tests: uc20 nested suite part II <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8423>
[21:41] <mup> PR snapd#8422 closed: tests: skip "/etc/machine-id" in "writablepaths" test <Simple 😃> <⚠ Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8422>
[23:51] <mup> PR snapd#8424 opened: cmd/snap-bootstrap/initramfs-mounts: cross-check partitions when mounting <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8424>


[09:24] <mandel> morning!
[09:38] <JamesTait> Happy Pancake Day! :D
[10:28] <czajkowski> has the add a device to U1 gone hiding on oneiric ?
[10:29] <czajkowski> trying to add a computer but cannot see the add a device anywwhere :/
[10:32] <czajkowski> twitpic.com/8mqze8  every time I click I've already have an ac it goes grey
[10:45] <mandel> czajkowski, let me check
[10:46] <mandel> czajkowski, have you joined?
[10:46] <czajkowski> joined?
[10:46] <mandel> czajkowski, in the image, you have to provide your creds
[10:46] <czajkowski> yeah so i click on the I've an ac
[10:46] <czajkowski> but it keeps going grey
[10:47] <czajkowski> but the U1 folder on my desktop says it's syning
[10:47] <mandel> hm.. funny
[10:47] <mandel> czajkowski, do the following, go to the keyring and remove the Ubuntu One creds key
[10:48] <czajkowski> funny isn';t the word I'd use , but possibly the politest :)
[10:48] <mandel> czajkowski, without the creds it sso will ask for them and you will be able to re-add the machine, then you should be ready to go
[10:49] <czajkowski> mandel: cheers
[10:50] <mandel> czajkowski, no problem, let me know if everything works ok
[11:05] <rye>   File "/usr/lib/python2.7/dist-packages/ubuntuone-control-panel/ubuntuone/controlpanel/gui/qt/filesyncstatus.py", line 73, in <module>
[11:05] <rye>     {'msg': WARNING_MARKUP % FILE_SYNC_ERROR, 'action': FILE_SYNC_RESTART,
[11:05] <rye> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 24: ordinal not in range(128)
[11:06]  * rye wants contrl panel
[11:06] <rye> also, i want the reactor to stop when u1sdtool finishes
[11:42] <mandel> rye, cute!
[11:42] <mandel> rye, gatox is going to love that we still have unicode errors ;)
[11:47] <rye> mandel, my locale is es_ES though
[11:48] <mandel> rye, even more fun :P
[11:54] <czajkowski> mandel: thanks that fixed it I think, I had to add my new address to it which could have been the issue as my sso changed.  But files on old computer say they are updates to u1 but checking them on other machine U1 isn;t showing them still
[11:55] <mandel> czajkowski, give it some time, if after lunch you have issues we can take a look at the logs
[11:57] <czajkowski> sure thanks
[12:05] <mandel> ok, early lunch for me
[12:05]  * mandel early lunch
[12:41] <gord> hey peeps, the ubuntuone plugin in rhythmbox is manually  adding ~/.ubuntuone/Purchased from Ubuntu One and ~/.local/share/ubuntuone/Purchased from Ubuntu One/ - causing all my music to get indexed twice. any way i can get it to stop doing that? its rather annoying
[12:50] <rye> gord, is the last one a symlink to the first one?
[12:50] <gord> rye, yeah, i assume it was created by u1 at some point, no idea if it still uses it
[12:51] <rye> aquarius, ^ do you recall?
[12:52] <aquarius> gord, it's created by the Rhythmbox plugin; it's there because people requested that music was placed in an XDG folder, and the symlink was a compromise to do that.
[12:53] <gord> aquarius, can we get the rb plugin to only index from one of them not both then? it actually only adds weird thing is, the plugin only adds ~/.ubuntuone/Purchased from Ubuntu One/ to the rhythmbox library gsettings key, doesn't add the other one, no idea how its even getting the library to update from there
[12:54] <aquarius> gord, RB shouldn't be indexing the .local folder
[12:54] <aquarius> gord, if it is... it's not supposed to be.
[12:54] <gord> i agree ;) if i remove the u1 plugin it stops indexing that folder though
[12:55] <aquarius> gord, davmor2 and repete seemed to have this problem too. dobey, ping about this; why would RB be indexing music in .local/share if it's not in the library gsettings key to do so?
[13:02] <gord> aquarius, dobey, looks like MusicStoreWidget.py manually adds your library from the XDG directory where-as ubuntuone.py adds the .ubuntuone/Purcha.. directory to your gsettings key
[13:02] <aquarius> so that sounds like we're doing both and shouldn't be. dobey, ^
[13:42]  * mandel back
[13:46] <alecu> hello all!
[13:46] <ralsina> hello alecu!
[13:47] <ralsina> restarting session because this is not working :-/
[13:49] <ralsina> Grmbl, for some reason my dbus system bus is crashing and things go awesomely bad
[13:55] <mandel> alecu, ralsina hello!
[13:55] <alecu> hola mandel!
[13:55] <mandel> alecu, we have ssl dialog! I need to clena the code and will ask for reviews :)
[13:56] <mandel> alecu, how did the long weekend go?
[13:57] <alecu> mandel, it's still going on... I had to cut it short, because I'll probably be taking this friday off.
[13:57] <alecu> mandel, everybody is sleeping at my home... it's a very quiet day.
[13:57] <mandel> alecu, ah, well better on a friday hehe
[13:57] <mandel> :D
[14:01] <alecu> mandel, I'm looking at your osx porting notes, and looking at the inotify docs... and I just realized this:
[14:01] <alecu> cat /proc/sys/fs/inotify/max_user_watches -> 8192
[14:02] <mandel> alecu, la puta!
[14:02] <alecu> mandel, that means that syncdaemon on linux can handle a maximum of 8192 folders, total.
[14:02] <ralsina> alecu, mandel: BTW we have a bug about noticing when we run out of watches and telling the user about it
[14:02] <alecu> mandel, (probably a bit less if other apps are using watches too)
[14:03] <ralsina> alecu, mandel: and that is better done using syctl so it's persistent
[14:03] <mandel> I love how we hit some many doggy things.. who wants to invest in alecu practicing kernel programming? raise your hand o/
[14:04] <alecu> mandel, I'll just make a patch to increase that number... say... tenfold
[14:04] <mandel> alecu, lol that is cheating!
[14:11] <dobey> aquarius, gord: there should be a bug filed about duplicate entries already
[14:12] <aquarius> dobey, I thought you already knew about this, indeed
[14:15] <rye> mandel, ralsina please pass this to gatox - bug #937809
[14:15] <rye> bug 937809 ?
[14:15] <mandel> ubuntulog, you son of a ...
[14:15] <mandel> puto, responde!
[14:15] <mandel> ..
[14:15] <rye> https://bugs.launchpad.net/ubuntu/+source/ubuntuone-control-panel/+bug/937809
[14:15] <mandel> ubuntulog, Y U NO ANSWER!
[14:15] <rye> ubuntuone-control-panel-qt crashed with UnicodeDecodeError in /usr/lib/python2.7/dist-packages/ubuntuone-control-panel/ubuntuone/controlpanel/gui/qt/filesyncstatus.py: 'ascii' codec can't decode byte 0xc3 in position 24: ordinal not in range(128)
[14:16] <ralsina> rye: hahahaha gatox is going to go insane ;-)
[14:16] <ralsina> rye: I will buy him cake for his 100th unicode bug though
[14:37] <elopio> rmcbride: hi. Are you working today?
[14:38] <rmcbride> elopio: yes I am.
[14:38] <elopio> rmcbride: great. Can you meet with me at 16:00 UTC?
[14:39] <rmcbride> elopio: I have to do the time conversion to know when that is, but sure :)
[14:39] <elopio> :)
[14:40] <elopio> joshuahoover is sick today, and pfibiger will not be available, so this week will be just the two of us.
[14:40] <rmcbride> elopio: OK, and I have the time marked now
[14:47] <dobey> mandel: ubuntulog isn't the bugs bot
[14:48] <dobey> hrmm
[14:48] <mandel> dobey, I just need to yell at someone :P
[14:48] <dobey> the bot is missing
[14:48] <mandel> dobey, give me the right target!
[14:48] <dobey> but that bug is private so it wouldn't have helped anyway
[14:48]  * dobey wonders which bot it was
[14:49]  * dobey reboots real quick
[14:52] <rye> no longer private
[14:54] <dobey> ugh now there is an ugly triangle in the bottom corner of my windows
[15:00] <mandel> me?
[15:00] <mandel> dobey, does the triangle move when you move the mouse?
[15:01] <dobey> mandel: it's the resize thing yes
[15:03] <mandel> dobey, ralsina, alecu no stand up, right?
[15:03] <alecu> me
[15:03] <ralsina> I am on a call, so standup if you have notes,or not
[15:04] <ralsina> But tomorrow, we have one!
[15:04] <mandel> then tom, right alecu dobey ?
[15:04] <dobey> alecu: aren't you on holiday?
[15:05] <urbanape> do we do standup in Mumble or just here?
[15:05] <ralsina> urbanape: it's here
[15:06] <ralsina> urbanape: are you already on desktop? I thought you switched next week! :-)
[15:06] <urbanape> you said monday!
[15:06] <urbanape> if you don't need me until next week, that's okay, too.
[15:06] <ralsina> urbanape: well, next week has a monday too. You said you needed two weeks for iOS :-)
[15:06] <dobey> urbanape is switching?
[15:06] <ralsina> dobey: on a loan
[15:06] <urbanape> we've always got polishing on iOS stuff to do
[15:07] <urbanape> okay, cool. See you all next week!
[15:07] <ralsina> urbanape: hahaha, interesting problem we are having. See you next week :-)
[15:07] <mandel> if only there was a day we could identify days by ids.. a way the will never repeat and would be exact..
[15:08] <ralsina> urbanape: we still need to talk a little about how we are going to do it. Want to have a conversation with you, alecu and mandel tomorrow if that's ok for you both
[15:08] <urbanape> sure thing
[15:08] <mandel> I know, I'm going to write a standard for it.. maybe something like dividing the year in sectors and those sectors in days and then add an id for each and combine them...
[15:08] <alecu> dobey, I'm on a swap from the long holiday
[15:08] <mandel> I'm going to call it calendar!! CALENDAR buahauhauhaauha
[15:08] <mandel> :P
[15:08] <ralsina> mandel: ha! you are so subtle.
[15:09] <mandel> ralsina, hehe
[15:09] <mandel> ralsina, I'm in for the chat
[15:09] <ralsina> mandel: can you schedule that call tomorrow? As early as possible for all.
[15:09] <mandel> ralsina, you know my sense of humor hehe it was a parallel conversation :)
[15:09] <dobey> mandel: does each day have a UUID?
[15:09] <mandel> dobey, I think is the best way.. how else?
[15:10] <dobey> Today is Boomtime, the 52nd day of Chaos in the YOLD 3178
[15:10] <dobey> i prefer that calendar :)
[15:15] <rmcbride> wow. I haven't played KoL in forever dobey
[15:16] <rye> dear software, please stop fixing itself when I am debugging you
[15:16] <dobey> heh
[15:16] <rye> also, does anybody have a working qt control panel now (not with nightlies)
[15:16] <rye> oh, ralsina btw
[15:17] <rye> ralsina, u1sdtool hangs (and jono filed a bug) - is it going to work/working in nightlies?
[15:17] <dobey> rye: it is a known problem
[15:29] <dobey> ugh. the weather, it hurts.
[15:49] <ralsina> LUNCH!
[15:58] <dobey> lunch and errands here. bbiab
[16:04] <mandel> ralsina, ping?
[16:15] <mandel> alecu, ralsina can I have reviews for https://code.launchpad.net/~mandel/ubuntu-sso-client/ssl-dialog/+merge/94012
[16:15] <mandel> alecu, ralsina if that branch lands we made the UI freeze deadline, right?
[16:19] <alecu> mandel, probably not. Branches are supposed to land on friday in order to be packaged today, so they get some test in nightlies.
[16:19] <mandel> alecu, :(
[16:27] <mandel> alecu, ralsina also, a very simple one: https://code.launchpad.net/~mandel/ubuntu-sso-client/fix-credentials-text/+merge/94016
[16:31] <mandel> does the qt control panel ask for credentials every single time?
[16:31] <mandel> it seems so in my machine
[16:56] <beuno> dobey, heya. Any idea what package I can be missing if I no longer have u1 nautilus integration?
[16:57] <apol_> hi, I need to get an Ubuntu SSO token to do some client operations (to ubuntu rnr service)
[16:57] <apol_> does anybody know if there's any code I can look into?
[16:59] <mandel> apol_, what exactly do you need to do?
[17:04] <mandel> apol_, sorry system went bananas
[17:04] <apol_> mandel: well, login to get a token then issue some requests to the rnr API
[17:05] <ralsina> mandel: pong
[17:05] <mandel> apol_, take a look at the lp:ubuntu-sso-client code
[17:05] <ralsina> mandel: we arenot supposed to land anything today
[17:05] <mandel> apol_, although you can also use the ubuntu sso client dbus api to do that if you are not in a headless server or something
[17:05] <mandel> ralsina, ok, no reviews then?
[17:06] <ralsina> mandel: you are free to convince nessita about it. Let's have the reviews done just in case
[17:06] <apol_> mandel: no, it's for muon, KDE/Kubuntu's software center
[17:06] <mandel> ralsina, well, it can be blocked, I'll keep moving in my pipeline
[17:06] <mandel> apol_, well, here is the things, there is a ubuntu sso client ui done in qt and we are working on making that the default
[17:07] <apol_> mandel: what package provides this API?
[17:07] <mandel> apol_, so using the dbus api sounds like a more reasonable approach, right?
[17:07] <mandel> apol_, let me get the package name
[17:07] <apol_> mandel: well, it's a possibility, haven't made up my mind yet. It also depends on the dependencies it pulls
[17:07] <mandel> apol_, ubuntu-sso-client
[17:08] <mandel> apol_, it should just pull qt, which is there and the correct code to perform the calls
[17:08] <ralsina> mandel, alecu,dobey: I forgot to mention, but brian is onjury duty, supposed to come back tomorrow, but you never knoe
[17:08] <ralsina> know
[17:08] <mandel> ralsina, hahaha that's so american :)
[17:09] <apol_> mandel: it depends on a lot of python and gtk stuff :)
[17:09] <ralsina> mandel: yes, if he lived in Valencia, his contribution to the legal system would be a dentist appointment instead ;-)
[17:09] <apol_> (in 11.10)
[17:09] <mandel> apol_, atm yes, that is why you should look at lp:ubuntu-sso-client
[17:10] <mandel> apol_, take a look at the nightlies
[17:10] <apol_> mandel: ok, I will
[17:10] <mandel> ralsina, yes, and he will get money so that the politician did not get in jail :)
[17:10] <ralsina> mandel: indeed. Win win! ;-)
[17:10] <mandel> apol_, if you have any questions feel free to ask me, ralsina, gatos or nessita
[17:11] <apol_> ok, thank you :)
[17:13] <mandel> apol_, no problem, here to help :)
[17:13] <apol_> apparently you're all spanish in this group no? :P (just saw the names in lp)
[17:13] <apol_> (i'm from barcelona)
[17:14] <mandel> apol_, most of them are argentian.. so I keep listening to bad pronunciation hehe
[17:14] <apol_> :)
[17:15] <apol_> cool
[17:15] <mandel> apol_, I'm from mallorca
[17:15] <apol_> nice :)
[17:17] <mandel> WTF: http://www.ubuntu.com/devices/android
[17:18] <mandel> so we run on 'some' arm phones :P
[17:21] <mandel> ok, EOD for me, got rugby and I need to walk the dog
[17:21]  * mandel away
[17:40] <dobey> beuno: ubuntuone-client-gnome ?
[17:41] <beuno> dobey, indeed, thanks
[17:42] <dobey> apol_: you can use ubuntu-sso-client. there is a qt front-end for it now. look at how ubuntu-software-center uses it, and you should probably just make similar requests
[17:46] <apol_> dobey: ubuntu-software-center uses a qt client? what would this look like? a library?
[17:51] <dobey> apol_: no. ubuntu-software-center uses ubuntu-sso-client
[17:51] <dobey> apol_: ubuntu-sso-client now has a qt front-end as well as a gtk+ front end, in 12.04 (ubuntu-sso-client-qt vs. ubuntu-sso-client-qt)
[17:51] <dobey> err
[17:51] <dobey> one of those is gtk
[17:52] <apol_> ok :)
[17:52] <elopio> dobey: do you have time to give me a hand?
[17:53] <dobey> elopio: i never have time for anything, but what's up? :)
[17:53] <elopio> I need to start the qt control panel with the qt -testability option.
[17:53] <elopio> dobey:
[17:53] <elopio> dobey: I know. The question was a formality, I was going to ask for your help anyway ;)
[17:54] <dobey> elopio: i don't know what the "qt -testability option" is
[17:54] <apol_> dobey: would you be open to external contributions? like supporting fdo's secretservice instead of gnome keyring?
[17:54] <elopio> dobey: there's a qt testability driver that allows a testing framework to inspect the UI objects.
[17:54] <elopio> on the documentation, it says:
[17:55] <elopio> If your application is a standard Qt application, use the "-testability" argument:
[17:55] <elopio> myapp -testability
[17:55] <dobey> apol_: ubuntu-sso-client already uses the fdo secrets dbus api
[17:55] <apol_> ah
[17:55] <apol_> awesome
[17:55] <apol_> :) sorry dobey
[17:55] <elopio> dobey: but if I do that, I get: ubuntuone-control-panel-qt: error: no such option: -t
[17:55] <apol_> i'll have to take a look into the new version then
[17:56] <dobey> apol_: if the packages currently in ubuntu depend on gnome-keyring specifically, it's likely to work around some other packaging issues or issues in the keyring itself :)
[17:57] <dobey> elopio: i think you'll have to ask ralsina or nessita probably. i guess control panel is doing its own options thing instead of using the qt API, and breaking that.
[17:57] <elopio> dobey: so, I guess that I can hardcode the -testability argument where the qt control panel is started. But I don't know where it is.
[17:58] <elopio> dobey: ok. I'll ask them when they return.
[17:58] <elopio> thanks.
[17:58] <apol_> dobey: is it documented anywhere how to use this ubuntu-sso-client?
[18:02] <dobey> apol_: i really don't know. i always just look at the code regardless of whether there is documentation or not for something, if i can. i guess it's a bit of a habit developed from being used to having no/poor/broken documentation :)
[18:03] <dobey> hrmm, i don't see it on http://developer.ubuntu.com/resources/platform/api/ though
[18:03] <dobey> aquarius: ^^ do you know?
[18:03] <aquarius> the sso-client desktop software isn't documented yet, I'm afraid :(
[18:04] <apol_> hm
[18:04] <apol_> dobey: so what code should I look in? lp:software-center?
[18:05] <aquarius> apol_, bear with me, because I'm not quite following what you want, so could I get you to explain again? Sorry
[18:05] <aquarius> apol_, you need an Ubuntu One oauth token in order to do something, yes?
[18:06] <apol_> aquarius: i'm working on Kubuntu's software-center thing. AFAIU, I need ubuntuone oauth token to ask for stuff
[18:06] <apol_> i've been suggested to look into this ubuntu-sso-client
[18:06] <apol_> aquarius: I'm trying to figure out if it's a solution
[18:07] <aquarius> apol_, ah, right, the token is for doing ratings and reviews and so on, got it. In that example, you're dealing purly with Ubuntu SSO -- that's not Ubuntu One, so don't be confused by things talking about Ubuntu One tokens.
[18:07] <aquarius> apol_, yes, the best place to look right now is software-center.
[18:07] <dobey> aquarius: he wants to do exatly what software-center is doing, but in kde instead :)
[18:08] <apol_> dobey: yes, basically
[18:08] <aquarius> dobey, right, and that's a good thing -- the point is that that's not an Ubuntu One token, so don't be confused by all of U1's token stuff because that's not connected. :)
[18:08] <dobey> apol_: so yeah, look at software-center code that does the authorization stuff.
[18:09] <dobey> aquarius: right. i don't think there is any confusion about that. nobody ever mentioned any u1 tokens in the discussion until you did just now :)
[18:09] <aquarius> :)
[18:09] <apol_> well then is this the right channel? i was told it was connected somehow (yep, my ubuntu knowledge isn't the best)
[18:09] <aquarius> that's why I said I was confused ;)
[18:09] <dobey> apol_: we developed ubuntu-sso-client yes
[18:09] <apol_> aquarius, dobey: so what's this ubuntu-sso-client about?
[18:10] <apol_> or, how can I use it?
[18:10] <dobey> apol_: it's the client software for talking to the ubuntu sso server and doing authorization for your application
[18:10] <ralsina> apol_: should not be a lot of code, either. Look for Credentials. ubuntu-sso-client is a way for desktop apps to authenticate to anything that uses login.ubuntu.com
[18:11] <apol_> well then it's a daemon right
[18:11] <ralsina> apol_: it provides a service via Dbus but it doesn't need to be running all the time
[18:11] <apol_> that exposes some API through dbus?
[18:11] <dobey> apol_: look at the software-center code where they do the authorization and make the dbus calls to ubuntu-sso-client, then convert to whatever language you are deeloping in, and make the same calls with similar arguments
[18:11] <ralsina> apol_: when the app needs it, it will start
[18:12] <dobey> apol_: yes, it's a service, and the front-ends are separate processes now
[18:12] <ralsina> apol_: but yes, you can act as if it were running all the time :)
[18:12] <dobey> apol_: so you can request the gtk+ one or the qt one specifically now as well i think, but they should both look the same regardless
[18:13] <apol_> well, just grep'd ubuntu-sso-client through the software-center code and the only places I get are comments
[18:13] <apol_> or debian/changelog
[18:14] <elopio> ralsina: do you have time to give me a hand? :D
[18:14] <ralsina> elopio: sure!
[18:14] <elopio> ralsina: I need to pass an -testability argument to the qt control panel.
[18:14] <ralsina> elopio: we are not passing the apps to QApplication
[18:14] <ralsina> elopio: that's a bug
[18:15] <ralsina> You can hardcode it though, to seeifit works. Look forQApplication and add it :-)
[18:15] <elopio> ralsina: I thought of hard-coding it where the application is started, but I know where's that.
[18:15] <ralsina> elopio: ok, let me find it for you
[18:15] <ralsina> elopio: gonna take just 2' (need to checkout trunk)
[18:16] <elopio> ralsina: the closest I got was ubuntuone/controlpanel/gui/qt/uniqueapp/linux.py
[18:16] <elopio> but I don't know how to add the -testability argument there.
[18:16] <ralsina> elopio: yes, that is very close. Give me 1' and I will give you a diff
[18:17] <ralsina> elopio: change super(UniqueApplication, self).__init__(argv) to super(UniqueApplication, self).__init__(argv+"-testability")
[18:17] <ralsina> elopio: that should do it
[18:17] <dobey> apol_: well "ubuntu-sso-client" isn't a valid variable name, and isn't a valid dbus interface name, so you probably won't find much looking for that exact string. :)
[18:17] <dobey> apol_: i'm sure the authorization is a contained module in the code though, so should be easy to find
[18:18] <dobey> apol_: and "com.ubuntu.sso" i think is the dbus interface name, though is probably defined in a constant in the authorization code, and re-used
[18:18]  * apol_ is diving through com.ubuntu.sso in qdbusviewer...
[18:19] <elopio> woohoo
[18:19] <elopio> ralsina: that would be super(UniqueApplication, self).__init__(argv+["-testability"])
[18:19] <dobey> apol_: you can also ask in #ubuntu-desktop for more specific help about the software center. it's not part of the ubuntuone projects, so we don't really know much about it ourselves :)
[18:19] <elopio> ralsina: it worked, thanks.
[18:19] <apol_> dobey: ok :)
[18:23] <dobey> ok, really need to make releases now
[18:25] <ralsina> elopio: could you file a bug against u1cp about us respecting qt's command line options?
[18:29] <apol_> dobey: for what I see, the sso dbus interface exposes everything needed, why do you need a qt and gtk interface?
[18:29] <elopio> ralsina: sure, I will.
[18:30] <dobey> apol_: the ubuntu-sso-login service has to pop up UI for a user to log in or create an account. that UI can either be gtk+ or qt currently.
[18:31] <apol_> dobey: the login method asks for username, password and appname
[18:32] <dobey> apol_: i think that one is deprecated. and well, you probably don't know the username and password already. and also, if auth fails, it will have to pop up a dialog again
[18:32] <apol_> deprecated :D great
[18:32] <apol_> dobey: well, thing is I can do that in the client too
[18:35] <dobey> apol_: i think you are supposed to call login() on the CredentialsManagemenet interface
[18:36] <dobey> apol_: the SSOLogin interface is what the UI uses to talk to the main sso login service (as they are separate processes)
[18:36] <apol_> dobey: if I use the login() method I get this error: "Unable to find method login on path /com/ubuntu/sso/credentials in interface com.ubuntu.sso.CredentialsManagement"
[18:41] <dobey> apol_: with what arguments are you passing it?
[18:41] <apol_> dobey: it has no arguments
[18:41] <dobey> apol_: the signature is 'sa{ss}'
[18:43] <dobey> apol_: so you need to pass the app name, and a dict with help_text, ping_url, tc_url, and window_id if any of them are necessary
[18:43] <apol_> ok
[18:43] <apol_> i found what was going on
[18:44] <apol_> I needed the com.ubuntu.sso.ApplicationCredentials::login_to_get_credentials method
[18:48] <apol_> dobey: well, got something to work somehow
[18:48] <apol_> thanks a lot for your help
[18:48] <apol_> (and others too :)
[18:48] <dobey> sure
[22:49] <dobey> later!


[03:17] <snap-l> http://www.faterpg.com/licensing/
[12:01] <rick_h__> morning
[12:01]  * rick_h__ needs more sleep
[13:10] <widox_> whoa trevlar, having some issues?
[13:12] <trevlar> do I keep disconnecting?
[13:12] <trevlar> hmm yeah didn't notice
[13:22] <trevlar> not sure if it was comcast or what. sorry for the flood :/
[13:41] <snap-l> Good mornign
[13:41] <snap-l> https://bmark.us/craig/recent/deal?count=50&page=0#
[13:42]  * snap-l is finding a use for Bookie as a URL shortener. ;)
[14:21] <jrwren_> how can I make python be like perl -p ?
[14:21] <jrwren_> python -c 'import sys;for line in sys.stdin.readlines(): print line' says error
[14:31] <snap-l> jrwren_: I'm sure there's a way, but I've never explored it
[14:31] <snap-l> seems like one of those "you're doing it wrong" things.
[14:32] <snap-l> even though it's likely supported
[14:32] <snap-l> "This is a big change, consumers don't always love change, and there's a lot of education we have to provide to make sure that people understand."
[14:32] <jrwren_> i gave up.
[14:32] <jrwren_> then i ran into other pythonisms.
[14:32] <jrwren_> python is a nice language.
[14:33] <snap-l> This statement is going into every business management book as how not to do PR with your customers
[14:33] <snap-l> jrwren_: It's no perl / awk drop-in. ;)
[14:33] <jrwren_> yup
[17:14] <snap-l> How's the afternon treating everyone?
[17:14] <greg-g> not there yet
[17:14] <snap-l> Well hurry up, dammit
[17:15] <snap-l> Pretty soon it'll be evening and you'll just be starting the afternoon
[17:15] <snap-l> amateurs
[17:16] <greg-g> lazy coast
[19:43] <jrwren_> rick_h: help me with my python, you are my only hope.
[19:43] <jrwren_> i've go a module level function which then imports another module which I need to patch. is there any hope for me?
[19:43] <jrwren_> I htink I should just move the import statement to the top of file. who knows, maybe I'll get better perf by only importing once?
[19:45] <jrwren_> yes, that is what I shall do.
[19:45] <jrwren_> thank you rubberduck rick_h
[19:52] <greg-g> rubber ducky you're the one, you make bathtime lots of fun
[19:55] <snap-l> We've secretly replaced rick_h with a rubber ducky. Let's see if anyone notices.
[20:22] <rick_h> hah, no one will notice
[20:22] <rick_h> jrwren_: yes, conditional imports like that tend to be more pita than they're worth for most modules
[20:22] <rick_h> jrwren_: and make for non-obvious bugs when you don't see the import
[20:23] <rick_h> though sometimes circular imports drive you batty and end up forcing it :(
[20:24] <jrwren_> plus... why not import a module which imports lots of other modules every time a function is called :)
[20:29] <rick_h> well, python will only import once
[20:29] <rick_h> it's a manual step to re-import something
[20:29] <jrwren_> i thought it reruns the module commands?
[20:29]  * jrwren_ tests
[20:30] <rick_h> jrwren_: no, only does on the first time, then it's in the sys.modules or some magic place and doesn't re-import
[20:30] <rick_h> it's why using things like ipython/etc are a pita sometimes when you're changing the module you're tinkering with
[20:30] <rick_h> some provide a shortcut to force a re-import
[20:30] <jrwren_> indeed.
[20:31] <jrwren_> i knew reimport was differnt
[20:31] <jrwren_> but I really thought it ran the module statements again. shows wtf I knew.
[20:32] <rick_h> yes, it's a bit more performant than that. Why it's not much better than just importing it on startup at the top of the file
[20:33] <rick_h> only big things that you might not need (numpy or such?) might be worth cheating and importing at use time
[20:33] <jrwren_> cherrypy
[20:33] <jrwren_> *sigh*
[20:35] <jrwren_> anyone know offhand how cherrypy 2.2.1's dispatcher works? :)
[20:36] <rick_h> magic :)
[20:36] <rick_h> I looked at it long ago :/
[20:36] <jrwren_> ugh
[20:56] <snap-l> I'm not a fan of magic in my code
[20:56] <greg-g> all you judgemental scientists, could use a bit more magic in your lives

[21:01] <jrwren_> its not really magic.
[22:47] <rick_h> heads up, we don't have the room at CHC tonight.  That was what I was a star at.
 I'm working on starting up a microbrewery. To hell with the tech industry. :-)
[23:21] <greg-g> really?
[23:21] <wolfger> fo' realz
[23:22] <wolfger> putting together a business plan, trying to figure out exactly how much cash I need to make a viable go of it
[23:22] <greg-g> nice
[23:22] <greg-g> where abouts?
[23:22] <wolfger> how much beer I need to sell to at least stay afloat
[23:22] <greg-g> all I saw was "beer ... float"
[23:23] <wolfger> I'm looking for near home. There's a dearth of microbreweries in NE Macom and St. Clair counties
[23:23] <wolfger> lol
[23:23] <wolfger> s/Macom/Macomb/
[23:23] <wolfger> at least I still remember simple regex....
[23:24] <wolfger> Once I have a plan and some cash I'll start hunting for a lease place within bicycle distance.
[23:24] <greg-g> good plan
[23:25] <wolfger> It won't be close to my partner's house, but he wants to move anyway :-p
[23:25] <greg-g> sounds like your going to force the issue ;)
[23:26] <wolfger> the tough part will be getting it up and running while keeping the day job, but if I keep my current position I'm pretty solid on 40 hours no weekends, so... I'll just have no life
[23:26] <greg-g> or sleep
[23:26] <greg-g> s/or/and/
[23:26] <greg-g> alright, speaking of, time to head home
[23:26] <greg-g> later
[23:26] <greg-g> good luck wolfger, keep your old pals informed!
[23:26] <wolfger> DragonMead had wonky hours when they started out, and they became very successful, so I know it's *possible*
[23:27] <wolfger> o/ greg-g
[23:28] <wolfger> but yeah, I seem to be on my last project as a guy who actually does stuff (very losely defined). My next project I will be babysitting other people who are (very loosely) doing stuff. It's like they're trying to force managerdom on me
[23:55] <snap-l> wolfger: I believe they called it "Being the team lead"
[23:55] <snap-l> Which was essentially being a project manager without the paygrade
[23:59] <wolfger> bingo


[03:33] <Samda> 안녕하세요
[05:09] <lexlove_> 안녕하세요
[07:38] <foxmask> jason_KR: not so much
[07:38] <foxmask> 안녕하세요
[07:44] <jason_KR> 다행이십니다. 안녕하세요~
[07:48] <foxmask> I found an institute to go to learn korean at school for some hours per week :) i'm waiting for an email from them to know how many hours and how long it will take (weeks/months)
[07:49] <foxmask> in france when you work the companies have to pay to each employee a training. this money is stored in a dedicated account and then we use it as we wat
[07:50] <foxmask> want*
[07:51] <jason_KR> 잘 되기 바래요. ^^
[07:54] <jason_KR> Same as in Korea. "in france when who work the companies have to pay to each employee a training."
[08:10] <foxmask> Good !
[12:14] <soyeomul> Rnqjr
[12:15] <soyeomul> 꾸벅
[12:27] <foxmask> soyeomul: \o
[12:46] <soyeomul> 엇
[12:46] <soyeomul> 폭스마스크님 안녕하세요^^
[12:47] <soyeomul> 아따 눈꺼풀 무거워서 이만 자러갑니다
[12:47] <soyeomul> 모두 존 밤요~~~
[12:47] <soyeomul> 꾸벅