[03:32] <thebeav> Does Ubuntu Studio 15.04 not include VeSTige support in LMMS? Just did a fresh install and the VeSTige icon is missing.
[03:33] <thebeav> (64 bit)
[03:35] <cfhowlett> thebeav, you mean VST plugins?  yes they're supported
[03:37] <sinewav> 64-bit Vestige is broken.
[03:37] <sinewav> Only 32-bit works.
[03:37] <thebeav> cfhowlett: How can I use them then if VeSTige isn't there?
[03:38] <thebeav> sinewav: Does that mean I need to install a 32 bit version of LMMS?
[03:38] <cfhowlett> thebeav, I've not used lmms enough to advise.  suggest you consult #opensourcemusicians
[03:39] <thebeav> cfhowlett: Thank you.
[03:39] <sinewav> Yes, Vestige only works in 32-bit LMMS, though I have heard that some people can use the 64-bit Windows version of lmms in wine and use VST plugins. Weird, eh?
[03:41] <sinewav> I haven't tried it myself because I don't often use LMMS, but I know only 32-bit Vestige works.
[03:42] <sinewav> It's a huge bummer.
[03:43] <thebeav> sinewav: Okay so it sounds like I'll need to install the 32 bit version of lmms. Is there an easy way to do that in Ubuntu Studio? Command line or Software Center would be fine.
[03:45] <sinewav> You are running 64bit Ubuntu Studio?
[03:47] <thebeav> sinewav: Yes.
[03:48] <thebeav> sinewav: fesh install
[03:48] <thebeav> 15.04
[03:50] <sinewav> yeah... that's a problem. You see, the problem is, you need 32-bit WINE libraries to use Vestige, specifically 32-bit DSSI. And you can't use those on a 64-bit install. The only way is to use 32-bit Ubuntu Studio. (Well, maybe there is a way, but I've never seen it.)\
[03:50] <sinewav> I went through this whole thing about a year ago an just gave up.
[03:51] <sinewav> I started using KXStudio's repros so I could use "FesTige" which is a 64-bi wrapper for VST pluggins, but even that was unstable, so I just use Windows for audio, mostly. :/
[03:52] <sinewav> Sorry, I don't mean to discourage you.
[03:54] <thebeav> I wonder then if it'd be simpler to just re-install Ubutnu Studio and use the 32 bit version? If that's the only problem.
[03:55] <sinewav> If your computer is sufficiently fast enough, using a 32-bit OS is fine. Eventually Linux audio will catch up. They are about a decade behind Win/Mac.
[03:56] <sinewav> My last computer was 32-bit and I did a lot of nice music with GNU/FOSS Audio, specifically using LMMS, Muse, and Ardour.
[03:58] <thebeav> sinewav: Thanks for the help. I think I'm gonna try my best to get it working on Linux somehow. Maybe even give that Festige software a look and see if they've improved the stability any since you tried it.
[09:51] <cfhowlett> May I see your identification, please?  http://fabianff.deviantart.com/art/Ubuntu-Studio-ID-84008463
[10:10] <zequence> I got to get one of those
[10:10] <cfhowlett> yeah, he did one for all the distros before the redesign came along.
[10:10] <cfhowlett> http://fabianff.deviantart.com/gallery/
[18:57] <csahens> Anyone here producing podcasts with UbuntuStudio?
[18:59] <csahens> Quiet room, lol
[19:04] <sunstar> nope but i have made a shoutcast station with wine+winamp
[19:06] <csahens> Shoutcast...what's that?
[19:06] <Unit193> Why not just icecast2+darkice/mixxx/etc?
[19:08] <csahens> My main problem with podcasting on Linux, at least until I figure it out, is how to record Skype calls at a decent bitrate. The only Skype recorder I've found for Linux only records wavs at 16kps, whereas I perfer to record in at leaast 44.1k.
[19:10] <sunstar> depending on your setup, VLC should be able to record
[19:23] <csahens> VLC?
[19:23] <csahens> that's interesting
[19:23] <csahens> I'd never considered using VLC. ou can record Skype calls with that?
[19:53] <csahens> Are there an Linux apps that could record Skype calls where one side of the conversation is panned hard left and the other side of the conversation is panned hard right for seperate editing? It's not a deal breaker or anything, but it's nice to be able to edit out some of the stuff in the background.
[19:59] <holstein> csahens: yes
[19:59] <holstein> though, i would try mumble, if you dont need video.. or, ask skype what tools they suggest
[19:59] <holstein> otherwise, you can just do that. .pan hard right and left, and route into whatever you are recording with.. in JACK for example
[20:00] <csahens> I don't need video, so that's not an issue. I found a Skype recorder, but it records wavs at a lower bit rate than I'd like. I'm looking to record at at least 44.1k.
[20:00] <holstein> sure
[20:00] <holstein> nothing here is preventing that..
[20:00] <holstein> if its a wav, its likely 44.1.. if its not, i would try it, and see if it meets your needs
[20:01] <holstein> mumble has/had a jack client.. where, each client has an ouput in jack..
[20:01] <csahens> Awesome. That really has been my number one issue on fully transitioning to Linux.
[20:01] <holstein> otherwise, you would run jack, then, using the pulse to jack bridge, you pan as you say, and route the right channel from pulse to a track in youd daw, and the left to anothher
[20:02] <holstein> well, just keep in mind, nothing in linux is preventing that
[20:02] <holstein> it would be ideal if skype, or example, supported jack.. and gave you separate output to jack.. right from skype
[20:03] <holstein> and, the tool they provide is likely keeping up with the audio quality you are getting over the network
[20:03] <csahens> I didn't really think so, but there aren't nearly as many resources about podcasting in Linux than for PC or Mac, so I wasn't really sure where I'd look...lol
[20:03] <holstein> you can also, just have each person record locally. the old "double ender" trick.. thats the way we used to do it, regardles
[20:03] <holstein> csahens: really?
[20:04] <holstein> csahens: i think the issue is, there are no commercial entities selling you a work flow, such as podcasting, on linux
[20:04] <holstein> csahens: i use ardour, and record what i like, to whatever format i want.. have for years.. worked well for podcasting, etc
[20:05] <holstein> one nice/easy trick to *really* step the quality up, regardless of OS.. record high quality locally, use something like dropbox to share the files.. then, one person can record the entire VOIP call output, and easliy line up the seperated, local, high quality files
[20:06] <csahens> We were doing it like that initially
[20:06] <holstein> that could be *many* different os's.. and formats.. one person just bringing the different high quality flies together
[20:06] <holstein> csahens: thats the "best" way to do it
[20:06] <csahens> But with 4 hosts, the editing just got crazy
[20:06] <holstein> csahens: the network is a bottle-neck for the quality, no matter what OS you are using..
[20:07] <holstein> we did the import, of all the parts.. *then*, its literally the same editing as before
[20:07] <holstein> say, you want to edit transitions.. you'll edit them, no matter hown many high quality wav files you import
[20:07] <csahens> That's true if you can get all of your hosts to practice proper mic technique...lol
[20:07] <holstein> csahens: we prepped before sending.. but still, you dont add any editing to the work flow
[20:08] <holstein> i mean, if you go in and manually adjust fader, thats likely overkill, anyways
[20:08] <csahens> I'm talking about editing out distractions in the background and things like that.
[20:08] <csahens> Or, one of m co-hosts has a problem with smacking his lips, so I edit out that as well.
[20:09] <holstein> sure
[20:09] <holstein> thats your choice, though
[20:09] <holstein> you can have him take them out before
[20:09] <holstein> or, just leave it. nothing we are talking about addresses that
[20:09] <csahens> That' true.
[20:10] <holstein> he's smacking his lips, and you choose to address that.. in windows, or whatever
[20:10] <csahens> Yes
[20:10] <csahens> I'm just saying that I don't just record, add music, export, and upload as some podcasters do
[20:10] <csahens> But you're right, those are issues for me regardless of OS
[20:11] <holstein> sure.. and im just saying, you pull in 2 tracks, and edit out the transitions.. its the same work, if you pull in 8 tracks
[20:11] <csahens> Editing two tracks is a mental thing for me.
[20:11] <holstein> if you are addressing individual issues in those source tracks, thats a different story, and something you can address.. but, not any different in any OS
[20:12] <holstein> csahens: in ardour, you edit out the spaces in *all* the tracks..
[20:12] <holstein> you would pull in, say, 8 hosts worth.. line up the tracks for timing to the master track.. and start editing. the same cuts and edit points no matter how many hosts
[20:12] <csahens> Yeah, like I said, it's a mental thing for me...I'm a lot less anal about what to edit when I have fewer tracks to edit.
[20:13] <holstein> csahens: you'll have as many tracks as hosts
[20:13] <csahens> The more tracks I have, the more likely I'm going to sit there and try to edit out every little sound that isn't talking.
[20:13] <holstein> csahens: *nothing* gives you less tracks.. its a track per host you are implemting
[20:13] <csahens> That or I suppose I could use a gate
[20:13] <holstein> *or*, ask the hosts to do it
[20:13] <holstein> or leave it in
[20:13] <csahens> Yeah
[20:13] <holstein> or gate the entire stereo track
[20:14] <csahens> I'm just so used to working with Audition...lol It looks like Ardour is pretty close to that than say, Audacity.
[20:14] <holstein> work with what you like, though
[20:15] <holstein> i mean, no DAW is really going to do this any easier.. or much differeint
[20:15] <holstein> different*
[20:15] <csahens> That's a fair point.
[20:15] <holstein> you'll still, ideally, have a track per host, and you'll be editing out whatever you want to cut.. and, gating, or whatever you want to do to deal with background noice
[20:15] <holstein> noise*
[20:15] <holstein> audacity is a great tool.. mostly, a stereo track editor..
[20:16] <holstein> ardour is a complete DAW.. it really depends on your needs..
[20:16] <csahens> As long as I can record a skype call, that's really all I *need* at this point and you've addressed that. So I need to play around with some of these tools to get it working like I want.
[20:16] <holstein> yup.. skype can go through pulse.. into jack
[20:17] <holstein> or, ideally, they would supply separate outputs per user in jack
[20:17] <holstein> thats what was implemented to mumble.. jack support
[20:17] <holstein> i wouldnt expect that in skype..
[20:17] <csahens> OH! So mumble is a VoIP client like Skype?
[20:18] <holstein> csahens: well, *all* of these things are what they are
[20:18] <holstein> i dont even think of it as constructive to think about what they are trying to replace..
[20:18] <holstein> i dont think its a goal of mumble to replace skype.. but, it does have a nice latency. it was made more for gaming groups
[20:18] <holstein> easy to setup, and control one's own server.. completely open.. etc..
[20:19] <holstein> it just had a way to record output per host
[20:19] <holstein> but, the editing process is still the same.. the only step that saved me was, importing the seperate files
[20:19] <holstein> and, the quality was literally like being in the same room.. so, i decided it wasnt worth the hassle
[20:20] <csahens> Interesting. Looks like I have a lot of options here.
[20:20] <holstein> its not really saving me any time to record the hosts, live, to seperate channels.. its not saving anything but, import and lining up. and its a hit in quality
[20:21] <holstein> now, when they record local, its sounds *just* like im in that room.. so, thats what i go for, since, tracking it live, VIA the voip call doest ease anything
[20:21] <holstein> doesnt*
[20:21] <csahens> yeah
[20:21] <holstein> i know, they were talking about this on the linux action show LUP show
[20:22] <holstein> personally, ive never minded that a call in show sounds like folks calling in and talking
[20:22] <holstein> background noise, as long as things are audible.. i never mind that..
[20:22] <holstein> network sounding audio, though.. i like to avoid that..
[20:22] <csahens> That's true...I suppose as podcast producers we care more about our audio than a lot of the listeners do...lol
[20:22] <holstein> bad network connection, i should say..
[20:23] <holstein> csahens: sure.. but, we, again, are *not* talking about the audio  quality
[20:23] <holstein> csahens: im suggesting recording it locally gets the *best* audio quality.. and it does. better than over the network
[20:23] <csahens> And I agree with you.
[20:23] <holstein> what you are talking about is background environmental noises.. that, are recorded at a high quality.. just arguably unwanted
[20:23] <csahens> Yes
[20:24] <holstein> if you want to remove them, then, sure.. a gate is an option.. or, just teaching the hosts how to better record..
[20:24] <holstein> quieter spaces.. etc
[20:24] <csahens> Yup
[20:24] <holstein> theres not really a piece of software to address that.. in any OS.. other than potentially the gate idea..
[20:24] <holstein> which, wont hurt at all to try..
[20:25] <csahens> Yup. Anyway, thanks for your help. I'm going to set up the mic and do some testing!
[20:25] <holstein> csahens: cheers.. and, let us know how it goest
[20:26] <csahens> will do
[20:26] <holstein> csahens: check out #opensourcemusicians if its slow here..


[00:04] <Unit193> I used to.
[00:08] <jrgifford> thafreak: i might do it for one of my throw-away domains.
[00:36] <jrgifford> yano: so you run the ##weather-us*
[00:36] <jrgifford> stuff right?
[01:01] <Unit193> Yes he does.
[01:01] <Unit193> https://github.com/myano/jenni
[01:01] <jenni> [ myano/jenni · GitHub ] - http://j.mp/efOomq
[01:03] <jrgifford> Unit193: oh, cool!
[01:04] <jrgifford> yano: OHMYWAT. you created lmddgtfy?
[01:04] <jrgifford> hi5.
[01:24] <Unit193> But we don't have a storm, wxbot is mean!
[01:26] <yano> jrgifford: yes
[01:26] <yano> jrgifford: i didn't create it, but i run it
[01:26] <yano> i forked it from mikejs
[01:26] <yano> on github
[01:26] <yano> he lost lmddgtfy.com
[01:26] <yano> so i bought lmddgtfy.net
[01:28] <jrgifford> ah
[01:29] <yano> and just started running his code
[01:30] <jrgifford> fantastic.
[01:30] <jrgifford> i'll need to find some bitcoin for oyu
[01:30] <jrgifford> because i use that a lot.
[01:30] <yano> hehe \o/
[01:30] <yano> awesome!
[01:31] <jrgifford> (well, i send it to people)
[01:31] <yano> did you know there is a !lmddgtfy bang?
[01:31] <yano> .ddg !lmddgtfy this is an example
[01:31] <jenni> yano: http://lmddgtfy.net/?q=this%20is%20an%20example
[01:31] <jrgifford> now that is fantastic.
[01:31] <yano> that's what i love about jenni, i can generate lmddgtfy URLs for people
[01:31] <yano> and i don't have to bother with the URL encoding
[01:31]  * Unit193 uses google. :P
[01:32] <jrgifford> i use the !b and !g a lot
[01:32] <jrgifford> but most of the time ddg just finds it.
[01:32] <jrgifford> (!b more than !g)
[01:32] <Unit193> Yeah, I won't use Bing, and ddg never can find anything I'm looking for.
[01:33] <yano> you aren't paranoid enough :-P
[01:33] <jrgifford> you have to learn to think like the duck
[01:33] <yano> I use http://3g2upl4pq6kufc4m.onion/
[01:33] <yano> which is DuckDuckGo
[01:33] <yano> and if i can't find something there i then go to https://startpage.com/
[01:33] <Unit193> I'm randomly paraniod about things. :P
[01:33] <jenni> [ Startpage Web Search ] - http://j.mp/1cga0bE
[01:33] <jrgifford> Dax really is a nice guy, once you get to know him.
[01:33] <jrgifford> (dax = the mascot)
[01:34] <yano> oh drats, i thought you meant the IRC nick dax
[01:34] <yano> i know dax on freenode
[01:34] <jrgifford> oh, i don't know dax on freenode.
[01:34] <jrgifford> I do know the duck though.
[01:34] <jrgifford> i ask him all sorts of questions.
[01:34] <yano> hehe
[01:34] <jrgifford> you should be able to go to duckduckgo.com/programming
[01:34] <jrgifford> and you can talk to him
[01:34] <yano> :o
[01:35] <jrgifford> https://en.wikipedia.org/wiki/Rubber_duck_debugging
[01:35] <jenni> [ Rubber duck debugging - Wikipedia, the free encyclopedia ] - http://j.mp/OEhl8P
[01:35] <jrgifford> i mean, http://www.rubberduckdebugging.com/ is nice, but yeah.
[01:35] <jenni> [ Rubber Duck Debugging ] - http://j.mp/1cgakav
[01:35] <yano> hehe
[01:36] <jrgifford> anyone want a dozen rubber duckies? $13.50 on amazon!
[01:36] <jrgifford> i might buy those for the office.
[01:36] <jrgifford> http://www.amazon.com/Rubber-Duckie-Shower-Birthday-Favors/dp/B000V26AO2/ref=sr_1_1?ie=UTF8&qid=1372124157&sr=8-1&keywords=rubber+duck
[01:36] <jenni> [ Amazon.com: One Dozen (12) Rubber Duck Ducky Duckie Baby Shower Birthday Party Favors: Toys & Games ] - http://j.mp/1cgauyr
[01:36] <jrgifford> ah, ninjas! http://www.amazon.com/One-Dozen-Ninja-Rubber-Duckys/dp/B000VQBQ1K/ref=sr_1_16?ie=UTF8&qid=1372124157&sr=8-16&keywords=rubber+duck
[01:36] <jenni> [ Amazon.com: One Dozen (12) ~ Ninja Rubber Duckys: Toys & Games ] - http://j.mp/1cgav5J
[01:37] <yano> haha
[01:37] <yano> also, is it evil if I use Linux Mint? :3
[01:37] <yano> it's ubuntu-like
[01:37] <jrgifford> debian edition or otherwise?
[01:37] <yano> the straight up Linux Mint
[01:37] <yano> not the debian Linux Mint
[01:37] <jrgifford> because if its debian edition, i'm ok with it. if it's the ubuntu based version, well, we've got some problems... ;)
[01:38] <yano> hah
[01:38] <yano> i switched to it from Debian stable on my work machine, so I could easily install/play Steam games after hours
[01:38] <yano> since Lint Mint had multi-arch before Debian testing did
[01:38] <jrgifford> cool. :)
[01:38] <yano> and at the time i wanted to avoid ubuntu because it was still too main stream, lol
[01:38]  * yano takes off the hipster glasses
[01:39] <yano> :-p
[01:39] <jrgifford> it's funny, at work we're almost a 50/50 split between mac and windows
[01:39] <jrgifford> and the only reason it isn't straight cut & dry is because of the 4 linux users.
[01:39] <jrgifford> 3 of which are on my team. :P
[01:40] <jrgifford> and out of that, we have a 50/50 split between ubuntu and fedora
[01:40] <jrgifford> (ok, i know rhel isn't fedora, but close enough)
[01:41] <Unit193> Go Suse, annoy all! :D
[01:41] <jrgifford> ugh, ew.
[01:41] <Unit193> See?  It works!
[01:41] <jrgifford> i tried, couldn't get my postgresql to work.
[01:41] <jrgifford> like, i wanted to, but nope.
[01:41] <yano> lol
[01:41] <yano> my boss and i use linux at work
[01:41] <jrgifford> if i have to spend more than 15 minutes tinkering with postgres to be as insecure as i need it to be for easy development, then i'm out of there.
[01:41] <yano> but everyone else (sales, and support) all use Windows
[01:42] <yano> then again we are a non-computer company
[01:42] <jrgifford> we're a byod shop. :(
[01:42] <jrgifford> causes so many problems.
[01:42] <yano> oh wow
[01:42] <yano> do they compensate you for your equipment?
[01:42] <jrgifford> nope.
[01:42] <jrgifford> http://launchhouse.com/
[01:42] <yano> and how to they handle sensitive user information on your machine, legal-wise?
[01:42] <jenni> [ LaunchHouse | Seed Capital Fund & Business Accelerator ] - http://j.mp/1cgb6Em
[01:42] <jrgifford> it's a coworking space.
[01:43] <jrgifford> so we supply internet access and printers.
[01:43] <jrgifford> that's it. fairly nice.
[01:43] <yano> ah
[01:43] <yano> cool
[01:43] <jrgifford> but also a pain, because you've got everything from XP to tiger (10.4) to rhel5
[01:43] <jrgifford> and you have to have stuff that works on all of htose.
[01:43] <jrgifford> *those
[01:43] <yano> geez
[01:45] <jrgifford> Its fun.
[01:45] <jrgifford> You get to tinker with all sorts of systems.
[01:46] <jrgifford> And you have to justify every change that you want to make.
[01:46] <jrgifford> Well, almost every change.
[01:47] <yano> dang
[01:48] <jrgifford> Its actually nice. Means that we do things once in production after extensive testing.
[01:48] <jrgifford> We make use of VMs (a lot).
[01:51] <jrgifford> Anyway, that's the fun environment we've got. But seriously, SUSE?
[01:51] <jrgifford> Unit193: ^
[01:52] <Unit193> jrgifford: That's the point, actually.
[01:52] <Unit193> Make all the linux users agree, annoy all of them. :D
[01:53] <Unit193> No, I've never used OpenSuse, nor do I plan on it any time soon.  Debian based is quite nice, and Arch does have appeal as well.
[01:55] <jrgifford> So. Fedora is interesting though
[01:55] <skellat> openSUSE was nice once upon a time before they geared up to being the best KDE-based distro ever
[01:55] <jrgifford> I could see myself becoming a fedora user when I no longer use 99% gnome stuff and could move to KDE.
[01:56] <jrgifford> Like, Debian and Ubuntu are gnomes are heart.
[01:57] <Unit193> I don't use Gnome, I don't like it either, Xfce is my way to fly it.  Yum isn't my favorite, so I don't really see myself likeing Fedora that much, but I don't exactly dislike it.
[01:59] <jrgifford> I just need something that has keyboard shortcuts, a little bit of eye candy and no small amount of documentation.
[01:59] <jrgifford> I don't want to learn Linux and X11 internals to install my OS.
[02:01] <Unit193> Not as hard as some make it out to be.
[02:02] <yano> I use AwesomeWM
[02:03] <yano> i love the tiling
[02:05] <Unit193> What about conky?  My setup may not look nice, but it's quite functional for me.
[02:06] <yano> hehe, want to know what my background image is?
[02:06] <yano> http://git.io/uPV1Xg
[02:06] <jenni> [ dot_files/vi_cheat_sheet.gif at master · myano/dot_files · GitHub ] - http://j.mp/1cgefUB
[02:07] <yano> damn you, jenni!
[02:07] <skellat> yano: jenni doesn't play nice when I paste links to stuff on Launchpad
[02:08] <yano> skellat: hm, do you have a quick example?
[02:08] <skellat> Gimme a sec to get LP open
[02:09] <skellat> Try this: http://bazaar.launchpad.net/~skellat/+junk/slapshot/view/head:/bp.conf
[02:09] <yano> .title
[02:09] <yano> :o
[02:10] <yano> oh fascinating
[02:10] <jenni> (HTTPError: HTTP Error 404: Not Found)
[02:10] <yano> .title http://bazaar.launchpad.net/~skellat/+junk/slapshot/view/head:/bp.conf
[02:10] <jenni> AttributeError: 'unicode' object has no attribute 'sender' (file "/home/jenni/jenni/modules/url.py", line 358, in get_results)
[02:10] <Unit193> yano: You like mine on the one computer http://unit193.tk/images/index.php?cmd=image&sfpg=V2FsbHBhcGVyLypEYXZyb3MuanBnKmM2ZGNlZWE3MmE0NmU5NWE3NDc4ZWRiNWI3YjZjZTBk ? :D
[02:10] <jenni> http://j.mp/1cgeTRY
[02:11] <yano> Unit193: lol nice
[02:11] <skellat> yano: And then there's this one: https://code.launchpad.net/~skellat/ubuntu-seeds/xubuntu.saucy-aptoffline-addition
[02:12] <Unit193> Netbook got http://unit193.tk/images/index.php?cmd=image&sfpg=V2FsbHBhcGVyLypEb2N0b3IgU3VucmlzZS5qcGcqNmIwNjIwNjA4ZWU4ODgyMDRhMjlmNjhmZDI1ZTljZGE
[02:12] <jenni> http://j.mp/1cgfaED
[02:12] <jenni> http://j.mp/1cgffYZ
[02:14] <yano> wow
[02:14] <yano> jenni is getting 404's for those launchpad links
[02:14] <jenni> yano: Yes. That's extremely strange.
[02:15] <yano> ikr?
[02:22] <yano> i wonder if launchpad.net blocks access from Google App Engine
[02:25] <jrgifford> yano: possible. I'd ask in #launchpad just to be sure.
[02:26] <jrgifford> (I think its #launchpad.)
[02:34] <yano> it must be doing something funky. because using the exact same user agent and python calls, it works when not proxied through app engine
[02:34] <yano> er wait
[02:34] <yano> it doesn't
[02:34] <yano> so maybe it just doesn't like the user agent >_>
[02:45] <yano> i can curl that link but i can't grab it in python at all now
[02:45] <yano> D:
[02:45] <yano> launchpad is a PITA
[02:45] <Unit193> Indeed.
[02:45] <yano> and their pastebin is shit
[02:46] <Unit193> paste.ubuntu?    I just had to migrate my BeagleBoard over to Debian Testing from Xubuntu since the upgrade failed miserably.
[03:04] <skellat> The needs of Canonical's business are changing rapidly and are going in interesting directions.
[03:04] <skellat> I've been stressing LP out over the past week or so too.
[03:04] <skellat> :-D
[03:05] <yano> okay, now i'm pissed at jenni
[03:05] <yano> apparently it works in ipython from the jenni user on my box
[03:05] <yano> but not as in the bot
[03:05] <yano> >:(
[03:09] <yano> ooh, hm!
[03:15] <yano> o.o
[03:15] <yano> http://bazaar.launchpad.net/~skellat/+junk/slapshot/view/head:/bp.conf
[03:15] <jenni> [ ~skellat/+junk/slapshot : contents of bp.conf at revision 634 ] - http://j.mp/1cgp8pE
[03:15] <yano> now it works
[03:15] <yano> i'm not even sure what is different now
[03:22] <yano> i think i copied the URL from somewhere wrong and i kept testing the a broken URL D:
[04:22] <skellat> Blah: http://www.speedtest.net/result/2795183472.png
[04:29] <BiosElement> Ouch
[11:20] <yano> lol
[11:55] <jrgifford> skellat: that ping isn't bad...
[14:52] <skellat> BiosElement, yano, jrgifford: See what I mean when I complain about my local service through Time Warner Cable?  I get told that that is normal...for ENGLAND...
[15:00] <yano> huh
[16:05] <Guest98593> skellat: ...
[20:08] <skellat> Jeepers the NOAA Weather Radio keeps going off with Emergency Alert System data blasts
[20:10] <skellat> And now one EAS blast just overrode another one!
[20:10] <skellat> .weather 44135
[20:10] <jenni> Overcast ☁, 78.8°F (26°C), 29.93in (1010mb), Thunderstorm, Squalls, Near gale 28kt (↑) - KCLE, 19:59Z
[20:10] <skellat> .weather 44005
[20:10] <jenni> Cloudy, 87.8°F (31°C), 29.93in (1010mb), Gentle breeze 8kt (↑) - KYNG 19:51Z
[20:11] <Unit193> Temp: 89 F (32 C) ~ Scattered Clouds ~ Heat index: 92 F (33 C) ~ Humidity: 48% ~ Alert: Severe Thunderstorm Watch
[20:13] <skellat> .weather KERI
[20:13] <jenni> Cover Unknown, 21°C, 1015mb, Shallow Fog, N SC, Light air 2kt (↑) - EETN, 19:50Z
[20:13] <skellat> Boom.  That's the third EAS data blast in the past five minutes
[20:13] <yano> geez
[20:14] <yano> you should see ##weather-us-oh
[20:14] <yano> it's going crazy
[20:14] <yano> oh you're alrady there
[20:14] <skellat> NWR audio says I've got one inbound that's about 15 minutes out
[20:18] <Unit193> ...Anyone else have problems trying not to read ##weather-us-oh messages with the voice on the radio?
[20:34]  * skellat notes power is out in Ashtabula and his 3G connection isn't too hot.  Laptop power is draining and the alarm on the UPS is still going off.  See y'all once we get things restored...
[20:37] <Unit193> Wooo! Upgraded to a warning!


[03:14] <locodir-user> Hello good people, I was wondering if I could get help here regarding edubuntu?
[03:18] <locodir-user> hello anyone out there?


[00:52] <callmepk> good morning
[06:40] <didrocks> good morning
[06:41] <jibel> Good morning
[06:55] <duflu> Morning didrocks and jibel
[06:56] <oSoMoN> good morning desktoppers
[06:56] <didrocks> Hey duflu, salut oSoMoN
[06:57] <oSoMoN> salut didrocks
[06:58] <jibel> Hi duflu oSoMoN
[06:59] <oSoMoN> salut jibel
[07:05] <duflu> Morning oSoMoN
[07:18] <oSoMoN> hey duflu
[07:41] <ricotz> good morning desktopers
[07:46] <didrocks> hey ricotz
[07:51] <duflu> Morning ricotz
[08:25] <marcustomlinson> morning didrocks jibel duflu oSoMoN ricotz
[08:26] <duflu> Hi marcustomlinson
[08:26] <marcustomlinson> ricotz: sorry I only saw your message this morning.  Otherwise fine. How are you seb128 ?
[08:41] <seb128> duflu, distro one again or upstream now?
[08:41] <duflu> seb128, ubuntu-only
[08:42] <seb128> got slightly more sleep but I got woken up at 5:30am again, I hate it :-(
[08:42] <seb128> duflu, :-(
[08:42] <seb128> I'm curious to know what we broke, let us know when you figure out
[08:43] <jibel> in a qemu VM on first boot, after login on wayland I cannot click on anything, but it works after a logout/login. Is it a known issue?
[08:43] <duflu> seb128, it appears to be a fix for one of the previous shell regressions that caused this new one
[08:43] <seb128> jibel, is that was is breaking the daily ISO promotion?
[08:43] <duflu> bug 1918874
[08:44] <seb128> duflu, ^ do you know that one from jibel?
[08:44] <seb128> I fixed the ISO warning on https://people.canonical.com/~platform/desktop/desktop-packages.html now, it was checking the dir before and arm64 ISO were updated
[08:44] <jibel> seb128, no
[08:45] <duflu> Not really. People report a couple of times per year that they can't click on app windows only. But it's rare
[08:45] <seb128> now it displays it properly, 'the current amd64 ISO is outdated (51 days old)'
[08:45] <duflu> Oh, jibel using Nvidia?
[08:45] <seb128> shrug, that's quite outdated :/
[08:45] <seb128> duflu, does it make a difference for qemu instances what driver the system is using?
[08:45] <duflu> Oops, in a VM is probably not Nvidia
[08:46] <jibel> duflu, no in a VM
[08:46] <jibel> and the host is full intel
[08:47] <duflu> jibel, can you click on the shell even?
[08:47] <jibel> duflu, no, on mouse over it detects that the pointer is over an element because it highlights for example in the dock, but I cannot click on it
[08:48] <jibel> like these old ghost window bugs
[08:48] <duflu> Weird. Sounds like it might be related to the input thread for Wayland introduced in mutter 3.38.3-3ubuntu1
[08:49] <jibel> I'll file a bug
[08:54] <seb128> jibel, any idea when that started? do you have a some weeks old iso to see if that's a regression from the recent changes?
[09:00] <jibel> seb128, not really, I noticed it yesterday when I installed a new VM to test zfs stuff
[09:02] <Laney> moin
[09:03] <jibel> hi Laney
[09:03] <duflu> Hi Laney
[09:05] <Laney> sup jibel duflu
[09:09] <seb128> hey Laney
[09:13] <Laney> yo seb128
[09:45] <marcustomlinson> hey Laney
[09:56] <abeato> ddd
[10:04] <Laney> eeefffggg
[10:04] <Laney> hey marcustomlinson
[10:58] <seb128> jibel, did you have any chance to poke at the outdated daily current iso yet?
[10:59] <jibel> seb128, I am on it but static validation fails for some reason today
[10:59] <jibel> seb128, meanwhile I manually verified and promoted latest iso
[10:59] <seb128> thanks
[11:07] <jibel> seb128, automated test are failing because the size of the image increased and the target disk is too small
[11:07] <seb128> ah
[11:07] <seb128> we need to land that KPI
[11:08] <jibel> seb128, I connected to libvirt, watched the installation and the error message is displayed by ubiquity
[11:09] <seb128> could you give me some details on how to connect to libvirt to do that? so next I might be able to poke myself
[11:09] <seb128> also where is the setup defined if we need to bump the disk allocated?
[11:10] <jibel> start virt-manager and create a connection to the server ofver ssh
[11:10] <jibel> over*
[11:10] <jibel> where the disk size is set is a bit more mysterious at the moment :)
[11:10] <seb128> which server?
[11:10] <seb128> sorry, I've close to 0 knowledge of that infra
[11:24] <Laney> there's a host which runs VMs for this testing in the DC, it's called venonat.ubuntu-ci
[11:27] <seb128> thanks
[11:34] <jibel> even after increasing the disk size it stops on stage "prepare" like something is missing from the seed
[11:36] <jibel> seb128, I think bug 1895351 caused the issue with the seed
[11:37] <seb128> ah
[11:37] <jibel> now I've to find where the seed is hidden and add the 2 new settings
[12:24] <jibel> seb128, tests are green again after preseeding use_nonfree and install_oem
[12:24] <Laney> \o\
[12:35] <seb128> jibel, great, thanks for fixing it!
[14:30] <seb128> hey there!
[14:30] <didrocks999> hey!
[14:31] <seb128> #startmeeting Desktop Team Weekly Meeting - 2021-03-16
[14:31] <meetingology> Meeting started at 14:31:04 UTC.  The chair is seb128.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:31] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:31] <seb128> Roll call:  didrocks, duflu (out), jamesh (out), jibel, kenvandine, laney, marcustomlinson, oSoMoN, tkamppeter, trevinho, robert_ancell (out), hellsworth
[14:32] <oSoMoN> o/
[14:32] <seb128> (sorry was struggling to promote the bot so it can update the topic)
[14:32] <marcustomlinson> \o
[14:32] <seb128> I hope everyone is doing fine!
[14:32] <jibel>  /o\
[14:32] <seb128> don't be sad jibel!
[14:32] <jibel> :)
[14:33] <seb128> sounds like we don't have much people around, another reminder to reply to L'aney's email :p
[14:33] <seb128> let's get started anyway
[14:33] <seb128> #topic rls-hh-bug
[14:33] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-hh-incoming-bug-tasks.html
[14:34] <seb128> the shell ones are being handled, first got fixed by the gjs revert
[14:34] <seb128> the other one duflu is on it
[14:34] <Laney> they should be assigned then or at least untagged?
[14:34] <seb128> bug #1916881 we discussed previous week, Olivier commented
[14:34] <Laney> s/assigned/nominated/
[14:34] <seb128> Laney, the first one probably untagged since it's fixed from the gjs side
[14:35] <oSoMoN> let's untag the thunderbird issue and assign to me
[14:35] <seb128> right
[14:35] <seb128> bug #1918874
[14:36] <seb128> Trevinho, another one due to the input changes, it's time we revert as agreed?
[14:37] <seb128> I know you care about doing the right thing but it has proven to create enough disruption, we at least found problems, now we can fix them for next cycle
[14:37] <seb128> unsure he's around so I'm going to move on, we can discuss that after the meeting
[14:38] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-hh-tracking-bug-tasks.html
[14:38] <seb128> those are assigned
[14:38] <seb128> #topic rls-gg-bug
[14:38] <seb128> (bot still not changing the topic so I guess that was not a permission issue)
[14:38] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-gg-incoming-bug-tasks.html
[14:39] <seb128> I notfixing the libreoffice one
[14:39] <Laney> (no, the topic isn't locked anyway)
[14:39] <seb128> and the thunderbird one as well
[14:39] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-gg-tracking-bug-tasks.html
[14:40] <seb128> bug #1914374 I wontfixed the ubuntu-drivers-common/groovy entry now
[14:40] <seb128> and that's it for this list
[14:40] <seb128> #topic rls-ff-bug
[14:40] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html
[14:40] <seb128> thunderbird only which is handled
[14:40] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-tracking-bug-tasks.html
[14:41] <seb128> those are either assigned or fix commited
[14:41] <seb128> #topic rls-bb-bug
[14:41] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[14:41] <seb128> no desktop there
[14:41] <seb128> those are either assigned or fix commited
[14:41] <seb128> that's it for bugs
[14:42] <seb128> #topic update_excuses_by_team.html#desktop-packages
[14:42] <seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
[14:42] <Laney> looks quite good!
[14:42] <seb128> firefox/thunderbird are blocked due to rust/s390x which foundations is actively working on fixing from what I saw today
[14:42] <seb128> indeed
[14:42] <seb128> calculator is my fault, another of the new tests not liking being offline
[14:42] <Laney> firefox looks like it's in NEW to me
[14:43] <seb128> I need to figure out how to properly setup things to be able to test that before upload
[14:43] <Laney> let me take a look at that one
[14:43] <Laney> ah yeah s390x
[14:43] <seb128> and webkit2gtk is ruby webkit segfault, which I upstreamed but didn't a reply on yet
[14:43] <seb128> and that's it
[14:44] <seb128> #topic AOB
[14:44] <seb128> anything else?
[14:44] <Trevinho> seb128: sorry, on that bug that's not a regression due to the input changes, it's due to 3.38.x base, there's a PR upstream I wanted to look at
[14:44] <Trevinho> so we need to fix in dashtodock, mutter isn't faulty here.
[14:44] <seb128> Trevinho, duflu disagrees, he bisected to a commit if you see the bug
[14:45] <seb128> but right, needs to be fixed in dashtodock, Daniel agrees on that part
[14:45] <Trevinho> mh, I want to check, but I'm sure there's a fix on the dock side I wanted to pick anyways
[14:45] <seb128> k
[14:45] <Trevinho> and since the dock doesn't fit with 40 anyways, I assume was present still
[14:45] <seb128> version says our dock is one version behind upstream, unsure if there are other changes worth getting
[14:45] <Trevinho> since was proposed by non-ubuntu users
[14:45] <Laney> ubuntu dock is still at the same version as in groovy, so how did something in mutter break it?
[14:46] <Trevinho> I think it's the shell side in fact, but whatever... There's a fix upstream and I'll pick it.
[14:46] <Trevinho> once I've finally reviewed
[14:47] <Trevinho> I mean https://github.com/micheleg/dash-to-dock/pull/1369
[14:47] <Trevinho> and the issue comes up only on wayland I think, reason why wasn't noticed?
[14:48] <seb128> k, let's discuss that post meeting, no point holding everyone (if anyone is really sticking to wait :p)
[14:48] <Trevinho> seb128: regarding versions back or forth, I think the ubuntu branch of the dock was still including the commits that ended up in the upstream one, more or less
[14:48] <seb128> anything else?
[14:48] <Trevinho> sure, sure... I was done, just wanted to mention it.
[14:49] <seb128> k
[14:49] <didrocks999> nothing for me :)
[14:49] <oSoMoN> nothing from me either
[14:49] <seb128> k, let's wrap then
[14:49] <seb128> thanks desktoppers!
[14:49] <seb128> #endmeeting
[14:49] <meetingology> Meeting ended at 14:49:46 UTC.  Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-desktop/2021/ubuntu-desktop.2021-03-16-14.31.moin.txt
[14:49] <didrocks999> thanks everyone
[14:49] <marcustomlinson> thanks seb
[14:49] <oSoMoN> thanks
[14:49] <hellsworth> thanks!
[14:49] <jibel> ty
[14:50] <seb128> people knowing about IRC bots, do we have one around we can easily patch to handle team specific things?
[14:50] <Laney> great meeting, one of the classics
[14:50] <seb128> :)
[14:50] <Laney> I know that Gustavo has a bot which is maintained if that helps ;-)
[14:51] <Trevinho> ahahha
[14:51] <seb128> Trevinho, going back to the point, you can keep saying 'one more fix' but at this point the team consensus it to revert those input backport, could you please do that instead?
[14:52] <Trevinho> seb128: I'm quite sure that's not what will fix it, that's my point.
[14:52] <Trevinho> if it was noticed eve withouth the mutter changes, how can it be the?
[14:52] <Trevinho> more typos than words :-D
[14:53] <seb128> Laney, 🤔
[14:53] <seb128> Trevinho, you are saying duflu got his bisect wrong?
[14:53] <Trevinho> I mean, https://github.com/micheleg/dash-to-dock/issues/1359 nobody mentions ubuntu
[14:53] <seb128> Trevinho, that bug is about flickering
[14:54] <seb128> Trevinho, the launchpad one is about having a windows on top of the overview screen
[14:54] <seb128> and happens in xorg
[14:54] <seb128> 'Click on 'Show Applications' the icons of the applications appear but the windows of the applications does not disappear so the icons are hidden.
[14:54] <seb128> problem happens with both sessions Xorg and Wayland after last updates
[14:54] <seb128> see attached picture'
[14:55] <Trevinho> yeah, I was reading but though was related, but ok.
[14:57] <seb128> Daniel also pointed out the problematic code in the last comments
[14:57] <seb128> which seems different from the fix you pointed out
[14:57] <Trevinho> yeah, i saw it, looks fine I definitely intended it was relating to something else
[14:59] <seb128> aaanyway, doesn't change the point, can we get the backport reverted and go back to focus on other things than fixing side effects of that landing?
[14:59] <seb128> jibel also pointed out earlier than the first logging in a vm isn't reacting to clicks for him, which Daniel though might also be due to those changes
[15:00] <Trevinho> seb128: fact is to me is quite more annoying at this point to revert two packages changes, and also I like that we can test upstream code that is going to be released anyways, which also made us fix various upstream issues already, even if we're not in 40 for something, giving us better experience later.
[15:01] <seb128> I don't deny that the work is useful
[15:01] <seb128> it's just not what we signed up for doing
[15:01] <Trevinho> but I see the point, it all depends on time consuming and so far I thought was more to revert than to have the fixes in.
[15:01] <seb128> one reason we say we wouldn't update to GNOME 40 was so we could focus on other tasks
[15:02] <seb128> not that we would spend the efforts fixing upstream anyway through backports
[15:02] <seb128> Daniel stated that he wasted several days in bisecting regressions
[15:02] <seb128> I doubt that reverting would have taken several days
[15:03] <seb128> also other people had to fix their box so they could go back to work
[15:03] <seb128> it adds up, it's not only the time you are spending on the revert vs fix
[15:04] <seb128> anyway, I argued enough, if I didn't convince you it's not another 10 lines that will make a difference...
[15:04]  * seb128 goes back to write reviews
[15:04] <Trevinho> it's hard as I bisected the previous issue in half hour, so I can handle that since it's my responsability, but that's fine, i'll revert it. you can imagine though that I see it more productive time
[15:05] <seb128> thanks, I know you invested in there and you would feel better about pushing forward
[15:06] <seb128> sorry it's not turning as you wanted
[15:06]  * seb128 hugs Trevinho
[15:10] <Trevinho> seb128: it's fine, it was an experiment and I'm quite happy how it went given that it turned it into 3-4 upstream fixes, so had it relevance.
[15:10] <seb128> right
[15:10] <Trevinho> the floss again gained by the ubuntu user base :)
[15:15] <oSoMoN> Laney, earlier in the meeting you said firefox is in NEW, and you were right, there's a new binary package (firefox-locale-szl)
[15:16] <oSoMoN> it's blocked because it FTBFS on s390x anyway
[15:16] <Laney> oSoMoN: yeah, I should accept that but the s390x issue will still block it
[15:20] <Laney> ah there's xwayland in the queue too


[00:31] <bluesabre> flexiondotorg: we are not.
[00:31] <bluesabre> ... as Unit193 already indicated
[00:31] <bluesabre> :)
[09:49] <Unit193> Debian #827792, Debian #827794, https://ftp-master.debian.org/new/numix-icon-theme_0~20160619.217701b-1.html
[09:53] <Unit193> bluesabre, ochosi: https://launchpad.net/bugs/1593038
[10:25] <bluesabre> Unit193: sure would be nice if he'd go ahead and package the other
[10:26] <Unit193> "Other"?
[10:32] <Unit193> bluesabre: gtk-theme is in git, just not NEW yet.
[10:36] <bluesabre> I meant greybird in debian
[10:38] <Unit193> They're unrelated sources, and murrine-themes carries Greybird already.
[10:38] <bluesabre> ah
[10:38] <bluesabre> did not know that
[10:38] <Unit193> Outdated, and same package, but nevertheless.
[10:38] <Unit193> !find Greybird unstable
[10:38] <Unit193> !find Greybird unstable
[10:38] <bluesabre> neat
[10:39]  * bluesabre shuts up
[10:39] <bluesabre> :x
[10:40] <Unit193> Last updated in June, and they have GTK 3.20 already, sooo....
[10:45] <Unit193> Also seems GNOME is willing to test GTK 3.20 Greybird maybe.
[19:14] <Unit193> flocculant: You haven't noticed screen flickering/glitches on Yak right?
[19:25] <flocculant> Unit193: nope - using nouveau
[19:25] <flocculant> well
[19:25] <flocculant> I see a glitch with ff if page opening in a new tab includes a flash video - but assume that to be ff :)
[19:27] <flocculant> actually - even more specifically - with bbc pages on ff that have a flash video
[19:28] <knome> even more specifically bbc pages on ff that have a flash video about politics
[19:28] <knome> at that point i'd assume it's your brain giving the black flicker...
[19:28] <flocculant> ha ha ha
[19:29] <Unit193> Not a black flicker, it'd be amusing if it didn't happen so often and be so annoying.  I'd equate it to xfwm/x having a seizure.
[19:29] <flocculant> this is black - but pretty sure it's not xfanythingatall :)
[19:30] <Unit193> Get adobe-flashplugin and browser-plugin-freshplayer-pepperflash. :P
[19:31] <Unit193> (...Yes, I typed both out..)
[19:32] <flocculant> Unit193: don't have them here - but did have them here before it all went wrong 2 weeks or so back
[19:32] <Unit193> Just a recommendation or such, not entirely sure they'd help.
[19:33] <flocculant> doing so let's see :)
[19:34] <flocculant> upgraded at the same time
[19:34] <flocculant> initscripts marked as autoremove
[19:46] <pleia2> knome: did you find our distinguished PTL yet? I'm conferencing Sunday - Wednesday next week so it would be good to publish this thing soon
[19:47] <knome> PTL?
[19:47] <knome> pain tolerance level?
[19:48] <pleia2> too much openstack, XPL
[19:48] <knome> no, i didn't find him yet
[19:48] <Unit193> pleia2: Yep, you!
[19:48] <knome> but if he's not around... then just do it
[19:48] <knome> schedule for like tomorrow?
[19:49] <flocculant> knome: I'd say so
[19:49] <pleia2> Unit193: take it back
[19:49] <flocculant> only xpl to have an xpl - really he's waiting for council to take over :)
[19:49] <knome> who knows...
[19:49] <flocculant> and expires in a week or so again
[19:50] <Unit193> I'm waiting on him for theme discussions.
[19:50] <flocculant> that's a bit different - he'd have a different hat on :)
[19:52] <flocculant> knome: talking of which - perhaps we should actually move on a bit - I guess it'll be you and I moving that forward ... again :p
[19:53] <knome> yes
[19:53] <knome> schedule that for a bit later today or tomorrow
[19:54] <flocculant> I could cope for a while a bit later on today, then continue if we need to
[19:54] <knome> sure
[19:55] <knome> during the next hour or so?
[19:55] <flocculant> need to eat - and I'm behind atm - mother decided I meant 6 when I said 8 - which has put me all over the place ...
[19:55] <knome> lol
[19:55] <flocculant> by need to eat - read ravenous :p
[19:55] <flocculant> it is cooking though right now
[19:55] <knome> but not all over the place like mr. creosote?
[19:56] <flocculant> no :D
[19:56] <knome> good
[19:56] <knome> let's hope that doesn't happen post-dinner either
[19:57] <flocculant> :)
[19:57] <flocculant> if it does then tomorrow :p
[19:57] <knome> haha
[20:25] <flocculant> knome: anyway - back now if you like
[20:26] <knome> soon
[20:31] <flocculant> hi wxl
[20:31] <Unit193> (That was a netsplit.)
[20:33] <flocculant> didn't seem like much of one here :p
[20:33] <Unit193> Netsplit *.net <-> *.split quits: floc culant, sak recoer, dav mor2_HOLS, w x l
[20:35] <flocculant> no difference to the odd bbc black box glitch btw
[20:36] <Unit193> Meh, worth a shot I guess.
[20:36] <flocculant> yup
[20:38] <ax562> so how would I go about helping with testing again?
[20:38]  * knome points ax562 to flocculant
[20:39] <knome> flocculant, i'm good to go in 15ish once wife is in bed and me on the desktop
[20:39] <flocculant> okey doke - probably best to pm and pad like last time
[20:39] <ax562> I'm about to do a fresh install of xubuntu 16.06 and running 14.04lts with the xfce-environement
[20:40] <ax562> flocculant should I pm you?
[20:41] <flocculant> Unit193: definitely a ff thing - no such thing in chromium
[20:41] <Unit193> ax562: We'd be testing 16.10, .04 is already released.
[20:41] <flocculant> ax562: #xubuntu
[20:41] <flocculant> I've been running 16.10 since the day after we released 16.04
[20:42] <Unit193> I've been running it ever since I upgraded.
[20:42] <flocculant> later I'll do some 14.04.x to 16.04.1 upgrade testing - and will ask others
[20:42] <flocculant> Unit193: :)
[20:43] <ax562> cool so right now 16.10 needs testing?  how would one get 16.10
[20:44] <Unit193> ISO, upgrade, or minimal+task.
[20:44] <flocculant> ax562: pretty sure I pointed you at the dev docs the other day
[20:44] <ax562> yeah, i missed one of the links
[20:44] <ax562> hold on let me check
[20:44] <Unit193> flocculant: Point at the most up to date ones! :--D
[20:44] <flocculant> chapters 4-7 are all qa/testing ones
[20:44] <flocculant> http://docs.xubuntu.org/contributors/
[20:45] <flocculant> also http://wiki.xubuntu.org/qa/isotesting
[20:45] <flocculant> Unit193: not changed anything
[20:45] <flocculant> yet ...
[20:45] <ax562> http://docs.xubuntu.org/contributors/
[20:45] <ax562> this is what I should be looking at rigt?
[20:45] <flocculant> read up :)
[20:46] <ax562> ok cool. so 4-7
[20:46] <flocculant> and below that ;)
[20:46] <ax562> is there a video :p
[20:47] <flocculant> nope
[20:47] <flocculant> ax562: but guess what ...
[20:47] <ax562> what?
[20:47] <flocculant> http://dev.xubuntu.org/#tab-details/spec=xubuntu-y-qa
[20:47] <flocculant> see the item David has at the top
[20:48] <flocculant> nothing to stop you doing that given you want to help :)
[20:48] <ax562> haha ok
[20:49] <ax562> one step at a time though :p
[20:49] <flocculant> well the best people to do something like that - are people who don't do things on autopilot :)
[20:51] <ax562> i don't have a plane so I think i'm good ;)
[20:52] <flocculant> I'm definitely on autopilot - a command grabs the iso's then boots them sequentially with kvm
[20:52] <flocculant> well - updates the iso's
[20:52] <Unit193> Hrm, I should update the ISOs then.
[20:52] <ax562> ah your talking about scripts
[20:53] <Unit193> flocculant: I tried not using the ubiquity hack recently, did not work. :/
[20:53] <flocculant> Unit193: :)
[20:54] <flocculant> ax562: nope http://paste.ubuntu.com/17767276/
[20:55] <flocculant> yes probably krytarik - but it works so *shrug*
[20:55] <ax562> that's pretty cool
[20:55] <flocculant> :)
[21:04] <knome> let's do two things at once
[21:04] <knome> flocculant, the mail to CC (probably doesn't need much work)
[21:04] <knome> pleia2, the #lovexubuntu announcement
[21:04] <pleia2> eh?
[21:04] <knome> pleia2, let's do it now?
[21:05] <knome> i know i said tomorrow... (and it's technically "tomorrow" here now)
[21:05] <pleia2> but we don't have our leader dude
[21:05] <knome> but we haven't seen him in a while and we're moving towards a council anyway
[21:05] <flocculant> pleia2: yep - but ^^
[21:05] <pleia2> ok wfm
[21:06] <flocculant> and 3 or 4 of team have said go for it :)
[21:06] <knome> i don't think it's a biggie for him
[21:06] <knome> he isn't even in the marketing team...
[21:06] <pleia2> indeed :)
[21:06] <flocculant> pseudo-council :)
[21:06] <knome> meh, i need to figure out my ubuntu one password
[21:06] <knome> sec
[21:06] <Unit193> Still, just XPL pleia2, everyone's happy.
[21:06] <flocculant> knome: the CC is easy - send them our plan with a cover note
[21:06] <pleia2> Unit193: I don't even have time to do my marketing duties as well as I'd like
[21:07] <Unit193> pleia2: FWIW, you're just the fun one this week, last time it was slickymaster. :)
[21:07] <pleia2> next time, Unit193
[21:07] <knome> next time should last for like, 2 years
[21:08] <pleia2> yeah, voluntelling is an important skill in XPL
[21:08] <Unit193> Rules me out.
[21:09] <knome> pleia2, so was there anything we wanted changed in the article, or should i go push it out, then social media?
[21:10] <pleia2> knome: it lgtm
[21:10] <knome> pleia2, ok, publishing when i'm in..
[21:10] <pleia2> I'll do G+ and FB once it's out, then I will take a nap
[21:10] <knome> flocculant, http://pad.ubuntu.com/x-council-cc-mail
[21:10] <knome> flocculant, that's the proposal part (plus some) from the mail to the devel list
[21:11] <knome> needs some tweaks and an introduction
[21:12] <knome> pleia2, https://xubuntu.org/news/looking-memorable-fun-xubuntu-stories/ is out
[21:12] <pleia2> ty sir
[21:12] <knome> and making it an article too so it shows up on the front page
[21:13] <knome> and done
[21:13] <knome> tweeting next...
[21:15] <knome> --> https://twitter.com/Xubuntu/status/746089144535875585
[21:15] <pleia2> G+ and fb done
[21:25] <knome> flocculant, i'm pretty much fine with it; we could probably tweak it for another hour, but ultimately, it's "just" the CC and we want this to progress ASAP
[21:41] <flocculant> knome: did you say ^^ while I was facepalming at stylish?
[21:41] <knome> flocculant, ok, sent
[21:42] <knome> flocculant, did i say what? :)
[21:42] <knome> i said ^ ^ to make sure you saw the whole link :D
[21:42] <flocculant>  we could probably tweak it for another hour, but ultimately
[21:42] <knome> right
[21:43] <knome> probably earlier
[21:43] <knome> or later
[21:43] <flocculant> cool - got the cc
[21:43] <knome> i don't remember
[21:43] <flocculant> ha ha ha
[21:43] <knome> ...
[21:48] <flocculant> right - dreamtime :)
[21:48] <knome> nighty flocculant!
[21:49] <flocculant> knome: all I'd say is I'd like if we can just get as much done as possible, and start moving on - otherwise it'll be 17.04 dev cycle :)
[21:49] <knome> yep
[21:49] <knome> maybe
[21:50] <flocculant> :)
[21:50] <flocculant> anyway - not tonight :)
[21:50] <flocculant> night peeps
[22:13] <ax562> so I would have to dl the 16.10.iso to test correct?
[22:18] <knome> yes
[22:18] <Unit193> I'd of course be interested in responses too.
[22:22] <knome> ax562, note that for the testing to be useful, you will have to follow the steps mentioned in the contributor docs, which will ultimately lead you to reporting a test (or several ones) to the testing trackers
[22:30] <ax562> yeah I created a launchpad, joined the xubuntu group, and was at the iso stage but didn't know which to download
[22:30] <ax562> or do I have to download
[22:30] <knome> ok
[23:05] <ax562> downloading 116.10 :)
[23:31] <Unit193> All of GNOME 3.20 is held up right
[23:31] <Unit193> ?
[23:31] <Unit193> (https://packages.qa.debian.org/e/evince/news/20160623T232718Z.html)


[17:22] <cwayne> hello all
[21:26] <ajmitch> hi cwayne
[21:27] <ajmitch> mhall119: I'm sorry I didn't get you those build system stats, getting the info morphed into something a bit more complicated
[21:27] <cwayne> ajmitch: heya, hows it goin?
[21:27] <ajmitch> cwayne: good thanks, how are you?
[21:27] <cwayne> ajmitch: not bad thanks
[21:27] <cwayne> just waitin for 1 more vote to get my app accepted :)
[21:28] <ajmitch> pretty sure that I voted on your one :)
[21:28] <mhall119> ajmitch: would it be easier to get a rough estimate rather than exact numbers?
[21:28] <cwayne> ajmitch: haha, well in that case, thanks!
[21:29] <ajmitch> mhall119: could be, I ended up starting on something to view the queue & run arb-lint, licensecheck, etc across the lot & show it
[21:29] <ajmitch> bad feature creep, I know :)
[21:29] <mhall119> heh
[21:30] <ajmitch> I'll get rough stats to you asap then
[21:31] <cwayne> are you guys looking for help QA-ing apps?
[21:31] <ajmitch> mostly with reviewing & fixing packaging, license checks, all the boring bits :)
[21:35]  * ajmitch thought there was a post on the mailing list about what we'd like people to help with
[21:37] <ajmitch> but basically, until we get a more automated process for packaging in place, we expect app authors to submit a source packages either in a branch or a PPA, it should pass checks such as those found in arb-lint, it must have appropriate copyright documentation in debian/copyright
[21:37] <ajmitch> https://launchpad.net/arb-lint is the tool used along with lintian
[21:45] <cwayne> hmm, i may be able to help with that, although most of my expertise would be QA
[21:48] <cwayne> i would like to help though, i figure you guys are pretty swamped since the app showdown ajmitch
[21:49] <ajmitch> yeah, swamped with that & for other reasons
[21:53] <cwayne> ajmitch: yeah :/
[21:54] <cwayne> it's definitely quite frustrating at times
[21:58] <ajmitch> sorry
[22:11] <cwayne> ajmitch: heh don't be, you got me one of my 2 votes :)


[06:14] <hyper_ch> hi there, can't login to my launchpad account. it says something about cookies and http referer
[06:27] <wgrant> hyper_ch: The page tells you what you need to change.
[06:28] <hyper_ch> wgrant: it doesn't really help... cookies are activated for launchpad... well, they're activated for everything, just they get deleted after a while... and referer is also fine
[06:28] <wgrant> What is the URL that is complaining, and what exactly does it say?
[06:28] <wgrant> And are you completely sure you haven't got any extensions that may have changed Referer behaviour?
[06:28] <wgrant> eg. NoScript
[06:29] <hyper_ch> of course I run noscript
[06:29] <hyper_ch> https://login.launchpad.net/1PADmYr8Y29gZj9S/+login
[06:30] <hyper_ch> and launchpad is allowed to use js
[06:32] <wgrant> Right, but do you use NoScript's settings that give weird Referer behaviour?
[06:32] <hyper_ch> actually, using notscripts in chromium
[06:33] <wgrant> I don't know anything about that.
[06:33] <wgrant> Anyway, launchpad.net does not require JS for login, but it does require cookies and a minimally invasive Referer.
[06:33] <hyper_ch> what you mean by that?
[06:34] <wgrant> In Firefox I run with network.http.referer.XOriginPolicy=2 and network.http.referer.trimmingPolicy=2, which sends the origin (eg. https://launchpad.net/ -- no path) and only to the site itself.
[06:34] <wgrant> That's sufficient for almost all sites.
[06:34] <hyper_ch> I don't use ff
[06:34] <wgrant> I know.
[06:34] <wgrant> But I don't know the corresponding Chromium or NotScript settings, so I was explaining the minimum requirement.
[06:35] <hyper_ch> on a gazillion other sites I have no issues loging in.... but I can't login on launchpad
[06:35] <hyper_ch> and I don't even know what you mean by sends origin
[06:37] <wgrant> Try disabling NotScripts temporarily to see if that solves the problem.
[06:37] <wgrant> It works fine with default settings, so something in your configuration is breaking it.
[06:37] <hyper_ch> default settings aren't privacy concious
[06:38] <hyper_ch> so don't even refer to those
[06:39] <wgrant> But mine are, and they work fine.
[06:39] <hyper_ch> same results with notscripts disabled
[06:40] <wgrant> Do you have other extensions that are potentially relevant? And have you reclicked the login link, rather than just refreshing the page?
[06:41] <hyper_ch> I have lots of privacy extensions
[06:42] <wgrant> I suggest you try disabling them all and reenabling it until you find which one is causing the misbehaviour, so you can work out which one you need to reconfigure.
[06:43] <hyper_ch> found it
[06:49] <wgrant> hyper_ch: Which was it?
[06:53] <hyper_ch> fix url links redirect
[06:54] <hyper_ch> guess, I can't log into launchpad anymore
[07:18] <wgrant> Or you could just use something with a sensible Referer policy, but okay.
[17:10] <Sweet5hark> so ... with the new git support: what's the best way to mirror to launchpad?
[17:11] <cjwatson> Sweet5hark: We'll be adding proper mirroring support soonish, though no specific schedule yet.
[17:11] <cjwatson> Sweet5hark: In the meantime you could do a git clone --mirror / git push --mirror, I imagine, if you had a specific reason to be in a rush
[17:13] <Sweet5hark> we have gerrit running at gerrit.libreoffice.org and it routinely pushes to backup locations like github for mirroring. I assume, if we could push to launchpad, we could mirror using gerrits stuff.
[17:13] <Sweet5hark> cjwatson: hang on, getting our guy in here ...
[17:13] <cjwatson> It's a bank holiday today, I'm only slightly around, please don't expect to have a lengthy conversation with me
[17:16] <Sweet5hark> cjwatson: shm_get is our gerrit guy. however, I didnt realize that there is a bank holiday at cjwatsons home. So maybe you two just meet tomorrow, or something?
[17:16] <shm_get> Sweet5hark or something.. I'm at a conference for the next 3 days :-)
[17:16] <cjwatson> You may not need much from me, if all you want to do is treat git.launchpad.net as an ordinary git server
[17:20] <cjwatson> If you're pushing the main upstream repository, pushing it to git+ssh://git.launchpad.net/libreoffice will cause it to be set as the default, which will make pushing of per-user libreoffice repositories much quicker
[17:23] <shm_get> cjwatson our 'main' repo is core.git but it has 3 submodules...  and we have a bunch of auxiliary repos.... that being said my issue are less likely to be with git itself than with launchpad in general :-)  I have an openid on it.. but that is about it...
[17:23] <shm_get> cjwatson are repo auto-created.. or do I need to pre-seed things ?
[17:25] <shm_get> and presumably I do not want to associate them with my personal user.. but to something more generic... like a 'tdf' group or a tdf user at least...
[17:26] <shm_get> cjwatson and yes.. the whole point is to mirror our main upstream repositories....
[17:41] <cjwatson> Repositories are auto-created on push.  You should probably push to a team-owned account, which requires a bit more fiddling in order to set it up as a default repository for a project.
[17:41] <cjwatson> Catch me tomorrow.
[17:42] <cjwatson> Er, "to a team-owned repository" I mean.
[17:47] <shm_get> cjwatson sadly that won't be tomorrow... next friday most likely...
[17:47] <teward> cjwatson: any idea when PPAs will be enabled for wily?
[17:52] <barry> is it expected right now that git branches don't show up on your code.launchpad.net/~ page?
[17:53] <teward> barry: https://help.launchpad.net/Code/Git - "Here's a short list of bugs you don't need to tell us about: ... there is no web listing of repositories available for a given target"
[17:53] <barry> teward: oops, i missed that line
[17:54] <barry> no worries, you can always go directly to the branch page
[18:21] <xnox> $ git push lp:~ubuntu-foundations-team/cross-toolchain-base master:master
[18:21] <xnox> fatal: remote error: You cannot set the default Git repository for '~ubuntu-foundations-team/cross-toolchain-base'.
[18:21] <xnox> please help with git =)
[18:32] <xnox> ah i must be an admin =(
[18:42] <xnox> yeah \o/ got it to work
[22:00] <cjwatson> teward: PPAs are enabled when the distroseries works, but it usually takes a day or two to get everything set up.  Please don't nag :-)
[22:00] <cjwatson> shm_get: np
[22:14] <courrier> Heys guys! Is it possible to submit a bug directly within the web interface? While I'm logged in, I can't find any link to submit a new bug
[22:15] <ali1234> yeah it's possible
[22:16] <ali1234> on a project page it's one the right under "Get Involved"
[22:18] <courrier> ali1234: mmmmh, it's disabled "Launchpad needs to know where the user can report a bug"
[22:18] <ali1234> it depends on the project
[22:18] <ali1234> some don't use lp for bug tracking
[22:19] <courrier> oh, I see. It's for pulseaudio
[22:19] <courrier> I've seen another repositery for pulseaudio, but I couldn't submit a bug there either
[22:20] <ali1234> i highly recommend you run "ubuntu-bug pulseaudio" to report the bug
[22:21] <courrier> ali1234: under Mint as well?
[22:21] <ali1234> no
[22:22] <cjwatson> http://www.linuxmint.com/getinvolved.php says they want bug reports at https://bugs.launchpad.net/linuxmint
[22:22] <ali1234> right, looking at that now
[22:23] <courrier> gosh, spaghetti bug submission =)
[22:23] <courrier> cjwatson: thanks :)
[22:24] <ali1234> well it's much easier if you don't use what essentially amounts to ubuntu with the serial numbers filed off :)
[22:26] <ali1234> i do kind of wish it was easier to report bugs against unofficial packages though
[22:26] <ali1234> for example, staging PPAs
[22:27] <courrier> ali1234: is that jealousy of Ubuntu forks?
[22:28] <ali1234> lol
[22:42] <courrier> AAAAaaaaaaaaaaaaaaaaarg, "Timeout error" in launchpad, my bug submission is lost x(
[22:43] <courrier> " Trying again in a couple of minutes might work.".... ok, but still need to rewrite everything :(
[22:45] <mapreri> courrier: if you are lucky clicking the back bottom of your browser might get you back right with your text
[22:45] <mapreri> (depends on the browser mood)
[22:46] <courrier> mapreri: this trick no longer works with Web2.0 usually
[22:47] <mapreri> it used to work with lp, at least
[22:47] <courrier> going back in this case returns to the bug search field before submission
[22:48] <courrier> I wish someone wrote a Firefox extension to record the very last text typed in a field before validating it
[22:49] <mapreri> i'd not be happy to run such a plugin, though, for reasons.
[22:49] <courrier> mapreri: privacy I assume?
[22:50] <mapreri> you assume right.
[22:50] <mapreri> even if the text i type is already "in the browser", that's anyway more things that read it.
[22:50] <courrier> mapreri: as long as it's opensource that shouldn't be an issue...
[22:51] <mapreri> courrier: nothing block an opensource project to do evil things.
[22:52] <courrier> mapreri: nope, but asking an opensource extension to record a field is as much dangerous as asking an opensource browser to sumbit the same field to my mind
[22:53] <mapreri> maybe


[08:20] <apw> djs, given the only thing you change is the kenrnel, that tends to indicate it is related to that rather doesn't it ?
[09:58] <ddalex> hi
[09:59] <ddalex> I'm getting errors with a ppa/mainline kernel
[09:59] <ddalex> where should I report them ?
[10:00] <ddalex> or, maybe, how ?
[10:03] <apw> ddalex, those are debugging tools, so mostly not supported, we may be interested in some classes of issues as they may indicate issues coming down the line
[10:04] <ddalex> apw, are these unmodified upstream kernels ? i.e. are the bug reports valid for bugzilla.kernel.org ?
[10:04] <apw> they are unmodified indeed, they have an ubuntu-like configuration applied but otehr than that no changes
[10:04] <apw> ddalex, so yes filing them upstream is not unreasonable
[10:05] <ddalex> thanks, I'll fill upstream
[12:09] <zyga> ogasawara: https://bugs.launchpad.net/snappy/+bug/1607344
[12:11] <ogasawara> zyga: thanks!
[13:27] <attente> does building the kernel require editing the Makefiles to disable -pie? is there some easier way to pass cflags into the build system?
[13:29] <apw> attente, which series are you building on, and which kernel are you trying to build.  depending on the combinations that can be true
[13:29] <apw> attente, though there is a patch in recent ubuntu kernels for that
[13:30] <attente> apw: building from git://kernel.ubuntu.com/ubuntu/ubuntu-yakkety.git
[13:31] <attente> apw: it's the current master with a small patch on top
[13:31] <attente> Ubuntu-4.4.0-22.40
[13:32] <apw> attente, right but what are you building that _on_ as a local host, you should be building it in a
[13:32] <apw> yakkety chroot, whcih wuold understand the pie bits
[13:33] <apw> though -22 is very old, why that one of all of them, maybe that is too old to have the fix
[13:33] <attente> apw: which branch is the development target?
[13:34] <apw> for the 4.4 that is in the xenial repositories, we're working on 4.6 in the yakkety repo
[14:44] <djs> apw: well, yes, the failure to decrypt the rootfs is definitely related to the kernel since that is the only thing changing
[14:45] <djs> apw: I'm wondering whether it's a timing problem of some sort, I was poking through the initramfs-tools scripts a bit trying to see where it might be getting stuck
[14:46] <djs> but so far no luck... booting with debug doesn't get me anywhere, the problem is earlier than that
[14:47] <apw> djs, it was 4.7 you were trying out wasn't it
[14:48] <djs> yeah
[14:48] <apw> i would guess we have something useful turned off in that 4.7 build, like an encryption algo or something
[14:50] <djs> yeah possibly... I was also looking over diffs between the 4.6.4 and 4.7.0 initrd and there definitely are some
[14:50] <djs> so do those builds get refreshed from time to time or are they static?
[14:53] <apw> builds are a one off, unless we find a clear config issue which gets fixed in our main branches, then i may chose to respin them
[14:54] <djs> ok, so do you have any suggestions on how I ought to proceed? my interest in newer kernels is support for newer hardware in the laptop I'm running on
[14:54] <djs> it's not too bad with 4.6.4 but I'm hoping a few issues will be fixed with 4.7


[00:18] <sergiusens> elopio: I hinted earlier that if we get the right mocking level I don't mind extending the unit tests for snapcraft itself
[00:19] <sergiusens> elopio: but there is no test code for that in there and I didn't want to deviate from the current status quo in my first contribution ;-)
[00:21] <sergiusens> elopio: and you last comment taken into account
[00:23] <elopio> sergiusens: top-approved.
[00:23] <elopio> sergiusens: I think I wouldn't want to mock hg, or git. But I don't like the tests written in those plainbox commands.
[00:23] <sergiusens> elopio: \o/ one more MP and I can build py2 and hg projects from the ether
[00:23] <elopio> I would prefer to have integration tests written in python.
[00:24] <sergiusens> elopio: heh, feel free to change it all ;-)
[00:24] <sergiusens> elopio: would it be python snippets given plainbox?
[00:24] <elopio> well, I first need a good reason to re-do all the work.
[00:25] <elopio> I'm not sure why do we want plainbox here. So I'll wait for our qa meeting next week to talk about it with zyga.
[00:25] <sergiusens> elopio: what I like of it being a script is that I can read all about it when it fails really easily, aside from that, nothing else; I prefer compiled languages these days to not run things and find typos along the way ;-)
[00:25] <elopio> he did a lot of work to get it working with plainbox, so...
[00:26] <elopio> what I don't like is the lack of cleanups, fixtures, assertions.
[00:46] <sergiusens> elopio: latest snapcraft is broken for me, can you check? I think it's 'self.recommends = options.recommends or False' whereas we probably want getattr there
[00:48] <elopio> sergiusens: what command are you running? Some commands work for me using trunk.
[00:49] <sergiusens> elopio: right, it's when executing certain projects that use the ubuntu plugin
[00:49] <sergiusens> elopio: http://paste.ubuntu.com/12010834/
[00:50] <sergiusens> elopio: that's what I mean
[00:50] <elopio> right, that looks good.
[00:50] <elopio> sergiusens: + one test, it would look perfect :)
[00:50] <sergiusens> elopio: let me propose an MP and see if I can write a small test
[00:52] <elopio> sergiusens: there's test_ubuntu_plugin.py
[00:55] <sergiusens> elopio: is there an assertNotRaises?
[00:56] <elopio> sergiusens: no, for that case what I do is just to end the test with the call.
[00:56] <elopio> if it raises something, the test will fail.
[00:57] <elopio> a comment saying like # The call should not raise an error. would be nice.
[01:02] <sergiusens> elopio: https://code.launchpad.net/~sergiusens/snapcraft/recommendedOptions/+merge/267119
[01:02] <sergiusens> elopio: took a slightly different approach
[02:16] <sergiusens> elopio: https://code.launchpad.net/~sergiusens/snapcraft/setuptools/+merge/267121
[02:16] <sergiusens> see if you have a better idea there
[03:39] <elopio> sergiusens: can't you specify the python-setuptools dependency in the yaml of your package?
[03:40] <elopio> there are other setup packages, so not all will require setuptools.
[03:43] <sergiusens> elopio: I can, but I thought it be pretty common
[03:44] <sergiusens> elopio: well now that I know about the 'after' keyword; but the PYTHONPATH gimmick would go where?
[03:44] <sergiusens> anyways, bed time :-)
[04:06] <ToyKeeper> Snapcraft looks very helpful...  am hoping to try it this week.  :)
[04:07] <ToyKeeper> (building and packaging a python-based network game)
[07:05] <fgimenez> good morning
[07:13] <dholbach> good morning
[08:54] <JamesTait> Good morning all; happy Fresh Breath Day! 😃
[10:29] <longsleep> i think i have found a bug in snapcraft ubuntu plugin, it does not fix up symlinks to folders, but it seems that os.walk does list symlinks to directories which exist in dirs rather than in files and the plugin only checks the files.
[10:29] <ogra_> well, i guess at this state snapcraft bugs are still pretty expected ;)
[10:30] <ogra_> file it :)
[10:30] <longsleep> right - my Python got a little rusty since Go is around ..
[11:17] <hio> what is the ETA?
[11:18] <ogra_> 7am on a sunday
[11:18] <hio> i mean the ETA of snappy
[11:18] <ogra_> for what exactly ?
[11:18] <hio> so that i can use it as my production server environment
[11:19] <ogra_> snappy is out there and is used by projects already ...
[11:20] <hio> ogra_: i cant find the iso download?
[11:20] <ogra_> really depends what you want to do with it
[11:20] <hio> well i told you: server for my webapps
[11:20] <sergiusens> hio: it's available on the major cloud envs already fwiw
[11:20] <hio> well i have a VPS / root server
[11:21] <hio> i need to install it there with an ISO
[11:21] <longsleep> ogra_: made a patch instead https://code.launchpad.net/~longsleep/snapcraft/snapcraft-dirs-symlink/+merge/267176
[11:21] <hio> and on vmplayer too
[11:21] <ogra_> there is no installer yet and it is currently mainly focusing on IoT, cloud and embedded
[11:22] <ogra_> you would have to boot from some other media and then dd the img file to disk ... not sure that will work with a VPS at all though ... since you often dont have control over the kernel in such setups
[11:22] <ogra_> and snappy has pretty specific requirements on the kernel config
[11:23] <ogra_> (and on the bootloader for all the rollback functionality)
[11:53] <Mikaela> hio: https://developer.ubuntu.com/en/snappy/start/
[12:44] <longsleep> So, someone would be so kind to review https://code.launchpad.net/~longsleep/snapcraft/snapcraft-dirs-symlink/+merge/267176 please
[13:50] <sergiusens> mterry: do you have your snapcraft project for the webcam thing available anywhere?
[13:53] <mterry> sergiusens, my own code for the demo is lp:~mterry/snapcraft/mitdemo (mostly just trunk's webcam-webui example + go-on-arm branch + a couple change to the webcam code to work in my case)
[14:00] <longsleep> mterry: have you seen https://code.launchpad.net/~longsleep/snapcraft/snapcraft-dirs-symlink/+merge/267176 - i think it is important to merge that asap to avoid problems with absolute directory links with the ubuntu plugin.
[14:01] <mterry> longsleep, yeah I did, thanks!  Good catch.  I approved it, but then noted that I realized that you weren't in the contributor agreement LP team.  Have you signed the contributor agreement?
[14:01] <longsleep> mterry: no i did not - can it be signed on compay level?
[14:02] <longsleep> company
[14:02] <mterry> longsleep, yes -- I gave a link in the MP
[14:02] <mterry> longsleep, www.ubuntu.com/legal/contributors
[14:02] <longsleep> oh i missed that sorry
[14:02] <mterry> longsleep, no worries, LP mail gets delayed or filtered weird sometimes  :)
[14:15] <longsleep> mterry: I gave the contributor agreement to my boss and he will eventually sign it. I think the symlink patch is trivial and you can just merge that. I will let you know when the agreement is signed. Let me know if you have any further comments to the debs plugin.
[14:16] <mterry> longsleep, I'm off tomorrow (and am switching teams shortly) -- you may want to poke mvo or rsalveti after today.  Just heads up  :)
[14:16] <mterry> longsleep, but understood re: symlink
[14:43] <longsleep> anyone got thoughts how to run multiple services from a single snap? I consider to use supervisord similar like it is used with Docker. What do you think?
[14:46] <ogra_> ARGH !
[14:46] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ ifconfig
[14:46] <ogra_> enxb827eb04db1c Link encap:Ethernet  HWaddr b8:27:eb:04:db:1c
[14:46] <ogra_>           inet6 addr: fe80::ba27:ebff:fe04:db1c/64 Scope:Link
[14:46] <ogra_> yay for discoverable interface names
[14:47] <longsleep> lol
[14:47] <ogra_> but even worse :/
[14:47] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ fw_printenv
[14:47] <ogra_> Warning: Bad CRC, using default environment
[14:47] <ogra_> damn
[14:48] <longsleep> 4 byte 5 byte problem?
[14:48] <longsleep> check the hexdump
[14:48] <ogra_> could be, not sure
[14:48] <ogra_> though no, the snappy code fails too
[14:49] <ogra_> and that should be safe against the header byte issues
[14:49] <longsleep> how did you create the file? saveenv?
[14:49] <ogra_> mkenvimage -s 131072 -o uboot.env uboot.env.in
[14:49] <longsleep> uh
[14:49] <ogra_> well, it works just fine in uboot
[14:50] <ogra_> and i see onyl 4 bytes in hexedit
[14:50] <longsleep> ogra_: try adding -r parameter to mkenvimage
[14:51] <ogra_> then uboot doesnt accept it anymore
[14:51] <longsleep> but the snappy tool loads it?
[14:51] <ogra_> though let me try again, might have been the other build
[14:51] <longsleep> then you have 4 bytes header if you did not add -r
[14:51] <longsleep> you have to use 5 bytes to make fw_* tools work
[14:52] <longsleep> (or change their config)
[14:52] <ogra_> reading uboot.env
[14:52] <ogra_> *** Warning - bad CRC, using default environment
[14:53] <longsleep> right, make sure you have #define CONFIG_ENV_SIZE                 (128 * 1024) and #define CONFIG_SYS_REDUNDAND_ENVIRONMENT in your u-boot config
[14:54] <longsleep> then you will have 5 bytes header and i guess it will just work
[14:54] <ogra_> ah, the latter was missing
[14:54] <ogra_> thanks !
[14:54] <longsleep> i hope that was it
[14:55] <joc_> could someone provide some assistance in checking whether an app we have snapped is running unconfined? (app is plainbox)
[14:55] <longsleep> ogra_: still trouble that the snappy tool fails to parse the env file with 4 byte though
[15:01] <ogra_> longsleep, thanks, that helped, looks all fine now
[15:02] <longsleep> ogra_: great
[15:06] <ogra_> so what the heck do i do with the NIC now :/
[15:07] <joc_> ogra_: ricmm might one you be able to help with the above please?
[15:08] <ogra_> joc_, sorry, i dont know how to determine that, perhaps from syslog
[15:08] <longsleep> ogra_: where does that name come from? Check /etc/udev/rules.d/70-persistent-net.rules i think it should define the name alias there
[15:09] <ogra_> well, where would that file come from on a readonly system ? :)
[15:09] <longsleep> that file is writable
[15:09] <ogra_> hmm, true
[15:09] <longsleep> if you do not have it, it explains the strange name
[15:10] <ogra_> right
[15:10] <ogra_> so why dont i have it :P
[15:10] <longsleep> now you are closer to the solution :D
[15:11] <longsleep> but it is good that you have a problem with that file, because i have one too :P
[15:11] <longsleep> (my nic is there twice with the same MAC)
[15:13] <longsleep> elopio: Hi, the symlink directory problem can be seen in openssl for example. I pull in the openssl debs file with my debs plugin.
[15:18] <joc_> hmm i'm seeing a lot of..
[15:18] <joc_> Aug  6 15:14:12 localhost kernel: [ 8857.835029] audit: type=1400 audit(1438874052.138:70): apparmor="DENIED" operation="open" profile="plainbox.sideload_plainbox_0.23.dev0" name="/proc/1162/fd/" pid=1162 comm="python3.4" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[15:19] <elopio> longsleep: ok, let me see if I can reproduce it.
[15:19] <elopio> thanks for the patch btw.
[15:21] <ogra_> joc_, that looks like confined (and with wrong profile actually)
[15:23] <longsleep> elopio: sure, to reproduce just add openssl package to a snapcraft file using the ubuntu plugin
[15:23] <joc_> ogra_: what looks wrong about the profile?
[15:23] <ogra_> you get denials
[15:28] <sergiusens> ogra_: seb128 is input known to not work in a kvm for ubuntu personal?
[15:28] <ogra_> worked for me ... but i last tested a month ago or so
[15:29] <ogra_> (mouse input)
[15:29] <sergiusens> ogra_: yeah, thats what I recall too, not anymore it seems :-P
[15:42] <ogra_> pitti, bah ... i cant get the network on my rpi 15.04 imae up anymore ... what was the magic incarnation to force it to be called eth0 ?
[15:43] <pitti> ogra_: see /usr/share/doc/udev/README.Debian.gz
[15:43] <ogra_> hmpf
[15:43] <pitti> ogra_: either boot with net.ifnames=0, or touch /etc/udev/rules.d/80-net-setup-link.rules
[15:43] <pitti> whatever is better
[15:44] <ogra_> i cant really fiddle with udev rules, this is a released image
[15:44] <ogra_> ah, that was what i was lookin for
[15:44] <ogra_> kernel cmdline ;)
[15:44] <ogra_> (for this image i can only change the bootloader setup actively )
[15:47] <longsleep> ogra_: Starting with v197 systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme ("eth0", "eth1", "wlan0", ...), but should fix real problems.
[15:47] <longsleep> ogra_: haha - "should fix real problems"
[15:47] <ogra_> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
[15:47] <ogra_> i got that in front of me :)
[15:48] <longsleep> interesting read
[15:48] <ogra_> doesnt mention the boot option at all !
[15:48] <longsleep> i wonder why the odroid does get named eth0
[15:48] <ogra_> oh, it does
[15:48] <longsleep> it does
[15:48] <ogra_> i just gave up reading to the end :P
[15:49] <longsleep> ogra_: why do you need to change it by the way, or why does the interface need to be named eth0?
[15:50] <ogra_> because the 15.04 image has /etc/network/interfaces.d/etc0 hardcoded by default
[15:50] <ogra_> *eth0
[15:50] <longsleep> ah
[15:50] <ogra_> that was only fixed in the rolling image
[15:51] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ fw_printenv board
[15:51] <ogra_> board=rpi_2
[15:51] <ogra_> :D
[15:51] <longsleep> (ODROIDC)root@odroid:~# fw_printenv board
[15:51] <longsleep> ## Error: "board" not defined
[15:51] <longsleep> should i have that?
[15:51] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat /proc/cpuinfo |grep erial
[15:51] <ogra_> Serial          : 000000008b04db1c
[15:51] <ogra_> \o/
[15:52] <ogra_> i doubt the odroid uses board= anywhere
[15:52] <ogra_> (i even doubt the rpi does :P but it is in teh default env)
[15:52] <longsleep> (ODROIDC)root@odroid:~# cat /proc/cpuinfo |grep Serial
[15:52] <longsleep> Serial		: 1b00000000000000
[15:52] <longsleep> i am not sure that serial of mine makes any sense
[15:53] <ogra_> well, nothing you need it for, do you ?
[15:53] <ogra_> rpi needs it for the codecs
[15:53] <longsleep> yes - well some snaps might want it
[15:53] <ogra_> mine here gets seeded from the binary blob bootloader
[15:55] <longsleep> mhm in u-boot i have a more complicated serial
[15:56] <ogra_> the rpi kernel accepts a cmdline option to set it
[15:56] <ogra_> perhaps the odroid has somethin similar
[15:57] <longsleep> no - i think the kernel has the means to read the serial directly
[15:58] <longsleep> what i do not understand why i get eth0 in my image
[15:58] <longsleep> shouldnt i have some other name as well ?
[16:01] <longsleep> well the serial is the same for the stock kernels from Hardkernel - at least its not my fault :)
[16:03] <longsleep> dpkg -l|grep systemd
[16:03] <longsleep> sorr
[16:03] <longsleep> y
[16:06] <ogra_> while you say systemd http://blog.darknedgy.net/technology/2015/08/05/0-androidinit/
[16:06] <ogra_> :D
[16:06] <ogra_> such an awesome trolling attempt :)
[16:06] <longsleep> ahaha
[16:06] <longsleep> nice
[16:22] <sergiusens> stgraber: hey, do you have an lxd snap for armhf?
[16:27] <cwayne> barry: hiya, was it you that was working on snaps based on .pex files?
[16:32] <cwayne>  barry: hiya, was it you that was working on snaps based on .pex files?
[16:32] <cwayne> (sorry if that repeated, my irc's been a bit wonky lately)
[16:33] <ogra_> ( RaspberryPi2)ubuntu@localhost:~$ cat /proc/device-tree/soc/i2c\@7e804000/status
[16:33] <ogra_> okay
[16:33] <ogra_> \o/
[16:48] <barry> cwayne: yep: http://www.wefearchange.org/2015/04/creating-python-snaps.html
[16:52] <cwayne_> barry, yeah, so I believe we'd basically followed that, and we seem to be having some confinement issues :/  getting the following denial: Aug  6 15:14:12 localhost kernel: [ 8857.835029] audit: type=1400 audit(1438874052.138:70): apparmor="DENIED" operation="open" profile="plainbox.sideload_plainbox_0.23.dev0" name="/proc/1162/fd/" pid=1162 comm="python3.4" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[16:52] <cwayne_> was wondering if that looked familiar
[16:56] <ogra_> tyhicks might be able to help
[16:57] <ogra_> being our fake jdstrand this week :)
[16:58] <tyhicks> I can but I'll need a bit so I can finish something up
[16:58] <cwayne_> tyhicks, hiya :)  any advice ^  I think we have security_template: unconfined set, so i imagine we should have access
[16:58] <cwayne_> ah, ok
[17:20]  * ogra_ tries snappy update on the rpi and crosses fingers
[17:21] <ogra_> (using image 8 from 15.04 alpha)
[17:24] <elopio> mterry: longsleep: https://code.launchpad.net/~elopio/snapcraft/symlinks/+merge/267218
[17:24] <elopio> there are tests that check symlinks to directories. I think your bug is slightly different to that.
[17:25] <ogra_> yay, boots from b :D
[17:26]  * ogra_ tries rollback
[17:28] <barry> cwayne: yeah, that doesn't ring a bell.  must be a new constraint since i wrote that blog
[17:34] <tyhicks> cwayne_: ok, looking now
[17:38] <elopio> longsleep: these are your problematic links, right?
[17:38] <elopio> /tmp/stage/usr/lib/ssl/private
[17:38] <elopio> /tmp/stage/usr/lib/ssl/certs
[17:39] <elopio> um, no, those should work fine too.
[17:39] <elopio> I'm confused.
[17:41] <stgraber> sergiusens: sorta. I have one but it doesn't work. It's on my todo for next week to fix.
[17:55] <elopio> ahh, I get it.
[17:55] <elopio> the link destination must be an existing directory.
[17:55] <longsleep> elopio: yes
[17:55] <elopio> that's the bug in the original test.
[17:55] <longsleep> if it is existing (means not broken) then it ends up as dir
[17:57] <sergiusens> stgraber: thanks for the update!
[17:57] <longsleep> elopio: and for openssl these dirs probably always exist
[18:00] <longsleep> other question, snappy port conflicts - is the negotiable key actually implemented? How do i know which port i should listen?
[18:02] <cwayne_> tyhicks, the thing we're talking about is plainbox btw, (lp:checkbox, then the manifest is in checkbox/plainbox/Makefile)
[18:13] <ogra_> elopio, if you feel like http://people.canonical.com/~ogra/snappy/test/ has two rpi images, one built from stable 15.04 that i plan to release and one built from the 15.04 alpha channel with --revision=-1 for testing upgrade/rollback
[18:14] <ogra_> (not urgent, but i would like someone else but me test it additionally before i release ... as extra datapoint)
[18:14] <ogra_> kivi, ^^^
[18:14] <kivi> ogra_, ?
[18:14] <elopio> longsleep: sorry for being so dense. This should expose the bug and confirm your fix:
[18:14] <elopio> https://code.launchpad.net/~elopio/snapcraft/symlinks-2/+merge/267240
[18:15] <ogra_> kivi, err, ignore that ... tab mistmatch :)
[18:15] <ogra_> kyrofa, ^^^
[18:15] <elopio> ogra_: ok, I'll check after lunch.
[18:15] <elopio> ogra_: I thought updates were not psosible with rpi.
[18:15] <ogra_> i plan to release it tomorrow, so no hurry
[18:16] <ogra_> elopio, kernel/oem updates arent
[18:16] <ogra_> ubuntu-core wasnt until we fixed our uboot setup to use the uboot.env file ;)
[18:16] <ogra_> so now pi users can at least get rootfs updates :)
[18:16] <elopio> I see, that's nice.
[18:17] <ogra_> yep
[18:17] <ogra_> i2c should work too
[18:17] <ogra_> (not that we ship any tools to test it actually though :P )
[18:19] <elopio> woot for i2c.
[18:19] <elopio> now I don't want to have lunch.
[18:20] <ogra_> lol
[18:20] <ogra_> there is also a way to use pverlay DTBs but i need to document that ... it isnt straightdforward until sergio adds directory support for oem snaps to u-d-f
[18:21] <ogra_> *overlay
[18:21] <kivi> ogra_, Aww... I thought I was special...
[18:21]  * ogra_ hugs kivi
[18:23] <kivi> !hugs
[18:23] <kivi> ubottu can't hug...
[18:41] <tyhicks> cwayne_: my apologies, too many distractions for me today
[18:42] <tyhicks> cwayne_: can you paste the relevant plainbox file in /var/lib/apparmor/profiles/ ?
[18:43] <tyhicks> cwayne_: there should be 1 per binary but it looks like you only have 1 binary
[19:34] <cwayne_> tyhicks, sorry, was afk for a bit: http://paste.ubuntu.com/12013969/
[19:35] <tyhicks> cwayne_: ah, that's definitely not the unconfined template
[19:35] <tyhicks> # Description: default AppArmor template
[19:40] <cwayne_> ah, so are we setting it incorrectly?
[19:41] <tyhicks> cwayne_: that's what I'm looking into
[19:42] <tyhicks> https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
[19:43] <tyhicks> cwayne_: ^ that page suggests that security-template is specified underneath 'binaries:'
[19:43] <tyhicks> (all the examples show it underneath 'services:' but I think that should be interchangeable)
[19:57] <cwayne_> tyhicks, hm ok, i think that may be it then, will play around with it
[19:57] <cwayne_> tyhicks, thanks for taking a look!
[20:01] <tyhicks> cwayne_: no problem - let me know if you still have trouble and I can dig some more


[02:06] <astroo-> ciao pessoal
[20:44] <astroo-> ola pessoal
[23:37] <astroo-> Mozilla lashes Out at CISPA; First Major Player to Do So
[23:37] <astroo-> http://www.devicemag.com/2012/05/02/mozilla-lashes-out-at-cispa-first-major-player-to-do-so/


[02:52] <lotuspsychje> good morning
[08:09] <ducasse> good morning
[08:12] <TJ-> 'morning
[13:53] <jeremy31> The MT76 fix is in proposed in kernel 5.4.0-61
[13:54] <lotuspsychje> tnx jeremy31
[13:55] <jeremy31> That was quick compared to the last fix I submitted
[13:56] <lotuspsychje> the customer box suffered it, has still hwe edge 5.8 now, so i guess he will be good for a while
[13:58] <jeremy31> I am putting 20.04 on a USB to install over 20.10 and see what happens when I install updates after installing without internet.  Find out why all these people are getting 5.8 on 20.04
[13:58] <lotuspsychje> yeah its weird man
[14:01] <TJ-> linux-generic-hwe-20.04 ?
[14:02] <lotuspsychje> TJ-: no, we had volunteers & users reporting fossa dragging kernel 5.8 on regular updates on 20.04
[14:02] <lotuspsychje> after that it started raining bugs of all kinds on 5.8
[14:03] <lotuspsychje> TJ-: jeremy31 had it on a clean install iso updates for example
[14:05] <TJ-> suggests something depending on a 5.8 package then
[14:07] <TJ-> aren't the latest 20.04 point releases using 5.8 ?
[14:07] <lotuspsychje> TJ-: think 20.04.2 planned 5.8
[14:08] <daftykins> dep was what i thought :) no exposure to those reporting though, so no action from me
[14:09] <daftykins> in general i'm pretty tired of the frequency of kernel emissions
[14:09] <TJ-> daftykins: devops taking over!
[14:09] <lotuspsychje> TJ-: from the kernel guys;  <klebers> By default the 20.04 media installs the hwe kernel for desktop images. The hwe meta was still pointing to the 5.4 generic kernel, until this week when we released an update to pull the hwe-5.8 backport
[14:10] <daftykins> that response is misleading to me, because it was never the case that 20.04.0 media would install HWE, so are they saying focal changed this behaviour?
[14:10] <daftykins> if so... disappointing
[14:11] <jeremy31> It will cause a lot more headaches
[14:14] <jeremy31> It is the case, linux-generic not installed but linux-generic-hwe-20.04 is on a fresh install
[14:15] <TJ-> yes, the manifects for the ISO contains
[14:15] <TJ-> inux-generic-hwe-20.04 <IP_ADDRESS>.34~20.04.19
[14:15] <TJ-> linux-headers-5.8.0-32-generic 5.8.0-32.34~20.04.1
[14:15] <TJ-> linux-headers-generic-hwe-20.04 <IP_ADDRESS>.34~20.04.19
[14:15] <TJ-> s/manifects/manifest/
[14:15] <daftykins> desktop .1 image?
[14:15] <jeremy31> desktop image, not a point release ISO
[14:15] <daftykins> oh eww
[14:16] <TJ-> 20.04.1 manifest still shows:
[14:16] <TJ-> linux-generic-hwe-20.04 <IP_ADDRESS>.46
[14:16] <TJ-> linux-headers-5.4.0-42 5.4.0-42.46
[14:16] <TJ-> linux-headers-5.4.0-42-generic 5.4.0-42.46
[14:16] <TJ-> linux-headers-generic-hwe-20.04 <IP_ADDRESS>.46
[14:16] <jeremy31> 20.04:  linux-generic-hwe-20.04:
[14:16] <jeremy31>   Installed: <IP_ADDRESS>.32
[14:16] <jeremy31>   Candidate: <IP_ADDRESS>.40~20.04.21
[14:17] <TJ-> yes, 20.04.0 shows linux-generic-hwe-20.04 <IP_ADDRESS>.46  HOWEVER if the user enables updates during install that'll pull in 5.8
[14:17] <lotuspsychje> tricky
[14:18] <jeremy31> Looks like the only fix to stay on 5.4 would be to install linux-generic before updates
[14:20] <TJ-> I'm not sure that'll work since linux-*generic/linux-generic-*hwe* don't Conflicts:/Replaces: each other
[14:20] <TJ-> maybe a pin ?
[14:20] <tomreyn> https://ubuntu.com/about/release-cycle#ubuntu-kernel-release-cycle discusses how it is meant to be
[14:20] <TJ-> no, that wouldn't do it if they're side-by-side, you'd need to remove the *hwe*
[14:20] <lotuspsychje> so that means all fresh users from now will result on 5.8?
[14:21] <jeremy31> Looks lika all 20.04
[14:21] <TJ-> lotuspsychje: yes, once they do the first package upgrade, either during install or later
[14:22] <jeremy31> Now that they switched the kernel linked to linux-generic-hwe
[14:22] <lotuspsychje> TJ-: so only offline boxes wont?
[14:23] <daftykins> lol who's offline
[14:23] <TJ-> lotuspsychje: I *think* that removing "linux-generic-hwe-20.04" before the first update/upgrade would keep on 5.4
[14:23] <lotuspsychje> we get some cool kids with 12.04 offline box questions here sometimes :p
[14:24] <daftykins> those are the fakes
[14:24] <TJ-> lotuspsychje: the manifest for the 20.04.0 ISO has "linux-generic-hwe-20.04 <IP_ADDRESS>.46" so you'd need to 'apt remove linux-generic-hwe-20.04 linux-headers-generic-hwe-20.04 linux-image-generic-hwe-20.04" and then "apt install linux-generic"
[14:27] <lotuspsychje> yikes
[14:27] <lotuspsychje> no wonder its raining bugs in -announce
[14:28] <jeremy31> nvidia, broadcom, virtualbox, and a bunch of others
[14:28] <TJ-> lotuspsychje: so "apt remove linux-*generic-hwe-20.04 && apt install linux-generic" I think
[14:29] <TJ-> all the out-of-tree modules that don't keep up
[14:30] <jeremy31> anything not backported from groovy
[14:31] <TJ-> has bcmwl been patched up ? I didn't notice that in launchpad earlier
[14:31] <jeremy31> That askubuntu link has a link to bcmwl for groovy
[14:33] <TJ-> oh yeah, minor ubuntu patch debian/patches/0028-add-support-for-linux-5.6.patch
[16:29] <daftykins> i was bored enough to just install from 20.04.0 media in a VM and spy 5.8.0 indeedy, tsk tsk
[16:31] <daftykins> however it ran through it even though i had specified no update during install, which i know is to be expected since i think it handles kernel update tasks regardless of your intention
[16:31] <jeremy31> daftykins: I installed without internet connected
[16:31] <daftykins> yeah i recall
[16:32] <daftykins> i was just going through the motions myself for fun, the above being my first choice
[16:45] <jeremy31> Going to cause quite a few duplicate bugs
[16:57] <daftykins> one thing i didn't quite grasp yet then, does it seem to be a new intention or an oversight?
[17:06] <daftykins> can confirm i purged linux-image-generic-hwe-20.04 and linux-generic-hwe-20.04 before reconnecting the network, running an apt update, then installing linux-generic
[17:19] <jeremy31> It would have to be a mistake as nobody using desktop would be left on LTS kernel anymore
[17:26] <daftykins> mmm
[17:35] <jeremy31> All I could find in release notes was:  Ubuntu Desktop flavour now always tracks HWE kernel (hardware enablement). It means that from 20.04.2 release Ubuntu Desktop will gain new major kernel versions every 6 months through to summer of 2022.
[17:41] <daftykins> hrmm
[17:42] <jeremy31> About a month away from 20.04.2
[22:53] <nwotnagrom> anyone here trying to use ubuntu on other devices like a chromebook, iPad or other tablet?