[08:40] <Ubugtu> New bug: #71763 in vnc (main) "Font problems (dup-of: 2066)" [Undecided,Needs info]  https://launchpad.net/bugs/71763


[00:14] <afv> hi
[00:15] <afv> RAOF, i'm having no problem with nouveau-kernel-source, this time
[00:16] <afv> but i still do have that font issue
[00:16] <afv> and by the way, did anyone tried to compile mesa today?
[00:16] <afv> i'm getting a "nv20_context.c:326: error: ‘NV20TCL_FOG_MODE_EXP_SIGNED’ undeclared (first use in this function)"
[00:17] <RAOF> Hm.  I'd guess that nouveau's been messing with the #defines again.
[00:17] <RAOF> That'd require a new libdrm, probably.
[00:17] <afv> (nv20_context.c: In function ‘nv20_init_hwctx’)
[00:17] <afv> hmm ok
[00:18] <RAOF> afv: Possibly it's time to bounce it up to nouveau's bugtracker?
[00:18] <afv> do you have a link at hand?
[00:19] <RAOF> https://bugs.freedesktop.org/
[00:19] <afv> thanks
[00:35] <afv> http://bugs.freedesktop.org/show_bug.cgi?id=25974
[00:36] <afv> i hope the information provided is enough
[00:39] <Sarvatt> afv you need an updated libdrm..
[00:41] <Sarvatt> dont have time to update it right now on edgers, will try to get it up in the morning
[00:41] <afv> so.. should i close the bug?
[00:41] <RAOF> afv: Whoops.  I meant bounce the font issue bug up to the nouveau bugtracker :/
[00:41] <afv> RAOF, ah. ok then
[00:42] <afv> marked the bug as invalid..
[00:42] <afv> lol. sorry
[00:42] <Sarvatt> can you compile your own libdrm from the debian package?
[00:43] <afv> i can try
[00:44] <Sarvatt> actually, that commit is self contained, i'll just throw it in as a patch for now and upload it real quick
[00:45] <afv> thanks
[00:46] <Sarvatt> lucid right?
[00:46] <Sarvatt> (dont want to bother with whatever you arent using because i'll just do a git update tomorrow)
[00:47] <afv> right
[00:50] <Sarvatt> uploaded
[00:51] <afv> to the ppa?
[00:51] <Sarvatt> yeah
[00:51] <afv> ok. many thanks :)
[00:52] <Sarvatt> just added http://cgit.freedesktop.org/mesa/drm/patch/?id=5963c023b84daaacb91ae0aa4cf841acff63fd1f
[00:53] <sistpoty> finallly, fixed mesa uploaded, thanks againg albert23
[00:53] <sistpoty> !
[01:19] <afv> Sarvatt, thanks. mesa compiled fine :)
[01:20] <afv> but this is what happens when trying to run compiz: http://dl.dropbox.com/u/659315/screenshots/compiz_20100110.png
[01:20] <afv> and i have a "nv40_screen_get_param:56 -  Unknown PIPE_CAP 31" when trying glxgears or compiz
[01:32] <ScottK> mesa's got further than it did before on i386 ....
[01:39] <RAOF> afv: Yeah, everyone gets that warning; it doesn't stop compiz from working for me.
[01:40] <afv> okay
[01:54] <ScottK> Congratulations albert23.  Thanks for making mesa build.
[02:33] <afv> RAOF, how many frames do you get running glxgears?
[02:36] <afv> i'm getting around 490 using gallium and around 700 without it. but.. iirc, not sure, i was getting like 6000 using nvidia blob..
[02:37] <bjsnider> what memory manager is the nouveau blob using?
[02:37] <bjsnider> i should sayd hte nouveau driver
[03:15] <RAOF> bjsnider: ttm.
[03:15] <RAOF> afv: Something in the order of 500ish, I think.  It's not a good benchmark.
[03:16] <bjsnider> it uses a pure ttm?
[03:17] <bjsnider> not a gem-ified ttm?
[03:17] <bjsnider> i didn't knpow ttm had gone into the kernel
[03:18] <RAOF> It has; I'm pretty sure it was in 2.6.32, and probably earlier.
[03:18] <RAOF> radeon has been using it for a while.
[03:18] <RAOF> Because gem doesn't really cover “my graphics card has onboard memory” :)
[03:19] <bjsnider> radeon uses a comination of gem and ttm
[03:19] <RAOF> Yes; as does nouveau.
[03:19] <ScottK> tjaalton: mesa's not there yet: https://launchpad.net/ubuntu/+source/kdebase-workspace/4:4.3.90-0ubuntu1/+build/1436135/+files/buildlog_ubuntu-lucid-i386.kdebase-workspace_4:4.3.90-0ubuntu1_FAILEDTOBUILD.txt.gz
[03:21] <bjsnider> gem doesn't understand dedicated vram, only shared?
[03:21] <ScottK> That's with the new one too.
[03:21] <ScottK> Get:5 http://ftpmaster.internal lucid/main libglu1-mesa-dev 7.7-0ubuntu3 [211kB]
[03:23] <afv> ok, thanks RAOF
[04:02] <Sarvatt> theres a dangling symlink left behind in /usr/lib now
[04:02] <Sarvatt> lrwxrwxrwx 1 root root     10 2010-01-08 23:06 /usr/lib/libGL.so -> libGL.so.1
[04:05] <Sarvatt> ah i see why
[04:05] <ScottK> Why?
[04:06] <Sarvatt> well i see a problem maybe, kdebase-workspace is using libglu1-mesa-dev, glu.pc is pointing to /usr/lib but the libglu1-mesa-dev package installs it to /usr/lib/mesa/
[04:07] <Sarvatt> oh bah nevermind
[04:07] <Sarvatt> libdir=/usr/lib/mesa
[04:07] <Sarvatt> working on 2 machines with different mesa versions on them because one isnt seeing the update
[04:07] <ScottK> Fun
[04:10] <ScottK> Sarvatt: If you can figure out something that doesn't look too crazy, I can upload it.
[10:03] <tjaalton> ScottK: oh bugger
[10:06] <tjaalton> I think it should be libgl1-mesa-glx that ships the GL.conf and not the xserver..
[10:16] <jcristau> that would mean the server has to depend on libgl1-mesa-glx
[10:17] <jcristau> which is better than the other way around, but still
[10:17] <tjaalton> fck
[10:17] <jcristau> this whole thing is screwed up
[10:17] <tjaalton> you don't say :)
[10:20] <tjaalton> I like how the stuff is named; /etc/ld.so.conf/GL.conf -> /etc/alternatives/gl_conf -> /usr/lib/standard-x11/ld.so.conf
[10:29] <tjaalton> somehow I don't want to do anything until tseliot shows up
[10:41] <tjaalton> s/want to/feel like/
[10:41] <tjaalton> s/do/doing/
[10:42] <jcristau> :)
[10:45] <tjaalton> just moving that conf will be messy
[10:46] <albert23> can't xserver-xorg-core and libgl1-mesa-glx both provide an alternative for GL.conf?
[10:46] <tjaalton> why?
[10:46] <albert23> to prevent the new dependency
[10:47] <tjaalton> it just lists /usr/lib/mesa, so why should they both do the same
[10:47] <jcristau> they'd provide dangling symlinks?
[10:47] <albert23> They can both setup a full alternative for GL.conf?
[10:48] <tjaalton> I think the ugliness factor has been fulfilled already :)
[10:49] <jcristau> albert23: the alternative has symlinks to libglx.so and libdri.so as slaves
[10:51] <albert23> Ah, I see
[16:19] <albert23> yay: kdebase-workspace-bin_4.3.90-0ubuntu1albert1_amd64.deb built with new mesa
[16:19] <albert23> that took 2 changes
[16:20] <albert23> First I added xserver-xorg-core as build-dependency, to get GL.conf installed (would be covered by the change suggested by Tjaalton)
[16:21] <albert23> Then I had to add export CMAKE_LIBRARY_PATH=/usr/lib/mesa in debian/rules
[16:21] <albert23> Without that, I got -- Looking for glXChooseVisual in GL - not found
[16:22] <albert23> and part of the package was not buit, resulting in a dh_install error
[16:22] <jcristau> changing every GL client to use -L/usr/lib/mesa is not a reasonable
[16:22] <jcristau> option
[16:23] <jcristau> moving libGL.so back to /usr/lib would be better imo
[16:24] <albert23> jcristau: unless there is a way to tell cmake to use pkg-config
[16:24] <albert23> pkg-config in the build showed the right -L option, but it was not used
[16:25] <jcristau> no, not unless
[16:26] <jcristau> not all GL clients use cmake, and not all GL clients are packaged by ubuntu.  that would be asking everyone to change their software because ubuntu decided to break stuff
[16:28] <jcristau> making 'gcc -lGL foo.c -o foo' not work out of the box is stupid imo
[16:46]  * ScottK agrees with jcristau
[16:52] <wind-rider> ScottK: when will it be safe to upgrade mesa? it is available as an update now
[16:53] <ScottK> wind-rider: The update doesn't fix the problem.
[16:54] <wind-rider> ScottK: I updated, and now my x-server won't start
[16:54] <wind-rider> only afterwards i saw the note that it was better not to upgrade
[16:55] <ScottK> wind-rider: I've no idea.  I'm waiting with you for a proper solution.
[16:55] <wind-rider> ok
[16:56] <wind-rider> should i file a bug?
[16:57] <sebner> wind-rider: I'm sure tseliot is aware of it
[16:57] <wind-rider> all right
[16:57]  * sebner has a working Xserver with newest mesa though. The first boot resulted in a segfaulting Xserver indeed
[16:57] <JontheEchidna> there's bug 505359 already filed anyways
[16:57] <wind-rider> sebner: so i should try to reboot?
[16:58] <sebner> wind-rider: dunno, as I said /here it didn't work the first boot and no problems since then
[16:58] <wind-rider> i'll try :)
[16:59] <wind-rider> see you later
[17:03] <wind-rider> sebner: you were right, rebooting helped, so i don't need my Live-usbstick anymore :) thx for the hint
[17:05] <sebner> wind-rider: heh, the windows-way of life
[17:05] <wind-rider> sebner: looks like that indeed :P
[17:19] <hyperair> windows-way?
[17:21] <woozy_> "reboot until it works"
[17:28] <wind-rider> i must go
[17:28] <wind-rider> bye
[17:28] <sebner> hola hyperair :)
[17:29] <hyperair> hola sebner =)
[17:32] <sebner> hyperair: are you already on the agenda for the meeting (speaking about your applications)?
[17:32] <hyperair> not yet
[17:33] <hyperair> i'm still thinking which meeting i should choose
[17:33] <hyperair> one of them will occur at 3am on a friday morning
[17:33] <sebner> hyperair: heh, so you are ready for the weekend then :P
[17:33] <hyperair> that'll be the meeting after the next
[17:33] <hyperair> sebner: so i still have time to think which one i feel like going for =p
[17:34] <hyperair> sebner: and also to reap more endorsements
[17:34] <hyperair> =D
[17:34] <sebner> hyperair: heh, you should mention your interest in non cli packages/sponsoring too though
[17:34] <hyperair> sebner: didn't i?
[17:35] <sebner> hyperair: ah right, :) just not good to only have on area standing above all
[17:36] <jcristau> really?
[17:37] <sebner> jcristau: depends but in most cases not
[17:37] <sebner> hyperair: speaking of, where is banshee 1.5.2 ;P
[17:38] <sebner> hyperair: stopped by transition I suppose?
[17:38] <hyperair> sebner: yes, that it is.
[17:38] <sebner> kk
[17:39] <hyperair> sebner: also, i think you focused too much on the bulleted list of PPAs.
[17:39] <ripps> Does anybody have any clue how the xf86-input-wacom driver for lucid is coming?
[17:39] <jcristau> by train
[17:40] <sebner> hyperair: yeah right
[17:40] <sebner> hyperair: It's also my personal experience with you though :)
[17:40] <hyperair> =p
[17:40] <hyperair> right
[17:44] <ripps> I believe the new udev xf86-input-wacom driver was released in debian just the other day. So how long until it gets in Ubuntu?
[18:05] <ripps> Okay, I just pulled the xf86-input-wacom source package from debian and built it with pbuilder. It seems to fix my immediate problems I had with my tablet, unfortunetly, it seem the xsetwacom utility doesn't really work. The names it lists for the stylus/eraser/cursor devices don't actually work when you try to set them.
[18:07] <ripps> Oh, okay, I figured it out. I has to have the quotes in the actual name sting.  What do I have to have the devices called '"Wacom Graphire3"'? Notice the two sets of quotation?
[18:12] <jcristau> because X gets the device name from udev, and there are quotes
[18:14] <ripps> hmm... it seems that KeepShape doesn't work anymore, good thing I kept an old script with some manual BottomX BottomY to accomplish the same thing with my screen
[18:24] <ripps> Huh, TPCButton value is inverted. It's on when I set it to off... now that's a bug
[18:25] <ripps> Where do I file bugs? or should I wait until it gets into Ubuntu?
[18:45] <wind-rider> ripps: if you know the package, run: ubuntu-bug <packagename>
[18:45] <wind-rider> ripps: else, go to bugs.launchpad.net
[21:50] <al> https://help.ubuntu.com/community/RadeonDriver#Tweaking%20The%20Driver could use a review maybe
[21:51] <al> i just edited to reflect the default AccelMode change from XAA to EXA, which had a severe negative performance impact on my R350 card
[21:51] <al> don't know about the other options though
[23:01] <tjaalton> maybe a time to fix the mesa mess, if only my DNS worked
[23:33] <tjaalton> still broken, I'll leave mesa for tomorrow..
[23:51] <bjsnider> there is no fix is there?


[00:00] <vorlon> ahasenack: hmm nevermind, wouldn't help because postgresql-server-dev-12 also Depends: clang-9 and I don't know that this could be made :any (but also, what's with dev packages specifying a compiler :P)
[00:02] <WoC> Could be worse, it could be demanding cobol 1.0.1, which may be tricky to find ;)
[12:18] <AsciiWolf> I have noticed that "info" package that is preinstalled on Ubuntu Focal contains a desktop file (/usr/share/applications/info.desktop) that adds a "TeXInfo" desktop entry that is shown among other (GUI) apps in Shell Overview
[12:18] <AsciiWolf> this desktop item opens a terminal window with the info program
[12:19] <AsciiWolf> I don't think it is a good idea to have something like this showing on a clean system installation since it is confusing for many (regular) users
[12:20] <AsciiWolf> adding something like NotShowIn=GNOME; to the desktop file would solve this
[12:20] <AsciiWolf> but I am not sure if info has an active maintainer in Ubuntu or is just synced from Debian
[12:26] <AsciiWolf> I have made a Launchpad ticket for this: https://bugs.launchpad.net/ubuntu/+source/texinfo/+bug/1859963
[13:19] <rbasak> ahasenack: import complete for netcfg
[13:19] <rbasak> But it looks like it hasn't changed since Feb 2019
[13:19] <rbasak> So I'm not sure it actually did anything
[13:19] <ahasenack> ok
[13:20] <rbasak> Maybe it updated the branch pointers only
[13:41] <juliank> AsciiWolf: I feel like GNOME should just hide applications with Terminal=true in a subfolder
[13:41] <juliank> e.g. "Terminal applications"
[13:54] <AsciiWolf> juliank, hmm, I am not sure... however the info.desktop does not have Terminal=true
[13:54] <juliank> AsciiWolf: Well sure it has
[13:54] <juliank> It's Exec=info\n[...]\nTerminal=true
[13:55] <AsciiWolf> juliank, really? that's weird
[13:56] <AsciiWolf> then I am not sure why it shows on latest Ubuntu Focal among other apps
[14:00] <ahasenack> rbasak: hi, could you please give me some help in figuring out why bind9 is stuck in migration?
[14:00] <ahasenack> I rebuilt every reverse-deps I could find
[14:00] <ahasenack> the only ones I can't really test are the udeb ones
[14:00] <ahasenack> but I did upload debian-installer, which is all that it took in the previous bind9 soname bumps I have done
[14:01] <ahasenack> but now some guestfs packages are showing up in update_output.txt
[14:01] <ahasenack> I installed all os those in amd64 and s390x, then removed all previous bind9 libs, and nothing else was removed. The old bind9 libs were even in the autoremove suggestion list
[14:02] <ahasenack> I'm also trying now on s390x, which has nbdkit-plugin-guestfs
[14:02] <ahasenack> (not available in amd64)
[14:02] <ahasenack> but that also installs fine
[14:03] <ahasenack> and I don't see how that relates to the bind libs
[14:03] <ahasenack> or isc libs
[14:05] <ahasenack> maybe it's debian-installer-udebs on s390x
[14:07]  * ahasenack starts downloading individual udeb packages
[14:08] <rbasak> Looking
[14:10] <rbasak> Yeah I think it's udeb related
[14:11] <rbasak> But amd64 also, not just s390x
[14:11] <ahasenack> ok
[14:14] <ahasenack> rbasak: do you know of any way to easily check udebs, other than downloading them and dpkg -i each one?
[14:14] <ahasenack> i.e., something apt related
[14:15] <rbasak> I was just looking in to that.
[14:15] <rbasak> I want to add debian-installer to chdist
[14:15] <ahasenack> I'm using pull-lp-udebs for now
[14:15] <rbasak> I haven't found a way yet
[14:18] <rbasak> isc-dhcp-client-udeb is one
[14:18] <ahasenack> one what?
[14:18] <rbasak> That'll need rebulding I think. It needs libdns-export1104-udeb for example but the new bind9 is making libdns-export1107-udeb
[14:19] <ahasenack> I did rebuild isc-dhcp, isn't that where the udeb comes from?
[14:19] <rbasak> Ah maybe I'm looking at the release pocket
[14:19] <ahasenack> https://launchpad.net/ubuntu/+source/isc-dhcp/4.4.1-2ubuntu6 is the rebuild
[14:19] <ahasenack> ubuntu6
[14:26] <rbasak> ahasenack: I'm not sure if I'm just catching up with your understanding here
[14:26] <rbasak> debian-installer-udebs in focal-proposed still depends on libdns-export1104-udeb and libisc-export1104-udeb
[14:27] <rbasak> (amd64)
[14:27] <ahasenack> hm
[14:27] <ahasenack> let me see the rebuild logs
[14:27] <rbasak> And also libisc-export1100-udeb
[14:29] <ahasenack> maybe I uploaded it too soon :/
[14:29] <rbasak> I did work out how to get chdist working with debian-installer
[14:29] <rbasak> http://paste.ubuntu.com/p/WJF4SZgJHQ/ for example works
[14:29] <ahasenack> Get:9 http://ftpmaster.internal/ubuntu focal/main/debian-installer amd64 isc-dhcp-client-udeb amd64 4.4.1-2ubuntu5 [210 kB]
[14:30] <ahasenack> it grabbed the old one indeed
[14:30] <ahasenack> same for bind
[14:30] <ahasenack> ok, that explains it
[14:30] <ahasenack> I'll upload again
[14:30] <ahasenack> rbasak: thanks!
[14:31] <rbasak> https://pastebin.ubuntu.com/p/CpKH2dYYMq/ is what gave me the answer in the end
[14:31] <rbasak> You're welcome!
[14:31] <ahasenack> what's chdist-if-migrated?
[14:32] <rbasak> ahasenack: http://paste.ubuntu.com/p/M57JwfjFFW/
[14:33] <ahasenack> cool
[14:34] <AsciiWolf> juliank, I just re-checked it on latest Ubuntu Focal, TeXInfo is showing in Shell Overview although it's desktop file contains "Terminal=true"
[14:34] <AsciiWolf> are you sure that desktop files for terminal applications are normally not showing in GNOME?
[14:36] <juliank> AsciiWolf: No, I meant that GNOME should stop showing them
[14:37] <AsciiWolf> ah :-)
[14:37] <AsciiWolf> I agree
[16:13] <ahasenack> rbasak: bind9 migrated, thanks again for your help
[17:16] <tjaalton> I have a (non-root) zfs mirror on focal, and need to import it after each reboot.. how to fix that?
[17:29] <tjaalton> seems it's bug 1850130
[17:46] <ahasenack> rbasak: hi, quick help again if you are still around
[17:46] <ahasenack> I think doko removed nut from the archive
[17:46] <ahasenack> see https://launchpad.net/ubuntu/+source/nut/+publishinghistory and the output of "rmadison nut"
[17:46] <ahasenack> that only shows nut in focal-proposed
[17:47] <ahasenack> which was kanashiro's upload
[17:47] <ahasenack> we didn't know nut was removed
[17:47] <ahasenack> it's a server package :/
[17:47] <doko> ahasenack: let me look ...
[17:48] <ahasenack> k
[17:53] <doko> both nut and net-snmp are valid candidates
[17:53] <ahasenack> I'm troubleshooting the net-snmp migration, and found this oddity about nut
[17:53] <ahasenack> that is't not in the release pocket
[17:53] <ahasenack> can't say yet it's what is causing the migration to fail, I just spotted it
[17:54] <ahasenack> it's built with the right libsnmp35 lib, so that's good
[17:54] <doko> needs a rebuild
[17:54] <doko> no
[17:55] <ahasenack> nut-snmp has Depends: nut (>= 1.4.1-pre1), libc6 (>= 2.28), libsnmp35 (>= 5.8+dfsg)
[17:55] <doko> ok, you're right
[17:56] <ahasenack> ok, and I think I found the culprit
[17:56] <ahasenack> libsane
[17:57] <doko> ahasenack: looking at the last occurrence of net-snmp in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt shows you that nut is not blocking
[17:57] <doko> yes, libsane is among those
[18:00] <ahasenack> and it all boils down to a dep8 failure in arm64 for gscan2pdf which blocked sane-backends in proposed (which is built with the right libsnmp35)
[18:00] <ahasenack> ok
[18:00] <ahasenack> what a rabbit hole
[18:00] <ahasenack> sorry for the nut alarm
[18:01] <doko> nuts
[18:04] <ginggs> sounds more like a squirrel hole
[18:07] <ahasenack> nuts at the end
[18:08] <ahasenack> man, that test passed just once in 13 runs
[18:08] <ahasenack> http://autopkgtest.ubuntu.com/packages/g/gscan2pdf/focal/arm64
[18:08] <ahasenack> even worse if I count all runs in that page
[18:08] <ahasenack> sea of red
[18:10] <doko> ahasenack: the problem is the amount of triggers you need ... and all-proposed=1 doesn't work because the current arm64 kernel is broken because it was built with a bad binutils
[18:11] <ahasenack> you think gscan2pdf/arm64 is failing because it needs selected packages from proposed?
[18:12] <doko> hmm, no, looks more like a perl package
[18:34] <ahasenack> doko: I can reproduce that hang in gscan2pdf/arm64
[18:35] <ahasenack>   54751 pts/0    Sl+    0:01                                                      \_ /usr/bin/perl t/06190_Dialog_Scan_Image_Sane.t
[18:35] <ahasenack>  (the next test to be run) is stuck
[18:35] <ahasenack> t/0618_Dialog_Scan_Image_Sane.t ............... ok <-- last one logged in the output
[18:35] <ahasenack> I can work with this, maybe even disable just that one test if it comes to it
[19:21] <allquixotic> In terms of testing and bug reports, what is needed for Focal right now? I'm a developer (though not a current contributor to Ubuntu, I have an LP.net account, etc.) and I just updated my laptop from 19.10 to the latest 20.04 packages. I know testing week happened recently but I'm happy to give my 2 cents now as well, and will be on the hunt for obvious bugs while using the system.
[19:24] <sarnold> allquixotic: I think it's probably a bit underwhelming as an answer -- use your system and report bugs as you find them :)
[19:54] <ddstreet> rbasak any change you could import ubuntu-dev-tools into git-ubuntu?  doesn't seem to be there currently
[20:56] <zyga> focal updates crash on ubuntu-release-upgrader: https://pastebin.ubuntu.com/p/zj92spzYNF/
[21:00] <ahasenack> zyga: worth a bug against the release upgrader?
[21:00] <zyga> yeah, I think so
[21:02] <mwhudson> xnox: 57pollinate is not +x in the casper in bionic proposed :(
[21:02] <zyga> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1860606
[21:03] <bryce> allquixotic, apart from finding new bugs, as a tester another great way to help any open source project is to review existing bug reports and see if you can reproduce them, and if so add your findings to the existing bug report.  If there's patches or ppas proposed, verifying those fixes can be super helpful.
[21:03] <sarnold> mdeslaur, juliank, ^^ -- this feels ever so vaguely like this may be a regression https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1860606
[21:03] <mwhudson> oh well easy to fix
[21:07] <allquixotic> bryce: Sure thing. So far things seem _really_ smooth on KDE Plasma. The only thing I had to go off the rails to support is my external GPU; I am using a PPA for egpu-switcher that runs on boot, detects whether the eGPU is attached, and symlinks in an appropriate Xorg.conf. Not sure if eGPU support is planned for Ubuntu-Gnome3 or KDE Plasma for 20.04.
[21:08] <allquixotic> It's "supported" at a hardware level for sure, as I can get it working without issue once egpu-switcher puts in the right Xorg.conf -- my GPUs are an Intel IGP, an Nvidia dGPU in the laptop, and an Nvidia eGPU -- but there's no nice GUI for switching/selecting the GPU. I think pop! OS has that.
[21:11] <mdeslaur> juliank: looks like you forgot to fix aptdaemon in focal
[21:11] <mdeslaur> sarnold: fyi ^
[21:11] <sarnold> mdeslaur: is this running focal code? or eoan code?
[21:12] <zyga> sdhd-sascha: eoan updating to focal
[21:12] <zyga> er
[21:12] <mdeslaur> sarnold: focal, and I confirmed atdaemon isn't patched in focal
[21:12] <zyga> sarnold:
[21:12] <zyga> sarnold: I was running eaon at the time, focal update was initiated with do-release-upgrade -d
[21:12] <zyga> (when it crashed and burned I did it manually)
[21:13] <sdhd-sascha> hey, zyga :-)
[21:13] <zyga> hey :)
[21:13] <mdeslaur> sarnold: I think /me shrugs
[21:14] <mdeslaur> or perhaps eoan wasn't updated before the update to focal
[21:14] <zyga> eoan was freshly updated all the way
[21:14] <zyga> I was going from 19.04 to 19.10 (fully including reboot)
[21:14] <zyga> then to 20.04
[21:15] <sdhd-sascha> zyga: hmm ... what should a distributor do... support all ... or give for each hardware, a branch....
[21:15] <zyga> sdhd-sascha: ?
[21:16] <sdhd-sascha> zyga: well, then all ;-)
[21:16] <sarnold> the other user in #ubuntu who is reporting this same problem also said that python-apt was updated just before starting the do-release-upgrade
[21:16] <sdhd-sascha> sarnold: what problem ?
[21:17] <sdhd-sascha> i'm new here... and can test...
[21:17] <sarnold> sdhd-sascha: when upgrading from eoan to focal, this error message https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1860606
[21:19] <sdhd-sascha> hey, of course. But the message says, that it's sure that one argument is missing ;-
[21:19] <sdhd-sascha> )
[21:19] <mdeslaur> oh right, looks like ubuntu-release-upgrader needs a fix
[21:19] <mdeslaur> juliank: ^
[21:19] <zyga> "run focal they said"
[21:20] <sarnold> still gotta admit it found a bug, right quick too :)
[21:20] <mdeslaur> this is going to fail on every release
[21:20] <sdhd-sascha> zyga: thank you ... really, i like to test the next version ;-)
[21:21] <sdhd-sascha> zyga: but i don't remember what this python library calls... (ncurses thing)
[21:21] <zyga> sdhd-sascha: I don't know what you mean
[21:21] <sdhd-sascha> ...widget...
[21:21] <sdhd-sascha> wait...
[21:24] <bryce> allquixotic, external GPU sounds like something that would best be worked on directly upstream
[21:30] <sdhd-sascha> hey, folks... how can ubuntu in future installed without be hardware aware ?
[21:30] <sdhd-sascha> i don't nknow.
[21:33] <sdhd-sascha> i try to build a limited snap... with seccomp and apparmor... but didn't know if the user had nvidia or amd... what should i limit or do ?
[21:41] <juliank> mdeslaur: oh yes
[21:41] <juliank> mdeslaur: I forgot to fix aptdaemon in focal
[21:41] <mdeslaur> juliank: yeah, but unrelated in this specific issue
[21:45] <sdhd-sascha> hey, i wonder, is mesa packages better - or non mesa ?
[21:51] <sdhd-sascha> zyga: you can ask tomorrow. it's not your timezone;-) what version could land into 20.04?
[21:54] <sdhd-sascha> hey, should i upgrade tomorrow ? or will the new kernel .... ...
[21:54] <sdhd-sascha> ...
[21:55] <sdhd-sascha> (i'm not kernel .. but developer)
[23:59] <CarlFK> a while ago I brought up  bug #1807047
[23:59] <CarlFK> someone said something like "ubuntu is moving away from di"