[14:04] <pooryorick> hi
[14:05] <pooryorick> "Configuring source routing" example says, "This enables clients on either network to connect to th other..."
[14:06] <pooryorick> but then th routes in the example don't provide for any routing between those two networks, do they_
[14:06] <pooryorick> ?
[19:15] <skeer> Howdy! I'm trying to determine how netplan processes any conf files found under /etc/netplan, since the default file begins with a '50-' I assume like in other cases, a lower numbered file might be examined/tried before the higher numbered ones. In practice though I see more specific files, being the ones actually applied. A static address/GW/nameserver over the 50- dhcp. Can anyone help me understand this?  All I've found so far
[19:15] <skeer> searching was a blurp on StackOverflow about how netplan takes into account all files.. somehow.
[21:39] <pooryorick> nobody here but us chickens


[04:42] <zer0-x> Hi, I'm installing Ubuntu Studio 14.04.3 LTS and see this error:  The following file did not match its source copy on the CD/DVD: /target/usr/lib/libkcalcore.so.4.13.3. I press Retry and it keeps showing many other libs error like that. My Installation source is an USB made with Unetbootin.
[05:09] <zer0-x>  Hi, I'm installing Ubuntu Studio 14.04.3 LTS and see this error:  The following file did not match its source copy on the CD/DVD: /target/usr/lib/libkcalcore.so.4.13.3. I press Retry and it keeps showing many other libs error like that. My Installation source is an USB made with Unetbootin.
[05:10] <cfhowlett> zer0-x, but ... did you md5sum the .iso before you made the usb?  did you md5sum the usb after you made it?
[05:13] <zer0-x> you mean to check the data to make sure that it's the same from source? I didn't, but I know how to md5sum the iso but how to md5sum the usb?
[05:13] <cfhowlett> zer0-x, always md5sum your .iso.  ALWAYS
[05:14] <cfhowlett> https://help.ubuntu.com/community/HowToMD5SUM#Check_the_CD
[05:18] <zer0-x> cfhowlett, thanks for the link
[05:18] <cfhowlett> happy2help!
[18:45] <Nardo> Ihave instaled edubuntu and my laptop d'not work more, then i decided to install other versiòn  10.04 i think.
[18:45] <cfhowlett> Nardo, unsupported.  we only support 12.04, 14.04, 15.04
[18:45] <Nardo> is posible to install the resent versions?
[18:46] <cfhowlett> Nardo, download, the .iso (I suggest 14.04 as it is long term support), make a boot usb/dvd, boot and install.
[18:47] <cfhowlett> !lts | Nardo
[18:50] <Nardo> i am  a new student of linux   my laptop has edubuntu butit is crash
[18:50] <cfhowlett> !install | Nardo
[18:51] <cfhowlett> understood.


[18:39] <studio-user596> just installed ubuntu studio 17.10 on 2009 macbook pro.  have a usb audio box and midi controller.  can't get a sound to work in anything yet.  newb.  any tips or useful sites?
[18:40] <krytarik> It may help if you told us what all you already tried.
[18:41] <studio-user596> haha.  ardour.
[18:41] <studio-user596> i had a slightly older version running live from a usb yesterday and it was all fine.
[18:41] <krytarik> I mean in the way of troubleshooting.
[18:41] <studio-user596> nothing seems to work with 17.10 so far
[18:42] <studio-user596> didnt have to do anything special yesterday.  so i guess i was wondering if there are some huge known problems with this release?
[18:42] <krytarik> No, there isn't.
[19:13] <Ins0l3nt> is there anything out there that is more beginner than demystifying jack?  the fact that i cant plug in and play right now is fuckin ridiculous.
[19:21] <OvenWerks> Ins0l3nt: try running: cd /tmp && wget http://jackaudio.org/downloads/adevices.sh && bash ./adevices.sh
[19:22] <OvenWerks> take the output and paste it to a paste site let us know the url...
[21:36] <Bear_> Hey guys, I do a bit of youtube training videos, photography, some gaming and php development.  I know there are distro's specifically for each ( desktop, server, studio, game ) but I really don't know which would be best suited.
[21:37] <Bear_> Is it difficult to install the other "preconfigured" systems that the different variants have?
[22:24] <Bear_> any feedback?
[22:35] <krytarik> Bear_: It's quite fuzzy what you describe, but at least it would seem a server install wouldn't be fitting for you.
[22:38] <Bear_> krytarik: probably because I'm fuzzy lol...  I'm a photographer, youtube tutorial creater, php coder using LAMP so it's kinda confusing which version to start with.. does that make sense?
[22:39] <Bear_> the thing thats confusing me is I realize the different flavors, like studio vs desktop have the apps/configurations already optimized.. I'm completely unsure how I would apply the studio optimizations if I installed desktop
[22:39] <Bear_> does that help?
[22:41] <krytarik> The default Ubuntu Studio install *has* a desktop - does *that* help? :P
[22:41] <Bear_> heheh yeah, of course it does, last time I touched *nix ubuntu was in version 7
[22:42] <krytarik> If you are thinking vanilla Ubuntu vs Ubuntu Studio, I'd go for the latter.
[22:43] <Bear_> @krytarik thats basically what I was wondering...  I've heard to use ubuntu, mint, elementary so I'm pretty confused.
[22:51] <Ins0l3nt> hey all. had some luck so far getting my guitar into ardour but im having a constant problem stating that my audio backend is stopping
[22:51] <Ins0l3nt> havent gotten my midi controller to do anything yet either
[22:51] <Ins0l3nt> tips?
[23:01] <Ins0l3nt> im added to the audio group, or whatever.  pasuspender just seems to piss qjackctl off.  i just wanna make some noise here.


[09:31] <BluesKaj> 'Morning folks
[12:02] <IdleOne> !find systemd
[12:02] <IdleOne> !more
[12:02] <IdleOne> @more
[16:53] <lordievader> Good evening.
[16:56] <Beldar> lordievader, 10 am here, but welcome back
[16:58] <lordievader> Beldar: Here it is 7 pm ;)
[16:58] <Beldar> cool, time to pop a cold one and chill


[11:03] <brainwash> bluesabre: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892010
[11:03] <brainwash> should this be fixed in 19.04?
[11:04] <brainwash> -> SRU
[11:04] <brainwash> it does not affect xubuntu-desktop, but xfce4
[11:05] <bluesabre> I think so
[11:06] <bluesabre> Also recently moved more things into exo-2, not released yet... that should likely resolve any more issues of that sort
[11:07] <bluesabre> Looking at the release notes, that might still be present in 19.04
[11:07] <brainwash> see https://forum.xfce.org/viewtopic.php?id=13000
[11:09] <bluesabre> I see
[11:12] <bluesabre> Unit193: I moved several things around (exo-1 -> exo-2, some things to exo-common, unversioned scripts)... do you foresee any issues with that related to packaging/package updates? https://git.xfce.org/xfce/exo/log/ (since 0.12.4)
[11:13] <bluesabre> Been hesitant to release because I figure that would annoy some packagers :)
[16:16] <Spass> something important possibly - https://forum.xfce.org/viewtopic.php?pid=52644#p52644
[19:11] <Unit193> New path so doesn't need breaks/replaces, -helpers might need a versioned dep but that's fine.  I can't really think of anything, I presume nothing external uses these.


[08:05] <fwereade> good mornings
[12:20] <fwereade> lunch, bbiab
[13:39] <mramm> Good morning fellow Juju-ers!
[13:48] <fwereade> mramm, heyhey
[17:57] <mramm> http://www.ubuntu.com/  -- 3:00 min to go


[12:57] <mok0> bigjools: you found our priorities?
[13:07] <bigjools> mok0: yes I did, thank you for doing those
[13:07] <mok0> OK, just wanted to check!
[13:08] <mok0> bigjools: we just left the "dont-care" ones blank
[13:08] <bigjools> mok0: yep, that's fine.  Only the top 10 are really relevant anyway
[13:09] <mok0> alright, good to know


[08:20] <tjaalton> bryce: I'll start uploading the input properties stuff now, starting from inputproto
[08:25] <bryce> heya tjaalton.  sounds good
[08:45] <tjaalton> hum? lp doesn't show builds other than i386 anymore?
[08:46] <tjaalton> need to wait for the proto to get in the archive first, then libxi and xserver after that
[08:58] <crevette> hello
[12:59] <tjaalton> hey
[17:46] <kees> bryce: say, can include/misc.h have MAXCLIENTS raised?
[17:46] <kees> bryce: maybe to 1024 from the current 256?
[17:47] <kees> (a friend with like 20 work spaces and lots of RAM just ran into it, and it doesn't seem to be run-time configurable)
[17:56] <pwnguin> how much extra ram will that allocate?
[18:09] <kees> pwnguin: that I don't know.
[18:10] <kees> I've opened bug 260138 for it, with upstream bug links, and proposed patches.  (they're untested, though)
[18:10] <pwnguin> i have to ask
[18:10] <pwnguin> why does nabble know so much about mailing lists?
[18:23] <pwnguin> kees: so uh. the stuff im reading says you'll need more than a simple header change?
[18:24] <pwnguin> (if you've tested the patches, that's at least a good sign)
[18:26] <kees> pwnguin: nope, I haven't tested anything -- just prepared patches based on the discussion.
[18:27] <kees> pwnguin: I have no idea what the impact would be, but I figured since I could do the other legwork, I could contribute that bit.
[18:27] <kees> honestly, if someone who know this area says "wtf? no way" that's fine too.  :)
[18:28] <pwnguin> so that bit operation macro you wrote. it operates on ints?
[18:29] <pwnguin> s/wrote/extended/
[19:04] <tjaalton> at least rhel4 has those patches
[19:04] <tjaalton> 20:52 < ajax> you trade more clients for fewer resources per client
[19:11] <bdmurray> bryce: bug 219952's recent comments don't look like an -video-ati bug right?
[19:14] <tjaalton> bdmurray: it might still be the driver. the original issue seems resolved though (no picture with livecd)
[19:15] <bdmurray> tjaalton: it's before X starts though right?
[19:16] <tjaalton> bdmurray: ah, right.. that's the kernel/usplash doing something funny
[19:16] <tjaalton> so this bug is fixed
[19:16] <bdmurray> and they should open a new bug with those screenshots?
[19:17] <tjaalton> I'd say so, yes
[19:28] <bryce> yep
[19:36] <tjaalton> bryce: I've pushed the IDP patches for xorg-server in git, and it should be ready to go. Anything to add?
[19:37] <tjaalton> after that, driver support (evdev, synaptics) and a new xinput (and/or gui support) :)
[19:43] <tjaalton> bryce: also, the "evdev keyboard model" mess is not over yet. Since it broke jp106 & ABNT2, svu and daniels thought that it would be best to force the evdev _rules_, not model, and to allow changing the model like before, and no need to force it in gnome-settings-daemon either
[19:44] <bryce> hrm
[19:44] <pwnguin> so what's the point of no return on this
[19:44] <tjaalton> the evdev rules just need to add support for jp106 & ABNT2 (and whatnot)
[19:44] <tjaalton> this is already in upstream. we just need to make sure no-one notices anything when they upgrade. it shouldn't be too hard
[19:45] <tjaalton> pwnguin: what do you mean?
[19:45] <pwnguin> i recall someone important saying that no one feature was worth holding back the whole release, but i cant recall when a feature has been tried and rolled back
[19:45] <pwnguin> i can recall a few times where a feature was pushed in and left there
[19:45] <tjaalton> we can't avoid evdev
[19:45] <tjaalton> forever..
[19:45] <jcristau> it's like the future or something
[19:46] <tjaalton> yeah, or something
[19:46] <pwnguin> im just wondering if there is such a mechanism in place
[19:47] <pwnguin> recall pulse audio troubles in hardy =/
[19:47] <tjaalton> pwnguin: it should not hold back anything.. the next alpha is due in two weeks so there's plenty of time to upload :)
[19:47] <tjaalton> well, pulse..
[19:48] <pwnguin> in the mean time, HAL is on its way out for devicekit...
[19:48] <tjaalton> looks like it'll get sorted out finally
[19:48] <tjaalton> the pulse mess that is
[19:49] <pwnguin> i get the impression that pulse would have gone faster if it had been called "audioKit"
[19:49] <pwnguin> for some reason the *Kits have a level of inevitability
[19:49] <tjaalton> apart from the jp106 & ABNT2 brokenness, the input-hotplug change has been quite smooth
[20:14] <bryce> yup
[20:15] <bryce> although, it's not solved as many issues as I'd hoped... quite clearly input X drivers for uncommon devices don't get as much attention as they need
[20:27] <pwnguin> thats why i worry about this devicekit thing
[20:28] <pwnguin> it seems like every few years everyone runs away from the complexity of properly handling the broken hardware of the world
[21:01] <tjaalton> bryce: what devices do you have in mind?
[21:08] <bryce> tjaalton: game controllers, tablets, etc.
[21:09] <jcristau> why wouldn't game controllers work with evdev?
[21:09] <pwnguin> depends on your definition of game controller
[21:09] <pwnguin> as for why it might not work, have you tried any jcristau?
[21:10] <jcristau> no
[21:10] <pwnguin> well, you're not alone
[21:10]  * jcristau <- not a gamer
[21:11] <pwnguin> heh
[21:11] <pwnguin> gamers dont use joypads on PC
[21:11] <pwnguin> they're so pedestrian
[21:12] <pwnguin> plus, there's so many of them, with different numbers of buttons and sticks and layouts
[21:14] <pwnguin> so we wind up with a few games in Ubuntu that are Designed for Xbox 360
[21:49] <bryce> it's not so much they don't work, just that there's some manual configuration needed that we could probably do a lot more cleanly
[21:50] <bryce> also there's some driver issues, like certain buttons not working, or features not working in the same modes, etc.  little stuff
[22:05] <tjaalton> hmm, my rumblepad doesn't seem to like evdev, or the other way around
[22:05] <tjaalton> (WW) Logitech Logitech RumblePad 2 USB: Don't know how to use device
[22:05] <tjaalton> but usually it's just that the fdi-files need to know about the devices (like the apple trackpads)
[22:08] <tjaalton> evdev should have the same features as mouse has, plus properties
[22:09] <tjaalton> and non-serial tablets should work OOTB
[22:09] <tjaalton> by now
[22:10] <tjaalton> evdev only has two bugs, of which one is likely fixed and the other one is asking for the moon
[22:14] <tjaalton> maybe I'll debug joysticks tomorrow then ;)
[22:22] <pwnguin> tjaalton: so protocol IV stuff is serial -- i should be making fdi rules for that?
[22:23] <tjaalton> pwnguin: serial devices can't be autodetected AIUI
[22:23] <tjaalton> you need some input from them first
[22:23] <pwnguin> heh
[22:23] <pwnguin> theres another trick
[22:23] <pwnguin> dont detect the serial
[22:23] <pwnguin> detect the laptop that should have one
[22:23] <tjaalton> that should work
[22:23] <tjaalton> could
[22:24] <pwnguin> unfortunately, the laptop team is dead
[22:28] <tjaalton> so revive it?-)
[22:28] <pwnguin> well, i kinda have
[22:29] <pwnguin> the toshiba tablet team!
[22:29] <tjaalton> btw, just matching the laptop model doesn't work. you need to match the device
[22:30] <tjaalton> and then tell it to load the driver for that device
[22:30] <pwnguin> "device"
[22:30] <tjaalton> you can't say "oh, this is toshiba FOO, load wacom" and expect it to work :)
[22:30] <tjaalton> see the output of lshal
[22:31] <tjaalton> your mouse probably has several devices
[22:32] <tjaalton> of which only one is the device that the driver can handle
[22:32] <tjaalton> the one that has info.capabilities ~= input.mouse
[22:32] <pwnguin> lshal's pretty damn long
[22:33] <pwnguin> heh
[22:33] <pwnguin> udi = '/org/freedesktop/Hal/devices/pnp_WACf004' info.capabilities = {'input', 'input.tablet', 'input.tablet.tabletPC'} (string list)
[22:33] <pwnguin> those ones
[22:33] <tjaalton> there you go
[22:33] <tjaalton> is that a serial device?
[22:33] <pwnguin> yes
[22:34] <tjaalton> sweet
[22:34] <pwnguin> two of em
[22:34] <pwnguin> err
[22:34] <tjaalton> so the wacom fdi should match the info.product of it
[22:35] <pwnguin> tjaalton: the launchpad team "Toshiba Tablet Team" should have an email you can reach random wacom tester/motu/devs at
[22:36] <tjaalton> ok
[22:48] <bdmurray> bryce: about bug 163044 if I can't recreate that is not an indication it is fixed right?
[22:49] <bryce> bdmurray: generally if you were able to reproduce the bug in some fashion, and then with current code the problem does not occur, then that's considered a verification of a fix
[22:49] <bryce> however, if you're never able to reproduce the problem, and it just works, that's not sufficient to confirm it as fixed.
[22:49] <bdmurray> bryce: okay, but I never saw the bug originally so won't comment
[22:49] <bryce> if you have identical hardware to the reporter, then *maybe* that can be considered fixed, but it'd still be good to ask the original reporter to confirm.
[22:50] <pwnguin> tjaalton: where is this wacom.fdi?
[23:17] <pwnguin> tjaalton: so I can see this wacom rules mentioned in the changelog and in the source package, but it's not in the binary...
[23:24] <pwnguin> anyone wanna confirm what i think is wrong with this patch?
[23:24] <pwnguin> +	mkdir -p debian/$(package_xorg)/usr/share/hal/fdi/policy/20thirdparty/
[23:24] <pwnguin> +	dh_install debian/10-wacom.fdi usr/share/hal/fdi/policy/20thirdparty/
[23:25] <pwnguin> +err
[23:25] <pwnguin> <-- fails


[11:43] <Mirv> ali1234: :( the xcbglintegrations is for X.org / normal OpenGL. if you build with only OpenGL ES development headers installed during the build time, that wouldn't get built. (even if it would get built, it wouldn't be used on armhf board's GLES GPUs)
[11:43] <ali1234> Mirv: i fixed it now :)
[11:43] <ali1234> currently making a snap out of the resulting package
[11:44] <Mirv> awesome :)
[11:44] <ali1234> i do still have a couple of minor problems with the package but it works with a bit of fiddling
[11:44] <ali1234> like it defaults to using xcb so you have to run with -platform eglfs
[11:45] <ali1234> and i have to symlink one of the egl libraries from whatever.so to whatever.so.2 (but that's down to the libraspberrypi stuff)
[11:45] <ali1234> would be nice to get rid of the xcb stuff entirely since it would make my snap smaller
[11:50] <ksamak> hikiko: do you know what interferes with the background transparency of the popup from "switcher" module? i'm sure there's a theme somewhere
[11:50] <ksamak> can't seem to pinpoint it though
[11:50] <ksamak> i have one custom build of compiz, that has no theme, and one packaged, and i can't seem to get the theme off.
[11:51] <ksamak> Trevinho: if you know
[11:51] <Trevinho> ksamak: you mean the unity or compiz switcher?
[11:51] <ksamak> compiz
[11:52] <Trevinho> mmh, I think there's no theme... just textures
[11:52] <ksamak> there's an option, called background color for it
[11:52] <ksamak> the bg of the popup
[11:52] <ksamak> and it doesn't have any effect when this "texture" is on
[11:52] <ksamak> and i can't seem to get rid of it.
[11:53] <ksamak> the problem is the transparency, it's not so nice for visually impaired people
[11:54] <Trevinho> ksamak: I think that there has never been written anything for that
[11:54] <Trevinho> ksamak: so you should probably patch in order to get it opaque
[11:55] <ksamak> mmm, you think it could be the entire gtk theme then?
[11:55] <ksamak> how come there's no theme when i make install it?
[11:56] <ksamak> Trevinho: cmake options are the same as .deb though
[11:57] <ksamak> i'm sure i'm missing smt...
[11:57] <Trevinho> ksamak: there's no theme. It's all hardcoded
[11:59] <ksamak> isn't there gtk windows then? i'm looking for the difference between a locally compiled project, that has no 'theme', and a .deb, on which i can't get the theme out


[00:44] <CFHowlett> http://www.unixmen.com/medibuntu-repositories-available-for-ubuntu-12-04-lts-precise-pangolin-ppa/
[02:08] <micahg> astraljava: I can do it tonight, so it should appear on tomorrow's images
[02:09] <ScottL> micahg, can you wait until tomorrow morning to update the metas?
[02:09] <micahg> ScottL: sure, no problem, just ping me when you're ready (ISO builds happen around 18:30 UTC IIRC)
[02:10] <ScottL> micahg, thanks!  i should have the seeds updated in about ten hours
[02:11] <ScottL> len-nb, knome :  i've updated the applications menu icon already
[02:11] <ScottL> but it's only been pushed to bzr
[02:12] <ScottL> len-nb, i don't have privileges yet to get to the actual repos yet, i hope to have it in the next couple of cycles though
[02:33] <len-nb> Ja we figgured that out.
[02:51] <ScottL> we still are having a preseed issue (i presume) and have talked to cjwatson and sent in my casper.log file to the bug report
[04:41] <ScottL> okay, micahg , i think i'm done with updating the seeds
[04:41] <ScottL> i did two things
[04:41] <ScottL> #1 replace -generic with -lowlatency
[04:41] <ScottL> #2 added photography apps but did it in graphics seed
[04:42] <ScottL> since we don't have tasksel or ubiquity plugin it seems that ALL seeds are being installed, so this shouldn't hurt anything
[04:42] <ScottL> (i also spoke with scottk about this and this was actually his solution)
[04:42] <ScottL> oh, i also did these in two separate bzr commits
[05:05] <micahg> ScottL: thanks, is there a bug that needs closing for these changes?
[05:12] <micahg> ScottL: I wouldn't remove the -generic kernel unless you're committed to following each main kernel upload with one for lowlatency
[05:13] <micahg> it's one thing to have it in the archive, it's another to make it default
[05:13] <micahg> ScottL: also, we should chat tomorrow about how you can do a package security audit so you know if your packageset is supportable
[05:16] <micahg> ScottL: also, do you have any other KDE packages, digikam will pull in a lot of KDE dependencies
[08:57] <astraljava> micahg: I see you agreed on it with Scott, which is excellent. Thanks a bunch!
[08:57] <micahg> astraljava: well, it's under discussion, we'll get it uploaded later today
[08:58] <astraljava> Sure, WorksForMe™
[13:18] <shnatsel> hmm, I like pantheon even on ubuntu
[13:42] <ScottL> micahg, our plan has been to use the -lowlatency kernel as default
[13:43] <ScottL> micahg, although since it seems to be TheMuso who is currently  rebasing (at least for the short term if not longer) we should get his input
[13:44] <ScottL> micahg, the blueprint lists getting it into a git repo and then me learning how to rebase for kernel changes/security updates
[13:44] <ScottL>
[13:45] <ScottL> micahg, yes, i would like to discuss security audit on our packageset
[13:45] <ScottL>
[13:46] <ScottL> micahg, hmmm, digikam is not a "must have" application at this point, i was really only trying to make a user from the mailing list happy
[13:46] <ScottL> micahg, i would rather not include digikam then if it pulls in the kde libraries, i'll adjust the seeds in a few hours
[13:47] <ScottL>
[13:47] <ScottL> shnatsel, ping
[13:47] <knome> hey ScottL :)
[13:47] <shnatsel> ScottL: pong
[13:47] <ScottL> good morning knome
[13:47] <knome> good evening! :)
[13:47] <ScottL> shnatsel, heh, you responded too quickly :P  let me get a link for you to look at, i'd like your opinion on some applications
[13:48] <ScottL> shnatsel, http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.precise/revision/1313
[13:49] <ScottL> shnatsel, starting at line 25 i have included what i could for photography applications
[13:49] <ScottL> shnatsel, is there something you would add/change/remove?
[13:50] <shnatsel> ScottL: well, screw shotwell in the first place. It's no way professional, and it's not needed when you have darktable already.
[13:51] <shnatsel> ScottL: not sure about rawtherapee, Luminance HDR may be better
[13:53] <shnatsel> ScottL: well, I was told Luminance HDR is better, but I've never worked with it tbh
[13:53] <shnatsel> neither of them
[13:53] <ScottL> i have thought about moving shotwell to the desktop seed for general purpose picture gallery stuff
[13:54] <knome> ScottL, is it similar to ristretto?
[13:54] <ScottL> i included rawtherapee because someone on the mailing list talked about it with some praise
[13:54] <shnatsel> ScottL: well, looks like you'll just have to get somebody try both :)
[13:54] <ScottL> knome, i don't think so, it's more of a photo gallery type of application i believe, let's you group them, tag them, and i believe it lets you upload to places
[13:54] <knome> aha, right
[13:54] <knome> :)
[13:55] <ScottL> shnatsel, hehe, yeah...just not me, i'm lucky to actually take pictures with my canon t2i
[13:55] <ScottL> although i do want to start playing around will adjusting colour in my photos
[15:36] <len> ScottL, Digikam does look like it does a lot of stuff. I'm not arguing for it to be included at this point...
[15:37] <len> But, I am thinking that we do not have people who use photographic software giving much feedback because while we target these people we don't know what they need.
[15:38] <len> I would sugest that we would include something like gcdmaster even if it brought the extra libs in just because it feels needed.
[15:39] <len> It may make sense in starting to support more than just audio to add more apps and not less just to atract the right kind of people.
[15:40] <len> Maybe if people start using US for a graphics we will get some who will want to be active in development too.
[15:41] <len> s/graphics/graphics platform/
[15:41] <kubotu> len meant: "Maybe if people start using US for a graphics platform we will get some who will want to be active in development too."
[15:44] <len>
[15:46] <len> ScottL, all that aside, thankyou for grouping the photography apps in the graphics seed.
[15:47] <len> I will test for menu placement today when the new iso comes out (seeds seem to happen faster) and make sure things show up  where they should.
[15:48] <len> I notice there are somethings in the photography section that are commented out because they are already included above.
[15:48] <len> Should those things appear in both menus?
[15:51] <ScottL> len, the .desktop file provides the categories for where an app will display in the menu
[15:52] <ScottL> you can always force it in the menu directory file, but that's not elegant of course
[15:52] <ScottL> and tedious
[16:17] <len> The photography apps normally have graphics as a category as well. I have found many .desktop files do not do what they should. For example almost none of the mixer.desktop files include the mixer category. and have to be put there menually.
[16:21] <len> ScottL there has been some suggestion both in the list and here that in the case where an app is used in more than one place it would make sense for it to appear in more than one menu place as well.
[16:22] <len> For example gimp is graphics because it belongs there, but it also would get used for fixing photographs and would not be out of place in the photography menu as well.
[16:23] <len> I don't want to just do a bunch of those kinds of changes though and it seems your feeling is not.
[16:24] <len> As for being tedious, in my mind the idea is for the programer or in our case packager to do the tedious work so the user has a better use experience.
[16:25] <len> The programer/packager only has to do it once, the user has to deal with it daily.
[16:26] <falktx> ScottL: you ping'd me yesterday, but I had to left with internet down. can you describe what is still needed to be done?
[16:26] <falktx> (hi there everyone)
[16:28] <len> Hi falktx, it looks like lots of stuff to test this afternoon (for me anyway) new kernel (yahoo!) and new apps.
[16:29] <falktx> new apps?
[16:29] <len> Scott has added some photography apps to the seeds
[16:29] <falktx> oh cool
[16:29] <falktx> btw, 12.04 now has wine1.4 which doesn't support jack-audio anymore
[16:30] <falktx> I created come content on the wine sound wiki for this - http://wiki.winehq.org/Sound?rev=50
[16:30] <falktx> some wine dev didn't liked it and deleted my stuff... :(
[16:30] <falktx> can someone put this on the ubuntustudio wiki?
[16:30] <len> Probably the two main things we need to look at are jack having RT out of the box and PA-jack bridging.
[16:30] <knome> falktx, why don't you add it yourself
[16:31] <falktx> knome: need to create account first
[16:31] <knome> falktx, you can log in with LP account
[16:32] <falktx> ah, and I though my work today was done...
[16:32] <knome> welcome to FOSS contributing ;)
[16:44] <len> Ack, I just figured out there was a time change last night... gotta run.
[16:46] <knome> ScottL, working on sun?
[16:50] <scott-work> aye, a bit, but i'm also going to spend a little time on ubuntu studio
[16:51] <scott-work> knome: i have trouble on weekends at the house trying to do creative, abstract thinking when everyone is in the house
[16:51] <scott-work> knome: so i'm doing a little bit of work, then i'm removing myself downstairs to a meeting room where i can write on the dry erase board, walk around the room in circles, talk to myself, and gesticulate with my hands as i talk
[16:52] <scott-work> i find that helps me think :)
[16:52] <scott-work> knome: specifically, i want to work on the slideshow concepts/text which should couple with the information needed for the website tour pages
[16:52] <scott-work> which loosely will be based on our strongest work flows
[16:52] <scott-work>
[16:53] <scott-work> micahg: i'm sorry, i don't think i ever answered your direct question....no, i don't think there is a bug number to reference for the lowlatency or photography seeds, just blueprints from UDS
[16:54] <knome> scott-work, heh, sounds good. :)
[16:58] <scott-work> knome: i'm feeling energized again about development, not sure why or what changed and is the catalyst
[16:58] <scott-work> but i really want to get some things done before the end of this cycle
[16:58] <scott-work> ..
[16:59] <knome> scott-work, yeah, too bad we're past all the freezes
[16:59] <scott-work> oh, general statement to the channel, i emailed quadrispro about mudita24 and the .desktop file as it looked like git had changed but the changes weren't pushed to release
[16:59] <scott-work> he said he did it now, so hopefully it's not too late and we can file a sync request and get this updated so we have it in the menus now :)
[17:00]  * scott-work is going downstairs  for a bit, i'll check back in in about thirty minutes
[17:01] <knome> see you :)
[18:25] <scott-work> well, time ot go home
[23:41] <len-nb> There is no daily ISO today... did the build fail?
[23:50] <micahg> ScottL: I still have my question about whether the lowlatency kernel should replace the generic one
[23:58] <len-nb> micahg, Scott did answer, did you miss the answer? or is it still inconclusive? I can quote that part of the irc log if you missed it.
[23:59] <len-nb> If you need more input... I can't help


[03:00] <mup> PR snapcraft#2408 closed: multipass: avoid stdin where possible <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2408>
[06:08] <mborzecki> morning
[07:14] <mborzecki> mvo: morning
[07:19] <mvo> hey mborzecki - good morning
[07:34] <zyga> Hey
[07:34] <zyga> Oh boy, winter is coming
[07:36] <zyga> mborzecki: RHEL 8 has very recent kernel
[07:37] <mborzecki> zyga: and a very far relase date :)
[07:57] <zyga> What is the release date?
[08:00] <mborzecki> zyga: when it's ready
[08:00] <mborzecki> zyga: i don't think they've annouced anything yet
[08:00] <zyga> Mmm
[08:03] <pstolowski> morning
[08:05] <mborzecki> pstolowski: hey hey
[08:10] <mborzecki> 2.36 branch is failing all the time
[08:10] <mborzecki> the travis job
[08:13] <mborzecki> google:opensuse-42.3-64:tests/main/interfaces-openvswitch-support is failing, i'd be surprised if it's https://bugzilla.opensuse.org/show_bug.cgi?id=1115168
[08:29] <mup> PR snapd#6152 closed: spdx: update licenses to current data <⛔ Blocked> <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6152>
[08:30] <mborzecki> there's something messed up with our opensuse-42.3 images, they are not 43.2 but leap 15.0, https://paste.ubuntu.com/p/ZYFc8Rkjq4/
[08:31] <mborzecki> i guess cachio is the only one who can fix it?
[08:33] <mvo> mborzecki: yeah, I think so - we can set opensuse to manual though to unblock us
[08:36] <pedronis> mvo: hi, I closed the spdx PR for now, it needs some more thoughts, we also need to check what we did about licenses in our oldest releases out (debian? 16.04 active images?)
[08:36] <mup> PR snapd#6163 opened: interfaces: tweak deny-auto-connect policy tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/6163>
[08:36] <mvo> pedronis: yeah, thats fine
[08:36] <mvo> pedronis: I agree this needs more work
[08:38] <pedronis> mvo: the personal/system-files PR needs a jdstrand re-review, right?  I haven't really done a review myself yet, just gone over some bits, also sorry, not sure if I put some comments at the wrong place, or the code changed under them
[08:38] <mvo> pedronis: your comments were useful, I addressed them now
[08:39] <mvo> pedronis: yeah, jdstrand should look at this again, I added the allow-install: false now
[08:39] <pedronis> yes, saw that
[08:39] <pedronis> thanks
[08:41] <pedronis> zyga: mvo: I saw we put some bug cards (with landed PR) in the Done column, shouldn't they go in the cur release column?
[08:41] <mvo> pedronis: I think so, this may require a 2.36 colum now that we have backported some of the bugfixes
[08:42] <pedronis> or a backport label
[08:42] <pedronis> but yes
[08:42] <mvo> pedronis: yeah, or that :)
[08:44] <pedronis> mvo: were they backported already?
[08:44] <mvo> pedronis: yes, let me double check but yes, we pulled into 3 PRs into 2.36 yesterday
[08:45] <pedronis> one doesn't have a card
[08:45] <pedronis> (it's ok)
[08:45] <pedronis> mvo: yet, another approach is indeed two columns, and copy the cards
[08:47] <mvo> pedronis: or we put the card just in 2.36 and assume that whatever bugfix we did there automatically is also in all higher versions (which is generally true because we always cherry-pick from master)
[08:47] <pedronis> yes, that's usually the case
[08:47] <pedronis> let's try that
[08:47] <mvo> great
[08:48] <pedronis> mvo: does it look right now?
[08:53] <mvo> pedronis: yeah - looks good, I would switch the order 2.36 and 2.37 (so that its from lower to higher) but thats a) nitpick b) personal preference
[09:00] <zyga> pedronis: re, I think you may be right, let me re-read the trello rules post
[09:01] <zyga> pedronis: thank you for moving them to the appropriate lanes
[09:03] <pedronis> zyga: I'm not sure the rules explain the done lanes
[09:03] <pedronis> I can add that
[09:08] <zyga> tumblweed moved to 4.19
[09:08] <pedronis> mvo: zyga: I added a para about the done lanes into the rules
[09:08] <pedronis> hope it makes sense (I hope it makes a bit also without reading them tough)
[09:16] <pstolowski> zyga: i've just did snap run --shell gnome-calculator and got this:
[09:17] <pstolowski> https://www.irccloud.com/pastebin/TVwffLQo/
[09:17] <pstolowski> zyga: expected?
[09:17] <zyga> nope
[09:17] <zyga> some of those are bugs in the theme
[09:17] <zyga> that are quite unexpected since they were reported months ago
[09:17] <zyga> but the last few are certainly unexpected
[09:17] <zyga> is this on master?
[09:18] <pstolowski> zyga: i'm on edge, 2.36.1+git1017.fdb9926~ubuntu16.04.1
[09:18] <zyga> thank you, I will check this out
[09:19] <zyga> "fun" (not)
[09:19] <pstolowski> zyga: gnome stuff is from stable
[09:19] <mborzecki> pstolowski: https://forum.snapcraft.io/t/gtk-common-themes-bind-mount-sources-are-symlinks-missing-sounds/8540/1
[09:19] <zyga> pstolowski: can you file the bug about /snap/
[09:20] <pstolowski> zyga: sure
[09:20] <mborzecki> $SNAP/share/sounds is missing entirely, and Saru icon theme is a symlink
[09:20] <zyga> rebooting and jumping into this
[09:21] <mborzecki> pstolowski: there's a github issue as well https://github.com/snapcrafters/gtk-common-themes/issues/16 can you add it to the topic?
[09:23] <zyga> oho
[09:23] <zyga> 4.19 is not working too great with snaps
[09:23] <mborzecki> zyga: 4.19.1-arch1-1-ARCH, didn't notice anything special, what does not work in your setup?
[09:24] <zyga> type=AVC msg=audit(1542360228.183:306): apparmor="DENIED" operation="mkdir" profile="/usr/lib/snapd/snap-confine" name="/tmp/snapd.quirks_fAGbSk/" pid=4922 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
[09:24] <zyga> zyga@yantra:~> snap run gnome-calculator
[09:24] <zyga> cannot create temporary directory for /var/lib/snapd mount point: Permission denied
[09:24] <mborzecki> hm, profile update?
[09:24] <pedronis> is that the kernel really? or selinux?
[09:25] <pedronis> zyga: also if it's hairy can you take a note and look more later?
[09:25] <zyga> pedronis: sure
[09:25] <zyga> I wonder if this is because I have been hacking on this machine
[09:25] <zyga> probably so, let me just reinstall the package
[09:25] <zyga> pedronis: on suse there's just apparmor, no selinux
[09:25] <pedronis> ok
[09:26] <zyga> yes :)
[09:26] <zyga> uff
[09:26] <zyga> I didn't have the permission to do quirks because I was hacking on quirks removal here
[09:26] <zyga> all is good
[09:26] <zyga> looking at the theme issue
[09:30] <Chipaca> pedronis: morning. Do I understand correctly that you think having the 0 epoch (or rather, anything that serialises back to "0") deserialise to unset is the best approach?
[09:30] <Chipaca> pedronis: (I think I agree, but wanted to confirm before implementing it -- in the same pr?)
[09:30] <pstolowski> zyga: not sure if i described it correctly, but here you go: https://bugs.launchpad.net/snapd/+bug/1803687
[09:30] <mup> Bug #1803687: snap run --shell gnome-calculator gives a series of errors <snapd:New> <https://launchpad.net/bugs/1803687>
[09:31] <pedronis> Chipaca: yes, if we basically say internal unset [09:31] <pedronis> Chipaca: can be a follow up tough
[09:31] <pedronis> that PR is around since a while
[09:32] <pedronis> (relatively speaking, is not ancient in snapd PR terms)
[09:32] <Chipaca> pedronis: 8 days old, if you count the original homonymous pr, yes
[09:33] <Chipaca> pedronis: anything else I should do on this one and not the followup?
[09:38] <pedronis> Chipaca: you are asking because it's green ? :)
[09:40] <pedronis> Chipaca: there's the amend test revision to change, it's ok for a follow up if it doesn't get lost
[09:41] <zyga> thank you pawel
[09:43] <zyga> reproduced
[09:44] <pstolowski> great!
[09:47] <pedronis> mvo: do we have a edge build now for https://bugs.launchpad.net/tillamook/+bug/1802581 ?
[09:47] <pedronis> to announce
[09:47] <zyga> pedronis: I believe so, I can test on my device quicklyl
[09:48] <Chipaca> pedronis: was asking because the tests were green, and it's got a 'changes requested' from you :-)
[09:48] <zyga> refreshing to edge, i'll know in 3 minutes
[09:48] <mvo> pedronis: yeah, build 5h ago and landed last night but if its not trouble for zyga to double check lets wait for that first
[09:48] <pedronis> yes, that's fine
[09:51] <zyga> rebooting pi3-1
[09:53] <zyga> testing now
[09:54] <zyga> confirmed
[09:54] <zyga> edge allows to disable and enable the snap that previously reproduced the issue
[09:56] <zyga> mvo, pedronis: +1
[10:02] <pedronis> mvo: zyga: I'm writing something in the bug
[10:02] <zyga> thank you
[10:03] <pedronis> done
[10:05] <pedronis> Chipaca: I wrote what we discussed yesterday about restart SNAP etc here: https://bugs.launchpad.net/snapd/+bug/1803212
[10:05] <mup> Bug #1803212: snap restart starts disabled services <snapd:New> <https://launchpad.net/bugs/1803212>
[10:05] <mborzecki> zyga: if you have a rhel instance, can you `yum --enablerepo=epel-testing install snapd` and report feedback here https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b240f3418f ?
[10:06] <zyga> mborzecki: I don't have one handy now
[10:06] <zyga> mborzecki: actually, maybe I'm wrong
[10:06] <zyga> one sec
[10:06] <zyga> nope
[10:06] <zyga> I think I killed it
[10:08] <mborzecki> ah ok, nvm, i've given +1, snapd installs and runs on 7.6
[10:11] <pedronis> Chipaca: I have a remark, it seems all the store tests use either "0" or nil, no test with something a bit more interesting
[10:11] <pedronis> in epoch
[10:11] <pedronis> I also don't know if the change we plan affects that
[10:12] <Chipaca> pedronis: there is one snap.E("1*") in the store tests (for the amend case)
[10:13] <pedronis> Chipaca: yes, but nothing for context
[10:13] <Chipaca> hmmm
[10:13] <Chipaca> i'll see how things change with this
[10:13] <pedronis> I made a remark
[10:14] <zyga> pstolowski: ah
[10:14] <zyga> pstolowski: I think it's not terrible
[10:14] <zyga> I was worried this is a regression
[10:14] <zyga> I improved logging of trespassing events
[10:15] <pedronis> Chipaca: gave a +1 assuming you'll work through my wonderings :)
[10:15] <pedronis> in the follow up
[10:15] <Chipaca> mbuahaha
[10:15] <Chipaca> i mean, "yes of course"
[10:15] <Chipaca> :-p
[10:15] <zyga> pstolowski: quick question, was it failing to start in your case?
[10:15] <zyga> for me it starts ok
[10:15] <zyga> (as in, runs)
[10:16] <zyga> https://www.irccloud.com/pastebin/lBeg5CYb/
[10:16] <pstolowski> zyga: no, no, it worked (i used --shell)
[10:16] <zyga> look at line 1
[10:16] <zyga> this is really telling us this
[10:16] <zyga> the snap gnome-calculator
[10:17] <zyga> was trying to write to /snap/gtk-common-themes/808/share/sounds/Yaru
[10:17] <zyga> and that was refused
[10:17] <zyga> it was trying to write there because of a content connection
[10:17] <zyga> that's the "remote" end
[10:17] <zyga> but it is absent (not really in the snap)
[10:17] <zyga> so the code tried to make it
[10:17] <zyga> but it wasn't allowed to
[10:17] <zyga> that's all
[10:17] <zyga> interesting
[10:18] <zyga> I mean, we could allow writes to /snap/*/ except for /snap/bin
[10:18] <zyga> but I really think this is a bug in the desktop themes snap
[10:18] <zyga> I don't quite understand what is the thing going on there
[10:19] <zyga> I mean
[10:19] <zyga> it's totally bogus
[10:20] <zyga> sound themes exposed by gtk-common-themes https://www.irccloud.com/pastebin/1T1cK5k0/
[10:20] <zyga> the share/sounds directory is not even in the snap!
[10:20] <mup> PR snapd#6142 closed: overlord/snapstate, store: always send epochs <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6142>
[10:21] <zyga> kenvandine: ^ should we escalate that, it feels like stable version of gtk-common-themes is missing files
[10:22] <mborzecki> zyga: https://forum.snapcraft.io/t/gtk-common-themes-bind-mount-sources-are-symlinks-missing-sounds/8540 heh
[10:22] <zyga> heh, thank you for reporting this maciek
[10:22] <mborzecki> pinged popey and kenvandine there ;)
[10:22] <zyga> with enough eyeballs :)
[10:23] <zyga> wat
[10:24] <zyga> the snap is on gnome gitlab
[10:25] <zyga> k, done
[10:25] <zyga> good :)
[10:25] <zyga> back to features
[10:27] <pstolowski> zyga: i see, good :)
[10:29] <pstolowski> zyga, mborzecki thanks for reporting it
[10:32] <mborzecki> zyga: can we do a HO about mounts & rhel/centos? wanted to discuss something
[10:32] <zyga> sure
[10:32] <zyga> let me join
[10:33] <zyga> can we "meet" instead?
[10:33] <zyga> https://meet.google.com/sri-fdeu-yur?authuser=0
[10:33] <zyga> just had this open now
[10:34] <pstolowski> zyga: is there anything new re mount issue that's also reported here https://bugs.launchpad.net/snapd/+bug/1772016 ?
[10:34] <mup> Bug #1772016: Mount snap "snapcraft" (1591) ([start snap-snapcraft-1591.mount] failed with exit status 1: <snapd:Triaged> <https://launchpad.net/bugs/1772016>
[10:34] <zyga> pstolowski: I'll check after the call with mborzecki
[10:38] <pstolowski> Chipaca: was https://bugs.launchpad.net/snapd/+bug/1767445 fixed already in snapd?
[10:38] <mup> Bug #1767445: Uninstalled snaps show most recent channel version, not version to be installed by default <amd64> <apport-bug> <bionic> <verification-done> <verification-done-bionic> <verification-done-xenial> <snapd:New> <Snap Store:New> <gnome-software (Ubuntu):Fix Released> <gnome-software
[10:38] <mup> (Ubuntu Xenial):Fix Released> <gnome-software (Ubuntu Bionic):Fix Released> <gnome-software (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1767445>
[10:39]  * Chipaca looks
[10:39] <mup> PR snapd#6164 opened: wrappers: rename the desktop file to their apps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6164>
[10:40] <Chipaca> pstolowski: no, there was nothing to fix in the current api
[10:40] <Chipaca> bah
[10:41] <Chipaca> pstolowski: yeah, that
[10:41] <pstolowski> Chipaca: can be closed in snapd then? or it's for the future?
[10:43] <Chipaca> pstolowski: I mean, as described in the attached forum post, snapd could workaround things, but it's mostly up to the store to return the most stablest revision or not, there
[10:44] <Chipaca> pstolowski: i'd go with a "Won't fix" on snapd side though, with the rationale that (a) look in the channel map if you want to know what you'll get in stable, and (b) store can change what's returned outside the channel map, which we'd forward on
[10:45] <pstolowski> Chipaca: allright, thanks, it wasn't clear where the things are since that topic is 5 months old
[10:46] <zyga> pstolowski: looking
[10:47] <zyga> ah
[10:47] <zyga> this is the issue we know about
[10:47] <zyga> it's bound to be fixed this cycle
[10:49] <pstolowski> pedronis: what do you think about adding a pre-remove script? one of the bug reports request that we have a remove hook that runs before stop-snap-services, not after. we kina expected this when remove hook was introduced, but just wanted feedback and people actually starting to use hooks
[10:49] <pstolowski> zyga: great, thanks for updating it
[10:50] <zyga> kjackal: hello
[10:50] <zyga> kjackal: do you have a moment to talk about microk8
[10:50] <pedronis> pstolowski: can you point me to the actual bug?
[10:50] <kjackal> hi zyga, yes go ahead
[10:50] <kjackal> whats up?
[10:50] <zyga> I'm looking at https://bugs.launchpad.net/snapd/+bug/1802332
[10:50] <zyga> and I'd like to reproduce it locally
[10:50] <mup> Bug #1802332: Apparmor complains in strict confinement with base: core18  <snapd:Incomplete by zyga> <https://launchpad.net/bugs/1802332>
[10:50] <zyga> is the snap something you built locally or can I get it somewhere?
[10:50] <pstolowski> pedronis: https://bugs.launchpad.net/snapd/+bug/1777121
[10:50] <mup> Bug #1777121: Remove is called after snap services are stopped  <snapd:Triaged> <https://launchpad.net/bugs/1777121>
[10:51] <pedronis> pstolowski: thanks, I'll put in my queue of things to look at
[10:51] <kjackal> the snap is patched, let me find the branch
[10:51] <zyga> kjackal: can you send me the snap please
[10:51] <zyga> perhaps via wormhole :)
[10:52] <pedronis> zyga: what's the status of per-user mounts?  wating o reviews?
[10:52] <kjackal> Ah it is on the ticket https://github.com/ubuntu/microk8s/tree/feature/strict
[10:52] <zyga> pedronis: yes, I really need to land the current set
[10:52] <kjackal> zyga: ^
[10:52] <zyga> pedronis: it's bound with several dependencies but it should all be landable
[10:52] <zyga> kjackal: so I just need to take that snap, build it, and run it?
[10:52] <kjackal> yes
[10:53] <kjackal> zyga: for building the snap I went to snapcraft, version 3.0+git13.g04f18f5
[10:54] <zyga> kjackal: let me try, I'll bug you if I cannot get it somehow
[10:55] <kjackal> thank you
[10:56] <pedronis> zyga: do nag people for reviews a bit :) , given I'm sprinting next week I will not dive into that
[10:57] <zyga> pedronis: ay ay sir!
[10:57] <zyga> mborzecki: could you do a 2nd review on https://github.com/snapcore/snapd/pull/6145
[10:57] <zyga> that's the first one to go in
[10:57] <mup> PR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
[11:14] <zyga> mvo: or you perhaps? ^
[11:14] <zyga> this unclogs the pipe :)
[11:33] <mup> PR snapd#6165 opened: cmd/snap-update-ns: extra debugging of trespassing events <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6165>
[11:40] <mup> PR snapd#6157 closed: userd: force zenity width if the text displayed is long <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6157>
[11:40]  * Chipaca afk for a bit
[11:44] <zyga> hmm
[11:44] <zyga> where does snapcraft 3.0 drop built snaps?
[11:46] <mborzecki> zyga: pwd?
[11:46] <mborzecki> cwd
[11:46] <zyga> nope :)
[11:46] <zyga> not for me
[11:46] <zyga> I forked microk8s and built it with snapcraft and multipass
[11:47] <zyga> no snaps found
[11:49] <zyga> I'll clean and try again
[11:49] <zyga> but ... wtf
[11:49] <zyga> no errors or anything
[11:53] <zyga> sergiusens:
[11:53] <zyga> sergiusens: halp
[11:53] <zyga> snapcraft 3.0
[11:54] <zyga> build works for a while
[11:54] <zyga> then nothing
[11:54] <zyga> error code 0
[11:54] <zyga> last messages are:
[11:54] <zyga> https://www.irccloud.com/pastebin/V8knVrdk/
[11:58] <zyga> oh boy :)
[11:59] <zyga> I need snapcraft, not snapcraft build
[11:59]  * zyga facepalms
[12:07] <cachio> mvo, hey
[12:07] <cachio> https://paste.ubuntu.com/p/CwM7k7ntvW/
[12:10] <sergiusens> zyga: help no longer required I assume?
[12:10] <zyga> yes :)
[12:10] <zyga> sergiusens: my only comment would be to auto-match the number of cores in qemu to the cores on the host
[12:10] <zyga> 6 core machine had 4 cores idle
[12:11] <zyga> it matters in the last step (compression)
[12:11] <mborzecki> cachio: hey, we have a problem with opensuse-42.3 images, they are in fact leap 15.0 images
[12:11] <mvo> cachio: hm, hm, is it connected? I assume so
[12:11] <sergiusens> zyga: oh, you can do that manually, but we were killing the machines because you need to also assign around at least 1G of RAM per core
[12:11] <mborzecki> cachio: that's why 2.36 branch is failing on travis
[12:12] <cachio> mborzecki, checking
[12:12] <sergiusens> zyga: it was the original design, moved away from it after some testing and agreements with Saviq
[12:12] <zyga> 1G ram per core? why
[12:12] <mborzecki> cachio: https://paste.ubuntu.com/p/ZYFc8Rkjq4/ this was on release/2.36 branch
[12:13] <sergiusens> zyga: SNAPCRAFT_BUILD_ENVIRONMENT_CPU=8 SNAPCRAFT_BUILD_ENVIRONMENT_MEMORY=8G snapcraft (for a fresh project)
[12:14] <sergiusens> given that 8 is the most common amount of RAM out there (I have one of those configurations) and that I usually barely manage to have 2G of free RAM I thought this conservative approach would be best for the wider audience
[12:16] <cachio> mborzecki, it seems that the last automatic update did it
[12:17] <mborzecki> cachio: can you fix it?
[12:18] <cachio> mborzecki, yes
[12:18] <cachio> I am on that
[12:18] <mborzecki> cachio: thank you!
[12:19] <cachio> mborzecki, np
[12:19] <cachio> mvo, yes, it is connected
[12:32] <zyga> simple review for https://github.com/snapcore/snapd/pull/6165
[12:32] <mup> PR #6165: cmd/snap-update-ns: extra debugging of trespassing events <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6165>
[12:34] <ogra> jdstrand, i see some very weird behaviour with the kvm interface ... when i switch qemu-virgil into --devmode i all of a sudden get "qemu-system-x86_64: failed to initialize KVM: Operation not permitted" ... switching back to --jailmode makes it work again
[12:35] <cachio> mborzecki, I am creating the new image
[12:35] <ogra> (nothing is printed in journalctl when that happens)
[12:36] <mborzecki> cachio: did the automatic update tool pick the wrong name the last time?
[12:36] <cachio> mborzecki, the change was caused because opoensuse project changed hte default image from 42.3 to 15
[12:36] <cachio> and we build based on that
[12:36] <cachio> mborzecki, I just changed to point to a specific 42.3 image
[12:40] <mup> PR snapd#6165 closed: cmd/snap-update-ns: extra debugging of trespassing events <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6165>
[12:40] <zyga> thank you :)
[12:43] <pstolowski> #6100 needs 2nd review
[12:43] <mup> PR #6100: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>
[12:43] <pstolowski> and has nice PR number ;)
[12:45] <zyga>  haha, nice
[12:45] <zyga> looking
[12:46] <mup> PR snapcraft#2407 closed: build providers: preset the timezone <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2407>
[12:46] <cachio> mvo, this is interesting https://paste.ubuntu.com/p/Fx48q9phRR/
[12:50] <Saviq> zyga: https://bugs.launchpad.net/snapcraft/+bug/1795666
[12:50] <Saviq> and https://github.com/CanonicalLtd/multipass/issues/420
[12:50] <jdstrand> ogra: that is weird. when you go to --devmode, is that an remove/install --devmode or something else?
[12:51] <jdstrand> s/an/a/
[12:51] <zyga> Saviq: using 4 cores on a 2 core system is certainly wrong
[12:51] <ogra> jdstrand, a refresh
[12:51] <zyga> Saviq: not sure about using 6 cores on a 6 core system
[12:51] <zyga> also not sure how ram relates
[12:51] <zyga> is there really a kvm correlation between ram and cores?
[12:52] <jdstrand> ogra: I suspect it would work right with a remove/install. I bet something isn't right with the device cgroup when refreshing to devmode. that probably deserves a forum topic
[12:52] <ogra> jdstrand, with qemu-virgil normally installed i did "sudo snap refresh qemu-virgil --edge --devmode" and "sudo snap refresh qemu-virgil --stable --devmode"
[13:04] <pedronis> jdstrand: hi, is re-reviewing #5845 in your queue?
[13:06] <pedronis> pstolowski: I left some comments in the hotplug-disconnect PR, we probably need to be a bit more careful about conflicts there
[13:07] <pstolowski> pedronis: yep, just noticed, thanks!
[13:08]  * pstolowski lunch
[13:15] <cachio> mborzecki, new opensuse image ready
[13:16] <cachio> mvo, snapd[30158]: task.go:303: DEBUG: 2018-11-16T11:53:56Z INFO snap "test-snapd-sh" has bad plugs or slots: personal-files (cannot add personal-files plug: "$HOME" must start with "
[13:16] <cachio> I see this error too
[13:17] <mborzecki> cachio: thanks, let me restart the travis jobs and see if it's ok now
[13:18] <zyga> hum hum
[13:18] <zyga> I need to run an errand now
[13:18] <zyga> I may miss the standup
[13:22] <cachio> mborzecki, nice, sorry about that issue but this leap image is not under our control
[13:22] <cachio> mborzecki, I'll see if I can create a copy to our project and then use it
[13:22] <mborzecki> cachio: so you mean it's some other project that's changed the image?
[13:23] <cachio> mborzecki, yes
[13:23] <mborzecki> cachio: yeah, copy sounds like a good idea
[13:23] <cachio> mborzecki, for some oss I get the images from other projects
[13:24] <cachio> i.e. opensuse, debian, etc
[13:28] <mvo> cachio: interessting error, I look at it
[13:31] <cachio> INFO snap "test-snapd-sh" has bad plugs or slots: personal-files (cannot add personal-files plug: "$HOME" must start with "$HOME")
[13:31] <cachio> this is the full message
[13:33] <zyga> https://github.com/snapcore/snapd/pull/6150 is the next branch in the chain
[13:56] <kenvandine> zyga: the Suru symlink issue is fixed in a Yaru PR by jamesh, I think
[13:58] <kenvandine> zyga: indeed the sounds are missing
[14:02] <mvo> zyga: standup?
[14:07] <zyga> kenvandine: and the sound theme issue?
[14:08] <kenvandine> zyga: working on it
[14:08] <zyga> I cannot join
[14:08] <zyga> mvo: sorry, cannot join
[14:09] <mvo> zyga: ok
[14:12] <zyga> My update is short, bug fixes and nagging for reviews
[14:13] <zyga> Call with Maciej about mount issues
[14:13] <zyga> No new bugs so happy
[14:13] <zyga> Working on tests
[14:13] <zyga> Master very flaky with testing
[14:13] <zyga> On 1000 cuts of random stuff breaking
[14:13] <zyga> mvo: ^
[14:14] <zyga> Cannot wait for 2.36.1 to be released
[14:19] <pstolowski> popey: hey, i asked you in some of your old bug reports to re-check if the problems can still be reproduced, hope you don't mind
[14:19] <popey> I got the mails :)
[14:21] <pstolowski> popey: good. i expected this :)
[14:29] <ogra> jdstrand_, if you wouldnt mind ... https://dashboard.snapcraft.io/snaps/opencv-demo-ogra/revisions/19/
[14:30] <Saviq> zyga: that's not really "cores" though - it's CPU threads, so with HT, that's what snapcraft was doing originally
[14:31] <Saviq> it was matching the number of threads available on the host, but without a sane amount of memory for each core
[14:31] <Saviq> so I recommended $threads * 1GB
[14:32] <Saviq> still, with the cgroup approach we want to apply we might reduce that limit since it will be obvious what happened
[14:32] <Saviq> without it things just get stuck, OOM never kicked in
[14:33] <cachio> mvo, https://paste.ubuntu.com/p/cr2cbCtDHN/
[14:34] <cachio> also failing with $HOME/
[14:34] <cachio> both things are conflicting
[14:34] <mvo> cachio: interessting
[14:47] <mvo> mborzecki: http://paste.ubuntu.com/p/3yfgGjqXGY/
[14:47] <mvo> mborzecki: that was my attempt to reproduce using plain mount
[14:48] <mborzecki> mvo: thanks, i'll extend it with mount units and daemon-reload like we talked about
[14:49] <mborzecki> mvo: i recall there were some concerns about daemon-reload in the context of packaging and post install tasks
[14:54] <mborzecki> cachio: mvo: release/2.36 branch finally green
[14:54] <mvo> mborzecki: awesome
[14:56] <Son_Goku> mborzecki, can you please CC me on https://bugzilla.redhat.com/show_bug.cgi?id=1650582
[14:57] <Son_Goku> I can't see the bug report otherwise
[14:57] <mborzecki> Son_Goku: done
[14:58] <Chipaca> pedronis: https://forum.snapcraft.io/t/snapctl-status/8313/7?u=chipaca fwiw
[14:59] <Son_Goku> mborzecki, thanks
[14:59] <cachio> mborzecki, :)
[14:59] <mborzecki> Son_Goku: the good news is that rhel8 looks fine
[14:59] <Son_Goku> I'm not surprised
[15:00] <mborzecki> Son_Goku: as you said before, alt kernels on ppc64el and aarch64 are probably fine too
[15:00] <Son_Goku> yeah
[15:00] <Son_Goku> those on rhel7 are based on 4.14 kernel
[15:02]  * Chipaca goes afk for a another bit
[15:22] <cachio> mvo,  personal-files test working in case I don't specify $HOME
[15:23] <cachio> it is the only scenario where it failed
[15:31] <kenvandine> zyga: the sound theme issue is fixed in candidate
[15:37] <kenvandine> sparkiegeek: i'd like to promote gtk-common-themes to stable today
[15:37] <kenvandine> sparkiegeek: any concerns with the store?
[15:40] <roadmr> kenvandine: the store seems happy, I think you could go ahead. However, the earlier the better for us; in case things get wobbly, it's easier for us to handle when some in the store team still have most of the day ahead
[15:41] <roadmr> kenvandine: which revision(s) are you planning on promoting? the ones currently on candidate?
[15:41] <kenvandine> 818
[15:41] <kenvandine> currently on candidate
[15:41] <kenvandine> just need to finish a round of testing
[15:41] <roadmr> awesome
[15:42]  * cachio lunch
[16:07] <mvo> 6156 is ready for a review now
[16:43] <roadmr> kenvandine: hey a question, gtk-common-themes is *not* baked/shipped preinstalled on Ubuntu images, is it? (I see it's not on 18.04, maybe it is on 18.10?)
[16:44] <kenvandine> it is
[16:44] <kenvandine> also in 18.04
[16:44] <kenvandine> there are snaps that use it which pulls it in
[16:44] <kenvandine> all the seeded snaps in 18.04 use it
[16:45] <kenvandine> roadmr: i'm really close to being ready to release it to stable
[16:45] <roadmr> kenvandine: hm, I don't see it on a fresh 18.04, but I'm using the live cd image
[16:45] <roadmr> kenvandine: awesome
[16:45] <kenvandine> ah, it wasn't on the actual iso
[16:45] <kenvandine> but everyone that installed 18.04 has gotten it installed since
[16:46] <kenvandine> as the seeded snaps now mount content from it
[16:46] <roadmr> kenvandine: yes, that's the question; because if so, I need to generate the deltas from whichever version is shipped in the ISO to the one you're about to release
[16:47] <roadmr> kenvandine: but if it was never shipped on an iso then I don't need to do anything special; just let me know when it gets released so I can keep an eye on our metrics
[16:47] <roadmr> when you release the new version, one of two things can happen:
[16:47] <kenvandine> it was on the 18.10 iso
[16:47] <roadmr> people who had the previous stable will get a delta (the store auto-generates these, yay)
[16:47] <roadmr> and people who didn't have it get a full download anyway
[16:48] <roadmr> kenvandine: oh! 18.10, then I should totally generate the delta. Do you by chance know which revision shipped with 18.10? fine if not, I can find out but it'll take me a few mins
[16:48] <kenvandine> actually it would have also been on the 18.04.1 iso
[16:48] <kenvandine> i do not know which revision
[16:49] <roadmr> kenvandine: ok, not a problem, I can find all that out
[16:49] <kenvandine> roadmr: i'm release to release it to stable, should i wait a few?
[16:49] <roadmr> kenvandine: and while it's better to pre-generate the deltas, I can also gen them post-facto which is not a huge setback
[16:51] <roadmr> kenvandine: if you're ready to release let's go ahead with tht
[16:51] <kenvandine> roadmr: cool, releasing now
[16:52] <roadmr> woohooo!
[16:52] <roadmr> kenvandine: btw many thanks for giving us a heads-up, it allows us to be on the lookout for issues and provide a better experience to end users
[16:53] <kenvandine> roadmr: no problem
[16:53] <kenvandine> roadmr: done
[16:53] <roadmr> yay :)
[17:34] <roadmr> kenvandine: we found the revisions that shipped with 18.04.1 (319) and 18.10 (701) and built deltas from those to the one you just released. This way, people booting from those images will get a nice small delta
[17:57] <jdstrand_> ogra: sure
[18:06] <kenvandine> roadmr: awesome
[18:30] <mvo> cachio: could you please look at 5845? the new tests are failing it seems
[18:39] <cachio> mvo, sure
[18:50] <cachio> mvo, I fixed the issue for personal-files
[18:50] <cachio> I am testing it
[18:50] <cachio> the errors on system-files seem to be real
[18:51] <cachio> I manually tested and the snap cannot see under the dir /tmp/.testdir1
[18:51] <mvo> cachio: thanks, well, could be because of /tmp being special, can you test if its also an issue with non-tmp?
[18:52] <cachio> mvo, sure
[23:40] <AuroraAvenue> e-what is the cli-instrn to install (pop) prnce of persia?


[10:19] <infinity> mdz : Nah, just 30 minutes ago, from whatever airport he was in, he'd mentioned his surprise at the lack of fallout from the switch. :)
[10:20] <mdz> it only landed yesterday; most of the world didn't upgrade until today
[10:20] <mdz> and still more haven't rebooted yet
[10:21] <mdz> amd64 is blocked by gnome-applets and gnome-app-install
[10:21] <infinity> I rebooted pretty well instantly, out of fear that I'd have to get involved in some messy recovery.
[10:21] <mdz> (at top level)
[10:21] <infinity> And, oddly, I didn't.
[10:22] <mdz> gnome-app-install I traced earlier to python-gnome2-extras, which just needed to be built
[10:22] <infinity> mdz : Yup, I tracked that one down, too.
[10:22] <infinity> The other direction is the hal problem.
[10:22] <mdz> it doesn't seem to have a recent attempt
[10:22] <mdz> http://people.ubuntu.com/~lamont/buildLogs/g/gnome-python-extras/2.11.4-0ubuntu2/
[10:23] <mdz> the last one was a dpkg segfault

[10:23] <infinity> Requeued already.
[10:30] <mvo> mdz: I have a apt upload pending (send you a mail about it some days ago, a small bugfix in the dpkg<->apt communication). can I do that now is it inconvenient now (because of the buildd situation)?
[10:31] <infinity> The buildd situation isn't much of a situation.  i386 will normalise in a few hours and it'll be like nothing happened.
[10:32] <infinity> (Until I wake up tomorrow and do a mass give-back to catch everything that may have been screwed by the dpkg segv...)
[10:33] <infinity> Right, that's why I need the new hal built.
[10:33] <mdz> mvo: gnome-app-install-data just failed to install on amd64 for me
[10:33] <mvo> mdz: yes, the fix is uploaded but not yet build
[10:34] <mvo> mdz: it fails only on a upgrade, right? not for a new install
[10:34] <infinity> mdz, pitti : The old hal refers to libdbus-1.la, so building against it fails, the new hal will be built against the new dbus and fix that.  gnome-python-extras won't build until we have it.
[10:34] <mdz> dpkg: error processing /var/cache/apt/archives/gnome-app-install-data_0+20050809_all.deb (--unpack):
[10:34] <mdz>  trying to overwrite `/usr/share/gnome-app-install/Mozilla.desktop', which is also in package gnome-app-install
[10:34] <mdz> dpkg-deb: subprocess paste killed by signal (Broken pipe)
[10:34] <mdz> mvo: ok
[10:35] <mvo> mdz: ok for g-a-i or ok for the apt upload?
[10:35] <mdz> mvo: g-a-i
[10:36] <mdz> mvo: I cannot deal with apt or anything else until this situation is fixed
[10:37] <mdz> our priority at the moment is working CDs
[10:37] <{Seb}> i've got a few niggles with breezy and i don't know if they are known bugs
[10:38] <{Seb}> first - i had to remove /usr/bin/X11 and symlink it to /usr/bin to get X to start
[10:38] <mdz> pitti: I'm getting my amd64 upgraded so that I can look at hal; have you had any luck with it?
[10:38] <pitti> mdz: I'm on it
[10:38] <pitti> mdz: but its a bit tricky
[10:38] <mdz> what the hell
[10:38] <{Seb}> second - gnome-app-install is broken
[10:38] <mdz> locales is generating EVERY locale
[10:38] <pitti> needs some time, but I'll solve it
[10:39] <{Seb}> and i had to force install gnome-app-install-data
[10:39] <{Seb}> are these known bugs or should i file them in bugzilla?
[10:39] <mvo> mdz: well, the upload is ready. but if you want to have a look first it can certainly wait. it contains only small (but importent) fixes
[10:39] <mvo> {Seb}: it's a known bug, the fix is uploaded but not yet in the archive
[10:39] <{Seb}> which ones?
[10:39] <mdz> {Seb}: gnome-app-install is known; it has already been discussed here several times today
[10:39] <mdz> {Seb}: for X, search bugzilla and report only if it is not there already
[10:40] <{Seb}> also, my scroll wheel won't work
[10:40] <{Seb}> i'll search
[10:40] <{Seb}> breezy is look absoutly great
[10:40] <ogra> pitti, something about BLKGETSIZE64 ?
[10:40] <mdz> infinity: what's broken on the gnome-applets size?
[10:40] <pitti> ogra: no, something entirely different, it just appears to be so
[10:40] <mdz> s/size/side/
[10:40] <pitti> YAY, hal builds!!!
[10:40] <ogra> hooray...
[10:41] <pitti> with a 178 KB patch..
[10:41] <pitti> anyway, I'll throw it at the buildds to have something working, and I'll sort that out with upstream to find the real solution
[10:42] <mdz> pitti: 178kb?
[10:42] <pitti> mdz: upstream does weird things with datatypes, so I needed a find/sed to replace them all
[10:42] <pitti> mdz: and I need to regenerate configure
[10:42] <mdz> so 8k search/replace, 170k configure ;-)
[10:43] <pitti> mdz: no, about 120 KB search/replace
[10:43] <infinity> mdz : Out of date, waiting on new hal.
[10:43] <mdz> wow
[10:43] <infinity> mdz : So, both paths lead to hal.
[10:43] <pitti> mdz: it's not a good patch, and not the final one, but I'll test it on some arches now and upload to have a quick solutuon
[10:43] <mdz> pitti: ok
[10:46] <pitti> wow, hal even works
[11:00] <pitti> mdz, infinity: hal_0.5.3-0ubuntu3_source.changes ACCEPTED
[11:00] <mdz> pitti: good timing for :03
[11:00] <pitti> hehe :)
[11:04] <pitti> awstats   | 6.3-1ubuntu0.1     | source               | 4 hours old
[11:05] <mdz> pitti: is the firewall stuff landing or no?
[11:05] <mdz> I need to know whether I need to implement the contingency for ltsp
[11:06] <pitti> mdz: I asked carstenh about useful subsets, but most certainly not
[11:06] <mdz> damn
[11:06] <pitti> mdz: he doesn't even have packages yet
[11:06] <ogra> SoC started way to late
[11:06] <infinity> i386 buildds are coming back. One's here.
[11:06] <mdz> pitti: please set it to deferred
[11:06] <pitti> so not until tomorrow, but even this wouldn't yield much useful
[11:06] <pitti> mdz: ok
[11:07] <mdz> infinity: is hal building?
[11:07] <infinity> Still not registered in wanna-build.  Give cron.daily some breathing room.
[11:07] <pitti> mdz: oh, it's not even in the table yet
[11:08] <mdz> pitti: add it to the deferred table
[11:08] <mdz> seb128: how is launchpadintegration?
[11:09] <seb128> mdz: ~25/30 apps patched
[11:10] <mdz> seb128: is there a list somewhere?
[11:10] <seb128> I'll update the wiki
[11:10] <seb128> a min
[11:11] <doko> one ooo2 build did finish ...
[11:11] <mdz> mvo: findingpackages is bust, I guess?
[11:12] <infinity> Oh, hey php4 finally got shoved to universe.
[11:12] <pitti>       php4 | 4:4.3.10-15ubuntu2 | http://archive.ubuntu.com breezy/universe Packages
[11:12] <pitti>       php4 | 4:4.3.10-15ubuntu2 | http://archive.ubuntu.com breezy/main Sources
[11:12] <pitti> well, almost...
[11:12] <mdz> Someone else saved this page while you were editing! Please review the page and save then. Do not save this page as it is! Have a look at the diff of BreezyGoals to see what has been changed.
[11:12] <infinity> mdz : Can I sync php4 with Debian, and upload php-imap (which builds php4-imap and php5-imap) to universe?
[11:12] <mdz> who ignored my lock?
[11:12] <pitti> mdz: I just added Firewalls, but I didn't get a lock...
[11:13] <infinity> pitti : The binries all got shoved to universe...
[11:13] <mvo> mdz: FindingPackages gnome-app-install is in, but nautilus/mozilla integration is not done yet
[11:13] <mdz> pitti: I made several edits, so I'm clobbering your changes
[11:13] <pitti> mdz: I was told that I had the lock, sorry
[11:13] <infinity> pitti : Not sure why the source didn't move.
[11:14] <pitti> mdz: I fix it
[11:14] <mdz> pitti: thanks
[11:15] <mdz> infinity: packages moving between components is an entirely manual process
[11:15] <mdz> infinity: send me email with the details
[11:16] <mdz> (re: php)
[11:16] <pitti> mdz: odd, how can this happen? race condition?
[11:16] <seb128> mdz: https://wiki.ubuntu.com/LaunchpadIntegration
[11:16] <ogra> infinity, btw, edubuntu has only hp5 deps let, i git them all sorted, so php4 could go completely to universe
[11:16] <ogra> s/hp5/php5
[11:17] <mdz> pitti: it is easy to overlook the message; are you sure it did not warn you?
[11:17] <ogra> s/let/lefzt
[11:17] <ogra> grmpf
[11:17] <ajmitch> morning
[11:17] <infinity> ogra : Excellent.  If edubuntu needs any php5 extensions we don't have packaged, you need to let me know, and ask mdz for permission to let me upload them. :)
[11:18] <pitti> mdz: I remember having read the usual "you have locked 10 minutes" sign, but given my current mental state I could be wrong; nevermind for now
[11:19] <Kamion> mdz: the dpkg segfault does appear to be present in hoary too, looking at the code
[11:19] <ogra> infinity, oki... but i'm fine for now...
[11:20] <Kamion> mdz: however, it really is quite a corner case, so I'm not that worried about it; we only ran into it because of very odd packaging
[11:20] <pitti> Kamion: so it won't break the usual langpack use case?
[11:20] <Kamion> mdz: you need to have something doing an unversioned Replaces on a package that's still active in the distribution, which is not a usual thing to do
[11:21] <Kamion> pitti: hmm
[11:21] <Kamion> you do have an unversioned Replaces there ...
[11:21] <pitti> Kamion: I guess if the fix is easy we should update, but it's not super urgent, right?
[11:21] <pitti> Kamion: I can't update langpacks before rosetta export is working anyway
[11:21] <seb128> mdz: gnome-python-extras build failed again ... nautilus-cd-burner 0ubuntu2 needs to be built first and then gnome-python-extras
[11:21] <infinity> seb128 : On it already, don't worry.
[11:22] <seb128> mdz: due to dbus.la changes
[11:22] <seb128> daniels insisted to drop them
[11:22] <Kamion> pitti: now you mention it, it looks to me as if it ought to break, but then I'm amazed it hasn't broken lots already
[11:22] <pitti> Kamion: we didn't actually update hoary langpacks yet (ENOROSETTA)
[11:23] <Kamion> pitti: yes, but that dpkg change happened some time before release
[11:23] <Kamion> and before the last language pack upload for hoary
[11:23] <Kamion> so, if it were going to happen I'd've thought we'd see it then
[11:23] <Kamion> perhaps the circular Depends and bidirectional Replaces manage to insulate us from it
[11:24] <Kamion> the fix is trivial, anyway, and I can probably prove that it doesn't break anything that wasn't already broken ;)
[11:25] <pitti> sounds like a "5 free minutes to fix it" case for hoary-updates, then?
[11:26] <pitti> haha, SuSE replaces mozilla in all stable releases to 1.7...
[11:27] <infinity> Vindication!
[11:28] <Kamion> pitti: probably, if the stress-test-by-buildd goes well
[11:28] <_d4vid> hi all
[11:31] <doko> Mithrandir: -10 is built on i386
[11:35] <pitti> infinity, mdz: hal built on amd64
[11:36] <infinity> pitti : I know, I've been babysitting it.
[11:42] <infinity> Argh, I hate my laptop crashing every day.
[11:47] <pitti> mdz: btw, I tried to get the ffox crash on i386 by incrementally upgrading everything to the latest version, no luck
[11:47] <Kamion> mdz: I assume removing l-r-m-2.6.10 from breezy is fine?
[11:54] <pitti> night everybody!
[11:55] <paolo> Goodnight pitti
[11:58] <doko> Kamion: something wrong with the new lrm upload?


[18:51] <Ahmuck> is there a way to chroot wine?
[22:12] <stlsaint> Ahmuck: not that i am aware of
[22:17] <Ahmuck> found some articles on 64bit in ubuntu for chroot wine.  looking to see if possible with 32 bit
[22:19] <stlsaint> oh i have never done it myself