[00:02] <oerheks> if it is UEFI, AMD A9 cpu ...
[01:42] <jhutchins> dunbrokin: There is often a physical "key" required to unlock the BIOS password.  Sometimes it's as simple as a jumper on the motherboard, other options include a specially built loop-back plug for the parallel port.
[01:42] <jhutchins> dunbrokin: You might be up against something like that.
[04:49] <QuestionMark> hi
[04:51] <QuestionMark> im install ubuntu 22.04 in a hp laptop with windows 10, but when reboot show a BSOD and need to select UEFI Reboot option in orden to start ububtu
[04:52] <QuestionMark> how can i delete windows and start just with ubuntu
[04:53] <arraybolt3> QuestionMark: Easiest way is to reinstall Ubuntu from scratch using the Erase Disk option.
[04:53] <arraybolt3> Careful - this will wipe EVERYTHING on the computer and replace it with a brand-new Ubuntu installation.
[04:54] <QuestionMark> thanks arraybolt3 , but i cant start from the usb drive anymore
[04:54] <arraybolt3> If you have data you care about, save it to an external drive first.
[04:54] <arraybolt3> QuestionMark: Turn the computer all the way off. Insert the USB drive, then turn the computer on and hit Esc (or another key indicated by your system) over and over during early boot. From there you should be able to select a boot menu, then select the flash drive.
[04:55] <arraybolt3> (This should work on EFI systems - if you don't have a Boot Menu option on your system, let me know what manufacturer and model your system is.)
[04:55] <QuestionMark> gonna try again
[04:55] <descent1> esc for hp
[04:55] <QuestionMark> HP 240 G8
[04:56] <QuestionMark> F10 works for the BIOS
[04:56] <QuestionMark> ce ya !
[04:57] <descent1> oh yeah i think f10 hp..whoops
[04:58] <arraybolt3> descent1: Esc works for me.
[04:58] <descent1> ah cool
[04:58] <arraybolt3> On an Elitebook 8570p, a Z220 SFF workstation, and a Pavilion something-or-other.
[04:58] <arraybolt3> And I think it even works on an old Compaq I have around here (I think Compaq and HP are the same now?)
[04:59] <descent1> haha cool
[04:59] <descent1> i have a pavillion 8400 i5
[04:59] <descent1> the cpu anyways
[05:00] <arraybolt3> Must be nice! All my stuff is pretty old (my desktop is rocking a 3rd or 4th gen Xeon, and used to run Windows 8.0...)
[05:01] <descent1> yeah its a pretty fast cpu 6 cores no ht 16gb ram
[05:02] <arraybolt3> QuestionMark: Any progress?
[05:02] <QuestionMark> hi again
[05:03] <QuestionMark> nop, i cant boot from the usb drive
[05:03] <arraybolt3> It doesn't show up in the boot menu, I'm guessing?
[05:03] <oerheks> uefi system? disable fast boot.
[05:03] <QuestionMark> i was disable secure boot
[05:04] <oerheks> secureboot is fine.
[05:04] <arraybolt3> QuestionMark: In the BIOS, set the boot order to put the flash drive first. https://support.hp.com/in-en/document/ish_3891464-2337914-16 Then try to boot from it.
[05:04] <QuestionMark> im need start  ububtu install setup into ubuntu, like wubi but in linux
[05:04] <QuestionMark> boot order its ok
[05:05] <arraybolt3> QuestionMark: That doesn't exists AFAIK. Maybe you should redownload the Ubuntu ISO and flash it to the USB using Startup Disk Creator?
[05:05] <QuestionMark> windows try to restore te system and block usb start
[05:05] <arraybolt3> (It's possible that it's the USB drive's fault.)
[05:05] <arraybolt3> Oh, I know what you're talking about, I think!
[05:05] <QuestionMark> i can see my usb drive, but i cant boot from them
[05:05] <arraybolt3> Hold down the Shift key when you power down Windows. I think you're running into Fast Startup.
[05:06] <oerheks> sure you can, you did this before.
[05:06] <QuestionMark> good tip arraybolt3 , i gonna try again
[05:06] <arraybolt3> Like, boot into Windows, click the Start Button, hover (or click on?) the power button, then hold down Shift, and while holding Shift, click the Shut down button.
[06:04] <webchat61> Hi!
[06:04] <webchat61> I am not entirely sure if this is the correct channel to ask, so if it is not I apologize and would ask you to point me in the right direction.
[06:04] <webchat61> I have two problems running Ubuntu 22.04 in my VM explained in detail here: https://communities.vmware.com/t5/VMware-Workstation-Pro/Workstation-Pro-16-2-3-Pick-your-Poison-gt-Massive-Input-Lag-or/td-p/2911264
[06:04] <webchat61> TLDR: I either enable hardware acceleration for my VM and see rendering issues in Chrome and IntelliJ or I turn hardware acceleration off and experience a massive input lag. It seems that it even got worse after the latest round of updates.
[06:04] <webchat61> Does anyone else have these problems?
[06:04] <webchat61> Are there any known workarounds?
[06:07] <oerheks> webchat61, more an issue for #vmware ?
[06:11] <webchat61> Well, I am not sure. VMWare support said they couldn't reproduce the issue and that since "Ubuntu 22.04 has ben recently released it hasn't been fully tested yet"... So I am trying my luck here.
[06:11] <webchat61> oerheks thanks for the suggestion though, I will post there as well.
[06:16] <oerheks> webchat61, else post on askubuntu?
[07:03] <pagios> hey guys, whar do you think about this book to understand browser security ? https://www.amazon.de/Tangled-Web-Securing-Modern-Applications/ does it still apply?
[07:12] <oerheks> pagios, no, as it is a dead url
[07:13] <oerheks> this pages says 2011...  https://www.amazon.nl/Tangled-Web-Securing-Modern-Applications/dp/1593273886
[07:13] <pagios> yea does it still apply
[07:13] <oerheks> nope, 2011?
[07:13] <oerheks> 11 years ago ..
[07:56] <gneeriiloeepdeer> Im using okular to study. Its a great tool because I can annotate and highlight text. However, I can only highlight in 2 colors, green and yellow. Is there something that allows the user to use more colors?
[07:56] <gneeriiloeepdeer> an expansion package?
[08:06] <confuseus> i am getting these messages since yesterday i think "pending update of ["chromium"|"firefox"] snap. close the app to avoid further disruptions (13 days left). am on ubuntu 22.04. not sure what i am supposed to do. close the app for how long? i closed them and reopened the messages did not go away. i also tried snap refresh...
[08:35] <ogra> confuseus, there are still some rough edges around the snap update control ... especially that it does not tell you to run "sudo snap refresh" (or offer a button that can do this without oprning a terminal)  ... close the app, open a terminal, run the refresh command and you will be good
[08:37] <confuseus> thanks. i saw that when closed them and done snap refresh they both refreshed. so, i hope it' resolved now
[08:39] <deadrom> leftyfb, how's lxd different from esxi? I need bare metal for reasons. (yesterday asked about recovery options for an LTS, you mentioned lxd)
[08:39] <deadrom> oh, container. nvm.
[08:41] <imi> hi, how do I list the snap packages that can be updated?
[08:59] <sophie> imi: snap refresh --list
[09:06] <gneeriiloeepdeer> each time I start ubuntu I get: Pending update of firefox snap, close the app to avoid disruptions (13 dys left), but ff is already updated to 100
[09:07] <gneeriiloeepdeer> I already shut ff yesterday, upon this prompt, but nothing changed...
[09:08] <oerheks> gneeriiloeepdeer, see answer ogra; sudo snap refresh
[09:08] <oerheks> might work for you too
[09:08] <gneeriiloeepdeer> I can execute that command, but do you mean user ogra from this channel?
[09:09] <oerheks> ogra from this channel, and yes, executing that command should do no harm
[09:09] <gneeriiloeepdeer> all snaps up to date
[09:09] <gneeriiloeepdeer> and that prompt appeared again...
[09:09] <oerheks> firefox in 22.04 is 101 now
[09:10] <gneeriiloeepdeer> curious: mine is 100.0.2
[09:10] <oerheks> remove firefox / chromium and reinstall?
[09:10] <gneeriiloeepdeer> dammit
[09:10] <ogra> try "sudo snap refresh firefox" then
[09:10] <oerheks> i think 101.2 https://snapcraft.io/firefox
[09:11] <oerheks> if not, something is terrably behind..
[09:12] <ogra> i think firefox gets phased updates due to the sheer amount of users it has ... some might still be behind then until the phasing is finished
[09:13] <gneeriiloeepdeer> I don't see how snaps is better than deb. With deb, my machine downloaded the stuff automatically. I only had to accept the changes.
[09:13] <gneeriiloeepdeer> now I have to intruct the machine to update?
[09:14] <gneeriiloeepdeer> and thanks ogra , your command worked
[09:14] <ogra> no, you could just wait 13 days and it would just update quietly
[09:14] <gneeriiloeepdeer> oh
[09:14] <ogra> it is to prevent you from having the app open while it gets updated (which means the data dirs change underneath the open app, which is not a go idea)
[09:15] <ogra> but the refresh control stuff is brand new and not 100% yet ... there will be soething lie an "update now" button in the notification eventually ... or something similar
[09:16] <ogra> s/g👋good/
[09:16] <ogra> bah ...
[09:16]  * ogra curses hexchats emoji plugin
[09:16] <gneeriiloeepdeer> I see, still migrating
[09:19] <gneeriiloeepdeer> ogra, when I execute 'firefox' in my CLI, my system needs 5 seconds to show the app. Is this going to be addressed or is this the new normal?
[09:23] <ogra> gneeriiloeepdeer, the most complained-about bug and being workd on with full throttle :) https://ubuntu.com/blog/how-are-we-improving-firefox-snap-performance-part-1
[09:23] <ogra> gneeriiloeepdeer, note that it only happens after boot or after refresh on first start ... all subsequent starts should be in the sub-3-sec realm
[09:24] <descent1> what causes it
[09:25] <ogra> that's the million dollar question 🙂 (funnily the chromium snap does not expose it)
[09:31] <descent1> well sometimes i would click firefox it wouldnt load, then click it again it would
[09:33] <descent1> i was using a hard drive too
[09:33] <descent1> maybe it was too slow
[09:35] <ogra> i'd guess it was already starting and your second click just went into nirvana
[09:36] <ogra> but yeah, rotary drives seem to have some impact ... AMD graphics cards seem to have some too based on the data that has been collected yet ... https://discourse.ubuntu.com/t/known-issues-with-firefox-snap/24663
[09:37] <descent1> it acted like it was starting on the top bar in gnome de it would say firefox top left then disappear
[09:37] <descent1> ah
[09:38] <ogra> it will be fixed before the .1 release of 22.04
[09:38] <descent1> cool
[09:38] <ogra> (at least thats the target AFAIK)
[09:57] <gcds> Hi, maybe someone could help me with ubuntu server netplan stuff, I am going bald from trying to figure out what is wrong. Context: I have network <IP_ADDRESS>/16 the server has a bridge with one interface and static IP address of <IP_ADDRESS>/16, everything generates and works but for some reason I can't access anything higher than <IP_ADDRESS>, I
[09:57] <gcds> tried adding a static route for <IP_ADDRESS>/16 via <IP_ADDRESS> but didn't help, but then I removed default generated route which looked suspicious to me (the <IP_ADDRESS>/16 via <IP_ADDRESS> in the paste) and it worked then, I would consider it's done but I know it's not permanent so maybe can help me figure out whats wrong with netplan so I would not need
[09:57] <gcds> to make changes after each reboot? https://paste.ubuntu.com/p/kPrPBwPQBx/
[10:02] <lotuspsychje> gcds: try #ubuntu-server where the server experts gather
[10:02] <gcds> lotuspsychje thanks!
[11:17] <WeeBey98> Good morning frens!
[11:18] <WeeBey98> Which would be the preferred method to stop a fresh installation from performing ANY updates? (and never update automatically)?
[11:19] <matsaman> Debian
[11:19] <WeeBey98> disabling apt-daily ?
[11:19] <WeeBey98> matsaman, lol; Debian does not perform auto updates?
[11:20] <matsaman> don't think so
[11:20] <matsaman> not by default
[11:20] <matsaman> https://linuxconfig.org/disable-automatic-updates-on-ubuntu-22-04-jammy-jellyfish-linux
[11:21] <WeeBey98> matsaman, thanks. I'll give this a shot. I'll be likely using LTS 18.04.
[11:21] <WeeBey98> Hope it works. If not, maybe I'll try Debian!
[11:21] <WeeBey98> :-)
[11:24] <WeeBey98> Another question then. If I download 18.04 from Ubuntu website, does it have updates already installed? Or is it the original 2018 18.04 ISO? I can see the last modified for the iso is 2021... that's why I am asking.
[11:25] <matsaman> WeeBey98: if you're downloading now, I don't know why you'd choose 18 and not 22.04
[11:25] <bittin> 18.4.6 updated 17:th September 2021: https://lists.ubuntu.com/archives/ubuntu-announce/2021-September/000272.html last time
[11:25] <bittin> but you can update it via apt
[11:25] <matsaman> WeeBey98: the .6 is the revision from the original, in that case
[11:26] <WeeBey98> bittin, ah! Ok. thank you for the clarification.
[11:26] <bittin> np
[11:26] <WeeBey98> Ok, I will look for the original.
[11:27] <bittin> not sure why you don't want a more updated image?
[11:27] <matsaman> https://old-releases.ubuntu.com/releases/bionic/
[11:28] <WeeBey98> matsaman, Just had arrived at that page.
[11:28] <matsaman> WeeBey98: sure sure sure =)
[11:28] <WeeBey98> bittin, I have a security course assignment and I need unpatched software.
[11:28] <bittin> ah
[11:28] <bittin> i see
[11:29] <WeeBey98> so, if I find the original file, it will save me from having to find and install older libs manually
[11:29] <matsaman> it could, theoretically
[11:30] <WeeBey98> Right! matsaman I am hoping that my theory is correct. :D
[11:30] <WeeBey98> You are very helpful. Thanks so much!
[12:09] <BluesKaj> Hi all
[12:10] <deadrom> Heya
[12:19] <transhumanist> system_key.go:154: cannot determine cgroup version: cannot determine cgroup version: cannot statfs path: no such file or directory twm:  unable to open fontset "-adobe-helvetica-bold-r-normal   << I have narrowed this error down to sandboxing browsers while the browser is installed with snaps. Anyone know a fix?
[12:20] <transhumanist> noone ever answers from snappy forum or snappy channel
[12:25] <transhumanist> I just figured out its a problem with systemd and is going to be fixed in the next version (well a similar error) https://github.com/containers/podman/issues/7562   , can I install systemd from source and expect it to work ok?
[12:27] <transhumanist> forget it , I think its too risky an upgrade
[12:41] <chrfle> Hello, I'm trying to get ccache to work across different directories. I have set base_dir to /home/chrfle ... if I make clean && make then it uses the ccache to speed it up, but if copy this director and make clean && make in the new directory, I get 100% cache miss.. Any advice what I've done wrong, or how I can debug it
[15:06] <SpeedStick> hello hope someone can help i'm trying to get gnome shell integration to work on Ubuntu 22.04 and i'm having issues
[15:07] <SpeedStick> I've installed everything and when I go to the gnome extension website its telling me "Although GNOME Shell integration extension is running, native host connector is not detected. Refer documentation for instructions about installing connector."
[15:08] <oerheks> yes, there is no tool anymore to auto detect your gnome version to get the plugin
[15:09] <oerheks> so, install the plugin for your browser, see https://linuxconfig.org/how-to-install-gnome-shell-extensions-on-ubuntu-22-04-jammy-jellyfish-linux-desktop
[15:09] <oerheks> and then you can do what you like
[15:10] <SpeedStick> thank you i'll go ahead and try it
[15:12] <SpeedStick> so i'm not getting the switch on gnome extension
[15:12] <oerheks> restart browser ?
[15:15] <SpeedStick> oerheks: I was using brave and for some reason it wasn't working right on brave but I started up chrome and it worked (I restarted browser etc) thank you
[15:15] <oerheks> SpeedStick, have fun!
[15:19] <xu-help45w34> How to use proxy servers and VPNs in Ubuntu for getting access to sites? I'm stuck since I can't get access...
[15:20] <xu-help45w34> Or any other methods to get access to a site...
[15:27] <oerheks> there are tons of manuals/howtos for a proxy, with a vpn i don't know.. https://www.webservertalk.com/configure-proxy-on-ubuntu
[15:32] <transhumanist> so how do I compile with linux-um-noemu on ubunt 22.04 on x64  do I need to install a package, I get a make error  *** No targets specified and no makefile found.  Stop.
[15:33] <oerheks> transhumanist, what is linux-um-noemu?
[15:36] <ravage> no google results :D
[15:36] <transhumanist> nm I think I figured it out
[15:37] <xu-help45w34> oerheks, thank you! It's useful, but it seems I also have to find a working proxy/vpn which is honestly harder to find
[15:42] <oerheks> there are no good free VPN services
[15:42] <oerheks> so, pay for it or run one yourself
[15:44] <xu-help45w34_pho> oerheks, sorry but it just isn't true. I've been using a ton of free VPN services and all of them were working great
[15:44] <xu-help45w34_pho> Forgot to add: in Androis
[15:46] <xu-help45w34_pho> The only difference is probably that usually VPN in Android works through its own app.
[15:48] <oerheks> choice of vpn is not an ubuntu support issue, what i said about free vpn was just a warning
[15:48] <oerheks> good luck!
[15:50] <goddard> how can i check firmware version for elan fingerprint reader?
[15:50] <goddard> fprintd isn't working for me
[15:50] <goddard> i wanna see if it needs an update or something
[15:50] <xu-help45w34_pho> oerheks, I realise the facts you are talking about :) I think it's kind of OS issue that an ordinary user has trouble getting possibilities which are easily obtainable in Android.
[15:51] <oerheks> goddard, check https://launchpad.net/~fingerprint/+archive/ubuntu/fingerprint-gui and https://fprint.freedesktop.org/supported-devices.html
[15:51] <oerheks> if your fingerprint device is supported
[15:51] <goddard> oerheks: thanks
[15:52] <oerheks> else, if it is listed, check for a bios update?
[15:52] <goddard> oerheks: yep its supported
[15:52] <goddard> 04f3:0c11
[15:52] <goddard> oerheks: ill check that
[16:27] <mjg_> hi. i recently updated focal to jammy and ssh-agent stopped being automatically started. from grepping around it should come from gnome-keyring
[16:28] <mjg_> gnome keyring starts for --components=secrets, just not ssh
[16:28] <mjg_> any ideas what's up? i did not modify /etc/xdg/autostart/gnome-keyring-ssh.desktop fwiw
[16:37] <mjg_> i can work around it by manually starting gnome-keyring-daemon
[17:15] <Hans_Zero> Hi,
[17:15] <Hans_Zero> I have this weird problem while using ubuntu via citrix where my shift keys do work as for writing uppercase letters and symbols and they do work as part of shortcut combinations (e.g. ctrl+shift+v) but they do not work for selecting strings (e.g. shift+right, shift+pageup) unless capslock is active.
[17:15] <Hans_Zero> And I googled a truck load of related problems and I'm confident, that this is indeed an Ubuntu problem and not for example citrix, but I'm totally lost if I go to the forums with this or write a bug report and to which category to apply.
[18:00] <bancroft> I sub to all the security advisories, and in there they say "upgrade to version 8:<IP_ADDRESS>+dfsg-16ubuntu6.13 to no longer be vulnerable". How can you tell what version you're on? This particular case is for imagemagick (or rather, imagetragick). When I run convert --version I have something lik 6.9.7 and not 8:<IP_ADDRESS>_...
[18:03] <alkisg> dpkg -l imagemagick => 8:<IP_ADDRESS>+dfsg-1.3build2
[18:03] <alkisg> The 8: in front is called the "epoch", it's a packaging trick needed when version updates have been jumpy in the past
[18:04] <alkisg> So convert --version is the upstream version, while dpkg -l tells you the debian package version
[18:04] <bancroft> I see, thanks for that :)
[18:28] <lotuspsychje> bancroft: https://ubuntu.com/security/notices/USN-5456-1
[18:36] <QuestionMark> Hi guys
[18:49] <bancroft> hi ?
[18:49] <sarnold> hello
[19:03] <morganu> hello back y'all: is there a routine that can tell if the connection to the enternet drops and reforms in under a second. (I see that on a stream, and didnt used to see that.)
[19:03] <morganu> 20.04
[19:06] <morganu> or do I call the cracker, uh I mean Spectrum, aka Charter in soCal.
[19:08] <sarnold> morganu: ip monitor  can spot some kinds of things like that; often people will run something like smokeping or write similar tools for checking latency / connectivity ..
[19:22] <Guest89> Hey, just installed 22.04 and wanted to setup wireguard. When trying to connect, it complains about not able to use resolvconf. Shouldn't systemd-resolved take this part and should be usable?
[19:26] <tomreyn> Guest89: by "complain", are you referring to a warning message? if so, which? how did you install wireguard?
[19:26] <jhutchins> morganu: What exactly do you "see" on a stream?  Dropping and re-negotiating a connection takes more than a second.
[19:27] <Guest89> tomreyn: I installed the wireguard metapackage and complains (I guess errors out) as he removes the eth device after that
[19:28] <Guest89> tomreyn: https://paste.debian.net/1242725/ this is when i sudo wg-quick up wg0
[19:29] <tomreyn> Guest89: i see. this looks like a packaging error in case this is the official wireguard package for 22.04.
[19:30] <Guest89> tomreyn: ahh which means resolvconf should be installed with wireguard?
[19:30] <tomreyn> Guest89: that's what i assume needs to happen, just based on the message you shared.
[19:31] <tomreyn> another option would be to edit / rewrite the wg-quick script, i guess
[19:31] <Guest89> tomreyn yeah interesting. I thought it would conflict with systemd-resolved, which it doesnt
[19:34] <tomreyn> Guest89: https://packages.ubuntu.com/jammy/wireguard-tools is the userland tooling that's in main in jammy (22.04), it recommends openresolv or resolvconf
[19:34] <tomreyn> sugggests, not recommends, sorry
[19:35] <tomreyn> and that's probably the actual issue here.
[19:35] <Guest89> ahh thanks :)
[19:35] <Guest89> and btw, shouldn't network manager handle wireguard? when I go to network settings (gnome) I can't add a wireguard config
[19:37] <bahamat> Hey all. I also recently installed ubuntu 22.04, and am trying to use RDP. It seems like it only works when someone's actively using the directly attached X? If the screen is locked I can connect. Is there a way to make it always available?
[19:37] <morganu> easy question: in 20.04 can I snap 2 (or more) windows to fill the screen?
[19:38] <Guest89> morganu yes, just drag them to the side, as the top would maximize them
[19:38] <tomreyn> Guest89: usually, network-manager support for additional protocols such as VPNs are packaged separately (in universe) as extensions / plugins. but none seems to exist for wireguard in jammy.
[19:39] <Guest89> tomreyn it was integrated with nm in 1.24 or so. since then I can't find it
[19:40] <ioria> Guest89, try 'nm-connection-editor'
[19:41] <tomreyn> Guest89: apparently you're supposed to import its configuration file into NM as you would for openvpn
[19:41] <Guest89> hm let me try that tomreyn
[19:41] <tomreyn> https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ (very old 2019 article, may no longer apply)
[19:43] <Guest89> tomreyn hm, when using nm on the cli, why would I ever do that and not just push the config into the direct directory :/  let's see if it's somehow possible with the gui
[19:43] <tomreyn> i concur with ioria about how to configure it graphically. wireguard support is part of network-manager core, no need for plugins/extensions/extra packages.
[19:44] <tomreyn> https://www.xmodulo.com/wireguard-vpn-network-manager-gui.html
[19:46] <Guest89> ugh, k thanks tomreyn and ioria, sadly it seems like it's not possible to just import the conf files, you would need to set it up :(
[19:48] <tomreyn> why does it not seem to be possible?
[19:48] <Guest89> tomreyn when I try to import the conf file, it complains that it's not a correct conf (I assume because it's expecting a openvpn config)
[19:50] <tomreyn> hmm, maybe the "type wireguard" is not being passed to the backend by the GUI then: nmcli connection import type wireguard file "wg0.conf"
[20:05] <Guest89> tomreyn thanks, seems like wireguard is still not ready for the masses (was looking something for my parents) but I can't activate the connection in any gui way.
[20:06] <Guest89> and honestly, why would the vpn activate directly when you import the config file ...
[20:07] <tomreyn> Guest89: i have no personal experience with using wireguard through a GUI on 22.04, can't comment.
[20:08] <Guest89> tomreyn thanks anyways :)
[20:09] <Guest89> tomreyn btw, do you happen to know if it's an extension or builtin that when you have a vpn connection that it shows in the menu in the right corner (gnome)
[20:11] <tomreyn> Guest89: i do not know for sure, but would assume this to be part of network-manager-gnome directly, since this is what wireguard support is in.
[20:12] <Guest89> tomreyn huh, oh well. I will play with it some more, but seems like I need to go back to ovpn then, as nm doesn't seem to play well with wg
[20:14] <BadAtom> Guest89: if you have the wireguard and wireguard-tools packages installed, you should be able to do the full set-up in network-manager
[21:10] <Guest89> another question, I tried to use machinectl, which errored out while pull-tar with permission denied. now I can't delete the directory it created under /var/lib/machines (even root is not enough oO) any idea how I would go about to delete that?
[21:50] <QuestionMark> Hi guys
[21:51] <matsaman> hi
[21:54] <Guest89> hm even using a live usb doesn't help in deleting the directory https://paste.debian.net/1242741/ anybody got any idea?
[21:55] <Guest89> hm, even using a live usb doesn't help in deleting the directory, somebody got any idea? https://paste.debian.net/1242741/
[21:56] <sarnold> Guest89: look for 'i' in the chattr(1) manpage
[21:56] <Guest89> sarnold thanks :)
[21:56] <sarnold> Guest89: if it's something else I'd be very curious to hear it :) hehe
[21:57] <matsaman> Guest89: smells a bit like a mount
[21:57] <matsaman> mount | fgrep '#tar43'
[21:58] <Guest89> sarnold thanks worked perfectly :)
[21:58] <Guest89> matsaman chattr helped :)
[21:58] <Guest89> now I have to figure out why I got a permission denied when pulling a tar into machinectl :/
[21:59] <matsaman> cool
[22:06] <Guest89> does reportbug report a bug to debian or ubuntu? it's a bug in systemd, and it got never backported to 249, which sadly 22.04 is on
[23:09] <goddard> why am i getting an issue running nvidia-smi
[23:09] <goddard> NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.
[23:09] <goddard> nvidia is installed
[23:10] <arraybolt3[m]> goddard: How did you install the nVidia drivers?
[23:10] <goddard> with the drivers gui
[23:11] <goddard> i always get this issue
[23:11] <arraybolt3[m]> Do you mean the "Additional Drivers" tab of Software Sources, or do you mean the nVidia installer script provided by nVidia themselves?
[23:11] <goddard> yes
[23:11] <arraybolt3[m]> The first one?
[23:11] <goddard> yes
[23:11] <arraybolt3[m]> Hmm. OK, well, are other applications able to use your GPU?
[23:12] <arraybolt3[m]> (Also, what GPU are you using? GTX 1050 Ti? Or...?)
[23:13] <goddard> 3080
[23:13] <goddard> nope
[23:14] <arraybolt3[m]> Hmm. What driver version are you using? You might need to try a different driver.
[23:15] <goddard> 510
[23:15] <goddard> it was working previously
[23:15] <goddard> i always get this issue
[23:15] <goddard> if you have cuda and you upgrade your nvidia driver it puts cuda on the uninstallable list and then i have to totally reinstall the driver
[23:16] <goddard> if you sudo apt autoremove you just nuke your ability to use cuda/nvidia
[23:16] <goddard> What is the correct way to install cuda and still be able to handle upgrades?
[23:17] <arraybolt3[m]> ?! That's really weird. Someone else appears to have had a similar problem to you and was able to fix it by manually installing the nVidia drivers with the .run script. This is generally a bad idea, but it might work in your situation. https://forums.developer.nvidia.com/t/nvidia-smi-has-failed-because-it-couldnt-communicate-with-the-nvidia-driver-make-sure-that-the-latest-nvidia-driver-is-installed-and-running/197141/7 Make backups and
[23:17] <arraybolt3[m]> be prepared to reinstall your Ubuntu system if you're going to do stuff like this.
[23:17] <goddard> ya probably works on the run script because that pins the version
[23:19] <arraybolt3[m]> Oh hey, do you have Secure Boot disabled on your system?
[23:21] <goddard> no
[23:22] <arraybolt3[m]> Some people reported that disabling Secure Boot fixed the problem.
[23:23] <sarnold> o_O
[23:23] <sarnold> did they install drivers from not-ubuntu or something?
[23:24] <arraybolt3[m]> I dunno, but I do know that Secure Boot and nVidia can have some serious problems when you put them together if you don't go through some crazy MOK signing process. And Secure Boot doesn't actually help computer security all that much, anyway.
[23:25] <arraybolt3[m]> If you're unable to get nVidia to work at all, and you're using Secure Boot on your system, that's likely the problem, in which case the easiest solution would be to disable Secure Boot.
[23:26] <arraybolt3[m]> sarnold: Oh, I got you and goddard mixed up...
[23:26] <arraybolt3[m]> (Matrix gave you both a green icon with a blue name...)
[23:26] <sarnold> booooooo
[23:27]  * sarnold kicks matrix
[23:33] <goddard> haha
[23:34] <goddard> im just gonna reinstall
[23:34] <goddard> see if that resolves that issue
[23:34] <goddard> turn it off and turn it on again
[23:34] <goddard> solves all problems
[23:34] <arraybolt3[m]> OK. If Ubuntu tells you anything about MOK keys, go ahead and do the thing it tells you. That should give you a chance with Secure Boot.
[23:38] <goddard> thanks will do


[00:07] <nigelbabu> 82, yaay!
[00:07] <nigelbabu> nhandler: you're on in 1 hour
[00:20] <nhandler> nigelbabu: Aren't I going on 01:00 UTC, which is 1.75 hours from how
[00:21] <nigelbabu> nhandler: wht is utc time now?
[00:21] <nhandler> nigelbabu: 23:21
[00:21] <nigelbabu> nhandler: oh no, can you start frm next session, i need to get to work
[00:22] <ajmitch> nigelbabu: wouldn't you need sleep or something first? :)
[00:22] <nigelbabu> ajmitch: sleep is over. 2200 to 0230
[00:22] <nhandler> nigelbabu: I can try, but I'll probably be eating dinner in the middle
[00:23] <nigelbabu> nhandler: *grin*  ajmitch will be around :)
[00:23]  * ajmitch may not be around
[00:23] <ajmitch> that'll be when I head out for lunch (12:00 here)
[00:24] <nigelbabu> 83 bugs more!
[00:24] <nhandler> Somehow we'll cover any questions that get asked during that hour, but they might need to wait for answers
[00:26] <maco> nigelbabu: im helping a guy fix his centos
[00:26] <maco> im failing :(
[00:26] <maco> im *trying* to help him fix his centos
[00:26] <maco> but its a yum b0rk not a things-that-exist-here-too b0rk
[00:27] <maco> akk: i think the list is "stuff ubuntu-reviewers is subscribed to" and that the magic date is simply the date from which the script that autosubscribes the team was set to run
[00:28] <nigelbabu> maco: lol, ok.  we're having a gap in coverage due to my excellent math skills thinking gmt = utc
[00:30] <maco> ah daylight savings got ya?
[00:31] <nigelbabu> i think so, why is there no desktop tool for time conversion?
[00:31] <maco> date -u
[00:31] <yofel> @now
[00:31] <yofel> :(
[00:32] <maco> nigelbabu: the date command accepts format strings, such as %Z for the timezone name to be listed
[00:33] <nigelbabu> maco: ok, so basically its always -4:30 for me
[00:33] <nigelbabu> well, I'm always at +4:30 from UTC
[00:33] <maco> right, whereas gmt moves about for british summer time
[00:34] <nigelbabu> yeah, I usually keep a gmt thingie on my clock and forgot it moved around
[00:36] <nigelbabu> can someone review 3 more bugs?
[00:36] <nigelbabu> so we can get to 70?
[00:37] <nigelbabu> at least I want to make sure we reach the 40s for this patch day :)
[00:38] <nigelbabu> persia: we need some system to deal with packages that are ubuntu-specific
[00:40] <nigelbabu> also, can someone test and review bug 564698
[00:40] <ubot3> Malone bug 564698 in util-linux "lscpu command shows "???" when messages are translated in Japanese" [Undecided,New] https://launchpad.net/bugs/564698
[00:40] <ajmitch> persia would be good to look at that :)
[00:40] <nigelbabu> yes, hopefully he will when he sees it :)
[00:41] <nigelbabu> maco: can take a look at the k-reltaed packages in the list?
[00:41] <nigelbabu> wow, I spell *bad*
[00:42] <nigelbabu> ajmitch: wise to defer eucalyptus to server team?
[00:42] <ajmitch> yes
[00:42] <nigelbabu> just unsubscribe then?
[00:42] <ajmitch> I assume so, you're the boss ;)
[00:43] <nigelbabu> lol, no I'm not :)
[00:43] <ajmitch> but that bug looks very actively looked at
[00:43] <nigelbabu> yeah, its assigned too
[00:46] <nigelbabu> ok, so I'm off, someone please cover and answer questions
[00:46] <nigelbabu> we're at 82
[00:47] <nigelbabu> bug 569442
[00:47] <ubot3> Malone bug 569442 in ttf-wqy-zenhei "After upgradeing to Lucid, unexpectedly-using bitmap font in Japanese Environment (upgrading regression)" [Undecided,New] https://launchpad.net/bugs/569442
[00:47]  * nigelbabu points to maco ^
[00:48] <maco> ew yuck. bitmapped japanese. that has to be hard to read
[00:48] <nigelbabu> bitmapped chineese actually I think
[00:48] <nigelbabu> check out the bug
[00:49] <maco> japanese uses chinese characters
[00:49] <Paddy_NI> Hey maco
[01:12] <nigelbabu> maco: o_0 thats news to me
[01:16] <maco> nigelbabu: japanese didnt have a written language. chinese monks gave them literacy
[01:20] <nigelbabu> maco: wow
[01:24] <ajmitch> almost down to 1 page of stuff to look at
[01:25] <nigelbabu> YAAY! We have breached 80
[01:25] <nigelbabu> Only 79 more bugs to look at!
[01:47] <maco> Paddy_NI: https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
[01:48] <Paddy_NI> thanks maco I was wondering what I should be doing.. perhaps reading the topic :)
[01:59] <maco> um hmmm
[01:59] <maco> so one of the wiki pages links to bugs that have been marked accepted upstream or accepted debian
[02:00] <maco> maybe this query should filter out "fix committed" bugs though, since if its committed in ubuntu, its just waiting for a freeze to be lifted, which most people cant really do anything about
[02:00] <nhandler> So I guess I'm up now
[02:23] <nhandler> Nice and quiet now
[02:25]  * ajmitch is working...
[02:41] <nhandler> Hmm...Does anyone remember what bugs the script looks for to subscribe the reviewers team to?
[04:49] <persia> nhandler: I believe the script looks for any bugs with attached patches that have the patch added since a certain date and aren't subscribed to a blacklist of teams and aren't bugs against a blacklist of packages.
[04:50] <nhandler> persia: Do you know what statuses it looks at?
[04:51] <persia> I believe all open statuses (not invalid, won't fix, fix released).
[04:51] <nhandler> Ok, thanks
[04:51] <persia> The interesting question is: if a bug is Fix Committed and has a patch attached, is this confusion on the part of the person setting the status?
[04:54] <maco> persia: bdrung told me today that if i upload a package but its sitting in the queue waiting to be approved, then its fix committed
[04:54] <maco> for -proposed stuff and during freezes
[04:55] <persia> I guess, but why should it both have an attached patch and *not* be subscribed to a team?
[04:56] <persia> I think the majority of cases are mistakes: the rare case where it's correct, we can just unsubscribe the team.
[05:00] <persia> And it's still Patch Day!  We're down to 79 bugs to review, which indicates that we're 58% done.
[05:01] <maco> what team would be subscribed when its uploaded and sitting in a queue?
[05:01] <maco> archive admins or something?
[05:01] <maco> (do they have a team?)
[05:01] <persia> Depends on the reason for the freeze.
[05:02] <persia> I'd say the Release Team, generally.
[05:02] <maco> i uploaded a merge to maverick today thats waiting for toolchain freeze to go away
[05:02] <persia> So, bug #538774 is an example of a bug in our queue that's Fix-Committed.  Why shouldn't that get patch-accepted-debian and be unsubscribed?
[05:02] <ubot3> Malone bug 538774 in python-scipy "scipy.io.loadmat() excessively slow (regression)" [Undecided,Fix committed] https://launchpad.net/bugs/538774
[05:03] <persia> Also, even if an upload is prepared for Ubuntu, should we not be looking at pushing the patch somewhere else (or verifying that this has been done)?
[05:03] <maco> that's a misuse
[05:04] <maco> the person put fix committed when they committed to their own branch on lp, but if theyre going to use that it should be when it gets committed to lp:ubuntu/<package>
[05:04] <persia> How is that different than the case you describe?  It will be closed with autosync in a couple days, much like the case you descibe will be closed with unapproved queue clear.
[05:05] <persia> Oh, right.  Timing miss.
[05:05] <maco> timing miss?
[05:05] <persia> Yeah.  The status was changed for the incorrect reason (making it good we caught it), *but* in later analysis, it has reached a state that matches what you describe.
[05:06] <maco> oh yeah i looked at the activity log to see how it got there
[05:07] <maco> i dont think we're doing it like this yet, mostly (though kubuntu does) but committing to lp:ubuntu/<package> bunches of fixes and then only doing a dpkg-buildpackage -S once seems like something thatll be futury
[05:07] <maco> futurey
[05:07] <maco> erm..something
[05:07] <persia> Right.  Anyway, my point is that in case 1: where it's Fix Committed for the wrong reasons, we want it anyway, and in case 2: where it's Fix Committed because it's been uploaded and pending processing, it's not bad for us to get it.
[05:07] <maco> "get it"?
[05:07] <persia> "receive the bug in our review queue"
[05:09] <persia> I've worked on a bunch of packages that do VCS packaging and upload containing lots of fixes by lots of folks, and yes, in that case, Fix Committed makes sense, but I think there's still value in us tracking the patches to ensure that patch communication is happening.
[05:15] <maco> you mean in terms of upstreams?
[05:21] <maco> persia: patch communication in terms of what?
[05:21] <persia> Yeah.
[05:22] <persia> Basically, I'm not sure how the stuff we do is in any way affected by Fix Committed.
[05:22] <persia> because none of the automated patch communication stuff takes effect until the upload is processed.
[05:23] <maco> i think ill go through all the fix-committed's and check to see if theyre improper use and if so put them to the proper status
[05:23] <persia> I recommend against that.  You'll bump into the Desktop Team, which abuses that status regularly.
[05:23] <persia> There aren't any more Fix Committed ones in our queue.
[05:26] <maco> yeah just noticed that when i saw jon the taco and seb128 both use it weirdly
[05:26] <maco> seems that team uses fix committed in ubuntu in place of upstream bug watches
[05:32] <maco> persia: my email says to tell you im gonna expire from sponsors soon
[05:33] <persia> I suspect your email tells you that you're expiring from the obsolete sponsors team, and suggests telling me under the false impression I'm going to let anyone renew :)
[05:33] <persia> Would you like to join the new, cool, shiny, real sponsors team?
[05:35]  * persia finds the .m and prepares to click the button, waiting for a response
[05:37] <maco> hehe yes :)
[05:37] <maco> the .m?
[05:38] <maco> is that because lp/~maco != me ?
[05:38] <persia> Yes.
[05:38] <persia> The .m is essential
[05:38] <maco> yeah i dont know lp/maco
[05:38] <maco> just that they took my name
[05:43] <maco> thanks
[05:43] <maco> (just got email)
[05:44] <persia> Thanks for helping with sponsoring :)
[05:57] <persia> OK.  5:00 UTC, and we're only down to 78, which is the one I did.  There's lots there, and we've only 6 hours left, which means we need to push fairly hard to finish within the day!
[06:35] <maco> persia: it went back up to 79
[06:37] <persia> It did indeed, but shishire is working 485225, and I expect it to go back down soon.
[06:39] <maco> persia: if a not-right patch is attached to a bug, should we unmark it as a patch or delete it or what?
[06:39] <persia> example?
[06:39] <maco> https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/512395
[06:39] <ubot3> Malone bug 512395 in openoffice.org "Openoffice.org's .desktop files do not contain translation domain info" [Wishlist,New]
[06:40] <maco> well in this case there are a bunch of "oh no wait this time i got it right..." type things
[06:40] <persia> I'd call that patch-needswork
[06:40] <maco> should the old patches be removed?
[06:40] <dholbach> good morning
[06:40] <persia> I'd leave the old patches for historical purposes.
[06:40] <maco> ok
[06:41] <maco> should they be unmarked so that the patch list on the side only lists the one thats being suggested?
[06:41] <persia> Hmm.  That's an interesting question.
[06:42] <persia> I think "No", because I think there's sufficient value in reading the bug log to understand the background.
[06:42] <maco> ok
[06:42] <persia> That said, it does add apparent difficulty if one assumes folks just grab from the patch lists and push, but I think doing so is uninformed behaviour, and don't want to encourage it.
[06:43] <persia> Note that I feel this is a very subjective opinion on my part: I'm not certain it should be policy without wider discussion.
[06:43] <maco> usually when im going "oops that patch was wrong, heres a fixed one" i delete my previous one from the bug. wasnt sure if that was just me or not
[06:43] <dholbach> Development and MOTU Q&A Session in #ubuntu-classroom in 17m
[06:44] <maco> dholbach: pfft nobody in this channel has any interest in development :P
[06:44] <maco> this channel is for kitten photos!
[06:44] <dholbach> maco: I hope you're wrong ;-)
[06:44] <persia> And we kinda compete with MOTU in some ways: seeing who can get the patches applied first
[06:44] <persia> (to different targets)
[06:44] <maco> (actually no, #ubuntu-women was the kitten-photo channel earlier)
[06:45] <maco> cuz we're trying to make it so that all the patches reach ubuntu by syncing from debian?
[06:45] <persia> Or, better, by inclusion by the original software authors, yeah.
[06:46] <persia> Mind you, it's a very freindly and cooperative competition :)
[06:46] <maco> well if its in upstream, itll hit debian then sync to here in most cases
[06:46] <persia> Right.
[06:46] <maco> i dont /think/ there's a whole lot that goes straight into ubuntu without passing through debian
[06:46] <maco> except kde. we get that packaged within a day or two of a new release and then i have no idea how long til debian's got it
[06:47] <persia> Depends on the area of focus.  Some areas have lots, some not so much.
[06:47] <maco> mm and the kernel
[06:49] <maco> so where do OOo patches get pushed to? OOo-proper or Go-OOo?
[06:50] <persia> Ask ccheney :)
[07:11] <persia> And we're still at 79 at 6:00 :(
[07:11]  * persia needs to stop digging at hard ones, and hunt through for easy ones
[07:15] <maco> persia: unsubscribe the reviewers team after marking patch-needswork?
[07:16] <persia> maco: Please, and please give the patch submitter as *much* detail as you can about how to fix it.
[07:16] <persia> I'm not sure we have a good model for what to do once the patches get fixed: maybe hint that they can resubscribe us.
[07:16] <maco> persia: a comment has already done that
[07:17] <persia> nigelbabu: When you get back: this is a case that deserves some thought: how to we recapture patches that needed work to ensure that they don't get lost.
[07:25] <maco> persia: dont suppose a script could be written to run periodically that churns through all bugs tagged "patch-needswork" and check the activity log to see if a patch has been added since the tag was and if so, replace the patch-needswork with patch?
[07:25] <maco> (no idea if lplib exposes enough info for that though)
[07:26] <persia> That might work, but we'd need to find a way to put it in a workqueue.
[07:26] <persia> Maybe have that script remove patch-needswork and subscribe the reviewers team again?
[07:40] <ajmitch> oops, looks like I missed dholbach's session :)
[07:40] <maco> ajmitch: its still going
[07:40] <maco> he's doing a Q&A
[07:41] <maco> and im learning more about this UDD stuff and how it makes everything ive been doing obsolete and wrong
[07:41]  * ajmitch goes to read the backscroll
[07:41]  * ajmitch needs to learn how to be a rock star
[07:42] <persia> maco: It's not obsolete and wrong.  I do nearly everything that way.  There are alternatives.
[07:43] <maco> apparently i fail at humour this far past bedtime
[07:43] <ajmitch> even though I've been using bze since 0.0.x, I'm still getting used to the Proper way of using it for packages
[07:43] <ajmitch> s/bze/bzr/
[07:44]  * persia isn't convinced there exists *the* proper way.
[07:45] <persia> I've used it in at least 3 different ways, depending on the set of packages with which I was interacting.
[07:45] <ajmitch> yeah, I've used it with having upstream+debian+integration branches
[07:45] <ajmitch> that made for fun times
[07:53] <persia> Hey gotunandan!
[07:53] <gotunandan> hi persia
[07:53] <persia> It's Patch Day! We're following https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow : just ask if you have any questions, or need an opinion or a hand.
[07:53] <gotunandan> i do not know how useful I can be right now, since I am on a windows PC (at work :P )
[07:54] <persia> Ah, yeah, that makes it tricky to test the patches :)
[07:55] <gotunandan> Also I think I'll need to do some reading up on the entire packaging process, pretty keen on doing something at least in the maverick cycle !
[07:56] <persia> I'd actually recommend against "reading up" too much.  It's easy to get stuck in circles of ever-more-complex documentation for specialised corner cases.
[07:57] <persia> If you just want to do packaging work for Ubuntu, I'd suggest you'd do better to hang out in #ubuntu-motu, try to work on some of the MOTU TODO tasks, and ask questions whenever you get stuck (this will probably be *lots* at the beginning).  Folks will likely point you at specific, targeted, documentation that helps you understand the problem at hand, rather than you needing to learn everything first.
[07:57] <gotunandan> oh, but its been a while since I last did some packaging, my ppa has been stale for a few months now :| Just need to refresh a bit, I guess
[07:57] <persia> Even our most knowledgeable packagers don't pretend to know everything about packaging.
[07:57] <gotunandan> right, thanks :)
[07:58] <ajmitch> not even persia knows all :)
[07:58]  * persia encounters unknown stuff *every day*
[08:00] <persia> OK.  7:00 and we're down to 76.  I'll blame that on the recent -classroom session, but let's get back to Patch Day!
[08:01]  * ajmitch hasn't been working on any for several hours
[08:07]  * imbrandon grabs the list-o-bugs
[08:07] <persia> We're down to one page :)
[08:09] <ajmitch> and some of the bugs have 2 tasks listed there
[08:11] <persia> Hey etretyak!
[08:12] <etretyak> persia, hi
[08:12] <persia> We're following https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow and down to 75 bugs in our current worklist.  Jump in, grab one, and ask if you have questions.
[08:13] <etretyak> ok.. let me see
[08:17] <persia> Welcome ddecator :)
[08:17] <ddecator> thanks persia =)
[08:18] <ddecator> hopefully you guys can introduce me to what patch reviewing entails this weekend. is there a wiki page i can look over?
[08:19] <persia> https://wiki.ubuntu.com/ReviewersTeam is probably a good place to start.
[08:19] <persia> https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow is the core of what we do.
[08:21] <ddecator> perfect, thanks
[08:23] <persia> Hey zus!
[08:23] <zus> persia, helllo
[08:25]  * zus waves to persia
[08:25] <persia> Did you change your mind, and are staying up to review a few patches, or just stopping by?
[08:25] <persia> Ah, the latter, I think :(
[08:27] <ddecator> how long does it take to review a patch?
[08:27] <persia> Minutes to hours, depending on the complexity of the patch, etc.
[08:27] <ddecator> if you got one that'd only take a few minutes, i can see about helping out real quick before i go to bed =)
[08:28] <persia> Sometimes we get lucky, and the patch is submitted by upsteam, so it's just a quick test and see about getting into Ubuntu.
[08:28] <persia> Sometimes we're unlucky, and the patch is confusing, does something subtle that's tricky to reproduce, and has an usptream with an irregular bug tracker with a complicated signup process.
[08:28] <ddecator> i'll let you guys handle those for now..
[08:30] <persia> Bug #527639 looks like it's not terrible.
[08:30] <ubot3> Malone bug 527639 in boinc "boinc should use chrt instead of schedtool" [Wishlist,Triaged] https://launchpad.net/bugs/527639
[08:30] <persia> Should be easy to test, and seek upstream comment.
[08:34] <ddecator> so since it's not necessarily a bug to reproduce, i just get the software, see how it works, apply the patch, and make sure it doesn't break the functionality at all?
[08:37] <ddecator> persia: ^
[08:38] <persia> Basically, yeah.
[08:39] <persia> Also, check some upstream docs on schedtool and chrt and make sure that it actually makes at least some sense (no reason to bother upstream if it's pointless).
[08:39] <persia> I suspect it does make sense because without having thought about it previously, I have chrt on my system, and don't have schedtool, but that may be coincidence.
[08:40] <ddecator> right, which seems to be the reasoning behind the suggested change
[08:40] <persia> Indeed :)
[08:41] <persia> You did ask for an easy one :)
[08:41] <ddecator> alright, so i have some more questions about what i should do exactly, but i'm afraid that'll take up too much time and i've already stayed up later than i should have, so i'll return to this patch tomorrow and ask for some help in here =)
[08:41] <persia> OK.
[08:41] <ddecator> thanks for the help persia
[08:41] <ddecator> g'night guys
[08:41] <persia> Note that someone else might grab it first though, and you'll have to get a new one.
[08:42] <ddecator> that's fine
[08:42] <ddecator> i'll watch to see what the person did in that case
[09:01] <persia> Hey RAOF.  We're almost done, but can always use a bit more on the last push :)
[09:09] <persia> OK.  75 bugs.  3 hours.  It's a push, but  possible.  Now we just need a *heap* of reviewers in the eastern pacific :)
[09:27] <persia> Hey alourie|work.
[09:58] <persia> Still 75 at 8:00 :(
[10:39] <nigelb> persia: how are we doing on the count?
[10:39] <persia> Not wonderfully :(
[10:39] <nigelb> breached 70s?
[10:40] <persia> We're down to 75, but we've been holding there for a good while now.
[10:40] <nigelb> ouch, was 79 when I left
[10:40] <persia> So it's nice to have only one page of reports, but I think not many people still find it 5th May :)
[10:41] <nigelb> well, patch day gets over in about 20 days and we can review what we did wrong
[10:41] <nigelb> I have a couple of complaints with the workflow which I need to correct
[10:41] <nigelb> I feel we should never unsubscribe ~ubuntu-reviewers unless we don't intent to review that patch at all
[10:42] <nigelb> also, I'm thinking of defering a few packages to the server folks, the ones that are too hot to handle for us
[10:42] <persia> Hrm?  80 minutes I thought.
[10:42] <nigelb> 1100 UTC is when?
[10:42] <persia> 78 minutes from now.
[10:42] <nigelb> ok, my time calculation is just broken :)
[10:43] <persia> So, my thought on unsubscription is that if we have already reviewed a bug, why do we need to stay subscribed?
[10:43] <nigelb> also we need a way for people to say, I got this, the ~ubuntu-reviewers need not get into this bug
[10:44] <nigelb> the unsub is because I'm giving other folks can option to say ^
[10:44] <nigelb> so, all the sub'd bugs would be taken care of by us, and others would be taken care of someone else
[10:46] <nigelb> great, now I have putty, my private key, but forgot to note down the ip adress and port to connect to :(
[10:47] <persia> I don't think that's a big deal: if we bump into bugs like that, we can just unsub.  It's usually fairly easy to identify when someone has it, and it's not that hard to add our tags and unsub.
[10:47] <persia> heh.
[10:48] <nigelb> yes, so we'll make a policy that we wont take of bugs that we've unsub'd
[10:48] <nigelb> so I'd rather have the others in the review queue.  anyway it wont show up in the query unless ready for re-review
[10:49] <persia> How does "ready for re-review" work?
[10:49] <persia> Especially for the patch-needswork case?
[10:52] <nigelb> we leave instruction that once you feel the patch needs another review by us, please change the patch-needswork tag to patch tag
[10:55] <persia> Oh right.
[10:55] <persia> maco: ^^
[10:58] <nigelb> i probably need to work on standard replies
[11:02] <persia> heh
[11:06] <nigelb> any other lessons from patch day?
[11:07] <persia> 10:00 and still 75 bugs.  Over to nigelb!
[11:07] <persia> We need to do better at determining what to do with Ubuntu-only packages.
[11:08] <persia> When there's no real upstream, I'm not sure how much we can help.
[11:08] <persia> Maybe that's just extending the blacklist a lot.
[11:09] <nigelb> I'd vote to blacklist packages like eucalyptus
[11:09] <nigelb> we'll just break their workflow
[11:10] <persia> And stuff like apport/mountall/casper/ubiquity/etc. as well?
[11:11] <nigelb> yep, especially stuff maintained by folks at canonical
[11:11] <nigelb> they are being paid to do it, we're better off helping the packages that noone cares about
[11:12] <persia> I disagree with that.  I don't see how it matters whether it's being maintained by folks at Canonical: I think it matters more whether it's being maintained *in* Ubuntu.
[11:13] <persia> So, there's folks at Canonical who maintain a bundle of packages and do most of their uploads to Debian, etc.  They might use the package in Ubuntu, but ae normal upsteams in that they don't tend to use distribution-provided packages.
[11:13] <nigelb> yeah, well, they tend to sort of coincide
[11:13] <persia> And there's package in Ubuntu, like ubuntustudio-controls, that aren't maintained by folks at Canonical, but have no sensible separate upstream.
[11:14] <nigelb> we ignore those is what I'm saying
[11:14] <nigelb> the ones that are always uploaded to ubuntu
[11:14] <persia> Sure, but I think we should focus on stuff where upstream maintains it in Ubuntu, rather than anything else.
[11:15] <persia> whereas something like python-lazr.uri would work fine with our regular process.
[11:15] <persia> (or maybe that wasn't the best example, but you get the idea)
[11:16] <nigelb> its extremely subjective, we'e better off having a wiki page were folks can suggest the ones we can *potentially* ignore and then take a call
[11:17] <persia> That sounds ideal: let's have a wiki page and invite developers who maintain their packages *in Ubuntu* and don't want us pushing patches upstream to add their packages there.
[11:17] <persia> That makes it opt-in on a per-developer/per-package basis.
[11:17] <persia> And nicely avoids all the social discussions :9
[11:17] <persia> :) !
[11:17] <nigelb> yes, better than them coming screaming at us
[11:19] <nigelb> ok, so graphs, changes to workflow, standard replies, and page for developers to opt-out
[11:19] <persia> Well, if we have a wiki page, and we announce it to ubuntu-devel@, then if folks come screaming, we can point at the wiki page and the email, and ask them why they don't read their mail :)
[11:19] <nigelb> exactly!
[11:23] <nigelb> Anything else hit you we're doing wrong?
[11:24] <nigelb> Did we advertise too less about patch day? :/
[11:24] <persia> I think we did fairly well.
[11:24] <persia> 110+ patches reviewed.
[11:24] <nigelb> It would be very intersting to see the patch review mailing list, especially the moderation to see how many people participated
[11:25] <nigelb> all the bug mails would be stuck in moderation.  I have to ask brian to give me a tar or something of all the mails over last 2 days
[11:25] <persia> I think we also need to work on integration with bugsquad more.
[11:25] <persia> I saw someone in bugsquad suggest subscribing us and adding the patch tag as the way to triage a bug with a patch.
[11:25] <nigelb> woot, yes it is :)
[11:26] <persia> But I'd rather be more integrated, so that folks upstreaming bugs know about our tags, and we make sure we do the right upstreaming stuff when we forward our patches.
[11:26] <nigelb> raise it at the next bug squad meeting?
[11:26] <nigelb> its after UDS anyway
[11:26] <persia> Sounds like a good plan.
[11:27] <nigelb> during UDS you can say how successful Patch day was ;)
[11:27] <persia> and make sure the upsteaming docs point to our docs about tags when also sharing patches and make sure our docs point at the upstreaming docs as best practice when opening upstream reports, etc.
[11:27] <nigelb> our docs point to upstream docs
[11:27] <nigelb> *upstreaming
[11:28] <persia> Sure, but let's make sure we *preserve* that as we update our docs :)
[11:28] <nigelb> yes, the docs need extensive revision, including how to test
[11:28] <persia> We're an interesting mix of triagers and developers (and folks who are both), and I'd like to not end up with too much of a separate identity.
[11:28] <persia> Patch review should be something people do, not something people are.
[11:29] <nigelb> did I tell you the statistic I had come up with?
[11:29] <nigelb> 1800 bugs with patches attached, out if which 1500 will be in our queue if there were no date thingy.  If all the members of ~ubuntu-dev reviewed 10 bugs, we'd be done!
[11:30] <nigelb> there were 153 members of ~ubuntu-dev when I last checked
[11:31] <nigelb> if everything comes together, patch review, adopt-an-upstream, bug triage, it would be the most awesomest!
[11:31] <persia> Yeah.  It's not hard to review all the patches.  Folks just aren't doing it.  That's why we needed this initiative.
[11:32] <nigelb> Yep.  I'm deeply saddened by that.
[11:32] <nigelb> But, also happy that in 1 month, we could get going so fast.
[11:33] <nigelb> This cycle, I'd like to explore the possibility of us being the new starting point for development, though I'd advocate uploads to debian than Ubuntu to reduce the delta.
[11:33] <persia> I don't think any model that involves the starting point for development is good.
[11:33] <persia> I'd rather consider us *a* starting point.
[11:34] <nigelb> Well, yeah *a* starting point, especially to budding triagers
[11:34] <nigelb> People who are well versed with bugs and want to start thinking of packaging stuff
[11:34] <persia> And I think that work in this team is a close match to a lot of MOTU work, so it makes a good "next step" for bug control folks vaguely wanting to do more development, but without any close association with one of the development teams (e.g. desktop, server, kubuntu, mythbuntu, etc.)
[11:35] <nigelb> yep, lost folks like me ;)
[11:35] <persia> Right.  I think we're thinking the same, except for the "a"/"the" bit :)
[11:35] <persia> I don't like to think we're lost, so much as we're more interested in fussing with random stuff than focusing on anything specific.
[11:35] <nigelb> yea, I agree with the 'a' too
[11:36]  * persia tends to focus first on anything that is irritating when using Ubuntu installs, and then on various unloved pacakges.
[11:37] <persia> At least, for me, if someone is caring for a package, they tend to do a good enough job that I'll end up being lazy, rather than fixing it.  If nobody else is watching, then I'm more likely to be annoyed and just fix it.
[11:37] <nigelb> Desktop team likes us taking care of patches, so far they're happy that we're pointing out stuff that work
[11:38] <nigelb> But I'd defer mozilla stuff to somene from the team since they take good care of them
[11:38] <nigelb> Also, most of the patches tend to turn up in unmaintained stuff since no one maintaines those pacakgse
[11:39] <nigelb> People get annoyed and fix the bug.
[11:39] <nigelb> And we ignore them.
[11:40] <nigelb> We're down to 74, I guess you're reviewing.
[11:43] <persia> I must run: good luck with the end of the day.  I think we made great progress, regardless of the counts, just from the number of folk who came by the channel and read the docs, and had some practice doing it.
[11:43] <nigelb> persia: I'm stepping out for some chores too. :)
[11:44] <nigelb> persia: shall I delcare patch day officially over?
[11:44] <nigelb> another 15 mins to go, but I have to run
[11:44] <persia> If you have to run, unless you can get someone else, yeah.
[11:44] <persia> 111 bugs done!
[11:44] <persia> Actually more, because we got some new ones (the count went up a couple times)
[11:45] <nigelb> Patch Day is officially over.  Thank you Review Leads for your help.  Those who reviewed patches, thank you for your time.
[11:45] <nigelb> We have reviewed 111 bugs in the last 50 hours!
[11:45] <persia> 49 :)
[11:46] <nigelb> 48-3/4 ;)
[11:46] <persia> We hit 61% of our target queue.
[11:46] <nigelb> Which is really really good news
[11:46] <persia> Which isn't bad for a first time.
[11:46] <nigelb> now, I think we can move that date 1 month back
[11:46] <nigelb> and plan for regular patch days
[11:46] <nigelb> no wait, scratch regular patch days
[11:46] <persia> Every month?
[11:47] <persia> Yeah, let's not have them for a while.
[11:47] <nigelb> we need something to encourage every day review, like 5-a-day
[11:47] <persia> Let's have sporadic patch days on an as-needed basis until we get a feel for how the team works.
[11:47] <persia> and if enough folks want to have a special Patch Day! we can do that.
[11:47] <nigelb> yes, when we get dangeoursly high, for now lets just keep things in 2 digits :)
[11:48] <persia> That makes sense to me, but let's not worry so much about next week, as lots of folks will be paying attention to UDS.
[11:48] <persia> With luck, we won't get so many patches, but I expect a bit of backlog :)
[11:48] <nigelb> persia: yes, and do tell them about the 10 patch per head thing and the 111 that me manged :)
[11:49] <nigelb> *we
[11:49] <persia> Really, UDS doesn't work that way: there's no good way to do announcements.
[11:49] <nigelb> plenary?
[11:49]  * persia is *not* going to try to schedule a plenary about Patch Day
[11:49] <nigelb> lol, ok
[11:49] <nigelb> just mention that in the session
[11:50] <persia> Best is just to send mail to the developer and bugsquad mailing lists, saying what was done.
[11:50] <nigelb> Yes, that's a good idea
[11:50] <persia> That ends up getting mirrored all over the place
[11:50] <nigelb> The fridge can re-post *that* one
[11:50] <persia> Anyway, really have to go :)
[11:50] <nigelb> ok, ciao
[12:21] <vish> aw.. i did probably only around 5 :(
 We need to do better at determining what to do with Ubuntu-only packages. <--- subscribe sponsors?
[12:29] <yofel> would be fine, but only after we convert it into a debdiff
[12:29] <yofel> (IMHO)
[12:31] <yofel> I saw bugs where the sponsors were subscribed, didn't find a debdiff, unsubscribed themselved and subscribed us
[12:31] <maco> which they're not supposed to do
[12:32] <maco> the debdiffs-only stuff was supposed to have gone out a year or two ago
[12:32] <yofel> hm, I didn't check the dates on the posts
[12:33] <vish> maco: recent bugs too its being done
[12:35] <yofel> well, packaging the patch included reviewing it so it makes sense in some way
[12:35] <yofel> *includes
[12:35] <maco> "check it before you upload" has always been part of the sponsor's job
[12:35] <maco> even if it's a debdiff, they're still supposed to check it out!
[12:36] <yofel> true
[12:36] <vish> hrm , if the patch has been forwarded upstream do we unsubscribe te review team?
[12:36] <vish> the*
[12:37] <yofel> is says so on the workflow, you're supposed to subscribe yourself and follow the bug after that
[12:41] <vish> yofel: Bug #40872 , nigel has subscribed himself, i think we can remove the review team..
[12:41] <ubot3> Malone bug 40872 in nautilus "Desktop icons are allowed to overlap" [Unknown,Confirmed] https://launchpad.net/bugs/40872
[12:41] <yofel> true, work is done
[12:48] <persia> So, patches for ubuntu-local stuff fals into an annoying gap.
[12:49] <persia> Sponsors *aren't* supposed to upload anything that isn't a ready candidate, and *are* supposed to be all sorts of picky to help train nascent developers.
[12:49] <persia> But we're not even especially focused on getting stuff into Ubuntu.
[12:50] <persia> The thought was to blacklist the Ubuntu-local stuff from the script that fills the review queue, and then expect whoever maintains the package to process the bugs once in a while.
[12:50] <persia> (where "whoever maintains" might be some random Ubuntu developer passing by, depending)
[12:51] <persia> That said, there's no reason that any of us *can't* turn a patch into an upload candidate in any of several ways, but that it's not the main goal of the team.
[12:55] <yofel> hm, about bug 546032 - I did use reportbug a few times already, but never supplied patches, and I don't get how submittodebian works, can I just use reportbug with the patch tag and supply links to the patches in the bug description?
[12:55] <ubot3> Malone bug 546032 in tcsh "[PATCH] tcsh-6.14.00-astron $COLUMNS $LINES not set" [Undecided,New] https://launchpad.net/bugs/546032
[12:56] <persia> I usually attach the patch in an email to the BTS.
[12:56] <persia> I'm not sure how reportbug does it.
[12:56] <yofel> well, reportbug is a cli app that creates a mail, but you're right, just sending a mail directly would be easier I guess
[12:58] <persia> yofel: reportbug has a -A option that lets you attach something, so you could use that.
[12:59] <yofel> ah, you're right, thanks
[12:59] <persia> Just be sure to add the patch tag if you sdo.
[12:59] <persia> manpages are wonderful :)
[13:01] <yofel> yep, I did check it, too fast it seems :P
[14:08] <nigelbabu> maco: UUD can be taken at UDW
[14:08] <nigelbabu> err UDD
[14:11] <hyperair> nigelbabu: so how did patch day go overall?
[14:12] <nigelbabu> hyperair: 111 patches reviewed
[14:12] <hyperair> woo
[14:12] <hyperair> that's a lot
[14:12] <hyperair> it's now down to one page \o/
[14:12] <nigelbabu> yes, thanks a lot for the tme that the review leads put in
[14:12] <nigelbabu> I intend to write a mail, now sleep time
[14:13] <vish> nigelbabu: hey ,any reason we you've left the team still subscribed to  Bug #40872
[14:13] <ubot3> Malone bug 40872 in nautilus "Desktop icons are allowed to overlap" [Unknown,Confirmed] https://launchpad.net/bugs/40872
[14:16] <nigelbabu> vish: Its reviewed, see tags
[14:16] <nigelbabu> the review team will not be unsub'd ever unless they dont want us playing with the bug
[14:17] <nigelbabu> I'll change the docs as soon as I'm sane and conscious
[14:17] <vish> nigelbabu: yup ,the docs wasnt clear... hence, was wondering if the team needs to be un-sub'd there..
[14:18]  * persia has been unsubbing from everywhere, and wonders why we bother to have sub/unsub at all if we're not unsubbing to drop from the workqueue
[14:18]  * hyperair did the same as persia
[14:18] <nigelbabu> vish: I realized the hole in the docs only today.  Its my mistake
[14:18] <nigelbabu> Just to make it clear.  Do *not* unsub reviewers unless they dont want us poking in
[14:19] <nigelbabu> persia can explain further on that or you can read scroll back
[14:19] <hyperair> =\ i don't even remember which bugs i unsubbed reviewers from
[14:19] <nigelbabu> we talked about it 2 hours back
[14:19] <nigelbabu> hyperair: dont worry, we can find with tgas :)
[14:19] <hyperair> heh okay
[14:20] <nigelbabu> I'll do that next week, though I may have to run a huge LP query through api
[14:21] <nigelbabu> persia: can follow up with lool about the MIR? I need sleep and rest
[14:21] <persia> I can't explain, because I don't see the point (but I'm sure nigelbabu will explain better later)
[14:21] <persia> Which MIR?
[14:22] <nigelbabu> bug 525512
[14:22] <ubot3> Malone bug 525512 in libtime-modules-perl "[MIR] libtime-modules-perl" [Undecided,New] https://launchpad.net/bugs/525512
[14:22] <nigelbabu> but 525395 is blocked due to this
[14:22] <yofel> so instead of usubbing reviewers remove the patch tag? or just add the tags?
[14:22]  * persia doesn't like MIRs are part of not liking components, but isn't prepared to ignore components completely yet
[14:22] <nigelbabu> yofel: just change the tag according to situation
[14:22] <persia> nigelbabu: And the query already hides stuff with the right tags?
[14:23] <nigelbabu> persia: yes it does
[14:23] <nigelbabu> the unsub was part of workflow when I didn't know that
[14:23] <nigelbabu> brian explained it to me that day, that meeeting we had
[14:24] <persia> OK.  I'm not sure there's any benefit to any of subscription/unsubscription/even having a team in LP if we're not actually using it.
[14:24] <yofel> k, so change the tag (and leave only one) and leave team subscribed, right?
[14:24] <nigelbabu> yofel: yes
[14:24] <yofel> ok
[14:24] <nigelbabu> persia: having the team sub'd gives option to others not to have us meddle
[14:25] <yofel> I'll try to fix the bugs I still find in my inbox later
[14:25] <persia> How?
[14:25] <hyperair> nigelbabu: but other people can't unsub us.
[14:25] <persia> But explain it to be when you've slept.
[14:25] <persia> I'm sure I'll disagree then too, but we can have a productive debate :)
[14:25] <nigelbabu> persia: when there is a bug a and there is a very responsible person taking care of it
[14:25] <vish>  IMO , unsubscribe if someone takes up the bug..
[14:25] <nigelbabu> vish: no
[14:25] <hyperair> launchpad api again \o/
[14:25] <hyperair> nigelbabu: go sleep =p
[14:25] <nigelbabu> what if that person "gets hit by a bus"
[14:26] <nigelbabu> hyperair: good idea
[14:26] <nigelbabu> I should
[14:26] <hyperair> =)
[14:26] <vish> nigelbabu: i meant , if forwarded upstream..  , but not very sure the current flow is good though
[14:26] <persia> nigelbabu: Do.  I'm fully prepared to debate this with you another day.
[14:26] <hyperair> count me in.
[14:26] <vish> lol!
[14:26] <yofel> me too
[14:26] <nigelbabu> vish: we still want it on the list, later, sleep is overtaking me
[14:27] <persia> nigelbabu: And I think you've been pinging lool sufficiently for 525512: I'll pay attention and say something if necessary whist you sleep, but it may just be a matter of time.
[14:27] <nigelbabu> persia: most probably, only if he asks something you feel I wont be able to answer :)
[14:27] <nigelbabu> persia: and I dont want to wait for 24 hours to finish a conversation ;)
[14:27]  * nigelbabu goes before someone kicks me out
[14:28] <persia> I think it's 99% a matter of waiting for him to have time, which means it's probably not going to happen until post-UDS.
[14:28] <nigelbabu> im just reminding, btw vish had you assigned a bug to me? I vaguely remember a mail
[14:28] <yofel> hm, a patch attached and issue already fixed upsteam in a different way would be patch-rejected-upstream?
[14:29] <yofel> bug 542185
[14:29] <ubot3> Malone bug 542185 in qt4-x11 "holdingnuts GUI badly affected by a bug in Qt 4.6.2" [Medium,Triaged] https://launchpad.net/bugs/542185
[14:29]  * persia looks
[14:29] <vish> nigelbabu: the cheese bug?
[14:29] <vish> nigelbabu: wasnt that what we discussed the other day?
[14:29] <yofel> upstream patch: http://qt.gitorious.org/+kde-developers/qt/kde-qt/commit/1ab5feb6260589f254ed209816cb67dbe9d3e4a5
[14:31] <persia> Yeah, that'd be patch-rejected-upstream, but it's worth adding a comment that this tag is used to denote the case where a patch doesn't match upstream changes perfectly, so that we know it has to be an Ubuntu-local adjustment, etc.
[14:31] <yofel> ok, thanks for confirming
[14:31] <persia> I'm not certain that all patch authors would understand this use of "rejected" (which isn't quite right) without explanation.
[14:32] <yofel> indeed
[14:32] <persia> But I'm not sure what other tags correctly toss the bug into the right "bucket": specifically the set of stuff that needs a developer to apply in Ubuntu directly.
[14:33] <vish> persia: i see one problem though , once we unsubscribe the team , the person who takes over must fully respond to the bug .. or we need to draw a line where the reviewer work ends.. if the bug patch is redone after 2-3 months what is the procedure then? if the person subscribed has gotten busy and is not looking at bugmail?  who's task is it to check the patch then?
[14:34] <persia> vish: I don't think whether the team is subscribed or not makes any difference in that case.
[14:35] <persia> I think we'd do better to define a set of states in our patch management workflow, and then focus on moving patches between these states in various ways.
[14:35] <persia> subscription/unsubscription is one tool that could help with that, because it lets us set a match criteria for LP queries (and in a way that *dosen't* send bugmail).
[14:36] <persia> But just because the team is subscribed doesn't mean anyone will ever look at the bug.
[14:36] <vish> persia: yup no bug mail , but in that case , having the team subscribed might ensure the bug gets a second look ,... but still the current workflow isnt perfect though , this makes
[14:36] <vish> s/this makes/  /
[14:36] <persia> do a search sometime on all the bugs assigned to MOTU.  Every single one of those is wrong, and nobody has ever used that query to find work to do.
[14:36] <persia> Why would it get a second look?  If it doesn't show in the queries on the reviewing guide page, it's not likely to be looked at, regardless of anything else.
[14:38] <vish> persia: if the team is subscribed it could be looked again , but the tags would be misleading.. which is kinda wrong , what we need is the re-tagging to work properly and automatically ,once a new patch is submitted ,the old patch must be auto removed and subscribing the team then would probably work
[14:39] <vish> s/old patch/old tag/
[14:39] <persia> vish: *why* would it be looked at again?  Who would look at it?
[14:39] <yofel> is the mail that the review team gets as a launchpad group sent somewhere or to /dev/null ?
[14:39] <persia> And how would the result differ from e.g. a query againt the "patch" tag?
[14:39] <vish> right..
[14:39] <persia> yofel: It goes to an LP mailing list that is subscribers-only, so most stuff ends up in a moderation queue, and is dropped summarily.
[14:40] <persia> vish: My point is not that the current system is correct.  My point is that there's no inherent value to subscription, unless subscription is used to define a query that is used as a workqueue.
[14:41] <vish> +1
[14:41] <persia> Well, and also that it has no more or less value than any other change we make to bugs to define a workqueue.
[14:41] <yofel> ah, if there was some way to access it I think it would make sense to leave the team subscribed, but from my point of view I would vote to unsubscribe the team currently
[14:41] <vish> persia: currently the workflow is kinda what anyone can do , there is no need for a specific team :s
[14:42] <yofel> +1
[14:42] <persia> Well, unless we use subscription/unsubscription as a way to manage workqueues.  We currently do, in that we only have the team subscribed to a subset of the available bugs, so as to focus on quick response to current patches, rather than too much on older patches.
[14:43] <yofel> only team members can unsubcribe the team, which means that if we don't require that we don't really get to review newcomer work as they have no reason to contact us
[14:43] <persia> I'd say that the vast majority of the patches we reviewed during patch day were submitted in the last couple months, which is good.  If a patch has already sat around for a year, we already look bad, and it's not worth missing new ones to try to clean them up until we're ahead of ourselves with the new ones.
[14:44] <persia> yofel: Indeed, which is one of the reasons I *like* having unsubscription be part of the workflow: it encourages a member of the team to review all work by non-members until someone shows they know what they are doing, and can be made a member.
[14:44] <persia> (as our current requirements for membership are basically: someone says "Yeah, this person is good at it).
[14:45] <yofel> yeah, and about an hour to fulfill the bugsquad requirements
[14:47] <persia> and a week to get approved :)
[14:49] <yofel> unless somone doesn't use the desktop bugs team as a loophole yes
[14:50] <yofel> as that gives you an indirect membership
[14:52] <persia> There are lots of loopholes :)  But yeah.
[14:53] <persia> The point of the requirement is basically that we didn't want to have to explain basic bug triage stuff also in the reviewers docs.
[14:54] <persia> Oh, and that most of the tasks end up being very similar to triage tasks, so it's helpful to have that background (in any of the *many* ways in which one can get it).
[14:54] <yofel> true


[18:53] <tomreyn> hi. i'm creating this page https://help.ubuntu.com/community/EOL and am trying to understand how long Ubuntu Kylin 18.04 will be supported.
[18:53] <tomreyn> Neither http://www.ubuntukylin.com/news/shownews.php?lang=en&id=761 (nor its chinese counterpart) nor https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes/UbuntuKylin seem to state so.
[18:55] <tomreyn> https://wiki.ubuntu.com/XenialXerus/ReleaseNotes/UbuntuKylinChinese also does not seem to say so.
[18:55] <tomreyn> Thanks in advance!


[21:59] <juzzy_> HELP! all my file folder try to open with gedit text editor!
[22:00] <pleia2> juzzy_: this channel is for developing class materals for ubuntu
[22:00] <pleia2> I see you asked in other channels at the same time too, so you'll probably have better luck there
[22:01] <juzzy_> cheers


[00:07] <brokendatapoint> knock knock
[01:20] <Atamira> no ones home brokendatapoint :P
[08:33] <phonex01>  i'm trying to install tor-proxy and i have this error ? W: Failed to fetch http://deb.torproject.org/torproject.org/dists/maverick/Release.gpg  Got a single header line over 360 chars
[08:57]  * ajmitch wonders why people don't stick around for answers
[09:15] <Atamira> always in a hurry
[23:00] <brokendatapoint> morning
[23:31] <Atamira> afternoon


[08:10]  * apw yawns
[08:11]  * cking offers apw coffee
[08:12]  * apw looks at the kettle, seems its tea for now, the coffee grinder is just toooo noisy to deal with this early in the morning
[08:12] <infinity> I think small town living is getting to you.
[08:13] <infinity> A coffee grinder at 9am is nothing compared to jackhammers outside at 6 in a real city.
[08:15] <apw> infinity, oh so very true, so very very true
[08:15]  * infinity can't wait to move back downtown next month.
[08:16] <infinity> Something about the complete lack of street noise out in the suburbs just amplifies ten-fold the one car that DOES drive by at 3am.
[08:19] <apw> yeah that is true you need either silence, or a constant drone
[08:19] <apw> though you could just fire up leviathan and get the same effect no ?
[08:19] <cking> either stick your head in a complete vacuum or inside a server, either suffice
[08:24] <infinity> apw: leviathan is right next to my ear, though, not quite the same as street noise.
[08:24] <infinity> (This, too, will change when I move)
[08:24] <apw> infinity, and if i make it compile a nice kernel for you to get a bit more variablility?
[08:25] <infinity> Heh.  Are you hinting that you need the machine?
[08:25] <infinity> I thought you were all done being nice to flavours for this cycle.
[08:28] <apw> heh no don't need it
[08:28] <apw> i was just trying to help you sleep
[08:29] <infinity> Too kind.
[08:31] <infinity> apw: Is there another kernel coming before release, or are we shipping with what's in the archive?
[08:32] <apw> infinity, we have a pending fix for confinment which i believe needs to go in, i should have it shortly for testing with a view to getting it in today
[08:33] <infinity> apw: Alright, cool.  Hopefully, small and testable fix(es) only from here out, unless we're doing a full SRU-style validation.  Don't want any unexpected regressions before release day.
[08:34] <apw> infinity, yep i will confirm, but this is eminently testable, and will be pounded i am sure, and the other bits which come with have been validated already and are hyper-v specific
[08:35] <infinity> Mmkay.
[08:35] <apw> sadly many of the hyper-v flaws prevent boot so are not handleable as a day0
[08:37] <apw> infinity, oh i lie the hyper-v bits mostly made the last upload, so its thiner than i thought
[08:37] <infinity> Even better.
[08:38] <infinity> apw: Did you catch my prattle in /msg over the weekend about dropping some build-deps for headers-only arches?
[08:38] <apw> infinity, it is possible that that is sitting in /msg on my other machine (i am remote right now)
[08:39] <apw> so if you want to paste it back to /msg that'd work
[08:40] <infinity> Assuming a headers-only build doesn't need things like libdw-dev, libelf-dev, etc, it would be nice to arch-restrict those to only the arches that actually build kernels/tools.
[08:40] <infinity> Perhaps we should test this theory before we break anything.
[08:40] <infinity> (This is motivated by elfutils being broken on arm64 right now, and my wanting to actually build the headers correctly in the archive from the linux source package)
[08:41] <infinity> apw: If you hold off on your upload until after I've had a nap, maybe we can pick this up in the morning, and I can do some test builds on real hardware.
[08:41] <apw> infinity, sure, i expect tim will be point on uploading tonight, or me in the am
[08:42] <infinity> apw: Alright, well pass along to Tim that I'd like to hold off for this change too, then. :P
[08:43] <infinity> Or maybe I'll find the brainpower and/or motivation to hunt down why elfutils hates me tomorrow.
[08:43] <infinity> But I dunno.
[08:43] <infinity> Still seems silly to install build-deps one doesn't need for a header-only build.
[08:47] <apw> infinity, so that'd be for powerpc i assume
[08:49] <infinity> apw: arm64, powerpc, x32, ppc64el
[08:50] <infinity> apw: The inverse is easier to express, in that you only need certain build-deps on [amd64 i386 armhf] until other arches also build kernels/tools.
[08:51] <apw> infinity, yeah makes sense, it would be nice if you could have 'includes' for things like that
[08:51] <apw> Build-dep-<random keyword>: stuf
[08:52] <apw> Build-depends: Build-depends-<random keyword> [i386] sort of thing
[08:52] <infinity> apw: The whole deb-profile stuff (when done) sort of caters to this, though these aren't really build profiles.
[08:53] <infinity> apw: It's not uncommon, though, for build-deps to be autogenerated based on smarter lists (see d-i's control file, for instance, which is self-regenerating madness)
[08:55] <jjohansen> cking: try pulling from the tree now
[08:55] <infinity> apw: Would be cute if you could hook it into the do_* targets somehow, but parsing that out to magically divine build-deps sounds painful.
[08:55] <cking> jjohansen, thanks
[08:55] <infinity> apw: (Since you have some build-deps that are generic, some just for kernels, some just for tools...)
[08:56] <apw> infinity, yeah indeed, it would be nice to have at least # Build-depends-tools: <list>
[08:56] <apw> in there so _we_ know which are added why
[08:57] <infinity> apw: Anyhow, engineering something fancy is probably out of scope for what will (hopefully) be the last upload in saucy.  But I'll play in the morning with getting a diff to arch-restrict a few build-deps to make headers-only builds more lightweight.
[08:58] <apw> infinity, sounds great, as it is low risk
[09:02] <infinity> zequence: Thanks for the SRU kernels, BTW.  Everything's built and copied to -proposed now.
[09:16] <zequence> infinity: cool
[09:17] <zequence> I'm off to the dentist soon again. Pain meds aren't helping anymore.
[09:18] <zequence> Wisdom teeth aren't all that wise, evolutionary-wise
[09:19] <infinity> zequence: I had mine done at 15.  My condolences for doing it as an adult.
[09:19] <infinity> zequence: At least you have an excuse to be whiney for a few days.
[09:33] <apw> zequence, ouch, you have my sympathy
[09:46] <zequence> Might have melted some stiches by drinking rum the same day as the operation. So, I should probably just blame myself - or the dentist. Not sure yet :P
[12:36]  * henrix -> lunch
[13:06]  * apw runs for home ...
[13:36] <sforshee> rtg: is there any reason to have the CONFIG_ANDROID options enabled in our non-touch kernels?
[13:37] <sforshee> rtg: I ask because of bug #1235161
[13:37] <ubot2> Launchpad bug 1235161 in linux (Ubuntu) "lowmemorykiller killing processes when swap still available" [Undecided,Confirmed] https://launchpad.net/bugs/1235161
[13:39] <rtg> sforshee, hmm, lemme check
[13:43] <rtg> sforshee, how about CONFIG_ANDROID_LOW_MEMORY_KILLER=n ?
[13:44] <sforshee> rtg: I definitely think that's what we should be using, but I'm wondering if we should go a step further and do CONFIG_ANDROID=n
[13:45] <rtg> sforshee, I was just looking at the other android staging bits. though most of them are built in, they don't really do anything unless prodded (so far as I've looked)
[13:46] <sforshee> rtg: indeed, the rest probably are mostly harmless
[13:47] <sforshee> I'm not so sure about including binder support however
[13:47] <rtg> sforshee, alarm-dev seems a bit more proactive....
[13:49] <rtg> sforshee, can you think of any possible use folks might have for these android bits ? they _are_ staging. as such, they are also subject to abrupt termination.
[13:50] <rtg> or removal
[13:52] <sforshee> rtg: not outside of the touch images. I'm sure people _could_ find uses for them, but I'd think it unwise to become reliant on them for sure.
[13:53] <sforshee> rtg: my inclination is towards CONFIG_ANDROID=n, but at minimum the lowmemkiller should be disabled. It needs active management by userspace to be useful, afaict.
[13:54] <rtg> sforshee, agreed (about ANDROID=n). I'm whipping up a patch and test build...
[13:56] <sforshee> rtg: ta
[14:08] <nessita> jsalisbury, hey there, you around? have some minutes?
[14:08] <rtg> sforshee, patch sent
[14:09] <sforshee> rtg: ack
[14:10] <nessita> jsalisbury, regarding bug #1201528 (I was on a leave for 2 weeks so I'm catching up with it): not sure where to get kernel 3.11.0-7 from, on my saucy installation I have 3.11.0-11-generic, and on the precise installation I'm not sure where to install it from (I can not find 3.11.0-7 on http://kernel.ubuntu.com/~kernel-ppa/mainline/)
[14:10] <ubot2> Launchpad bug 1201528 in linux (Ubuntu Saucy) "[INTEL DP55WG,Realtek ALC889] - Audio Playback Unavailable" [Medium,Incomplete] https://launchpad.net/bugs/1201528
[14:10] <nessita> I guess I will leave a comment in the bug report
[14:16] <nessita> jsalisbury, replied to the bug report, now I need to reboot because audio playback broke while testing the latests kernel with mumble :-)
[14:36] <jsalisbury> nessita, I'll checkout the bug comment
[14:36] <jsalisbury> nessita, No need to test 3.11.0-7 anymore, since there is a newer kernel.  Just confirming the bug still exists in the latest saucy kernel is good enough.
[14:36] <nessita> jsalisbury, perfect, already did
[14:37] <jsalisbury> nessita, thanks.  I'll post the next test kernel to test in the bug.
[14:38] <nessita> jsalisbury, awesome. Is there any way you could post a list of ~5 kernels to test? is easier for me to do so in batch, since I need someone else on mumble to chat with me to ensure proper testing
[14:38] <jsalisbury> nessita, sure
[14:39] <nessita> thanks!
[14:40] <jsalisbury> nessita, if we end up having to bisect further, that would only give us one kernel at a time to test though.
[14:41] <nessita> jsalisbury, no problem
[16:19] <rtg> jsalisbury, if you haven't already seen it, please work with the reporter on bug #1234662 and build him some test kernels.
[16:19] <ubot2> Launchpad bug 1234662 in linux (Ubuntu) "Ubuntu-lts-3.8.0 kernels corrupt ext[234] filesystems with 1k block size in Xen guests" [High,Confirmed] https://launchpad.net/bugs/1234662
[16:19] <xnox> Is there any general advice w.r.t. debugging kernel panic? "Unable to handle kernel paging request at virtual address c02fabe4 pgd = d5e24000" bug #1236444
[16:19] <ubot2> Launchpad bug 1236444 in linux-goldfish (Ubuntu) "kernel panic" [Undecided,New] https://launchpad.net/bugs/1236444
[16:19] <xnox> ?
[16:21] <rtg> xnox, ow!
[16:21] <xnox> rtg: i know that apparmor triggers it (disabled) later, "Setting up X socket directories..." triggers it.
[16:22] <jsalisbury> rtg, I pinged kamal about that bug on Friday.  It seems that commit can't be backported very easily to 3.8, which is why it wasn't picked up from stable.
[16:22] <xnox> rtg: there are vague hints online that compiling with 4.7 helps (instead of 4.8) but we already do that.
[16:23] <jsalisbury> rtg, there is some history in #stable-kernel
[16:23] <rtg> xnox, actually, I'm using 4.6 on several of the Nexus kernels.
[16:23] <rtg> jsalisbury, ack
[16:25] <rtg> xnox, maguro, manta, and grouper
[16:26] <xnox> rtg: what cross-prefix should I be using when cross-compiling goldfish? arm-linux-gnueabihf-, or CROSS_COMPILE=arm-linux-gnueabi-, or something else?
[16:26] <xnox> rtg: or can you compile with 4.6 and give me the deb somehow, for me to try it?
[16:26] <rtg> xnox, yeah, gimme a min or 2
[16:27] <jsalisbury> rtg, commit b764915 was cc'd to stable, but it doesn't look like it was picked up in any of the stable branches.
[16:28] <jsalisbury> rtg, except 3.10
[16:28] <rtg> jsalisbury, ok, just note it in the bug report I guess.
[16:28] <jsalisbury> rtg, ack
[16:29] <xnox> rtg: cool.
[16:40] <rtg> xnox, http://kernel.ubuntu.com/~rtg/linux-image-3.4.0-1-goldfish_3.4.0-1.7_armhf.deb - Note that this has patches from jjohansen that fix socket containment.
[16:44] <xnox> rtg: better. Let me re-enable apparmor, and reboot again.
[16:47] <rtg> xnox, better, as in no crashes ?
[16:53] <xnox> rtg: yeap, all is perfect with http://kernel.ubuntu.com/~rtg/linux-image-3.4.0-1-goldfish_3.4.0-1.7_armhf.deb
[16:54] <xnox> rtg: all init succeeded, all android lxc container finished booting, system is stable and works for >> 2 minutes
[16:54] <rtg> xnox, so, the question is was it the compiler or jjohansen's patches. do you have time to try another deb built with gcc-4.7 ?
[16:54] <xnox> rtg: yeap, I have time to try another deb.
[16:54] <rtg> xnox, ok, 10 mins
[17:13] <kamal> jsalisbury, hey did you ever get any response from anyone re: your patch "Input: cypress_ps2 - Return zero finger count if palm is detected."
[17:15] <xnox> rtg: I need to go, ping me URL to the new kernel, when ready. And i'll test it when I get back.
[17:17] <rtg> xnox, http://kernel.ubuntu.com/~rtg/linux-image-3.4.0-0-goldfish_3.4.0-0.7_armhf_gcc47.deb - Note this is a downgrade from the previous kernel (ABI change)
[17:30] <xnox> rtg: panics.
[17:31] <rtg> xnox, dang compiler then
[17:31] <xnox> rtg: =(
[18:43] <jsalisbury> kamal, I didn't get any response from upstream, but I'll ping them again or see if it was accepted.
[18:44] <kamal> jsalisbury, if you haven't heard back, then it probably hasn't been ... yes, I recommend pinging dmitry and rydberg
[18:48] <jsalisbury> kamal, ack
[20:21] <apw> rtg, did i see compiler issues with arm for goldfish?
[20:23] <apw> we did get a new compiler this week, arm changes only
[20:24] <apw> i know jj wont see it quite like that :)
[20:24] <apw> bah
[20:59] <rtg> apw, yeah, I rebuilt with gcc-4.6 and all of xnox's problems seemed to go away.
[21:13] <rtg> apw, I pushed a patch to change the armhf compiler for goldfish
[21:28]  * rtg -> EOD


[00:24] <clay> hey Im trying to use cloud init to setup a physical server, and am trying to use the dmi variable sub to specify metadata. I realized the cloud init thats running is v22.2, how can I make cloud init update before accessing the seedfrom url to have dmi variable substitution work?
[00:27] <claycovariant> hey im trying to use cloudinit to setup a physical server, how can i choose which cloud init version im running? Im trying to install jammy LTS
[00:31] <minimal> "how do I choose which cloud-init version"? What are you booting on the physical machine? Are you trying to add a cloud-init package AFTER booting the machine?
[00:33] <minimal> cloud-init is designed to run on 1st boot to do initial configuration
[00:33] <claycovariant> im using pxe boot to boot the physical machine passing in a command line with `vmlinuz autoinstall ip=dhcp auto=true cloud-config-url=/dev/null url=http://{PXE_SERVER}/isos/ubuntu22base.iso ds="nocloud-net;s=http://{PXE_SERVER}/cloudinit/__dmi.chassis-serial-number__/"`
[00:34] <claycovariant> yeah thats what im trying to do, use cloud-init to setup the machine, but I want to use cloud-init 23.1 to use dmi variable substitution to pass different metadata based on the machine
[00:34] <minimal> is this Subquity/Curtin installer?
[00:35] <claycovariant> right now its running 22.2
[00:35] <claycovariant> i believe so
[00:35] <dbungert> the version of cloud-init that will run will be the version built into the the install iso
[00:35] <minimal> I use cloud-init to setup physical machines but I use a disk image prepared with cloud-init installed
[00:36] <minimal> so from your command example above you're trying to pass "ds=" and "cloud-config-url" to the Ubuntu installer, not to cloud-init it seems
[00:37] <claycovariant> yeah, which from my understanding then calls cloud init at one point in the install
[00:37] <claycovariant> so i need to package cloud init into my iso?
[00:37] <minimal> that's Subquity/Curtin, a Ubuntu-specific way of installing that uses cloud-init, it's not cloud-init "proper"
[00:37] <dbungert> if you're using official Ubuntu ISOs cloud-init will already be present in there
[00:38] <minimal> dbungert: but that's via Subiquity/Curtin, right?
[00:38] <claycovariant> that ubuntu22base.iso is just an official ubuntu iso renamed
[00:39] <claycovariant> I was unclear on the differences of subiquity and cloud init, they seemed very similar looking at the repos
[00:39] <dbungert> subiquity is the installer, subquity interacts with cloud-init in two ways
[00:40] <dbungert> cloud-init is present in the install environment, which means you can send any cloud-config it knows how to process, to customize the installation environment
[00:40] <minimal> AFAIK there is a slight difference in the YAML used, subiquity has at least one additional "layer"
[00:40] <dbungert> cloud-init can be used to pass autoinstall to subiquity
[00:40] <dbungert> then finally, cloud-init runs in the target system on first boot
[00:43] <minimal> I don't think you can get the installer to update the cloud-init version so that it understands/uses the DMI-related url stuff you are passing the installer before the installer uses the url stuff you are passing in order for it to install the OS ;-)
[00:46] <dbungert> claycovariant: https://github.com/mwhudson/livefs-editor should let you put the newer cloud-init version into a modified version of the iso
[00:47] <claycovariant> thanks! ill give that a shot
[01:00] <blackboxsw> thx dbungert. claycovariant: I use something like the following locally to inject/upgrade cloud-init in isos for manual testing (leveraging livefs-editor) https://paste.ubuntu.com/p/9PVvsH69HM/ note it's pulling the version of cloud-init in from our daily build PPA so use at your own risk, but it's a good template on which to build different livefs-editor "actions" if you are rolling your own custom isos.
[01:11] <minimal> there seem to be quite a few Ubuntu Curtin/Subiquity related questions cropping up here recently, is there another Ubuntu channel that people should be referred to?
[01:25] <dbungert> there is significant overlap.  Some Subiquity questions could be redirected to an Ubuntu channel, but others will ultimately be cloud-init.  Or both.
[15:26] <holmanb> meeena: interesting, that is a bit surprising
[15:27]  * holmanb will read netbsd docs to be sure
[16:41] <meena> holmanb: i dunno. these systems diverged 30 years ago. and while there's a lot of cross pollination, something as low level as how do they boot their kernel will be fairly set in their own ways. c.f.: OpenBSD not having any loadable kernel modules
[20:09] <holmanb> meena: sysctl maybe? I see you can set / get kernel env vars, much like kenv on freebsd
[20:18] <meena> holmanb: i don't see anything relevant or useful https://man.netbsd.org/sysctl.7
[20:25] <holmanb> meena: there is an examlpe in https://man.netbsd.org/NetBSD-8.0/sysctl.8
[20:29] <meena> holmanb: which one??
[20:31] <holmanb> this part
[20:31] <holmanb> https://dpaste.org/QWuFY
[20:33] <meena> that's still something you'd have to write into the image tho, not an external mechanism
[21:06] <holmanb> meena: true - isn't that how kenv works too? if not, then I misunderstood that
[21:09] <meena> kenv reads kernel_options. you can set them on the bootloader
[21:09] <meena> what I'm unclear about is how to chain that
[21:10] <meena> like, how do i tell virtio to pass those options to the FreeBSD bootloader
[21:11]  * meena asks in #qemu on OFTC
[21:12] <holmanb> I think you can use -append, but for that I think you need to also specify the kernel.
[21:19] <holmanb> meena: I will drop the netbsd changes from the PR, since I don't see a documented way to do this.
[21:21] <meena> 👍