[01:56] <codepython777> has anyone recently bought a laptop here? I'm looking to buy a good ubuntu laptop. Had my eye on dell xps 13 - but that has been discontinued for now.
[04:26] <pitti> Good morning
[07:04] <dholbach> good morning
[07:16] <dholbach> @pilot in
[07:17] <seb128> hey dholbach, enjoy ;-)
[07:17] <dholbach> thanks
[07:29] <Noskcaj> dholbach, 3.8.3 is the newest non-bluez5 version
[07:29] <dholbach> ah ok
[07:29] <Noskcaj> It just brings in a few bug fixes, but it would be nice to have
[07:29] <dholbach> right
[07:29] <Noskcaj> We're discussing bluez5 in -desktop now, it will happen later this cycle if we can get the manpower finally
[09:04] <dholbach> Noskcaj, do you have a link to the source package of 3.8.0-2?
[09:05] <Noskcaj> I thought i got the merge up to 3.8.3-1
[09:05] <Noskcaj> https://download.gnome.org/sources/gnome-user-share/3.8/gnome-user-share-3.8.3.tar.xz
[09:05] <Noskcaj> https://download.gnome.org/sources/gnome-user-share/3.8/gnome-user-share-3.8.0.tar.xz if not
[09:05] <dholbach> the source package
[09:05] <dholbach> like the .dsc file and everything
[09:06] <Noskcaj> oh, no. I just got it from the pkg-gnome tags
[09:06] <dholbach> mh
[09:07] <dholbach> nevermind... http://snapshot.debian.org/package/gnome-user-share/3.8.0-2/
[09:35] <doko> seb128, I saw you didn't forward libproxy to debian. are there other uploads which are not yet forwarded?
[09:37] <seb128> doko, yes, I didn't manage to go through all the diffs on thursday and I was on friday, I'm going to do the remaining ones after lunch
[09:45] <doko> thanks
[09:55] <hron85> Hi, anyone can help me with working with quilt? I made an upgrade for a package and now I have a non-applying patch. However, I cannot refresh it, since it does not apply and quilt do not want to move to this patch until it does not apply
[09:55] <hron85> quilt refresh <patchname> does not work
[09:57] <pitti> Laney: in case you had some config or other files: I just redeployed the entire autopkgtest cloud stuff from scratch
[09:58] <Laney> pitti: nope, maybe stuff in shell history that'll be gone though. :P
[09:58] <pitti> Laney: I did some work this morning to add basenode/ksplice/landscape/two nova configs, and wanted to re-test the whole thing before we switch to production
[09:59] <Laney> what is basenode?
[09:59]  * Laney can't quite google it up
[10:02] <cjwatson> hron85: quilt push -f, resolve conflicts (it should tell you about where they are, and IIRC there'll be the usual patch-conflict <<< [10:03] <cjwatson> hron85: assuming that your starting point is a consistent tree whose quilt state is at the patch immediately below the non-applying one
[10:14] <hron85> cjwatson: yep, it solved my problem, thanks
[10:15] <hron85> cjwatson: yes, I knew the not-applying patch will be the next, but i did not found any way to move to it, since quilt refresh <patchname> rejects to work if the mentioned patch is not applied yet.
[10:34] <jhenke> does anybody know if someone is working on the proposed gnupg 2.1.x as default? I did not see anything since the original message and I wondering if I missed some message
[10:38] <ricotz> StevenK, hi, a gcc5 rebuild of aptitude please :)
[10:39] <ricotz> ah sorry, slangasek ^
[10:41] <cjwatson> hron85: right, in general I think it's best to avoid quilt refresh's mode where it takes a patch name - it's conceptually very confusing
[10:50] <Laney> seb128: doko: do you want help with rebuilds/uploads? if so, where?
[10:51] <doko> ricotz, current ftbfs
[10:51] <doko> Laney, see slangasek's message on -release
[10:52] <Laney> hmm, I don't have one
[10:52] <Laney> nor on the archive
[10:52] <Laney> link?
[10:58] <doko> Laney, #ubuntu-release
[11:00] <Laney> still unclear
[11:00] <Laney> I see the individual transitions - should I take one and work on it?
[11:00] <Laney> + checking your build logs for ABI changes
[11:09] <ricotz> doko, oh, I see
[13:01] <alkisg> mitya57: hi, I'm trying to look into the gnome-flashback keyboard layout applet issue, is the problem there that the existing applet doesn't respond to layout changes reported by xorg?
[13:39] <dholbach> @pilot out
[13:50] <doko> seb128, Laney: just updated to wily. the handles for the terminals don't exist. is this expected?
[13:50] <doko> also when trying to update to wily-proposed:
[13:50] <doko> The following packages will be REMOVED:
[13:50] <doko>   aptitude compiz compiz-gnome compizconfig-settings-manager libasprintf0c2 libcompizconfig0 libdouble-conversion1 libllvm3.6 libmirclient8 libprotobuf9 libproxy1 libtag1-vanilla libxapian22
[13:50] <doko>   mumble python-compizconfig python-xapian signon-ui signon-ui-x11 software-center tasksel tasksel-data ubuntu-desktop unity unity-control-center-signon unity-tweak-tool
[13:50] <doko>   webaccounts-extension-common xul-ext-webaccounts
[13:53] <seb128> doko, the scrollbar issue is known I think, Laney has the details
[13:54] <seb128> doko, compiz/unity rebuild/fixes for gcc5 are in silo43 it seems, check with bregma when he plans to land it I guess
[13:55] <seb128> dunno about aptitude mumble etc
[13:55] <doko> bregma, ^^^ ???
[13:56] <bregma> doko, there's an issue with one of the branches landing that still needs to be retested, then I'm landing that silo as soon as I can
[13:57] <doko> ta
[13:57] <bregma> it's been a game of whack-a-mole getting everything to build
[14:00] <doko> bregma, are there any other silos needed?
[14:01] <bregma> doko, that silo installs OK as long as -proposed is enabled, so not for the Unity stack as far as I know
[14:09] <pitti> Laney: FYI: https://code.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud (moved from ~pitti)
[14:12] <doko> jamespage, zul, roaksoax, smoser: there doesn't seem to be any progress on the ruby dep-waits ...
[14:13] <pitti> apw: not sure if you actually still need this, but http://autopkgtest.ubuntu.com/data/packages/wily/amd64/l/linux/latest.json (and all other JSONs) have URLs to the swift artifacts nwo
[14:14] <apw> that looks useful, even if i don't use it, though i suspect i will
[14:15] <cjwatson> doko: which ruby dep-waits are those, the ones on gem2deb?
[14:16] <cjwatson> doko: because if so (and they quite probably involve gem2deb somewhere), don't hassle the server team about it, needs the next launchpad-buildd rollout because gem2deb started making use of build profiles
[14:16] <doko> cjwatson, ruby-hashie, ruby-rspec, ruby-safe-yaml, ruby-test-unit
[14:16] <doko> ahh, ok
[14:17] <cjwatson> doko: there might be some MIRs buried in there too
[14:17] <doko> dpkg-gencontrol: warning: can't parse dependency libxapian22 (>= 1.2.21)v5
[14:17] <doko> hrm,
[14:17] <cjwatson> ah, no, just misleadingly wrong dep-waits I think
[14:18] <cjwatson> doko: certainly at least ruby-hashie and ruby-rspec will be ultimately fixed by new buildd, haven't checked them all
[14:18] <cjwatson> hopefully I'll get a review of https://code.launchpad.net/~cjwatson/launchpad-buildd/snapcraft/+merge/266541 soon and then I can start the release process
[14:18] <doko> ok, good to know ... still we should address the dep-waits too
[14:19] <cjwatson> doko: what kind of addressing are you talking about?
[14:20] <doko> writing MIR's, dropping b-d's etc
[14:20] <cjwatson> doko: well, some of the dep-waits you see are bogus
[14:20] <cjwatson> so it's probably not worth chasing any of that down until the buildds are fixed
[14:21] <doko> sure, but I doubt that the perl team uses these too
[14:21] <cjwatson> doko: ruby-test-unit -> ruby-power-assert looks like a real MIR case
[14:21] <cjwatson> doko: perl example?
[14:22] <doko> see http://qa.ubuntuwire.com/ftbfs/
[14:25] <cjwatson> ok, sure, there's probably a bunch of MIR handling to be done there
[14:59] <Laney> doko: handles? we changed the scrollbars and there's a problem with the terminal's widget but the thumb is gone if that's what you mean
[15:00] <Laney> you can still scroll it but it's annoying to make it go big
[15:00] <Laney> pitti: ah, cool
[15:01] <Laney> pitti: do you plan to document the architecture? :)
[15:01] <pitti> Laney: yes, of course
[15:04] <doko> Laney, indeed very ugly
[15:05] <Laney> pitti: great - I'm currently still a bit sketchy and would be scared if I had to (e.g.) redeploy it :P
[15:05] <Laney> doko: we will try to tweak more before release
[15:06] <pitti> Laney: heh, sure; indeed there is one remaining bug for complete re-deployment
[15:08] <pitti> (bug 1480962)
[15:08] <pitti> Laney: once that's fixed, it will become really simple; I'll write documentation of all of that once it's all in place
[15:08] <Laney> yay
[15:43] <pitti> tseliot: hmm, seems something broke the fglrx driver? http://autopkgtest.ubuntu.com/packages/u/ubuntu-drivers-common/wily/amd64/
[15:46] <tseliot> pitti: having an actual build log would help. I'll try it here, thanks
[15:46] <pitti> tseliot: yeah, we should fix those tests to cat the build log on failure
[15:46] <tseliot> pitti: that would be nice
[15:50] <smoser> bdmurray, i gues you're not awake...
[15:50] <smoser> https://code.launchpad.net/~smoser/ubuntu-reports/trunk.fix-server-merges/+merge/266745
[15:51] <bdmurray> smoser: I am actually and in a meeting. I'll have a look shortly.
[15:52]  * pitti waves good night
[15:52] <smoser> bdmurray, ok. thanks. and then kick the report generation if you could.
[15:53] <tseliot> pitti: the module built but I see two architectures in my chroot: dkms status
[15:53] <tseliot> fglrx-core, 15.200.1, 4.1.0-3-generic, amd64: installed
[15:53] <tseliot> fglrx-core, 15.200.1, 4.1.0-3-generic, x86_64: installed
[15:59] <pitti> tseliot: did you enable -proposed?
[15:59] <tseliot> pitti: not really
[16:00] <tseliot> pitti: this is all I have http://paste.ubuntu.com/11993942/
[16:00] <pitti> tseliot: i. e. it's plausible that it fails due to gcc 5; /me tries in a chroot with -proposed
[16:01] <tseliot> pitti: gcc -v reports "gcc version 4.9.2 (Ubuntu 4.9.2-17ubuntu1)"
[16:01] <pitti> tseliot: right, and in -proposed we switched to 5.
[16:02] <tseliot> pitti: right, but I don't have -proposed enabled
[16:02] <tseliot> so it must be something else
[16:03] <tseliot> or maybe the failure is a separate issue and/or a false positive
[16:05] <pitti> (wily-amd64)root@donald:/home/martin# modprobe fglrx
[16:05] <pitti> modprobe: ERROR: could not insert 'fglrx': Unknown symbol in module, or unknown parameter (see dmesg)
[16:05] <pitti> [  404.772855] fglrx: Unknown symbol amd_iommu_bind_pasid (err 0)
[16:05] <pitti> [  404.772925] fglrx: Unknown symbol amd_iommu_set_invalid_ppr_cb (err 0)
[16:05] <pitti> [  404.773082] fglrx: Unknown symbol amd_iommu_set_invalidate_ctx_cb (err 0)
[16:05] <pitti> [  404.773170] fglrx: Unknown symbol amd_iommu_unbind_pasid (err 0)
[16:05] <pitti> [  404.773265] fglrx: Unknown symbol amd_iommu_init_device (err 0)
[16:05] <pitti> [  404.773372] fglrx: Unknown symbol amd_iommu_free_device (err 0)
[16:05] <pitti> tseliot: ^ I get that with -proposed
[16:06] <tseliot> pitti: ok, so it's not a build error. It looks like fun. I'll fix it, thanks
[16:06] <pitti> tseliot: hm, I get the same without -proposed
[16:07] <pitti> it started failing on Aug 1
[16:08] <tseliot> maybe the ABI broke somehow?
[16:08] <pitti> tseliot: hm, maybe this is normal in a chroot; that's not what the test fails on
[16:08] <pitti> so this needs a closer look
[16:08] <mitya57> slangasek, ScottK is right — only the plugin(s?) are built against default python3, everything else is built against all supported versions
[16:08] <mitya57> (sorry for the delay btw)
[16:08] <tseliot> pitti: yes, I'll test it on a real system
[16:08] <pitti> tseliot: cheers
[16:12] <mitya57> alkisg, hi, if by "existing applet" you mean indicator-keyboard, then it doesn't support xkb switching. It listens to gsettings changes on org.gnome.input-sources (that are done by g-s-d or u-s-d).
[16:13] <mitya57> And that should work fine in Ubuntu (unlike Debian or upstream).
[16:13] <alkisg> mitya57: it works here in 14.04, but not in 15.10
[16:14] <alkisg> I can use indicator-keyboard with the mouse to change the language, but I can't use any keyboard shortcut to change it
[16:14] <alkisg> Even though gsettings are the same as in 14.04 when it worked
[16:16] <alkisg> mitya57: so the plan is for someone to write such an applet, and then use it in all variants, upstream, debian and ubuntu?
[16:16] <alkisg> Or ubuntu will keep using indicator-keyboard?
[16:18] <mitya57> alkisg, it's in our "patches welcome" list upstream :)
[16:18] <mitya57> let me look at the code a bit
[16:19] <alkisg> If you accept one that listens for *xkb* changes as well, instead of only for gsettings changes, it would be interesting... :)
[16:25] <mitya57> alkisg, why do you still need xkb changes? GNOME upstream deprecated that and gsettings is much easier to use.
[16:25] <mitya57> alkisg, also, do you have gnome-settings-daemon or unity-settings-daemon running?
[16:25] <alkisg> mitya57: unity-settings
[16:26] <mitya57> that should work fine…
[16:26] <alkisg> It doesn't... clean 15.10 installation
[16:26] <alkisg> That was basically what I was worried about, I thought that it would be broken in ubuntu 15.10+, 16.04 etc like it is upstream...
[16:26] <mitya57> Are you using modifiers-only keybinding or not?
[16:27] <alkisg> The defaults, win+space
[16:27] <alkisg> I also tried alt+shift which worked in 14.04, it doesn't work either
[16:27] <mitya57> Does it list in gsettings get org.gnome.desktop.wm.keybindings switch-input-source?
space
[16:28] <mitya57> Looks fine.
[16:28] <mitya57> Is there a bug open in LP for it, and if no, can you please file one?
[16:29] <alkisg> I'll check + file a bug, thanks,
[16:29] <alkisg> about xkb changes, unfortunately gnome upstream breaks sdl apps, and we're trying to make things work as they were with xorg without gnome breaking them...
[16:30] <mitya57> Can you also attach "gsettings list-recursively org.gnome.desktop.input-sources" to the bug, please?
[16:30] <alkisg> E.g. in tuxpaint, tuxtype, we cannot type greek at all now with recent gnome versions, the last one to work fine for us was 12.04
[16:30] <alkisg> mitya57: another issue that might need resolving,
[16:31] <alkisg> I install ubuntu with greek layout in ubiquity etc. Then I create a user, and /home/user is empty
[16:31] <andol> There is something off with the http://releases.ubuntu.com/vivid/ FOOSUMS files, and their corresponding FOOSUMS.gpg - http://paste.ubuntu.com/11994117/. In addition to gpg reporting BAD signatures there is also the oddness that the FOOSUMS files appear to have newer mtimes than their corresponding FOOFUMS.gpg.
[16:31] <alkisg> If that user logs in, he has nothing in the layouts list, while it should be "us,gr"
[16:31] <andol> (No idea where the proper place to report such an issue is)
[16:31] <alkisg> So all users need to go to keyboard settings and add the layouts manually
[16:32] <alkisg> I think this happens in all ubuntu gnome variants, while it doesn't happen in e.g. fedora... or of course in ubuntu <= 12.04
[16:32] <mitya57> alkisg, please report that against the installer (i.e. if you use the graphic one, then it's ubiquity)
[16:33] <alkisg> mitya57: I think the problem is that gnome doesn't respect the global xorg settings anymore
[16:33] <alkisg> It's not about ubiquity... e.g. when one run `adduser x` after the installation, that "x" user doesn't get the xorg system default layout
[16:33] <alkisg> *runs
[16:33] <mitya57> alkisg, are you installing Ubuntu GNOME?
[16:33] <alkisg> No, plain ubuntu and then gnome-flashback
[16:34] <alkisg> It's been that way since 14.04. It was working in 12.04
[16:34] <alkisg> I've been filling a lot of bug reports about these issues, but they didn't draw much attention...
[16:35] <mitya57> This is first time I hear about this issue.
[16:35] <mitya57> :)
[16:35] <alkisg> :)
[16:35] <mitya57> It looks like it's not specific to GNOME Flashback, so try sending a mail to<EMAIL_ADDRESS>[16:35] <mitya57> There are people who should know what component to blame
[16:36] <alkisg> The long story is that ubiquity, lightdm, accountsservice, gnome-settings-daemon, unity-settings-daemon, and a couple of other applications don't work with multiple keyboard layouts since 13.04 or so
[16:37] <alkisg> Let me try the indicator with unity...
[16:38] <alkisg> mitya57: I think that the "indicator doesn't change on layout changes by keyboard shortcuts" is specific to flashback, in unity it's working fine
[16:38] <alkisg> And it broke after 14.04
[16:39] <alkisg> The 10+ rest issues about layouts are not specific to flashback, but they are specific to ubuntu though... :-/
[16:40]  * alkisg checks + files a bug for that one...
[16:40] <mitya57> alkisg, does the gsettings key (i.e. org.gnome.desktop.input-sources current) change when you toggle the keybinding?
[16:41] <alkisg> unity => yes, moment for flashback...
[16:41] <alkisg> metacity => no, moment for compiz...
[16:42] <infinity> pitti: Did I ever get those trusty langpacks?
[16:44] <alkisg> mitya57: gnome-flashback (compiz) gives me unity without the top panel... go figure :)
[16:44] <mitya57> alkisg, metacity is enough, that indicates that the problem is not in the indicator, but in unity-settings-daemon
[16:44] <mitya57> the fix for compiz will be in next compiz upload :)
[16:45] <alkisg> mitya57: hope you don't mind me asking, are you using the flashback+metacity session yourself in production?
[16:46] <alkisg> We're using gnome-flashback in 1000+ schools here, but I was wondering if mate would be more appropriate, considering the old hardware...
[16:46] <alkisg> gnome-flashback feels like the best choice, considering it's closer to upstream gnome, but it also feels understaffed... :)
[16:50] <mitya57> Yes, we are quite lacking resources
[16:50] <mitya57> Actually I do just packaging (don't have time for anything else), all upstream work is done by 1.5 people :)
[16:52] <alkisg> Yes fortunately Alberts is doing the bulk of the work... but mitya57, are you using it in production somewhere? Or is it just your preferred DE?
[16:53] <mitya57> Many my friends use it :)
[16:53] <alkisg> Nice :)
[16:53] <mitya57> Also I set it up in a school some time ago, not sure if they are still using it
[16:53]  * mitya57 keeps accidentally pressing Ctrl+Q
[16:54]  * alkisg wonders where "ibus" fits in all this... it's preinstalled, and previously it was not running by default, and now it is...
[16:55]  * mitya57 doesn't know anything about ibus
[17:00] <alkisg> mitya57: should I file the bug against indicator-keyboard (Ubuntu), or against unity-settings-daemon?
[17:00] <alkisg> I.e. that it works in unity but not in flashback
[17:05] <mitya57> alkisg, unity-settings-daemon, and also add https://launchpad.net/ubuntu-gnome-flashback as a subtask
[17:05] <alkisg> Thanks, trying...
[17:08] <doko> why is xapian-bindings ftbfs on the buildds ...
[17:14] <doko> bregma, so even with your landing PPA enabled, I can't upgrade
[17:20] <alkisg> mitya57: I've filed LP #1481025
[17:27] <Mirv> cyphermox: thanks for the new wpa! fwiw it does not seem there is stated delta anymore to Debian's debian/config/wpasupplicant/linux, other than the fact that Ubuntu has the settings specified twice + there is unmentioned Android config delta
[17:35] <cyphermox> Mirv: are you saying I forgot to re-add the android crap in changelog?
[17:36] <cyphermox> looks to me like it's there
[17:36] <mitya57> alkisg: thanks
[17:38] <alkisg> Tthank _you_ :)
[17:46] <doko> Noskcaj, qqwing accepted in -proposed
[17:47] <hjd> cyphermox: Thanks for packaging. :) I suppose it's too late to mention it in the changelog, but would you mind leaving a comment on bug 1370245?
[18:01] <Mirv> cyphermox: the section stating remaining changes in debian/config/wpasupplicant/linux from Debian mentions the two options that are double stated in that file but does not mention the CONFIG_ANDROID_HAL=y which is the only actual delta in that config
[18:02] <cyphermox>   - debian/config/wpasupplicant/linux: enable CONFIG_ANDROID_HAL.
[18:03] <Mirv> cyphermox: I mean, oh, right, it's up there. then the later mention is just unneeded + the config file should be cleaned since the delta is actually now this http://paste.ubuntu.com/11994721/
[18:03] <cyphermox> nah
[18:03] <cyphermox> *bah
[18:04] <Mirv> so CONFIG_P2P and CONFIG_AP are repeated in Ubuntu's version
[18:06] <cyphermox> Mirv: how about that. Feel free to clean it up if you want to
[19:05] <hjd> jjohansen: Hi :)
[19:06] <jjohansen> hjd: hello
[19:06] <hjd> jjohansen: Sorry for the random ping, but I saw bug 1481039 and wondered whether the linux-lts-backport-maverick and -natty tasks are included for completeness, since they don't seem to be part of any current Ubuntu release.
[19:07] <jjohansen> hjd: its actually because I need to do some updates to the tooling we use so we can drop those
[19:11] <hjd> ok :)
[19:44] <doko_> desktop updated to wily-proposed + landing-043. seems to work again \o/
[19:46] <infinity> doko_: Impressive.
[19:47] <Laney> oh, they fixed the arm64 FTBFS of $package
[19:47] <Laney> SHIP IT.
[19:48] <doko_> apt-get dist-upgrade removes gnome-control-center, but you can install it again. only thing missing is aptitude
[19:51] <Noskcaj> Logan, Would you mind checking the sponsors queue for stuff before you merge? I had a finished merge for light-locker waiting, so there was a bit of an overlap of work. That said, i should have asked you if i could merge it
[19:52] <Laney> doko_: If you can get an easily understandable list of work to be done then I can help out tomorrow
[19:52] <Laney> like 'rename these packages' or 'rebuild/fix for these transitions'
[19:54] <doko_> I'm trying, need to prepare for travel tomorrow as well
[19:54] <doko_> I mean, you could starting to rebuild stuff for icu and boost in main
[19:55] <Laney> I also don't want to clash/duplicate
[19:55] <Laney> so some pad/wiki would be nice
[19:55] <doko_> Laney, coordinate with slangasek; I think I won't do much tomorrow
[20:28] <ari-tczew> cjwatson: shouldn't the fakesyncs be synced automatically?
[20:33] <ari-tczew> cjwatson: nvm, due to mismatch tarballs isn't possible, but I think fakesyncs should be on MoM visible...
[20:33] <ari-tczew> correct me if I'm wrong
[21:45] <doko_> cyphermox, you still involved with libcolumbus?  could you have a look at the ftbfs?
[21:55] <doko> Noskcaj, pyicu 1.8 ftbfs with ICU 55. updated to 1.9.2
[22:09] <Noskcaj> doko, I'll update it in debian python svn today
[22:10] <doko> ta
[22:25] <infinity> robert_ancell: Hey, do you know of anyone (perhaps you?) who could verify the SRU for https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1410801 ?
[22:29] <robert_ancell> infinity, I don't have any AMD hardware, sorry
[23:39] <mwhudson> go 1.5 prep feels like http://media.giphy.com/media/MRUj8R8SMWlIk/giphy.gif today
[23:57] <infinity> mwhudson: You keep getting attacked by a vicious cat?
[23:57] <mwhudson> not entirely what i was trying to convey, no


[00:02] <AmEv> Hi
[00:07] <AmEv> Anyone here able to troubleshoot Tegra 2 non-booting problems?
[00:16] <AmEv> Anyway, the tablet I'm trying to install Ubuntu onto is the Toshiba thrive. Biggest possible issue I see? The version of Tegra 2 it is.
[00:18] <AmEv> Is it a Harmony Tegra 2? Nope. Ventana? Nope. It's in its own ball park: the Antares.
[00:18] <RaYmAn> it's irrelevant. It's ventana based, but it doesn't really matter. THe drivers work on any tegra2 as long as it has the right kernel
[00:19] <AmEv> Hmm...
[00:20] <AmEv> Anyway, I'm hitting two things that are happening: Either it stays at the bootup logo, or the screen goes black, and the backlight goes off.
[00:21] <AmEv> I do get some garbled display on HDMI, either way.
[00:21] <AmEv> So, are there some essentials I need to have configured, besides VT and framebuffer console?
[00:22] <RaYmAn> what kernel are you using?
[00:25] <AmEv> I'm trying to build my own, as nobody has released one for the Thrive. However, what I'm starting to use is at this git: https://github.com/pio-masaki/at100-kernel
[00:25] <AmEv> *released a GNU kernel, that is.
[00:28] <infinity> I do wonder if our ac100 kernels might Just Work on it.
[00:28] <AmEv> Compile for Ventana instead of Harmony?
[00:29] <AmEv> Both are Toshiba. That's good news.
[00:30] <infinity> I've never seen a Thrive in person to play with it, but I'd always had a sneaking suspicion that (with the exception of a few peripherals) it's identical to the ac100.  But, who knows.
[00:31] <AmEv> Heh. One of the Thrive devs would love to have an AC100. Can't afford it, though.
[00:31] <infinity> If I were the Toshiba engineers, the ac100 would have just been my devel version of the at100 (cause keyboards are handy for debugging).
[00:31] <AmEv> Downloading AC100 kernel source.
[00:32] <infinity> You could just grab the debs and try the binaries for a quick "hey, maybe this works" smoketest.
[00:32] <AmEv> I've prepared a rootfs on an external SD card already.
[00:33] <AmEv> It's actually a Plasma Active rootfs, but with my touch screen dying (cracked)... At least we have LXDE.
[00:34] <AmEv> Yeah... As nice as a VNC for Android solution is, it's extremely laggy, to the point of almost unusability.
[00:34] <infinity> I've been seriously considering dropping Tegra2 support from future Ubuntu versions.  If people are still actively developing on them, I may need to bring this to a community vote/discussion.
[00:36] <AmEv> Heh. The reason I chose the Thrive about a year ago was because it seemed to be a perfect candidate for Ubuntu.
[00:36] <infinity> Yeah.  And we've had a policy of no-neon-by-default specifically because of the Tegra2 (the only SoC we support that doesn't have NEON).
[00:37] <infinity> It's irksome to keep patching upstream sources for this assumption, but if the target is still widely developed on/with, we may have to stick with it for a bit.
[00:38] <AmEv> Seems that performance development is slowly shifting away from x86 and going to ARM...
[00:39] <infinity> About time.  ARM could use more performance-oriented tweakers.
[00:40] <AmEv> I do like ARM because of its power-performance ratio.
[00:41] <infinity> Yup, and that ratio can only improve as more people start hand-tuning code the same way they've done for x86, rather than falling back to generic C implementations.
[00:41] <infinity> (But NEON is a big part of that story... hand-tuned NEON can be blazingly fast but, sadly, leaves Tegra2 out to dry)
[00:42] <AmEv> I'm no CPU design expert, but it seems that x86 is starting to hit a performance ceiling.
[00:42] <infinity> Well, not all that sad.  Just annoying that ARM allowed NEON to be optional so NVIDIA could make that silly decision.
[00:42] <claes> is this the right place to ask about what rooting option to choose from the google nexus 7 toolkit, to then install multrom and dualboot android and ubuntu?. if so wich rooting option should i choose, its a bit confusing.
[00:43] <infinity> claes: https://wiki.ubuntu.com/Nexus7/Installation has clear unlocking instructions.
[00:44] <infinity> claes: We don't support installing in a dual-boot setup, though, you're on your own for figuring that one out.
[00:44] <claes> ok thanks
[00:48] <AmEv> Well, porting Ubuntu Phone to a spare phone I've got should be fun...
[00:58] <xnox> AmEv: can it run android stock kernel? that would be first step.
[00:59] <AmEv> It's actually a WebOS phone.
[00:59] <AmEv> Meets bare-minimum requirements, with OC...
[01:00] <AmEv> As for the Thrive, should I use the Google cross-compiler toolchain?
[01:02] <AmEv> Got a Ventana Android defconfig...
[01:02] <AmEv> And a Harmony GNU config..
[01:04] <AmEv> Really? No Ventana GNU config on Google?
[01:05] <AmEv> Or is it under another name?
[01:14] <AmEv> Hmmm.. The one guy ported CM10 to the Thrive. Said that the Thrive was almost identical to the Iconia a500....
[01:15] <AmEv> And it's a Harmony board....
[01:17] <lilstevie> AmEv: the Iconia a500 is a picaso board not a harmony board
[01:18] <lilstevie> AmEv: Harmony is the name of one of the dev boards made by nvidia
[01:18] <lilstevie> AmEv: but if you were to compare the device to a dev board it would be closer to ventana
[01:19] <AmEv> Hmmm...
[01:20] <lilstevie> the a500 and the tf101 are almost identical, and the tf201 is almost identical in hardware and config to ventana (except the display)
[01:20] <lilstevie> er
[01:20] <lilstevie> s/tf201/tf101/
[01:20] <lilstevie> been doing too much work on the later one :p
[01:21] <AmEv> I know people have been runing Ubuntu on their Transformers for a while...
[01:21] <AmEv> Lemme see if I can snag the dev in here....
[01:21] <AmEv> Nope.
[01:21]  * lilstevie raises his hand
[01:22] <lilstevie> http://forum.xda-developers.com/showthread.php?t=1191141
[01:22] <AmEv> Heh.
[01:28] <AmEv> Yeah, I thought your name looked familiar from one of my earlier attempts.
[01:35] <AmEv> Hmmm... http://www.nvidia.com/content/devzone/linux-for-tegra.html
[01:44] <AmEv> Found a zImage, but no complimentary initfs...
[09:42] <netchip> hi
[09:42] <netchip> where can I get the default initrd for ARMHF?
[09:42] <netchip> I mean, the initrd you have to customize for your device
[11:22] <marvin24> netchip: mkinitramfs?
[11:30] <marvin24> the question which plagues me is if it can be used on a forgein arch (e.g. x86_64) to generate an arm version
[11:30] <marvin24> or do I need to use some changeroot and qemu?
[11:32] <netchip> AFAIK you can
[11:32] <netchip> BTW
[11:32] <netchip> marvin24, https://wiki.ubuntu.com/ARM/RootfsFromScratch
[11:39] <marvin24> yes, will try it out
[11:40] <netchip> hum
[11:40] <netchip> how to test if my network connection is OK?
[11:40] <marvin24> I was just wondering if I need to emulate the whole cpu or just use a dir with an arm  filesytem
[11:40] <marvin24> netchip: ping?
[11:41] <netchip> marvin24, isn't installed...
[11:41] <marvin24> ifconfig
[11:41] <marvin24> route ...
[11:42] <netchip> also nopt installed
[11:42] <netchip> how to install without internet connexction?
[11:42] <marvin24> dpkg has a "chroot" option
[11:43] <marvin24> also make sure to fill /etc/resolv.conf
[11:44] <netchip> hmm
[11:45] <netchip> marvin24, do you know how I can get my WiFi on my phone work (a SGS3 running Ubuntu, BCM4334)?
[11:45] <netchip> just installing linux-firmware?
[11:45] <netchip> and then some conf files?
[11:47] <netchip> LMAO
[11:47] <marvin24> best is to configure it on the phone once it is installed
[11:47] <netchip> yeah
[11:47] <netchip> it's checking if it's enabled
[11:47] <netchip> if not
[11:47] <netchip> enable it
[11:47] <netchip> lol
[11:47] <netchip> http://www.plethoracomputers.com/index.php/component/option,com_kunena/Itemid,277/catid,4/func,view/id,59/
[11:47] <netchip> have to bootstrap a new image
[11:55] <marvin24> oh, rootstock is depricated ...
[11:56] <marvin24> fetching some pre-build image and adjust it seems the way to go now
[12:02] <netchip> well
[12:02] <netchip> how do they generate the prebuilt image? ;-)
[13:23] <beer> netchip: stop annoying the poor devs
[13:29] <netchip> beer, you are annoying
[16:25] <marvin24> netchip: some live-build
[16:25] <marvin24> and qemu doesn't work with omap4 (and filesystem image)
[20:44] <zoktar> anyone here who can help me with multirom with kexec im not sure how i install kexec to make it work. It seemed to install correctly from recovory, but loading ubuntu rom says i havnt installed kexec.
[20:45] <zoktar> owh its for the nexus 7
[20:47] <tassadar_> what exactly have you flashed in the recovery?
[20:47] <tassadar_> gimme name of that ZIP file
[20:47] <zoktar> the kexec? its the 4.2 one
[20:47] <zoktar> kernel_kexec_42.zip
[20:48] <tassadar_> okay, go to multirom menu, try to boot ubuntu  (the "you don't have kexec" message must pop out), the go to the "Misc" part and select "Copy log to /sdcard"
[20:49] <tassadar_> reboot to recovery then and "adb pull /data/media/0/multirom/error.txt"
[20:50] <zoktar> alright will that show me the error log?
[20:50] <tassadar_> it will save it to your computer, upload it to pastebin and show it to me :)
[20:50] <zoktar>  ah alright cool
[20:50] <zoktar> thanks
[23:16] <zoktar> tassadar_, seemed i hadnt installed the kernel correctly. working fine now thanks.
[23:17] <tassadar_> okay, great


[03:38] <Dr_Who> urbanape: around ?
[08:20] <mandel> morning all!
[08:21] <mandel> bug 962860
[08:35] <JamesTait> Morning all! :)
[11:15] <gatox> good morning!
[11:16] <mandel> gatox, morning!
[11:41] <mandel> gatox, ralsina, briancurtin, happy thrusday: https://jenkins.errormessaging.com/job/ubuntu-sso-client-windows-test/47/testReport/?
[11:47] <gatox> mandel, nice
[11:48] <mandel> gatox, we are getting there :)
[12:00] <mandel> briancurtin, gatox, ralsina, it looks like the special folders tests are borken on jenkins because it runs with a user that does not have them.. ain't that fun?
[12:01] <gatox> always something new :P
[12:05] <mandel> gatox, well, we have improved in 1119 tests, so I'm happy :)
[12:05] <mandel> gatox, next step, fix or skip those, move to make the .exe for the ubuntuone-windows-installer
[12:06] <gatox> mandel, i'm running the tests for sso in mac.... i'm checking that the number is the same as in linux (because it was too fast)......... also i'm skipping test_is_already_running...... but we have 50 skips, 1 error, 597 success
[12:07] <mandel> gatox, hm.. well, it is promising
[12:08] <mandel> gatox, looks like we have some small broken tests on ubuntuone-client in jenkins due to the same as the ubuntuone-control-panel, we'll have to talk about that
[12:08] <gatox> mandel, about the special folders?
[12:09] <gatox> mandel, also...... that is clearly an user that couldn't use u1....
[12:09] <mandel> gatox, in this case is changing rigths, but is the same issue, u1-client assumes we are admin to change to read only (wrong) which is no usually a problem, but it is when you have a gay username :P
[12:09] <mandel> gatox, and yes, it is a user that would have problems with u1..
[12:10] <mandel> gatox, but results are comming out nice: https://jenkins.errormessaging.com/job/ubuntuone-client-windows-test/33/console
[12:10] <mandel> gatox, I'll make it throw reports for the next build to get a more decent output
[12:11] <gatox> mandel, wow!! that's cool
[12:12] <gatox> mandel, also.... in mac we are ignoring some tests when we run the scripts.... i have confirm that ignoring the same tests in linux, we have the same results (except for the skips)...... so, it seems we are on track
[12:12] <gatox> now....... to fix the backend :P
[12:13] <mandel> gatox, wait, lets think about the parts that we know are broker for sure
[12:13] <mandel> gatox, the IPC is, because tcp activation assumes that we have a port stored in the registry when we have nothing of that, I'm got that part :)
[12:13] <mandel> gatox, then we know we have not network detection, which we fake to have always as true
[12:14] <gatox> aja
[12:14] <mandel> gatox, and we do not have a runtests which is a PITA
[12:14] <mandel> gatox, with those we should be able to have the tests passing.. that it works, is a diff story :)
[12:14] <mandel> gatox, search for u1-darwin in lp
[12:14] <gatox> i've installed some modules in my system..... and it's easy to run tests...... but i did that manually
[12:15] <mandel> gatox, here: https://bugs.launchpad.net/ubuntu-sso-client/+bugs?field.tag=u1-darwin
[12:16] <alecu> gluten tag!
[12:16] <mandel> alecu, hello!
[12:16] <gatox> alecu, buenasssss
[12:16] <mandel> alecu, for you too: https://bugs.launchpad.net/ubuntu-sso-client/+bugs?field.tag=u1-darwin
[12:16] <alecu> mandel, \o/
[12:16] <mandel> alecu, good news are, jenkins is back up for windows, bad news are, some tests fails because the jenkins user has no special folders and no admin rights :)
[12:17] <gatox> mandel, the problem with the backend, probably is or it's related to tcpactivation
[12:17] <mandel> alecu, sso are the best news: https://jenkins.errormessaging.com/job/ubuntu-sso-client-windows-test/47/testReport/?
[12:17]  * alecu loved urbandictionary's definition of "gluten tag"
[12:17] <mandel> alecu, also, I was approach about bug 962860
[12:18] <mandel> alecu, and proposed: https://code.launchpad.net/~mandel/libubuntuone/fat-alert-label/+merge/102671
[12:18] <mandel> alecu, apparently we need to be fast with that or it won't be in the iso
[12:18] <alecu> mandel, "you were approach about bug"? have you grown a Borat moustache too?
[12:18] <mandel> alecu, gluten tag => lol
[12:19] <mandel> alecu, approached, I having a terrible day..
[12:20] <gatox_mac> alecu, also: http://ubuntuone.com/0BqdovN6VAkyVrFzaMqX4s (ignoring some tests as the doc mention)
[12:20] <mandel> alecu, gatox, briancurtin: we should be happy about : https://jenkins.errormessaging.com/job/ubuntuone-client-windows-test/34/testReport/?
[12:21] <alecu> gatox: that's just beyond awesome.
[12:22] <gatox> alecu, i needed to skip test_is_already_running to be able to check the rest.... because it was getting stuck there cause of tcpactivation..... but we are getting some results
[12:22] <mandel> alecu, I think we could get sso by end next week on darwin, that is ignoring packaging and making it a per user service, but we can ask urbanape about how to do that
[12:23] <alecu> mandel, how can I tests that fat-alert-label branch?
[12:23] <alecu> mandel, we surely want it to be a "per user service", right? what is the other option?
[12:24] <gatox> mandel, do you want to have a quick mumble about mac tasks or you are busy with jenkins today?
[12:24] <alecu> gatox, mandel: I'd like to be in the mumble too, if it's ok with you guys.
[12:24] <alecu> gatox: and perhaps we should wait till urbanape wakes up
[12:25] <mandel> gatox, alecu, lets wait for urbanape
[12:25] <gatox> mandel, alecu, fine by me....
[12:25] <mandel> alecu, yes, per user, there is a way, is simple, urbanape should know more
[12:26] <mandel> alecu, fat-alert-label => ./autogen.sh && make
[12:26] <mandel> alecu, then remove the mp3 plugins from your system (ugly, etc..) and run ./tests/test-music-store
[12:27] <mandel> alecu, that will show the aler label, the install button and the store
[12:27] <alecu> mandel, great, I'll test it on a vm.
[12:28] <ralsina> good morning!
[12:28] <alecu> hola jefe!
[12:28] <mandel> alecu, I'm not super busy with jenkins, I just ensured that we are in the right track and will talk with briancurtin to add bugs for those failing tests :)
[12:28] <mandel> ralsina, morning!
[12:29] <ralsina> mandel: just for lunch-planning-pursposes: we moved the meeting 30 minutes earlier because brian has to run some errands
[12:29] <mandel> ralsina, good news, jenkins is back, 100% tests pass for sso, few (less than 10) fail in u1-control-panel and u1-client due to the special user that jenkins uses
[12:29] <ralsina> mandel: cool
[12:29] <mandel> ralsina, I'm going to have lunch now, no problem :)
[12:29] <gatox> ralsina, hi
[12:29] <mandel> ralsina, take a look at the dashboard, tests are not that slow, is just that the jenkins machine did not have qt4reactor installed
[12:30] <mandel> ralsina, that should be fixed once we use the buildout to run the tests, which i think is the best approach
[12:32] <mandel> ralsina, one last thing before I go for lunch, we really need to be fast fixing bug 962860
[12:32] <alecu> mandel, I think we may skip the "test_set_file_readonly" tests when running inside jenkins
[12:32] <mandel> ralsina, I have proposed a branch that does the correct thing (wrap the label) if we are not quick that wont be in the iso
[12:32] <alecu> mandel, I'm reviewing that branch right now.
[12:33] <mandel> alecu, well, that shows an bug in the implementation since it assumes that we are admin, which aint good :)
[12:33] <mandel> alecu, but we can skip them if needed :)
[12:33] <alecu> mandel, we should have a "@skipIfJenkins" decorator for those 10 tests :-)
[12:33] <mandel> alecu, maybe skipIfNotAdmin or something, but yes, is a good plan :)
[12:34] <mandel> ok, I'm off to have lunch, then I'll need to move to fix u1-dev-tools because they do not build on L
[12:34] <alecu> mandel, the thing is that those are "integration" tests more than unit tests.
[12:34] <alecu> mandel, and they require a special setup on the part of the test runner.
[12:34] <mandel> alecu, indeed, is a problem, we can chat with briancurtin to see what is the best thing to do, and which is the fastests :)
[12:35] <mandel> ok, lunch for me
[12:35]  * mandel lunch
[12:35] <alecu> mandel, and since we may not be able to provide that for the test environ inside jenkins, I think we should skip them instead of forcing jenkins to replicate the setup we need.
[12:35] <alecu> mandel, bye
[12:35] <mandel> alecu, I agree, and I'm not here as of now (I eat fast)
[13:00] <cento> hi to all
[13:00] <cento> how to sync thunderbird contacts and ubuntuone, on 12.04 (new UbuntuOne client don't have old options)
[13:00] <cento> ?
[13:00] <cento> old ubuntuone client allow it
[13:00] <cento> but in 12.04?
[13:34] <mandel> cento, the couchdb package was discontinued.. I don't know we support that anymore until u1-db is done, rye_ can you confirm this?
[13:37] <rye_> joshuahoover: ^ ?
[13:37] <beuno> right
[13:37] <beuno> we don't support it anymore
[13:42] <dobey> ugh, got connection drop apparently
[13:43] <dobey> can have review on https://code.launchpad.net/~dobey/ubuntuone-dev-tools/fix-bat-3-0/+merge/102595
[13:44] <dobey> well, desktopcouch sync still generally works, though we have announced that we will be closing it at some point, and we are producing a better alternative for our use case called u1db
[13:45] <mandel> dobey, on it
[13:45] <mandel> dobey, I think that can be approved with a single review, right?
[13:46] <dobey> yes
[13:48] <mandel> dobey, sorted
[13:50] <urbanape> morning, all
[13:52] <ralsina> alecu: quick 1-1? I can call you on the phone
[13:53] <urbanape> hey, Dr_Who. I'm around now
[13:54] <alecu> ralsina, sure
[13:54] <Dr_Who> hey ya urbanape
[13:55] <Dr_Who> nothing pressing was debugging away last night and wanted to ask you about something or other… no worries
[13:57] <Dr_Who> urbanape: had you had a chance to look at the various patches and such I'd have for the files app ?
[13:57] <Dr_Who> s/have/had posted/
[13:57] <gatox> urbanape, hi
[13:57] <urbanape> Dr_Who: I haven't. Have you proposed any branches?
[13:57] <urbanape> gatox: howdy
[13:58] <gatox> urbanape, i'm running the tests without problems now.... i need to change a couple of things, because dev-tools wasn't up to date and some problems with the ptyhonpath in my case..... but everything working :D
[13:58] <Dr_Who> I'd attached them to the bugs proper.  For some reason launch pad will only allow me to push bar branches for the files and music app if I keep them under +junk
[14:00] <Dr_Who> granted what i have pushed up in bazaar was pushed with --fixes lp:xxxxxx which should still be picked up
[14:00] <Dr_Who> regardless if it's most helpful to you to go via the propose process, I'll sure follow it
[14:00] <urbanape> awesome, I'll take a look at the branches, thanks.
[14:01] <dobey> Dr_Who: how are you pushing a branch such that bzr won't let you create them outside +junk?
[14:04] <Dr_Who> dobey: could have been some sort of lp hiccup but the error message was something to the effect of ubuntuone-ios-music is a private project and I wasn't allowed to push something to the tune of bzr push lp:~tom-gall/ubuntuone-ios-music/ubuntuone-ios-music
[14:04] <Dr_Who> change to +junk and things were fine
[14:05] <facundobatista> dobey, alecu, ralsina: how is the proper "./autogen.sh" call in ubuntuone-client in Precise?
[14:05] <alecu> facundobatista, for me it is: "gnome-autogen.sh && make"
[14:05] <facundobatista> alecu, you don't use the ./autogen.sh of the project?
[14:06] <gatox> mandel, alecu, hey..... urbanape is already here..... so we can have a quick mumble whenever you want
[14:06] <dobey> facundobatista: just ./autogen.sh
[14:06] <urbanape> yup, I'm available.
[14:07] <mandel> gatox, I think ralsina is chattin with alecu, we can do it when they are done
[14:07] <facundobatista> dobey, gracias, I was missing a sudo apt-get build-dep ubuntuone-client (trying now...)
[14:07] <gatox> ok
[14:08] <dobey> facundobatista: ah yes. you'll want the deb-src url for the nightlies ppa in your sources lists, to get the proper build deps
[14:08] <ralsina> mandel: I finihed with alecu, do what when we are done doing what?
[14:08] <alecu> ralsina, we're about to have a mumble re the mac tasks
[14:09] <mandel> ralsina, just a sync mumble about mac since gatox is helping too
[14:09] <ralsina> alecu: remember you have 20 minutes
[14:09] <alecu> ralsina, you are welcome to join
[14:09] <ralsina> let's do it, I will listen in
[14:09]  * alecu goes to fetch the mumbling laptop
[14:09] <mandel> dobey, the two was proposed by design, we can remove it :)
[14:12] <mandel> ralsina, cotilla!
[14:12] <ralsina> mandel: MANAGER! ;-)
[14:12] <mandel> ralsina, suuure..
[14:14] <ralsina> I am not leading that call, so start talking people ;-)
[14:14] <mandel> ralsina, we need alecu :)
[14:14] <alecu> mandel, coming!
[14:15] <mandel> alecu, you are leading :)
[14:15] <briancurtin> ralsina: i'm now being told i have to leave at 9:45, so 15 minutes into the meeting :/ can i request to do my part of the call first? (sorry for having this change yet again)
[14:15] <ralsina> briancurtin: sure
[14:16] <mandel> briancurtin, while I'm chatting about mac stuff, can you take a look at jenkins, there are some errors related to the fact that the user used by jenkins is funny :)
[14:16] <dobey> we can do the call now
[14:16] <briancurtin> mandel: yeah i saw that, i'll see if i can find why
[14:16] <dobey> if everyone is around
[14:16] <ralsina> dobey: we are on another call first, the weekly call will be short anyway
[14:17] <ralsina> dobey: below 30' for sure
[14:17] <dobey> i wasn't suggesting it for my sake :)
[14:19] <Dr_Who> mandel: working on a mac client by chance ?
[14:19] <mandel> Dr_Who, yep
[14:19] <Dr_Who> very cool
[14:32] <briancurtin> thisfred: mumble meeting?
[14:32] <thisfred> ah si
[14:36] <dobey> ralsina: can you turn down the gain or move the mic a little further away or something?
[14:40] <dobey> ralsina: you dropped off
[14:41] <ralsina> Lost power :-/
[14:45] <mandel> alecu, bug #985576
[14:47] <mandel> alecu, it should be a simple one to fix, yet, I wonder in how many places we do that, probably 2, web client and the tunner
[14:47] <mandel> *tunnel
[15:16] <thisfred> ralsina: so for UI for the demo app, should I look at pyside + QML (Note: It's going to be example code, not a real application, so what I'm looking for in the UI is to get out of the way and contribute the least amount of logic possible to the whole application, so the developer does not get distracted by things that have nothing to do with u1db)
[15:16] <thisfred> ?
[15:16] <ralsina> thisfred: then no :-)
[15:16] <thisfred> QWebkit?
[15:17] <thisfred> pyqt?
[15:17] <ralsina> thisfred: QML is funny, addictive, but I have never heard ayone describe it as "out of the way" :-)
[15:17] <ralsina> thisfred: yes, PyQt
[15:18] <thisfred> ralsina: this didn't look to bad, and close to what I want to do, http://qt-project.org/wiki/Multi-selection_lists_in_Python_with_QML but pyQT is fine wit
[15:18] <thisfred> h me also
[15:18] <ralsina> thisfred: looking...
[15:19] <ralsina> thisfred: actually, you are right
[15:19] <ralsina> thisfred: but please, PyQt
[15:19] <ralsina> thisfred: :-)
[15:20] <thisfred> ok :)
[15:20] <ralsina> thisfred: because what you want is a QListWidget with its items set to checkable
[15:20] <ralsina> thisfred: it's literally no code if you go that way
[15:20] <thisfred> excellent
[15:21] <thisfred> no code is better than code
[15:21]  * thisfred claps with one hand
[15:21]  * ralsina actually has a video of him clapping with one hand somewhere
[15:22] <ralsina> it has a very quiet noise
[15:22] <gatox> ralsina, i've playing with qml these days... and yes, it's addictive, and i found out how to embed qt widgets inside qml stuff.....
[15:22] <thisfred> The Bart Simpson method
[15:22] <ralsina> gatox: I did some experiments a while ago, and yes, it works, but it tends to look strange
[15:22] <gatox> ralsina, yes
[15:22] <ralsina> gatox: and I am guessing thisfred doesn't want to spend a week polishing the round corners of the todo app
[15:23] <gatox> jejejee no..... i don't think this is the case where qml it's needed :PPP
[15:23] <thisfred> +1Ki+
[15:24]  * gatox lunch!
[15:25] <ralsina> oh, lunch, what a novel idea
[15:27] <mandel> dobey, any idea of why the button does that in libubuntuone
[15:30] <dobey> mandel: gtk+ bug maybe. i need to get lunch but i'll poke at it more after. it might be faster for me to just reject your branch and make a branch myself. but will see after lunch
[15:31] <mandel> dobey, ok, as you wish :)
[15:32] <dobey> ok. lunch. bbiab
[15:34] <joshuahoover> ralsina, briancurtin: fyi, added another user to the list of those impacted by bug #984407
[15:35] <joshuahoover> ralsina, briancurtin: that's the "please don't run syncdaemon as root" bug
[15:35] <DamienCassou> rye_: hi. I just wanted to let you know that the tutorial at https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted does not work as expected. pbuilder can't build wikkid_0.2+69+61.dsc due to a python error
[15:37] <rye_> DamienCassou: i am afraid i was only the last to edit, adding an option to builddeb. Are you referring to pbuilder trying to build precise package from oneiric or earler?
[15:39] <DamienCassou> rye_: I'm trying to build wikkid package using pbuilder locally on my ubuntu 11.10
[15:40] <rye_> DamienCassou: for precise? what's the distro pbuilder is configured with?
[15:40]  * rye_ needs to check whether pbuilder is working
[15:40] <DamienCassou> rye_: http://pastebin.com/A7xrievB
[15:41] <DamienCassou> rye_: I just followed the tutorial and didn't specify any distro
[15:44] <rye_> DamienCassou: hm, i guess wikkid trunk is somewhat broken
[15:45] <rye_> DamienCassou: that tutorial is not exactly about wikkid but about the recipes
[15:45] <rye_> DamienCassou: but i understand your concern
[15:45]  * rye_ tries building too
[15:46] <DamienCassou> rye_: thank you. Will try to replace wikkid by emacs and see if it works better (I'm writing a recipe to build emacs-snapshot versions)
[16:02] <alecu> hello...
[16:03] <alecu> I'm on a crappy 2g connection.
[16:10] <mandel> all, EOD for me here :)
[16:11] <mandel> I need to walk the dog etc.. I might be mack if I have some time
[16:14] <alecu> bye mandel!
[16:18] <DamienCassou> rye_: any news?
[16:25] <rye_> DamienCassou: i am having problems building a pbuilder
[16:38] <DamienCassou> rye_: I have to leave now, sorry
[16:38] <Scunizi> Logging in to the web interface I don't seem to have access to my Tomboy notes.. I haven't tried this in a while so I don't know if this is an issue on my end or there was a change to the online sytem.  Please advise.
[16:50] <rye_> Scunizi: http://voices.canonical.com/ubuntuone/2012/02/05/an-important-note-about-notes/
[16:53]  * briancurtin back
[18:08] <dobey> ralsina, briancurtin: seen bug #985343 ?
[18:09] <briancurtin> dobey: no, but looking
[18:09] <ralsina> dobey: happened once before was a aborted install
[18:09] <ralsina> as in "for some unknown reason it failed to copy that file entirely"
[18:09] <dobey> hmm
[18:09] <ralsina> dobey: the user reinstalled and it worked, right?
[18:09] <dobey> i don't know
[18:10] <dobey> i was just pointing you at the bug :)
[18:10] <dobey> feel free to ask user to reinstall and try :)
[18:10] <ralsina> dobey: hehe
[18:10] <ralsina> dobey: he already did it
[18:10] <ralsina> dobey: and it worked ;-)
[18:10] <dobey> ah ok
[18:10] <dobey> well there you go :)
[18:10] <ralsina> So, briancurtin, dobey: this seems to be something that happens very very very rarely
[18:10] <dobey> ok
[18:11] <ralsina> Oh, and dobey: http://www.youtube.com/watch?v=NC79kolQ7p8
[18:11]  * dobey blames ntfs
[18:11] <briancurtin> yeah i hadn't seen that through any of my installer testing and runs
[18:11] <ralsina> we also had one that complained that a corrupted library.zip failed ungracefully
[18:11] <dobey> ralsina: oh, i got mine like 10 days ago
[18:11] <ralsina> which is understandable since our code is IN THERE
[18:11] <ralsina> dobey: he, but mine traveled much farther
[18:11] <briancurtin> there should be some type of integrity check after the installer finishes :/
[18:12] <ralsina> briancurtin: I *think* installbuilder supports that
[18:12] <dobey> ralsina: and i have yet to get a "cool shirt" response from anyone in this area. even at the Yuri's Night party. :(
[18:13] <ralsina> dobey: maybe everyone agrees
[18:13] <ralsina> dobey: and we are now mainstream
[18:13] <dobey> i am so mainstream that i'm not mainstream
[18:13] <ralsina> dobey: my most successful cool shirt is by far the rock-paper-scissors one from Malki
[18:14] <ralsina> followed by the QR-code ones, which did cause a queue at DisneyWorld
[18:14] <ralsina> short queue, but a queue
[18:15] <dobey> i should start making troll qr codes to put on things
[18:16] <dobey> "I don't even see QR codes any more, it's just blonde, brunette, Rick Astley."
[18:27] <urbanape> +1
[19:16] <urbanape> pushed the changes that mandel had asked about (well, apart from header changes, still tracking those - is it the desktop policy to still track authors? We gave up on that in web & mobile)
[19:16] <dobey> track authors?
[19:17] <dobey> you mean "AUTHORS: " in the license header in code?
[19:19] <urbanape> yeah
[19:19] <urbanape> Authors: Alejandro J. Cura …
[19:20] <ralsina> urbanape: we are deleting the AUTHORS as we modify each file
[19:20] <urbanape> cool.
[19:21] <dobey> yeah, drop that noise
[19:22] <ralsina> dobey: how jip hop that sounds.
[19:23] <ralsina> dobey: http://www12.zippyshare.com/v/9403906/file.html
[19:23] <ralsina> There, I probably just commited a crime
[19:28] <alecu_> ralsina, that's no hip hop... sounds like a weird kind of house.
[19:28] <ralsina> alecu_: I saw the title, why would I *listen* to it?
[19:28] <dobey> wub-house
[19:29] <dobey> anyway
[19:29] <dobey> anyone care to review https://code.launchpad.net/~dobey/libubuntuone/alertbar-align/+merge/102749 please?
[19:30] <urbanape> cool. I'll make mention in my MP that that stuff is updated.
[19:30] <ralsina> dobey: sure
[19:30] <alecu_> dobey, reviewing too
[19:31] <ralsina> dobey: these are easiest with screenshots
[19:31] <gatox> urbanape, the mp is ready for review?? or are you talking about something else?
[19:31] <ralsina> dobey: but it's OK!
[19:32] <urbanape> gatox: I think I've hit on all the Needs Fixing that mandel identified.
[19:32] <urbanape> just running tests locally to be sure.
[19:32] <gatox> urbanape, great, let me know and i'll run the tests on linux, win, mac and review it :D
[19:32] <dobey> i can make a screenshot
[19:32] <dobey> fits on a phone!
[19:33] <ralsina> dobey: he
[19:38] <ralsina> dobey: +1 from me but it was just a code review
[19:39] <ralsina> And I have to run to my son's birthday party
[19:39] <ralsina> I will do some more work tonight as usual so if anyone needs anything, mail me
[19:42] <alecu_> ralsina, all: remember that tomorrow I'm taking a conference day.
[19:43] <ralsina> alecu_: ack
[19:43] <dobey> kids these days.
[19:43] <ralsina> alecu_: and we should have mentioned it on the channel earlier :-)
[19:44] <alecu_> ralsina, right: I should have mentioned that on the team meeting.
[19:44] <alecu_> sorry about that, all.
[19:44] <gatox> alecu_, which conference? if i may ask
[19:45] <alecu_> gatox: https://eventos.mozilla-hispano.org/13/mozilla-mdn-hack-day-en-buenos-aires-2012/
[19:45] <gatox> alecu_, ahhhhh i read about that.... cool!
[19:49] <alecu_> dobey, I approved the branch, but I got a question.
[19:49] <alecu_> dobey, when I shrink the window, it looks nice.
[19:50] <alecu_> dobey, but when I grow it so only one line is needed, the text looks a bit off the center of the icon.
[19:50] <alecu_> dobey, should I get a screenshot?
[19:50] <dobey> no, i know it does
[19:51] <alecu_> dobey, ok then.
[19:51] <dobey> and there is basically no way to make it line up
[19:51] <dobey> also the button looks a little off as well
[19:51] <dobey> and basically no good way to fix it
[19:52] <urbanape> ugh something happened with my buildout.
[19:52] <urbanape> gatox: if you want to try it, I've pushed to lp:~urbanape/ubuntu-sso-client/initial-darwin-port
[19:52] <urbanape> I've got to go pick up Lex
[19:53] <gatox> urbanape, ok! no problem..... i'll try that and let you know
[19:53] <urbanape> thx. back in a while
[20:26] <gatox> urbanape, the tests are ok in mac, but in linux i'm getting this: http://paste.ubuntu.com/937410/  and in windows i'm getting a lot of failures: http://paste.ubuntu.com/937423/
[20:32] <alecu_> gatox, urbanape: sorry I missed the second part of the meeting. My internet has been working awfully today.
[20:32] <gatox> alecu_, no problem..... been there :P
[20:35] <alecu_> gatox, so what did you guys discussed in the second part of the meeting?
[20:35] <alecu_> gatox: can you give me a small summary?
[20:35] <alecu_> hmmm... quick is better than small in this matters.
[20:36] <gatox> alecu_, we are going to focus today and tomorrow on landing urbanape branch, i'm looking at the tests (if we can create some kind of runtests for mac... kind of tricky by now because of all the paths and everything that we have to put manually)...... and look at what is failing in u1-cp to try to get some things working......
[20:37] <alecu_> gatox: great
[20:37] <gatox> alecu_, and mandel is going to start with tcpactivation.... so we can start to have some working..... or close...... and ralsina told us that we are getting some assignments on monday that you are going to discuss with him
[20:37] <gatox> alecu_, i think that's all
[20:39] <alecu_> gatox: perfect
[20:40] <alecu_> gatox: yes, we are meeting with ralsina on monday, so he can take home the mini I have, and to discuss the pending bugs we have in the queue.
[20:41] <gatox> ok..... soooo, eod for me now...... urbanape i'll be around anyway, so let me know if you need me to run the tests again or something, or i'll do it first time tomorrow if you want too
[20:41] <gatox> bye all!
[21:31] <thisfred> ralsina, would appreciate QT (or other) feedback on this: https://code.launchpad.net/~thisfred/u1db/u1todo-2/+merge/102770
[21:31] <thisfred> if you're not past EOD already that is.
[21:31] <thisfred> it's not urgent
[21:33] <thisfred> and with that, *I* am EOD
[21:36] <dobey> later all


[06:05] <mup> PR snapd#9939 opened: RFC: Vendor apparmor3 for improved cross-distro/platform support and easier ongoing maintenance <Created by alexmurray> <https://github.com/snapcore/snapd/pull/9939>
[07:14] <mborzecki> morning
[07:49] <mborzecki> mvo: hey
[07:49] <mvo> hey mborzecki !
[07:51] <mup> PR snapd#9940 opened:  boot: cmd/snap-bootstrap: handle a candidate recovery system v2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9940>
[08:04] <pstolowski> morning
[08:10] <mvo> good morning pstolowski
[08:21] <mup> PR snapd#9901 closed: o/devicestate,many: introduce DeviceManager.preloadGadget for EarlyConfig <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9901>
[08:22] <mborzecki> hmmm
[08:22] <mborzecki> that labeler does silly things sometimes
[08:22] <mborzecki> https://github.com/snapcore/snapd/pull/9940#event-4345279407
[08:22] <mup> PR #9940:  boot: cmd/snap-bootstrap: handle a candidate recovery system v2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9940>
[08:33] <zyga> o/
[08:44] <pedronis> mborzecki: hi, I'm looking at #9940, it feels weird that we need to check that new flag in so many places? am I missing something?
[08:44] <mup> PR #9940:  boot: cmd/snap-bootstrap: handle a candidate recovery system v2 <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9940>
[08:45] <mborzecki> pedronis: you mean the flat to not allow fallback keys?
[08:45] <pedronis> yes
[08:47] <mborzecki> pedronis: hm i guess i could simplify that to do the check only in the fallback* state handlers
[08:49] <pedronis> mborzecki: we are probably misunderstanding each other on something else
[08:49] <mborzecki> pedronis: quick chat?
[08:50] <pedronis> mborzecki: I have a meeting in 10
[08:51] <mborzecki> pedronis: after the meeting then?
[08:52] <pedronis> I need to chat with mvo after the meeting
[08:52] <pedronis> mborzecki: what I don't understand is also why we don't finish early in this mode?
[08:53] <mborzecki> pedronis: we do, right after the initramfs mounts state machine finishes
[08:53] <pedronis> mborzecki: but shouldn't the state machine finish early too?
[08:53] <pedronis> maybe
[08:55] <mborzecki> pedronis: it's done after mounting save
[08:58] <pedronis> mborzecki: anyway we should find a way to reduce the ifs and diff size, maybe we'll also need less tests then
[08:58] <pedronis> *fewer
[08:59] <mborzecki> pedronis: added something to the calendar to discuss it, maybe i missed something
[09:00] <pedronis> mborzecki: also why the mountsErr vs err thing ?
[09:01] <mborzecki> pedronis: here? https://github.com/snapcore/snapd/pull/9940/files#diff-aec04aa8357bab6140f694de4af1f79a69d615f74585f349e7a389fb43e975d8R1029
[09:01] <mup> PR #9940:  boot: cmd/snap-bootstrap: handle a candidate recovery system v2 <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9940>
[09:01] <pedronis> mborzecki: well a bit everywhere
[09:01] <pedronis> mborzecki: also do we stop asking for the recovery key?
[09:04] <mborzecki> pedronis: yes, the handling returns early if fallback keys are to be skipped
[09:05] <pedronis> mborzecki: I mean the user input recovery key, not the fallback keys to be clear
[09:07] <mborzecki> pedronis: yes, that place is not reached, but yeah, i see now how moving the check to the fallback state handler would make it clearer
[09:11] <pedronis> mborzecki: yes, moving the fail to the actual states we don't want, instead of all the places that call them would be much easier
[09:11] <mup> PR snapd#9941 opened: Snapshot save fails with sockets in folder <Created by mapero> <https://github.com/snapcore/snapd/pull/9941>
[09:12] <mborzecki> pedronis: i've added quick sync at 1030 after the desktop meeting
[09:14] <pedronis> mborzecki: as I said I should sync with mvo at that time
[09:15] <mborzecki> pedronis: ah ok, got a quick errand at 11, so 12 then?
[09:15] <pedronis> mborzecki: maybe you have already input now anyway?
[09:15] <pedronis> mborzecki: my main ask it to make the diff smaller and less churny
[09:16] <pedronis> *enough input
[09:17] <mborzecki> pedronis: ok, let me work on this for a bit then and push something, and then we can discuss
[09:56] <mborzecki> quick errand, back in 30
[10:50] <mborzecki> re
[10:53] <mborzecki> pedronis: i'm thiniking, i could split the boot bits into a separate pr, should make the whole thing easier to review hopefully
[10:54] <pedronis> mborzecki: yes, that is also true
[10:54] <mborzecki> pedronis: just the tests in s-b are like 350+ inflating the whole thing a lot
[10:55] <pedronis> mborzecki: I still hope the diff of cmd_initramfs_mounts.go itself can be shrunk
[10:58] <mborzecki> pedronis: it is a bit smaller now: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/uc20-recovery-mgmt-sb-try-handling-v2-wip#diff-aec04aa8357bab6140f694de4af1f79a69d615f74585f349e7a389fb43e975d8
[11:01] <pedronis> mborzecki: yes, it looks a bit easier to review without getting lost at least
[11:01] <mborzecki> tests are still large, but sadly there's lot of state to mock :/
[11:01] <mup> PR snapd#9942 opened: boot: helper for checking and marking tried recovery system status from initramfs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9942>
[11:01] <mborzecki> pedronis: just the boot bits ^^
[11:02] <pedronis> mborzecki: that's ok, at the end of the day the code needs to look right first even before considering the tests
[11:04] <mborzecki> in the meantime, not sure how gorename ended up renaming so many bits to mountsErr, hmm
[11:05] <pedronis> mborzecki: ah, well that was messy
[11:05] <mborzecki> it's not even gorename, but godoctor rename
[11:06] <pedronis> ok but for sure didn't win points :) no cookies for that tool
[11:11] <mborzecki> hahah that's true
[11:12] <mborzecki> surprising golsp doesn't have that functionality yet
[11:53] <pstolowski> pedronis: i've updated #9930 but I'm going to remove bulk.go changes from it and work on it in a separate PR
[11:53] <mup> PR #9930: asserts: pool changes and RefreshValidationSetAssertions method for validation-sets <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9930>
[11:54] <pstolowski> (overlord/assertate/* will be moved to a separate PR)
[11:55] <pedronis> pstolowski: sounds good
[11:56] <pedronis> pstolowski: let me know when it's ready to review
[11:58] <pedronis> mborzecki: I will start with 9942 but is 9940 also re-ready for review?
[11:58] <mborzecki> pedronis: yes, i've updated it
[11:58] <pedronis> thx, I will look in a bit
[12:04] <pstolowski> pedronis: it is now
[12:14] <mborzecki> pedronis: wondering, shall we s/good_recovery_sytems/verified_recovery_systems/ or does verified imply too much here?
[12:17]  * cachio afk
[12:39] <mvo> pedronis: I updated 9907 with the most simple version of a filter func, please have a look (not urgent) and if it looks too simplistic I will have to do a version of mountedfilesystemwriter that also takes the filter func (separate PR as discussed). thanks again for all your suggestions
[12:44] <pedronis> mborzecki: it implies the wrong things, we use verify for the checks we do based on assertions, and we really never boot something that is not verified
[12:45] <mborzecki> ack
[12:45] <pedronis> or at least shouldn't
[13:27] <pedronis> mborzecki: I did a pass on 9942
[13:28] <mborzecki> pedronis: thanks, finishing the modeenv bits and will take a look after
[13:40] <pedronis> mvo: I commented on #9907
[13:40] <mup> PR #9907: gadget,devicestate: perform kernel asset update for $kernel: style refs <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9907>
[13:47] <mup> PR snapd#9943 opened: boot: introduce good recovery systems, provide compatibility handling <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9943>
[13:47] <mborzecki> pedronis: hopefully this one is simpler ^^
[13:57] <mup> PR snapd#9944 opened: github: temporarily disable action labeler due to issues with labels being removed <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9944>
[14:12] <mup> PR snapd#9905 closed: asserts: validation sets WIP <Skip spread> <validation-sets :white_check_mark:> <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/9905>
[15:42] <mborzecki> heh, so now i know why my spread test didn't work, ofc boot-state is completely unaware of grubenv being somewhere else, especially not under /run/mnt/ubuntu-seed..
[15:43] <mborzecki> mvo: debian testing is getting installed in a vm
[15:51] <ijohnson> thanks mborzecki
[15:51] <ijohnson> mborzecki: I made a spreadsheet to track the testing on debian, I'll PM it to you
[15:52] <mborzecki> ijohnson: thanks, i'l try to run some tests today, if not then tomorrow morning
[15:52] <ijohnson> great!
[15:53] <mborzecki> ijohnson: s/debian 10/debian 11/ in the spreadsheet right?
[15:53] <ijohnson> ah yeah probably
[15:53] <ijohnson> I made it during another meeting so typos 🤷♂
[15:57] <mvo> mborzecki: \o/ you rock
[16:03]  * cachio afk & lunch
[17:02] <pedronis> pstolowski: I made maybe a simplifying suggestion in #9930
[17:02] <mup> PR #9930: asserts: pool changes for validation-sets <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9930>
[17:02] <pstolowski> pedronis: ty, looking
[17:04] <pstolowski> pedronis: sounds sensible, i'll see how it goes, thanks
[17:43] <kkoukiou> Hi :) I want to ask if there is plan/interest for resolving https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1714941 ? In cockpit [1] we have a udisks2 UI where we display available volumes, and we got one issue about it [2]
[17:43] <kkoukiou> [1] cockpit-project.org/
[17:43] <kkoukiou> [2] https://github.com/cockpit-project/cockpit/issues/14424
[17:43] <mup> Bug #1714941: mounts should hint ignore <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1714941>
[19:06] <mup> PR snapcraft#3438 opened: flutter: Specify arch specific bundle dirs fixes LP:1915991 <Created by kenvandine> <https://github.com/snapcore/snapcraft/pull/3438>
[19:10] <diddledan> kkoukiou: I've remapped that bug to snapd because it isn't related to the snapcraft utility that is for building snaps
[20:52] <lord4163> Hi
[20:53] <lord4163> I have lxd installed as a snap on raspbian and I try to import a qcow2 image using `lxc image import <image>`, but it fails... Error: exec: "qemu-img": executable file not found in $PATH
[20:53] <lord4163> I have qemu and qemu-utils installed as regular packages
[21:08] <ijohnson> lord4163: that's probably a bug with the lxd snap, try the #LXD channel
[21:08] <ijohnson> cc stgraber ^
[21:11] <mup> PR snapcraft#3439 opened: Don't error out if font cache generation fails.  This can cause <Created by kenvandine> <https://github.com/snapcore/snapcraft/pull/3439>
[21:36] <diddledan> ijohnson: as you're around, and I don't know who to ping, can you point a security person at https://forum.snapcraft.io/t/cve-2021-3177/22843 who can advise as to the processes in place for Ubuntu and the base snaps (separately)
[21:37] <ijohnson> haha I literally _just_ replied to that :-D
[21:37] <ijohnson> but thanks for the ping diddledan
[21:37] <diddledan> haha
[21:37] <diddledan> I see it now :-)
[21:38]  * diddledan clicks the heart


[09:36] <JackFrost> bluesabre: May I poke you about catfish? :)
[09:37] <bluesabre> JackFrost: yes, planning to do another point release in the next day or so to fix the new packaging issue
[09:40] <JackFrost> OK, no pressure since you already have a lot going on. :)
[09:48] <JackFrost> Oh hey, I presume there's no place you want Emery to report Xubuntu Core tests? :D
[09:49] <bluesabre> Email hasn't been bad, but we could add the tests to the tracker instead
[09:50] <JackFrost> Problem is that it's not official still, so I guess email will have to do.
[09:52] <bluesabre> Yup
[09:53] <bluesabre> Sure would be nice if there was >1 person as the gatekeeper
[09:53] <bluesabre> Suppose I should start my 20.04 nagging at him for it
[09:54] <JackFrost> I'm sorry you seem to get stuck with everything. :3
[09:54] <JackFrost> Discarding from the mailing list: Subject: LiveFS xubuntu/focal/amd64 failed to build on 20200107
[09:56] <bluesabre> Alrighty
[10:16] <JackFrost> Did you want me to start funneling free experimental xfce 4.15 packages somewhere?
[10:20] <JackFrost> Debian #925824
[17:38] <flocculant> bluesabre JackFrost - doesn't have to be official for it to be on the tracker, they can be added - but they never ever reported to there even after being asked more than once - so probably not worth the bother
[21:00] <ochosi> JackFrost: that'd be nice (4.15 packages)
[21:00] <ochosi> i guess i need to work on getting more releases out though
[22:13] <JackFrost> ochosi: Well I can pick them up as they go into Debian experimental, but they'd have to go *somewhere*.


[19:22] <iophk> I have two questions about the writing of the server guide: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/UbuntuServerGuide
[19:22] <iophk> 1) What version of Docbook is being used, v5?
[19:22] <iophk> 2) What element would be used to link from one Docbook file to a section within another Docbook file?


[03:52] <pavlushka> Morning Every one :)
[05:09] <pavlushka> Morning Nahiyan :) and Eid Mubarak !
[05:09] <Nahiyan> yo
[14:41] <sk_> hello everyone :)
[17:03] <dipraw> back after a long time!!
[17:03] <dipraw> eid mubarak to everyone!


[18:54] <jafa> I maintain ppa packages for varnish and hitch to stay up to date with the latest releases (ubuntu server 24.04 is still on a varnish release from 2 years ago)... wondering if the varnish package is actively maintained and/or what the process is to volunteer to help
[18:57] <JanC> 24.04 has 7.1.1
[18:58] <JanC> seems like Debian sid also has that
[18:59] <JanC> might be worth checking why Debian is still on 7.1.1
[19:02] <JanC> also, late requests for upgrades will probably be seen as suspicious after what happened recently...  :-/
[19:04] <mdeslaur> heh
[19:09] <JanC> it looks like maybe Debian could use some help with varnish?
[19:10] <tomreyn> yes, the package doesn't look too happy
[19:14] <tomreyn> jafa: the path towards getting more up to date varnish packages into ubuntu, as .deb packages, through the default ubuntu repositories, goes through debian. https://tracker.debian.org/pkg/varnish is an overview on the package state and developer information. the package is in such a bad state that it was just removed from debian testing a week ago (it can re-enter there if someone works on it), because there is an unfixed security bug and
[19:14] <tomreyn> two grave bugs in it.
[19:15] <tomreyn> *is through
[19:16] <tomreyn> connect to the oftc irc network, and join #debian-mentors for more info on how you can contribute.
[19:38] <jafa> thanks
[22:30] <MTecknology> I can't even remember the last time I heard of varnish in use.
[22:31] <MTecknology> (certainly not saying "bad," but it sure hit me like I'd just heard mandrake)
[22:33] <MTecknology> jafa: If you're seriously considering taking it over, I *highly* recommend reaching out to the most recent uploader(s) and ask what issues they ran into. It's also worth asking if they can help you learn how to get things into good shape so that you can continue the effort.
[23:53] <jafa> MTecknology: thanks for the direction
[23:54] <jafa> I am a big fan of varnish... in part because you can add c code to the vcl script
[23:55] <jafa> which means you can do pretty much anything
[23:56] <jafa> no compiling/restarting necessary


[04:58] <mborzecki> morning
[05:00] <zyga> mborzecki: fire fire
[05:00] <mborzecki> zyga: hi, yeah, looking into it
[05:00] <zyga> https://bugzilla.redhat.com/show_bug.cgi?id=1716397
[05:01] <zyga> Thank you!
[05:14] <mborzecki> zyga: makes me wonder, why snapd attempts to remount /var/lib/snapd/snap
[05:14] <mborzecki> zyga: maybe it's because it's trying to put some services in separate ns?
[05:23] <mborzecki> mborzecki: must be because of Private* directives in service files
[05:24] <mborzecki> zyga: ^^
[05:25] <zyga> Remount?
[05:25] <zyga> Aha!
[05:25] <mborzecki> zyga: PrivateMounts=yes probably
[05:25] <zyga> Private directives is a systemd feature
[05:25] <zyga> Is it on by default?
[05:25] <mborzecki> zyga: then systemd sets up a mount namespace for the service
[05:26] <mborzecki> zyga: i think now (at least not on arch), but some services, like resolved have it enabled
[05:26] <zyga> So what is the interplay with snapd?
[05:27] <mborzecki> snaps are mounted with snappy_snap_t context, but init_t does not have permission to remount this
[05:27] <zyga> Ahhhh
[05:27] <zyga> Meh
[05:28] <zyga> Selinux is too complex!
[05:28] <zyga> So now we have to fix systemd policy?
[05:28] <mborzecki> zyga: no, just selinux
[05:29] <mborzecki> zyga: http://paste.ubuntu.com/p/fZ2hp7Y9hC/ the fix
[05:29] <mborzecki> i supose that's the best we can do outside of core/contrib policy
[05:31] <zyga> Why did our test suite not catch that?
[05:31] <zyga> And how does it cause people’s machines to become unresponsive? Is systemd hanging?
[05:32] <mborzecki> zyga: we don't reboot in the tests mostly, and it affects external services that need to be restarted, eg resolved, which we don't do
[05:32] <mborzecki> zyga: i guess sddm and such have PrivateHome or similar
[05:34] <zyga> mborzecki: let’s add a test that reboots
[05:34] <zyga> It is essential to provide good service
[06:36] <mborzecki> zyga: running a regression test spread test
[06:39] <mvo> hey mborzecki and zyga!
[06:39] <mborzecki> mvo: hey, some fire in fedora-land
[06:39] <mvo> mborzecki: uhoh, whats up?
[06:39] <mborzecki> mvo: https://bugzilla.redhat.com/show_bug.cgi?id=1708991
[06:40]  * mvo looks
[06:43] <zyga> Hey mvo
[06:43] <zyga> I didn’t manage to do that review for avahi changes
[06:44] <zyga> Sorry, fighting uphill battle with kids
[06:44] <zyga> I’ll start around 10
[06:47] <mvo> zyga: ok
[06:47] <mborzecki> zyga: about that spurious SELinux failure in tests, it's caused by the upgrade test, which installs snapd from the repo, a version we know to break with symlinks in /etc/
[06:48] <mvo> mborzecki: I read the bugzilla now, do we have an idea about the fix already?
[06:50] <mborzecki> mvo: yes, i'm running a regression test under spread now
[06:50] <mvo> cool
[07:03] <pstolowski> morning
[07:13] <mvo> hey pstolowski ! good morning
[07:18] <mborzecki> pstolowski: hey
[07:18] <mborzecki> mvo: zyga: https://github.com/snapcore/snapd/pull/6946
[07:23] <mvo> mborzecki: we will do a 2.39.2 for this one
[07:23] <mvo> mborzecki: it sound critical enough, yes?
[07:24] <mborzecki> mvo: yeah, neal asked whether we could do .2
[07:28] <mborzecki> funny that there is no issue on centos
[07:48] <mvo> mborzecki: do you need the logs from #6944 ? I would like to restart it
[07:49] <mborzecki> mvo: no, go ahead
[07:49] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6946 ?
[07:49] <zyga> Arriving in 10 min
[07:51] <pstolowski> mborzecki: ok
[07:55] <mborzecki> pstolowski: thanks!
[07:58] <zyga> Almost ready
[08:00] <zyga> re
[08:00] <zyga> okay
[08:00] <zyga> mborzecki: looking
[08:02] <mvo> mborzecki: I added some comments for 6946
[08:03] <zyga> mborzecki: reviewed
[08:03] <mborzecki> zyga: can't push to fedora
[08:03] <zyga> why not?
[08:03] <zyga> ENOPERM?
[08:04] <zyga> if so we should fix that
[08:04] <zyga> but I can help meantime
[08:05] <mborzecki> zyga: yeah, no permissions :P
[08:06] <zyga> trying to log in on https://bugzilla.redhat.com/show_bug.cgi?id=1716736
[08:07] <zyga> gets bounced via id.fedora*
[08:07] <zyga> then nothing
[08:07] <zyga> still not logged in
[08:07] <zyga> eh
[08:08] <zyga> browser woes
[08:09] <mborzecki> zyga: you can mark it as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1708991
[08:12] <mborzecki> pstolowski: are you using the nested spread suite?
[08:13] <pstolowski> mborzecki: i used it for hotplug test, yes
[08:13] <zyga> mborzecki: sure
[08:14] <mborzecki> pstolowski: that's good
[08:14] <zyga> mborzecki: done
[08:26] <pstolowski> mborzecki: i haven't run it for a while; but i believe it's now run overnight (unless Sergio changed something)
[08:30] <mborzecki> pstolowski: hm no clue where those are started
[08:31] <mborzecki> pstolowski: there's no indication in travis.yaml or travis project page, probably sergio knows
[08:33] <mborzecki> got a quick errand to run, back in 30
[08:41] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6946 is green
[08:43] <pstolowski> mborzecki: i don't know how this is all wired up with spread-cron, but i found a run from 6h ago here: https://travis-ci.org/snapcore/spread-cron/builds/541031798, you can see nested stuff is run there
[08:51]  * zyga moves  somewhere  quiet
[09:01] <pstolowski> pedronis: can https://github.com/snapcore/snapd/pull/6935 land (has +2 now) or do you want to take a look?
[09:02] <pedronis> pstolowski: it's fine
[09:02] <pstolowski> ty
[09:04] <pstolowski> pedronis: btw, load-state was too fast in my tests to get saved in the state and was not reported, likely due to small size
[09:11] <mborzecki> re
[09:35]  * zyga is back home
[09:35] <zyga> apparently no good place for work today
[09:35] <zyga> ETOOHOT ETOOLOUD
[09:36] <ogra> ogra@localhost:~$ sudo hostnamectl set-hostname pi2
[09:36] <ogra> Could not set property: Failed to set static hostname: Read-only file system
[09:36] <ogra> ogra@localhost:~$ ls /etc/writable/
[09:36] <ogra> ogra@localhost:~$ ls -l /etc/hostname
[09:36] <ogra> lrwxrwxrwx 1 root root 17 Feb 11 14:50 /etc/hostname -> writable/hostname
[09:36] <ogra> mvo, i thought that was fixed (core18)
[09:36] <ogra> (just downloaded from cdimage stable)
[09:39] <mvo> ogra: can you please refresh core18? maybe the image is old?
[09:39] <ogra> it did just auto-refresh it seems
[09:39] <ogra> creating writable/hostname works fine btw
[09:39] <Chipaca> ogra: is there an /etc/writable ?
[09:40] <ogra> Chipaca, yes, but not the empty files
[09:40] <ogra> just touching hostname, localtime and timezone in the dir usually makes  it work
[09:45] <ogra> oh, lovely ... and while i was just apt installing something under the classic snap, snapd decided to reboot in the middle of it
[09:45]  * Chipaca hands ogra a wand of shutdown -c
[09:45] <ogra> Chipaca, hard to do if the console is occupied by apt output :P
[09:46] <Chipaca> ogra: and 'tmux' is a classic snap :-(
[09:46] <ogra> (i know i can open a second ssh session but you have to be really fast since the shutdown happens so quickly in 18)
[09:51]  * Chipaca goes for coffee
[09:53]  * zyga is tired today
[09:53] <zyga> sorry everyone, next year I'm getting A/C
[09:53] <zyga> I'll get that coffee
[09:54] <zyga> but first some paperwoor
[09:54] <zyga> work
[10:09] <zyga> mvo: can you commit this suggestion please https://github.com/snapcore/snapd/pull/6945#discussion_r290222845
[10:10] <mvo> zyga: already done
[10:10] <zyga> thank you
[10:18] <Chipaca> grah, there's a bug in a test :-(
[10:18]  * Chipaca grahs
[10:18]  * Chipaca restarts the test because it's a racy bug but looks into fixing it anyway
[10:38] <mborzecki> looks like i've hijacked all build slots on travis :)
[10:39] <zyga> mborzecki: *used* :)
[10:39] <zyga> it's good to keep things going
[10:39]  * zyga iterates locally
[10:55] <zyga> my mind is melting today
[10:56] <mborzecki> zyga: well +30 in shade here, summer came early?
[10:56] <zyga> mborzecki: I'm working from within an oven
[10:57] <zyga> tried to work from a cafeteria but the insane requirement to keep ultra loud music drove me away
[10:57] <zyga> I really hate that brand owners force branded stores to play loud music all day long
[10:57] <zyga> I got a headache and left
[10:58] <mborzecki> zyga: should have played some vader on your laptop to counter the ambient noise :)
[10:58] <zyga> the staff hates it
[10:58] <zyga> but they cannot turn it down
[10:58] <zyga> they literally cannot I was told
[11:09] <ogra> mvo, digging a bit deeper regarding the hostname/timezone/localtime stuff, i see the files in /snap/core/current/etc/writable/ and also only have one core installed yet ... seems the content of /etc/writable did not get copied for me
[11:12] <ogra> ogra@pi2:~$ grep etc/writable /etc/system-image/writable-paths
[11:12] <ogra> /etc/writable                           auto                    persistent  none        none
[11:13] <ogra> hmm, shouldnt the second arg ne "transition" ?
[11:20] <ogra> ok ... here is core16:
[11:21] <ogra> ogra@stream:~$ grep /etc/writable /etc/system-image/writable-paths
[11:21] <ogra> /etc/writable                           auto                    synced      none        none
[11:21] <ogra> why did we remove the "synced" between core 16 and 18 ?
[11:24] <zyga> ogra: perhaps, I recall some changes there
[11:24] <zyga> mvo: do you remember?
[11:25] <zyga> ogra: the problem with writable paths is that it is non-obvious what happens when a file is removed
[11:25] <ogra> well, "persistent none" is definitely wrong
[11:25] <zyga> and that it's pretty niche so we don't all have experience with it
[11:26] <ogra> well, if persistent is set nothing happens if a file is removed from the writable area ... if synced is set the one from the core(18) snap will be copied in place
[11:26] <ogra> http://manpages.ubuntu.com/manpages/xenial/man5/writable-paths.5.html is pretty clear about the bahaviour
[11:26] <ogra> *behaviour
[11:28] <ogra> or do you mean removed from the readonly part (it will not have any effect, we had a userspace removal service for that on the phone to make sure the writable side gets removed as well if needed)
[11:30] <ogra> in any case the current behaviour is wrong, the dir needs to be copied once on firstboot (whihc either "synced none" or "persistent transition" achieves", with synced you have a permaent connection between the two while "persistent transition" will only copy once on first boot)
[11:31] <zyga> ogra: I'm deep in another place, sorry I cannot help with this now
[11:32] <ogra> i didnt expect you to ... but i had the impression that was fixed a while (months ?) ago
[11:32]  * pstolowski lunch
[11:38] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/6946 landed
[11:45]  * zyga debugs stuff
[11:45] <zyga> gnome, how I hate your interactions
[11:45] <zyga> I cannot wait for WSL2
[11:45] <zyga> I will happily run WSL2 and windows terminal
[11:45] <zyga> sorry gnome, you're full of great tech and you were surely made with love
[11:46] <zyga> it's me, it's not you
[11:46] <cachio> mvo, hey
[11:47] <mborzecki> zyga: how about garden gnomes? :)
[11:47] <zyga> mborzecki: same level of adoration
[11:54] <cachio> mvo, is it ok if I do some modifications to the autopkgtests change?
[12:03] <zyga> cachio: I think so, what do you want to change?
[12:06] <cachio> zyga, move the test to the new nightly suite
[12:06] <zyga> cachio: what are you aiming to achieve with that move?
[12:06] <mborzecki> off to pick up the kids
[12:09] <cachio> zyga, it is mainly because the find of tests we have in the nightly suite
[12:11] <cachio> zyga, but we can do it in a following PR
[12:16] <cachio> zyga, I am running the test now to see how it works within the nested suite
[12:27] <mvo> cachio: sure, what do you have in mind?
[12:28] <pstolowski> zyga: i failed to rework retry error handling, but come up with this https://github.com/snapcore/snapd/pull/6949 ; keen to see how travis likes it. local runs with network ns & spread tests on select machines were succesful
[12:29] <mvo> mborzecki: thanks, cherry-picked
[12:30] <mvo> ogra: hey, sorry for the delay. re "synced"> we don't have synced anymore as it was a source of confusion and issues, having transition there is fine if its missing of course
[12:31] <mvo> ogra: let me look at the issue at hand
[12:32] <ogra> mvo, yeah, we should definitely add transition to get the dir initially filled with files ... interestingly hostnamectl seems to behave differently on x86 (for lool ) and actually just creates the missing file (while it seems to try to modify /etc/hostname directly on my pi install)
[12:33] <ogra> so there seems to be an additional issue that doesnt show up if the filesystem is set up as expected
[12:33] <zyga> hmm
[12:33] <zyga> mborzecki: do you know when you are in debug shell
[12:33] <zyga> and then you run a command like foo.sh
[12:33] <zyga> when sh is a simple app that does exec /bin/sh "$@"
[12:34] <zyga> and then you end up in a loop with /bin/sh: 0: Bad substitution
[12:34] <zyga> and you cannot interrupt that
[12:34] <zyga> is that that app running itself?
[12:34] <zyga> I bump into this once in a while
[12:34] <zyga> and it is infuriating when it happens
[12:34] <zyga> (I just lost all state I had in this machine)
[12:35] <cachio> mvo, as the test is failing at least on ubuntu-16.04 running on nested vm
[12:36] <cachio> I though on moving it to the nightly suite
[12:36] <mvo> ogra: I created #131 against core18
[12:36] <cachio> and there run spread with autopackgtest backend
[12:37] <mvo> cachio: meh, ok, I ran it only on 16.04 - what is the error?
[12:37] <cachio> mvo line 65: autopkgtest-buildvm-ubuntu-cloud: command not found
[12:38] <mvo> cachio: aha, ok - I think I know what to do
[12:38]  * zyga tries some more debugging
[12:39] <mvo> cachio: nightly is an interessting idea, we can test on more distro release then too, right? lets talk about it in a bit, need to talk to zyga first about something unrelated
[12:39] <cachio> mvo, sure
[12:41] <ogra> mvo, thanks !
[12:46] <mvo> ogra: thanks for raising it
[13:05] <zyga> mborzecki: it's curious, just running spread -shell-before and running "sh" kills the system
[13:05] <zyga> checking
[13:15] <zyga> mborzecki: it's PS1
[13:15] <zyga> mborzecki: it's not compatible with sh
[13:45] <Eighth_Doctor> zyga, mborzecki: so are we going to have a 2.39.2, or should I cherry-pick on top of 2.39.1?
[13:45] <zyga> Eighth_Doctor: I would recommend cherry picking
[13:45] <zyga> we just discussed this
[13:45] <zyga> .2 would be for autopkg test
[13:45] <zyga> that's not really anything relevant
[13:45] <Eighth_Doctor> 🤷♂
[13:46] <zyga> and I think it's really better to cherry pick in both cases (maybe .2 is not needed at all)
[13:46] <Eighth_Doctor> I'll work on cherry-picking later today then
[13:46] <mborzecki> Eighth_Doctor: .1 also has a fix for symlinks in /etc/
[13:46] <Eighth_Doctor> yeah, I saw that
[14:02] <zyga> Eighth_Doctor: thank you!
[14:03] <zyga> I'm suspending my desktop and going to look for shade in the bedroom; this place is at +40C now
[14:03] <cachio> mvo, hey
[14:03] <Eighth_Doctor> zyga: you should get air conditioning
[14:03] <Eighth_Doctor> I would have figured after last year, you would have bought an AC unit and set that up
[14:03] <cachio> so am also getting out of snpace issues runing autopkgtests on gce
[14:04] <cachio> mvo, perhaps the best is to remove the test from that PR, and I'll continue wotking on this on a following PR
[14:04] <cachio> otherise it is going to break the nested suite
[14:05] <cachio> otherwise
[14:05] <cachio> mvo, does it makes sense?
[14:06] <cachio> mvo, I'll need to create new images to support this new test
[14:27] <ijohnson> hey folks, is it possible to get https://github.com/snapcore/snapd/pull/6805 pulled into a 2.39.x ? or do we need to wait until 2.40 hits stable?
[14:27] <pstolowski> zyga: #6949 is green; are you able to test it on a suse build infra?
[14:28] <zyga> pstolowski: sure, let me try
[14:29] <mvo> cachio: yes, I can do this - fwiw, I got the same error you got - testbed failure due to timeout, I think we need to run "autopkgtest --timeout-factor=3" or something
[14:29] <mvo> cachio: I will remove the test now and force push and then we can do that in a separate PR
[14:29] <mvo> ijohnson: hey, let me look
[14:29] <mvo> ijohnson: that looks ok for 2.39.2
[14:30] <ijohnson> thanks mvo! do you want me to file a PR against release/2.39 for that branch?
[14:30] <mvo> ijohnson: let me see if I can cherry pick cleanly, if so no need for a PR
[14:31] <cachio> mvo, nice, thanks
[14:31] <mvo> ijohnson: cherry pick worked, so all good, its part of release/2.39 now
[14:31] <ijohnson> mvo: thank you!
[14:31] <cachio> mvo, in the nightly suite is not giving that error but at some point the vm is going out of space
[14:32] <cachio> mvo and breaks
[14:32] <mvo> ijohnson: thank *you* for the PR :)
[14:32] <mvo> cachio: oh, woah
[14:32] <mvo> cachio: the nested VM? or the "parent" VM?
[14:32] <cachio> I think the nested
[14:33] <cachio> mvo, https://paste.ubuntu.com/p/G9qhxwcn5W/
[14:33] <cachio> I mean the parent
[14:34] <mvo> cachio: thanks and *meh* thats annyoing, I can see why, the nested vm will also need quite a bit of space :/
[14:34] <mvo> cachio: I removed all but the "integrationtest" commit
[14:34] <cachio> mvo, I'll updates those images with more space
[14:34] <mvo> cachio: thanks
[14:34] <cachio> mvo, nice
[14:35] <mvo> cachio: I will run adt manually now on all our supported distro releases to unblock this PR
[14:35] <cachio> nice
[14:35] <cachio> mvo, thanks
[14:36] <zyga> pstolowski: building now
[14:41] <pstolowski> zyga: ty
[14:45] <zyga> pstolowski: I need to rebase the patch, hold on
[14:48] <pstolowski> mborzecki: can you take a look at #6900 if you have a moment?
[14:49] <mborzecki> pstolowski: sure
[14:49] <zyga> pstolowski: some typos in the patch, check your editor please
[14:51] <zyga> pstolowski: rebased, not sure which other patches should be present
[14:51] <zyga> testing now
[14:51]  * cachio lunch
[14:51] <pstolowski> zyga: typos?
[14:52] <zyga> pstolowski: yes, commit message has several
[14:52] <zyga> pstolowski: the  tests have failed:
[14:52] <zyga> https://www.irccloud.com/pastebin/GlYDnpJR/
[14:52] <zyga> pstolowski: also the 1st line is too long for git commit messages
[14:53] <zyga> pstolowski: anyway, the essence  is different
[14:53] <zyga> pstolowski: I pushed opensuse/2.39.1-patches
[14:53] <zyga> this is what  I tested
[14:53] <zyga> please look at  the patches, I can nuke any easily
[14:55] <pstolowski> zyga: ah, but this is something else, i haven't seen such failure when running with net ns
[14:56] <zyga> pstolowski: correct, I think inside obs there are  more things changed
[14:56] <zyga> specifically the DNS server
[14:56] <pstolowski> wonderful
[14:56] <zyga> pstolowski: fun, right?
[14:56] <zyga> pstolowski: if you want I can show you how to set up for local testing
[14:56] <zyga> it's not complex actually
[14:57] <pstolowski> zyga: okay, i need some way of triggering this
[14:58] <pstolowski> zyga: need to got to vet now, bbiab
[14:58] <zyga> pstolowski: k, ping me later please
[15:32] <pstolowski> zyga: back
[15:33] <zyga> in a call now
[15:33] <zyga> pstolowski: install tumbleweed in a vm
[15:33] <zyga> pstolowski: maybe pick ext4 over btrfs
[15:33] <zyga> pstolowski: that's all you'll need
[15:33] <pstolowski> k
[15:57] <pstolowski> zyga: ok, i've it nwo
[15:57] <pstolowski> *now
[16:01] <zyga> pstolowski: you want to install whatever provides osc
[16:01] <zyga> pstolowski: osc checkout system:snappy
[16:01] <zyga> pstolowski: then osc build
[16:01] <zyga> it's fairly well documented
[16:01] <zyga> you will likely need to create a suse account
[16:01] <zyga> it's hand-holdy all the way so I think it should be smooth
[16:01] <zyga> once you have that I can show you how to trigger the failure
[16:02] <pstolowski> k
[16:08] <zyga> pstolowski: pstolowski: we can HO if you want to do  that interactively
[16:08] <pstolowski> zyga: i've a checkout now
[16:08] <zyga> pstolowski: try osc build
[16:08] <zyga> that should  pass
[16:09] <zyga> if you comment-out some of the patches you can osc build again and see the failures happen
[16:16] <pstolowski> zyga: ok, got successfull build as you said, trying without patches now
[16:16] <zyga> pstolowski: ok
[16:16] <zyga> pstolowski: you only need to change two lines
[16:16] <zyga> one that says Patch: ... at the top of the file
[16:17] <zyga> and another one  slightly lower that says %patch3 ...
[16:17] <zyga> pstolowski: using a git branch, like the one I sent, is convenient
[16:17] <zyga> pstolowski: because you can then git format-patch 2.39.1..HEAD and simply copy them over
[16:18] <zyga> pstolowski: you can also tweak the spec file, so when it runs tests it will run that test only, that's somewhere around %check
[16:18] <pstolowski> zyga: good hint with git branch, thanks
[16:19] <pstolowski> zyga: ok, got test failure now as expected. good
[16:19] <zyga> pstolowski: ok, great!
[16:19] <zyga> pstolowski: if you want I can  dig around to understand what exactly is going on when osc build runs
[16:19] <zyga> pstolowski: I didn't look that deep yet
[16:23] <pstolowski> zyga: looks like a chroot in /var/tmp/build-root/openSUSE_Tumbleweed-x86_64 ?
[16:23] <zyga> pstolowski: yep, likely
[16:26]  * zyga jumps back at mount issues
[16:29] <pstolowski> will continue digging tomorrow
[16:33] <zyga> sure, thank you pstolowski|afk
[16:36] <cachio> mvo, should we merge the autopkgtests PR now?
[16:40] <mvo> cachio: I think so, we need a test too but that can be in a followup, I will do 2.39.2 with those fixes in my morning then
[16:41] <cachio> mvo, perfect
[17:23] <Chipaca> EOD here 👋
[18:21] <Pharaoh_Atem> zyga: 2.39.1 updates proposed
[18:21] <Pharaoh_Atem> F30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-3c4eec8250
[18:21] <Pharaoh_Atem> F29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-02e160af16
[18:21] <Pharaoh_Atem> EL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-91a080fd55
[19:05]  * cachio afk
[19:26] <zyga> Pharaoh_Atem: thank you
[19:40] <Pharaoh_Atem> zyga: I need testing and karma
[19:40] <Pharaoh_Atem> otherwise this update will not ship anytime soon