[04:22] <ryan__> Hey all, the gnome3 ppa is kicking back an error that it doesn't have the release info for 16.10 - is there a workaround?
[11:07] <testname> HELP
[11:09] <testname> LOGIN
[12:41] <LinDol> hi all
[14:18] <markus__> hey guys! is it possible to force the dark theme on gedit 3.22?
[16:28] <freakyy> hi all. i have a HyperX II Gaming Headset and it worked before the upgrade to ubuntu 16.10 with 16.04. but now the device isnt even listed as output device - only as input device in the sound settings. any idea what i can do?
[16:30] <freakyy> ah i replugged it in
[16:30] <freakyy> now it works
[16:30] <freakyy> nm ;D
[16:32] <freakyy> ok i got another question. is there any possibility to control the logitech g213 keyboard leds (which keep cycling in 16million colors if they are not "set")?
[16:44] <fleetfox> ..
[16:55] <markus__> freakyy: maybe this helps: https://gnome15.org/


[00:31] <howarth> Has anyone using the nvidia drivers actually been able to get single user or rescue mode to work?
[01:46] <mattfly> im testing 20.04 beta and using apt is extremely slow
[01:46] <mattfly> any idea why? even snap is faster
[01:51] <lotuspsychje> good morning
[02:37] <valorie> mattfly: test the RC instead
[02:38] <valorie> beta is old now
[02:38] <mattfly> cant i upgradE?
[02:38] <mattfly> i was willing to upgrade to the lts
[02:38] <mattfly> then stay there
[02:39] <mattfly> but apt kinda worked fine now
[02:44] <housecat> "apt is extremely slow" sounds like a mirror issue, try a different one
[02:44] <housecat> and yes, just do apt update and apt upgrade as normal to go from beta to RC
[02:47] <valorie> LTS won't be declared until this summer
[02:47] <valorie> when teh .1 is released
[02:47] <valorie> you can upgrade of course
[02:48] <valorie> but then it is really no longer a test
[02:48] <housecat> it's LTS at release, .1 is when upgrades from older LTSes are enabled
[02:48] <valorie> housecat: true
[02:49] <valorie> I guess not everyone here is testing as in 'reporting results on the qa tracker'
[02:50] <housecat> speaking of which, any idea why http://iso.qa.ubuntu.com/qatracker/milestones/412/builds is missing most products?
[02:50] <housecat> did they just happen to do netboot and mate now and the rest are next week?
[02:51] <valorie> I'm guessing it's being built now
[02:51] <housecat> ah
[02:52] <housecat> been like that for hours, i guess i should just be patient
[02:52] <valorie> I guess the place to ask would be in -release
[02:52] <valorie> if there is anyone about
[02:52] <housecat> it's sunday nighttime, i'll just leave it
[02:53] <housecat> will probably be fixed monday anyway
[02:53]  * housecat grabs the ubuntu mate iso and does that while she's waiting
[02:56] <sufy> hi i have an issue with realtek 8192ce rtl8192ce on ubuntu 20.04, seems to be an issue on a modified debian distro called avlinux aswell
[02:56] <sufy> keeps disconnecting, seemed to work okay on debian stable and arch linux though
[03:21] <lotuspsychje> sufy: did you update system to latest?
[03:21] <lotuspsychje> we saw realtek bugs passby on 5.4 -24 yesterday
[03:21] <lotuspsychje> now we have -25
[03:30] <AlexMax> My default sound card/output device isn't being paid any attention to
[03:31] <AlexMax> I tried setting it in the pulse default config and even on restart the defaults are both my microphone's sound in and out
[03:34] <AlexMax> Wait a minute, it's working in my standard user account, but not my alternative
[04:02] <AlexMax> Finally fixed it, no idea how or why
[05:02] <Haxxa> Can we postpone the Ubuntu launch until the 27th April, busy on the 24th. Thanks
[05:29] <valorie> lol
[06:14] <LuckyMan> is steam supported in 20.04?
[06:14] <lotuspsychje> !info steam | LuckyMan yes
[06:15] <LuckyMan> I can't run it
[06:16] <LuckyMan> I've got an error message, is it my mx230 ?
[06:17] <LuckyMan> also, when my computer goes to suspension (I close the lid) it doesn't come back sometimes (it makes noise but all is black)
[06:19] <lotuspsychje> LuckyMan: is your graphics card driver loaded?
[06:20] <LuckyMan> I've got an acer A315-55G-KL
[06:21] <lotuspsychje> LuckyMan: pastebin please: sudo lshw -C video && uname -a
[06:22] <LuckyMan> https://paste.ubuntu.com/p/pWkSH3WTtH/
[06:23] <LuckyMan> lotuspsychje, ^^
[06:24] <lotuspsychje> LuckyMan: ok so your card is probably an optimus right?
[06:25] <lotuspsychje> LuckyMan: did you check nvidia-settings if your card is set to performance mode (nvidia) ?
[06:25] <LuckyMan> lotuspsychje, idk... what's an optimus?
[06:25] <lotuspsychje> LuckyMan: its a hybrid card, combined graphics like intel-nvidia
[06:26] <LuckyMan> lotuspsychje, its set to choose whatever is neeeded
[06:26] <LuckyMan> should I choose only nvidia?
[06:26] <lotuspsychje> try nvidia only, and try again launching steam, from terminal this time
[06:29] <LuckyMan> how do I install steam (the propper way)?
[06:29] <LuckyMan> sudo apt install steam?
[06:29] <lotuspsychje> LuckyMan: you just said you had an error? where was that?
[06:30] <LuckyMan> i removed steam
[06:30] <LuckyMan> it was when I runned it
[06:31] <lotuspsychje> you installed it last time right, you know how
[06:32] <LuckyMan> SteamUpdateUI: An X Error occurred
[06:32] <LuckyMan> X Error of failed request:  GLXBadContext
[06:32] <LuckyMan> SteamUpdateUI: An X Error occurred
[06:32] <LuckyMan> X Error of failed request:  BadValue (integer parameter out of range for operation)
[06:32] <LuckyMan> Major opcode of failed request:  152 (GLX)
[06:32] <LuckyMan> Minor opcode of failed request:  3 (X_GLXCreateContext)
[06:34] <lotuspsychje> use a pastebin LuckyMan
[06:34] <lotuspsychje> brb coffee..
[06:36] <LuckyMan> https://paste.ubuntu.com/p/Whp7RpBZKG/
[06:53] <LuckyMan> lotuspsychje, are you back?
[06:53] <LuckyMan> I did a purge and then re-installed steam, same error
[07:02] <lotuspsychje> LuckyMan: pastebin: nvidia-smi please
[07:04] <LuckyMan> https://paste.ubuntu.com/p/DY8ff2m3pG/
[07:05] <lotuspsychje> LuckyMan: lets try a driver switch, open software&updates tab additional drivers and choose 1 version lower driver, perhaps 435?
[07:07] <LuckyMan> lotuspsychje, same error
[07:07] <lotuspsychje> LuckyMan: did you reboot after switch?
[07:07] <LuckyMan> nope
[07:07] <LuckyMan> I will
[07:07] <lotuspsychje> always reboot after drivers switch
[07:16] <LuckyMan> lotuspsychje, steam now works :-D Thank you!
[07:16] <lotuspsychje> welcome LuckyMan
[07:17] <lotuspsychje> LuckyMan: you have now 435 driver, if you feel its lacking performance, you could still try 440 again
[07:17] <LuckyMan> ok
[07:17] <LuckyMan> I'm not much of a player, I only play Team Fortress
[07:18] <lotuspsychje> allrighty, 435 will surely work too
[07:19] <LuckyMan> :-)
[07:43] <sufy> does anybody find ubuntu frustrating if things related to your computer don't work so well on it
[07:43] <sufy> i felt like i should use debian instead it seemed to handle my computer ebtter
[07:44] <sufy> i am getting tired of time wasting with my operating system rather than spending on work
[07:44] <lotuspsychje> sufy: elaborate please?
[07:45] <sufy> i tried out the beta and my wifi card wouldn't function properly for me
[07:45] <sufy> kept turning itself off
[07:45] <sufy> i think i spent a whole night troubleshooting it
[07:45] <lotuspsychje> sufy: did you try my previous suggestion?
[07:46] <sufy> lotuspsychje no i haven't seen, was it something about non-free or contrib, i did try those yes
[07:46] <sufy> they didn't resolve it
[07:46] <lotuspsychje> no, it was about kernel version
[07:46] <sufy> on the ubuntu beta i used the default kernel version that it came shipped with
[07:46] <sufy> but i also experimented with some other non ubuntu things but not worht mentioning them
[07:47] <lotuspsychje> sufy: after you install ubuntu, you need to update your system
[07:47] <sufy> lotuspsychje sorry i just read your comment
[07:47] <sufy> you are saying you passed an update that resolved it?
[07:48] <sufy> that honestly gives me alot of confidence to reinstall
[07:48] <sufy> thankyou
[07:49] <sufy> lotuspsychje in the last few days before release how much work is being done to tune the small issues like that for specific issues
[07:50] <lotuspsychje> sufy: there is no magic red button for bugs, when they arise, the devs and community do their best to fix them
[07:50] <lotuspsychje> hence why you need to keep your system up to date
[07:51] <sufy> lotuspsychje: yes, thankyou for letting me know
[07:52] <lotuspsychje> sufy: during install, you can also toggle 'update system during setup', check if you notice that option ok
[11:10] <luna_> https://www.youtube.com/watch?v=Hg77Rp-ykHE
[11:10] <luna_> also got a 5.4.25 kernel today
[11:51] <TJ-> Weird issue; with dual monitors with external positioned to left of laptop primary, when enabling the external display both displays immediately become 'block-stepped' - looks like there are about 6 horizontal rows with each succeeding row shifted to the right. This was working fine but now affects all log-ins. Thought it might be the -25 kernel but tried -21 and it still happens
[12:03] <lotuspsychje> TJ-: havent seen much bugs passby yet on dual monitors yet, might be worth a new bug?
[12:04] <lotuspsychje> seen a few scaling bugs
[12:07] <lotuspsychje> TJ-: wich graphics?
[12:09] <ttamm> Every time I click a url in vscode, firefox instantly crashes and it seems to open inside the vscode's snap environment somehow (when I click restart firefox in the firefox has crashed window, it doesn't restart my actual firefox browser launched normally)
[12:11] <Ussat> So, I have a question regarding snaps in 20.04. Is it possible to totally rip them out. The thought of snaps being auto updated and restarted outside of my normal scheduled maintenance period is pretty unacceptable here
[12:11] <Ussat> I know in 18.04 I rip them out.
[12:12] <lotuspsychje> its possible Ussat but some snaps are default now, so you will need alternatives for it
[12:12] <Ussat> fuck
[12:13] <lotuspsychje> like the snap-store will be default
[12:13] <Ussat> The idea that things will update on its own...outside of my maintenance time is nuts. How can people think this is acceptable
[12:13] <oerheks> and there are tweaks, manually, to stop updating, or schedule
[12:13] <Ussat> If I could schedule them ONLY douring patch times, that would be fine
[12:14] <Ussat> oerheks, not from what I have read, you can delay, but there is no way to 100% to only have them happen in a set maint window
[12:14] <oerheks> https://snapcraft.io/docs/keeping-snaps-up-to-date
[12:16] <Ussat> oerheks, thats not what I mean, I want snap updates to ONLY happen when I update for patches.
[12:16] <oerheks> or bad; stop updating https://linuxconfig.org/disable-automatic-updates-on-ubuntu-18-04-bionic-beaver-linux
[12:17] <oerheks> no, i have no info hoto update snaps when you hit the update button, or something like that :-(
[12:17] <Ussat> I dont use automatic updates
[12:17] <oerheks> would be a nice idea though
[12:17] <Ussat> I have scheduled maintenance windows to update
[12:17] <Ussat> I cant have things doing whatever when they want
[12:18] <Ussat> Thats nuts, I cant believe anyone thought this was a good idea
[12:19] <Ussat> Looks like I will need to find an alternative to Ubuntu then if thats the case goimng forward
[12:19] <Ussat> I mean I dont care about that for my personal VM, but for production in my data center, that just nuts that people think thats ok
[12:21] <TJ-> lotuspsychje: AMD Vega
[12:22] <TJ-> Ussat: are you using snaps at all (lxd maybe? )
[12:22] <lotuspsychje> TJ-: with block stepped you mean disforming?
[12:24] <TJ-> lotuspsychje: no, literally like someone split the screen into 6 rows and then pushed each row over to the right so it ends up loking like a stair
[12:24] <Ussat> TJ-, right now I dont have 20.04 installed anywhere except a test VM. My question was origionally, can I just rip snaps out all together
[12:24] <lotuspsychje> wow
[12:24] <howarth> Has anyone here using the nvidia drivers tried booting into single user or rescue mode? On the nvidia-340 drivers at least, I never get past the loading of the kernel image.
[12:25] <TJ-> we've 2 identical laptops and both were fine until one lost power; now it does this stepping. I've verified all system files are intact, tried the -21 kernel, it affects all users, and as we play with it we're finding it only seems to happen when the left Y coordinate of the two displays isn't the same
[12:25] <Ussat> TJ-, If snaps updated when I did my patching and ONLY then I would have no issue
[12:26] <Ussat> but I can not believe that admins are ok with systems updating and restarting things on their own, outside of the admins controll.
[12:26] <TJ-> Ussat: is this for workstations or server ?
[12:26] <Ussat> Server
[12:26] <lotuspsychje> TJ-: an idea might be comparing this in wayland
[12:26] <TJ-> Ussat: so is there anything 'snap' that they rely on? if not, rmeove snapd
[12:26] <Ussat> TJ-, I do in 18.04, but was told in 20.04 I cant, which was my origional question
[12:27] <TJ-> Ussat: did anyone tell you why you cannot?
 its possible Ussat but some snaps are default now, so you will need alternatives for it
[12:27] <Ussat> Yes ^^
 like the snap-store will be default
[12:27] <Ussat> ^^
[12:28] <TJ-> lotuspsychje: not going near Wayland ... these are Xubuntu XFCE4
[12:28] <lotuspsychje> i did not say you cannot Ussat
[12:28] <TJ-> Ussat: if you're only using apt then snap store isn't an issue
[12:29] <Ussat> So I CAN do a sudo apt-get -y  autoremove --purge snapd
[12:31] <Ussat> or can I not, thats all I am asking
[12:42] <TJ-> Ussat: none of us here have tried it, you can be the first
[12:42] <TJ-> lotuspsychje: only GPU related clue I can find when monitor is connected (in kernel log) is "[drm] SADs count is: -2, don't need to read it)
[12:45] <Ussat> TJ-, yup, I plan to start testing that later this am
[12:48] <Ussat> I will let people know how works out if they are interested/care
[12:59] <TJ-> lotuspsychje: slight clue I believe. from an SSH session, 'xrandr' is not showing the HDMI-A-0 output connected DESPITE the GUI display manager positioning the external to the left and the stepping happening.
[13:02] <TJ-> lotuspsychje: yes, on the 'good' laptop xrandr shows both
[13:02] <lotuspsychje> hmm i wonder of that drm warning is amdgpu related TJ-
[13:04] <TJ-> lotuspsychje: the kernel message happens on the GOOD laptop as well so discounting that
[13:04] <lotuspsychje> oh ok
[13:05] <TJ-> depsite 'dpkg --verify' not showing anything my gut feeling is file-system corruption of some ancillary file(s) --- possibly under /var/ or /etc/
[13:13] <lotuspsychje> TJ-: can you see if bug #1866616 is related
[13:15] <TJ-> lotuspsychje: theory: Earlier, whilst I was showing Cal how to munge/hack an old printer-driver .deb 's Depends: to install on 20.04 he ran an 'apt install -f' which pulled in some packages. I'm wondering if there's some temporary inconsistency between libraries
[13:17] <lotuspsychje> dont suspect so
[13:17] <lotuspsychje> my bet would be amdgpu or kernel 5.4 related
[13:27] <TJ-> lotuspsychje: Earlier I saw in a log file I cannot now find, but possibly .xsession-errors, a mention of an iccm problem (the colour manager) and when the above-mentioned 'apt install -f' ran libxcb-iccm4 was upgraded along with some other core libxcb* packages
[13:28] <lotuspsychje> TJ-: did you try a reboot with the dualscreen setup?
[13:28] <TJ-> lotuspsychje: several times!
[13:28] <lotuspsychje> ok that makes it weird indeed
[13:28] <TJ-> we've just done another apt upgrade and are doing a reboot
[13:33] <TJ-> Still happening but *only* when ext display is left or right of eDP - above or below is fine
[13:33] <AlexMax> My cursor is getting stuck when changing the xrandr scale.    The only way to make it not appear is to make the cursor disappear, like by typing in stuff at the terminal.
[13:33] <AlexMax> rather, make the cursor disappear just before I run the xrandr command
[13:34] <TJ-> it looks like the display driver is thinking the framebuffer is wider than it really is so it 'wraps' in the buffer
[13:37] <mike-hs> Hi. I was using beta for few days, new install. Today I had to reinstall because I trashed the os with some vfio fidling. Now installer crashes everytime almost at the end
[13:37] <mike-hs> Is there a bug tracking this? Installer crashing during install?
[13:38] <mike-hs> I tried different usb thumbs and even updating from livecd - nothing
[13:38] <mike-hs> same iso booted and installed few times with no problem few days ago
[14:06] <TJ-> lotuspsychje: this looks similar but I think the mention of xpresent is a misnomer; Ubuntu has upgraded some of the libx packages from 4.4 to 4.5
[14:06] <TJ-> lotuspsychje: https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/10
[14:07] <lotuspsychje> TJ-: wow the 'stairs' lol
[14:11] <TJ-> :)
[14:14] <lotuspsychje> TJ-: makes me think of the famous amd + ubuntu disforms during the years
[14:15] <TJ-> hmmm, but why on 1 and not on the other identical laptops?
[14:15] <TJ-> it can't just e due to the power-loss... there are package version differences because I've not allowed upgrades on mine and there are 314 pending, including libxcomposite
[14:18] <lotuspsychje> TJ-: were they both installed at same time?
[14:19] <iconoclasthero> if GNOME Tweaks isn't working in 20.04, i.e., it is not spanning desktop wallpaper (and consequently breaking the function of Hydrapaper), is that an ubuntu 20.04 bug a gnome bug, a tweaks bug?
[14:35] <TJ-> lotuspsychje: both laptops? yes, both 20.04 but upgrading at different times
[14:36] <lotuspsychje> TJ-: interesting bug
[14:45] <TJ-> upgrading all the packages on mine now... see if I can replicate the bug with the upgrades in place
[14:45] <TJ-> waste of an afternoon!
[14:46] <TJ-> going to reboot :)
[15:01] <iconoclasthero> is there some way to get wallpaper to span in 20.04?
[15:15] <longstride> lotuspsychje, do you recall I was in here some time ago with an issue of my screens going black after logging in to 20.04?
[15:15] <lotuspsychje> longstride: not sure, what was that about again?
[15:18] <longstride> I had run the apt-get upgrade command, and from then on, for some unknown reason, I would get to the login screen, put in my password, and my monitors went blank, straight into powersaver mode
[15:23] <longstride> ngaio had been trying to give me some assistance but nothing was working.  I was able to press ctrl+f1 to get my login screen back, and then ctrl+f3 to get to a console.  So, periodically from then on, I would boot up 20.04, get to the login screen, hit ctrl+f3 and run the upgrade command again.
[15:26] <longstride> I hadn't done this in a few days, so yesterday I figured I'd give it another go.  Booted up to the login screen, pulled up the console, and ran the upgrade command.  Lots of package updates.  And this time, when I rebooted, I was able to get to the desktop!
[15:32] <longstride> It was a good day!  Even with the bugs, I loved using 20.04
[15:49] <TJ-> reported as Bug #1873895
[17:14] <howarth> Did a few more test installs with current 18.04 and updates. The nvidia-340 drivers on a GTX680 allow both single user and rescue boots to work. However I am still seeing that neither work under the nvidia-340 drivers with 20.04. Also, I am finding that the rescue boot doesn't produce the expected rescue boot option selector under either nouveau or nvidia-340.
[18:59] <howarth> Has anyone gotten the rescue boot to work under nouveau drivers in 20.04?
[19:00] <howarth> I can boot into the rescue kernel under current 18.04 but nothing ever appears for 20.04 on a GTX680
[19:00] <howarth> If that is broken, I am really shocked that it hasn't been reported
[19:06] <howarth> Not even sure exactly what package that issue would fall under
[19:06] <howarth> I don't see any reports at all for focal on busybox
[19:56] <stiltrumpelskin> hello i wonder how to make .desktop files execute whats in them when you double click on the desktop
[19:56] <stiltrumpelskin> right now it opens the file in text editor
[20:13] <stiltrumpelskin> how do people use these chat rooms? i see many people in the room but very little discussion here. am i missing something?
[20:14] <Bashing-om> stiltrumpelskin: Upcomming release discussions/release conversations here - Baited breath currently.
[20:22] <tomreyn> stiltrumpelskin: 'You should right click on the .desktop file and select “Allow Launching”' according to https://itsfoss.com/ubuntu-desktop-shortcut/
[20:23] <tomreyn> also https://linuxhint.com/add_shortcuts_ubuntu_desktop/
[20:23] <tomreyn> neither of these are official documentations, but on a glance i found no bad advice.
[20:24] <stiltrumpelskin> doing that changed something
[20:24] <stiltrumpelskin> but it does not appear to work right now
[20:24] <stiltrumpelskin> i will check the .desktop file
[20:25] <stiltrumpelskin> tomreyn: thanks for your suggestion
[20:26] <tomreyn> you're welcome. :)
[21:14] <TJ-> ping?
[21:14] <luna_> pong
[21:14] <TJ-> thanks! not had any messages for an hour; thought it had dropped offline
[21:15] <luna_> TJ-: ah okay
[21:15] <TJ-> managed to pin down a most obscure bug #1873895
[22:37] <howarth> Has anyone recently tried to boot 20.04 into recovery mode from grub?
[22:37] <howarth> I filed https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/1873965
[22:38] <howarth> If anyone else can reproduce that please append to the report
[23:00]  * genii installs Mojave on howarth's 3,1 instead
[23:02] <howarth> the other drive is actually running patched Catalina
[23:03] <howarth> Actually the only two real issues that I have found in 20.04 are the generic breakage of the recovery mode from grub and the broken single user boot under nvidia-340
[23:04] <genii> howarth: Clean 20.04 on my HP 10th-gen i5 boots to recovery without issue. I do have an Early 2008 3,1 here, but it doesn't have Linux currently installed, just Mojave
[23:04] <howarth> Unfortunately, I can't fully test nvidia-440 because nvidia-modeset is broken on Mac ROMed GTX680
[23:04] <howarth> If you have a spare usb external, give it a try
[23:04] <genii> ( th 3,1 here has NVidia 8800GT also )
[23:05] <genii> I can test the Mac Pro tomorrow, but not tonight
[23:05] <howarth> It actually runs quite nicely in general
[23:06] <genii> howarth: Just curious if you also have the APFS ROM patch installed
[23:07] <howarth> Yes, APFS ROM patched
[23:08] <howarth> The only oddity there is that for macOS, it gives you two devices in the option boot selector (one EFI Boot device and the actual volume name device)
[23:08] <genii> I can't remember if the 3,1 uses 32 or 64 bit EFI
[23:09] <howarth> 64 bit EFI
[23:09] <howarth> I have Windows 10 on a third drive
[23:10] <genii> Mine currently has some PRAM or similar issue where it needs some motherboard buttons pushed if it's powered off for a while, it's a pain
[23:10] <howarth> I upgraded to machine's wifi to a bcm94360cd and installed an overclocked EVGA GTX680 which I then flashed to Mac ROMs
[23:10] <howarth> Do you have Mac ROMs in the video card?
[23:11] <genii> howarth: Yep, PC 8800GT flashed to Mac
[23:11] <howarth> You need to change the lithium battery on the motherboard
[23:11] <genii> I did put a new 2032 already
[23:11] <howarth> odd
[23:11] <genii> ..but maybe there's another barrel one someplace
[23:12] <howarth> The only weirdness I ran into was in my effort to upgrade to ac wifi, I originally tried a BCM94360CS2 with a generic adapter card
[23:12] <howarth> That caused motherboard boot failures (red leds)
[23:13] <howarth> Switched to the bcm94360cd with a better quality adapter card and it has been flawless
[23:13] <howarth> Airdrop and Handoff out of the box under patched Catalina
[23:14] <howarth> The only thing that doesn't work is the TV app remote playback
[23:14] <howarth> which I suspect is unsupported SSE4,2 instructions somewhere
[23:16] <howarth> It would be interesting to know if the PC ROM'd GTX680 eliminated the nvidia-modeselect failures but I don't want to tempt fate by reflashing the card to test that
[23:16] <howarth> I filed that with nvidia a few years ago but that is super niche to them
[23:33] <mattfly> any idea why the auto hiding doc doesnt show up when controling ubuntu with symergy?
[23:45] <mattfly> also gnome is taking so much ram
[23:45] <mattfly> well idk, i installed the beta iso and ran upgrade, should i do something else to be in the RC?


[00:46] <chatter> hey guys
[02:13] <flexiondotorg> http://mate-desktop.org/blog/2016-12-22-server-outage/
[04:46] <sanjeev_> face disconnection issue with my WiFi
[04:47] <sanjeev_> Very frequently it disconnected
[04:47] <sanjeev_> any idea
[06:07] <Ghosthunter_> ?HELP
[06:07] <Ghosthunter_> Nevermind
[06:07] <Ghosthunter_> Figured it out.
[07:45] <sudosundu> Wow! Ubuntu mate increased my battery life
[07:45] <sudosundu> Thanks! for the community!
[07:45] <sudosundu> :)
[08:13] <wangrenai> +i
[08:13] <wangrenai> hello
[08:14] <alkisg> Hi
[08:15] <wangrenai> I am a newbie
[08:22] <ouroumov> Hello wangrenai. We won't hold that against you.
[09:53] <SylvainOnLine> Bonjour a tous, je recherche un client google drive gratuit pour ubuntu mate 16.04 impossible de trouver cela des idées ?
[10:07] <alkisg> !en
[10:07] <alkisg> SylvainOnLine: see this ^
[10:08] <alkisg> !fr
[10:09] <SylvainOnLine> Hi all, I'm looking for a free google drive client for ubuntu mate 16.04 impossible to find that ideas?
[10:32] <alkisg> SylvainOnLine: http://www.webupd8.org/2016/03/use-gnome-318-google-drive-integration.html
[10:33] <masnell_> @SylvainOnLine: try insync - works well for me with free & paid accts
[10:33] <masnell_>  Just recalled I saw an article on a new client available but do not recall the name sorry
[10:33] <alkisg> http://www.webupd8.org/2015/03/insync-12-released-with-new-html5-ui.html
[10:38] <masnell_> SylvainOnLine: https://plus.google.com/105258101046165462263/posts/iBxkVG9Yatf OverGrive is new, maybe worth checking out
[10:59] <SylvainOnLine> alkisg, masnell_ insync & overgrive is not free
[11:01] <alkisg> SylvainOnLine: the first link I gave, gnome drive integration, is open source
[11:02] <masnell_> SylvainOnLine: grive2 is free but is batch cli AFAIK
[11:06] <SylvainOnLine> alkisg, masnell_
[11:06] <SylvainOnLine> I try the first link but can not install gnome-control-center it does not find the package
[11:07] <alkisg> SylvainOnLine: run this: sudo apt-get update; sudo apt-get install gnome-control-center
[11:07] <alkisg> !info gnome-control-center
[11:07] <alkisg> It's normally available in the repositories, you should be able to find it
[11:10] <masnell_> $ apt search  gnome-control-center
[11:10] <masnell_> Sorting... Done                                                                                Full Text Search... Done
[11:10] <masnell_> gnome-control-center/xenial 1:3.18.2-1ubuntu6 amd64                                                     utilities to configure the GNOME desktop
[11:10] <masnell_> gnome-control-center-data/xenial,xenial 1:3.18.2-1ubuntu6 all
[11:10] <masnell_>   configuration applets for GNOME - data files
[11:10] <masnell_> gnome-control-center-dev/xenial,xenial 1:3.18.2-1ubuntu6 all                                            utilities to configure the GNOME desktop
[11:10] <masnell_> gnome-tweak-tool/xenial,xenial 3.18.1-1 all
[11:10] <masnell_>   tool to adjust advanced configuration settings for GNOME
[11:10] <alkisg> !pastebin
[11:10] <masnell_> alkisg: sorry, my bad, I should now better
[11:11] <alkisg> no worries it's not a crowded channel :)
[11:59] <SylvainOnLine> alkisg, masnell_ thanks its ok
[13:12] <cortana_> ehi
[13:12] <cortana_> mi servirebbe una mano
[13:13] <cortana_> o
[13:13] <cortana_> ?????'
[13:13] <cortana_> ??????
[13:14] <cortana> tutti morti?
[13:14] <cortana> tutti inglesi
[13:15] <cortana> i donate 1000€ for nothing....
[14:49] <alkisg> cortana, I didn't receive them, send them again :P
[15:35] <liu> hello
[19:31] <veter> hey
[23:41] <wangrenai> @ouroumov Thanks


[08:07] <jamespage> urulama, morning - I'm working through https://github.com/juju/charmstore-client/issues/61 whilst beisner is on leave
[08:07] <jamespage> urulama, is there a nice way I can login once, and them propagate the usso credentials to a number of machines so that they can all push and publish charms?
[08:21] <urulama> jamespage: hm. if you copy the store-usso-token in ~/.local/share/juju across machines, this should do the trick
[08:22] <urulama> we need to provide you with better instructions how to hook CI
[08:29] <jamespage> urulama, ok tried that, but charm whoami still thinks I'm not logged in on machines other than the one I generated that file on
[08:30] <urulama> jamespage: hm. seems like ~/.go-cookies are used still. try copying that file
[08:33] <jamespage> urulama, trying that now
[08:34] <jamespage> urulama, +1 that fixed me up
[08:34] <jamespage> thanks for the help
[08:44] <jamespage> tinwood, thedac, gnuoy, beisner: OK charm push on change landing for master and stable branches is now live.
[08:44] <tinwood> jamespage, excellent!
[08:45] <jamespage> thanks to urulama for helping get the auth sorted out
[08:46] <jamespage> +1 ta
[08:46] <tinwood> urulama, excellent too! :)
[08:46] <urulama> i think proper way would be to create a "bot" user to be used by CI
[08:47] <urulama> tinwood: ty, it has some rough edges still, but, we'll get there :)
[08:47] <jamespage> gnuoy, https://review.openstack.org/#/c/320817/
[08:47] <jamespage> urulama, agreed - we already have a bot user
[08:48] <jamespage> gnuoy, if you have time :-)
[08:54] <godleon> Hi all, I have a question about openstack charms, do you have any plan to develop charm for projects in big tent other than core projects? e.g. magnum, murano ... etc
[08:57] <jamespage> godleon, we're working on a way to make it easy to charm said projects - and the current team may pick off a few of those, but we'd love to have other contributors who know and use those projects working on the charms :-)
[08:58] <jamespage> godleon, find that works best rather than the 'read the docs -> write the charm' approach :-)
[08:59] <godleon> jamespage: thanks! I will spend some time to read the docs.
[09:00] <jamespage> godleon, still wip but worth a look - https://github.com/openstack-charmers/openstack-community/blob/master/openstack-api-charm-creation-guide.md
[09:00] <godleon> jamespage: And I have another question about nova-compute with LXD, is it possible to have two virt-type(KVM & LXD) simutaneously on the same openstack platform?
[09:01] <jamespage> godleon, yes - but not on the same servers
[09:01] <jamespage> godleon, one sec - letme pick out the reference for that
[09:04] <godleon> jamespage: wow, you are so kind. :)
[09:05] <jamespage> godleon, http://bazaar.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk/view/head:/README-multihypervisor.md
[09:05] <jamespage> np :-)
[09:09] <godleon> jamespage: can I manage multiple hypervisor's workload in one Horizon portal?
[09:09] <jamespage> godleon, yes
[09:12] <godleon> jamespage: How about the performance comparison between LXD and docker, havr you ever done this kind of test?
[09:12] <jamespage> no
[09:12] <jamespage> godleon, they target different spaces ...
[09:12] <jamespage> system containers vs application containers
[09:12] <jamespage> mutable vs immutable
[09:13] <godleon> jamespage: ok, I didn't have this concept, sorry about that.
[09:16] <godleon> jamespage: ok, I will dig into the LXD and multiple hypervisor architecture to evaluate if it can help me solve the problems in my project. Really appreciate for ur infomation. :)
[09:16] <jamespage> godleon, I did a talk about this in austin - letme dig out the video
[09:17] <godleon> jamespage: great
[09:17] <jamespage> godleon, https://youtu.be/u511z0BGnw4
[09:18] <jamespage> godleon, enjoy my shirt :)
[09:19] <jamespage> godleon, the demo is missing due to some video problems - I'll ping gsamfira to see if he's re-recorded the demo for us yet...
[09:19] <godleon> jamespage: haha, will do. Many thanks!
[09:19] <godleon> jamespage: wow, good! Thanks!
[09:20] <godleon> godleon: should I leave my email here?
[09:50] <gnuoy> jamespage, do you happen to know if the juju native bundle unit placement syntax is documented anywhere?
[09:50] <jamespage> gnuoy, probably but not sure where
[09:50] <jamespage> gnuoy, what are you trying todo?
[09:50] <gnuoy> lxc:nova-compute=1
[09:51] <gnuoy> jamespage, fwiw I know it's lxd now
[09:51] <jamespage> gnuoy, that does not work
[09:52] <jamespage> gnuoy, you have to target the actual machines
[09:52] <gnuoy> jamespage, ok, I can live with that, whats the syntax for targetting actual machines
[09:52] <gnuoy> ?
[09:52] <jamespage> gnuoy, read this - https://api.jujucharms.com/charmstore/v5/openstack-base/archive/bundle.yaml
[09:52] <gnuoy> jamespage, ta
[10:44] <jamespage> gnuoy, could you take a peek at https://code.launchpad.net/~james-page/charm-helpers/newton-opening/+merge/295693
[10:44] <jamespage> ?
[11:51] <coreycb> jamespage,  I fixed up the cinder.conf commit message.  I never realized you could edit it directly within gerritt.
[12:39] <jamespage> gnuoy, https://review.openstack.org/#/c/320817/
[12:39] <jamespage> all good to go
[12:40] <gnuoy> jamespage, approved your ch change too
[12:41] <jamespage> gnuoy, ta
[12:54] <gnuoy> tinwood, I really like the clean look of the baribcan charm. The only thing that jars a little for me are the setup_amqp_req, setup_database and setup_endpoint being part of barbican.py. they seem standard and not specific to barbican at all. Can we push them down into the layer or module?
[12:55]  * tinwood hadn't considered that.
[12:56] <tinwood> gnuoy, I'll take another look.  I sure there's a dependency on one of them on the charm, but the other two could probably move.
[13:00] <gnuoy> tinwood, do you agree in principle to moving them?
[13:04] <tinwood> gnuoy, setup_amqp_req() and setup_database() are both independent of the charm and could happily go elsewhere.  setup_endpoint() seems more problematic, in that it needs access to some of the charm's properties.  I'm wondering whether that might be better elsewhere?
[13:06] <gnuoy> tinwood, it was originally part of the charm class wasn't it? do you feel uncomfortable with it going back there?
[13:11] <tinwood> gnuoy, I'm not sure.  The `keystone` object is an interface class instance.  It would be possible to have a `register_endpoints` with a sig register_endpoints(keystone : `keystone-interface`) which then turns around a calls the register_endpoints() on the interface, assuming all OpenStackCharms will have service_type, region ... admin_url.
[13:13] <gnuoy> tinwood, It's safe to say all charms calling register_endpoints will have tose attributes
[13:13] <gnuoy> s/tose/those/
[13:13] <tinwood> I'm actually in favour of pushing the setup_amqp_req() and setup_database() basck to the handlers file in the charm.
[13:14] <tinwood> gnuoy, but I did want to keep all the handlers together.
[13:14] <tinwood> hmm.  It's because reactive forces us to put some functions in the reactive directory, but we're putting charm code in lib/
[13:16] <jamespage> gnuoy, we need a better way todo feature discovery in the cloud - https://review.openstack.org/#/c/320972/1
[13:16] <jamespage> I have this type of config option...
[13:17] <jamespage> have/hate
[13:17] <lazyPower> godleon - i've done some benchmarking in terms of starting containers but thats not much of a telling story. we both launch containers silly fast if you have the images cached. but jamespage was spot on with them targeting different spaces so its comparing apples to pineapples.
[13:18] <gnuoy> jamespage, I take it cinder-backup doesn't register an endpoint in keystone?
[13:18] <jamespage> gnuoy, hmm
[13:18] <jamespage> it might
[13:18] <jamespage> gnuoy, however...
[13:18] <gnuoy> if only there was some sort of service catalogue...
[13:18] <jamespage> gnuoy, I'd not want to query the service catalog for this; it should be done using charm semantics
[13:49] <petevg> cory_fu, kjackal, kwmonroe: I've got a question about Bigtop automagic, using the layer-apache-bigtop-spark charm as an example: Does Bigtop know to tell puppet to install spark simply because there is a "spark" entry in the "hosts" dict that we pass to render_site_yaml? Or is there additional configuration info in the charm that I'm missing?
[13:51] <cory_fu> petevg: It's actually the roles that define what gets installed: https://github.com/juju-solutions/layer-apache-bigtop-spark/blob/master/lib/charms/layer/bigtop_spark.py#L28
[13:52] <petevg> cory_fu: got it. That makes sense, now that I think about it.
[13:52] <petevg> Thank you :-)
[13:54] <cory_fu> petevg: The Bigtop Puppet scripts have two methods for selecting what gets installed: components or roles.   Roles are more fine-grained, and let you sepcify things more precisely, while components infer a lot more based on what hosts are provided
[13:56] <cory_fu> petevg: https://github.com/apache/bigtop/blob/master/bigtop-deploy/puppet/hieradata/site.yaml has a list of the components you can choose from, while https://github.com/apache/bigtop/blob/master/bigtop-deploy/puppet/manifests/cluster.pp has a (not 100% complete, it seems) listing of roles
[13:57] <petevg> Ooh, useful. Will bookmark that, and also link in the README.
[13:58] <cory_fu> Unfortunately, there doesn't seem to be much in the way of documentation of this stuff outside of the Puppet scripts themselves.
[13:59] <cory_fu> Adding some would be a good patch to submit, I think
[14:32] <deanman> Is it possible to deploy an openstack bundle on a Juju with manual provider? I can see from store that the default bundle requires MAAS.
[14:35] <magicaltrout> marcoceppi stop spamming me! :P
[14:40] <magicaltrout> arosales: they've fixed my CS login, if it makes you feel any better, I'm also listed in 0 teams ;)
[15:02] <marcoceppi> magicaltrout: stop opening bugs on the wrong project ;)
[15:02] <arosales> magicaltrout: glad to they got you sorted
[15:02] <magicaltrout> just doing what arosales told me :P
[15:02] <marcoceppi> arosales: stop opening bugs on the wrong project ;)
[15:02] <arosales> magicaltrout: I hear the ~charmer group is a good group to be in
[15:02]  * marcoceppi labored over that issue template
[15:03] <arosales> marcoceppi: ?
[15:03] <magicaltrout> Ctrl -a <backspace>
[15:03] <marcoceppi> magicaltrout: :sadpanda:
[15:03] <magicaltrout> hehe
[15:04] <marcoceppi> arosales: charm-tools is only for proof, build, inspect, layers, create, and a few other things. Everything else (login, whoami, push, pull, grant, publish) is charmstore-client
[15:04] <arosales> magicaltrout: you should at least be in charm contributor and apachefoundation
[15:05] <arosales> marcoceppi: how is any normal human suppose to know that?
[15:05] <arosales> marcoceppi: I install charm tools
[15:05] <marcoceppi> arosales: well, because I created an issue template that tells people this
[15:05] <arosales> I look at charm tools
[15:05] <magicaltrout> templates are for wimps
[15:05] <arosales> Version
[15:05] <marcoceppi> arosales: https://github.com/juju/charm-tools/issues/new
[15:05]  * marcoceppi tries so ahrd
[15:06] <magicaltrout> marcoceppi: you know that rule about website loading speeds
[15:06] <magicaltrout> it also applies to placeholder text ;)
[15:06] <marcoceppi> okay, so trim the fat, got it
[15:06] <magicaltrout> remove the first para for a start
[15:06] <magicaltrout> I know you like thanking people, but there is a time and a place... namely a juju charmer summit
[15:07] <marcoceppi> yeah, I was just thinking that as well
[15:07] <magicaltrout> you also have a typo in para 2
[15:07] <magicaltrout> agains isnt' a word
[15:08] <arosales> marcoceppi: how hard is it for us to move the bug?
[15:08] <marcoceppi> arosales: I already did
[15:08] <magicaltrout> hyper links don't work, so just remove the hyperlink markup
[15:08] <arosales> marcoceppi: so not very hard in general then
[15:09] <marcoceppi> arosales: it is very very annoying, because gh doesn't have a way to "move" issues
[15:09] <marcoceppi> and only admins of both repos can do it, so a select few in general
[15:09] <arosales> But something a person can do
[15:10] <marcoceppi> arosales: it's super SUPER dirty, ugly, and not friendly
[15:10] <arosales> I am +1 for the template
[15:10] <arosales> But
[15:10] <marcoceppi> magicaltrout: I've been mulling over the idea of `charm bug` or something that can collect 90% of this from the command line
[15:10] <arosales> Let's not make it cumbersome on someone giving feedback
[15:10] <marcoceppi> magicaltrout: not sure if people would actually use it
[15:11] <marcoceppi> I updated the issue template as well
[15:11] <arosales> ideally we have one place like Juju to summit all bugs and then triage from there
[15:11] <arosales> Make it easy for
[15:11] <arosales> Contributors
[15:12] <arosales> But that's ideal
[15:12] <magicaltrout> I don't think charm bug is a bad idea, if i'm already in the command line, copying that stuff out of my terminal is clearly harder than me typing charm bug
[15:12] <marcoceppi> arosales: sure, if we do that on Launchpad.
[15:12] <marcoceppi> because you can not move issues around in gh
[15:13] <marcoceppi> but we can in lp, but now you're subjecting people to lp
[15:13] <arosales> Well gh repo admin can I think
[15:13] <arosales> But that's technical
[15:14] <arosales> All I am saying is take the burden off someone trying to give feedback
[15:14] <magicaltrout> don't subject people to LP, most people will have a GH login, not so with LP. Finding anything in LP, including your own code is a pain in the ass :)
[15:14] <arosales> +1 on the template helping them
[15:14] <marcoceppi> arosales: you can not move issues between repos, pretend I ever said that
[15:14] <arosales> Get to the right spot
[15:15]  * marcoceppi spins up a third, bugzilla site ;)
[15:16] <magicaltrout> juj deploy cs:bugzilla juju-charm-website-massive-bug-aggregator
[15:16] <magicaltrout> +
[15:16] <magicaltrout> u
[15:16] <arosales> My feedback is make it easy on contributors even if it isore back end woek
[15:17] <arosales> .. If it is more back end work
[15:18] <arosales> +1 for templates to help folks get to the right place, but if that fails let's just take care of it on the back end, even if copy paste
[15:24] <arosales> magicaltrout: would you mind if I demo'ed your mesos bundle?
[15:24] <magicaltrout> not at all arosales
[15:24] <magicaltrout> just bear in mind currently it doesn't support > 1 master
[15:25] <magicaltrout> which i appreciate defeats the point slightly, but there is a fix in the works for that, its just wiring as opposed to anything technical
[15:25] <arosales> magicaltrout: attending mesoscon in Denver next week and would like to present your bundle at a lighting talk
[15:25] <magicaltrout> yeah i was thinking about showing up to MesosCon europe with a talk if they fancied it
[15:26] <arosales> magicaltrout: could you point me at your latest bundle?
[15:26] <magicaltrout> ah yeah i've not published it yet :P
[15:26] <magicaltrout> should probably do that
[15:27] <magicaltrout> https://github.com/buggtb/dcos-master-charm / https://github.com/buggtb/dcos-agent-charm / https://github.com/buggtb/dcos-interface
[15:27] <magicaltrout> currently
[15:27] <arosales> magicaltrout: thanks
[15:28] <magicaltrout> i'll try and get the multi-master finished this week and get it published
[15:28] <arosales> magicaltrout: oh no worries on working on it this weekend on my account
[15:29] <arosales> https://www.irccloud.com/pastebin/7DJdv9mG
[15:30] <magicaltrout> its like you're talking to me in a webpage....
[15:30] <arosales> magicaltrout: have you seen the work SaMnCo and data art have done on mesos
[15:30] <magicaltrout> I've not seen it, but he tried to hook us all up pre-apachecon and we all said hi then it went quiet
[15:30] <arosales> Dang phone client
[15:31] <magicaltrout> i mailed SaMnCo the other day to try and reboot it, but i've noticed if I mail him with more than one issue a day, the others don't get a response, so that went unanswered ;)
[15:31] <arosales> I'll try to follow up with SaMnCo
[15:31] <arosales> magicaltrout: could you
[15:31] <arosales> Add marcoceppi and I to cc?
[15:31] <magicaltrout> I'm not sure what they are upto , but it would be cool to get all of this stuff aligned, hipster tech and all that
[15:33] <magicaltrout> will do
[15:34] <magicaltrout> i also need to get a talk submitted to Oslo Devops Days, so I'll probably submit something similar to what I did in that ApacheCon talk with some more hadoop-y stuff to pad it out
[16:00] <arosales> magicaltrout: good stuff, thanks
[16:20] <kjackal> petevg: Thank you for the README PR. Docs is something (at least) I have to pay more attention. Good work!
[16:21] <petevg> kjackal: thanks. Nice to hear that it's appreciated :-)
[16:44] <kwmonroe> cory_fu: what's wrong with me?  why can't i see an issues tab here? https://github.com/juju-solutions/layer-apache-bigtop-nodemanager
[16:45] <kwmonroe> and why does going to https://github.com/juju-solutions/layer-apache-bigtop-nodemanager/issues redirect me to PRs?
[16:45] <cory_fu> That repo doesn't have issues enabled, apparently.  Probably some weirdness because of how it was forked
[16:45] <cory_fu> We should probably re-own it anyway, so it's easier to make PRs
[16:46] <cory_fu> kwmonroe: Anyway, issues are enabled now
[16:46] <kwmonroe> gracias!
[17:38] <bdx> openstack-charmers: when using nova-lxd, am I confined to using local storage, or does ceph work in some way as a backend for nova-lxd that I'm unaware of?
[17:49] <tinwood> gnuoy, you about or eod?
[17:55] <hatch> Is there a way to get the full log from a unit from the Juju CLI?
[18:00] <lazyPower> hatch - yep
[18:00] <lazyPower> juju debug-log -i --replay
[18:00] <lazyPower> you'll need to pass the unit in the -i flag
[18:00] <lazyPower> hatch if you dont want to tail after its done, pass -F
[18:00] <lazyPower> or, juju debug-log --help for the full list of awesome
[18:01] <hatch> lazyPower: ahhh that's it - I didn't read the docs for --replay because I didn't want to 'replay' them, I just wanted to see them
[18:01] <hatch> heh
[18:01] <hatch> thanks :)
[18:01] <lazyPower> ye :) that'll get ya sorted
[18:01] <lazyPower> cheers
[18:20] <hatch> how do I destroy a service with units in error?
[18:20] <lazyPower> hatch juju remove-machine --force #
[18:21] <lazyPower> hatch then juju destroy-service will cleanly remove the service/charm from the controller
[18:21] <lazyPower> that or juju resolved mything/0    all the way down as it fail-cycles until its removed
[18:21] <hatch> thanks lazyPower
[18:22] <hatch> saying to destroy a service and getting no feedback is not very good
[18:22] <lazyPower> i dont know that i'm following what you're calling attention to. How did you not get feedback?
[18:22] <hatch> I can spam destroy-service and because units are in error nothing happens
[18:22] <hatch> and I get no feedback
[18:23] <hatch> so I just sit here wondering why Juju is broken :)
[18:23] <lazyPower> ah, well, do you expect the command to block until its removed?
[18:23] <hatch> at the very least I'd expect a message telling me why it's not doing what I told it to do
[18:23] <lazyPower> its doing the right thing in my mind. its a one-shot declaring a state. "Remove this thingy!!" and its trying its best to get there, and if it fails to do so it reports that.
[18:24] <lazyPower> thats a disconnect between blocking commands and the fire/forget style state change you've defined.
[18:24] <hatch> no it doesn't
[18:24] <hatch> it doesn't report anything
[18:24] <lazyPower> juju status sure does
[18:24] <hatch> I guarantee it doesn't
[18:25] <hatch> https://gist.github.com/hatched/9a374d20d007e019d3ec2045cf7edc1f
[18:25] <lazyPower> thats funny. workload-status: error
[18:25] <hatch> where there says that I have destroyed the service about 10 times?
[18:25] <lazyPower> message: hook failed 'install'
[18:25] <hatch> yep the hook failed - so why can't I destroy the service?
[18:26] <natefinch> lazyPower: I'm with hatch.  juju destroy-service, IMO, should just take down errored units.  who cares if a unit is in an error state, I'm explicitly removing it
[18:26] <lazyPower> you're making an assumption about what it should be doing
[18:26] <lazyPower> and i dont agree with your assumptions
[18:26] <lazyPower> "i said destroy service, and its still here D:"
[18:26] <lazyPower> what if you want to debug that while its in life: dying?
[18:26] <hatch> so you prefer for the command to just return with no message to the user
[18:26] <lazyPower> and root out what the cause was?
[18:26] <lazyPower> no, i want you to admit that you're conflating two issues
[18:27] <natefinch> I definitely agree that if we KNOW that destroy-service is not going to work, we tell the user
[18:27] <hatch> I said to Juju to destroy the service - I want it to destroy the service
[18:27] <lazyPower> thing is
[18:27] <lazyPower> juju status --format=yaml
[18:27] <lazyPower> the life is going to be dying
[18:27] <hatch> but it's not dying
[18:27] <lazyPower> it received and is working towards that destructive state
[18:27] <hatch> it's going to sit there forever
[18:27] <natefinch> juju destroy-service foo
[18:27] <lazyPower> the fact there's a hook error is regardless of what state change you just told it to take
[18:27] <natefinch> ERROR: can't destroy service, unit in error state: foo/0
[18:27] <hatch> ^^^ this
[18:27] <hatch> 100x this
[18:28] <natefinch> if we want to be pedantic and conservative and not destroy an errored unit automatically.... at least tell the user we're not going to do it
[18:28] <lazyPower> thing is, it IS going to do it if you resolve it and it doesn't further error
[18:28] <hatch> if you're not doing to do what the user intends to do then at least tell them why
[18:28] <lazyPower> its not "uncommitting" that destroy directive
[18:28] <natefinch> WARNING: unit foo/0 in errored state, will not be destroyed until resolved.
[18:29] <lazyPower> that makes more sense
[18:29] <lazyPower> i'm +1 to that
[18:29] <natefinch> throw me a bone, FFS.  The user shouldn't need to know the internal details of exactly how everything works... we should help them to use juju
[18:29] <hatch> YES!
[18:29] <lazyPower> but i still stand that its 2 sep. issues.
[18:30] <natefinch> I'm fine with it being two separate issues - do we or do we not destroy errored units automatically?   and, if we don't, we need to tell the user explicitly.
[18:30] <natefinch> And honestly, I wish destroy-service were synchronous, like destroy-model is now
[18:31] <natefinch> maybe with a flag to make it async... or vice versa....  I shouldn't ever need to type watch juju status in order to figure out WTF is going on in juju
[18:31] <hatch> +1
[18:31] <lazyPower> i'm going to leave this alone
[18:31] <hatch> lol
[18:31] <mbruzek> what?
[18:31] <lazyPower> this is going off the rails into a really bad gripe session
[18:31] <natefinch> lol true, sorry :)
[18:32] <hatch> I'm going to file a bug about the destroy-service messaging
[18:32] <mbruzek> natefinch: I watch juju status all the damn time
[18:32] <mbruzek> It is the only way to figure out what is going on behind the curtain
[18:32] <mbruzek> That wizard is up to some crazy stuff folks, I constantly watch juju status and tail the debug log
[18:32] <natefinch> mbruzek: that's my point.  You shouldn't have to.  Like the way destroy-model is synchronous and actually tells you what it's doing.
[18:32] <lazyPower> whats fun is something errors you destroy it, then figure out it was like a race condition and the charm can recover... it goes to started, then immediately destroys itself
[18:32] <lazyPower> thats the best
[18:33] <hatch> lazyPower: sorry I told it to do something - I expect it to listen :)
[18:33] <hatch> I don't much care what it wants
[18:33] <lazyPower> again. it listened
[18:33] <lazyPower> you weren't prepared for the sequence of papercuts afterwords
[18:34] <hatch> this is like going to a restaurant, placing an order with the server and then the server walks away
[18:35] <hatch> you sit there forever waiting for your food
[18:35] <hatch> it was sitting in the kitchen, but you forgot to tell them to deliver it
[18:35] <hatch> not that you knew you had to say that
[18:35] <hatch> because the server didn't tell you that
[18:35] <lazyPower> look i'm not saying you're wrong, i'm saying teh way you're conveying it and griping is wrong, beause you're telling me it didnt do something that it is celary doing
[18:35] <lazyPower> *clearly
[18:35] <hatch> how is it doing it? It isn't destroying the service
[18:35] <lazyPower> did you juju remove-machine # --force?
[18:36] <hatch> I did
[18:36] <lazyPower> teh service should have gone then
[18:36] <lazyPower> its dead
[18:36] <lazyPower> has no units
[18:36] <hatch> it did
[18:36] <lazyPower> is in state: dying
[18:36] <lazyPower> then how did it not destroy?
[18:36] <hatch> so destroy-service isn't destroy service
[18:36] <hatch> it's "mark for destroy sometime in the future when a pretermined list of requirements have been satisfied - oh but you don't know what those are"
[18:37] <hatch> that's quite the command ;)
[18:37] <natefinch> it seems to me that if destroy-service had a --force flag, it would help a lot.
[18:37] <lazyPower> thats not true either
[18:38] <lazyPower> hatch - this. x1000 is this conversation
[18:38] <lazyPower> https://xkcd.com/386/
[18:38] <hatch> lol except this _is_ important
[18:38] <hatch> users need to be informed about what's going on
[18:38] <hatch> and if it's not doing what they said to do they need to know why
[18:40] <mbruzek> Has anyone opened a bug about this problem? With the problem statement, and expected result. I think others would like to see this and possibly comment on either it is working as designed or a problem that will get fixed next release.
[18:40] <hatch> mbruzek: here is one I filed earlier https://bugs.launchpad.net/juju-core/+bug/1568160
[18:40] <mup> Bug #1568160: destroying a unit with an error gives no user feedback <destroy-unit> <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1568160>
[18:41] <hatch> I actually totally forgot I filed that one
[18:41] <hatch> haha
[18:41] <hatch> I file a lot of bugs
[18:41] <hatch> :)
[18:42] <hatch> mbruzek: I think there are really two points here - 1) why errors block removal actions and 2) lack of user feedback in any case
[18:52] <mbruzek> hatch: natefinch: lazyPower: I commented on the bug ^.  I think the actual problem is the charm code had a bug, and would not destroy because a hook returned non zero and that is literally how Juju hooks works.
[18:52]  * lazyPower smirks
[18:52] <hatch> https://bugs.launchpad.net/juju-core/+bug/1585750
[18:52] <mup> Bug #1585750: Destroying a service in error gives no feedback <juju-core:New> <https://launchpad.net/bugs/1585750>
[18:55] <hatch> mbruzek: your comment doesn't really apply
[18:56] <hatch> mbruzek: if you want to fix the error then fix the error
[18:56] <hatch> you wouldn't destroy it if you wanted to fix it would you?
[18:56] <mbruzek> in the charm code rather than fix juju
[18:56] <lazyPower> stop isn't executed without first destroying the service or removing a unit
[18:56] <magicaltrout> marcoceppi: ping
[18:56] <lazyPower> you may not know its a problem until you've already issued the destroy stanza, and by your proposal - there is no way to really debug it. its just LOL bye.
[18:56] <marcoceppi> magicaltrout: yo
[18:56] <mbruzek> Actually hatch that is a valid test case when developing a charm. I want to make sure that the charm goes down cleanly
[18:57] <magicaltrout> hey, 2 things
[18:57] <magicaltrout> a) warning: bugs-url and homepage are not set.  See set command.
[18:57] <magicaltrout> hmm nm
[18:57] <mbruzek> hatch: There is no other way to call the stop hook that I know of.
[18:57] <magicaltrout> ignore that one
[18:57] <magicaltrout> b) https://jujucharms.com/u/apachesoftwarefoundation/ why did the charm I publish earlier vanish?
[18:57] <marcoceppi> magicaltrout: are you logged in
[18:58] <magicaltrout> i am logged in
[18:58] <hatch> mbruzek: This is the first time I've ever heard of any reason to not clean up on error
[18:58] <mbruzek> hatch: If the charm *-broken relations, or stop hooks, did something really important, I would TOTALLY want to know if they worked or not.
[18:59] <hatch> mbruzek: but put yourself in the users shoes - how are they supposed to know any of this?
[18:59] <mbruzek> Like backing up data to S3 or doing other important clean up things
[18:59] <magicaltrout> i fully had a charm there earlier that I went to look at and stuff
[18:59] <lazyPower> magicaltrout - its likely permissions
[18:59] <hatch> mbruzek: there is literally 0 feedback or help given to the user
[18:59] <mbruzek> hatch: I *am* thinking of the users. I would propose that you are using the wrong command.
[18:59] <lazyPower> magicaltrout - pastebin teh output of charm show cs:~apachefoundation/mything
[18:59] <hatch> mbruzek: so what command am I supposed to use?
[18:59] <mbruzek> If there are errors in the hook, remove-machine
[19:00] <mbruzek> or resolve the errors
[19:00] <natefinch> mbruzek: In the long term, 99.9999% of users will not be charm authors
[19:00] <hatch> ok so I'm supposed to know that when I try to destroy a service, if there is an error I need to remove the machines
[19:00] <hatch> but I have to actually check juju status
[19:00] <hatch> often
[19:00] <hatch> to know what commands to run
[19:00] <magicaltrout> marcoceppi: http://paste.ubuntu.com/16691257/
[19:01] <lazyPower> magicaltrout   Read:
[19:01] <lazyPower>   - apachesoftwarefoundation
[19:01] <lazyPower> thats the issue
[19:01] <lazyPower> magicaltrout charm grant cs:~apachesoftwarefoundation/trusty/joshua-full --acl=read everyone
[19:01] <lazyPower> the reason you saw it was because you were logged into the store, and had access to "read" the charm
[19:01] <lazyPower> if you checked it in private mode, you would not have seen it.
[19:02] <mbruzek> hatch you and natefinch, when a hook returns a non zero return code Juju pauses to let the admin fix the stuff. If the stop hooks were doing some legit backup sequence, the admin would totally want to know if that is not working
[19:02] <magicaltrout> you are correct lazyPower it is perms related.... that said jujucharms.com says I'm logged in
[19:02] <lazyPower> ooo
[19:02] <lazyPower> weird
[19:02] <hatch> mbruzek: fine, but how do they know that?
[19:02] <magicaltrout> and once I granted permissions it appeared, but i'm on the homepage and can see my face
[19:02] <magicaltrout> which tends to indicate i am logged in
[19:02] <hatch> how do they know to resolve the units?
[19:02] <magicaltrout> anyhoo, weird, but works, thanks a lot
[19:03] <lazyPower> hatch - clairvoyance obviously
[19:03] <hatch> lazyPower: this is how my experience has been, yes
[19:03] <lazyPower> as i said, feedback is fine
[19:03] <mbruzek> hatch: Charms throw all kinds of errors, resolve is the mechanism to force Juju to proceed
[19:03] <natefinch> I think that if the unit is in an error state *before* calling juju destroy-unit, we should warn the user and ask them if they want to destroy it anyway
[19:03] <lazyPower> bu ti do take issue with wholesale deletion of a service in error state
[19:03] <lazyPower> unless you make it flag based where thats not default behavior
[19:03] <lazyPower> as cmars suggested which is nice middle ground
[19:04] <lazyPower> cmars thanks for being the voice of reason in this
[19:04] <cmars> reason? me? what? :)
[19:04] <lazyPower> you're the only one who piped in with adding --i-mean-it
[19:04] <cmars> :)
[19:04] <lazyPower> which is nice middle ground
[19:04] <lazyPower> keep default behavior, give the hatches of the world an option to wholesale delete
[19:04] <hatch> I really don't understand why there is so much resistance to working hard on user experience with the CLI
[19:04] <hatch> there is a problem, lets work on a fix
[19:05] <hatch> not drag our heals because this is how it is
[19:05] <lazyPower> hatch - because your campaigning for something thats really destructive and ops people will not appreciate it
[19:05] <cmars> i think mbruzek has a good point, but i've certainly screwed up a charm with repeated `juju upgrade-charm --force-units ... ; juju resolved --retry` that I have no confidence its state reflects any kind of debuggable reality
[19:05] <lazyPower> yup
[19:05] <lazyPower> we've all been there but thats an edge case
[19:06] <cmars> there's also the case where you're trying out different versions of charms, not really developing on them, just evaluating them
[19:06] <natefinch> I think the problem might just be that a hook error can mean two wildly different things - one is "something external is wrong, you have to do this concrete step to fix it before I can continue" and the other is "there's a bug in the hook, good luck!"
[19:06] <cmars> oops, i got the old precise version.. nooo
[19:07] <hatch> lazyPower: I strongly disagree that leaving the user to "just have to know" what to do is a good idea
[19:07] <cmars> with reactive its easier to be resilient in the face of externalities
[19:07] <hatch> you should always do what they expect to do
[19:07] <lazyPower> hatch - i didnt say dont give the user feedback
[19:07] <lazyPower> i said dont wholesale delete my thing unless you are absolutely sure thats what i want
[19:07] <lazyPower> again, conflating 2 issues
[19:08] <lazyPower> please stop and re-read my exact statement of my stance in teh 3 lines above
[19:08] <lazyPower> because its really exhausting repeating myself on this
[19:08] <cmars> hmm
[19:08] <hatch> lazyPower: I just want user feedback with instructions on how do what the user is intending
[19:08] <hatch> lazyPower: what do you think the user wants to do when they type 'destroy-service' ?
[19:08] <hatch> it's certainly not sit there
[19:08] <natefinch> ERROR: unit is in an errored state, can't be removed. To remove anyway, use juju destroy-unit foo/0 --force.
[19:08] <hatch> ^ this
[19:28] <godleon>  lazyPower, good! thanks for your information. And..... the images caches is for LXD or for both?
[19:28] <lazyPower> lxd requires you to import the image before you can even launch the container, so to be fair, both
[19:33] <godleon> lazyPower, hmm...........it makes sense.
[19:42] <ryebot> marcoceppi, lazyPower - what's the right way to fix this? https://github.com/juju-solutions/layer-basic/pull/70
[19:42] <marcoceppi> ryebot: why are we just seeing this now?
[19:43] <ryebot> marcoceppi still trying to figure that out - best guess is some package deps changed and are pulling in 8.1.1 now
[19:43] <ryebot> cynerva, you experimented with this - can you comment?
[19:44] <Cynerva> marcoceppi ryebot - not much info, i'm seeing the issue too, on xenial but not trusty
[19:44] <marcoceppi> Cynerva: sure, but when I did a xenial deploy last week I didn't get this error
[19:45] <Cynerva> marcoceppi yeah - seems like something changed today
[19:45] <marcoceppi> so weird
[19:45] <ryebot> marcoceppi yeah, last few hours, happened to both of us independently at roughly the same time
[19:45] <marcoceppi> xenial has always had 8.1.1
[19:46] <ryebot> marcoceppi yeah, but I think it wasn't being pulled in before
[19:46] <ryebot> marcoceppi so we pulled in 7.1.2 first
[19:46] <lazyPower> perhaps you used virtualenv: true, and that locked your pip version in a virtualenv instead of using system pip?
[19:46] <marcoceppi> charm build and layer-basic haven't changed ina bit
[19:46] <lazyPower> or perhaps thats the path forward?
[19:47]  * lazyPower is not positive, but thinks that would have some good results, isolating from system deps and creating your own python tree of goodness
[19:47] <marcoceppi> lazyPower: it's annoying to have to do that, but possible owrk around
[19:47] <lazyPower> well we are getting kind of funky with python across series these days
[19:47] <lazyPower> considering xenial is py3 default, trusty is py2 default, and we're somewhere in the middle of all that
[19:48]  * marcoceppi does tests
[19:48] <marcoceppi> lazyPower: py3 is on both trusty and xenial
[19:48] <marcoceppi> that's not a problem, it's the versions of pip that's problematic
[19:48] <marcoceppi> I can't remember why we had to upper bound pip for trusty, but we did
[19:50] <marcoceppi> huh, maybe not. It looks like I just upper bound it for no good reason
[19:50] <marcoceppi> ryebot: I think your pull request is OK actually'
[19:51]  * ryebot reopens his PR victoriously!
[19:58] <lazyPower> \o/
[20:01] <lazyPower> marcoceppi - i think at the time there was a dependency issue like the frequent path.py woes. i dont recall the exact details, but it was a temporary solution to a temporary problem
[20:03] <marcoceppi> lazyPower: possibly
[20:08] <magicaltrout> marcoceppi: whats the latest beta?
[20:08] <marcoceppi> beta7
[20:09] <magicaltrout> is there a ppa for that?
[20:11] <lazyPower> ppa:juju/devel
[20:11] <magicaltrout> aye ta
[20:11] <lazyPower> or grab charmbox:devel


[03:59] <joelesko> micahg: I added the change to my beta branch. Going to do a test build to verify.
[04:02] <joelesko> micahg: I looked at the thunderbird code branches and see what you mean that you need to redo the seamonkey branches to better organize them
[04:03] <joelesko> Let me know if there is anything I can help with.
[04:56] <micahg> joelesko: thanks, I think just stable and beta are fine for seamonkey at this point
[05:53] <micahg> joelesko: ok, so a few things, first, the changelog target should be UNRELEASED, this can be accomplished by making a new changelog with dch -i -DUNRELEASED or dch -v VERSION_GOES_HERE -DUNRELEASED
[05:55] <micahg> joelesko: second, patches should only be removed if they're applied upstream, not if they don't apply to the source (they may need to be rebased)
[05:57] <micahg> joelesko: third, r261 is confusing, the patches are removed, but they're added to the series file
[05:57] <micahg> joelesko: regarding these patches, you might want to look at the thunderbird-beta branch to see which ones have been kept and which ones dropped
[06:00] <micahg> joelesko: if you want to try to fix these, you can start with a fresh branch and pull each revision in individually from the old one with bzr merge -c, then you can overwrite the branch you pushed to LP with your new changes
[06:01] <micahg> joelesko: if this were a production branch, we'd just commit on top though, but since it's a branch to be merged, you have that luxury :)
[06:08] <micahg> joelesko: also, if you can make the commit for the new beta release separate (i.e. before you make changes related to the new release), that would be great
[12:37] <chrisccoulson> g'ah, i hate this KDE patch
[12:37] <chrisccoulson> i think we should kill it
[12:37] <chrisccoulson> it's such a pain having a distro patch this bug
[12:37] <chrisccoulson> **big
[12:45] <chrisccoulson> m_conley_away, you around?
[12:45] <chrisccoulson> could we get the latest version of messagingmenu-extension on addons.mozilla.org?
[12:46] <chrisccoulson> we have some upgraders from natty who installed it, and are having issues after upgrading to oneiric (because it takes priority over the bundled version, and loads old libraries in to thunderbirds address space)
[13:39] <chrisccoulson> w00t, i'm attending mozcamp in berlin :)
[13:39] <chrisccoulson> busy month next month
[14:47] <byte_bucket> anyone here happen to be involved in the CA (re)verification project  ?
[15:43] <micahg> chrisccoulson: you were supposed to upstream the KDE patch :P
[15:43] <chrisccoulson> micahg, well, it's maintained by the opensuse maintainer
[15:44] <chrisccoulson> and it's not really in an "upstreamable" form
[15:46] <joelesko> micahg: I did the changes you requested to  my beta branch ( I think) . The pldhash is in the upstream version as pldhash.cpp.
[15:47] <joelesko> micahg: I'm not sure I'm in sync with what you want yet. I was having some problems with the merge -c stuff.
[15:47] <micahg> joelesko: thanks, it's a busy short week for me, so I might not get to review again before the weekend
[15:48] <joelesko> no problem. I want to build the beta to make sure it works.
[15:48] <micahg> joelesko: so, I was just offering a tip there, it's not required, bzr merge -c REV_NO just gives you the diff of one revision that you can apply to another branch
[15:49] <joelesko> micahg: I apperciate tip. I'm always open to learn a better way. I know you have been doing for a long time and would like to learn from your experiences.
[15:51] <joelesko> chrisccoulson: Is the L10N intergration difficult?
[15:51] <micahg> joelesko: better, but, can you make each change/entry in debian/changelog a single commit, they came through all as one commit this time
[15:52] <micahg> it makes it easier to review the changes as well as merge specific changes to another branch
[15:52] <micahg> joelesko: well, we wanted to do l10n for oneiric, but I had a build failure, I can push up my branch if you want to play with it
[15:52] <joelesko> micahg: I was wondering about that. I think you said it a few times. Each '*' in the changelog needs to be it's own commit. Correct?
[15:53] <micahg> joelesko: yes, and bzr commit will use whatever the diff is in debian/changelog as the commit message in oneiric on
[15:54] <micahg> joelesko: also, let's not hardcode specific tags in debian/rules, it should be able to use any tag from the beta channel ideally
[15:55] <joelesko> ok. makes sense
[15:56] <joelesko> I will fix those issues later today. Thanks for the feedback.
[16:11] <mdeslaur> chrisccoulson: have you seen an issue where opening firefox will only show the window decorations with nothing inside?
[16:11] <mdeslaur> chrisccoulson: retrying 2-3 times eventually makes it open
[16:14] <chrisccoulson> mdeslaur, i haven't
[16:15] <chrisccoulson> mdeslaur, perhaps try chrome? isn't that what everyone else is using anyway?
[16:15] <chrisccoulson> sorry, that was meant to be sarcastic ;)
[16:15] <chrisccoulson> not having a good start to the week
[16:17] <micahg> chrisccoulson: so this would be a bad time to tell you I'm out Thursday and Friday again this week (last one until I go on a real vacation) ;)
[16:18] <chrisccoulson> micahg, i don't mind. perhaps i will book some time off at the end of the week too
[16:19] <mdeslaur> chrisccoulson: I can blame compiz if it makes you feel any better
[16:20] <chrisccoulson> mdeslaur, oh, blaming compiz always makes me feel better
[16:20] <micahg> mdeslaur:  there are bugs about compiz/vlc already :)
[16:20] <chrisccoulson> especially seeing as i don't use it ;)
[16:20] <micahg> unity-2d FTW! :)
[16:20] <chrisccoulson> heh
[16:20] <chrisccoulson> i actually like gnome-shell
[16:20]  * chrisccoulson hides
[16:20] <micahg> chrisccoulson: you're safe in this channel (mozjs :))
[16:21] <chrisccoulson> but i prefer unity-2d over both of them
[16:23] <joelesko> chrisccoulson: I always blame it on solar flares :)
[16:23] <chrisccoulson> heh :)
[16:24] <chrisccoulson> wow, i've booked my flight to the platform rally already. i normally end up forgetting about it and then leaving it really late
[16:26] <joelesko> micahg: If we don't put a tag in for what release to use, shouldn't all patches be removed?
[16:27] <micahg> joelesko: huh? why?
[16:27] <joelesko> from the beta branch
[16:27] <joelesko> If you check out a different beta, patches may not work.
[16:27] <joelesko> Or am I missing something
[16:27] <micahg> joelesko: the patches should only be removed when they get applied upstream or are no longer necessary due to upstream changes (not just not apply)
[16:29] <micahg> joelesko: we'll track the latest version of the channel in question, that's why commiting which version you're working on (as an entry in debian/changelog) is important, people can see at what point stuff gets changed/dropped
[16:29] <joelesko> ohhhh. Now I get it. Thanks
[16:40] <chrisccoulson> mdeslaur, do you see anything on the console when you see your firefox bug btw?
[16:42] <mdeslaur> chrisccoulson: no, but I'll restart my session, may not be a firefox issue


[01:08]  * guiverc notes no new daily.. i know about soft-freeze, but didn't expect RC till monday; older casper my main watch point
[01:15] <kc2bez[m]> I think sil2100 built some pre-RC isos yesterday.
[01:15] <guiverc> :)  I gathered that from his chosen wording.
[01:16] <kc2bez[m]> Not sure if you noticed but I updated the release notes.
[01:17] <guiverc> yeah I noted that; I haven't noticed a change but only glanced at it (~a min ago actually)
[01:22] <guiverc> the "Resolved Bugs" section can be removed I think kc2bez[m] ; BTRFS issue seems resolved given testing by @Leokolb, I can run another test if confirmation helpful, but I gather we've got that resolved (the text could be reword to say resolved; but why not just remove it?)
[01:23] <guiverc> if the intention of the paragraph was to say you shouldn't get that issue anymore with 22.04.1, I missed that from my reading.
[01:27] <kc2bez> Good point. I guess I was thinking we should note bugs that were in previous release notes and now resolved. It should probably be reworded to note that better.
[01:28] <guiverc> :)  want me to have a go? or you happy to.
[01:28] <kc2bez> Sure go ahead.
[01:33] <kc2bez> I will give it a look in my morning.
[01:34] <guiverc> yeah, I just started an QA-test install so it's only one 'ball in the air' currently
[01:38] <guiverc> paragraph changed... returning to UWN


[06:46] <ToyKeeper> I wonder why there are new builds happening this week.  I thought everyone was off until the new year.


[19:03] <graph> Hello I would like to ask about something. Lubuntu 18.04 LTS Bionic Beaver is based on Debian 9 Stretch?
 Not directly
 During the development cycle, packages are pulled from Debian Sid
[19:03] <graph> hmmm..
 While there is a lot of coordination, so many packages might end up at same versions, packages are pulled from Sid
[19:04] <graph> So I want to install OpenSnitch what package od Deb to chose? https://pkgs.org/download/openvswitch-switch
 Ubuntu 18.04 LTS (Bionic Beaver)
[19:05] <graph> I know <lubot> thx for answer. I have Lubuntu 18.04 LTS
 Yes, but it's the same archive :)
[19:06] <graph> what DEB package choose to install https://pkgs.org/download/openvswitch-switch ???
[19:06] <graph> Debian 8 or Debian 9 or Debian Sid?
 Ubuntu 18.04 LTS (Bionic Beaver)
 Don't install Debian packages on Ubuntu-based systems.
[19:07] <graph> Please look its very important to me because I would like to know what package to install at present and in the fture
 Lubuntu 18.04 is Ubuntu 18.04 at its core
 Yes
 I know
 I see what you're saying
 Just listen to what I'm saying ;)
[19:07] <graph> I know sory I dont speak english fluently and good
 Your answer is Ubuntu 18.04 LTS (Bionic Beaver)
[19:07] <graph> So forgive me
 No problem :)
[19:09] <graph> Ok but..sory for my next question. I use to install Deb package ..gDebi...I always use as equwallent for 18.04 LTS Debian Strech
[19:09] <graph> And in most is working
[19:09] <graph> :):)
[19:10] <graph> But few hours ago I have found this chart... https://askubuntu.com/questions/445487/what-debian-version-are-the-different-ubuntu-versions-based-on?rq=1
[19:10] <graph> and I am suprised
 When you're talking about downloading packages to install, I would ignore that
[19:11] <graph> according this chart they say that  18.04 LTS Bionic is Debian Buster/Sid   - 10 (so its Debian 10)
 Well, you have to understand how Debian works
 When Debian wants to put a package into the next release, they first upload to Sid
 Ubuntu pulls from there
 Debian then migrates packages into Testing
 Testing is what is released
[19:12] <graph> Could you tell me why? sory I am not totall nOOb but I am not professional. I am just user who use Lubuntu from5 years
 Both of them have a common origin
 However, one is not based off of the other
 Does that answer your question?
[19:13] <graph> Ok
[19:13] <graph> Understan o
[19:13] <graph> Understand
[19:14] <graph> So Do you know OpenSnitch?
 I don't
[19:14] <graph> Its very good tool
[19:14] <graph> Very Uniqe
[19:14] <graph> Very uniqw
[19:14] <graph> Oohhh..
 I bet
[19:14] <graph> Its firewall / Guard for application
[19:14] <graph> Not like GUFW
[19:15] <graph> Gufw works deeper OpenSnitch I think is working on application layer
[19:15] <graph> please look https://www.linuxuprising.com/2018/04/how-to-install-opensnitch-application.html
[19:16] <graph> This app I think should be in Repository of Lubuntu its great for medium skill user
[19:16] <graph> Is very uniqe
 ahh
[19:16] <graph> For user who are not god of terminal commands:_
[19:16] <graph> :)
[19:17] <graph> Just proposition: Years ago I was proposed Kaffeine to add to repo and Devs of Lubuntu add it:) for my proposition
 cool :)
[19:18] <graph> here is for github https://github.com/evilsocket/opensnitch
[19:18] <graph> Very cool!!
[19:18] <graph> Its good complementation for gufw
[19:19] <graph> And I know that OpenSnitch is fork of the best application firewall on MAC
[19:19] <graph> On Mac its called as Little Snitch https://www.obdev.at/products/littlesnitch/index.html
 ok
[19:26] <graph> So Is the chance that OpenSnitch will be on repository?
 In the repository, sure
[19:27] <graph> Ok thanks really its very uniqe app
[19:27] <graph> very good for no super skill terminal user:)
[19:28] <graph> just do what should do:) its like Comodo firewall for windows ..we can manage in GUI rules for each aps in linux or process
[19:29] <graph> In aplication layer but gufw works in deeper layer
[19:29] <graph> Ok I will be very thankfull for add it to repository of Lubuntu. And sory for my english.
[19:30] <graph> it will make life easier people who are just simple user like me
[19:31] <graph> I know that Arch has it in own repository