[00:00] <TJ-> DumbLDoor: looks like F12 is only BIOS... there's an F13 then they've released 2 UEFI replacements
[00:00] <TJ-> DumbLDoor: looking at https://www.gigabyte.com/Motherboard/GA-Z68MX-UD2H-B3-rev-10/support#support-dl-bios
[00:00] <TJ-> DumbLDoor: so if you're is BIOS-only you're fine
[00:00] <leftyfb> 2021 May 10 19:45:24 <leftyfb>	DumbLDoor: you mentioned non-UEFI. If your system is non-UEFI, then an EFI bug won't affect you
[00:01] <DumbLDoor> TJ, leftyfb: Hybrid EFI technology with DualBIOS for 3TB HDD support
[00:02] <DumbLDoor> this is what the Gigabyte website states
[00:02] <leftyfb> DumbLDoor: do you have EFI enabled?
[00:05] <DumbLDoor> leftyfb: there is no sign of it but I don't know in case it is and i have not been able to figure out the same
[00:06] <leftyfb> DumbLDoor: then you should not have an issue
[00:07] <leftyfb> DumbLDoor: Are you currently running Ubuntu 20.10?
[00:08] <DumbLDoor> leftyfb: Yes
[00:08] <leftyfb> DumbLDoor: How are you now trying to upgrade to 21.04?
[00:08] <DumbLDoor> leftyfb: update-manager -d I think
[00:10] <leftyfb> DumbLDoor: what do you mean "I think". Did you type:  "update-manager -d" ?
[00:11] <DumbLDoor> leftyfb: when i tried it last night, it gave me the option to upgrade to 21.04. It does not do so now
[00:11] <DumbLDoor> leftyfb: yes, i have the upgrade to 21.04 option again now
[00:12] <DumbLDoor> leftyfb: But I wonder if I should upgrade to UEFI first. The Gigabyte server has new firmware for it
[00:13] <leftyfb> DumbLDoor: look in your BIOS and see if you have UEFI enabled. If you do not, then you will be fine
[00:15] <DumbLDoor> leftyfb: Ok, ty
[00:15] <DumbLDoor> leftyfb: One more thing. Ubunu shows me ver. x.x for  the mboard. How do i know the exact version, any Idea?
[00:16] <leftyfb> DumbLDoor: I don't understand your question. Why not believe what it says?
[00:17] <DumbLDoor> Gigabyte site says it has two mb versions: 1.0 and 1.3, Ubuntu tells me x.x
[00:17] <leftyfb> DumbLDoor: look in your BIOS
[00:19] <DumbLDoor> leftyfb: Sorry, was trying to save a reboot cycle
[00:21] <leftyfb> DumbLDoor: if you're concerned about BIOS/firmware updates through your manufacturer, then you should be getting that information from the BIOS
[00:41] <DumbLDoor> leftyfb: ty.. it is rev 1.0.. cya in a few
[02:31] <Oddyseous> I'm having issues trying to get crypto mining software to work with my gpu on ubuntu 20.04 if anyone is able to help I'd appreciate it
[02:33] <Oddyseous> Getting this error: Phoenix Miner 5.6c Linux/gcc - Release build
[02:33] <Oddyseous> --------------------------------------------
[02:33] <Oddyseous> OpenCL driver version: 21.10-1247438-rocr
[02:33] <Oddyseous> No avaiable GPUs for mining. Please check your drivers and/or hardware.
[02:33] <Oddyseous> rick@DeathStar:~/Downloads/PhoenixMiner_5.6c_Linux$
[04:27] <ksynwa> Anyone knows if I can disable the shortcut for launching the favourites in the side panel of GNOME? For example, if I do Super+1, it launches Firefox because it's on the top of the favourites list.
[04:27] <ksynwa> Let me know if I am not clear.
[04:38] <leaftype> you want to type super+1, and have it do nothing, right?
[04:40] <leaftype> I'm not on gnome shell right now, but keyboard shortcuts should be in settings somewhere. Type the super key, and then type "settings"
[05:01] <ksynwa> leaftype: Thanks
[05:37] <Bodsda> Is there a way to disable the software updater from popping up on 21.04?
[05:38] <leaftype> Bodsda: you want no updates at all?
[05:40] <Bodsda> leaftype: I don't want to be notified about them.
[05:42] <leaftype> it shoudln't be any different in 21.04 than other recent versions - open up "software and updates"
[05:43] <leaftype> there is a tab for updates, you can configure which updates you want automaticall installed, how oftne to check, which releases to show, all that stuff
[05:44] <Bodsda> leaftype: there is no configuration within the application to disable all types of graphical popups. I can limit it, but not disable it for some reason
[05:45] <leaftype> "automatically check for updates" -> never
[05:46] <Bodsda> leaftype: and attempting to remove the update-notifier package would also remove ubuntu-desktop and ubuntu-desktop-minimal. I currently have those settings set to (from top down): All, Never, immediately, fortnight, never
[05:48] <leaftype> the third one, "immediately" - that probably will notify you
[05:48] <leaftype> but only when it checks for updates, so... depends on whether you care about that
[05:48] <leaftype> but i would imagine that would work
[05:50] <ledeni> Bodsda:settings -- applications -- Software -- notifications -- disable check for 'updates-notifier' maybe it is on list too in Applications
[05:51] <Bodsda> leaftype: the only other options are download automatically and download and install automatically. Neither of which is desirable. -- The notifications thing is a good one thanks, was not aware of those settings
[05:51] <leaftype> as long as you're never checking ofr updates, there is no way to tell you they exist
[05:52] <leaftype> I assume you plan to just do them manually now and then?
[05:52] <Kingsquee> Hey, I'm running 20.04, and since a few months ago when I try to run most applications in wine I get "0009:err:wgl:init_opengl Failed to load libGL: libGL.so.1: cannot open shared object file: No such file or directory"
[05:53] <Kingsquee> not sure if I messed something up or an update did
[05:53] <Kingsquee> help would be appreciated :I
[05:54] <Bodsda> leaftype: that's what I had hoped, but even with check for updates set to never I had the pop up this morning telling me of updates to firefox. Yeah, I manage the updates manually as and when.
[05:54] <Bodsda> Kingsquee: I had something similar - are you using nouveau driver?
[05:55] <Kingsquee> Bodsda: nvidia
[05:58] <Kingsquee> Bodsda: how did you solve it?
[05:58] <Kingsquee> my best guess currently is some i386 packages have broken or something
[05:58] <leaftype> Bodsda: was the firefox update through the package manager? I know firefox seems to like ot update itself too\
[05:59] <leaftype> it just asked me to restart the browser earlier
[05:59] <leaftype>  or maybe I'm wron gon that fornt
[06:02] <Bodsda> Kingsquee: try switching back to nouveau - I think the problem was introduced because of the switch from X11 to wayland - the other thing to try would be switching back to X11 from the configuration button on the GDM login screen
[06:02] <Kingsquee> I've never known switching back to nouveau from nvidia to work
[06:02] <Kingsquee> nvidia is basically a virus lmao
[06:02] <Kingsquee> as for X11, I never left
[06:02] <Kingsquee> so \shrug
[06:03] <tatertots> you can go back to nouveau
[06:03] <tatertots> it's not impossible
[06:03] <Kingsquee> I'd rather keep the perf and figure out the actual problem
[06:04] <Kingsquee> linux applications work fine and a few wine ones afaikt
[06:04] <Kingsquee> although I'm not sure if the latter few are doing software rendering or something
[06:07] <Bodsda> Kingsquee: To be honest, I saw this issue, switched back to nouveau because I also had problems with Teams and a few other display related niggles, then swithced back to nvidia and it seems to have fixed my issues
[06:07] <Kingsquee> :I
[06:08] <Kingsquee> well, knowing how to switch back to nouveau might be coo in any case
[06:08] <Kingsquee> tell me your secrets my dude
[06:08] <Bodsda> Kingsquee: software updates > additional drivers > select nouveau
[06:08] <Kingsquee> yeah but that usually doesn't work
[06:09] <Bodsda> Kingsquee: personally never had an issue with that method, it's probably nothing more than a package, 1 sec
[06:10] <ksynwa> I enabled mpd's user service for my user and for some reason two mpd instances start up at boot
[06:10] <ksynwa> Any idea how i can debug this?
[06:11] <Bodsda> Kingsquee: install this package: xserver-xorg-video-nouveau
[06:11] <Kingsquee> ahaha, I'm using kde neon, and the driver manager doesn't even show anything currently
[06:11] <Kingsquee> it's just stuck in "collecting information about your system"
[06:11] <Kingsquee> nice, nice
[06:11] <Bodsda> Kingsquee: run: ubuntu-drivers devices
[06:12] <Kingsquee> okay, it shows stuff
[06:12] <Bodsda> Kingsquee: pastebin?
[06:13] <Kingsquee> shows a bunch of nvidia driver options, and "driver   : xserver-xorg-video-nouveau - distro free builtin"
[06:13] <Kingsquee> so I guess "ubuntu-drivers install xserver-xorg-video-nouveau"?
[06:13] <Bodsda> Kingsquee: cool, so you have the driver, do: sudo apt-get install xserver-xorg-video-nouveau
[06:15] <Kingsquee> oh wait, I might have found a hint
[06:16] <Kingsquee> https://pastebin.com/raw/P42ZY8Lm
[06:17] <Bodsda> ksynwa: there is some good config info for mpd here: https://gmpc.fandom.com/wiki/MPD_INSTALL_USER_SERVICE_UBUNTU - I would remove the user config and just use the config files explained in the link, if it provides everything you need
[06:18] <Kingsquee> Bodsda: xserver-xorg-video-nouveau is already the newest version (1:1.0.16-1).
[06:18] <Kingsquee> is the output from "sudo apt-get install xserver-xorg-video-nouveau"
[06:19] <Bodsda> Kingsquee: you have held packages apparently - what does this show: dpkg -l | grep "^hi"
[06:19] <Kingsquee> what is a 'held' package :I
[06:20] <Kingsquee> command outputs nothing
[06:22] <Bodsda> Kingsquee: a package that apt won't upgrade. Usually you pin them when a newer version does something you don't like or breaks something - but that output suggests nothing actually is held. Try: sudo apt-get install --fix-broken
[06:22] <Kingsquee> 0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
[06:23] <ksynwa> Any idea why I am unable to disable mpd's user service? https://termbin.com/qglq
[06:24] <Kingsquee> I guess I could try uninstalling nvidia and reinstalling it...?
[06:24] <Kingsquee> spooky ram-based graphics lifeline
[06:24] <Bodsda> Kingsquee: that would be a good next step. Remove, then update, then fix broken, then install nvidia
[06:25] <Kingsquee> alright, I did some updates earlier, so I'm going to reboot just to be sure there's no weird pseudostate
[06:25] <Kingsquee> then I'll give that shot, brb
[06:26] <Bodsda> ksynwa: did you look at the link I sent? Try: /etc/init.d/mpd stop; sudo update-rc.d mpd disable
[06:26] <ksynwa> Bodsda: I must have missed your link.
[06:26] <ksynwa> Can you send it again please?
[06:26] <Bodsda> ksynwa: sure, https://gmpc.fandom.com/wiki/MPD_INSTALL_USER_SERVICE_UBUNTU
[06:27] <ksynwa> Thanks very much Bodsda
[06:29] <Kingsquee> >run nvidia-detector
[06:29] <Kingsquee> nvidia-driver-460
[06:29] <Kingsquee> >run nvidia-settings
[06:29] <Kingsquee> NVIDIA driver version: 450.119.03
[06:29] <Kingsquee> and yet it moves
[06:31] <Bodsda> Kingsquee: what moves?
[06:31] <Kingsquee> the OS :P
[06:32] <Kingsquee> https://askubuntu.com/questions/1231849/how-to-fix-update-problems-ubuntu-20-04
[06:32] <Kingsquee> might be relevant
[06:33] <Bodsda> Kingsquee: hmm, do you have more than 1 nvidia drivers installed? dpkg -l | grep -i nvidia-driver
[06:34] <Kingsquee> https://pastebin.com/raw/Baeg7huj
[06:37] <Bodsda> Kingsquee: I would remove both and install 460 -- sudo apt-get remove nvidia-driver-*; sudo apt-get install nvidia-driver-460 -y
[06:37] <Kingsquee> yeah, I ran purge on 450, and it removed 440 as well
[06:37] <Kingsquee> then I ran `sudo ubuntu-drivers install` and it seems to be doing the rest of the job
[06:38] <Kingsquee> removing clang-11 and stuff that showed up as an error before
[06:38] <Bodsda> Kingsquee: ok, hopefully we can get it to a state where dpkg and nvidia-settings agree on what drivers you are using
[06:38] <Kingsquee> ye
[06:38] <Kingsquee> I'm glad this is possible though, thanks for the tip re: terminal
[06:39] <Kingsquee> nvidia driver has some bugs re: laptop screen brightness so maybe I can make nouveau work for me sometime
[06:47] <Kingsquee> alright, installed
[06:47] <Kingsquee> gonna reboot and cross fingers
[06:47] <Bodsda> Ok
[07:04] <fiesh> we're using netplan on our router / server box, its configuration is https://paste.debian.net/1197100/  during maintenance schedules, it seems our ISPs router (<IP_ADDRESS>) does a power cycle, leading to a "enp4s0f3 NIC Link is down" / "enp4s0f3 NIC Link is up" cycle.  whenever this happens, the default route is dropped and not added back automatically.  I can't figure out why this is, what to do
[07:04] <fiesh> (installing ifplugd doesn't seem like the right approach here, I'd just like the route to remain, and I don't know how it interacts with netplan anyhow).  Any hints?
[07:06] <fiesh> (I stripped the configuration marginally but also included parts that I think are almost certainly irrelevant, like the other network devices)
[07:11] <Kingsquee> Bodsda: nomodeset saves lives
[07:11] <swensson> I managed to remove the CTRL C to interupt bash... How do I get it back? :D
[07:16] <Bodsda> Kingsquee: true :) - where are we at now?
[07:17] <Kingsquee> well,, when I boot normally, I get some really messed up color bitrate
[07:17] <Kingsquee> mostly back and red and yellow
[07:17] <Kingsquee> nomodeset works to access the os again
[07:18] <Bodsda> Kingsquee: ok, just on boot or on login and desktop as well?
[07:18] <Kingsquee> only after os boots
[07:18] <Kingsquee> grub is fine
[07:18] <Kingsquee> login and desktop are borked
[07:19] <Kingsquee> trying to run 'sudo apt-get purge nvidia*' but I'm now getting 'Unable to locate package nvidia-brightness.sh'
[07:19] <Kingsquee> which is... a script I was running back in the day to try and get screen brightness working on nvidia driver?
[07:19] <Kingsquee> what is happening XD
[07:20] <Bodsda> swensson: what is intr = ? in this: stty -a | grep -i intr
[07:20] <Kingsquee> death has an appointment for this laptop tonight in samarra
[07:20] <Bodsda> Kingsquee: what's the output of: dpkg -l | grep -i nvidia-driver
[07:21] <Kingsquee> ii  nvidia-driver-460                             460.73.01-0ubuntu<IP_ADDRESS>                                       amd64        NVIDIA driver metapackage
[07:21] <Kingsquee> nvidia-settings says NVIDIA driver version: 460.73.01
[07:21] <Kingsquee> so now they agree \o/
[07:21] <Kingsquee> and don't work
[07:22] <Kingsquee> lets try nouveau lmao
[07:23] <Bodsda> Kingsquee: before that: lsmod | grep nvidia
[07:24] <Kingsquee> https://pastebin.com/raw/nkfEU7cF
[07:24] <swensson> Bodsda: intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
[07:25] <Bodsda> swensson: in a terminal run: yes     can you quit this with ctrl+c?
[07:26] <Bodsda> Kingsquee: that shows the nvidia kernel module loaded, so it should be working. If it's not then maybe the 460 is not right for your card. Uninstall and return to 450
[07:26] <Kingsquee> Bodsda: also maybe of interest, some mesa stuff not getting upgraded it seems https://pastebin.com/raw/i0WRuVd3
[07:27] <Kingsquee> seems like I can remove them without issue
[07:27] <Bodsda> Kingsquee: if you didn't install them manually, then don't remove them - they were installed as a dependency for something, and if no longer required then autoremove can be used to remove them
[07:28] <Kingsquee> Bodsda: dist-upgrade claims they're broken
[07:29] <Kingsquee> autoremove doesn't remove them
[07:29] <Kingsquee> seems suspicious
[07:29] <Bodsda> Kingsquee: can I see the output of: sudo apt-get update; sudo apt-get upgrade -y
[07:30] <zamba> i have a VM running in the cloud (ovh) that feels very sluggish.. the load is at around 7-8.. i have 32 vCPUs, but only 5-6 of them actually firing, but they are running at 100 %.. i/o wait is peaking at only 3-4%
[07:30] <zamba> any ideas how to troubleshoot this?
[07:30] <Kingsquee> Bodsda: just checks the ppas and says 'done'
[07:31] <Bodsda> Kingsquee: no actions or errors on an upgrade command?
[07:31] <Bodsda> zamba: htop to find the process with highest CPU utilisation would be my first step
[07:32] <zamba> Bodsda: yeah, i see that this is the sshd.. i'm running quite a lot of sftp transfers
[07:32] <Kingsquee> Bodsda: https://pastebin.com/raw/qGHdQv9B
[07:32] <swensson> Bodsda: Not with CTRL C, but CTRL SHIFT C
[07:32] <zamba> Bodsda: but i don't see any i/o wait that could explain the spike in load
[07:33] <Bodsda> zamba: your maxing 6 vCPUs for file transfers? I assume your network utilisation is at maximum?
[07:33] <Bodsda> Kingsquee: check your first command, you've run update twice, not update then upgrade
[07:33] <Kingsquee> oops, sorry
[07:34] <zamba> Bodsda: everything just feels sluggish and slow.. for instance.. starting 'iftop' took 5 seconds
[07:34] <zamba> Bodsda: logging into the server took 10+ seconds
[07:34] <Bodsda> zamba: I wouldn't say that's unreasonable if all of your network utilisation is being spent on transfers and you are on an ssh session instead of a console
[07:36] <Kingsquee> Bodsda: https://pastebin.com/raw/EpT49rpm
[07:37] <Kingsquee> notable: On KDE neon you should use `pkcon update` to install updates. If you absolutely must use apt you do have to use dist-upgrade or full-upgrade in place of the upgrade command.
[07:37] <Kingsquee> :^)
[07:38] <Bodsda> Kingsquee: yeah I just saw that - disclaimer: I have no idea what kde neon have done to their package management
[07:38] <Kingsquee> doing pkcon-update just gives me a fatal error on mesa-va-drivers and mesa-vdpau-drivers
[07:38] <Bodsda> Kingsquee: can you show me that error output?
[07:39] <Kingsquee> https://pastebin.com/raw/zxyW8Qry
[07:39] <Kingsquee> llvm seems to be the demon in charge
[07:40] <Bodsda> Kingsquee: pkcon install libllvm11
[07:40] <Kingsquee> Command failed: This tool could not find any available package: No packages were found
[07:41] <Bodsda> Kingsquee: stupid thing -- sudo apt-get install libllvm11
[07:41] <Kingsquee> libllvm11 is already the newest version (1:11.1.0~++20210405103834+1fdec59bffc1-1~exp1~20210405084454.165).
[07:41] <Kingsquee> libllvm11 set to manually installed.
[07:42] <Kingsquee> remove it I guess?
[07:42] <Bodsda> 1 sec
[07:42] <Kingsquee> iirc I was doing something with ppa llvms while mucking about with compiling compilers
[07:42] <Kingsquee> but it was a long time ago
[07:44] <Bodsda> Kingsquee: ah ok - let's check your sources -- cat /etc/apt/sources.list; ls -lah /etc/apt/sources.list.d/
[07:45] <Kingsquee> mind if we move to pm?
[07:46] <Bodsda> Kingsquee: sure
[08:36] <nomad_fr> Hi
[08:36] <nomad_fr> Since last upgrade tu Ubuntu hirsute, I anymore wake from encrypted Hibernate my laptop. Everything works but during boot the encrypted partition is not find.
[08:36] <nomad_fr> The sawp passwd is asked after like in a normal boot.
[08:36] <nomad_fr> My crypt partition is name 'cryptswap' but 'swapon --summary' says that is name is '/dev/dm-0'
[08:42] <lnielsen> nomad_fr: dmsetup info /dev/dm-0
[08:43] <lnielsen> Also, use swapon --show
[08:54] <nomad_fr> ok I get back to encrypted version, I was checking that every thing was ok in uncrypted
[08:59] <nomad_fr> lnielsen: so 'swapon --show' says : /dev/dm-0
[09:00] <nomad_fr> lnielsen: and 'dmsetup ...' : cryptswap
[09:01] <nomad_fr> maybe I can use this UUID : CRYPT-LUKS2-ab1060125bfe4059b6fb51335f274172-cryptswap : for
[09:01] <nomad_fr>  /etc/initramfs-tools/conf.d/resume
[09:03] <nomad_fr> I seems to be something like that : my update-initramfs says : initramfs-tools configuration sets RESUME=CRYPT-LUKS2-ab1060125bfe4059b6fb51335f274172-cryptswap but no matching swap device is available.
[09:10] <nomad_fr> in fact I think that my trouble is just to putthe right thing in /etc/initramfs-tools/conf.d/resume
[09:22] <zamba> is 5.4.0-73 a hwe kernel for 18.04?
[09:25] <zamba> nevermind, it is :)
[09:30] <ksynwa> Any suggestions for GUI music players?
[09:30] <ksynwa> That can handle large library (only 40GB) with ease?
[09:42] <kiwi18> Hi, I just upgraded to ubuntu 20.04 and my USB disks don’t automount under /media/username/DISK_LABEL anymore. They did on 18.04, without editing fstab
[09:42] <kiwi18> how can I fix it?
[09:46] <jeremy31> kiwi18: there might be an option in the file manager to auto mount removable drives
[09:46] <kiwi18> jeremy31: I have no GUI, ssh access only
[10:16] <torbjorn> does anyone know how one can use super-space as a custom keyboard shortcut? I have set one, removed the others I could find, and removed it from switching input-sources in ibut-setup , but still hitting super-space does not trigger my intended command
[10:18] <torbjorn> or how can I find out what super+space does to my system
[10:52] <TJ-> Building a debian-arm64 chroot on amd64 (utilising qemu-aarch64-static) with {qemu-}debootstrap is resulting in a segfault (signal 11) for /sbin/ldconfig when installing bullseye but not buster. Any ideas?
[11:08] <lotuspsychje> TJ-: is bug #1670905 useful for you?
[12:07] <nokiomanz> Hello everyone! On ubuntu20.04 the latest mysql-server is 8.0.23. Is there a place where I can see when the version 8.0.24 is going to be release? I guess this can apply to any package. But I am looking to that minor update and was wondering is there was a place with potential date etc. Hope I make sense.
[12:22] <legreffier> nokiomanz: it's unlikely it gets released. only security updates should come through.
[12:23] <TJ-> lotuspsychje: thanks; no, unrelated
[12:23] <nokiomanz> legreffier, I see. Before 8.0.23 it was at 8.0.19. Did it get updated then because of security updates?
[12:25] <legreffier> nokiomanz: yup. if you want the latest stable mysql package, maybe use oracle' provided repo : https://dev.mysql.com/doc/mysql-apt-repo-quick-guide/en/
[12:25] <RJ45> I am high af rn, so I may be slow to respond.. but I have question..
[12:26] <nokiomanz> legreffier, That is what I saw as well. Makes a lot of sense. Thanks for your time !
[12:26] <brutamontes> how in hell do you install magento2 on ubunntu lamp?
[12:27] <RJ45> I am migrating to a new PC with NVME SSD, so I want to to a new fresh install of Ubuntu MATE, is there a way I have a script a script to run on the new install, that will auto-install everything I have on my old pc?
[12:27] <legreffier> RJ45: there's about 1000 persons (including minors) reading you here. maybe not the best place to brag about drug use ?
[12:27] <RJ45> minors in #ubuntu ?
[12:28] <RJ45> sounds like some really mature intellectual minors
[12:29] <RJ45> stay in school kids, conform to the doctrine of your country's leaders
[12:31] <legreffier> RJ45: you can list installed packages with dpkg -l , and on the newer machine 'for i in $( < list_of_package.txt ) ; do sudo apt install $i ; done'
[12:31] <legreffier> something like this.
[12:33] <RJ45> what if I have 3rd part ppas?
[12:33] <RJ45> 3rd party PPAs*
[12:35] <legreffier> RJ45: you need to add them on the newer machine as well
[12:35] <legreffier> i don't think there's an automated upgrade path when you'
[12:35] <legreffier> are using such customization
[12:40] <brutamontes> How to install Magento 2.4.2 on Ubuntu 21.04 with Lamp (latest) ?!
[13:20] <leftyfb> RJ45: look into ansible
[13:22] <BluesKaj> Hi folks
[13:42] <lnielsen> ksynwa: https://snapcraft.io/foobar2000
[13:42] <lnielsen> whoops that was an old question
[14:00] <abijoy87> hey good people I need a help. Once I dissabled my laptop's internal keyboard and touchpad; But I can't remember the IDs of those devices; What can I do reanable them ?
[14:01] <leftyfb> abijoy87: undo what you did to disable them
[14:03] <abijoy87> sad! I can't remember. I did disable them maybe a year ago; copy pasted something from stackoverflow
[14:04] <abijoy87> xinput list
[14:04] <abijoy87> ⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
[14:04] <abijoy87> ⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
[14:04] <abijoy87> ⎜   ↳ SIGMACHIP USB Keyboard Consumer Control 	id=10	[slave  pointer  (2)]
[14:04] <abijoy87> ⎜   ↳ AlpsPS/2 ALPS DualPoint TouchPad        	id=13	[slave  pointer  (2)]
[14:04] <abijoy87> ⎜   ↳ PixArt USB Optical Mouse                	id=17	[slave  pointer  (2)]
[14:04] <abijoy87> ⎜   ↳ AlpsPS/2 ALPS DualPoint Stick           	id=14	[slave  pointer  (2)]
[14:04] <abijoy87> ⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
[14:04] <abijoy87>     ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
[14:04] <abijoy87>     ↳ Power Button                            	id=6	[slave  keyboard (3)]
[14:04] <abijoy87>     ↳ Video Bus                               	id=7	[slave  keyboard (3)]
[14:04] <abijoy87>     ↳ Sleep Button                            	id=8	[slave  keyboard (3)]
[14:04] <abijoy87>     ↳ SIGMACHIP USB Keyboard                  	id=9	[slave  keyboard (3)]
[14:04] <abijoy87>     ↳ SIGMACHIP USB Keyboard System Control   	id=11	[slave  keyboard (3)]
[14:04] <abijoy87>     ↳ Integrated Camera: Integrated C         	id=12	[slave  keyboard (3)]
[14:04] <abijoy87>     ↳ ThinkPad Extra Buttons                  	id=15	[slave  keyboard (3)]
[14:06] <jess> that looks accidental
[14:06] <rapid16> Anyone know of a gui front-end for PuTTY-Gen?
[14:06] <jess> i've removed the k-line
[14:18] <rapid16> Sorry,,I parted by mistake. Does anyone know of a GUI front-end for PUTTY-gen? I really hate using shell for SSH stuff.
[14:18] <rapid16> I've tried searching, but haven't found anything
[14:24] <leftyfb> rapid16: seriously? you should learn more CLI SSH. It's WAY more powerful and you have way more control.
[14:27] <rapid16> It gets confusing quickly for me
[14:27] <rapid16> Learning disability makes it tougher for me to grasp more complex things
[14:28] <rapid16> However...most tutorials say '1096' in key generations, shouldn't that be 2048 for most secure?
[14:30] <ash_worksi> reading a guide on help.ubuntu.com for ufw; I don't understand the syntax `ufw allow from <target> to <destination> port <port number>`
[14:31] <ash_worksi> firstly, I would personally have used <source> instead of <target> since that is kind of a synonym for <destination>
[14:31] <ash_worksi> secondly, what _is_ "destination"?
[14:31] <ash_worksi> the only example is "any"
[14:32] <ash_worksi> and it makes it look like "to any port" until you read on to see that it's actually some specified port
[14:32] <zzzoid> I am running ubuntu 19.10 - I would like to update packages but it fails on Nvidia saying it can't overwrite the package. What can I do?
[14:32] <aaronr> ash_worksi: to <ip|any> [port <portnumber> [proto <tcp or udp>]]
[14:32] <aaronr> same for from
[14:33] <aaronr> square brackets indicate optional sections and should not be typed
[14:33] <ash_worksi> aaronr: so it must be IP or any? it can't be eg hostname?
[14:33] <aaronr> ash_worksi: oh, i think hostname works too, yeah
[14:34] <aaronr> but i'd probably recommend an IP
[14:34] <ash_worksi> aaronr: did oyu copy that exactly? they use both pipe and the word "or" ?
[14:34] <aaronr> ash_worksi: no just lazy inaccurate typing on my part haha
[14:34] <ash_worksi> oh okay :P
[14:35] <aaronr> there's an optional free text comment that you can add by ending the command with: comment "<your freetext comment here>"
[14:35] <aaronr> (wrap your comment in double quotes)
[14:35] <ash_worksi> I see
[14:35] <aaronr> eg `ufw allow from any to any port 80 proto tcp comment "Allow HTTP"`
[14:37] <leftyfb> !oel | zzzoid
[14:37] <leftyfb> !eol | zzzoid
[14:37] <leftyfb> zzzoid: Ubuntu 19.10 is no longer supported
[14:37] <zzzoid> O
[14:37] <zzzoid> Ok
[14:37] <zzzoid> I can't update though
[14:38] <zzzoid> Because I keep getting a message to try: apt --fix-broken install
[14:38] <leftyfb> zzzoid: https://help.ubuntu.com/community/EOLUpgrades
[14:38] <leftyfb> zzzoid: remove the package it's complaining about, upgrade then reinstall packages as needed
[14:38] <zzzoid> I can't remove
[14:39] <zzzoid> It just keeps saying do this --fix-broken install
[14:39] <zzzoid> I tried to purge Nvidia
[14:39] <leftyfb> zzzoid: please pastebin the command you're running and it's output
[14:39] <ash_worksi> aaronr: so that would be equivalent to `allow 80/tcp` right?
[14:42] <aaronr> yeah -- i'm not sure if you can combine the short notation with defining an IP address but you might be able to. if you're just doing "any" then the short notation is fine.
[14:43] <ash_worksi> aaronr: I wonder if i can shim words into short notation and vise versa
[14:43] <ash_worksi> ie `ufw allow **TO** 80/tcp`
[14:43] <zzzoid> leftyfb, https://pastebin.com/Ang8reNz
[14:44] <leftyfb> zzzoid: add libnvidia-compute-440 to the end of your command and try again
[14:44] <aaronr> ash_worksi: https://help.ubuntu.com/community/UFW would imply you can't mix and match long and short
[14:45] <ash_worksi> aaronr: I see
[14:45] <ash_worksi> it just would make some sense based on the status output; (since you can have just a port under TO)
[14:46] <zzzoid> leftyfb, I get the same error
[14:46] <leftyfb> zzzoid: please pastebin that as well
[14:47] <leftyfb> zzzoid: it shouldn't be exactly the same
[14:47] <ash_worksi> tbh, I would prefer if it was just `ip_addr/subnet:port/proto` syntax and just use `*` for any
[14:48] <ash_worksi> I wonder if i create a short-syntax rule if i can delete it with a long syntax rule
[14:49] <zzzoid> leftyfb, https://pastebin.com/cyrNQGbj
[14:50] <leftyfb> zzzoid: sudo apt-get remove --purge '^nvidia-.*' libnvidia-compute-440
[14:50] <zzzoid> Ah ok :)
[14:51] <zzzoid> leftyfb, then it just tells me to do the --fix-broken install command
[14:51] <leftyfb> zzzoid: show me the output please
[14:52] <leftyfb> zzzoid: sudo apt-get remove --purge '^nvidia-.*' libnvidia-compute-440 | nc termbin.com 9999
[14:53] <zzzoid> termbin.com/tsgul
[14:53]  * ogra thinks zzzoid shoud first remove the third party archive from the sources.list and run apt update ...
[14:53] <zzzoid> Ah nice tip
[14:53] <leftyfb> oh, that's a given, yeah
[14:54] <ogra> smells like nvidia simply packaged it in a broken way (without conflicts/replaces/breaks fields in the control file)
[14:55] <leftyfb> zzzoid: after removing the 3rd party repo's, run:   sudo apt update ; sudo apt-get remove --purge '^nvidia-.*' libnvidia-* cuda-drivers | nc termbin.com 9999
[14:55] <zzzoid> Orga, Nvidia is not in sources.list
[14:55] <leftyfb> zzzoid: looks for 3rd party repo's in /etc/apt/sources.list.d/
[15:02] <zzzoid> I removed all cuda and nvidia repos and then purged all the packages and now rebooted and upgrading
[15:27] <eskatrem> Hi, the usb plug on my laptop doesn't seem to be recognized by ubuntu, and when running dmesg I get "[drm:mipi_exec_pmic [i915]] *ERROR* Your hardware requires CONFIG_PMIC_OPREGION and it is not set". Are the two related and if so, how can I set CONFIG_PMIC_OPREGION (to what value)?
[16:13] <pangpang> can i invite someone to my youtube?
[16:13] <pangpang> https://www.youtube.com/watch?v=lBDDY5kk4EQ
[16:13] <leftyfb> !ot | pangpang
[16:13] <pangpang> just said 'it is really you pangpang?
[16:13] <pangpang> oh
[16:13] <pangpang> ok
[16:23] <elge> Meow.  Where to review all the things that are started by the graphical login manager (I believe it's gdm)?  I would like to switch to startx instead, but I need to load all the shit that makes Nautilus happy and shit
[16:26] <leftyfb> !language | elge
[16:26] <sarnold> elge: I think that's a combination of /etc/X11/Xsession.d/ plus /etc/xdg/autostart/
[16:28] <leftyfb> elge: why not use https://pastebin.ubuntu.com/p/fs7sQ6H4dq/ to default to booting to terminal and then just use : sudo systemctl start gdm  # to start X?
[16:41] <elge> leftyfb, it's not offensive, and we're not on massively censored social media here.  and of course I am willing to switch to multi-user here, that was my point already
[16:41] <elge> sarnold, thanks )
[16:42] <leftyfb> elge: my latter point was, just start the "gdm" service and it should do what you need
[16:42] <elge> *ubottu
[16:42] <elge> yeah that would work
[17:17] <floown> Hello. How to know if the patched version of Exim has been installed on an Ubuntu Server?
[17:18] <floown> apt-cache show exim4-base | grep "Version"
[17:18] <floown> Version: 4.93-13ubuntu1.5
[17:19] <ioria> floown, apt changelog exim4-base
[17:20] <physikoi> Hello #ubuntu. I'm trying to configure dnsmasq to play nicely with systemd-resolved. Unfortunately, i think i borked something. The files ive edited are these: /etc/systemd/resolved.conf, /etc/NetworkManager/NetworkManager.conf, and  /etc/dnsmasq.conf. The effect i'm trying to create is that all *.lan domains are resolved to loopback with dnsmasq. `dig <whatever>.lan +short` seems to indicate that goal
[17:20] <physikoi> is fulfilled (spits out <IP_ADDRESS>). However, now I can't resolve any other domain. What might have I done wrong? ty
[17:21] <physikoi> oh, and i'm on ubuntu server 20
[17:21] <floown> Thank you ioria
[17:21] <ioria> floown, no problem
[17:23] <physikoi> Oh, and one more file (making 4): /etc/NetworkManager/dnsmasq.d/lan-wildcard.conf (contains address=/.lan/<IP_ADDRESS>)
[17:29] <sarnold> floown: dpkg -l | grep exim4 ?
[18:11] <physikoi> Can anyone help me fix DNS on ubuntu server? Every suggestion i've found online doesn't work. I've tried stopping the dnsmasq service and restarting, but dns still does not work. EG pinging google yields "ping: google.com: Temporary failure in name resolution"
[18:18] <incognegro76> physikoi: what changes did you make to /etc/systemd/resolved.conf
[18:19] <physikoi> incognegro76: under [resolve] i added DNS=<IP_ADDRESS>
[18:19] <physikoi> FallbackDNS=<IP_ADDRESS>
[18:19] <physikoi> Domains=lan local test
[18:19] <physikoi> everthing else is commented out
[18:21] <physikoi> I've tried commenting that out and restarting services, but that didn't work either
[18:23] <incognegro76> Okay what happens when you try to ping the hostname of your system?
[18:23] <gschanuel> hello there! I have Ubuntu Server running on a VM but i'm having sume issues to boot. I booted the Ubuntu Server install media and I'm at boot menu
[18:23] <gschanuel> how can I get a basic shell to "mount -o remount,rw /" and fix things up?
[18:26] <physikoi> incognegro76: pinging hostname works
[18:26] <physikoi> sample output: 64 bytes from ubuntu-server (<IP_ADDRESS>): icmp_seq=7 ttl=64 time=0.052 ms
[18:30] <incognegro76> physikoi: have you tried running dnsmasq in debug mode?
[18:32] <physikoi> incognegro76: i could, but i don't think it's the cause of my woes. I shut it down, restarted, and confirmed that the service remained off
[18:33] <gschanuel> nevermind.. I got grub pressing ESC... i thought it was shift XD
[18:33] <physikoi> incognegro76: The goal was to get dnsmasq and systemd-resolv working simultaneously; however, I have no overriding motiviation to do it. Just something I read tbh.
[18:35] <incognegro76> physikoi: There are several moving parts to name resolution. It could be something simple like a character missing or command
[18:37] <incognegro76> If you want to use two separate methods of resolution for lan and wan you need to tell resolved.conf to prioritize one or the other first and you'll have to post the contents of those files for us to troubleshoot.
[18:37] <incognegro76> Anyway I gotta run, BBL
[18:38] <physikoi> incognegro76: ty for your time
[18:45] <oehman> hello! i'm running latest lts an uses mist theme from gnomelook.org
[18:46] <oehman> the problem is that in 21.04 the menu text works but in lts it's greyed out
[18:46] <oehman> is there a way to fix that?
[18:47] <oehman> hmm in lts 20.04 it's greyed out but works in 21.04
[18:52] <kryten> oehman: I guess ask the theme author if they are willing to make it work on the LTS too.
[18:57] <explodes> How long until kernel 5.11 is used by 20.04
[18:57] <oehman> anyone?
[18:57] <explodes> I guess my question is, really, how can I know the schedule for future kernel versions?
[18:58] <explodes> oehman: did you see "oehman: I guess ask the theme author if they are willing to make it work on the LTS too." ?
[18:59] <oehman> yes it works but the menyues are greyed out in 20.04 and works ok in 21.04
[18:59] <explodes> ask the theme author to backport the fixes
[18:59] <oehman> don't want to switch just because of that
[19:00] <oehman> hmm where can he be then?
[19:03] <oehman> brb just gonna get me a cup of coffe
[19:04] <kryten> explodes: I guess since unfortunately <https://wiki.ubuntu.com/Kernel/LTSEnablementStack> has no info at all about 20.04 so far, you could either a) try to extrapolate from past releases or b) ask on #ubuntu-kernel
[19:06] <kryten> oehman: Where you downloaded the theme from exactly, there is usually an option to at least post comments.
[19:06] <oehman> w8
[19:07] <oehman> https://www.gnome-look.org/p/1013000/
[19:08] <oehman> works with the latest ubuntu and newer gnom version i think
[19:14] <oehman> converted ubuntu into pure gnome look
[19:24] <kryten> oehman: The thing that's mildly curious here though, is that you seem to have no issues with the theme on a Gnome version of which there is no indication yet it supports, and vice versa on the version you got.
[19:25] <oehman> not an big issue but greyed out in the menytext
[19:25] <oehman> slightly visible
[19:41] <oehman> if i change to high contrast it works semi buticons looks ugly
[19:47] <oehman> brb
[19:47] <CarlFK> 21.04, how do I set autologin ?  I looked in Settings, Users and Power,don't see it
[20:35] <liebach> Have upgraded a server to 20.04 LTS, but I get "The following packages have unmet dependencies: apache2-bin : Depends: libaprutil1-ldap but it is not going to be installed"
[20:35] <liebach> Trying to install libaprutil1-ldap : Depends: libaprutil1 (= 1.6.1-4ubuntu2) but 1.6.1-5+ubuntu16.04.1+deb.sury.org+5 is to be installed
[20:36] <liebach> This is weird, upstream repo trouble?
[20:38] <sarnold> liebach: you can file bug reports for ondrej's stuff at https://github.com/oerdnj/deb.sury.org
[20:42] <leftyfb> liebach: to answer your question, yes, it's an issue with the 3rd party repo, not ubuntu
[20:42] <liebach> sarnold: Thanks, now I see it. Completely different thing, seems Ondrej's repo had been added in error to the server.
[20:47] <sarnold> liebach: oof. there's a ppa-purge package that may be able to help, if necessary
[20:49] <liebach> Just deleting the files should do it, right?
[20:49] <sarnold> that'll leave behind all the packages that came from the repo
[20:50] <liebach> Yeah, I see that, still get the error message.
[20:58] <liebach> deb http://ppa.launchpad.net/ondrej/apache2/ubuntu bionic main
[20:58] <liebach> That would be 'ppa-purge ppa:ondrej/apache2' - except it finds nothing.
[21:02] <EriC^^> liebach: is it still enabled?
[21:03] <liebach> Moved the list files out of the way.
[21:03] <EriC^^> it has to still be enabled for ppa-purge to work
[21:04] <liebach> dpkg -l | fgrep deb.sury.org  finds the packages too, right?  So just remove, install with only official ubuntu repos added.
[21:07] <EriC^^> liebach: sure, the only advantage of ppa-purge is if the repo had installed newer versions of some stuff, it would resort to the repo versions automatically
[21:07] <EriC^^> *if the ppaa
[21:07] <liebach> In this case it was old versions.
[21:08] <liebach> Have been doing this upgrade on the test server, the stage server, all went well. Then this on production...
[21:08] <liebach> I am very annoyed right now.
[21:08] <liebach> But I think I can make it work now.
[21:45] <liebach> It works, change verified.


[17:05] <marcone> hello
[17:13] <marcone> id have a inux question, is this the right place?
[17:28] <marcone> my question: i disabled my hdmi output to my tv on boot by a "video=HDMI-A-1:d" in the kernel command line. but i sometimes want to use it. is there a way of enabling it while the system is running?
[17:49] <marcone_de> ??
[21:13] <dsmythies> There is a relatively new kernel configurstion parameter, CONFIG_DEVMEM, which for some reason "is not set" for Ubuntu, and therefore demicode does not work. I found this: https://lists.ubuntu.com/archives/kernel-team/2015-May/057250.html and so had expected it to be set to yes by now, but in Kernel 4.1RC6 it still isn't. Does anybody know why?
[21:34] <apw> dsmythies, i thought we fixed that in the wily kernel, so it should be fixed for mainline builds, which is what i assume you are running
[21:34] <apw> dsmythies, could you file a bug against linux please asking about it and pointing all that info out, and assign it to "apw"
[21:35] <apw> dsmythies, and drop the LP# number here please as well
[21:35] <dsmythies> apw: O.K.
[21:54] <dsmythies> Note: for unknown reasons I always say demicode when I mean to say dmidecode.
[22:00] <dsmythies> apw (or anyone esle that is interested): bug 1462822


[08:15] <slyon> I'm glad you found the answer about initramfs-tools creating /run/netplan/intname.yaml on askubuntu.com!
[08:24] <slyon> PeGaSuS: I'm not sure if I fully get your question... but as kjetilho said, you should not be using two "gateway6"/default routes. In a situation like this you should rather manually define your routes and assign corresponding metrics/priorities accordingly, instead of having conflicting gateway6 definitions
[08:26] <PeGaSuS> slyon: well, honestly I've never had to do anything related to networking. so I just followed the instructions from tunnelbroker. I suppose that the tunnel gateway6 is also needed? the rest on en0 was already there, for the exception of the tunnel IPS that I've added
[08:27] <PeGaSuS> also all the routes were there since day 1
[08:29] <slyon> Have then tunnel "gateway6" and eno0 "gateway6" been there from the start?
[08:30] <PeGaSuS> en0 gateway6 is there from the start. the tunnel gateway6 was added by me
[08:35] <PeGaSuS> default config since day one was: https://paste.ubuntu.com/p/vCNg8nkBN5/
[08:35] <PeGaSuS> I know it's probably a mess, but blame Kimsufi. it's how they deliver the vps
[08:36] <PeGaSuS> in this case it's even a dedicated box
[08:41] <kjetilho> well, if *all* your via values for the individual routes are the same as your gateway6 value, the extra routes are superfluous.
[08:42] <kjetilho> (I would do a grep to check, but paste.ubuntu.com requires me to login using an Ubuntu One account to download as text(!)
[08:45] <slyon> Okay, so you added all the tunnel config, incl gateway6. Which default gateway do you want to use? Do you want to route your traffic via the eno0 network or via the tunnel network? I guess you should remove/comment the gateway6, which you do NOT want to use
[08:46] <PeGaSuS> kjetilho: https://termbin.com/iipi
[08:47] <PeGaSuS> slyon: if I remove the gateway6 from the tunnel can I still use the /64 subnet from the tunnel?
[08:47] <kjetilho> PeGaSuS: is this tunnel a general tunnel or just for access to some internal networks?
[08:48] <PeGaSuS> general tunnel, for outgoing connections
[08:48] <kjetilho> general tunnel as in "usable to access the whole of Internet"
[08:48] <slyon> PeGaSuS: Yes, if you define a route to that /64 subnet, via your GW address
[08:49] <slyon> PeGaSuS: but as you seem to want to use the tunnel by default, I'd suggest keeping the gateway6 in the tunnel config, but removing it from the eno0 network
[08:49] <PeGaSuS> but if I define the GW for the tunnel subnet I stop having the 1 native IPv6?
[08:49] <kjetilho> what is your native IPv6?
[08:50] <slyon> why is that?
[08:51] <kjetilho> ahhh, now I get it.  so 2001:41d0:a:f5d3::/58 is the stuff which should *not* go via the he-tunnel
[08:51] <PeGaSuS> exactly. that's the IPv6 assigned natively to the machine
[08:52] <PeGaSuS> and I'd love to use the native IPv6 and also the IPv6 /64 subnet from the tunnel in simultaneous
[08:52] <kjetilho> the list of subnets make my head hurt.  what would break if you tried to route all OVH traffic using your native IPv6?  2001:41d0::/44 is the block in whois.
[08:53] <kjetilho> (the computer doesn't mind the long list, though.)
[08:53] <PeGaSuS> I have no idea. I don't know if Kimsufi would be very pleased with that though
[08:54] <kjetilho> oh!  the long list is there to avoid a route entry for 2001:41d0:a:f5ff:ff:ff:ff:ff itself
[08:55] <PeGaSuS> I've asked them for a native /64 subnet, but no answer until now (only 12h have passed)
[08:55] <kjetilho> I should have noticed the "countdown" earlier :)
[08:59] <PeGaSuS> I really don't understand why Kimsufi only gives one IPv6 address. probably because they rely on OVH network?
[08:59] <kjetilho> I don't understand why you have a /58 for your address.  that is highly unusual
[08:59] <PeGaSuS> Kimsufi stupidity? :x
[09:00] <kjetilho> what is Kimsufi?
[09:00] <PeGaSuS> they're like an OVH subsidiary probably. the dedi box is from them
[16:16] <PeGaSuS> so, I asked for a /64 IPv6 subnet from Kimsufi (which seems to have some kind of relationship with OVH) and they kindly refused and said that if I want a /64 I should buy a dedicated server from OVH which is only like 6x expensive.
[16:17] <kjetilho> so you have a single address inside a /58?
[16:17] <PeGaSuS> yep, that's it
[16:17] <kjetilho> that's really weird
[16:18] <kjetilho> of course, the /58 only has room for 64 /64-subnets, so they would need a bigger allocation to start with
[16:20] <PeGaSuS> so, I guess I'm stuck with tunnelbroker. so, about the gateway6 thing, I should only have one at a time. but with my very limited knowledge about networking if I remove the native gateway6, will the native IPv6 be usable? what if I remove the tunnel gateway6?


[00:19] <davecheney> waigani_: menn0 thumper https://github.com/juju/juju/pull/548
[00:19] <davecheney> here is an easy one to warm up with this morning
[00:35] <hazmat> anyone know instance distributor provider code?
[00:35] <hazmat> just curious how it knows service name
[01:28] <menn0> thumper: got a sec?
[01:28] <thumper> menn0: aye
[01:28] <menn0> thumper: hangout?
[01:28] <thumper> sure
[01:29] <menn0> thumper: calling you now
[01:29] <menn0> thumper: https://plus.google.com/hangouts/_/g4pl2c7bq3jqz2jy3rsjdtvakea?hl=en-GB
[01:29] <menn0> thumper: grrr
[01:30] <menn0> let's use the standup hangout
[01:30] <thumper> ok
[01:38] <davecheney> wow, my branch from a month ago merged mostly cleanly with master
[01:38] <davecheney> not bad
[01:46] <thumper> \o/
[02:14] <axw> can I please get a review on https://github.com/juju/juju/pull/552 to unblock CI?
[02:16] <axw> wallyworld_: ^^  very small one
[02:16] <wallyworld_> sure
[03:15] <davecheney> OOPS: 34 passed, 6 FAILED
[03:15] <davecheney> --- FAIL: Test (18.44s)
[03:15] <davecheney> FAIL
[03:15] <davecheney> exit status 1
[03:15] <davecheney> FAIL    github.com/juju/juju/state/apiserver/provisioner        18.541s
[03:15] <davecheney> sigh
[03:16] <davecheney> well, at least it's only 3 of the apiserver packages
[03:16] <davecheney> which is better than before
[03:16] <davecheney> but still a lot of tests to fix
[03:17] <thumper> waigani: I'm about to drop maia down at hockey
[03:17] <thumper> waigani: how about we hangout when I get back and talk about the testing ?
[03:17] <waigani> thumper: that would be great, thanks
[03:20] <davecheney> ... obtained params.ErrorResults = params.ErrorResults{Results:[]params.ErrorResult{params.ErrorResult{Error:<nil>}, params.ErrorResult{Error:<nil>}, params.ErrorResult{Error:<nil>}, params.ErrorResult{Error:&params.Error{"not found", "machine 42 not found"}}, params.ErrorResult{Error:&params.Error{"not found", "unit \"foo/0\" not found"}}, params.ErrorResult{Error:&params.Error{"not found", "service \"bar\" not found"}}}}
[03:20] <davecheney> ... expected params.ErrorResults = params.ErrorResults{Results:[]params.ErrorResult{params.ErrorResult{Error:<nil>}, params.ErrorResult{Error:<nil>}, params.ErrorResult{Error:<nil>}, params.ErrorResult{Error:&params.Error{"not found", "machine 42 not found"}}, params.ErrorResult{Error:&params.Error{"unauthorized access", "permission denied"}}, params.ErrorResult{Error:&params.Error{"unauthorized access", "permission denied"}}}}
[03:20] <davecheney> welcome to my day
[03:20] <davecheney> looking at long likes of quasi json and spotting the n differences
[03:46] <thumper> waigani: back
[03:46] <waigani> thumper: https://github.com/juju/juju/pull/553
[03:47] <thumper> waigani: looking now, tests work ok?
[03:48] <wwitzel3> waigani: I added the comments for the public methods on https://github.com/juju/juju/pull/511
[03:49] <waigani> thumper: all tests passed except state/envuser_test.go which I fixed and tested individually
[03:49] <waigani> thumper: I'll do one more make test to be sure
[03:50] <waigani> wwitzel3: great thanks :)
[03:52] <waigani> wwitzel3, davecheney is my review mentor so you'll have to poke him for an LGTM
[03:52] <wwitzel3> thanks :)
[03:54] <davecheney> two secs
[03:55] <thumper> waigani: you are missing the new files...
[03:55] <thumper> waigani: state/envuser.go + test are not there
[03:55] <thumper> wwitzel3: o/
[03:55] <waigani> thumper: fuk
[03:56] <wwitzel3> thumper: heya
[04:00] <waigani> thumper: state/envuser.go is already in master?
[04:00] <thumper> waigani: is it?
[04:00]  * thumper looks
[04:00] <waigani> thumper: is for me?
[04:01] <thumper> waigani: umm... no. don't think so
[04:01] <waigani> thumper: okay my local master is stuffed up
[04:02] <waigani> thumper: let me clean this up and try again
[04:02] <thumper> ok
[04:20] <menn0> thumper: that change you helped me with: https://github.com/juju/juju/pull/554/
[04:20] <menn0> thumper: do you have time to review?
[04:20] <thumper> sure
[04:21] <menn0> thumper: i've already made sure this solves the problem of downgrades in local/manual envs
[04:21] <menn0> so once this is in
[04:21] <menn0> the other change can be proposed straight away
[04:23] <waigani> thumper: cleaned up, I'll address your initial comments before pushing again.
[04:23] <waigani> thumper: user take does not have a Name() method?
[04:24] <thumper> yes it does
[04:24] <thumper> are your deps up to date?
[04:24] <waigani> thumper: I just ran the godeps tool
[04:24] <thumper> but your branch probably isn't up to date with trunk
[04:26] <thumper> menn0: only one real comment
[04:29] <menn0> thumper: I don't think what you've suggested is necessary
[04:29] <thumper> why?
[04:29] <menn0> the test intentionally has no tools in env storage
[04:29] <menn0> so if a download was attempted it would fail
[04:30] <menn0> this work was done test first, and it failed because of this
[04:31] <waigani> thumper: dad duty just started, I'll get it back up later tonight.
[04:31] <thumper> waigani: ack
[04:31] <menn0> thumper: does that make sense?
[04:31] <thumper> menn0: in which case, please add a comment :-) as it wasn't obvious to me
[04:31] <menn0> thumper: will do
[04:37] <menn0> thumper: added comment and rearranged the test a little to make things clearer
[04:37] <menn0> how's this? https://github.com/juju/juju/pull/554/files
[04:37] <thumper> menn0: cheers
[04:38] <davecheney> wwitzel3: you've got a LGTM on that change
[04:38] <davecheney> there is nothing to be gained from another round of reviews
[04:38] <davecheney> do what you think is reasonable then submit that sukka before we get locked down again
[04:40] <thumper> menn0: a slightly premature merge :)
[04:40] <menn0> thumper: sorry. I wasn't sure if you were going to say anything else
[04:40] <thumper> menn0: that's fine :)
[04:40] <menn0> thumper: is there a problem
[04:40] <menn0> ?
[04:40] <thumper> no
[04:40] <menn0> just saw your LGTM :)
[04:41] <wwitzel3> davecheney: thanks
[04:43] <menn0> potentially dumb question: what does this do? go test -p 2 ./...
[04:43] <menn0> and why does the build do it?
[04:44] <menn0> wallyworld_'s last merge got aborted because a test took too long and then the tests were run again as above and passed
[04:44] <wallyworld_> menn0: it runs the tests with reduced parallelism
[04:45] <wallyworld_> because our tests sucks
[04:45] <menn0> oh right
[04:45] <wallyworld_> and often fail spuriously
[04:45] <menn0> I didn't realise we were running tests in parallel at all!
[04:45] <wallyworld_> but -p 2 works more often than not but is slower
[04:45] <wallyworld_> menn0: that's what Go does out of the box
[04:45] <menn0> right
[04:45] <menn0> well I have learned something today
[04:45] <wallyworld_> \o/
[04:46] <menn0> time to put my feet up
[04:46] <menn0> :)
[04:46] <wallyworld_> enjoy
[05:01] <davecheney> menn0: you and andrew gerrand
[05:01] <davecheney> he didn't know -p $NUMCPU was the default either
[05:01] <menn0> davecheney: well I don't feel so bad then :)
[05:02] <davecheney> possibly he doesn't spend as long as you and I do waiting for tests to ru
[05:02]  * thumper goes to make dinner
[05:09] <wwitzel3> I'm off, be back in the morning o/
[06:26] <davecheney> wallyworld_: ping
[06:55] <wallyworld_> davecheney: hey
[06:57] <davecheney> wallyworld_: i have a question about the keymanager
[06:57] <davecheney> when we pass user: juju-system-key
[06:57] <davecheney> to the keymanager
[06:57] <davecheney> is that a tag ?
[06:57] <wallyworld_> hmmm
[06:57] <wallyworld_> i didn't add that bit, but let me look at the code
[06:57] <davecheney> i've had to put a horrible hack in to make juju accept that as a tag
[06:57] <davecheney> ok, ifyou didnd't writ it
[06:57] <davecheney> that is ok
[06:58] <davecheney> you have TODOs all over it
[06:58] <wallyworld_> i don't think i did - i wrote the key manager itself
[06:58] <wallyworld_> but
[06:58] <davecheney> i have exactly one test to fix
[06:58] <davecheney> then this bloody branch is done
[06:58] <wallyworld_> i think someone came along and added support for a system-key
[06:58] <davecheney> well, they cocked it up
[06:58] <wallyworld_> let me look briefly
[06:58] <wallyworld_> i could have been me, but i can't recall
[07:02] <wallyworld_> davecheney: looks like it was me. a key can be for a user eg fred, or is the juju system key
[07:02] <davecheney> right, so they aren't tags
[07:02] <wallyworld_> i guess that was done back before tags
[07:02] <davecheney> yeah
[07:03] <davecheney> which makes it a bit of a hack to use common.AuthFunc
[07:03] <davecheney> anyway
[07:03] <davecheney> i've done a gross hack
[07:03] <davecheney> it'll hold
[07:03] <wallyworld_> yuk, sorry
[07:03] <davecheney> meh
[07:03] <davecheney> we'll live
[07:03] <davecheney> it can't be fixed now because of BACKWARDS COMPATABILITY !!1!
[07:04] <wallyworld_> yep :-(
[07:07] <davecheney> wallyworld_: https://github.com/juju/juju/pull/556
[07:07] <davecheney> DONE
[07:07] <davecheney> it's only taken a month
[07:07] <davecheney> i'm off to the pub
[07:07] <wallyworld_> looking
[07:07] <wallyworld_> have a drink for me :-)
[07:09] <voidspace> perrito666: let me know when you arrive :-)
[08:14] <jam> wallyworld_: I'm pretty sure you'll be having a drink for yourself, too :)
[08:16] <TheMue> morning
[08:18] <wallyworld_> jam: yes i will :-)
[08:18] <jam> morning TheMue
[08:22] <TheMue> dimitern: ping
[08:22] <dimitern> TheMue, hey
[08:23] <TheMue> dimitern: I changed my approach a bit, but I still hesitate to use the Entity approach.
[08:23] <TheMue> dimitern: see https://github.com/TheMue/juju/compare/capability-detection-for-networker
[08:23] <dimitern> TheMue, looking
[08:24] <TheMue> dimitern: Entity is really generic, for all entities with a tag. But IsManual is a flag for machines.
[08:25] <TheMue> dimitern: I now read it only once when creating a local Machine instance, so it is cached and will never bee refreshed, because it won’t change.
[08:25] <jam> TheMue: AIUI Jobs is also specific to Machines, but the "thing" is Entity which is more generic
[08:25] <dimitern> TheMue, no, please let's not make 2 calls for every life request
[08:26] <TheMue> jam: Entity doesn’t know about jobs
[08:26] <dimitern> TheMue, yes jam's right - there's already a precedent with Jobs, adding another flag is not a big deal I think
[08:27] <jam> dimitern: themue seems to think I've got the wrong object, I could be wrong there.
[08:27] <jam> But I thought I remembered seeing other stuff that was machine specific on the generic class
[08:28] <TheMue> Aaargh, I see, we’re talking about AgentGetEntitiesResult
[08:29] <dimitern> yes! :)
[08:29] <TheMue> But I’m still not happy with overloading that struct more and more
[08:29] <dimitern> TheMue, that's what versioning is for, no?
[08:30] <TheMue> dimitern: I don’t talk about differences, I talk about common and specific fields, separation of concerns
[08:30] <dimitern> TheMue, the agents need this data to do their jobs (efficiently), and it's also an internal api
[08:30] <TheMue> dimitern: So I would be more happy to let the machine fetch a doc especially for a machine
[08:31] <TheMue> dimitern: still not clean and optimal for maintainability, you see how easy one can move into the wrong direction
[08:31] <dimitern> TheMue, I don't think this is us moving in the wrong direction
[08:32] <TheMue> dimitern: IMHO the Machiner would be responsible for Machine operations and the Machine in the should know what it has to know about machines
[08:32] <dimitern> TheMue, fwiw, we probably need to have 2 separate unit and machine agent facades, rather than pretending we can treat both and their entities the same
[08:34] <dimitern> TheMue, and if you look at AgentGetEntitiesResults, only Life is common between machines and units, ContainerType and Jobs only apply to machines
[08:35] <TheMue> dimitern: yeah, maybe. so to come to a quick solution I will do the AgentGetEntitiesResult change. and I’ll file an issue for refactoring with low priority
[08:37] <dimitern> TheMue, that sounds good to me!
[08:52] <voidspace> So "juju restore" bootstraps again (which it needs to)
[08:52] <voidspace>  but if it fails it leaves the instance created - but with no running agent.
[08:53] <voidspace> So "juju status" (etc) fail and you have to manually destroy the instance (or accidentally leave it running because you don't realise)...
[08:53] <voidspace> jam: your hacked-up-backup script (for local provider)
[08:53] <voidspace> jam: it uses $JUJU_ENV
[08:53] <voidspace> this isn't set when I'm running the script directly, so I have to set it myself I guess
[08:53] <voidspace> or would you expect it to be set?
[08:54] <jam> voidspace: I believe it is set if you run "juju restore" but I just use "JUJU_ENV=local ./juju-restore"
[08:54] <voidspace> jam: right, cool
[08:54] <jam> voidspace: if you just run "juju-backup" it fails too, right?
[08:54] <jam> My understanding is that the plugin infrastructure sets that variable
[08:54] <voidspace> jam: it fails for publiic-key
[08:54] <voidspace> jam: right
[08:54] <voidspace> jam: that's what I *thought*, but I as just checking my system wasn't screwed in new and exciting ways
[09:01] <jam>  voidspace: did you do any more hacking on it, or shall I see if I can get it through to completion?
[09:01] <voidspace> jam: I was trying (and failing) to get amazon working
[09:01] <voidspace> jam: I've now switched to the local script
[09:01] <voidspace> backup seems to work fine :-)
[09:04] <dimitern> jam, got a minute?
[09:04] <jam> voidspace: well local backup "works" in that it generates a tarball, but all the paths match exactly the local paths, which means they *don't* match the "official" paths.
[09:04] <dimitern> jam, I'd like to pass an idea by you
[09:04] <jam> well, what *I* would consider official, at least (/var/lib vs /home/$USER/.juju/etc)
[09:04] <voidspace> jam: right
[09:04] <voidspace> yep
[09:05] <jam> dimitern: G+ or just in IRC?
[09:05] <dimitern> jam, just IRC should be fine
[09:05] <jam> voidspace: I think the thing to do there would actually be to rewrite them, but I don't expect backup of Amazon to be able to restore into local
[09:05] <voidspace> sure!
[09:05] <voidspace> just local to local will be a good start
[09:06] <voidspace> local to amazon might be useful :-)
[09:06] <dimitern> jam, so after experimenting with the net package's Interfaces() and InterfaceAddrs() on precise, trusty and utopic daily image, I realized we can get all the information we need about the network interfaces *without* ever bothering to read /etc/network/interfaces or /interfaces.d/*.cfg
[09:06] <voidspace> create your system locally, then "restore" to your production systems
[09:06] <jam> dimitern: what is it that we wanted but don't have access to?
[09:07] <dimitern> jam, like what?
[09:07] <jam> "we can't get all the information we need" such as?
[09:07] <jam> looking here: http://golang.org/pkg/net/#Interface
[09:07] <jam> it looks like we don't have anything about bridging, etc.
[09:08] <dimitern> jam, we can discover all interfaces, bridges included, their flags (up, down, broadcast, loopback, multicast), and their index and names, also any addresses assigned
[09:09] <dimitern> jam, I'm proposing to just rewrite the interfaces config as needed for ifup/down to work at boot, and as the networker starts it will read all configs and check if there are any changes between what we have in state and what's configured on the machine, and rewrite the configs as needed
[09:10] <jam> dimitern: ok, I read what you said wrong. I read it as "we cannot get all the information", if we *can* that's great, though I have my doubts. I'm also wondering where "net" gets its information from, is it just the live state, or is it the state that will be started on restart
[09:11] <dimitern> jam, the net package gets the info using syscalls and some obscure netlink packets
[09:11] <jam> dimitern: k, so it would be the "live" state, vs the saved state
[09:11] <dimitern> jam, it is more or less equivalent to what we can see using the "ip" command (i.e. real-time)
[09:11] <jam> dimitern: right, it is a kernel sort of interface
[09:11] <jam> "ifup" and /etc/network/interfaces are a debian/ubuntu-ism
[09:11] <dimitern> jam, yes, and it works just as well in precise as in utopic
[09:11] <jam> IIRC, Fedora/Redhat use a different saved state
[09:12] <dimitern> jam, well, there is support only for linux to discover the interfaces like that, but I've yet to try centos and fedora
[09:13] <dimitern> jam, that's true, we'll have to render different stored config for other distros, but let's worry about this as we get there :)
[09:15] <dimitern> jam, another up-side of using the net package is we don't need to rely on /etc/network/interfaces being there to decide whether to start the networker or not (more so now, as we have the "safe mode" to disable it selectively)
[09:38] <jam> dimitern: sorry about the delay, emergency take-the-dog-out action.
[09:38] <jam> dimitern: so I like the idea a bit (no safe mode would be very nice)
[09:38] <jam> *but*
[09:38] <jam> I wonder if we really don't want to save our configuration, which means writing to /etc/network/*
[09:39] <dimitern> jam, no, no, I'm not saying that :)
[09:39] <jam> dimitern: perhaps we could only rewrite things when we've actually decided we need to change things
[09:39] <dimitern> jam, we do write the network config in /etc, but we don't read it - we use the net package to discover what nics are there
[09:40] <jam> dimitern: but we shouldn't write it unless we think there is a change from what's written there, should we?
[09:40] <jam> in which case, we have to read what is there to write anythnig
[09:40] <dimitern> jam, we need to write the config, otherwise without a working juju machine agent + networker, the networking won't be setup correctly after system boot
[09:41] <dimitern> jam, yes, we get all NICs, read what's there and render and write "managed" config for each nic that we need to setup, but only if it's pre-existing config on disk is different from what the networker would generate
[09:42] <dimitern> jam, am I making more sense? :)
[09:43] <jam> dimitern: so I can understand that we may not need to parse them, I'm not 100% sure that our method of comparison as byte-strings is quite what we want (what about comments in the files, etc).
[09:43] <dimitern> jam, ok, so let's backtrack just a bit
[09:44] <dimitern> jam, the user trusts (or we hope they do) juju to do the right thing with the machines juju manages, right? the same should be true wrt the networker taking control over the machine's networking config and managing it, without expecting the user to interfere?
[09:45] <jam> dimitern: the whole point of "Safe" is because we don't trust us on Manual or Local
[09:45] <dimitern> jam, we make this obvious by using the comment header "# Managed by Juju, please do not change." in each config file the networker generates
[09:46] <dimitern> jam, right, so for "safe mode", don't write changes to the config or run any ifup/down commands, effectively just sitting there and logging what we discovered
[09:50] <dimitern> jam, I'm hoping we can get rid of safe mode for manual machines once we have a way for the user to explicitly tell us how to setup networking on them, or we're able to discover it somehow, smartly
[10:45] <jam> dimitern: TheMue: voidspace: standup?
[10:45] <voidspace> jam: omw
[10:50] <voidspace> perrito666: ping
[10:52] <jam> voidspace: are you still there?
[11:34] <jam> marcoceppi: poke about charm tools: https://bugs.launchpad.net/charm-tools/+bug/1359170
[11:34] <mup> Bug #1359170: juju charm create fails in an unhelpful fashion with juju-1.21 in PATH <Juju Charm Tools:New> <https://launchpad.net/bugs/1359170>
[11:34] <jam> Also, when I look at: https://juju.ubuntu.com/docs/authors-charm-writing.html
[11:34] <jam> It has the lines:
[11:34] <jam> juju charm create vanilla
[11:34] <jam> but in my browser, those are wrapped onto 2 lines
[11:34] <jam> so it looks like 2 commands
[11:35] <jam> Ctrl Refresh fixed it for me.... very weird
[11:41] <perrito666> morning voidspace
[11:41] <voidspace> perrito666: morning
[11:41] <voidspace> perrito666: solved my horrendous backup / restore problems
[11:42] <voidspace> perrito666: well, more or less
[11:42] <perrito666> voidspace: heh, all backup and restore problems are horrendous
[11:42] <voidspace> perrito666: backup wasn't working *at all*
[11:43] <perrito666> voidspace: odd, since when?
[11:43] <voidspace> perrito666: but jam finally sussed it - the juju 1.18 juju-backup is in the path and the dev one isn't
[11:43] <voidspace> perrito666: only for me on trunk
[11:43] <voidspace> perrito666: so I have to run the backup script directly to try it
[11:46] <perrito666> sweet, is there a PR already?
[11:46] <voidspace> perrito666: not a PR yet
[11:47] <voidspace> perrito666: I'll show you what I have (complete now I think)
[11:47] <jam> perrito666: the issue is that the 1.18 "juju-backup" shell script didn't know about /usr/lib/juju/bin/mongodump which you fixed for 1.20, but 1.18 is the one in /usr/bin/juju
[11:47] <voidspace> perrito666: although I need to test it, hence the problem with backup not working
[11:47] <voidspace> perrito666: https://github.com/voidspace/juju/compare/backup-ssh
[11:48] <jam> and just running "juju backup" searches $PATH for "juju--backup" so even though juju itself is 1.21, "juju backup" was running the 1.18 version.
[11:48] <voidspace> jam: so backup and restore from trunk worked fine for me - which is a first
[11:48] <voidspace> now to try it with my code...
[11:48] <perrito666> ah very true, my usual test uses absolute path
[11:50] <jam> perrito666: you mean /home/user/path/to/juju/cmd/plugins/juju-backup/juju-backup ?
[11:52] <perrito666> jam: yup, since I use the automated test from qa I added my paths to make sure it alwas runs the same
[11:52] <jam> perrito666: and then presumably you just set JUJU_ENV to test the right environment?
[11:53] <jam> TheMue: didn't you land a patch to allow "@" syntax for "juju set" ?
[11:54] <perrito666> jam: the CI test requires it as a param actually (test_recovery.py)
[11:56] <jam> perrito666: I don't see a test_recovery.py in lp:juju-ci-tools
[11:56] <jam> test_assess_recovery.py ?
[11:57] <perrito666> jam: it was test_recovery.py until friday
[11:57]  * perrito666 pulls
[11:57] <jam> perrito666: perhaps it is a different source code, because test_assess_recovery.py imports "test_recovery" at the top.
[11:58] <perrito666> RM  test_recovery.py => assess_recovery.py
[11:58] <jam> perrito666: looks like test_assess_recovery.py didn't get fixe
[11:58] <jam> fixed
[11:59] <jam> perrito666: and it looks like CI does, indeed, run "juju-backup" and not "juju backup" which might be something we should think carefully about, since *users* are going to be doing the latter.
[11:59] <jam> but we are testing the former
[11:59] <perrito666> I must have local changes to ensure that, ah I see, those tests ship their own version of backup
[12:00]  * perrito666 wonders why
[12:00] <voidspace> interesting
[12:00] <voidspace> yeah, seems odd
[12:00] <perrito666> jam: good point Ill nag sinzui about it when he shows
[12:00] <voidspace> anyway, about to test my restore
[12:00] <voidspace> just killed the state server
[12:04] <voidspace> jam: looks like restore does fetch the tools from the correct storage location when used in conjunction with upload-tools (just btw)
[12:04] <jam> voidspace: good to hear. I expected as much, since we are using the control-bucket as defined in the .jenv
[12:05] <jam> I almost wonder if backup should be saving the .jenv as well.
[12:05] <jam> since you really need both (I believe)
[12:05] <voidspace> yep
[12:08] <voidspace> jam: so my restore failed
[12:08] <jam> voidspace: did stock juju core succeed?
[12:08] <voidspace> jam: it looks like it opened the apiState fine, but then the Client failed to get an address for "machine-1" (my mysql unit - so the call to client.PublicAddress("machine-1") failed
[12:08] <voidspace> jam: yes
[12:09] <voidspace> jam: heh, although to be fair I didnt try with a unit with trunk as I wanted a quick test
[12:09] <voidspace> but this seems like a plausible failure
[12:09] <voidspace> I'm going to make coffee and then dig in
[12:09] <voidspace> no public address found: unknown unit or machine "machine-1
[12:10] <jam> voidspace: the nice thing about backup and restore is that once you have the backup, you don't have to backup again, just try restore
[12:10] <voidspace> yep :-)
[12:10] <jam> voidspace: that sounds like a "tag" vs an "id" issue
[12:10] <jam> as in, it might be expecting "1" for "machine-1"
[12:10] <voidspace> ah right, just "1" maybe
[12:10] <voidspace> will try that
[12:10] <voidspace> even before coffee :-)
[12:12] <voidspace> although if restore fails you have to manually kill the ec2 instance
[12:13] <voidspace> as a failed restore leaves the instance it created running
[12:15] <TheMue> jam: sorry, just seen your question. have been to lunch.
[12:16] <voidspace> ok, restore underway again
[12:16] <voidspace> coffee time
[12:16] <TheMue> jam: have to see what it has been exactly, but yes, IMHO it has been the @ to lead from files
[12:18] <TheMue> jam: https://bugs.launchpad.net/juju-core/+bug/1216967
[12:18] <mup> Bug #1216967: Missing @ syntax for reading config setting from file content <compat> <docs> <hours> <improvement> <juju-core:Fix Committed by themue> <https://launchpad.net/bugs/1216967>
[12:18] <jam> TheMue: k, I thought it would show up in "juju help set" but I didn't see it there
[12:19] <TheMue> jam: interesting, afair it should
[12:21] <TheMue> jam: the set doc has a hint. three paragraphs, the second one. which version do you use?
[12:23] <jam> TheMue: http://paste.ubuntu.com/8097539/
[12:23] <jam> is all I see for "juju help set
[12:25] <TheMue> jam: see line 28 in juju/cmd/set.go, it’s more. but it’s not yet released
[12:25] <TheMue> jam: so if you don’t use your own build you won’t see it.
[12:26] <jam> TheMue: $ ~
[12:26] <jam> ~/dev/go/bin/juju set -h
[12:26] <jam> I'm using trunk
[12:26] <jam> ~/dev/go/bin/juju --version
[12:26] <jam> 1.21-alpha1-trusty-amd64
[12:26] <jam> TheMue: you have "setDoc" set to the correct thing
[12:26] <jam> but line 48
[12:27] <jam> has "Doc: "set one or more ..."
[12:27] <jam> not Doc: setDoc
[12:27] <jam> TheMue: care to submit a bug and a patch for it?
[12:27] <TheMue> jam: aaargh, I found setDoc before and expanded it. never seen that it isn’t used.
[12:27] <TheMue> jam: yep, will quickly do it.
[12:46] <voidspace> jam: perrito666: looks to me like restore worked fine!
[12:46] <perrito666> voidspace: sweet
[12:46] <voidspace> jam: perrito666: will double check the code and create PR
[12:47] <voidspace> and then *re-PR* the database shutoff
[12:47] <jam> voidspace: greate. why didn't it work the first time? (did you fix something?) was it just the "machine-1" vs "1" issue?
[12:47] <voidspace> jam: yep
[12:48] <voidspace> jam: switching to id instead of tag fixed it
[12:48] <jam> voidspace: I wish our code was more consistent here, but that is what API versioning could get us to :)
[12:48] <jam> voidspace: can you file a bug tagged "API" about the inconsistency?
[12:48] <jam> and tech-debt
[12:49] <voidspace> jam: yep, and I'm adding a note to the PublicAddress docstring that "target" is an id not a tag.
[12:51] <perrito666> aghh the convoluted settings of networkmanager/dnsmasq in 14.04 drive me crazy
[12:52] <jam> perrito666: it looks like we broke plugins in 1.21 as well, which would have been caught if we were doing "juju restore" instead of "juju-restore", not that we should have used that to actually catch the bug
[12:53] <perrito666> jam: thats huge, dont we have a test to make sure plugins actually works?
[12:53] <jam> perrito666: apparently not https://bugs.launchpad.net/juju-core/+bug/1359170
[12:53] <mup> Bug #1359170: juju charm create fails in an unhelpful fashion with juju-1.21 in PATH <Juju Charm Tools:New> <juju-core:Triaged> <https://launchpad.net/bugs/1359170>
[12:53] <jam> I tried to run the charm-tools plugin
[12:54] <jam> and apparently we stopped passing arguments to plugins in 1.21
[12:54] <jam> I'm testing 1.20 now
[12:54] <jam> it seems broken there, too
[12:54] <jam> bugger
[12:54] <jam> curtis won't be happy
[12:56] <jam> wallyworld_: can I point you to bug #1359170 when you're around?
[12:56] <mup> Bug #1359170: arguments no longer passed to plugins <Juju Charm Tools:Invalid> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1359170>
[12:56] <jam> I'll try to pick it up since I discovered it
[12:58] <jam> CI isn't failing, so I'm not sure if it should be "CI regression" and block trunk, but it is a *serious* f-up on our part.
[12:59] <jam> I can't quite see why it is failing yet, though.
[13:02] <jam> sinzui: you'll certainly be happy to hear that I just opened a critical bug against 1.20...
[13:02] <sinzui> :)
[13:03] <jam> sinzui: bug #1359170
[13:03] <mup> Bug #1359170: arguments no longer passed to plugins <regression> <Juju Charm Tools:Invalid> <juju-core:Triaged by jameinel> <juju-core 1.20:Triaged by jameinel> <https://launchpad.net/bugs/1359170>
[13:04] <sinzui> jam, That is nicer that something breaking the entire packaging and publication step. I think you know what is wrong in you bug. at this moment CI is dead and I don't know why
[13:04] <TheMue> Hmm, it’s more intelligent to push branches when planing to create a PR.
[13:07] <sinzui> abentley, mgz: Looks like by stress from yesterday was just waiting for me to return to the job this morning. My top priority is to backport some ubuntu packaging rules into our source package branch. We want 1.20.5 accepted into utopic by feature freeze this Friday
[13:08] <abentley> sinzui: Hoo boy.  Have fun.
[13:09] <sinzui> Looks like one of the packaging changes broke CI. I will revert, but I think we need to rerun 1.20 each time I want to verify my changes to the source package branch
[13:09] <TheMue> jam: https://github.com/juju/juju/pull/559, extreme trivial :D
[13:10] <abentley> sinzui: Is "/home/ubuntu/juju-build/*.deb" right?  Should it be in the jenkins home dir?
[13:10] <jam> TheMue: I'd like to have a Launchpad bug to reference for this fix, also, you can add a test case in test_main.go which asserts the output of "juju set -h" matches setDoc.
[13:11] <jam> TheMue: otherwise LGTM
[13:11] <sinzui> abentley, no, because the script was written to work on a remote instance.
[13:12] <TheMue> jam: OK, the bug already exists, will put it in the description. And will add a test. Do we test the doc output in other commands too? Otherwise we should add tests there too.
[13:12] <sinzui> abentley, I added a hack to the script to run on local host to use the jenkin's workspace...but we haven't dismantled publish-revision to build on separate machines.
[13:12] <jam> TheMue: I've written tests in "main_test.go" before in order to assert that things were actually registered
[13:13] <jam> TheMue: for example "juju sync-tools --help" is in there.
[13:13] <jam> TheMue: *I* did it, because it was the most obvious place to check the lines in main.go where we have "r.Register(&Command)"
[13:14] <jam> TheMue: (test that the command exists because we get proper help text for it, rather than trying to say run the command and have unwanted side effects)
[13:15] <TheMue> jam: fine, so should look if this is done for all commands (but in an extra change)
[13:16] <jam> ah ffs, things work *if* you pass an environment name in "-e"....
[13:18] <sinzui> jam: I would like your advise. backup restore doesn't work unless mongodb-clients is not installed on the client machine. I think this is a " Depends" relationship in packaging. It was suggested to me that I use "recommends" because it is not needed by everyone.
[13:20] <jam> sinzui: if having something installed/not installed on the *client* changes whether backup + restore works then we just have a bug.
[13:20] <jam> we should not depend on local stuff in order for us to run stuff on the server.
[13:21] <jam> sinzui: it sounds like we are doing some sort of "does X exist" check on the client, when it needs to be run on the server.
[13:21] <perrito666> sinzui: mongodb-clients isrequired on the server not the client
[13:22] <sinzui> perrito666, oh!
[13:22] <perrito666> sinzui: and it is only required for restore
[13:22] <perrito666> and restore installs it if its not there
[13:23] <sinzui> perrito666, fab. Thank you very much perrito666 , so I am going to mark the bug as fixed in 1.20.x by you
[13:27] <perrito666> sinzui: indeed, the bug you just marked as fixed has the wrong diagnose, but it has been fixed in 1.20
[13:28] <sinzui> perrito666, Yeah. I elected to show it fixed in the latest to encourage people to seek it out
[13:28] <perrito666> sinzui: jam talked about it earlier, its because backup in 1.18 does not do a proper lookup for the tools which are in a juju folder
[13:34] <jam> dimitern: you're OCR today, so https://github.com/juju/juju/pull/560 if you want to give it a look. It needs a test that we operate properly under the circumstances I described in the bug.
[13:35] <jam> dimitern: I'd also like to run it past thumper, since I'm pretty sure he wrote the environmentCommandWrapper stuff.
[13:35]  * sinzui restarts CI from the publish-revision step for master
[13:40] <dimitern> jam, sure, will have a look in a bit
[13:48] <jam> perrito666: so it turns out we wouldn't have discovered my bug by running "juju restore", because it only breaks Args when you don't have an Environment, and "juju-restore" must have an environment set anyway.
[13:48] <perrito666> jam: you do make an interesting case for a test anyway
[13:48] <jam> perrito666: so we might have a test, but it either has a default environment, or what it is testing requires one.
[13:49] <jam> perrito666: I may be unique in how I do my environment management, and if I'm unique enough, maybe we should just deprecate it and not actually support it
[13:49] <jam> either that, or we need to be doing more testing that my way is actually supported.
[13:49] <jam> bash autocompletion also was (is?) buggy for me because it assumed you'd have an environment set
[13:49] <perrito666> jam: well, if we support it, we need to test it
[14:02] <alexisb> natefinch, wwitzel3: TOSCA call?
[14:02] <natefinch> alexisb: coming
[14:02] <wwitzel3> alexisb: I thought I was already in it ..
[14:02] <wwitzel3> alexisb: restarting the hangout :)
[14:05] <dimitern> jam, reviewed; just one comment - sorry it took so long :/
[14:30] <ericsnow> dimitern: you have a minute to take a look at a PR? https://github.com/juju/juju/pull/530
[15:01] <alexisb> TheMue, on my way, but will be a few minutes late
[15:01] <TheMue> alexisb: ok
[15:06] <ericsnow> perrito666, natefinch, wwitzel3: standup?
[15:07] <perrito666> ericsnow: going, just fighting with my hangut
[15:39] <natefinch> email I just got: "This is to notify you that the sum of 800,000 Britain Currency has been Donated to you by Colin Chris Weir Donation Scheme. for claims provide the below details"
[16:09] <gsamfira> ahh, they toned it down a bit.   I was hoping to work on it this week, but I'm less certain now, after talking to rick_h__ about it.
[16:25] <natefinch> sinzui: did you make progress on getting godeps in the tarball?  No big deal if it's not in yet, just checking.
[16:25] <fwereade> natefinch, dammit, I wanted to talk to you today, but the babysitter's just arrived and I'm trying to finish an email
[16:25] <fwereade> natefinch, what time is it for you now?
[16:25] <natefinch> fwereade: 12:30
[16:26] <fwereade> natefinch, cool, I hope I can get back to you in the next 5.5h
[16:26] <natefinch> fwereade: cool, ping me when you have time.  I appreciate you making time for it in your evening.
[16:28] <sinzui> natefinch, I failed. I cannot make it run run in unittests. But this morning I realised I want to run that as a precheck before the tarball is created. I hope to have that sorted out this week. Sorry, it wasn't an easy change, and I need to focus on putting 1.20.5 into utopicbefore Friday
[16:31] <alexisb> jam, you doing the cloudsigma call today
[16:39] <natefinch> sinzui: no problem.  It's not pressing.  It's a nice to have.  What I can do is make the test skip itself for now if godeps doesn't exist, that way it can still help developers (who should have godeps).
[16:46] <sinzui> natefinch, thank you that works for me because godeps does exist when we make the tarball.
[16:49] <rogpeppe1> natefinch: did you consider making that godeps test part of CI rather than an actual test in the suite?
[16:49] <natefinch> rogpeppe1: it's at least as important for developers as CI..... since innumerable times I've seen people ask why something was failing, only to figure out later that their dependencies were out of date
[16:50] <natefinch> (which has happened to me, as well)
[16:51] <natefinch> sinzui: I would like to make it mandatory at some point.  If you're developing on juju, you *need* godeps... I don't want someone to start hacking on juju and wonder why it's broken, just because they haven't run godeps.
[16:52] <sinzui> ericsnow, I am indeed very busy today I will reply before I EOD. Hp is my preferred could this week, and the the juju-core-slave machine might be ideal for setting up review board there. I need to think about your questions in more details though
[16:52] <ericsnow> sinzui: no worries :)
[16:54] <rogpeppe1> natefinch: ok. BTW, in your test, why not just use diff?
[16:57] <natefinch> rogpeppe1: what diff?
[16:57] <rogpeppe1> natefinch: diff(1)
[16:57] <natefinch> rogpeppe1: windows?
[16:58] <rogpeppe1> natefinch: no diff on windows?
[16:58] <natefinch> rogpeppe1: lol, no :)
[16:58] <gsamfira> git diff works :P
[16:58] <gsamfira> or were you referring to the manual? :P
[16:59] <gsamfira> in which case...no :D
[16:59] <rogpeppe1> gsamfira: i was referring to a command-line diff tool. i guess git has access to one, but perhaps it's not available for general use
[17:00] <gsamfira> it is available
[17:00] <rogpeppe1> natefinch: ^
[17:01] <gsamfira> if you have Git installed its in C:\Program Files (x86)\Git\bin\diff.exe
[17:01] <gsamfira> along with less, grep, etc
[17:01] <gsamfira> a small slice of home when having to work on windows
[17:01] <rogpeppe1> gsamfira: hmm, but i guess that won't be in the path, so you'd need some custom logic to work out how to find it (perhaps it's not in C:)
[17:02] <gsamfira> setx PATH "%PATH%;C:\Program Files (x86)\Git\bin"
[17:02] <gsamfira> and there ya go
[17:02] <natefinch> the last thing I want is yet another external dependency
[17:02] <gsamfira> if you set up your own system
[17:02] <gsamfira> you know where it is :)
[17:02] <rogpeppe1> natefinch: out of interest, what proportion of our tests pass under windows?
[17:02] <gsamfira> well, yes...an external dependency sucks :)
[17:03] <rogpeppe1> natefinch: you're probably right. but you could reduce your "monstrosity" by factoring out a "diff" function (diff(s, t string) []string, or something
[17:03] <natefinch> rogpeppe1:  a bunch, and that's next on our list of things to do - get tests passing on windows (except those we deem we can skip on windows because we just can't support them, like containers)
[17:03] <natefinch> rogpeppe1: yep
[17:05] <gsamfira> most tests on Windows fail because of the same reasons: unsanitized paths, short paths vs long paths, directory names containing illegal characters on windows (like ":")
[17:07] <gsamfira> there will be a few pull requests this week to fix some of them
[17:07] <gsamfira> the new github.com/juju/juju/wrench package also breaks tests on windows
[17:19] <natefinch> wwitzel3: want to do our 1:1?
[17:19] <wwitzel3> natefinch: yep
[18:07] <natefinch> heh, I had to fix dependencies.tsv on my PR that tests dependencies.tsv, because it was wrong.
[18:09] <wwitzel3> :)
[18:58] <sinzui> natefinch, can you find an engineer to look into bug 1359333
[18:58] <mup> Bug #1359333: win client thinks the cloud-init log is on the c drive <ci> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1359333>
[18:59] <natefinch> sinzui: crud. Yep.
[20:06] <natefinch> fwereade: forgot about the all team meeting tonight, I'm going to have to run to get some stuff done before then. Hopefully we can talk in the morning.
[21:51] <thumper> (╯°□°)╯︵ ┻━┻
[21:51] <wwitzel3> yep
[21:59] <thumper> menn0: still need that review?
[21:59] <thumper> can do it while all tests running
[21:59] <menn0> thumper, yes pleased
[21:59] <menn0> please even
[21:59] <menn0> (urgh... I have had just over 2 hours sleep - sick kids suck)
[22:02] <thumper> menn0: trade you https://github.com/juju/juju/pull/563
[22:02] <menn0> thumper, done
[22:03] <thumper> menn0: that was quick, did you read it ?
[22:03]  * thumper pokes
[22:03] <menn0> thumper, no I meant "yes, that trade sounds fair"
[22:03] <thumper> oh
[22:03] <thumper> heh
[22:03] <menn0> tiiiiiired
[22:04] <ericsnow> menn0: when you get a chance could you take a look at https://github.com/juju/juju/pull/530
[22:04] <menn0> the fun thing about me reviewing your change is that you then have to review my review :)
[22:04] <thumper> heh
[22:04] <alexisb> menn0, heh
[22:04] <thumper> hmm
[22:05] <menn0> thumper, maybe we ask dave or someone else to do that for this situation
[22:05] <menn0> ericsnow, will do
[22:06] <ericsnow> menn0: thanks!
[22:06] <menn0> let me get this review done and another small PR up first
[22:08] <menn0> thumper, regarding your PR... is it safe to assume that people won't/can't upgrade directly from pre 1.18 to post 1.20?
[22:08] <menn0> thumper, they have to go through an intermediate 1.18 release first?
[22:08] <thumper> menn0: yes
[22:08] <menn0> actually 1.18 and 1.20
[22:09] <thumper> that has always been the approach
[22:09] <thumper> the idea with the upgrade steps is that now it is *possible* to jump
[22:09] <thumper> but we don't support it yet
[22:09] <menn0> thumper, is that enforced?
[22:12] <menn0> thumper, found the bit that enforces it: validate() in upgradejuju.go
[22:12] <thumper> not explicitly I think
[22:12] <menn0> shame that it's enforced on the client side
[22:12] <thumper> oh, good :)
[22:13] <menn0> thumper, with the new release number scheme it's not quite right either...
[22:15] <menn0> thumper, the logic tries to find the next stable version by bumping minor by 1 if the current version is a dev release and by 2 otherwise
[22:15] <menn0> thumper, that's no longer right is it?
[22:15] <thumper> no
[22:15] <thumper> please file a bug
[22:16] <menn0> thumper, already doing it :)
[22:17] <menn0> thumper, when does the new scheme start? 1.20? i.e. will the next stable release be 1.21?
[22:17] <thumper> menn0: yes
[22:17] <thumper> 1.21 will be a stable release
[22:18] <waigani> thumper:  talking of reviews: https://github.com/juju/juju/pull/553
[22:18]  * thumper nods
[22:24] <menn0> thumper, please check the milestones and priorities for bug 1359435
[22:24] <mup> Bug #1359435: Next version selection for upgrades is no longer correct <juju-core:New> <juju-core 1.20:New> <https://launchpad.net/bugs/1359435>
[22:28] <menn0> thumper, review done.
[22:28]  * thumper does a bootstrap
[22:29] <menn0> thumper, so the stateservinginfo doc was only being created via the functionality for dealing with legacy envs? nice.
[22:29] <thumper> yeah
[22:29] <thumper> found that by failing tests when I removed it
[22:30] <thumper> local bootstraps fine
[22:31] <menn0> thumper, cool
[22:39] <menn0> thumper, I've replied to your review comments
[22:39]  * thumper nods
[22:43] <thumper> menn0: that comment makes no sense..
[22:43] <thumper> This is capturing the upgradedToVersion field from the agent's config as the agent starts up - i.e. the version we've just upgraded from
[22:43] <thumper> I read that as:
[22:43] <thumper> 'upgradedToVersion' is the version we have just upgraded from
[22:43] <thumper> which seems arse backwards
[22:43] <menn0> it is
[22:44] <menn0> upgradeToVersion is the version for which upgrades have successfully run
[22:44] <menn0> it gets updated to version.Current once upgrade steps have successfully run
[22:45] <menn0> but when a machine agent starts up, before the upgrade steps have run
[22:45] <menn0> it'll be set to the previous agent version
[22:45] <thumper> ok, that kinda makes sense
[22:45] <menn0> I didn't name this stuff
[22:45] <menn0> it's before my time
[22:47] <menn0> thumper, I'm so used to this part of the code now that it doesn't even seem strange to me anymore
[22:47] <menn0> but I do remember finding it confusing initially
[22:47]  * thumper nods
[22:59] <thumper> wallyworld: I took a very quick look at bug 1359333 (blocking landing)
[22:59] <mup> Bug #1359333: win client thinks the cloud-init log is on the c drive <ci> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1359333>
[22:59] <thumper> but I can't see how the diffs cause the failure
[22:59] <wallyworld> thumper: ok, i'm about to go into a meeting, but can look after that
[23:00]  * thumper has standup now too
[23:24] <davecheney> wallyworld: https://github.com/juju/juju/commit/3a8f263f8c2977241fc39450e9fb47b4d56fc975
[23:24] <davecheney> this was the commit that broke CI
[23:25] <davecheney> please revert it
[23:25] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1359333
[23:25] <mup> Bug #1359333: win client thinks the cloud-init log is on the c drive <ci> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1359333>
[23:31] <wallyworld> davecheney: hi, just finished a call, looking now
[23:32] <davecheney> wallyworld: the bug is it uses paths.DataDir which uses version.Current
[23:32] <davecheney> and version.Current, when you're using windows tools, will using windows tools
[23:32] <davecheney> this is reason number 9001 why version.Current is lethal
[23:32] <wallyworld> davecheney: do these guys doing windows develppment event test their stuff on windows before landing?
[23:33] <davecheney> wallyworld: that's between them and the person that reviewed their code
[23:34] <wallyworld> well i can understand how stuff gets through a review, but not to test on the platform you are developing for....
[23:38] <thumper> holy cow: 44 changed files with 1,954 additions and 360 deletions.
[23:38] <thumper> wallyworld: I don't think they are really testing it manually
[23:38] <thumper> that should really be raised as a concern
[23:38] <wallyworld> YES
[23:38] <thumper> alexisb: ^^
[23:39] <wallyworld> thumper: we'll discuss tonight at team leads' meeting
[23:39] <thumper> ack
[23:40] <wallyworld> thumper: davecheney: so are we 100% sure that https://github.com/juju/juju/pull/189 is the bad one? i'll just hit the Revert button if so
[23:40] <davecheney> wallyworld: not 100% sure
[23:40] <davecheney> what's the worse that can happen ?
[23:40] <thumper> wallyworld: can't say 100%, but indications are high
[23:40] <davecheney> we just re apply iy
[23:41] <wallyworld> ok
[23:42] <davecheney> man version.Current is a timb bomb
[23:42] <alexisb> thumper, wallyworld, davecheney: sorry I have to run, but I added a note about the windows workload reviews to the leads agenda so we wont forget
[23:42] <wallyworld> +1, and not just reviews, actual proper testing and due dilligence prior to landing
[23:46] <wallyworld> davecheney: thumper: reverted, let's now wait to see if CI is happy again
[23:47] <thumper> davecheney: did you mark it as fixes the bug so ci is unblocked?
[23:47] <thumper> sorry davecheney
[23:47] <thumper> wallyworld: ??^^
[23:47] <davecheney> thumper: thats ok thumper
[23:47] <davecheney> wallyworld: how long do we have to wait ?
[23:48] <wallyworld> thumper: i didn't because the revert didn;t go through ci
[23:48] <wallyworld> but i can mark the bug as resolved
[23:48] <wallyworld> pending CI running it's tests
[23:48] <wallyworld> we can reopen if needed
[23:48]  * thumper wonders if it should have...
[23:49] <davecheney> \o/, one down, one to go
[23:50] <wallyworld> thumper: maybe it should have, but i'll pull trunk now and run the tests
[23:54] <wallyworld> WTF
[23:54] <wallyworld> FAIL: dependencies_test.go:42: dependenciesTest.TestGodepsIsRight
[23:54] <wallyworld> dependencies_test.go:77:
[23:54] <wallyworld>     ...
[23:54] <wallyworld> dependencies_test.go:70:
[23:54] <wallyworld>     c.Fatal(string(out))
[23:54] <wallyworld> ... Error: godeps: no version control system found for "/usr/lib/go/src/pkg/bufio"
[23:54] <wallyworld> godeps: no version control system found for "/usr/lib/go/src/pkg/bytes"
[23:55] <wallyworld> thumper: davecheney: you guys seen ^^^^ as a result of PR 495?
[23:56] <thumper> huh? nope
[23:56] <wallyworld> sigh
[23:57] <thumper> I do think that a test for godeps isn't right
[23:57] <thumper> and the make rules I added were better
[23:57] <thumper> but ..
[23:57]  * thumper shrugs
[23:57]  * wallyworld will reply to list