[02:32] <Bashing-om> EriC^^: Still valid " Note: While the minimal iso image is handy, it isn't useful for installing on UEFI-based systems " ??
[02:32] <dax> debian's debian-installer works fine with UEFI, so hopefully not valid
[02:33] <Bashing-om> :)
[03:38] <bluefive> Do most applications rely on single thread performance?
[03:38] <bluefive> For instance, when I am upgrading my OS, is it the single thread performane that is the bottleneck?
[06:20] <lotuspsychje> this might be interesting for future support:
[06:20] <lotuspsychje> http://news.softpedia.com/news/canonical-recommends-open-source-amdgpu-and-radeon-drivers-for-ubuntu-16-04-lts-501556.shtml
[07:07] <bluefive> http://www.infoworld.com/article/2632284/web-browsers/mozilla-to-add-multithreading-to-firefox.html
[07:08] <bluefive> Does this mean that with two processors with equivalent single-thread performance, you would notice better responsiveness with Firefox with the one with significantly improved multi-thread performance?
[07:08] <lotuspsychje> bluefive: maybe the ##firefox guys might know this?
[07:09] <bluefive> You mean at irc.mozilla.org?
[07:10] <lotuspsychje> bluefive: no here on freenode
[07:11] <lotuspsychje> bluefive: #firefox sorry
[07:46] <dax> (crossposting from +1) anyway. another note to add to lotuspsychje's comment: fglrx is being deprecated by AMD upstream, it's not an Ubuntu-specific decision
[13:35] <BluesKaj> ohwdy folks
[13:36] <BluesKaj> howdy, even :-)
[16:59] <lotuspsychje> good afternoon
[17:36] <EriC^^> afternoon
[17:36] <lotuspsychje> hey EriC^^
[17:47] <lotuspsychje> EriC^^: seen this one mate, interesting for future support: http://news.softpedia.com/news/canonical-recommends-open-source-amdgpu-and-radeon-drivers-for-ubuntu-16-04-lts-501556.shtml
[19:22] <ilhami> !google ubuntu
[19:22] <ilhami> :D
[19:22] <ilhami> !google ubot5
[19:22] <ilhami> !wiki ubuntu
[19:22] <ilhami> !commands
[19:23] <ilhami> !help
[19:23] <ilhami> !patience
[19:23] <ilhami> !books
[19:23] <ilhami> !ban
[19:23] <ilhami> !behavior
[19:23] <ilhami> !etiquette
[19:23] <ilhami> !Etiquette
[19:23] <ilhami> :O
[19:49] <dax> !-etiquette
[19:49] <dax> hrm
[19:50] <dax> !search etiquette
[19:50] <dax> !-ban
[19:50] <dax> !ban =~ s/!Etiquette and //
[19:50] <dax> oh, right, ubot5 not ubottu


[13:36] <ClumsyTheFox> Hello
[13:37] <ClumsyTheFox> I have 2 questions about Lubuntu. Can i download a 32-bit release of the 20.1 LTS version and is it still aviliable with LXDE or is LXQT my only option? I want to install it on an old Toshiba laptop with a 32-bit Core Duo processor
[13:38] <Maik> there's no 20.1
[13:39] <Maik> and there's no 32 bit release anymore since 20.04, 64 bit only
[13:39] <Maik> if you need 32bit you need to switch to Debian
[13:39] <ClumsyTheFox> Oh sorry, 20.04. I mistaken the version with mint
[13:39] <ClumsyTheFox> Ok, thanks for the answer
[13:39] <Maik> no problem :)
[13:40] <ClumsyTheFox> Have a good one


[00:43] <kubotu> ::workspace-bugs:: [1119312] Desktop Effects keyboard shortcuts not saved @ https://bugs.launchpad.net/bugs/1119312 (by lordievader)
[02:50] <ScottK> Riddell: krfb works here.  It didn't work the first time I launched it, but it did the second.  No idea why.
[03:45] <ahoneybun> hey people!
[03:57] <ahoneybun> hey ScottK
[04:12] <ahoneybun> hey valorie
[04:49] <valorie> ahoneybun: here now
[06:27] <soee> good morning
[08:22] <Riddell> "Myriam Schweingruber (myriam) renewed their own membership in the Kubuntu Members (kubuntu-members) team" yay Mamarok still loves us!
[08:23] <smartboyhw_> Riddell: Meh if Mamarok isn't I will be O-mouthed
[08:24] <smartboyhw_> BTW, how is KDE SC 4.10.3 doing?
[08:26] <Riddell> see for yourself http://kyofel.dyndns.org/kubuntu/build_status_4.10.3_raring.html
[08:26] <smartboyhw_> Meh no one fixed it?
[08:27] <Mamarok> Riddell: what a silly assumption I would not still like you :)
[08:29] <smartboyhw_> Riddell: Anyone abandoned their membership in the past 12 months?
[08:30] <Mamarok> I use Kubuntu since its very existence, why would I abandon it?
[08:31] <smartboyhw_> Mamarok: You will not for sure.
[08:33] <Riddell> what small bugs shall we get agateau to fix?
[08:34] <smartboyhw_> Riddell: kactivities 4.10.3
[08:34] <smartboyhw_> It's crapped when cmaking
[08:37] <apachelogger> Riddell: ur such a stalker :P
[08:38] <smartboyhw_> apachelogger: lol
[10:17] <shadeslayer> yofel: hmm, how does one update the package in ninjas again :S
[10:38] <yofel> shadeslayer: huh?
[10:38] <shadeslayer> yofel: nvm :P
[10:39] <shadeslayer> did not have enough coffee and TT
[10:39] <yofel> smartboyhw_: kactivities is crapped because nepomuk-core needs an update
[10:39] <yofel> :D
[10:39] <shadeslayer> n-c is fixed
[10:39] <shadeslayer> just uploaded it
[11:16] <BluesKaj> Hey all
[11:16] <smartboyhw> Hello BluesKaj
[11:16] <BluesKaj> hi smartboyhw
[12:07] <Riddell> +           ) + i18n("
Kubuntu includes additions and alterations to the KDE translation from Launchpad.
");
[12:07] <Riddell> do we still need this?
[12:12] <Riddell> harald say no
[12:53] <ScottK> Riddell: What happened to you with krfb?  I made it work.
[13:34] <Riddell> ScottK: I really don't know
[13:34] <Riddell> ScottK: I made it work connecting to me, it just didn't connect from the withsupport office
[13:35] <ScottK> What VNC client where they using?
[13:35] <Riddell> it was connecting from an ubuntu machine so maybe there's something there
[13:35] <Riddell> but I've not looked any further than that
[13:35] <Riddell> maybe they were just doing something stupid
[13:35] <ScottK> I'd ask them what VNC client they were using as it seems to work with krdc.
[13:54] <smartboyhw_> apachelogger: Good guidelines
[14:11] <Riddell> kde telepathy's notification systray icon, should it blink?
[14:12] <yofel> IIRC there should be a seperate blinking envelope when you get a message
[14:13] <Riddell> yes that's what there is
[14:13] <Riddell> but should there be? from a nice design perspective
[14:13] <Riddell> I think it's annoying to have a blinking thing
[14:14] <yofel> I think that's very much personal preference. Most IM applications have some blinking thing for new messages
[14:14] <yofel> be it the application icon or something else
[14:15] <yofel> it could be redundant if you consider knotify to be responsible for that
[14:16] <shadeslayer> Martin says it's very heavy on kwin
[14:16] <yofel> because it's an animation? rendering some 16x16 px shouldn't be that heavy...
[14:17] <shadeslayer> I believe he said something about blur
[14:17] <shadeslayer> I forget
[14:17] <yofel> oh, blur can be heavy, right
[14:18] <yofel> I personally could live without it - *IF* I could make the knotify icon red when something's up
[14:18] <yofel> I don't notice a small grey icon on a grey panel with a number on it unless I'm actually there when the full notification pops up
[14:26] <shadeslayer> yofel: turns out the entire panel is redrawn if the hardware doesn't support caching
[14:26] <yofel> ouch
[14:27] <smartboyhw> yofel: ?
[14:27] <yofel> ok, mine supports caching if I can trust the "show paint" effect
[14:27] <yofel> smartboyhw: <shadeslayer> yofel: turns out the entire panel is redrawn if the hardware doesn't support caching
[14:28] <smartboyhw> yofel: Eh
[14:54] <apachelogger> smartboyhw: <yofel> smartboyhw: <shadeslayer> yofel: turns out the entire panel is redrawn if the hardware doesn't support caching
[14:56] <smartboyhw> apachelogger: You quoted too many people
[14:57] <apachelogger> I thought we were playing a game
[14:57] <smartboyhw> apachelogger: … No we are not.
[14:58] <apachelogger> :O
[14:59] <smartboyhw> apachelogger: lol
[16:07]  * Riddell spots https://blueprints.launchpad.net/ubuntu/+spec/client-1303-webkit-maintenance
[16:08] <ScottK> Seems rather incomplete.
[16:42] <apachelogger> Darkwing: yofel: shadeslayer: there are  2 pending questions on the mailing list for you guys....
[16:43] <shadeslayer> I have half a reply in my draft
[16:44] <apachelogger> that does not help me now does it :P
[16:44] <shadeslayer> I am sleepy
[16:45] <shadeslayer> coffee didn't help
[16:45] <apachelogger> cry me a river
[16:46] <shadeslayer> apachelogger: Barcelona has no river
[16:46] <apachelogger> that's why you are supposed to cry me one.....
[16:47] <shadeslayer> I don't think it works that way
[16:48] <apachelogger> it is
[16:48] <apachelogger> trust me
[16:48] <apachelogger> I am austrian.
[16:48] <shadeslayer> and that's exactly why I don't trust you
[16:48] <shadeslayer> 4.10.3 packages are just weird on the status page
[16:48] <shadeslayer> E: libkwineffects1abi4: symbols-file-contains-current-version-with-debian-revision on symbol _ZN4KWin15AnimationEffect25disconnectGeometryChangesEv@ABI_1_4
[16:49] <shadeslayer> I don't see the debian revision in there
[16:52] <debfx> look into the log file
[17:05] <mitya57> shadeslayer: re okular (again): I tried to change the ABI version, but the build still produces usr/lib/libokularcore.so.2abi1
[17:06] <mitya57> should I have a libokularcore2abi2 package providing a .so.2abi1 library?
[17:07] <shadeslayer> uh no
[17:07] <shadeslayer> apachelogger: ^^
[17:08] <mitya57> (detais are in bug 117943 I've filed today)
[17:08] <mitya57> *details
[17:09] <mitya57> *bug 1176943
[17:11] <apachelogger> shadeslayer: ?
[17:11] <shadeslayer> nvm
[17:11] <shadeslayer> mitya57: X-Debian-ABI: 1
[17:12] <apachelogger> ur such a troll
[17:12] <shadeslayer> mitya57: you need to bump that
[17:12] <mitya57> shadeslayer: ah thanks, didn't notice that
[17:12] <shadeslayer> np
[17:13] <apachelogger> someone please make sure albert is ok with the bump
[17:14] <mitya57> pushed to lp:~mitya57/kubuntu-packaging/okular, will submit a mp if/when it builds
[17:15] <apachelogger> shadeslayer: ^
[17:15] <apachelogger> shadeslayer: ^^^^^
[17:15] <shadeslayer> apachelogger: ^^
[17:15] <shadeslayer> apachelogger: ^^^^^
[17:15] <apachelogger> did anyone do that?
[17:16] <shadeslayer> do what
 someone please make sure albert is ok with the [abi] bump
[17:17] <shadeslayer> ah
[17:17] <shadeslayer> mitya57: ^^
[17:18] <mitya57> tsdgeos is not here
[17:18] <mitya57> will subscribe him to the bug
[17:18] <shadeslayer> #okular
[17:18] <apachelogger> awesome thanks
[17:20] <mitya57> s/the bug/the merge proposal/g, that'll make more sense
[17:20] <kubotu> mitya57 meant: "will subscribe him to the merge proposal"
[17:25] <shadeslayer> mitya57: btw please discuss with upstream before uploading anything
[17:25] <shadeslayer> just to make sure they're OK with it
[17:26]  * mitya57 thinks discussing with tsdgeos will be enough
[17:27] <Riddell> they're private symbols
[17:27] <Riddell> that's not an abi change
[17:27] <lordievader> Good evening.
[17:29] <mitya57> shadeslayer: ^^
[17:34] <Riddell> mitya57: they're all private symbols, it's fine for gcc to optimise them away
[17:34] <Riddell> no abi change
[17:34] <mitya57> OK, actually I thought about that but was not sure enough
[17:36] <mitya57> can one of you then pull ~mitya57/kubuntu-packaging/okular into the main branch? I've undone the package name change
[17:38] <Riddell> mitya57: let me look
[17:38] <mitya57> wait a second, I'll add a bug reference
[17:38] <mitya57> done
[17:39] <kubotu> ::workspace-bugs:: [1174495] kwin instability with r600 radeon and high monitor resolutions @ https://bugs.launchpad.net/bugs/1174495 (by sfar)
[17:40] <Riddell> mitya57: that still does the abi change, it's not necessary
[17:41] <Riddell> mitya57: ah no it's all good
[17:44] <apachelogger> yofel: piiiiing
[17:44] <yofel> apachelogger: reserved pong
[17:45] <apachelogger> yofel: if I upload a patched .2 runtime now will you hate me?
[17:45] <apachelogger> i.e. it could wait until after .3
[17:45] <apachelogger> it's just that I have it ready now ^^
[17:45] <yofel> well, not really... as long as you later rebase .3 on the new .2
[17:45] <apachelogger> :O
[17:46] <apachelogger> I'll wait :P
[17:46] <yofel> we need an intact changelog... that's all
[17:46] <Riddell> mitya57: merged!
[17:46] <mitya57> thanks Riddel!
[17:52] <apachelogger> JontheEchidna: exams done yet?
[17:54] <JontheEchidna> apachelogger: nope, www.unh.edu/registrar/finals/finals_spring_2013.pdf
[17:56] <apachelogger> oh my
[17:56] <apachelogger> I'll poke you on thursday I suppose then :P
[17:56] <apachelogger> or next week or something
[17:56] <apachelogger> I have great plans for making updates less annoying :P
[17:56] <JontheEchidna> k ^^
[17:57] <JontheEchidna> apachelogger: though personally, I have exams on the 10th, 13th and 14th
[17:57] <JontheEchidna> so you could probably poke me wed. and it'd be ok
[17:58] <JontheEchidna> that's a list of all the possible times a final exam could be scheduled
[17:59] <apachelogger> ok, perfect
[18:18] <Riddell> hmm not much on http://summit.ubuntu.com/uds-1305/2013-05-14/
[18:21] <Riddell> Darkwing: fancy setting up a mumble call again for kubuntu?
[18:22] <Riddell> ScottK: "[PyQt] ANN: PyQt5 Snapshots Available" does that make you exsxcited?
[18:53] <ScottK> I already ping'ed xnox and mitya57.
[18:53] <ScottK> I'm hoping they are excited enough to package it.
[18:53] <shadeslayer> py-cited
[18:53] <Riddell> mirv?
[18:54]  * mitya57 is excited but lacks time, so won't be against xnox doing it :)
[18:57] <ScottK> mitya57: Find someone else that does ...
[18:57] <ScottK> BTW, sip4 will need to be updated too.
[18:58] <mitya57> that should be an easy thing
[19:00] <ScottK> mitya57: Excellent.  Thanks for working on it.
[19:00] <mitya57> ScottK: do you want me to commit it to svn?
[19:01] <ScottK> mitya57: I'd say first get it into Ubuntu and in bzr.  I'm not sure the state of Qt5 in Debian at the moment.
[19:01] <mitya57> it's in experimental
[19:01] <ScottK> There's a few things around sip4/PyQt4 that need sorting before I can put it in Debian anyway.
[19:02] <ScottK> Once I get the current sip4 in experimental sorted, then it could go there, but in the mean time, I'd get it in Ubuntu.
[19:02] <mitya57> by "it" I meant sip4...
[19:12] <ScottK> No, not yet.
[19:12] <ScottK> Just do Ubuntu.
[19:15] <ahoneybun> ScottK: Justodo Kubuntu.
[19:15] <ahoneybun> *Just do Kubuntu.
[19:15] <k1ck-soee> hiho, KDE 4.10.3 out ?
[19:15] <ScottK> ahoneybun: It's all one package archive.  I meant Ubuntu as in Ubuntu the distribution, not Ubuntu the desktop.
[19:22] <Riddell> soee: needs packaging
[19:22] <soee> Riddell, can't do that but i can test when ready :)
[19:22] <Riddell> hmm, do I want to remove all these ? Build-Depends: kde-sc-dev-latest (>= 4:4.10)
[19:23] <Riddell> (again)
[19:27] <ScottK> apachelogger: More plymouth fun: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1171099/comments/20
[19:28] <ScottK> JontheEchidna: KDE Bug 317858 seems to be reasonably hot.  Is a solution for that available?
[19:29] <JontheEchidna> There's not one yet
[19:29] <JontheEchidna> It's one that I thought I had fixed, but the solution didn't end up working
[19:30] <ScottK> OK.  Thanks for working on it.
[19:32] <JontheEchidna> It's one I can't reproduce, so any of my attempts are blind. (Timing related)
[19:33] <ScottK> I can reproduce it intermittently.
[19:33] <ahoneybun> ScottK: I know just joking ;)
[19:33] <ScottK> OK
[19:33] <ahoneybun> Hey Riddell
[19:33] <ScottK> Some people don't.
[19:42] <ahoneybun> Riddell: https://wiki.ubuntu.com/KubuntuDocs/RaringRingtail/Basics
[19:44] <yofel> Riddell: well, as long as we don't change the version in meta-kde, you could just leave it in
[19:46] <yofel> ScottK: the graphical splash not working with nvidia means it works be design, no?
[19:46] <yofel> an nouveau is buggy alright
[19:46] <ScottK> No idea.
[19:46] <yofel> *as designed - I meant
[19:47] <yofel> the nvidia driver expects the kernel to be in text mode. Thus you get the text splash
[19:47] <yofel> you can ofc. force a framebuffer, but IIRC that doesn't work in all cases
[20:01] <ahoneybun> is Kubuntu still using guarddog?
[20:03] <yofel> ahoneybun: looks very KDE3 to me, so no
[20:05] <ahoneybun> what does
[20:05] <apachelogger> ScottK: "buggy" probably means text splash :P
[20:05] <apachelogger> i.e. kubuntu-text
[20:08] <yofel> ahoneybun: guarddog
[20:08] <yofel> though I meant qt3
[20:09] <ahoneybun> yofel: yes what does Kubuntu use as a firewall right now?
[20:09] <yofel> ahoneybun: nothing
[20:09] <yofel> the successor was kcm-ufw which was removed after being unmaintained
[20:09] <ahoneybun> oh nice
[20:10] <ahoneybun> I guess I can take that out of the Docs
[20:11] <yofel> if someone would want to configure the firewall gufw would probably be the thing to use
[20:23] <tyrog> Hello everyone. Is it possible to use the Ubuntu LTS enablement stack in Kubuntu 12.04.2? thanks
[20:23] <ahoneybun> just was wondering if that was still in theree
[20:23] <ahoneybun> tyrog: Kubuntu uses the same software repos
[20:24] <tyrog> ahoneybun: is there no problem with dependencies?
[20:33] <ahoneybun> if they are the same versions, I'm not 100% sure
[20:33] <ahoneybun> we use the same packages
[20:38] <yofel> tyrog: none that can't be worked out at least. If there are it's mostly apt doing the wrong thing
[21:01] <apachelogger> agateau: kde:about-distro
[21:01] <agateau> apachelogger: \o/
[23:05] <shadeslayer> anyone working on getting the kscreen update in?
[23:05] <shadeslayer> in Raring
[23:10] <ScottK> Don't think so
[23:11] <shadeslayer> uhm, shouldn't we?
[23:14] <ScottK> Yes
[23:20] <shadeslayer> ScottK: I've uploaded libscreek into kubuntu-ppa/experimental
[23:20] <shadeslayer> *libkscreen
[23:20] <shadeslayer> once that's compiled I'll upload kscreen
[23:21] <ScottK> OK


[01:44]  * pwnguin just realized there's no c in persia's name
[01:44] <pwnguin> now it makes a lot more sense why he's in .jp
[01:45] <persia> Actually, the two are completely unrelated (although it does make transliteration easier)
[09:21] <eggonlea> does any body use ZSYNC to download 9.10? It reports 302 error. Seems ubuntu.com changed the file location and zsync cannot deal with http redirection.
[09:22] <eggonlea> I could use zsync for 9.10 alpha, beta and rc.
[09:22] <eggonlea> but failed on this final one.
[09:27] <eggonlea> [answer my own question] just use redirected cdn.release instead of the release server. :P
[09:30] <ogra> note that the servers are under heavy load during the first 10 days after release usually
[09:31] <eggonlea> /nod
[09:32] <eggonlea> hope all are using bt or zsync instead of downloading .iso/.img directly with multithread sw
[14:48] <kblin> oh well, I'm giving up for now. ARM hardware doesn't seem to be quite ready for prime-time yet
[14:50] <kblin> can't build products on systems that decide to sometimes do the right thing
[15:08] <suihkulokki> kblin: you are aware that how well usb works on beagleboard is not representantive of how all other arm works with usb?
[15:08] <kblin> suihkulokki: yeah, I tried a shevaplug as well
[15:10] <kblin> that was even worse :)
[15:11] <suihkulokki> kblin: hmm? apart for the bootloader not supporting usb, usb has been solid for me on sheeva
[15:11] <kblin> does IPv6 work for you?
[15:12] <kblin> no, the sheeva had other issues
[15:12] <kblin> not the least dying on me after two weeks
[15:12] <kblin> and the globalscale support really sucks, especially if you're outside the US
[15:14] <suihkulokki> haven't had a ipv6 setup for a while
[15:15] <kblin> the default kernel shipped with the sheeva claims to support ipv6, but is missing the kernel module
[15:16] <kblin> which severly screws up applications that try to support ipv6
[15:18] <kblin> I didn't get around to try a custom kernel, as my plug died before I could test
[16:06] <tordne> hi, i'm getting the mobile phone toshiba TG01, with a snapdragon processor
[16:08] <tordne> I want to install ubuntu on the phone, but i can't seem to find what to install on it.
[16:09] <tordne> the snapdragon is based on ARM that is why I ended up here
[16:09] <tordne> can someone tell me if I can install ubuntu-arm on the phone
[16:09] <tordne> thanks
[16:10] <kblin> unfortunately there's much more variety between ARMs than between x86-based chips
[16:11] <kblin> hard to give definite answers there
[16:13] <ojn> tordne: after a lot of work messing around with all sorts of stuff, you would in the end have a phone that you can't make calls with. Is that really what you want?
[16:14] <tordne> @ojn: yes
[16:14] <tordne> @no :-D
[16:15] <kblin> see, that's why open source is great
[16:15] <kblin> it's all about choice.. even if the choice is shooting yourself in the foot
[16:15] <tordne> I don
[16:15] <ojn> Linux is free only if your time has no value... :)
[16:16] <tordne> @ojn: no I wouldn't mind to mess up the phone
[16:17] <tordne> @ojn: but i like linux, and can program a bit... maybe this is a start for me to realize something
[16:40] <tordne> @ojn: I think I found something better "Mer linux"
[16:41] <BeardedChimp> Once I've created a tarball from the rootfsfromscratch, how do I install that to an sd card such that it is bootable? I tried just creating a big ext2 filesystem and extracting inside it but the arm board seemingly didn't boot from it
[16:42] <BeardedChimp> (I had already figured that it wouldnt work but gave it a shot anyway)
[16:43] <ojn> BeardedChimp: It depends on your board. Some firmware expects to read the kernel (or even the firmware itself) from a FAT partition at the beginning of the media. It's more of a board than a distro question
[16:45] <BeardedChimp> I have an image of their edge install floating about, I'm guessing I could work it out by having a peak inside?
[16:45] <ojn> probably, yes
[16:50] <BeardedChimp> http://pastebin.com/m2e5b4365 I think this is the relevant bit from the docs, bit beyond me at the minute
[16:53] <armin76> BeardedChimp: hope you didn't used karmic as rootfs
[16:54] <BeardedChimp> No :)
[16:54] <BeardedChimp> I figured that would be suicide
[16:55] <BeardedChimp> The board comes with sarge installed on it, but with support dropped for it, it aint great
[16:55] <ojn> dist-upgrade to etch?
[16:56] <BeardedChimp> tbh im looking for >.27 kernel
[16:56] <BeardedChimp> Which is why I went for ubuntu


[03:46] <skellat> Unit193: Do you have a moment?
[03:46] <Unit193> I might, and if not I'll in and out.
[03:47] <skellat> I needed to ask you about ubottu and what happened to it
[03:47] <skellat> So this is properly something to discuss over in #ubuntu-locoteams
[03:48] <Unit193> Ah, so it's missing from there.  Was it actually ubottu, or another ubot[1-5]?
[03:49] <skellat> I think it was ubottu proper
[03:50] <skellat> jose mentioned off-hand something went haywire and beyond that...bupkis
[03:51] <Unit193> /bots has it marked as ubot4, but you'll want to ping tsimpson over in #ubuntu-irc.
[03:51] <skellat> Okay
[03:51] <skellat> I'll put that on tomorrow's today list
[03:51] <skellat> All jose said was blame tsimpson and I was left scratching my head as to what that meant
[03:52] <Unit193> :D
[03:52] <Unit193> Only thing I could do is drop ubot93 in.
[03:52] <skellat> Which I noticed is in #ubuntu-release
[03:53] <skellat> ...
[03:53] <skellat> I'll do the ping tomorrow
[03:53] <Unit193> Alrighty.
[03:53] <skellat> I may see about setting up a Vanguard schedule for LoCo Council members to actually sit on-channel to be available
[03:53] <skellat> Akin to #canonical-sysadmin
[03:54] <skellat> Thank you Unit193 for your aid
[03:54] <Unit193> -sysadmin needs it more than -loco does.  Sure thing.
[04:52]  * Derath-Srvr yawns
[08:24]  * Unit193 pokes Derath-Srvr.
[12:06]  * Derath-Srvr draws on Unit193's face with a marker


[00:01] <Mongo44> That jockey-text doesn't work.
[00:05] <Mongo44> I know Debian works maybe I will just create a Jessie VM.
[00:14] <holstein> Mongo44: i know *buntu works.. but, if you are more comfortable configuring debian, you can install lxde there
[00:15] <holstein> Mongo44: software-properties-gtk --open-tab=4 did what?
[01:11] <Mongo44> holstein, that last command?
[01:12] <holstein> Mongo44: ?
[01:12] <Mongo44> software-properties-gtk --open-tab=4
[01:13] <holstein> Mongo44: ok. what about it?
[01:13] <Mongo44> Where did you find that?
[01:14] <holstein> Mongo44: i found it above where Unit193 pasted it in and suggested you run it, and i pasted it again and asked you to run it
[01:15] <holstein> Mongo44: so.. when you run that command, are you promted for the driver?
[01:18] <holstein> Mongo44: what happens when you try the software-properties-gtk --open-tab=4 command?
[01:19] <Mongo44> Using x86 virtualization solution.
[01:20] <Mongo44> Selected that now it is applying changes.
[01:23] <Mongo44> What is the advantage of having seperate partitions for home, var, usr, and tmp?
[01:23] <holstein> Mongo44: seperation
[01:23] <holstein> Mongo44: the default installation is all in one partition
[01:24] <Mongo44> Lubuntu seems to have frozen.
[01:24] <Mongo44> Still trying to apply changes.
[01:25] <holstein> Mongo44: seems?
[01:26] <Mongo44> I am setting up a new VM also.
[01:26] <Mongo44> Maybe I will just abort and try again.
[01:28] <Mongo44> My new VM has about 4 GB of RAM. I need a Swap of the same size too right?
[01:28] <holstein> you dont "need" anything
[01:29] <holstein> swap is a tool you can choose to implement
[01:40] <Mongo44> Still trying to apply additional driver.
[01:42] <Mongo44> I selected do not use. Earlier I had selected x86 virtualization solution but it froze when it tried to apply changes.
[01:42] <holstein> Mongo44: ok
[01:43] <Mongo44> So I will wait for this to apply and select it again.
[01:44] <holstein> sounds great.. enjoy!
[01:45] <Mongo44> You sound pretty optimistic.
[01:50] <Mongo44> Alright so still no 1366x768 resolution.
[01:50] <Mongo44> Do I need to use xrandr?
[01:51] <holstein> i know, i have never suggest xrandr
[01:52] <holstein> i use arandr as a GUI.. and have suggested that
[01:52] <holstein> you dont *need" 1366x768
[01:52] <holstein> and thats not the way it works with guests in VM, Mongo44
[01:52] <ianorlin> host+C plus maximize
[01:52] <ianorlin> or make it try to not strech hopefully
[01:52] <holstein> yup.. that should just mek the guest take up the space..
[01:52] <holstein> make*
[01:53] <holstein> you dont set the res like that on the guest
[01:53] <Mongo44> There is no reason 1366x768 shouldn't work.
[01:54] <holstein> Mongo44: its not the way you do the guest OS's
[01:54] <holstein> but, i'l keep quiet til you ask a question
[01:59] <Mongo44> arandr says the resoution isn't possible
[01:59] <holstein> ok
[02:00] <holstein> the guest should be able to expand to the host res.. by using the command ianorlin said.. or in the menu
[02:01] <Mongo44> I only have 640x480 that is quite a stretch.
[02:02] <Mongo44> It is not suitable.
[02:04] <holstein> it would be, if that were they way you did it
[02:04] <holstein> but, its not.. you just make the guest maximised, as i and ianorlin suggested
[02:05] <holstein> how does it look when you try to run it fullscreen?
[02:14] <Mongo44> For some reason it is now in 1024x768 again.
[02:15] <holstein> its likely becuase, its dynamic.. it changes as you resize the window.. its supposed to
[02:17] <Mongo44> Nope it stays at 1024x768.
[02:17] <holstein> Mongo44: not if you say it changed
[02:17] <holstein> Mongo44: you said it was one thing, then a different one.. that is *not* staying th esame
[02:18] <holstein> it either stays at 1024x768, or it was at 640x480 and now it is 1024x768..
[02:18] <Mongo44> I rebooted and it switched from 640x480 to 1024x768.
[02:18] <holstein> i think if you'll stop trying to set the guest sessions res, you'll be ahead of the game
[02:19] <holstein> Mongo44: do you understand? *dont* set the res of the guest inside the guest
[02:19] <holstein> Mongo44: you get the driver support for vbox setup properly, and it'll just dynamically work.. its always just worke out of the box for me, so i dont know what you have going on there
[02:20] <holstein> Mongo44: what iso's are you using? the lubuntu 32bit?
[02:20] <Mongo44> Nah 64 bit.
[02:20] <holstein> Mongo44: ok.. *what* *specifically* did you use? what iso's?
[02:21] <Mongo44> lubuntu-13.10-desktop-amd64.iso
[02:22] <holstein> on both the host and guest?
[02:22] <ianorlin> by streched do you mean the aspect ratio is wrong on maximized?
[02:23] <Mongo44> No host is Wheezy.
[02:25] <ianorlin> keybind something in window manager to be 75% width and 100% height then it will not look skewed but I really only know how to do that in openbox
[02:28] <Mongo44> OBox better than VBox?
[02:28] <ianorlin> no openbox is the window manager for lubuntu
[02:29] <ianorlin> it draws the windows
[02:29] <holstein> they are not comparable
[02:29] <holstein> it was not intended as a replacement for virtualbox
[02:29] <Mongo44> Oh thought it is virtualization software.
[02:29] <ianorlin> Mongo44: your screen is 16x9 aspect ratio right?
[02:30] <Mongo44> How do I use Openbox?
[02:30] <holstein> Mongo44: you are using it
[02:30] <holstein> Mongo44: its the window manager for lubuntu.. for lxde.. so, in lubuntu and lxde you are using it
[02:31] <Mongo44> ianorlin, that is correct.
[02:40] <Mongo44> Alright I just made a Debian machine with the lxde kernel.
[02:40] <holstein> Mongo44: lxde is not a kernel.. and has no kernels
[02:41] <holstein> Mongo44: i would suggest using whatever kernels that distro provides, and the support venues they provide
[02:41] <Mongo44> Interface?
[02:41] <holstein> Mongo44: interface?
[02:43] <Mongo44> Just looking for correct term. Light Xorg Desktop Environment. That's it.
[03:49] <Mongo44> My new Debian lxde machine works just like it's supposed to.
[03:58] <holstein> !debian
[04:21] <Mongo44> What happens if you mix them up?
[04:23] <holstein> Mongo44: im going to assume you are talking about debian and ubuntu.. debian is the base for ubuntu, as the factoid i linked above states
[04:23] <holstein> you dont need to mix them up, and shouldnt have any need to, but on many levels, they will be very compatible
[04:24] <holstein> the biggest thing that happens when you mix them up is, you wont be running either one, officially.. so, your support options go upstream, where the upstream developers will likely conider the mixing of the 2 the cause of issues
[04:24] <holstein> but, the repos for debian and ubuntu contain most of the same packages, so you would have no need for mixing to aquire more or different packages
[04:25] <holstein> you might want or prefer debian testing to have the "bleeiding edge" newer versions, but, you can add those via PPA's in ubuntu
[04:25] <holstein> !ppa
[04:26] <Mongo44> Lexi, the VM, is back down to 640x480.
[04:26] <holstein> sure.. the issue is not lubuntu.. its njust a matter of learnig how to work with virtualbox
[06:19] <jirido> holstein: Hi are you there ?
[13:55] <Slit> Hi! I am trying to install Lubuntu on PowerPc mac mini. I tried Live CD everything looks to work ok (only graphic is on 800x600) but I don't have wifi. I am new to Linux so not knowing much...
[20:10] <cyborg4> Hey, I just got Lubuntu on a 507mb laptop with an Intel Pentium 4 processor. Recommendations on what projects to do / software to download / stuff?
[20:12] <ianorlin> cyborg4: depends what you want and like as this gets down to personal prefrence
[20:13] <cyborg4> ianorlin: i'm very techy! got a few things here already (the basics, teamviewer, skype, python GUI etc)
[20:13] <ianorlin> I like htop more than the lxtask but that is just me
[20:13] <ianorlin> ncdu is nice for going thorugh what folders take up how much space
[20:14] <n-iCe> hello my laptop is not sending the audio through the hdmi cable, to the tv any idea? I can see image though
[20:14] <cyborg4> hmm
[20:15] <cyborg4> n-iCe: is your TV compatible with HDMI audio? does it work with other devices?
[20:16] <n-iCe> uhm
[20:16] <n-iCe> I assume it does
[20:16] <n-iCe> is not the idea of hdmi?
[20:16] <ianorlin> http://ubuntuforums.org/showthread.php?t=2152486 is a thread on this with lots of tries to fix it
[20:16] <cyborg4> n-iCe: older ones may not be compatible
[20:22] <n-iCe> Codec: Realtek ALC269
[20:25] <n-iCe> ok
[20:26] <n-iCe> the tv works with audio
[20:26] <n-iCe> just tried, so is lubuntu
[20:31] <n-iCe> can't make it work
[20:31] <n-iCe> :(
[20:58] <n-iCe> solved it, with the grub thing
[20:58] <n-iCe> thanks


[13:07] <frankban> tvansteenburgh, Makyo: could you please take a look at https://code.launchpad.net/~frankban/juju-deployer/unit-placement-fix/+merge/267187 ?
[13:08] <tvansteenburgh> frankban: looking now, thanks!
[13:08] <frankban> tvansteenburgh: ty!
[13:45] <frankban> tvansteenburgh: ty for the review! patch_env_status is used to avoid the sleep loops on add_unit FYI
[13:45] <frankban> tvansteenburgh: can I remove also the reloaded stuff?
[13:46] <tvansteenburgh> frankban: yes please do!
[13:46] <frankban> tvansteenburgh: cool I will
[13:46] <frankban> tvansteenburgh: also I'd like to go ahead and release a 5.0.1 (pypi and juju stable ppa) after this is landed, if you agree
[13:47] <tvansteenburgh> 0.5.1 i assume, and yes i agree
[13:47] <frankban> yes 0.5.1 it is, thanks
[14:43] <frankban> tvansteenburgh: mp updated, if you approve the branch I'll go ahead and merge/rlease it
[14:44] <tvansteenburgh> frankban: looking
[14:49] <tvansteenburgh> frankban: approved, thanks
[14:50] <frankban> tvansteenburgh: great thank you, I'll ship 0.5.1 tomorrow
[14:50] <tvansteenburgh> frankban: excellent
[14:59] <frankban> tvansteenburgh: it seems that I cannot merge that branch: bzr: ERROR: Cannot lock LockDir(chroot-90063440:///%2Bbranch/juju-deployer/.bzr/branch/lock): Transport operation not possible: readonly transport
[15:05] <tvansteenburgh> frankban: want me to try it?
[15:10] <tvansteenburgh> frankban: merged
[15:19] <frankban> tvansteenburgh: sorry was on call, ty!
[15:23] <tvansteenburgh> frankban: np, would you like me to upload to pypi?
[15:23] <frankban> tvansteenburgh: yes please, I'll make the PPA release tomorrow
[15:24] <tvansteenburgh> frankban: done
[15:24] <frankban> \o/


[03:00] <Bashing-om> !backbox
[03:00] <ubot5`> Backbox Linux is not a supported derivative of Ubuntu and is thus not supported in #ubuntu. Please use #backbox on irc.autistici.org or https://forum.backbox.org/ for help with it.
[04:31] <lotuspsychje> good morning to all
[04:32] <lotuspsychje> !kylin
[04:32] <ubot5`> Ubuntu Kylin is a variant of Ubuntu that focuses on Chinese users. It is an official part of Ubuntu. For more information, see http://www.ubuntu.com/desktop/ubuntukylin
[04:33] <lotuspsychje> bah
[04:34] <pragmaticenigma> what are you looking for there lotuspsychje
[04:34] <lotuspsychje> all the factoids i try to change and suggest never get fixxed
[04:35] <lotuspsychje> pragmaticenigma: <lotuspsychje> !kylin is please update url 404, add channel tnx
 Your edit request has been forwarded to #ubuntu-ops.  Thank you for your attention to detail
[04:37] <Bashing-om> lotuspsychje: Your startup bug. My issue does not seem to be related. My blame log: http://termbin.com/l4zg . super fast, no ?
[04:37] <lotuspsychje> lets check
[04:38] <lotuspsychje> Bashing-om: yes thats very quick
[04:38] <lotuspsychje> not sure why it hangs on my side..
[04:39] <kostkon> http://bbcsfx.acropolis.org.uk/  search for "computer" and enjoy the background hum..
[04:39] <Bashing-om> lotuspsychje: I do have something that takes a long time to start the desktop . Not taken the time yet to investigate ... 12 seconds !
[04:40] <lotuspsychje> Bashing-om: systemd-analyze critical-chain
[04:42] <Bashing-om> lotuspsychje: Will see in the AM before I get all fired up :)
[04:42] <lotuspsychje> okay mate
[04:47] <pragmaticenigma> ugh... I dislike... just install so-in-so's ppa help in main
[04:47] <pragmaticenigma> and then they go silent when it doesn't work
[04:48] <Ben64> yep
[04:48] <Ben64> dude didn't even listen to the original request either, it doesn't solve the issue
[04:49] <kostkon> especially that PPA which contains loads of package and can mess up your system. im pretty sure if you run apt-get update apt-get upgrade after adding that PPA it'll update half your packages
[04:49] <Ben64> yeah those are annoying
[04:50] <kostkon> that's why i only add official ppas which contain only the project packages usually 1 or 2
[04:51] <Ben64> i have a few ppas... one for youtube-dl, google chrome, and wine
[04:51] <kostkon> and now i find myself using snaps whenever i can
[04:51] <kostkon> yep
[04:51] <Ben64> made my own ppa but couldn't get it to build properly so it has nothing in it, but i added that one too :D
[04:52] <pragmaticenigma> I use PPAs after really looking hard at what they provide
[04:52] <Ben64> https://launchpad.net/~ben64/+archive/ubuntu/virtualization
[04:52] <Ben64> it's really confusing :(
[04:52] <kostkon> you'll get it eventually it's not that hard
[04:53] <Ben64> i can't figure out dependencies
[04:53] <pragmaticenigma> right now I have the one that provides Nvidia drivers from the Graphics Driver Team at Canonical (repackaged Nvidia drivers with proper Ubuntu configurations)
[04:53] <kostkon> well it's got one package already
[04:54] <Ben64> failed to build
[04:54] <kostkon> pragmaticenigma, that's from canonical should be safe indeed
[04:57] <pragmaticenigma> kostkon, yeah... I got frustated with the propritary bundle in the main repo... was getting wicked tearing on video playback
[04:58] <pragmaticenigma> kostkon, part of it I blame on Unity and compiz... really hate that the "eye candy" affects performance so greatly
[04:59] <kostkon> you can set it to low-fx now if you want the've added the option
[05:00] <pragmaticenigma> kostkon, I've tried various tweaks, which end up with a finiky experience
[05:01] <pragmaticenigma> with 18.04 around the corner I'm being optomisitc that Gnome desktop will result in a better experience
[05:02] <kostkon> lol i wouldn't count on that
[05:02] <kostkon> gnome shell is even more finicky i believe
[05:03] <pragmaticenigma> I feel it has a bigger team on it... not just canonical
[05:05] <pragmaticenigma> It's my opinion that Canonical should have stuck with Gnome Desktop through and through. I know it didn't work well for mobile/touch platforms. It just has more experience behind it I feel
[05:08] <kostkon> yeah that's true but if you consider the fact that they still haven't managed to fix that major memory leak bug it offers some perspective on the limits and what the gnome team can generally accomplish in the given timeframe whatever this is i don't know how often they churn out major versions
[05:09] <kostkon> unity is a good DE. and if you actually think about it they've never abandoned gnome
[05:10] <kostkon> they never finished unity8 and unity7 is gnome based
[05:10] <Bashing-om> kostkon: Interesting article - fixed the memory leak - maybe : https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/ .
[05:10] <lotuspsychje> in 18.04 ppa adding will be even more easy i read
[05:12] <kostkon> Bashing-om, good to hear and let me say.. finally
[05:13] <Bashing-om> kostkon: +10 -
[05:13] <pragmaticenigma> kostkon, they figured out the memory leak
[05:14] <pragmaticenigma> kostkon, they just don't have an elegant fix yet. They're brute forcing at the moment till
[05:14] <lotuspsychje> pragmaticenigma: yeah i think the gnome guys are happy ubuntu taking over alot og bugs now
[05:15] <Bashing-om> Note that Gnome gave our Will Cook a pat on the back .
[05:16] <pragmaticenigma> My thought is that KDE and Gnome are the two mainstays of the community. If there is ever any hope of making Linux + Gnu a chance at becoming the average users option, we need to stick to what we know and what has the largest adoption
[05:17] <lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/gnome-shell
[05:17] <kostkon> pragmaticenigma, theyre doing a lot of gc it seems im ok with it as long as it works decently
[05:17] <pragmaticenigma> kostkon, the memory leak came from them deleating the root of the tree, instead of finding the root and deleting from its branches back down to root
[05:18] <lotuspsychje> we got all kinds of flavor lovers and new distro's comming out every day
[05:18] <pragmaticenigma> lotuspsychje, yes, but nearly every new distro that has had staying power has always choosen Gnome or KDE
[05:19] <lotuspsychje> true or xubuntu based
[05:20] <Bashing-om> Well; this flavor lover is going to call an end to this session .. \o
[05:21] <lotuspsychje> haha
[05:21] <lotuspsychje> bed lover
[05:21] <lotuspsychje> nite nite Bashing-om we take over from here now
[05:21] <lotuspsychje> Bashing-om: type sudo halt
[05:21] <lotuspsychje> -p
[05:22] <lotuspsychje> now
[05:22] <pragmaticenigma> hibernate is more apropos?
[05:22] <lotuspsychje> :p
[05:25] <kostkon> or use rtcwake
[05:26] <pragmaticenigma> think it's also time for me to go to hibernate
[05:27] <lotuspsychje> sleep well pragmaticenigma
[05:27] <Bashing-om> hibernate LOL ...laters .
[05:27] <pragmaticenigma> though I took a 5 hour nap earlier this afternoon which is really messing with my sleep desire now
[05:27] <lotuspsychje> pragmaticenigma: thats a good idea to feel real twilighted
[05:31] <pragmaticenigma> mm hmm
[05:31] <lotuspsychje> =p
[05:31] <lotuspsychje> i rather wakeup too early then in-between-naps
[05:32] <lotuspsychje> otherwise i feel too zombie
[05:37] <kostkon> it's lotuspsychje's turn to bail :P
[05:38] <lotuspsychje> he troll on us :p
[05:38] <kostkon> :(
[05:38] <lotuspsychje> !releasenotes
[05:38] <ubot5`> Ubuntu 16.04 (Xenial Xerus) release notes can be found here: https://wiki.ubuntu.com/XenialXerus/ReleaseNotes
[05:38] <kostkon> needs... updating
[05:39] <lotuspsychje> they gonna have so much work at final release..
[05:39] <kostkon> in a couple of days
[05:39] <kostkon> it's gonna be a good release
[05:39] <lotuspsychje> yeah
[05:39] <lotuspsychje> finally big changes :p
[05:40] <lotuspsychje> did you see the new welcome screen kostkon ?
[05:40] <kostkon> yeah good stuff
[05:40] <lotuspsychje> great for the newcommers :p
[05:41] <lotuspsychje> the livepatch...might skare a bit
[05:42] <kostkon> i hope so. livepatch a bit technical yeah they should have left it out
[05:42] <lotuspsychje> sky887: you see if you want, you can!
[05:42] <lotuspsychje> kostkon: yeah or some enable/disable in options right?
[05:43] <sky887> yep
[05:43] <sky887> but the offtopic channel THATs what really boggles me
[05:43] <kostkon> lotuspsychje, yep in system settings somewhere maybe in software settings or whatever it's called nowadays
[05:44] <lotuspsychje> sky887: register, identify
[05:44] <kostkon> !register
[05:44] <ubot5`> For information on registering your IRC nick, see https://help.ubuntu.com/community/InternetRelayChat/Registration - For any further help, ask in #freenode.
[05:44] <lotuspsychje> kostkon: found systemoptions/privacy/send info to canonical
[05:44] <sky887> NickServ	You are now identified for sky887.
[05:45] <kostkon> lotuspsychje, it's in there as well?
[05:45] <sky887> im using Polari, IS THAT A PROBLEM?
[05:45] <kostkon> or just the send your system info to canonical thingy?
[05:45] <lotuspsychje> kostkon: yes, aha found it livepatch is in software&sources now
[05:46] <kostkon> ah
[05:46] <kostkon> good
[05:46] <sky887> maybe a BANNED!
[05:46] <sky887> maybe im*
[05:46] <sky887> *weeps*
[05:47] <lotuspsychje> sky887: when joining a channel you should have error in the freenode status window
[05:48] <lotuspsychje> sky887: cannot join channel because...blabla
[05:48] <sky887> i cant access the freenode status window
[05:48] <lotuspsychje> why's that?
[05:48] <sky887> dunno 'ow rly
[05:48] <sky887> POLAAARiiiii
[05:48] <sky887> hehe :)
[05:48] <lotuspsychje> sky887: your not trolling on us now are you?
[05:48] <sky887> nope
[05:49] <kostkon> which channel are we talking about
[05:49] <lotuspsychje> he wants offtopic
[05:49] <kostkon> oh
[05:49] <lotuspsychje> thats registered?
[05:50] <sky887> what happend?
[05:50] <sky887> i want it
[05:50] <lotuspsychje> sky887: about what?
[05:50] <lotuspsychje> sky887: how about you install hexchat and try again
[05:51] <ducasse> good morning
[05:51] <lotuspsychje> hey ducasse
[05:51] <sky887> i really dont know how to see status msgs in Polari, maybe i should use another client - which ones are you using folkz?
[05:51] <lotuspsychje> sky887: i just suggested one
[05:51] <sky887> okay
[05:51] <sky887> ill do that then
[05:52] <sky887> but then i dont get the popups (or DO i?)
[05:52] <kostkon> polari? never heard of it
[05:52] <sky887> 'NOME
[05:52] <lotuspsychje> sky887: hexchat shows a nice freenode status window yes
[05:53] <lotuspsychje> sky887: then we will see why you cant join offtopic
[05:53] <sky887> Key, Ex-Chat it is
[05:53] <lotuspsychje> !xchat
[05:53] <ubot5`> xchat and xchat-gnome have not had stable releases in years. xchat was removed from Ubuntu for 16.04. Consider using hexchat instead, which is actively developed and available in 14.04 onwards.
[05:53] <sky887> Ok
[05:53] <lotuspsychje> ok
[05:53] <kostkon> sky887, lol no. hexchat. xchat is obsolete
[05:53] <sky887> !polari
[05:54] <sky887> yes ofc ofc i MEANT Hexchat
[05:54] <kostkon> of course you did
[05:54] <lotuspsychje> sky887: ok now less talk and action! :p
[05:55] <sky887> see ya soon!
[05:55] <sky887> im ON it
[05:55] <kostkon> where are you going :S
[05:55] <lotuspsychje> lol
[05:55] <kostkon> let's hope he rejoins
[05:55] <lotuspsychje> i specially invited him in discuss :p
[05:56] <lotuspsychje> its my new system, to avoid ramble in main...here we can take them right kostkon
[05:56] <kostkon> lol
[05:56] <lotuspsychje> haha
[05:59] <ducasse> morning lotuspsychje, how are you today?
[05:59] <lotuspsychje> great here ducasse
[05:59] <sky887> MADE it!
[05:59] <lotuspsychje> sky887: we can see it!
[06:00] <lotuspsychje> ducasse: cakes & coffee today :p
[06:00] <ducasse> lotuspsychje: have a fun b-day party :)
[06:00] <lotuspsychje> ty ducasse
[06:04] <lotuspsychje> ttyl guys
[06:04] <lotuspsychje> and have a nice day
[06:33] <guiverc> sky887, re: question in #ubuntu & 18.04 (not really a support issue, why I'm answering here) .. i suspect a few of us already use 18.04; at least on one machine..
[10:27] <BluesKaj> Howdy folks
[10:34] <ducasse> morning, BluesKaj - all well today?
[10:36] <BluesKaj> hey ducasse. well i have a cold, but otherwise ok
[10:36] <BluesKaj> how are you doing?
[10:37] <ducasse> ooof, hope you get better soon. i'm good thanks, thinking of taking a nap :)
[10:38] <sky887_> Hi all!
[10:38] <BluesKaj> thanks ducasse, it'll just have to run it's course...have a good nap...naps are good :-)
[10:38] <sky887_> :-):-)
[10:39] <BluesKaj> hi sky887_
[10:40] <ducasse> there's not much else to do, so thought i'd grab the opportunity
[10:43] <lotuspsychje> good afternoon to all
[10:43] <ducasse> hi lotuspsychje - how are you doing? party finished?
[10:43] <lotuspsychje> ducasse: no, we cleaned up now chill till party :p
[10:44] <lotuspsychje> cakes are here from bakery :p
[10:45] <lotuspsychje> ducasse: hows your day so far?
[10:45] <ducasse> cakes! \o/
[10:45] <ducasse> all quiet here, mate
[10:45] <lotuspsychje> raspberry PI cake and ananas cake
[10:46] <BluesKaj> Hey lotuspsychje
[10:47] <lotuspsychje> http://handmadehelen.nl/wp-content/uploads/2015/02/Chocolade-frambozen-mousse-taart-2.png
[10:47] <lotuspsychje> something like this
[10:47] <lotuspsychje> hey BluesKaj
[10:47] <lotuspsychje> did you have welcome screen on kde on bionic?
[10:48] <lotuspsychje> just got it after updates on desktop here
[10:48] <BluesKaj> justthe plymouth "kubuntu" logo
[10:49] <lotuspsychje> BluesKaj: how about livepatch screen?
[10:50] <BluesKaj> lotuspsychje, not that I'm aware
[10:50] <BluesKaj> i can reboot to have a look
[10:50] <lotuspsychje> BluesKaj: well actually makes sense, as the welcome screen is gnome related
[10:50] <BluesKaj> i'll check
[10:50] <lotuspsychje> so i presume only on ubuntu-desktop
[10:52] <BluesKaj> nope mjuat the regular K fanciful logo after the login
[10:52] <lotuspsychje> kk
[10:52] <BluesKaj> just
[10:53] <lotuspsychje> BluesKaj: so found out livepatch settings are now in software&sources
[10:54] <BluesKaj> which one /
[10:54] <BluesKaj> ?
[10:54] <lotuspsychje> BluesKaj: tab updates
[10:54] <lotuspsychje> BluesKaj: 'use canonical livepatch to...
[10:55] <BluesKaj> ppa?
[10:56] <lotuspsychje> BluesKaj: no, built in from canonical now
[10:56] <lotuspsychje> BluesKaj: wait lemme screenshot
[10:57] <BluesKaj> I use muo -legacy for app references, the new discovery one is awful
[10:57] <BluesKaj> muon
[10:59] <lotuspsychje> BluesKaj: https://imgur.com/a/x5jCf8g
[11:00] <lotuspsychje> BluesKaj: that livepatch popup screen also asks to enable/disable send system info the canonical
[11:01] <BluesKaj> no, don'[t have anything like that here
[11:06] <BluesKaj> I found the livepatch in the software center , but i prefer to do my  own updates/upgrades min the konsole, kde/plasma does do auto updates with the unattended upgrades app
[11:07] <lotuspsychje> yeah
[11:24] <lotuspsychje> hmm activities button got more cool now
[11:24] <lotuspsychje> mouse hover show all apps open
[11:30]  * BluesKaj uses the icons only taskbar for that
[11:31] <BluesKaj> well icons only task manager
[11:32] <sky887_> Is 18.04 released?
[11:32] <lotuspsychje> !isitoutyet
[11:32] <ubot5`> Not yet!
[11:32] <lotuspsychje> sky887_: but you can test/help bug the daily iso in #ubuntu+1
[11:33] <JimBuntu> !party
[11:33] <ubot5`> Please remember that #ubuntu, #kubuntu, #xubuntu, #edubuntu, and #lubuntu are support channels. To countdown to !bionic release and then party once it happens, join #ubuntu-release-party - For in-person parties, see http://loco.ubuntu.com/events/global/3339/
[11:34] <sky887_> Ok
[11:37] <lotuspsychje> sky887_: final release at 26 april
[11:37] <sky887_> Ok
[11:38] <lotuspsychje> sky887_: ltsupgrade from xenial, reccomended wait till june 18.04.1
[11:39] <sky887_> I won't wait :-)
[11:41] <lotuspsychje> sky887_: your the boss of your system
[11:42] <sky887_> I'm waiting til it arrives on the ubuntu site
[11:42] <sky887_> Oh I was mistaken. I do it just by the book
[11:43] <sky887_> *Scared*
[11:44] <sky887_> It arrives 26th of April on Ubuntu.com am I right?
[11:44] <lotuspsychje> sky887_: during the day yes
[11:45] <JimBuntu> https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes
[11:46] <lotuspsychje> nice page that
[11:46] <lotuspsychje> we should have it on trigger..
[11:46] <sky887_> Cool :-) lookin forward to it.  I have a pending or der on a new desktop PC as well. I'll install it instead of windowd
[11:46] <JimBuntu> "Python 2 is no longer installed by default. Python 3 has been updated to 3.6. This is the last LTS release to include Python 2 in main." <-- Me no likey
[11:47] <lotuspsychje> hmm
[11:47] <lotuspsychje> lotuspsychje@R00TB0X:~$ apt-cache policy python2.7
[11:47] <lotuspsychje> python2.7:
[11:47] <lotuspsychje>   Geïnstalleerd: 2.7.15~rc1-1
[11:48] <JimBuntu> I remember you mentioned it was installed lotuspsychje , I still don't like the release note. I'll find out for myself if it's in the live system shortly.
[11:49] <lotuspsychje> yeah
[11:57] <sky887_> Woo hoo it's released!!!!!
[11:57] <sky887_> *gotcha *
[11:57] <sky887_> For a sec anyhow
[12:01] <sky887_> Just being silly. Hehe
[12:01] <lotuspsychje> we almost believe you wow
[12:02] <sky887_> Yep for a sec cuz I'm the autorithy on this matter
[12:02] <sky887_> (NOT)
[12:05] <sky887_> Hm.. If i download it now. Will it be updated to its final version and beyond automatically?
[12:05] <lotuspsychje> !final | sky887_ no joke
[12:05] <ubot5`> sky887_ no joke: If you install a development version of Ubuntu bionic and keep up with package updates, then you will be upgraded to the official release of 18.04 when it comes out. To make sure, type « sudo apt update && sudo apt full-upgrade » in a terminal.
[12:05] <sky887_> I might just do that
[12:06] <sky887_> Ah interesting I'll copy that
[12:08] <sky887_> I'm on it!
[12:09] <lotuspsychje> good boy
[12:09] <lotuspsychje> another soul sold to ubuntu :p
[12:11] <sky887_> Ah heck yeah!
[12:16] <sky887_> I'd like to download am iso of the 18.04
[12:17] <sky887_> Where do I get it?
[12:18] <lotuspsychje> sky887_: http://cdimage.ubuntu.com/daily-live/current/
[12:19] <sky887_> Thanks
[17:08] <ducasse> what a special little snowflake
[17:09] <SlidingHorn> lol
[17:09] <ducasse> i'm guessing he gets to be pretty lonely
[17:10] <oerheks> i thought i gave the good direction..
[17:10] <oerheks> maybe one needs to logout/login for a ln to get active?
[17:11] <oerheks> never really got my hands dirty on that.
[17:12] <pragmaticenigma> oerheks, no... what they were trying to do was pointless.. moving the files to another folder and symlinking is the same as having the config file in the original place
[17:12] <pragmaticenigma> it doesn't hide anything
[17:13] <pragmaticenigma> oerheks, it's my guess... they are up to no good (!warez) and wanted our help in covering their tracks
[17:16] <ducasse> i can think of a reason, but i'm no longer very inclined to get involved :)
[17:17] <pragmaticenigma> is curious what ducasse thinks... oh well
[17:19] <ducasse> if you have an encrypted folder in your home, you might want to keep certain things like keys or config files with passwords etc there
[17:20] <pragmaticenigma> ducasse, but symlinking there would bypass that, no?
[17:20] <pragmaticenigma> ducasse, assuming the folder is unlocked
[17:21] <ducasse> yes, while the folder is unlocked it is just as accessible, but you can easily lock it
[17:22] <pragmaticenigma> but then the application wouldn't behave as expected since it's lost the ability to find it's config file
[17:23] <ducasse> true
[17:24] <ducasse> i'm not saying it's ideal, i'm considering it as a possibility
[17:24] <pragmaticenigma> yeah, I guess for the paranoid, there is a reason there is tails
[17:52] <lotuspsychje> good evening to all
[17:54] <SlidingHorn> howdy lotuspsychje
[17:54] <lotuspsychje> hey there SlidingHorn
[17:55] <ducasse> \o lotuspsychje
[17:55] <lotuspsychje> hey ducasse chill day?
[17:56] <ducasse> yup, making dinner now
[17:56] <lotuspsychje> cool bon apetit ducasse
[17:57] <ducasse> thanks :) how was your party? good cake? :)
[17:58] <lotuspsychje> yeah it was nice, and bread & sandwiches afterwards
[17:58] <lotuspsychje> sunny day again here
[18:25] <oerheks> no more warning for dirty languages :_D
[18:27] <pragmaticenigma> wha? oerheks
[18:28] <lotuspsychje> pragmaticenigma: cwr swearing
[18:29] <pragmaticenigma> lotuspsychje, oerheks - I'm not following what you're saying/meaning
[18:29] <oerheks> besides "I cant remember... " he used not welcome language
[18:30] <pragmaticenigma> yeah, but I don't follow how the "no more warning"
[18:31] <lotuspsychje> might mean he got enough of the swearing users :p
[18:34] <pragmaticenigma> I dunno... my head hurts too much to think further on it
[18:34] <pragmaticenigma> and the conspiracy topic in main is making it hurt more
[18:35] <lotuspsychje> what do you mean conspiracy pragmaticenigma ?
[18:35] <oerheks> oh that steamy guy ?
[18:36] <lotuspsychje> wauw dconf-editor pretty neat on bionic
[18:37] <lotuspsychje> !info dconf-editor bionic
[18:37] <ubot5`> dconf-editor (source: dconf-editor): simple configuration storage system - graphical editor. In component universe, is optional. Version 3.28.0-1 (bionic), package size 392 kB, installed size 2122 kB
[18:38] <SlidingHorn> lol oerheks - "you know what?  Fine.  Have at it."
[23:49] <bugzbunny> Have you people get over being upset me being here?
[23:57] <oerheks> yes, lets make you an Op
[23:59] <bugzie> My new nick will bugzie


[02:31] <Kon-> So it seems this is the continuously updated list of planned 32-bit support in Focal https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/i386/tree/i386


[17:52] <jono_> pleia2, akgraner the end time on the fridge post is still the old one, can you make it two hours earlier?
[17:52] <jono_> thanks!
[17:54] <pleia2> jono_: done
[17:55] <jono_> thanks pleia2


[02:59] <arraybolt3[m]> OK, I looked at the docs for `germinate`, and I understand what I'm looking at enough to be able to add qtxdg-tools to the seed. The problem is, I don't know how to properly test the changes I would make. I assume what I should do is:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/b5cc18cd47dd85fa2c184e0044bc1009478db4ba>)
[02:59] <arraybolt3[m]>  * OK, I looked at the docs for `germinate`, and I understand what I'm looking at enough to be able to add qtxdg-tools to the seed. The problem is, I don't know how to properly test the changes I would make. I assume what I should do is:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/02c4fa58dd130b4d471df529eae2ce973e6a9221>)
[03:00] <tsimonq2> That is the best, safest way to do it, I would agree with that much
[03:01] <arraybolt3[m]> Nice. I have to go afk again, but now we have a plan of attack. Thank you!
[03:45] <arraybolt3[m]> Simon Quigley: OK, this is the diff of the two germinate runs. It looks right to me, can I run it by you to make sure that it looks right to you too? https://termbin.com/dcvqb
[03:46] <arraybolt3[m]> (I just got all the seed files together, ran germinate with germinate -S file:///home/arraybolt3/Projects/ubuntu/lubuntu-seed -d lunar -s lubuntu -a amd64 -c main,universe,restricted,multiverse, put all the tons of output in one folder, added qtxdg-tools to the seed, ran it again, moved all that output to a second folder, then did diff -r -u run1 run2 on it.)
[03:47] <arraybolt3[m]> Also, the modification I made was:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/3a659fa603b50dc0252e910f623171457a372904>)
[03:47] <arraybolt3[m]> (I didn't put the comment in though :P)
[03:48] <arraybolt3[m]>  * (I just got all the seed files together, ran germinate with germinate -S file:///home/arraybolt3/Projects/ubuntu/lubuntu-seed -d lunar -s lubuntu -a amd64 -c main,universe,restricted,multiverse, put all the tons of output in one folder, added qtxdg-tools to the seed, ran germinate again, moved all that output to a second folder, then did diff -r -u run1 run2 on it.)
[04:29] <tsimonq2> The seed output looks correct. Remember to push a commit to the actual seed repo and use ./update for lubuntu-meta :)
[04:31] <arraybolt3[m]> Nice. (Forgot that I would need to update lubuntu-meta, thank you for the reminder!)
[04:36] <arraybolt3[m]> Simon Quigley: Last time we updated the seed and lubuntu-meta, I know the seed was on LP, but I *think* that lubuntu-meta is in Gitea and then uploaded to LP, right? Or did I forget where in LP I'm supposed to find lubuntu-meta?
[04:38] <arraybolt3[m]> (yikes, looks like we never uploaded it last time after updating it!)
[04:39] <arraybolt3[m]> (I guess that means it probably isn't in LP, then.)
[04:44] <tsimonq2> seed = only in LP under ~lubuntu-dev
[04:44] <tsimonq2> Metapackage should be updated in GiTea then uploaded as normal
[04:45] <arraybolt3[m]> OK, that's what I thought. (brain isn't working super-good right now, thanks for your help!)
[04:45] <arraybolt3[m]> One last thing - we didn't upload our last changes. Should I upload, update, and upload again, or just update and upload?
[04:45] <arraybolt3[m]> (I'm pretty sure that just updating and uploading is fine, but since this is new, I'd like to double-check these things.)
[04:51] <arraybolt3[m]> Actually, if I just add the new changes to the version we didn't upload yet, that will let us upload everything in one go.
 "OK, that's what I thought. (..." <- Ditto - been a long weekend and the week is just now starting!
 "One last thing - we didn't..." <- One upload is likely best, two would be redundant, no?
[04:56] <tsimonq2> Builder + publisher resources etc. (I mean, it's not like the first one will migrate before the second one is uploaded)
[04:57] <arraybolt3[m]> True. But an upload should only bump a package one version, right? That's where I was getting hung up - it didn't occur to me (until the last message) that I could just add more changes to the not-yet-uploaded version. But I can, which makes everything work right.
[05:28] <tsimonq2> Version numbers are cheap ;)
[05:30] <tsimonq2> (That took me time to learn; if you upload a version and it FTBFS, which will eventually happen to you, there's no way to remove a package from proposed and re-upload a version that has the same version)
 "[matrix] <kc2bez> Also, sorry..." <- Oh that sounds fun, /me looks
[15:50] <arraybolt3[m]> Dan Simmons, Simon Quigley: Asking for peer review on the latest changes to the meta, whenever you guys have time. I could just upload this and probably would if it was only qtxdg-tools that changed, but that update script also changed a debootstrap version number it looks like, so I'm a bit worried. Here's the diff (this includes all of the changes from last time, as well as the changes I made just now).
[15:50] <arraybolt3[m]> https://git.lubuntu.me/Lubuntu/lubuntu-meta/compare/ubuntu/22.10.3...ubuntu/lunar
[16:26] <Eickmeyer[m]> How's the updater looking these days?
 "How's the updater looking..." <- Better, the bug itself is fixed, we're still working on the workaround script. I intended on doing that today.
[16:48] <arraybolt3[m]> It will need a change made to the updater itself to make this stuff work, though. I'd say we're about halfway or more done.
[16:53] <Eickmeyer[m]> arraybolt3[m]: OK, keep me posted so I can unblock the sddm fix.
[16:53] <Eickmeyer[m]> Just bear in mind, though, that you're no longer racing sddm but unknown fixes that could cause the same problem.
[16:54] <arraybolt3[m]> Yes. I am well aware. There's just lots of other stuff that needs juggled, and I'm trying to help keep anything from falling through the cracks.
[16:55] <arraybolt3[m]> My main focus is going to be the fix for the updater today, hopefully we'll have something we can upload by tonight.
[16:55] <arraybolt3[m]> (And then we'll have to explain to the SRU team why allowing a patch that forcibly stops the update in some situations is a good idea, which may be... interesting :P)
[16:59] <Eickmeyer[m]> The core of the uphill battle is explaining why you're not simply using update-manager, which already provides the functionality. I mean, I get it, but there's a lot of nearsightedness going on, which comes down to a lack of maintenance of Qt frontends for certain tools, which comes down to another core problem that nobody is really talking about.
[17:04] <Eickmeyer[m]> I guess what I'm saying is, you don't have to explain why the tool exists, but you'll have to explain why a new feature needs to exist since it's causing a major usability issue. *But* they are coming at it from the perspective of "why does this even exist if this already does the job?"
[17:04] <Eickmeyer[m]> It's hard to remove bias.
[17:07] <arraybolt3[m]> It should be easy enough to explain. The new feature is needed because this tool is what's in use currently, and there's no way to swap out the tool and fix the bug at this point. The bug requires something to restart the updater in order to fix it, and the only updater that should accept something that hacky should be lubuntu-update-notifier. We fully intend to rewrite lubuntu-update-notifier to use update-manager, and there's
[17:07] <arraybolt3[m]> currently no Qt frontend for it that's good enough for Lubuntu so it will require us to rewrite it from scratch.
[17:07] <arraybolt3[m]> Replacing lubuntu-update-notifier with something else won't work here (and it would be too complex for an SRU anyway).
[17:08] <Eickmeyer[m]> I like that a lot. Not that my blessing is anything here, but that would convince the hell out of me. :)
[17:08] <arraybolt3[m]> Sounds good. /me buries my head back into the Debian Policy Manual to figure out what on earth I'm doing with a postinst script
[17:09] <Eickmeyer[m]> Hehe, think of a postinst script just like any other sh script with a few quirks.
[17:10] <arraybolt3[m]> That's what it looks like. I like some of the stuff like idempotency, that seems like a very good requirement for them to make.
[17:11] <arraybolt3[m]> (Obviously you know what it looks like, you've been doing this for way longer :P)
[17:11] <arraybolt3[m]> Thank you!
[17:11] <Eickmeyer[m]> No prob. Glad I can poke my head in and help.
[18:24] <arraybolt3[m]> Hey, I got autopkgtest to pass!
[18:25]  * arraybolt3[m] sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/d8c53972e4ac6e3f0867b976d9c8c599ac20a0ba
[18:26] <arraybolt3[m]> It doesn't like that I'm using killall, which I guess is reasonable. I may want to instead parse ps, extract the exact processes to kill, and kill those.
[18:26] <arraybolt3[m]> (I'm not worried about lubuntu-upgrader having a duplicate, but I can see that it's within the realm of possibility that something called "aptd" other than the "aptd" I'm targeting might exist.)
[18:27] <arraybolt3[m]> (Maybe I'll leave killall for lubuntu-upgrader for the sake of ease and simplicity, and use ps parsing to attack aptd.)
[18:34] <arraybolt3[m]> `killall -e "python3 /usr/sbin/aptd"` Nevermind, if *that* aptd isn't right where it should be, then something is dreadfully wrong. So that's safe to "killall" after all.
[18:46] <arraybolt3[m]> Hmm. So, it turns out killall matches process name, not full command line. Crud.
[18:47] <arraybolt3[m]> So I could probably nuke all python3 processes on the system, but not "/usr/bin/python3 /usr/sbin/aptd".
[18:47] <arraybolt3[m]> (And I get the distinct feeling that "killall /usr/bin/python3" won't get through SRU review...)
[18:48] <arraybolt3[m]> (warning, don't ever run the above command, for those who read the log)
[18:55] <arraybolt3[m]>  * (warning, don't EVER run the above command, for those who read the log, it may end up causing you to lose unsaved work or make your system otherwise behave wrong)
[20:03] <arraybolt3[m]> pkill looks like it might work.
[20:05] <arraybolt3[m]> pgrep looks handy too, that might reduce the complexity of some of the grep mess.
[21:28] <arraybolt3> The new lubuntu-meta successfully migrated to -release, shall I send the email asking for qtxdg-tools to be added to the Lubuntu packageset?
[21:31] <tsimonq2> +1
[21:39] <arraybolt3> Hmm, so I botched the email address. Sweet.
[21:39] <arraybolt3> Is it<EMAIL_ADDRESS>or<EMAIL_ADDRESS>[21:40] <tsimonq2> It's the latter
[21:40] <Eickmeyer[m]> 🪜
[21:41] <arraybolt3[m]> Alright, email sent successfully this time.
[21:41] <arraybolt3[m]> (cc'd it to the Lubuntu council and to Simon.)


[07:39] <ikt> hey all
[07:42] <Noskcaj> hello ikt
[07:48] <ikt> what's going on?
[07:48] <Noskcaj> not much.
[07:49] <Noskcaj> i have to go now, air force cadets
[14:10] <jared> ikt: that bitly stuff is a bit unsettling
[14:24] <jared> 2


[08:07] <KBar> Hi, Unit193. A follow-up to my previous question. After upgrading the Whisker Menu to the new version, I noticed that Xfce4 libraries were also bumped to version 4.16, which messed up my window decorations. I had to downgrade because of that, even though the Whisker Menu looks awesome and I loved it. I found these two commits: https://gitlab.xfce.org/panel-plugins/xfce4-whiskermenu-plugin/-/commits/main?search=horizontal
[08:07] <KBar> Would I be able to stay on version 2.4.3-1, grab the source code, apply just those changes locally and recompile?
[08:08] <Unit193> You can pop the two patches into ./debian/patches/ sure.
[08:09] <KBar> Awesome. Thank you.
[08:12] <Unit193> I mean I don't know specifically if those were work, but eh.  The panel doesn't search in /usr/local/ though so if you just compile it you'll have to set the prefix appropriately.
[08:13] <KBar> Hmm, I see. Gotta keep that in mind. Thanks for the heads up.
[13:25] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: xfce4-terminal 0.9.1 released @ http://www.mail-archive.com/xfce-announce@xfce.org/msg00641.html


[00:24] <pgraner_> ogasawara: ping
[00:25] <ogasawara> pgraner: pong
[00:27] <pgraner_> ogasawara: can you add https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/272885 to the list?
[00:27] <ubot3> Malone bug 272885 in linux-meta "linux-image package must depend on package grub" [Undecided,New]
[00:28] <pgraner_> ogasawara: I got bit buy this as well
[00:28] <ogasawara> pgraner_: yup, consider it added
[00:28] <pgraner_> ogasawara: great I'll see if rtg can fix it
[13:51] <_ruben> what's the best way to get this (http://kerneltrap.org/mailarchive/linux-kernel/2008/10/16/3678594) included an upcoming kernel update (for atleast intrepid) ?
[13:56] <smb_tp> _ruben, If there is no bug for that issue, open one and add pointers to the upstream fixes. Then ping us/me here with the bug number.
[13:58] <rtg> ivoks: I got a response from Ted. Any more details on your ext4 problem?
[13:59] <ivoks> i didn't report it yet
[13:59] <_ruben> smb_tp: ok
[13:59] <rtg> ivoks: if you want it fixed, then you gotta describe it.
[13:59] <ivoks> hehe i know
[13:59] <ivoks> i didn't have time
[14:01] <_ruben> smb_tp: so far the only reference to this fix is the above mentioned url .. havent found any traces of an actual commit thusfar
[14:04] <smb_tp> _ruben, Which make things normally harder since stable updates in general should come from upstream repos. The patch itself looks safe. I think I saw you comment somewhere thatyou tried this and it made a difference for you
[14:08] <_ruben> smb_tp: correct, its one in the it-works-for-me category
[14:09] <ivoks> rtg: bug 331558
[14:09] <ubot3> Malone bug 331558 in linux "Unabe to boot linux-image-2.6.28-7 or newer" [Undecided,New] https://launchpad.net/bugs/331558
[14:10] <_ruben> i could very well my lack of google-foo to find evidence of an upstream patch, as I'd be rather surprised if this hadn't gone upstream yet .. since a change in one part of the kernel broke another part
[14:10] <rtg> ivoks: thanks. I'll let Ted know.
[14:12] <_ruben> bugger .. <IP_ADDRESS> doesnt have the fix :/
[14:13] <smb_tp> _ruben, Better be in the fixes-it-for-me. The bug/request should clearly state how things are without and with. So this gives an argument why this makes sense. And maybe upstream has to be reminded somehow. Or it did not make sense to them. It isn't even in the latest git. Justchecking tip
[14:13] <smb_tp> No, neither
[14:14] <_ruben> ah .. was about to check <IP_ADDRESS>
[14:19] <ivoks> rtg: great
[14:20] <smb_tp> _ruben, The problem is likely that in theory both forms should yield the same results.
[14:23] <_ruben> smb_tp: hmm .. could be a problem scst itself then in some odd way .. a scst contributer claimed to have sent a patch upstream, which apparently never came through .. nor did a fix submerge within scst .. lets ask around for details
[15:05] <_ruben> linus prevented said patch from entering mainline without detailed explanation
[15:08] <smb_tp> _ruben, I would guess it was not enough reason. As said, regardless of the warning this should make no difference. And if so it has to be proved.
[15:49] <blizzle> I was recommended to try the latest 2.6.29.x kernel in jaunty last night, as I can't get any joy with the 2.6.28.x kernels on my system. Bug is the same as thins one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/314050
[15:49] <ubot3> Malone bug 314050 in linux "Jaunty doesn't boot on my DELL Latitude C810 with current kernel" [Undecided,Confirmed]
[15:50] <blizzle> The 2.6.29.x kernel failed even to boot. I was recommended to report the issue here.
[16:39] <rtg> smb_tp: it would seem that <IP_ADDRESS> will render ext4 no longer experimental.
[16:40] <smb_tp> rtg, I saw that big bunch of ext4 patches. I still have to look at them and then it depends when they are flushed. At least it won't cause regressions
[16:41] <rtg> smb_tp: its the same set I'm carrying in Jaunty. I puklked from Ted's tree a few weeks ago
[16:42] <smb_tp> I actually saw mails about this on both stable queues
[16:43] <rtg> yep - I'm going to revert a bunch of SAUCE patches in favour of the official stable commits.
[16:45] <smb_tp> Actually it could be a good indicator on how complete things are. If you pulled those from Ted's tree before, they should be at least near 1:1 wit what you have to revert
[20:23] <maxb> On one of my machine's today's kernel update seems to have had an unacceptable impact on interactive performance.
[20:23] <maxb> I assume it's the cpufreq stuff
[20:24] <maxb> Rolling back to -7 ABI fixes things
[20:24] <maxb> I shall now check the -8.x ones
[20:33] <rtg> maxb: what are you doing that you would even notice interactive performance? Is it under load?
[20:34] <maxb> even not under load, I found that screen redrawing was affected enough to be quite awkward
[20:34] <maxb> It could take a full second just to redraw an xchat window after clicking a different channel tab
[20:34] <rtg> maxb: can you change the cpu governor and see an effect?
[20:35] <maxb> let me quickly get back into -8.24
[20:39] <maxb> "quickly"
[20:39] <maxb> it's fscking
[20:42] <blizzle> I raised the issue earlier, got zero response, so I'll try again. I'm not able to boot jaunty using any 2.6.28.x kernels here, the bug has been reported: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/314050 .. If I use the patched kernel I can boot, but get other issues.. anyone one if/when this bug is likely to be addressed?
[20:42] <ubot3> Malone bug 314050 in linux "Jaunty doesn't boot on my DELL Latitude C810 with current kernel" [Undecided,Confirmed]
[20:42] <blizzle> s/one/know
[20:46] <maxb> The panel applet doesn't seem to be working
[20:46] <maxb> oh, I have an apport-crash of cpufreq-selector
[20:51] <blizzle> I should also mention that I've seen 2 machines unable to boot with the 2.6.28.x kernels (different hardware), and the 2.6.29.x latest kernel from the ppa failed to boot, also.
[20:52] <maxb> Can someone point me to the right place in /proc or /sys to change the governor manually?
[20:53] <rtg> maxb: /sys/devices/system/cpu/cpu0/cpufreq
[20:54] <rtg> actually, /sys/devices/system/cpu
[20:57] <maxb> right
[20:57] <maxb> that fixes it
[20:57] <maxb> My 3GHz processor was running at 375MHz, and was being excessively conservative about scaling up with 'ondemand'
[20:57] <rtg> maxb: changing the governor fixes it? What specifically did you do?
[20:58] <maxb> echo performance > thatsysfile
[20:58] <maxb> echo performance > ..../scaling_governor
[20:59] <rtg> maxb: would you open a bug report and add this detail? Keybuk and mjg59 will likely find it of interest.
[21:05] <soren> maxb: 375MHz? Seriously? I didn't think it could go lower than 600.
[21:31] <maxb> soren: that's what the panel applet claims....
[21:31] <maxb> seems rather excessive, especially for a desktop part


[11:55] <bjf> xnox, any progress on that "installer bug"?
[12:03] <xnox> bjf: yes and no. Haven't reproduced the failure.
[12:03] <xnox> bjf: and my local utah setup, no longer at all works.
[12:13] <cking> xnox, has utah changed (again?)
[12:14] <xnox> cking: there was stable release in june this year. and i'm assured that's what running in production, however it no longer provisions VMs in my local setup as it used to.
[12:14] <xnox> cking: also
[12:15] <xnox> bjf: cking: "<plars> Eisbrecher_xnox: looks like I can produce this problem on VM with latest trusty now that we have them"
[12:16] <xnox> bjf: it's not utopic unique. (at least in terms of guest)
[12:16] <bjf> xnox, ack
[12:17] <bjf> xnox, i'm also confused by the "now that we have them" part of that statement and wonder "why didn't you have them before?"
[12:19] <xnox> bjf: for some time we didn't have trusty dailies built (due to contention with precise dailies, it's first time we have .5 release) thus at first it was blocked on to moving building cds from nusakan into launchpad.
[12:19] <xnox> bjf: the launchpad bit is complete, and all images are build by launchpad buildd farm now.
[12:19] <bjf> xnox, ah, ok, makes sense
[12:19] <xnox> bjf: however, UTAH was searching for /daily-live/trusty-desktop-amd64.iso
[12:20] <xnox> bjf: whereas stable dailies are published in /trusty/daily-live/trusty-desktop-amd64.iso
[12:20] <xnox> bjf: top-level /daily-live/ is for devel series only, that is utopic now. And hence utah didn't pick up the new images when they started to be generated.
[12:21] <xnox> bjf: (well there is an extra subdir for image build number & current)
[12:24] <bjf> xnox, what do you need at this point to make progress? do you need help from plars and nuclearbob for the utah side?
[12:26] <xnox> bjf: i don't know if nuclearbob works on utah. I've been directed at ev, psivaa, plars, doanac.
[12:27] <xnox> bjf: in the mean time, I am investigating how to provision and run tests without UTAH in between.
[12:27] <bjf> xnox, if you would like utah help, i'm happy to go have a chat with evan
[12:27] <xnox> bjf: e.g. using a simple pxeboot provisioning and test provision/collection. Which should work with VMs and bare-metal alike.
[12:29] <xnox> bjf: i don't care much about utah. The hard-pressing thing is that: (a) bootspeed tests are not executed (b) power tests are not executed (c) utopic desktop daily tests has not run since 20th of May (thus not migrated from pending -> current)
[12:30] <cking> xnox, the weakness does seem to be at the utah side of things
[12:33] <bjf> xnox, i agree with you. i would hope that you could repro the issue outside of utah but if you can't we should get them involved
[12:35] <bjf> xnox, is there any additional information they can provide to you which would help debug this? if they provided you with access to a system in this particular state?
[12:38] <xnox> bjf: access to utah server, from which i can trigger utah provisioning runs would be useful, yes. Since my local utah setup is non-operation (as in it doesn't get as far as ci.ubuntu.com utah runs get to)
[12:38] <xnox> bjf: and it's not like current utah production server does anything useful =) given all tests timeout and don't run.
[12:39] <xnox> it's interesting that trusty 14.04.0 test run today, shows the in-ability to unmount /target ( https://jenkins.qa.ubuntu.com/job/trusty-desktop-amd64-smoke-default/163/artifact/log/utah-24420-install.log/*view*/ )
[12:40] <xnox> based on artifacts there, i believe the machine did install and reboot was requested.
[12:41] <xnox> but the target machine never showed up with working ssh server open.
[12:41] <xnox> https://jenkins.qa.ubuntu.com/job/trusty-desktop-amd64-smoke-default/163/artifact/log/utah-server-ssh.log/*view*/
[12:51] <psivaa> xnox: just going through the backlog.. re: 'current utah production server does anything useful =) given all tests timeout' we have server iso installations running ok
[12:51] <psivaa> xnox: the issue we are facing is only pertainning to desktop iso's
[12:51] <psivaa> xnox: the issue only started when we upgraded the production servers from precise-> trusty
[12:57] <bjf> psivaa, that's a completely different story than we have been getting
[12:57] <bjf> psivaa, we've been told that the problem is with the installer when installing on the test system
[12:57] <bjf> psivaa, it sounds like you are saying that after you updated your infrastructure it started failing
[12:58] <psivaa> bjf: well as you know the 'failing' has been for quite a long time and there was one or two installer issues two in between
[12:59] <psivaa> bjf: when i checked last time, it wasn't alone the installer thats at fault.
[12:59] <psivaa> bjf: and that was a couple of weeks ago
[13:00] <bjf> psivaa, how do we all come together on this and get the tests running again?
[13:00] <psivaa> bjf: manual installation went fine. and i tried a preseeded installation too and that worked too, outside of utah
[13:00] <bjf> psivaa, so how did the finger get pointed at the installer?
[13:01] <psivaa> bjf: as i said there were installer bugs too in between even with manual installation. but i *think that got fixed now
[13:01] <psivaa> (the finger pointed earlier might not have folded :))
[13:02] <bjf> psivaa, so what is the current issue(s) that need to be addressed to get the tests running again?
[13:03] <psivaa> bjf: the current issue was (when i checked about a week and half ago) that utah installation of desktop goes on a loop on trusty production servers and instead of  rebooting to login screen after the install, it starts the installation again.
[13:04] <bjf> psivaa, and where do you believe that issue exists? is it utah?
[13:05] <psivaa> bjf: i'd start from utah for a fix. but not ruling out any changes in the installer side that could make utah server to think that the installation is complete
[13:06] <psivaa> s/complete/not complete/
[13:07] <bjf> psivaa, ok, lets start with utah. who works on utah these days?
[13:09] <psivaa> bjf: so I think utah is now basically in  maintenance mode awaiting deprecating, in light of the ci-airline development. doanac, plars and myself in our team do the fixes as we see fit.
[13:09] <psivaa> this appear to be a complicated issue and there fore outside my capability
[13:15]  * cking wonders how many infrastructure development iterations are required to get something working for at least 2 cycles w/o breaking
[14:15] <apw> psivaa, i thought we used the same framework for the SRU validation, is this going to cause issues qualifying .5 ?
[14:20] <psivaa> apw: for kernel SRU, we dont use utah. for precise iso testing we dont use utah either. so should not affect precise .5. Not sure if anyone is using it for SRU validation of the other packages
[19:35] <jdstrand> rsalveti (and rtg): did the apparmor signal/ptraces patches make it into phone images yet?
[19:36] <rsalveti> jdstrand: yes
[19:36] <jdstrand> rsalveti: I was looking at https://launchpad.net/ubuntu/utopic/+source/linux-mako, but didn't see it in the changelog. is that expected?
[19:37] <jdstrand> oh, I see it in 3.4.0-5.30
[19:37] <jdstrand> rsalveti: nm, thanks!
[19:37] <jdstrand> it got hidden due to the ftbfs entry
[19:41] <jdstrand> rsalveti: thanks for that testing btw :)
[19:43] <rsalveti> jdstrand: np!
[22:01] <awe_> sforshee, could you or someone on your team take a look at: https://bugs.launchpad.net/ubuntu/+source/linux-mako/+bug/1337753
[23:15] <xevious> This isn't a kernel development question, but regarding internal kernel operations: when would it be necessary to manually use the sync command line utility? Shouldn't any pending writes be flushed when I run `losetup -d /dev/loopX` or `dmsetup remove exampledevice`? What types of operations could a user perform that the kernel wouldn't automatically sync? Can you provide examples of when I would need to run the sync command?


[17:13] <padraic> I had thought there was supposed to be a monthly meeting but I guess I should have noticed the last date mentioned in the Topic above.


[13:45] <rangerpb> smoser, larsks mind peeking at https://code.launchpad.net/~bbaude/cloud-init/azure_dhcp ? it contains the rework we discussed yesterday.
[13:46] <smoser> rangerpb, reading
[13:46] <rangerpb> im updating the commit msg now too
[13:50] <rangerpb> smoser, also wondering if you wouldnt mind peeking at https://code.launchpad.net/~bbaude/cloud-init/rh_sub_rm_first which is a trivial change too.  <-- larsks fyi
[14:02] <rangerpb> headed offline for a bit...back in about 90 minutes or so
[14:02] <smoser> k. i'll have it for you when you return
[14:40] <smoser> harlowja, please ping when you're in.
[16:54] <harlowja> smoser ping a ling
[16:54] <harlowja> so mr.version
[16:54] <harlowja> ha
[16:57] <smoser> hey
[16:57] <smoser> yeah.
[16:57] <smoser> so. we definitely can't pick up a runtime dependency for something so silly
[16:57] <harlowja> k
[16:57] <harlowja> that should be fine
[16:58] <harlowja> we should be able to just do
[16:58] <smoser> and even build-time is a pain. i'm perfectly fine to take the convention of pbr
[16:58] <harlowja> >>> import pkg_resources
[16:58] <harlowja> >>> pkg_resources.get_distribution("pbr").version
[16:58] <harlowja> for example
[16:58] <smoser> but only if you have that available in build
[16:59] <smoser> right?
[16:59] <harlowja> (to get whatever version is installed)
[16:59] <harlowja> everyone has pkg_resources
[16:59] <harlowja> :-P
[16:59] <harlowja> replace 'pbr' there with 'cloud-init'
[16:59] <harlowja> ha
[16:59] <smoser> i'm confused.
[16:59] <harlowja> so the runtime dependency would be for version.py?
[16:59] <harlowja> maybe i'm confused eto
[16:59] <harlowja> ha
[17:02] <smoser> so runtime, yeah.
[17:02] <smoser> so can't pick up runtime
[17:02] <smoser> but even the build time is a pita
[17:02] <smoser> and i'd like to avoid it
[17:02] <harlowja> meh
[17:02] <smoser> i think its more than just pkg_resources
[17:03] <harlowja> for build time, meh, what do u do
[17:03] <smoser> i have to have pbr at some sufficient version
[17:03] <harlowja> u either create your own pbr thing
[17:03] <harlowja> or use pbr lol
[17:03] <smoser> how hard is this though?
[17:03] <harlowja> if u want to actually provide a useful deb and rpm version at build time
[17:03] <smoser> i'm fine to follow their versioning scheme
[17:03] <harlowja> its sorta a pita that i don't want to recreate, lol
[17:03] <smoser> how is it hard?
[17:04] <harlowja> its complicated, not hard
[17:04] <smoser> it can't be that complicated.
[17:04] <smoser> i'm happy with git-describe
[17:04] <smoser> it gives you 3 tokens of information
[17:04] <smoser>  last_tag_on_branch, commits_since_tag, hash
[17:05] <smoser> you can only put those in so many different orders
[17:05] <harlowja> ya, hash is useless in redhat
[17:05] <harlowja> in rpms
[17:05] <smoser> its useful
[17:05] <smoser> you just hide it behind something like commits_since_tag
[17:07] <harlowja> https://github.com/openstack-dev/pbr/blob/master/pbr/version.py#L353 has some details around why its such a pita
[17:07] <harlowja> i just don't have much desire to recreate any of that crap
[17:08] <harlowja> https://specs.openstack.org/openstack/oslo-specs/specs/juno/pbr-semver.html#proposed-change has more details
[17:08] <harlowja> if u really want to recreate all that, go ahead i guess, i just don't care much to, lol
[17:09] <harlowja> "Provide a new command (deb-version) to output Debian package version compatible version strings. This primarily involves translating PEP-440 precedence rules into Debian ~ and . component separators.
[17:09] <harlowja> Provide a new command (rpm-version) to output RPM version metadata for incorporation in RPM versions using the ENVRA format. As RPM lacks a ‘before’ operator (~) the primary method for translation is to treat pre-release and dev builds as release builds of next lowest version to drive the sort order above all actual releases of the version below. We assume that no version will ever have more than 9998 patch/minor releases. E.g. 1.2.0.dev5 is
[17:09] <harlowja>  rendered as 1.1.9999.dev5. 1.0.0.dev5 would be rendered as 0.0.9999.dev5 and finally 0.0.0.dev5 would also be rendered as 0.0.0.dev5 to avoid negative version numbers.
[17:09] <harlowja> "
[17:51] <smoser> harlowja, you are correct that this is a pita
[17:56] <harlowja> ya, i mean, ya, we can do something similar
[17:56] <harlowja> sure, (although i don't really want to code it/verify its correctness, ha)
[17:58] <smoser> can pbr parse a string for me ?
[17:58] <smoser> and tell me what it thinks debiand and rpm versions shoudl be ?
[17:59] <harlowja> hmmmm
[17:59] <harlowja> don't think so
[17:59] <harlowja> some other package might be able to
[18:03] <smoser> this is crap harlow
[18:03] <smoser> version.SemanticVersion(0, 7, 6, dev_count=100).debian_string()
[18:03] <smoser> 0.7.6~dev100
[18:03] <smoser> i'd have thought i was saying 0.7.6 + 100 commits
[18:03] <smoser> and it gave me ~ which is < 0.7.6
[18:05] <harlowja> lol
[18:07] <harlowja> u might want to try https://github.com/openstack-dev/pbr/blob/master/pbr/version.py#L121 ?
[18:08] <harlowja> or seeing what https://github.com/openstack-dev/pbr/blob/master/pbr/packaging.py#L592 does
[18:08] <harlowja> or https://github.com/openstack-dev/pbr/blob/master/pbr/packaging.py#L691
[18:09] <smoser> harlowja, it sure looks to me like my versioning scheme works for both debian and rh
[18:09] <smoser> if it is a tag, then you use Major.Minor.Micro
[18:09] <smoser> if not, then you use
[18:10] <smoser>  Major.Minor.Micro+Commits.gHASH
[18:10] <harlowja> so "+" is addition there?
[18:11] <smoser> it just means greater
[18:11] <smoser> i am pretty sure.
[18:11] <harlowja> ya, i don't think that works in rpms from what i remember
[18:11] <harlowja> but maybe larsks can comment
[18:12] <larsks> harlowja: what am I commenting on?
[18:12]  * larsks reads...
[18:12] <larsks> I think we should be following https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines w/r/t rpm versioning.
[18:13] <larsks> I suspect you can use '+' in a release if you want (that is, I don't think it's prohibitied), but it's not magic in any way.
[18:15] <smoser> larsks, i'm not sure i follow
[18:16] <larsks> I think you are asking if "Major.Minor.Micro+Commits.gHASH" is a good versioning scheme for packages, yes?  Or did I misread? Apologies if so.
[18:16] <smoser> i'm saying that for snapshots of upstream, calling that the "upstream version" is sufficient.
[18:17] <smoser> if you want to suggest something else, i'm ok with that.
[18:17] <larsks> I'm still not following, sorry.  You are proposing that e.g., brpm should produce packages with this versioning scheme?  Or something else?  If it's just a documentation reference to the upstream version that seems lovely.
[18:18] <smoser> so, yeah. if you run 'brpm' on trunk, you'd get a rpm that had a version like that.
[18:18] <smoser> if you ran it with 0.7.7, you'd get '0.7.7'
[18:19] <larsks> I guess if those rpms never really go anywhere other than a local development host it doesn't really matter.
[18:19] <smoser> what versoinoing would you use for your packaging ?
[18:19] <smoser> you'd probably just use a serial incrementer on the releases youd done
[18:19] <smoser> right?
[18:19] <larsks> The doc I pointed at (the fedora packaging guidlines), which is pretty much what I implemented in my changes to brpm.
[18:20] <larsks> So, <name>-<version>-<release>.<date>git<commit_id>
[18:20] <harlowja> * if those rpms never really go anywhere other than a local development host it doesn't really matter.
[18:21] <harlowja> hmmm, but they will be going somewhere else, ha
[18:21] <larsks> harlowja: are they?
[18:21] <larsks> harlowja: none of the downstream rpm distributions use brpm for building packages.
[18:21] <harlowja> sucks to be them
[18:21] <harlowja> ?
[18:21] <larsks> I dunno about that.
[18:21] <larsks> But that is the current situation.
[18:21] <smoser> :)
[18:22] <harlowja> reality is i don't plan on waiting around for downstream rpm distributions :-P
[18:22] <larsks> harlowja: i am not sure I follow your comments.
[18:22] <larsks> In what way would you need to wait on them?
[18:22] <harlowja> wait for a change to filter through the pipeline ---> downstream rpm distributions
[18:23] <harlowja> to images that i can them use
[18:23] <harlowja> *then use
[18:23] <harlowja> (in the godaddy cloud)
[18:23] <larsks> Ah, I see.
[18:23] <harlowja> also need to add in a godaddy specific module to cloud-init, so i'll be repacking anyway, and cloud.cfg will require tweaks for that
[18:23] <larsks> It seems like that would happen in any case, regardless of what they were using for the spec file, especially for enterprise distributions, right?
[18:24] <larsks> There is almost always going to be delay between upstream release and downstream packaging.
[18:24] <harlowja> idk, i'm not a enterprise distributor :-P
[18:24] <harlowja> in the world of the future, no i don't like that delay and i think its messed up
[18:24] <harlowja> in the world of today, sure it probably is a delay
[18:26] <larsks> Okay.  Anyway, back to smoser's question, I would personally adopt the versioning scheme recommended in the fedora docs, but for our purposes here I don't think it matters one way or the other.  As long as release <N+1> is lexically greather than release <N>, it should all be okay.
[18:29] <harlowja> is that in part cause of the lack of usage of brpm?
[18:29] <harlowja> (why it doesn't matter)
[18:31] <smoser> http://paste.ubuntu.com/22207121/
[18:31] <smoser> that compares version info like
[18:31] <smoser> http://paste.ubuntu.com/22207177/
[18:31] <harlowja> woah, shell
[18:31] <harlowja> lol
[18:34] <larsks> smoser: I was curious about whether something like 0.7.7-10-g1234567 will be > 0.7.7-1-g1234567.   Have at it :)
[18:36] <smoser> the read-version stuff would have to be updated as it gets 0.7.7 now.
[18:36] <smoser> but tath is ok.
[18:44] <harlowja> and for a change of topic
[18:44] <harlowja> smoser any thoughts on https://issues.jenkins-ci.org/browse/JENKINS-30183
[18:45] <harlowja> https://github.com/jenkinsci/acceptance-test-harness/blob/master/src/test/resources/openstack_plugin/cloud-init  is the cloud-init file that uses
[18:45] <harlowja> i think in part its because runcmd probably shouldn't be used
[18:45] <harlowja> or the module ordering needs to be adjusted
[18:45] <harlowja> https://issues.jenkins-ci.org/browse/JENKINS-30183?focusedCommentId=266029&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-266029
[18:47] <harlowja> or someones package doesn't set the right ordering for sshd to start
[18:51] <harlowja> it almost seems like whats wanted is a init-run-cmds there
[18:51] <harlowja> or moving runcmd into the cloud_init_modules for this case
[18:51] <harlowja> so that sshd doesn't start until after thats done
[18:52] <smoser> so they want to lock sshd starting until its done?
[18:52] <harlowja> ya
[18:53] <smoser> ah. i see.
[18:53] <smoser> jenkins ssh's in
[18:53] <harlowja> any other way besides adjusting the module ordering that u can think of?
[18:54] <harlowja> ya, they do https://github.com/jenkinsci/acceptance-test-harness/blob/master/src/test/resources/openstack_plugin/cloud-init#L16 and line 22 there
[18:54] <harlowja> to work around this
[18:54] <smoser> does jenkins retry ?
[18:54] <smoser> if it can't get in.
[18:54] <smoser> i suspect yes
[18:54] <harlowja> ya, but the desire i think is to not allow sshd at all until user data scripts have all ran
[18:54] <harlowja> so that they know that user data scripts have finished before jenkins (the master) starts trying to connect in
[18:55] <harlowja> which it does via ssh
[18:55] <harlowja> (to establish the master <-> slave connection)
[18:55] <smoser> well, a boothook could disable sshd (and the stop it to make sure)
[18:55] <smoser> and then start it in runcmd
[18:55] <harlowja> right, that'd work to
[18:56] <smoser> also, if they did not put the ssh-authorized-keys in under 'users'
[18:56] <harlowja> the weird part (or harder part) is that that plugin allows for user specified cloud userdata
[18:56] <smoser> but wrote them when they're done
[18:56] <harlowja> so people can override it and not do that
[18:56] <harlowja> and screw themselves, ha
[18:57] <harlowja> bb
[18:57] <smoser> i've wanted to be able to block ssh from starting until users sare configured before.
[18:57] <smoser> so that if you ever got denied you'd not need to try again.  either connection closed or youre in
[18:57] <smoser> but never wanted to not start sshd till later.
[18:58] <smoser> ubuntu can disable sshd easily enough
[19:11] <smoser> harlowja, 2 other options
[19:12] <smoser> a.) rather than having jenkins just bang on the ssh port until gets in, you could have phone_home tell it it is ready
[19:12] <smoser> b.) you coudl have jenkins block until a /run/all-done is there
[19:12] <smoser> (or cloud-init's /run/cloud-init/result.json)
[19:30] <harlowja> ah, ya, the '/run/all-done' might be a good idea
[20:29] <hans__> hey folks, had a question on whether anything has changed in recent ubuntu images as far as initial mount and format of the ephemeral drive. we have started seeing this lately: Stderr: 'mke2fs 1.42.13 (17-May-2015)\n/dev/sdb1 is mounted; will not make a filesystem here!\n'
[20:35] <hans__> we think this might be a race condition between mnt.mount and cloud-config.service, but it seems to be a new issue
[20:51] <smoser> hans__, this is azure ?
[20:52] <hans__> @smoser, yes
[20:54] <hans__> @smoser: it looks like mnt.mount is doing a mount before cloud-init gets there sometimes, and we see 'Device /dev/sdb1 has Temporary Storage ntfs'
[20:55] <hans__> @smoser, then mke2fs fails - is it expected that the drive is unmounted before cloud-init gets there?
[20:56] <smoser> hans__, yeah, thats probably true.
[20:56] <smoser> nothing is stiopping the mounts from occuring