[01:35] <mup> Bug #1869116 opened: smartctl-validate is borked in a recent release <MAAS:New> <https://launchpad.net/bugs/1869116>
[05:56] <tosaraja> ltrager: wow, ok thanks. So this is a matter of firmware on the NIC? In which case I could try the on board 1GB links for booting and then the 10GB links for data transfer once we're up? I mean I could test if that works
[09:57] <mup> Bug #1867222 changed: MAAS should support hostnames for BMC addresses <MAAS:Invalid> <https://launchpad.net/bugs/1867222>
[10:00] <mup> Bug #1867222 opened: MAAS should support hostnames for BMC addresses <MAAS:Invalid> <https://launchpad.net/bugs/1867222>
[10:06] <mup> Bug #1867222 changed: MAAS should support hostnames for BMC addresses <MAAS:Invalid> <https://launchpad.net/bugs/1867222>
[12:09] <mup> Bug #1866118 changed: 2.6.2 new nodes always are calculated as ephemeral deploys <MAAS:New> <https://launchpad.net/bugs/1866118>
[12:15] <mup> Bug #1866118 opened: 2.6.2 new nodes always are calculated as ephemeral deploys <MAAS:New> <https://launchpad.net/bugs/1866118>
[12:21] <mup> Bug #1866118 changed: 2.6.2 new nodes always are calculated as ephemeral deploys <MAAS:New> <https://launchpad.net/bugs/1866118>
[13:45] <mup> Bug #1867991 opened: Commissioning fails due to linux-modules package when using 20.04 for commissioning  <hwcert-server> <MAAS:New> <maas-images:Invalid> <https://launchpad.net/bugs/1867991>
[13:51] <mup> Bug #1867991 changed: Commissioning fails due to linux-modules package when using 20.04 for commissioning  <hwcert-server> <MAAS:New> <maas-images:Invalid> <https://launchpad.net/bugs/1867991>
[13:54] <mup> Bug #1867991 opened: Commissioning fails due to linux-modules package when using 20.04 for commissioning  <hwcert-server> <MAAS:New> <maas-images:Invalid> <https://launchpad.net/bugs/1867991>
[14:12] <mup> Bug #1867991 changed: Commissioning fails due to linux-modules package when using 20.04 for commissioning  <hwcert-server> <MAAS:New> <maas-images:Invalid> <https://launchpad.net/bugs/1867991>
[21:28] <mup> Bug #1869264 opened: Upgrade from MAAS 2.6.0 to 2.6.2 in HA environment results in maas DB user's password reset, no MAAS nodes able to connect to DB <MAAS:New> <https://launchpad.net/bugs/1869264>
[21:31] <mup> Bug #1869264 changed: Upgrade from MAAS 2.6.0 to 2.6.2 in HA environment results in maas DB user's password reset, no MAAS nodes able to connect to DB <MAAS:New> <https://launchpad.net/bugs/1869264>
[21:34] <mup> Bug #1869264 opened: Upgrade from MAAS 2.6.0 to 2.6.2 in HA environment results in maas DB user's password reset, no MAAS nodes able to connect to DB <MAAS:New> <https://launchpad.net/bugs/1869264>
[21:37] <mup> Bug #1869264 changed: Upgrade from MAAS 2.6.0 to 2.6.2 in HA environment results in maas DB user's password reset, no MAAS nodes able to connect to DB <MAAS:New> <https://launchpad.net/bugs/1869264>
[21:43] <mup> Bug #1869264 opened: Upgrade from MAAS 2.6.0 to 2.6.2 in HA environment results in maas DB user's password reset, no MAAS nodes able to connect to DB <MAAS:New> <https://launchpad.net/bugs/1869264>
[22:25] <mup> Bug #1869269 opened: UI Stuck on loading <MAAS:New> <https://launchpad.net/bugs/1869269>


[19:26] <genunix> Hello, anyone tried unattended installation of Xenial? I am using Packer to build cloud images but I am facing issue when Xenial installer keeps showing language chooser. Even when language boot parameter + preseed is set. I am using similar template as this one: https://github.com/kaorimatz/packer-templates/blob/master/ubuntu-15.10-amd64.json#L14
[19:27] <genunix> It's strange that the same setup works for 14.04 and Debian Jessie but doesn't for Xenial (maybe bug in it's installer?)


[03:46] <astroo-> ciao pessoal
[14:13] <okdamn> guys sorry
[14:14] <okdamn> i'm in trouble with portuguese lang
[14:14] <okdamn> how do you say "Get what you want" in portuguese?
[14:14] <okdamn> :(
[18:45] <astroo-> ola pessoal


[00:40] <pleia2> boo, no updates to the wp ticket yet
[00:53] <Unit193> They be slow...
[00:53] <Unit193> Woops, this is -devel
[13:23] <mr_pouit> micahg: thanks for the orage sync, I guess I missed the testing migration mail ;-)
[13:26] <micahg> mr_pouit: I think it just migrated last night
[13:27] <ochosi> micahg: hm, do you know why the work-item for the white tb-icons disappeared from greybird-fixes?
[13:27] <micahg> it's a bug in thunderbird?
[13:27] <ochosi> oh, sry, i just saw it was moved
[13:27] <olbi> ochosi, hello, I have some problems with owner in Xubuntu 11.10 :)
[13:28] <ochosi> olbi: what exactly to do you mean?
[13:28] <knome> ochosi, i removed that from greybird* since that was in appearance misc
[13:28] <ochosi> knome: yeah, makes more sense there
[13:29] <olbi> ochosi, after installation, updating, adding some repos and installing programs, owner of dir /home/owner/.local/share change to root
[13:29] <knome> yeah, and we don't need both bug + work item :)
[13:29] <ochosi> olbi: hm, dunno why that is, never happened to me. chown it back?
[13:29] <olbi> i change it manually
[13:29] <olbi> but dont know why it makes
[13:30] <olbi> and what it did
[13:30] <ochosi> you mean it happens frequently?
[13:30] <olbi> yes
[13:30] <olbi> it was my second time
[13:30] <ochosi> hm, no clue tbh :)
[13:30] <ochosi> any more hints when it changes?
[13:30] <olbi> dont know yet, but I check it now by installing new and doing same things like before
[13:31] <ochosi> k, well if it happens again it sounds like you should file a bugreport
[13:31] <olbi> try to figure what makes it, are there any logs of that activities?
[13:32] <ochosi> not sure
[13:34] <mr_pouit> "adding some repos and installing programs" < if you mean unofficial repos, then that's probably the reason
[13:39] <olbi> I added medibuntu :D
[13:39] <olbi> and only that with ubuntu in name


[00:46] <cjwatson> ^- first test of new upload scheme
[00:46] <cjwatson> (I was in a bit too much of a rush the first time and beat the rollout to pepo, hence the reject)
[00:47] <xnox> g
[00:48] <xnox> please accept: libguestfs    x-kit    for python3.3 fixes
[01:05] <cjwatson> x-kit's fine
[01:06] <cjwatson> libguestfs (a) has a typo ("CPPCFLAGS") and (b) ignores test failures without explanation
[01:09] <cjwatson> So rejected - I've mailed doko with an explanation
[01:10] <cjwatson> xnox: ^-
[01:10] <cjwatson> (Plus, next upload will magically go to -proposed)
[01:13] <cjwatson> I've modified the queue client to look in -proposed by default, seeing as most things will be there now
[01:18] <xnox> cjwatson: ack. thanks for the review.
[04:26] <ScottK> ^^^ would be nice to get in before the general opening because there is a small chance packages might misbuild if it's not.
[04:32] <infinity> ScottK: Sure.
[04:32] <ScottK> Thanks.
[04:34] <infinity> I should probably nap.  I think eglibc's done, but it might help to look it over when my eyes aren't close to being glued shut.
[04:54] <ScottK> That means my local hack to avoid including the entire package changelog in the sync request worked ...
[07:05] <cjwatson> ScottK: oh, yeah, perhaps I ought to have mentioned that in my -devel-announce post - the "entire changelog" bug is one tumbleweed fixed in ubuntu-dev-tools bzr
[09:19] <doko> cjwatson: how long does it usually take for a package to migrate from -proposed to -release
[09:21] <RAOF> doko: That depends on a number of things; the SRU default policy is 7-days, plus all bugs marked as tested.
[09:21] <doko> RAOF, ahh, no, for raring
[09:21] <RAOF> Hah!
[09:21] <RAOF> ECONTEXT
[09:22] <cjwatson> doko: there is no migration delay; it should be in the next publisher cycle after it's built everywhere, typically
[09:22] <cjwatson> doko: see http://people.canonical.com/~ubuntu-archive/proposed-migration/
[09:22] <doko> thanks
[09:23] <doko> ohh, so we are blocking on the slowest arch
[09:23] <cjwatson> Yes
[09:24] <cjwatson> I *may* decide to weaken some of the constraints at some point, but I want to see how we do with these first
[09:24] <cjwatson> I'd prefer to start accurate rather than assuming failure
[09:25] <cjwatson> You can also look at it as "ensuring that multiarch systems combining fast and slow architectures don't fail"
[09:25] <cjwatson> Since they often require that versions are in sync
[09:33] <cjwatson> doko: BTW, packages in -proposed still build against -proposed, so this doesn't need to block build chains or anything
[09:34] <doko> right
[09:35] <xnox> doko: and the py3.3 rebuild ppa builds against raring-proposed as well ;-)
[09:39] <doko> hmm, the onboard ftbfs looks interesting
[09:57] <xnox> cjwatson: at the current moment nose is already deleted from -proposed, but not yet published in -release
[09:57] <xnox> ah it's pending in release
[09:57] <doko> bah, the setup.py overwriting locale.getpreferredencoding
[10:12] <cjwatson> xnox: that ordering can happen because it does Archive.copyPackage (creates async job processed maybe a minute or so later) then SPPH.requestDeletion (immediate)
[10:13] <cjwatson> But there's no risk of it actually getting lost AFAIK - worst case you get really unlucky and it vanishes for one publisher cycle
[10:13] <cjwatson> I think timings are such as to render that implausible at the moment, though
[10:15] <xnox> cjwatson: ok, i'm not sure if it ever managed to be published/available from -proposed or I have missed it with rmadison.
[10:15] <xnox> obviously it was published enough for britney to find it....
[10:51] <cjwatson> xnox: britney works off published Packages/Sources files, so it must have been fully published and available
[10:56] <xnox> ok.
[13:36] <cjwatson> prodded proposed-migration a bit - the conditions for running it weren't quite right
[13:36] <cjwatson> should sort itself out next publisher cycle
[13:37] <cjwatson> (specifically, it wasn't running when raring-proposed changed, only when raring changed)
[13:37] <Laney> can we see the scripts and the britney modifications?
[13:40]  * Laney finds promote-to-release
[14:39] <stgraber> ^ isn't that supposed to be blocked to start with? or is that how it's being handled (lands in queue then something rejects automatically)?
[14:46] <jdstrand> stgraber: let me try that again
[14:46] <jdstrand> that exim4 update is a security update
[14:46] <stgraber> sure, but you shouldn't be able to copy to raring, only to raring-proposed
[14:46] <stgraber> I'm just surprised it even showed up in the queue, I thought it'd be rejected at copy time, not when hitting the queue
[14:46] <jdstrand> stgraber: even as an AA?
[14:46] <micahg> stgraber: AAs should be able to copy to the release pocket still AIUI
[14:46] <stgraber> only if using the auto-accept flag
[14:47] <jdstrand> I'll happily put it in -proposed
[14:47] <infinity> stgraber: AAs can copy directly, with autoapprove=True or whatever it is.
[14:47] <infinity> Ahh, you beat me there.
[14:48] <jdstrand> ok, I was unaware of --auto-approve
[14:48] <jdstrand> actually, I was not, I just haven't used it in a while
[14:49] <jdstrand> that ^ will be rejected
[14:49] <jdstrand> then the next one was with --auto-approve
[14:50]  * jdstrand wonders if --auto-approve shows up here
[14:50] <stgraber> it shouldn't as it won't hit the queue
[14:50] <jdstrand> ah, makes sense
[14:53] <stgraber> jdstrand: is it just LP being a bit slow or did you get an error with the --auto-approve copy? I'm not seeing 1.1 on the publishing page for exim4 in raring
[14:53] <jdstrand> stgraber: I did not get an error. I assume it is slow
[14:54] <jdstrand> I never can remember how long it takes. 5 minutes, 10 minutes, 30 minutes...
[14:56] <jdstrand> not 5 it seems :)
[14:59] <jdstrand> I did unembargo 8 openjdks
[14:59] <jdstrand> so maybe that has something to do with it
[15:06] <ScottK> doko: Can I get pykde4 building with 3.3 before we switch the default?
[15:07] <doko> ScottK, is this on the images?
[15:07] <ScottK> Yes.
[15:07]  * ScottK double checks.
[15:07] <doko> see -devel, we wanted to make it the default now
[15:08] <doko> how difficult is this? like qscintilla2?
[15:08] <ScottK> It requires CMake to know about the alternate include directory.
[15:08] <ScottK> I have a test build of a dirty hack in progress.
[15:08]  * xnox already did 3-4 CMake's
[15:09] <xnox> blender morse-simulator hivex by memory
[15:10] <ScottK> Does PYTHON_INCLUDE_DIRS include both?
[15:10] <ScottK> It may just be then that I need to use that instead of PYTHON_INCLUDE_PATH
[15:10] <xnox> ScottK: no, it doesn't. But you need to add both into it and make sure all cmakelists use PYTHON_INCLUDE_DIRS
[15:11] <ScottK> pykde4 still uses the older PYTHON_INCLUDE_PATH, but that's an easy enough change.
[15:11] <xnox> here I cheated: used pkg_config to populate PYTHON_INCLUDE_DIRS http://launchpadlibrarian.net/121099621/morse-simulator_0.6~alpha-1~exp1_0.6~alpha-1~exp1ubuntu1.diff.gz
[15:12] <xnox> hivex is actually autoconf.
[15:15] <doko> ScottK, sip: /scratch/packages/tmp/pykde4-4.9.2/sip/kdecore/typedefs.sip:955: Mapped type has already been defined in another module
[15:16] <doko> make[5]: *** [sip/kterminal/sipkterminalpart0.cpp] Error 1
[15:16] <doko> make[5]: Leaving directory `/scratch/packages/tmp/pykde4-4.9.2/builddir-2.7'
[15:16] <doko> make[4]: *** [CMakeFiles/python_module_PyKDE4_kterminal.dir/all] Error 2
[15:16] <doko> make[4]: Leaving directory `/scratch/packages/tmp/pykde4-4.9.2/builddir-2.7'
[15:16] <doko> make[3]: *** [all] Error 2
[15:16] <doko> fails already in 2.7 :-/ or is this known?
[15:16] <ScottK> That's known.
[15:16] <ScottK> There's an upstream patch for that.
[15:17] <ScottK> doko: https://projects.kde.org/projects/kde/kdebindings/pykde4/repository/revisions/fd30259903ad693b86476b6e8c280b93d0102223
[15:17] <doko> just wanted to check for the so name renaming. ScottK: pointer?
[15:17] <ScottK> There you go.
[15:26] <doko> make[5]: *** No rule to make target `/usr/lib/libpython3.3mu.so', needed by `lib/pykde/akonadi.so'.  Stop.
[15:29] <ScottK> My horrible hack attempt is just about to get to that point.
[15:30] <cjwatson> Laney: lp:~ubuntu-archive/britney/britney{1,2}-ubuntu
[15:32] <cjwatson> stgraber,jdstrand: while people with queue admin privileges on the release pocket *can* copy directly to it (and it'll land in the queue if we're frozen and you don't use auto_approve), please do not do so.  This is intended only for the sake of the automatic scripts themselves
[15:33] <ScottK> doko: I'm stuck on "/usr/include/python3.3m/Python.h:8:22: fatal error: pyconfig.h: No such file or directory"
[15:33] <doko> ScottK, I have a fix. but how do a re-run a configure step just for 3.3?
[15:33] <ScottK> I don't know.  I just failed at that myself.
[15:33] <doko> ScottK, didn't xnox's hint help?
[15:33] <cjwatson> We should probably talk at UDS about exceptions, since there'll no doubt be some, but I don't really want AAs/release-team-members copying into release just because we can ...
[15:33] <ScottK> That one is still building.
[15:34] <ScottK> It's 1/4 of the way through python3.2
[15:34] <xnox> ScottK: well I look at the cmakes output's first to see if they make sence and have the paths, before launching the build ;-)
[15:34] <ScottK> That would have been one way to do it.
[15:39] <stgraber> if an SRU team member has a minute, the bridge-utils I just uploaded to precise-proposed fixes a boot time hang that quite a few people have been nagging me about on IRC over the past few days. It's a 3 lines change to a script so should be trivial to review and matches what we've had in quantal for months, so pretty safe.
[15:39] <doko>             -DPYTHON_LIBRARY=/usr/lib/libpython${v}$(shell python$(i) -c "import sys; print(sys.abiflags)").so \
[15:39] <doko> ScottK, ^^^
[15:39] <ScottK> doko: Thanks.
[15:40] <doko> and I see it prefers python2 as the default python version. maybe change that for raring (not now)?
[15:41] <ScottK> It has to.
[15:41] <ScottK> The one part of the build that that affects hasn't been ported yet.
[15:42] <doko> hrm, that's not enough ...
[15:45] <ScottK> It would be a more general solution, I think, to change FindPythonLibs.cmake in CMake itself so that PYTHON_INCLUDE_DIRS has both directories in it.
[15:51] <doko> I hate debhelper sequencer ...
[15:52] <ScottK> If we do that, it's a one line change (I think) in pykde4 to use PYTHON_INCLUDE_DIRS instead of PYTHON_INCLUDE_PATH
[15:54] <bdrung> slangasek: there are a bunch of patches for -proposed waits to get accepted (vlc, culmus, fonts-nanum-coding)
[15:59] <doko> ScottK, please do if it's quick. I have a patch for the rest of the renaming
[16:00] <ScottK> doko: Go ahead and do PYTHON_INCLUDE_DIRS in your pykde4 as that'll work regardless.  Let me look at CMake again.
[16:03] <infinity> ^-- Shouldn't natty be EOLish?
[16:05] <doko> ScottK, xnox: pkg_check_modules(PYTHON3 python3) how would that be patched to look for the python version used for the build (and not python3)?
[16:05] <bdmurray> I setup a blueprint for the SRU team at https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-sru-queue-velocity
[16:06] <ScottK> doko: I think python${_CURRENT_VERSION}
[16:06] <ScottK> That's what FinePythonLibs uses
[16:06] <jdstrand> cjwatson: so, exim4 never made it to raring. should I use raring-proposed?
[16:06] <ScottK> that may be internal to it though.
[16:07] <ScottK> Yes, it is.
[16:08] <ScottK> debfx: ^^^ Do you know the answer to doko's question?
[16:10] <skaet> infinity,  scheduled for 10/28 - will send out the email then.
[16:16] <slangasek> bdrung: I'm aware of the SRU queue and will be plowing through them today.  Please make sure that all SRU bugs have the required SRU information before I get there, otherwise they'll go to the back of the queue again ;)
[16:21] <stgraber> infinity: thanks. I poked a couple of the reporters on IRC so bridge-utils should be all tested before it reaches the 7 days mark.
[16:22] <infinity> stgraber: Alrighty.
[16:22] <infinity> stgraber: (Wait, how did you know it was me?)
[16:22] <stgraber> infinity: sru-accept comments in the bug ;)
[16:23] <infinity> stgraber: Oh, duh.  Right.
[16:23] <infinity> stgraber: I thought someone had finally implemented queue auditing when I wasn't looking.
[16:23] <stgraber> (no, we still don't have queue audit...)
[16:23] <stgraber> right :)
[16:55] <ScottK> doko: I'm lost in a maze of twisty turny cmake passage, all look alike.
[16:57] <doko> ScottK, I think I have something ...
[16:57] <ScottK> Great.
[16:57] <bdrung> slangasek: done. please note that vlc has a preliminary MRE
[16:58] <ScottK> It did, however, lead me to find a mistake I'd made in my hack to deal with multiple pyqtconfig.py files in the same directory for python3 in PyQt (thus the upload)
[16:58] <ScottK> So getting lost wasn't time wasted.
[17:01] <doko> cjwatson, ^^^ hmm, copies from ppa's including binaries don't seem to work
[17:01] <cjwatson> jdstrand: Please do, although I would like to investigate what happened to your previous copy when I'm not in an airport.
[17:01] <cjwatson> doko: see above comment :)
[17:02] <doko> yeah, seen python3-defaults too
[17:04] <jdstrand> cjwatson: ack
[17:04] <jdstrand> (and done)
[17:12] <ScottK> doko: Thanks.
[17:12] <ScottK> doko: Would you mind accepting the python-qt4 one as well?
[17:12] <doko> ScottK, is it really needed? arm builders are busy ...
[17:13] <ScottK> Without it pyqtconfig isn't going to work in python3.  Not sure how important that is.
[17:14] <ScottK> I got an accept from somebody.  Thanks.
[17:17] <jdstrand> meh
[17:19] <jdstrand> mdeslaur: seems that copies from ppas including binaries doesn't work atm, so the exim4 update was rejected (both to release and -proposed). the same thing happened to openjdk-6 and openjdk-7. cjwatson is aware, but will look at it late
[17:19] <jdstrand> later*
[17:19] <mdeslaur> jdstrand: ok, thanks
[17:21] <doko> ScottK, any idea about https://launchpadlibrarian.net/121171710/buildlog_ubuntu-raring-amd64.pykde4_4%3A4.9.2-0ubuntu3_FAILEDTOBUILD.txt.gz ?
[17:22] <doko> did build here locally
[17:36] <ScottK> doko: No idea why it'd work locally and not on the buildd, but "sip: Unable to find file "QtCore/QtCoremod.sip"" gives me some thought that a retry after the PyQt upload build is done might work.
[18:03] <xnox> doko this is some ^^^^
[18:03] <xnox> there will be more vvvvv
[18:06] <xnox> doko ^^^^
[18:08] <doko> xnox, why python-numpy again?
[18:08] <xnox> doko: not sure. reject for now and I'll double check my set.
[18:09] <doko> xnox, because I know this has the extensions for both 3.x versions
[18:13] <xnox> doko: ok, it was in my set because it has hard dependency on python3.2 via /usr/bin/f2py3.2
[18:13] <xnox> which will be dropped, when we drop py3.2 support.
[18:13] <xnox> so reject is correct.
[18:26] <xnox> doko: cjwatson: barry: shiboken is shibroken & hence I cannot rebuild pyside and therefore britney is holding back python3-defaults
[18:26]  * xnox decides to fix all of this.
[18:27] <slangasek> do we not have support for overriding britney here?
[18:27] <slangasek> because we shouldn't block on shiborken
[18:28] <barry> xnox: slangasek is correct.  if you *must* fix shiboken, my suggestion is to essentially no-op the tests that crash the interpreter.
[18:28] <barry> xnox: sucks because it hides a real bug (imho, in shiboken) but there you have it
[18:28] <slangasek> if britney is set up right, I could probably force it by manually copying python3-defaults over :P
[18:29] <slangasek> (and then let britney clean everything up afterwards)
[18:29] <slangasek> but, er, I haven't gotten a briefing yet on where the britney instance is doing its thing
[18:29] <slangasek> infinity: ^^ can you give me a pointer?
[18:29] <slangasek> (preferably a non-null one)
[18:29] <xnox> slangasek: I'm going to do the right way, and do "anything possible without touching britney" to migrate packages.
[18:30] <doko> yeah on https://launchpad.net/ubuntu/+source/gcc-4.7/4.7.2-5ubuntu3/+build/3928872/+files/buildlog_ubuntu-raring-armel.gcc-4.7_4.7.2-5ubuntu3_FAILEDTOBUILD.txt.gz
[18:30] <slangasek> xnox: I don't think disabling a test suite to make a known-broken package build is "the right way" :)
[18:31] <xnox> slangasek: it's bug 1070772
[18:31] <ubot2> Launchpad bug 1070772 in shiboken (Ubuntu) "modelview_test.py segfaults python" [Undecided,Confirmed] https://launchpad.net/bugs/1070772
[18:31] <doko> I think ignoring the test failure is ok provided you keep a bug report open and come to it back later
[18:31] <slangasek> xnox: and any more-correct fix for sheboygan is going to take much longer to implement, and really shouldn't be allowed to block here
[18:31] <xnox> and I don't know if it's bug in shiboken, the unit test, or our pythons.
[18:31] <barry> slangasek: i don't either :)  just sayin' if there's no other way, that's how i'd work around it
[18:32] <barry> xnox: i strongly suspect shiboken or some other related extension module
[18:32] <barry> xnox: i tried to report it upstream, but the qt bug tracker hates me
[18:32] <xnox> slangasek: shiboken is known fail to build from source in quantal. So can britney wave those?
[18:33] <xnox> slangasek: should shiboken binaries & pyside binaries be removed from the archive then?
[18:33] <xnox> is that a right fix?
[18:33] <slangasek> doko: ^^ would you agree with removing the binaries?
[18:33] <slangasek> they'd be uninstallable anyway, right?
[18:34] <doko> generally yes, if there are no r-deps
[18:34] <doko> afk now
[18:35] <xnox> slangasek: we are talking about removing pyside - python qt4 LGPL bindings here. (pyqt4 is gpl)
[18:35] <slangasek> the rdep chain is shiboken->pyside/pyside-tools->ipython3-qtconsole
[18:36] <barry> ScottK might have some input here, if he's around
[18:37] <slangasek> xnox: actually, I was only planning to remove shiboken; pyside could be left as-is until shiboken itself is fixed
[18:37] <slangasek> but "as-is" would be "uninstallable"
[18:37] <xnox> slangasek: python3-defaults will not migrate. britney is holding on pyside not shiboken.
[18:37] <slangasek> anyway, the set of revdeps on pyside is small, which is why I think this is reasonable
[18:37] <slangasek> oh
[18:37] <slangasek> xnox: where are you seeing the britney output?
[18:37] <xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[18:38] <xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[18:38]  * xnox *grins*
[18:38] <slangasek> perfect, thanks
[18:38]  * xnox also has no clue what britney is trying to tell me
[18:38]  * xnox is troubleshooting pycrypto in the mean time
[18:38] <slangasek> xnox: it tells you that updating python3-defaults results in those packages becoming newly-uninstallable
[18:39] <slangasek> pyside isn't the only package in the list though
[18:39] <slangasek> morse-simulator, python3-crypto-dbg?  what do we know about this?
[18:40] <slangasek> xnox: pulling the shiboken binary will definitely unblock britney
[18:40] <slangasek> because then pyside is *already* uninstallable in raring, so britney ignores it
[18:40] <slangasek> sorry, I mean it'll unblock britney wrt pyside
[18:40] <xnox> slangasek: morse-simulator is building, python3-crypto-dbg <--- working on it.
[18:41] <xnox> slangasek: also having python3-defaults generate uninstallable defaults packages doesn't help either.
[18:41]  * xnox goes to fix python3-defaults first.
[18:41] <slangasek> where do you see this?
[18:41] <xnox> slangasek: when trying to rebuild python-crypto in raring-proposed chroot.
[18:42] <slangasek> hmm
[18:42] <slangasek> but britney doesn't notice?
[18:42] <xnox> $ rmadison -S -s raring python3.3
[18:42] <xnox> $ rmadison -S -s raring-proposed python3-defaults
[18:43] <slangasek> I don't follow
[18:43] <xnox> defaults are at 3.3.0-0ubuntu1, while real one is at 3.3.0-2
[18:43] <slangasek> why is that a problem?
[18:43] <slangasek> they're different sources, there shouldn't be any lockstep versioned dependency
[18:44] <xnox> hmmm....
[18:45] <xnox> https://launchpad.net/ubuntu/raring/i386/python3-minimal/3.3.0-0ubuntu1
[18:45] <slangasek> shiboken binaries shibounced
[18:45] <xnox> slangasek: thanks.
[18:47] <slangasek> fwiw if someone (ScottK?) considers not having pyside installable a problem and feels that it's better to have shiboken skipping the test suite and building with a known bug, I don't object
[18:47] <slangasek> I just don't think we should do that as non-users of the package
[18:48] <barry> slangasek: you won't mind if i subscribe ScottK to the bug and paste your comment there?
[18:48] <barry> there == bug 1070772
[18:48] <ubot2> Launchpad bug 1070772 in shiboken (Ubuntu) "modelview_test.py segfaults python" [High,Confirmed] https://launchpad.net/bugs/1070772
[18:49] <slangasek> no, that's between you and him ;)
[18:49] <barry> :)
[18:50] <barry> slangasek: he and i are on the same flight to cph so maybe we'll chat about it
[18:52] <xnox> slangasek: ok. I had a dirty chroot.
[18:53]  * xnox continues to debug python-crypto
[18:54] <xnox> slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt now looks very interesting
[18:54] <xnox> are there any hints and trying to understand that output?
[19:01] <slangasek> xnox: it's more interesting now because there were more candidates; my binary removals hadn't taken effect yet, it's nothing different due to that
[19:02] <xnox> why python3-defaults is "tried" twice
[19:03] <xnox> ah.... if other candidates migrate (all: changes) will the skipped packages migrate together or not.
[19:03] <xnox> hmm.... clever but hard to read =)
[19:03] <slangasek> xnox: so each block beginning with "trying:" is a single source package that's a candidate for copying; 'ori' is the count of uninstallable packages, per architecture, at the beginning of the britney run; pre: is at the current point in the run before adding this candidate; now: is the result after trying to add the candidate
[19:03] <slangasek> xnox: correct
[19:05] <xnox> and the got bit?
[19:05] <xnox> got: 180+0: i-180
[19:15] <slangasek> xnox: that says something about the increase in uninstallability... I forget exactly what, sorry
[19:16] <slangasek> I believe it's "there are now 180 packages uninstallable on i386, which is an increase" (from 164)
[19:20] <xnox> I can see how circular dependencies may  confuse britney.
[19:21] <slangasek> they don't really confuse britney, they just make it slower due to NP-completeness :)
[19:21] <slangasek> actually, I would expect us to be using auto-hinting for -proposed and it doesn't look like we are
[19:24] <xnox> slangasek: can it please also do demotions/removals? it would be nice to ask britney to try to demote python3.2 and it tell me which packages I should fix =)
[19:24] <xnox> although we have transition trackers for that, britney is more robust.
[19:25] <slangasek> xnox: checkrdepends is probably better for that
[19:25] <xnox> ok.
[19:30] <slangasek> ah, seems the auto-hinting doesn't generate output anymore
[19:31] <slangasek> that does mean you can't use the output to track the progress of a related set of packages that are not-quite-ready
[19:32] <xnox> ^ above rebuilds makes python3-crypto-dbg to be Depends: python3 (>= 3.2.0) instead of Depends: python3 (>= 3.2.0), python3 (<< 3.3)
[19:33] <xnox> and then we will just have to wait for powerpc builds to finish =(
[20:58] <ScottK> barry/slangasek: pyside isn't on my list of things I care about.
[21:00] <barry> ScottK: cool
[21:04] <xnox> infinity: eglibc breaks boost
[21:05]  * xnox wishes I uploaded boost-mpi-source1.49 before your eglibc upload.
[21:05] <xnox> infinity: time.h now defines TIME_UTC, which boost used to be using.
[21:05] <xnox> in boost 1.50 they renamed it to TIME_UTC_
[21:06] <ScottK> Then boost needs to stop.
[21:06] <xnox> well there is patch https://svn.boost.org/trac/boost/changeset/78802
[21:06] <ScottK> Sounds like you know what patch you need to apply then ...
[21:06] <xnox> but will that break abi/api/compat if I do it in boost1.49
[21:07] <xnox> https://svn.boost.org/trac/boost/changeset/78802/trunk/boost/thread/xtime.hpp
[21:08] <xnox> it's part of enum xtime_clock_types
[21:08]  * xnox so does not want to have boost transition :`(
[21:14] <infinity> xnox: I'm inclined to say that boost is broken, not glibc.
[21:15] <infinity> xnox: But I'm happy to help with a boost transition during UDS.
[21:15] <infinity> xnox: Is 1.50 GA, or still in devel?
[21:15] <infinity> xnox: If it's GA, we should just switch, IMO.
[21:16] <xnox> infinity: released August 20th, 2012 23:00 GMT
[21:17] <xnox> infinity: well, that macro is part of C11 standard
[21:17] <infinity> xnox: Yeah, we should just transition and be done with it, then.
[21:17] <xnox> Unfortunately, on Linux, this is a problem in any C++ code. g++ implicitly defines _GNU_SOURCE, which in turn causes _ISOC11_SOURCE to be defined, regardless of what C++ standard is actually used. But regardless of this gcc feature, the boost interfaces are broken if I want to use C11 interfaces from C++ code.
[21:17] <xnox> quote from https://svn.boost.org/trac/boost/ticket/6940
[21:17] <xnox> I'm not sure *who* is defining _ISOC11_SOURCE
[21:21] <infinity> Anyhow, I'm pretty deep in the gin right now, so if that's the only major fallout of glibc 2.16 so far, we're doing well.
[21:27] <xnox> infinity: I think I will apply patch to boost1.49 and if rdeps break then we will move to boost1.50
[21:31] <xnox> infinity: no, we need to move to boost1.50 then because there is stuff that uses boost::TIME_UTC which is now invalid
[21:32] <infinity> xnox: If we're breaking ABI, we may as well just bump it correctly instead of fudging it.
[21:33] <xnox> infinity: yes. So for the currently stuck package in britney I can just port that one to boost1.50 (this should then allow python3-defaults to migrate)
[21:33] <xnox> and then we can do the boost transition
[22:18] <slangasek> xnox: why is it not sufficient to #undef TIME_UTC in the boost headers?
[22:18] <slangasek> (as a non-ABI-changing workaround)
[22:41] <xnox> slangasek: it should be. Why did fedora not do this when they hit it?
[22:41] <xnox> They first applied: http://pkgs.fedoraproject.org/cgit/boost.git/commit/?h=f18&id=f68c4dd92574829a34324290c15e360d0fedf643
[22:41] <xnox> drop enclosed enum and "embrace" TIME_UTC macro
[22:45] <xnox> and now transitioning to boost 1.50....
[22:46] <ScottK> xnox: Probably safer to apply just the patch to 1.49 and do some rebuilds.
[22:46] <xnox> ScottK: patch which does (i) undef TIME_UTC or (ii) s/boost::TIME_UTC/boost::TIME_UTC_/
[22:47] <ScottK> The latter.
[22:59] <xnox> I am doing a test build of slangasek 's simple solution, as I can't think of any reason why it wouldn't work.
[22:59] <xnox> eglibc 2.16 is new and nothing should be relying on TIME_UTC.
[23:00] <xnox> If something does conditionally rely on it & boost xtime.hpp at the same time it would only do so with boost1.50 which we have available.
[23:00] <xnox> I really don't want to have boost1.49.ubuntu1 abi =)
[23:06] <ScottK> OK.
[23:07] <xnox> slangasek: autohinter did the magic to transition python3-defaults \0/
[23:08] <slangasek> perfect
[23:11] <xnox> and your boost fix works as well http://paste.ubuntu.com/1308399/
[23:43] <ScottK> Boost insanity is curable for once.
[23:45] <infinity> xnox: Good to hear.


[08:00] <hrw> morning
[08:00] <lag> Morning hrq
[08:00] <lag> hrq*
[08:00] <lag> Grrrrrrrrr
[08:00] <lag> hrw*
[08:00] <lag> :)
[08:00] <lag> Stupid fancy keyboard!
[08:01] <hrw> ;D
[09:07] <cooloney> lag: can you boot the .34 panda kernel which was built by yourself?
[09:08] <lag> Yes
[09:08] <lag> :)
[09:08] <lag> I have been playing with it
[09:09] <cooloney> lag: excellent, man, good to hear that
[09:09] <cooloney> lag: thx
[09:09] <lag> cooloney: No problem
[09:10] <lag> Do you have HW yet?
[09:10] <cooloney> too bad, no
[09:10] <cooloney> i don't have omap3 and omap4
[09:10] <lag> Are you going to get HW soon?
[09:11] <hrw> igep v2 should be good omap3 testboard. compared to beagleboard (c4/xm) it is available
[09:11] <cooloney> hrw: igep v2 is from TI or other vendor?
[09:12] <cooloney> lag: no, i think there is no OMAP4 HW for me
[09:12] <cooloney> lag: and for omap3, no idea about that
[09:12] <lag> That sucks
[09:12] <hrw> other
[09:12] <cooloney> lag: maybe i need to order some omap3 boards and ship to folks in US, and get the board during next sprint
[09:13] <hrw> cooloney: spanish company
[09:13] <cooloney> hrw: ok, let me search
[09:13] <cooloney> hrw: thx
[09:13] <lag> I think I'd find it difficult working on an architecture without HW
[09:14] <lag> cooloney: Do you know if a console is configured on HDMI on the Panda board?
[09:15] <cooloney> lag: oh, not sure about that, let me check
[09:15] <hrw> cooloney: http://shop.igep.es/index.php?main_page=product_info&cPath=1&products_id=38&zenid=j4novjt0a4t4k1j0o2igoldhm6
[09:15] <amitk> cooloney: we are trying to get some IGEPv2 boards for evalueation
[09:15] <hrw> cooloney: 130€ for no wifi/bt, 145€ for wifi/bt
[09:16] <amitk> they should work with our kernel, i've enabled it in the configs
[09:16] <cooloney> hrw: nice, ehe
[09:16] <cooloney> amitk: good to know that. hope i can get one of them to play with
[09:18] <amitk> yeah, hope so too
[09:27] <cooloney> lag: i am not sure about the HDMI console. so i believe you are using HDMI display with panda,
[09:28] <lag> I want to
[09:28] <cooloney> lag: can you see anything on it?
[09:28] <cooloney> oh, you don't have
[09:28] <lag> No, nothing
[09:28] <lag> I do have
[09:28] <cooloney> oh, how about change some kernel cmdline to add 'console=tty0' or similar
[09:28] <lag> When I boot, I get 1,000's of these: omapdss DISPC error: SYNC_LOST_DIGIT
[09:29] <lag> That was my follow-up question - Which console ...
[09:30] <ukleinek> ericm|ubuntu: I start merging your and mine patches now, OK?  (You're not in #armlinux, so this is slightly off-topic)
[09:30] <lag> I've been meaning to install a full desktop environment on my new SD card
[09:30] <hrw> I wonder how many working pandas are outside of TI
[09:30] <ericm|ubuntu> ukleinek, i'm ok
[09:31] <cooloney> hrw: skip me, i don't have any
[09:31] <cooloney> hrw: ehe
[09:31] <lag> hrw: o/
[09:31] <cooloney> lag: hmmm, actually, i have no idea about that.
[09:32] <cooloney> sebjan: do you not this console tty0 should be the right one for HDMI console?
[09:32] <cooloney> sebjan: i think lag is trying to output our UNR on it
[09:37] <ndec> hrw: hi. not man panda outside of TI.. not many inside of TI anyways...
[09:37] <ndec> lag: which kernel are you using?
[09:38] <amitk> ndec: panda (the board) as endangered as panda (the animal) ?
[09:38] <lag> 2.6.34-900-omap4
[09:38] <lag> Maverick
[09:38] <ndec> amitk: yep... we are trying to save the animal from disparation ;-)
[09:39] <hrw> ndec: yep
[09:39] <ndec> lag: do you have a HDMI screen or is it a DVI screen using the HDMI output of the board?
[09:41] <lag> It's the real deal
[09:41] <lag> HDMI->HDMI
[09:42] <ndec> lag: ok. well this should work without any config change, assuming you have the right config in the kernel... but i have not tried on HDMI screen yet.
[09:43] <lag> Hmmm
[09:45] <lag> ndec: On which console?
[09:46] <lag> tty*
[09:47] <ndec> lag: don't know. i had tried HDMI->DVI screen several weeks ago with the UNE UI
[09:47] <lag> I've just tested the monitor on my Revo running Karmic and it worked fine
[09:48] <lag> The DVI port on the Panda has an HDMI socket, so I can't test that
[09:50] <ndec> lag: I am using the HDMI port (closest to USB). with the HDMI to DVI cable. I think we have problems with the DVI port. that one shouldn't work either...
[09:53] <lag> ndec: No, that doesn't work as far as I can tell
[09:53] <lag> But neither does the HDMI
[09:54] <lag> ndec: Have you seen this message: omapdss DISPC error: SYNC_LOST_DIGIT
[09:56] <ndec> lag: yes... something wrong in DSS2/OMAP4
[09:57] <armin76> i want one
[09:57] <lag> Do you think it will be related to why I don't have HDMI?
[10:00] <ukleinek> ericm|ubuntu: do you want to look into my patches 4 to 9 and comment/ack?
[10:00] <ericm|ubuntu> ukleinek, OK
[10:01] <ukleinek> ericm|ubuntu: well, my 7 = your 2
[10:01] <ndec> lag: yes.
[10:05] <armin76> ndec: can i get a panda? :D
[10:06] <ndec> armin76: why do you always ask me the same questions ;-)
[10:06] <armin76> last time it wasn't a question :P
[10:06] <ndec> armin76: good point...
[10:06] <ndec> armin76: let us know polish it first...
[10:07] <armin76> i want to polish it too :)
[10:16] <lool> hrw wants to polish it too!
[10:16] <lool> and zyga!
[10:16] <lool> (zyga and hrw are in Poland)
[10:17] <hrw> Polish man meets English man and says: "I need to polish my English". English man replies: "No, your English is Polish enough".
[10:17] <hrw> joke sounds better then looks
[10:22] <ndec> hrw: nice...
[10:22] <hrw> http://alt-tab.org/data/images/2010/06/angelamerkel.png
[10:38] <zyga> lol :-)
[10:52] <berco> anyone knows if it is possible to tell debuild to generate both a -dbg package a striped binary version? I know that I need to set DEB_BUILD_OPTIONS=noopt,nostrip for debug but this will provide me only the debug binary. I'd like to generate both in one command if possible
[11:00] <lool> berco: Is this a package with -dbg packages in control?
[11:00] <lool> berco: What you can do, and what Ubuntu does on all packages, is using pkg-create-dbgsym to achieve that
[11:01] <lool> berco: You would build the package as usual, but the build will output -dbgsym packages along the other ones
[11:01] <berco> lool: I have not changed the control file for this
[11:01] <lool> berco: Just install the package and it should work (you might have to turn it on in /etc)
[11:01] <berco> lool: I was looking more for the general rule to achieve this :)
[11:02] <berco> lool: thanks. I will give it a try
[11:03]  * armin76 steals lool's panda
[11:16] <hrw> armin76: since when he has one? ;D
[11:17] <armin76> he stole it too :D
[11:36] <ogra> dyfet, how far are you with the gobject-introspection FTBFS ?
[14:16] <ukleinek> npitre: ping
[14:17] <ukleinek> npitre: do you care to answer to<EMAIL_ADDRESS>[14:17] <ukleinek> ?
[14:21] <berco> lool: ping
[14:25] <lool> berco: pong
[14:25] <lool> berco: Ideally, don't ping but just ask something so that I dont context switch twice  ;-)
[14:25] <berco> lool: thx for the dbg, seems to work.
[14:25] <lool> Cool
[14:26] <berco> lool: I now face another issue
[14:26] <berco> lool: I noticed in my source package some files lost the execution privilege
[14:26] <berco> lool: any idea how to prevent this?
[14:27] <lool> berco: Sorry, what source is this?
[14:27] <berco> lool: package that contains source code (apt-get source <package name>
[14:27] <lool> berco: Yes, which one?
[14:28] <berco> lool: well not public yet, it's for omap4, this is the "tiler" package
[14:28] <lool> berco: Ok; would be easier to suggest a fix for a public source package
[14:29] <lool> berco: So which file is losing the +x bit exactly and at which point?
[14:29] <berco> lool: code has never been package. it's available but not in deb format yet. Am working on it...
[14:29] <lool> berco: There are two places where that can happen: in your source files, because of the source packaging format, or in the resulting .debs
[14:29] <berco> lool: this is bootstrap.sh file
[14:29] <lool> berco: are you saying that the +x is lost when you unpack the source package, or in the resulting .debs?
[14:30] <berco> lool: I need to check. I just did an "apt-get source" and noticed it's lost
[14:30] <lool> berco: Right, so while unpacking the source
[14:30] <lool> berco: So this is expected in the default source package format
[14:31] <lool> berco: you could of course change the source format, but there's something odd here
[14:31] <lool> berco: Usually, bootstrap.sh is part of the "upstream" tarball, the .orig.tar.gz
[14:31] <lool> berco: Files in this tarball wouldn't lose this bit
[14:31] <lool> berco: What might have happened here is that you intended to ship this file in the tarball, but it got shipped as part of the packaging instead
[14:32] <berco> lool: ok, so I need to check b'cos this file should be in my .orig.tar.gz
[14:32] <lool> berco: You really want this file to be in the upstream tarball I guess
[14:32] <lool> berco: Please do
[14:32] <berco> lool: thanks, that would make sense. I will check
[14:32] <lool> berco: Also, might be best to just ask the chan rather than me specifically -- will get you faster answers, spread the load, and also I dont actually work on omap4 stuff (yet?) but others here do
[14:33] <berco> lool: ok. Sorry I'm new to the Linux world so learning all the habits and stuff
[14:35] <lool> berco: This is fine; I hope you don't mind me telling you
[14:36] <berco> lool: not at all, just noticed you knew quite well the pcakaging topci
[14:48] <berco> :q
[14:58] <berco> when packaging from the .orig.tar.gz, I created a patch to move files but those that have +x attribute will lose it in the .deb source package. Anyone knows how that can be fixed. I want to keep the +x on these file.
[15:00] <berco> btw, I'm using cdbs-edit-patch for creating the patch
[15:02] <lool> berco: Why do you move the files?  and why in a patch?
[15:03] <berco> lool: git tree has the source code in a subfolder
[15:03] <berco> lool: am not really allowed to change this and I created the orig.tar.gz with the simple "git archive" command
[15:03] <lool> berco: You could either tell your package to build in a subfolder rather than build from the top, or you could release tarballs from the proper level?
[15:04] <berco> lool: might be simpler in my case to build from the subfolder until the upstream maintainer modifies the git tree
[15:04] <lool> berco: Without moving files in the git repo, could you strip a component when creating the tarball?
[15:05] <lool> berco: Ok; if you're not upstream, then just go for the sub-folder build
[15:05] <lool> berco: Set DEB_SRCDIR near the top of your rules if you're using cdbs
[15:05] <berco> lool: yes, am using cdb
[15:06] <lool> The default is ".", you could set it to subfolder or to $(CURDIR)/subfolder if you need an absolute pathname
[15:06] <berco> lool: cdbs. I will try this, that sounds the most reasonable at this point
[16:48] <in-game> anybody formilliar with the sharp netwalker?
[16:56] <lag> in-game: What's up?
[16:57] <GrueMaster> in-game: persia might be the one to ask, but he's on holiday.
[16:57] <GrueMaster> I believe he has one, though.
[16:57] <in-game> ahh ok
[16:57] <in-game> sweet device but the ubuntu running is 9.04
[16:57] <GrueMaster> yep.
[16:58] <in-game> so i am searching for a  way to upgrade somehw
[16:58] <in-game> now running lxdm to make it some faster
[16:58] <amitk> in-game: unlikely you'll be able to upgrade
[16:58] <GrueMaster> I don't think it supports 10.04.  Iirc, it was a hardware issue.
[16:58] <amitk> the kernel hasn't been mainlined
[16:59] <in-game> thought so
[16:59] <in-game> pitty, the arm packages are some what lagging behind
[17:00] <amitk> in-game: it is mostly kernel and any binary drivers if reqd.
[17:00] <GrueMaster> There were some hardware changes between 9.04 & 10.04.  The newer kernels in 10.04 were never made to support the older hardware rev.
[17:00] <npitre> ukleinek: sorry
[17:01] <GrueMaster> If you are kernel savvy, you could probably forward port the changes though.
[17:01] <amitk> in-game: the rest of the arm packages have been carried forward just fine
[17:02] <in-game> ok, yeah i wanted to update lxdm because of the network xplore function
[17:03] <GrueMaster> Unfortunately 9.04 packages are built for ARMv5 and 10.04 were built for ARMv7.  It would be like running x86_64 code on an Intel Pentium (P5).
[17:04] <amitk> in-game: you could enable the lucid repo in /etc/apt/sources.list and only upgrade certain packages
[17:04] <amitk> GrueMaster: the processor is a ARMv7
[17:04] <GrueMaster> amitk: The processor may be, but the kernel doesn't have support for it.
[17:04] <in-game> amitk tried that, but it deleted my x packages somehow
[17:05] <in-game> tried it twice now
[17:06] <amitk> GrueMaster: in-game does NOT want to upgrade the kernel, just the desktop. He can do that if the dependencies were carried over correctly
[17:07] <amitk> in-game: it is quite possible that the new version of the desktop brings in a new version of X which ofcourse doesn't have new version of some display driver or similar. That could kill your X
[17:09] <in-game> yups.
[17:10] <in-game> so hm first uprade the x
[17:10] <in-game> can add 10.04 to the repro and upgrade just without the kernel?
[17:11] <amitk> in-game: are you trying a 9.04->10.04 upgrade direct?
[17:11] <in-game> hmm
[17:11] <in-game> yeps
[17:11] <amitk> that is probably untested. Have you tried a 9.04->9.10 ?
[17:11] <in-game> maye first 9.10
[17:11] <in-game> not yet
[17:12] <in-game> heh that is pretty good one :)
[17:12] <NCommander> amitk: in-game: this is probably a bad idea. Netwalker kernel is very dated, and doesn't have proper thumb2 handling support which is required for lucid (you might get karmic to work)
[17:13] <amitk> NCommander: that is what I just suggested ^^ :)
[17:13] <in-game> yep :)
[17:13]  * NCommander brain farts, and goes to hide in a corner
[17:15] <in-game> no need for hiding, I tried it twice.... ><
[17:16] <amitk> hehe
[17:21] <in-game> Well lets try a update!
[17:21] <in-game> thanks for the info people
[17:21] <in-game> Speak to you later, if it works I will be back soon
[20:52] <ojn> Lucid isn't built with neon enabled by default, right?
[20:54] <cwillu_at_work> neon in what?
[20:54] <cwillu_at_work> libpixman includes neon routines for instance
[20:54] <cwillu_at_work> but as far as I know, gcc never outputs neon instructions automatically
[20:54] <ojn> huh. that won't run on Dove then...
[20:55] <slangasek> various packages include neon-optimized routines as alternatives but they're expected to work on non-neon systems too
[20:55] <cwillu_at_work> I'll check, but I'd expect there to be guard clauses
[20:55] <cwillu_at_work> exactly
[20:55] <armin76> ojn: its not
[20:56] <ojn> ok, thanks.
[20:56] <armin76> ojn: last time i checked ubntu had an old version of pixman which didn't had the neon routines
[20:57] <armin76> iirc pixman compiled automatically with neon, but it gets disabled/enabled at runtime
[20:57] <armin76> ssvb: is the master here :D
[20:59] <cwillu_at_work> armin76, pixman-0.16.4 has some neon fastpaths
[20:59] <cwillu_at_work> I'm looking at apt-get source libpixman-1-0
[21:00] <cwillu_at_work> doesn't have the more recent work done in january though
[21:01] <armin76> cwillu_at_work: as i said, ssvb should know for sure :)
[21:01] <cwillu_at_work> armin76, argument screens off authority :p
[21:01] <armin76> iirc the neon stuff was reworked on >0.16 by ssvb itself :)
[21:01] <cwillu_at_work> i.e., I'm looking at the source code :)
[22:44] <lool> ojn, armin76, cwillu_at_work: lucid's and maverick's pixman have some NEON bits which are detected at runtime (via /proc/self/auxv)


[00:38] <Moto33> hello?
[00:41] <sarnold> oh great now I'm going to have those old "HELLO MOTO" commercials stuck in my head
[00:44] <Eickmeyer> sarnold: XD
[00:47] <sarnold> :D
[00:47] <theorem> :D
[00:47] <theorem> \o\
[00:47] <theorem> \o/
[00:47] <theorem> /o/
[01:38] <gorgon> Hi, how do I record, view, and playback waveforms from my microphone?
[01:38] <gorgon> ups?
[01:38] <gorgon> Oh that was not an answer to me
[01:38] <gorgon> sorry
[01:38] <matsaman> gorgon: ups
[01:38] <matsaman> j/k =)
[01:39] <gorgon> ha ha
[01:39] <matsaman> gorgon: do you want a GUI app or commandline?
[01:39] <gorgon> commandline is preferable
[01:39] <gorgon> I use KDE
[01:39] <gorgon> anything lightweight will do actually
[01:39] <matsaman> you might have 'arecord' already
[01:39] <matsaman> playback ... I would use
[01:40] <gorgon> ahh thanks
[01:40] <matsaman> mplayer or mpv, but 'aplay' is probably also something you have
[01:40] <gorgon> wow how cool is that thanks!
[01:40] <matsaman> view is a special one, I don't think I would bother searching for something that would visualize a waveform in a terminal
[01:40] <gorgon> Oh and do you know how I can view the waveforms?
[01:40] <matsaman> most people use the GUI app 'Audacity' and call it a day
[01:40] <sarnold> 'view' sounds a bit like you want audacity
[01:40] <gorgon> I mean I could open a Jupyter Notebook I guess
[01:40] <matsaman> sarnold: indeed
[01:40] <sarnold> heya matsaman :)
[01:40] <gorgon> ok!
[01:41] <matsaman> I'm sure you could find a script to generate the waveform
[01:41] <matsaman> and even pass it to libcaca for an ascii representation
[01:41] <matsaman> if you like pain a lot
[01:41] <gorgon> Oh and while we're on the topic of viewing
[01:41] <gorgon> something I wondered for a hilw
[01:41] <matsaman> generate the waveform visual*
[01:41] <gorgon> and on the topic of console -
[01:41] <gorgon> Is there a console command that can show an image on the console?
[01:41] <gorgon> Of course, approximately
[01:41] <matsaman> gorgon: as in without X running?
[01:41] <matsaman> or just in a terminal?
[01:41] <gorgon> e.g. "aview abc.jpg"
[01:41] <gorgon> just in terminal
[01:42] <matsaman> I would use 'display' from imagemagick
[01:42] <gorgon> with as much color as possible
[01:42] <matsaman> but there are hundreds of image viewers
[01:42] <gorgon> Wow I used imagemagick I didn't know that it has display!
[01:42] <matsaman> if you want it _in_ the terminal, few terminals do that, but some do
[01:42] <gorgon> I'm gonna try it right now
[01:42] <matsaman> and you can always use something like libcaca to ascii-ize it
[01:42] <sarnold> gorgon: w3m-img can do it
[01:43] <sarnold> hmm, my first attempt it appeared to start an X program :/
[01:43] <gorgon> oh `magick display abc.jpg` opens an image using my X
[01:44] <matsaman> gorgon: you don't want to use X?
[01:44] <ravage> gorgon: if you want to go totally crazy on the console: https://github.com/fathyb/carbonyl/releases :D
[01:44] <matsaman> gorgon: displaying an image without X running is a different beast
[01:44] <gorgon> Yeah I'm generally fine with X, but sometimes I want to just use the console to quickly confirm an image you know
[01:44] <matsaman> gorgon: you would have to setup some framebuffer implementation, or use libcaca
[01:44] <gorgon> especially when I'm using an ssh session
[01:45] <matsaman> probably libcaca will be the easiest, although it's not going to be pretty frequently
[01:45] <matsaman> http://caca.zoy.org/static/images/stitch-80x45.png
[01:46] <gorgon> Huh carbonyl looks interesting!
[01:46] <sarnold> this guy suggests tiv or ranger https://www.baeldung.com/linux/view-images-from-terminal
[01:46] <gorgon> Will check it out later
[01:46] <arraybolt3> ravage: Sheesh, that Carbonyl thing is amazing.
[01:46] <arraybolt3> Might try it :P
[01:46] <ravage> it is!
[01:47] <gorgon> libcaca sounds great
[01:47] <gorgon> wasn't there a different library like that earlier
[01:47] <gorgon> ncurses?
[01:48] <matsaman> well curses is a different thing
[01:48] <gorgon> ok
[01:48] <matsaman> curses/slang/et al, are for terminal-based UI
[01:48] <sarnold> curses is something else, think more menu-driven programs
[01:48] <matsaman> and libcaca is for ascii-izing imagery, basically
[01:48] <sarnold> libaa was the first thing like libcaca that I heard of
[01:48] <gorgon> Wow libcaca is 10 years old
[01:48] <sarnold> back in school I watched a bootleg rip of the matrix with libaa, because of course I did
[01:49] <gorgon> I mean the last release was 9 years ago: http://caca.zoy.org/wiki/libcaca
[01:49] <gorgon> but that probably means there's nothing more to add
[01:49] <gorgon> as long as they compile it with all the recent security fixes it should be safe enough i suppose?
[01:51] <gorgon> Also I'll install Audacity if that's the best GUI viewer for Linux
[01:51] <gorgon> Thanks for all the suggestions!
[01:52] <sarnold> gorgon: audacity is an *audio* tool btw ;)
[01:54] <gorgon> thanks it seems really good
[01:57] <gorgon> The UI looks a bit out of place, more like Windows 3x
[01:57] <gorgon> Probably it's not a KDE application
[01:57] <gorgon> but it seems to be well maintained despite the looks
[01:58] <gorgon> Last code merge was just 16 hours ago
[01:58] <sarnold> it started in the same era, wikipedia says its first release was may 28, 2000
[01:58] <sarnold> (I was guessing earlier than that, heh)
[02:00] <matsaman> there is probably a KDE-oriented alternative, but you're going to find plenty of irreplaceable apps that aren't KDE oriented
[02:00] <matsaman> so probably best to get over that now (or spend ages setting up themes to make such apps look native)
[02:01] <gorgon> Nah I'm good with audacity
[02:01] <gorgon> If it's the gimp of audio, which it seems to be
[02:01] <matsaman> it is
[02:02] <sarnold> there's a kde non-linear video editor kdenlive that loads of people like; it *might* be able to do audio things, too, but it'd be an afterthought for them
[04:58] <zbu> halo
[05:15] <circle> The kubuntu 22.04.2 installer ISO -> USB has a partition named "writeable". This is a great advance. Is there anything I can do short of shutting down when I insert another USB which also has a partition named "writeable". Problem is that /var/log of the running OS is written on "writeable" *by name*, and then I cannot unmount the writeable
[05:15] <circle> partition on the second USB.
[05:16] <rbox> youc an disable automounting
[05:30] <circle> That would be a preventative measure, yes.   But is there a way to untangle two partitions once it occurs?
[05:32] <rbox> well yo uahent shown any output or error messages
[05:32] <rbox> so theres only so much one cay say...
[06:53] <LifeIsSoEZEZEZ> seexuntu
[06:53] <LifeIsSoEZEZEZ> o_o
[07:07] <shadowhawk> hello
[07:13] <LifeIsSoEZEZEZ> printf ("slave world");
[07:16] <circle> Is it conceivable that resetting the BIOS on an older machine (pre-2019) could make the recent Ubuntu installers no longer boot in secure mode?   I do not find an apt package named boot-repair
[08:28] <StyXman> is there any way I can disable the notification that says "Pending update of firefox snap. close the app to avoid disruptions (8 days left)"? it keeps nagging me for DAYS
[08:31] <akik> :)
[08:31] <akik> the new normal
[08:32] <StyXman> 9:32 I close it
[08:32] <StyXman> let's see how long (short) it takes to appear again
[09:36] <ice9> which component I should file a bug for USB transfer speed issues ?
[09:42] <shadowhawk> hey
[09:43] <bittin> hi
[09:50] <wwwi> hello, I can't connect to my Windows shared folder, I give credentials, then the credientials pop up is presented again, I type them again and then it perpetually keeps thinking
[09:50] <wwwi> any ideas?
[09:51] <shadowhawk> oh wow
[09:51] <shadowhawk> the problems we have here
[09:51] <shadowhawk> i hope we get some good answers!
[09:59] <blackmushroom> Can anyone help me?!?! too many kworkers process and mad cpu single core overload
[10:13] <kalilinux> hii friends
[10:13] <kalilinux> good morning
[10:14] <kalilinux> best alternative of microsoft office in linux except libreoffice
[10:14] <kalilinux> ???
[10:15] <dsc_> vim
[10:15] <kalilinux> vim ?
[10:16] <kalilinux> oo iget it
[10:16] <kalilinux> vim is a text editor
[10:16] <kalilinux> in linux
[10:17] <kalilinux> but i want some office app like word, excel, powerpoint
[10:17] <kalilinux> i found onlyoffice
[10:18] <kalilinux> its interface is same as MS Office
[10:19] <kalilinux> hii otisolsen70_
[10:19] <kalilinux> how are you my friend
[10:19] <kalilinux> i am fine
[10:19] <kalilinux> and you?
[10:19] <kalilinux> i hope ypu are well
[10:20] <kalilinux> and doing some works in your life
[10:20] <kalilinux> why in this channel no one talk
[10:21] <kalilinux> when i am using linux mint last year
[10:21] <kalilinux> many of them were chating
[10:21] <kalilinux> and discussing about linux and apps
[10:21] <EriC^^> !offtopic | kalilinux
[10:22] <kalilinux> and something realted to operating system
[10:22] <kalilinux> my username is kalilinux but i am on ubuntu 20
[10:23] <kalilinux> i choose my username kalilinux bcoz its sounds cool.
[10:49] <danjalical> huh, its my year to this day when I told myself I would run ubuntu for good
[10:49] <danjalical> I just realised
[10:55] <kalilinux> hii
[10:59] <wwwi> hi, I managed to access my Windows Shared folder from Ubuntu and nautilus sees it, but applications don't see it
[10:59] <wwwi> any ideas why?
[11:07] <ravage> wwwi: usually you see them in $XDG_RUNTIME_DIR/gvfs
[11:08] <ravage> on a default installation that should be /run/user/1000/gvfs/
[13:02] <BluesKaj> Hi all
[13:13] <jacob-vlijm> Hey!
[15:05] <lmat> When I   dpkg -S "$file"; I get "libace-7.0.6: /usr/lib/x86_64-linux-gnu/libACE_Monitor_Control-7.0.6.so". Then when I "apt purge libace", I get "E: Unable to locate package libace". Does this mean my system is broken or is there some other mechanism by which a package might be installed and providing a file, but I can't remove the package?
[15:06] <aiena> Is there a way to hide all those disk drive icons that show up in the Activities?
[15:06] <aiena> I mean mount points
[15:07] <lmat> aiena: I assume you don't want to unmount the filesystems? ;-)
[15:08] <aiena> lmat, the file systems are not mounted
[15:08] <aiena> but those icons show up giving a choice to mount them
[15:08] <aiena> they flood the activities sidebar
[15:08] <aiena> trash + mountpoints
[15:09] <aiena> err mountable partitons
[15:09] <aiena> maybe something of gvfs
[15:09] <aiena> e.g. mount 300gb volume, mount 41 gb volume etc....
[15:10] <aiena> the fs's are not mounted I just dont like those icons its ok in the file manager but why in the main Activities ribbon?
[15:11] <aiena> but it shows up in the running apps part
[15:13] <aiena> their icons to "Other locations" in the file manager
[15:13] <aiena> *they're
[15:14] <aiena> but only drives excluding the os root
[15:14] <jhutchins> lmat: Try dpkg -l | grep libace
[15:14] <jhutchins> lmat: You might simply try libace-7
[15:16] <ice99> .mp4 and .vid files are not playing in Videos, they only work in VLC, any idea?
[15:25] <jhutchins> ice99: Play them in VLC.
[15:26] <jhutchins> ice99: Make VLC the default app to open those file types.
[15:26] <leftyfb> lmat: sudo apt purge libace-7.0.6
[15:27] <ice99> I added Nextcloud account to online accounts but calendars and contacts doesn't show up in gnome even after relogin, any idea?
[15:30] <lmat> leftyfb: That worked! I'm surprised...I didn't think I needed to provide the version. Thank you!
[15:47] <akik> snap list in 22.04 says that firefox was published by mozilla. did they create the snap?
[15:47] <leftyfb> yes
[15:53] <jhutchins> lmat: It's hard to tell when there are version numbers that are part of a package name - and how much of the number is required.
[15:56] <wasutton> alright, it looks like the libvirt issues started with the jump from 20.04.4 to 20.04.5
[17:03] <WeeBey98> anyone ever get like... blinking windows or the taskbars on Gnome?
[17:05] <jhutchins> WeeBey98: Does your TV ever do that?
[17:06] <WeeBey98> Used to. I just hit it on the side. ;)
[17:06] <WeeBey98> I think something is funky with graphics drivers recently, but I'm not sure what it could be. It started happening last week.
[17:08] <jhutchins> WeeBey98: Remember there's a huge variety of hardware combinations out here.
[17:08] <jhutchins> WeeBey98: Although that sounds like it could be a hardware issue.  Loose connector or something.
[17:08] <WeeBey98> I know. Just sometimes something gets pushed out with some bug.
[17:08] <WeeBey98> jhutchins, Nah. it's only certain windows or panels.
[17:09] <WeeBey98> As if the rendering of that windows is acting up.
[17:09] <WeeBey98> not too serious. Just checking if anyone saw a siimlar thing recently. It happens.
[17:10] <oerheks> WeeBey98, on wht graphics card?
[17:11] <WeeBey98> oerheks, nvidia rtx 3070 mobile
[17:12] <oerheks> What kernel version? uname -a
[17:13] <WeeBey98> 6.1.12 (imma get in trouble lol)
[17:13] <oerheks> no, this is a known issue for windows too, often  too high refreshrate 144
[17:14] <WeeBey98> this display is 165hz
[17:14] <oerheks> up to 120 it could work fine..
[17:15] <WeeBey98> next time i'll see it i'll change the refresh and see.
[17:15] <WeeBey98> Thanks for the tip oerheks
[17:15] <oerheks> yw
[17:48] <supay> what does it mean when the dependency says `gnome-shell >= 40.0`?
[17:48] <supay> does it mean >= 3.40.0 or something else?
[17:49] <supay> also, can i upgrade my gnome-shell to 3.40.0 on ubuntu 20.04
[17:56] <tomreyn> supay: it means version 40.0 or higher.
[17:58] <tomreyn> and no, you should not try to upgrade gnome packages without also upgrading to a newer ubuntu release.
[17:58] <tomreyn> 20.04 LTS can be upgraded to 22.04 LTS
[18:00] <tomreyn> gnome moved to version numbers 40 and higher for what could also have been the 4.0 release, similar to other software such as some web browsers (firefox, chromium) https://packages.ubuntu.com/search?keywords=gnome-shell
[18:46] <supay> tomreyn: ahh, i see. that makes a lot of sense. thank you! :)
[18:47] <tomreyn> you're welcome
[19:36] <Floating4> whats the eqiv of ping -t in ubuntu terminal?
[19:36] <ravage> ping
[19:37] <sarnold> ping -t ?
[19:37] <Floating4> its -b  -- continious
[19:38] <ravage> that should be the default
[19:38] <ravage> -> ping
[19:38] <Floating4> well look at that - learn something every day
[19:38] <ravage> and b is broadcast ping on linux
[19:38] <Floating4> I see that now
[19:57] <jhutchins> Floating4: There's a man page for ping - man ping
[20:13] <tim95> Does anyone here know how to interpret dbus-monitor output?
[20:24] <saunders> my keyboard:  https://askubuntu.com/q/1449887/847449      an old question, but never figured out how to take a screenshot with the "printscreen" key as "windows-shift-s" on Microsoft Windows.  The "print" key is rather odd on this keyboard.
[20:27] <Gallomimia> pardon me... how can i verify a USB stick is bootable, using ubuntu
[20:27] <Gallomimia> i guess i could always try to boot from it...
[20:29] <akik> Gallomimia: you can try to boot it with qemu-kvm
[20:31] <Gallomimia> well i installed that easily enough. but here we hit a wall. got manual?
[20:31] <akik> Gallomimia: i think the minimal set of options was: sudo qemu-kvm -m 1024 /dev/sdX
[20:31] <akik> or if you fix the permissions on /dev/kvm, just: qemu-kvm -m 1024 /dev/sdX
[20:32] <Gallomimia> oddly enough, of all the commands available starting with qemu now, kvm is not one of them
[20:33] <akik> Gallomimia: yea i noticed that earlier. try to use qemu-system-x86_64
[20:34] <arraybolt3> Gallomimia: qemu-system-x86_64 -enable-kvm -m 4096 -smp 2 -hda /dev/sdx
[20:35] <arraybolt3> ^ that should work fairly well with Ubuntu Desktop, there are other variants on that command if you need something specific or less resource-intensive.
[20:35] <Gallomimia> wow. yeah i'm giving up on that. just trying to get a USB that's bootable. used dd on another machine to flash an iso, but that machine won't boot it
[20:35] <arraybolt3> Gallomimia: Is it a BIOS machine? And by "won't boot", does it not even try, or does it try but freeze during bootup?
[20:35] <Gallomimia> thanks for the suggestion. i'll read more about qemu later. it sounds like it will do some other things that i'd like
[20:35] <Gallomimia> yes, yes
[20:35] <arraybolt3> Ah, that's a known bug, just leave it "frozen" and it will figure itself out in 10 minutes or so.
[20:36] <akik> Gallomimia: if the iso image is not for uefi boot, change your uefi to boot in bios or csm mode
[20:36] <arraybolt3> Only affects booting the ISO, the installed system won't have the slow boot.
[20:36] <arraybolt3> I'll try and find the bug report.
[20:36] <Gallomimia> no it won't. the machine in question is like 12-15 years old, and we're trying to boot win7
[20:36] <Gallomimia> it's running manjaro but it's pretty darn slow, and the fellow who wants to use it is not too interested in linux at all. so... now we're off topic
[20:37] <arraybolt3> Gallomimia: Ah.
[20:37] <leftyfb> Gallomimia: manjaro is also offtopic here
[20:38] <arraybolt3> leftyfb: They're trying to test a bootable USB on Ubuntu I assume, that would be on-topic regardless of the OS on the ISO or the final target system, since whether it boots or not is the problem, not what it is that is being booted.
[20:38] <arraybolt3> And Ubuntu's qemu-system-x86_64 can do that.
[20:38] <Gallomimia> yeah i'm trying to use my ubuntu machine to check and see if the USB stick is bootable
[20:39] <leftyfb> oh, it looks like they had a manjaro machine trying to test a win7 installer usb
[20:39] <akik> Gallomimia: there's a command isohybrid that converts non-isohybrid isos to isohybrid
[20:40] <Gallomimia> as in.... efi/bios hybridness?
[20:40] <Gallomimia> isohybrid
[20:40] <Gallomimia> wrong window
[20:40] <arraybolt3> isohybrid I think makes a "can only boot from a DVD drive" ISO file also bootable from a USB drive when you dd it.
[20:41] <Gallomimia> OH!
[20:41] <arraybolt3> But also, Windows doesn't take too kindly to being straight dd'd to a drive - WoeUSB might be better.
[20:41] <Gallomimia> that's probably a big deal
[20:41] <Gallomimia> what is a woeUSB
[20:41] <arraybolt3> It won't need isohybrid. I've used it several times.
[20:41] <arraybolt3> https://github.com/WoeUSB/WoeUSB
[20:41] <arraybolt3> (Not officially supported, but if that's what you're doing anyway, may as well give an easy option.)
[20:41] <arraybolt3> s/several/twice/
[20:41] <arraybolt3> s/twice/thrice/ (ok so it was several :P)
[20:42] <Gallomimia> lots of options to look into. sounds like Future-gallo's problem
[20:42] <arraybolt3> or whatever, I'm mis-remembering things. You know what I mean. Use that tool, will make bootable Windows stick :D
[20:42] <arraybolt3> Anyway, /me stops going off-topic
[20:43] <akik> Gallomimia: i have the commands to make a windows iso able to boot from a usb stick if you need those
[20:43] <akik> Gallomimia: it's a matter of copying the files
[20:43] <ravage> the woeusb script really does a good job and is easy to use
[20:44] <akik> ravage: it's just a script with many dependencies?
[20:44] <ravage> it has some dependencies yes
[20:45] <ravage> i think most required for basic operation are part of a default ubuntu desktop install
[20:45] <ravage> if not all
[20:45] <arraybolt3> I had to install wimtools to make it work.
[20:46] <arraybolt3> Everything else was there.
[20:46] <ravage> that is not required for a simple iso to usb transfer
[20:46] <ravage> (to a ntfs usb)
[20:47] <arraybolt3> I was flashing Win10 ISOs to what I believe was a FAT32 USB (that was what it did by default), so it needed it for me. Win7 is smaller and might not need it.
[20:48] <ravage> yep. should not be needed with --tgt-fs ntfs
[20:49] <arraybolt3> OK, brb, trying something real quick...
[20:53] <akik> ravage: is --tgt-fs a woeusb option?
[20:53] <ravage> Yes
[21:25] <nsaunders> is there something like monitors.xml for wayland?  Previously available resolutions are no longer available.
[21:51] <telmac> chrome is crashing every time I start it, sometimes it lasts for a few seconds, sometimes it dies immediately
[21:51] <telmac> one sec i'll post a log
[21:52] <telmac> https://paste.debian.net/1274840/
[21:52] <matsaman> telmac: try chromium, I don't think any chrome you'd get would be anything but a really terrible upstream binary
[21:52] <matsaman> that is: built by google
[21:52] <telmac> I'm figuring it's line 7
[21:52] <telmac> there was some actual reason why I wanted chrome proper
[21:53] <telmac> my recollection is that I used chromium on debian maybe 7 years ago and it was noticeably worse than google's chrome packages
[21:53] <telmac> maybe this is moot now
[21:54] <matsaman> academic*
[21:54] <matsaman> on the one hand, yes, you're more likely to get Google's upstream features working in chrome
[21:54] <matsaman> on the other hand, the build is going to be really bad
[21:55] <telmac> hum hum
[21:55] <sarnold> what an unhappy log :/ each of those could have been a cause for the failure
[21:55] <matsaman> anyone it should be easy to try chromium and see if it's missing something, now
[21:56] <telmac> yeah I'm setting things up now
[21:56] <telmac> I see it's on the same official version number which is reassuring
[21:57] <matsaman> anyway* it should, wow
[21:57] <telmac> I have a chrome adjacent question, unrelated
[21:57]  * ogra agrees that anyone shoudl try chromium ....
[21:57] <ogra> 🙂
[21:57] <ogra> once at least
[21:57] <telmac> so there's a problem with wayland support in vscode
[21:57] <telmac> inb4 you say to use vscodium
[21:57] <matsaman> some old backstory if you're bored: https://spot.livejournal.com/312320.html
[21:58] <sarnold> wow, that is *the* spot
[21:58] <matsaman> telmac: use vscodi... aw
[21:58] <sarnold> lol
[21:58] <telmac> I *believe* I actually tried ubuntu's vscodium packages and they have the same problem, but apparently the packages in arch's repos *don't* which is interesting
[21:58] <matsaman> so what's the problem?
[21:58] <telmac> basically, you can pass electron apps a flag to use wayland natively
[21:59] <matsaman> neat
[21:59] <telmac> this is relevant specifically for hidpi support, otherwise I wouldn't really care
[21:59] <telmac> and this works fine with obsidian and slack, but it's broken in vscode
[21:59] <telmac> I think it's actually some larger problem that vscode is like refusing all flags or something
[22:00] <telmac> ah, ok, a legitimate reason not to use chromium: it doesn't support google's sync
[22:00] <matsaman> doesn't it?
[22:01] <telmac> https://www.reddit.com/r/chrome/comments/ly7dn8/no_option_to_sign_into_chromium/
[22:01] <telmac> (I also can't find a login button anywhere in the interface)
[22:01] <ogra> i use a hidpi (4k 13" dell laptop) here and had to recently tst the code snap for someone ... it was totally fine WRT scaling and resolution on wayland
[22:01] <telmac> interesting
[22:01] <telmac> I'm not using the snap, I think I'm using MS's .deb lol
[22:02] <ogra> that shouldnt really make a difference one would hope ...
[22:02] <telmac> one would hope
[22:02] <ogra> 🙂
[22:05] <telmac> @ogra, I just reinstalled it with snap, doesn't seem to help, let me try the electron flag again
[22:06] <telmac> what version do you have? (of vscode)
[22:06] <ogra> i didnt have to use any flag ...
[22:07] <telmac> so indeed it doesn't help with the flag, same error as I was getting a while back:
[22:07] <ogra> it was a few weeks ago and i tested for someone else, it is uninstalled again ... but back then i installed from the latest/stable snap channel whetever was recent in there
[22:07] <telmac> ~$ code --enable-features=UseOzonePlatform --ozone-platform=wayland
[22:07] <telmac> Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.
[22:07] <telmac> Warning: 'ozone-platform' is not in the list of known options, but still passed to Electron/Chromium.
[22:07] <ogra> thats fine, just a warning ...
[22:07] <telmac> well, but then it just didn't open anything
[22:07] <telmac> I'm not very knowledgeable about snap, is the repository the "same" for everyone?
[22:07] <ogra> right
[22:08] <ogra> its a single package per channel for every distor/relese you install it on
[22:08] <ogra> *distro or release
[22:09] <ogra> technically it should work the same everywhere
[22:09] <telmac> (and like, out of the box looks like it's rendering at a lower res etc)
[22:09] <telmac> well I'm running 22.10
[22:09] <ogra> ah, 22.04 here
[22:09] <telmac> oh interesting
[22:09] <ogra> might be related to gnome shell  ?
[22:10] <telmac> wait what compositor are you running
[22:10] <telmac> ohhhhhh
[22:10] <ogra> default ubuntu desktop
[22:10] <telmac> right
[22:10] <telmac> so I think this *was* fine in gnome shell but I think I was also running at 100% in gnome shell with some stupid "large text" thing on
[22:10] <ogra> (well, a bunch of extensions and hacks ... but largely default 🙂 )
[22:11] <telmac> and then I switched to sway recently and now this is broken
[22:11] <ogra> aha
[22:11] <telmac> I mean I could go check in gnome if it has this problem with fractional scaling
[22:13] <telmac> ok well now chrome is no longer crashing
[22:13] <telmac> ho hum
[23:34] <saunders> Is there something like lspci to show my monitor details?
[23:35] <arraybolt3> xrandr?
[23:37] <sarnold> edid-decode or read-edid perhaps?