[03:53] <Unit193> Did you folks have any plans to do anything with epubs?  I remember talk a bit back about sigil, but pretty sure that didn't go anywhere...
[04:04] <JoseeAntonioR> hey Unit193, akgraner and silverlion were the ones on that stuff
[04:10] <skellat> Unit193: Convert the MoinMoin markup to Markdown or HTML and then turn "pandoc" loose on it and you'll get epubs generated.  It would need some fine-tuning but it could be done.
[04:10] <Unit193> skellat: Not what I was asking.
[04:11] <Unit193> JoseeAntonioR: Yeah, know what came of it?
[04:11] <JoseeAntonioR> nope, at all
[04:12] <Unit193> Ok, thanks.
[06:49] <dholbach> good morning
[12:31] <akgraner> JoseeAntonioR, no time on my schedule at the moment for the epubs
[12:32] <Unit193> Ah, alright.  I was looking at the nightmare they call sigil, and updated the packaging (such that it is) for the new release (based on qt5, which isn't fully functional in raring but builds in saucy.)
[12:35] <akgraner> Unit193, I think there are some other ways we can do an epub, but I won't have anytime until after 13 July when I get back from Dublin (Linaro Connect Europe)
[12:37] <Unit193> No problem at all, if you want to look into pre-built debian install... (non-official quality)
[22:20] <jono> pleia2, hey
[22:20] <jono> are you around?
[22:22] <pleia2> jono: hey
[22:22] <jono> pleia2, hey, about set to announce the certificates
[22:22] <jono> if I send a post would you mind putting it on the fridge?
[22:22] <pleia2> jono: sure
[22:22] <jono> thanks, will be 2 mins
[22:24] <jono> pleia2, http://pastebin.ubuntu.com/5766151/
[22:24] <jono> thanks!
[22:24] <jono> oops
[22:24] <jono> need to fix it
[22:24] <jono> missed the end of a line
[22:25] <jono> pleia2, ok, http://pastebin.ubuntu.com/5766157/
[22:25] <jono> sorry about that
[22:27] <pleia2> jono: done http://fridge.ubuntu.com/2013/06/14/certificates-for-ubuntu-members/
[22:28] <jono> thanks pleia2!


[09:37] <JonathanD> Morning.
[09:54] <rmg51> morning JonathanD
[09:54] <JonathanD> Hello rmg51!
[09:54] <rmg51> o/
[09:54] <JonathanD> still 112.
[09:54] <rmg51> it's early yet
[09:55] <rmg51> and you still have 6 days before the big event
[09:56] <rmg51> counting today
[09:58] <JonathanD> Yes.
[09:58] <JonathanD> I hope we have enough chairs.
[10:01] <rmg51> standing room only! :-D
[10:03] <JonathanD> well, we have 140
[10:03] <JonathanD> but we have to split them up
[10:03] <JonathanD> so the keynote may well be standing room only.
[10:03] <JonathanD> either that or "everyone grab a chair!"
[10:04] <JonathanD> Going to try to scare up a last minute sponsorship this week and get tomato pie.
[10:37] <jedijf> tomato pie \o/
[10:39] <jedijf> JonathanD: i wouldn't sweat lunch type stuff, the local businesses would appreciate the saturday rush
[10:39] <JonathanD> I suppose :P
[10:39] <jedijf> there's a little joint right across the street and cocoos bar and grill around the corner
[10:39] <jedijf> coccos
[10:40] <JonathanD> we might overrun the place across the street.
[10:40] <jedijf> coccos isn't bad
[10:40] <JonathanD> going down today to drop off stuff.
[10:40] <JonathanD> Ya know. I need someone to bring some logs.
[10:40] <JonathanD> like, fireplace logs
[10:41] <JonathanD> maybe I can find some today.
[10:41] <jedijf> http://www.barfinder.com/listings/Coco-s-56953-details.aspx
[10:41] <PennBot> Title: Coco's 112 S 8th St Philadelphia, PA - BarFinder.com (at www.barfinder.com)
[10:41] <JonathanD> jedijf: how well do you know the area?
[10:42] <JonathanD> Think you could help me a bit with the printouts? I'm going to put maybe 4 local places on them.
[10:48] <jedijf> JonathanD: yeah, no prob, i'll get to it soon, trying to get caught up on some work emails
[10:49] <jedijf> i need to see if hive is going to do the open house on sunday too
[10:50] <jedijf> and the hours
[10:50] <jedijf> and if anybody needs any jewelry it's a homerun :P
[10:57] <JonathanD> they told me they were.
[11:53] <waltman> JonathanD: there's roughly 100 places to eat within a 5-10 minute walk
[12:16] <jedijf> waltman: i am getting hungry just looking/thinking about it!!!
[12:51] <waltman> maybe 200!
[14:13] <jedijf> JonathanD: waltman's right, it boils down to go any direction, find /somewhere/ to eat or drink
[14:13] <jedijf> plus if we name the good spots, where will we go?
[14:14] <jedijf> rmg51: you doing fosscon?
[14:14] <rmg51> prolly not
[14:14] <rmg51> still can't make up my mund
[14:23] <rmg51> what's a mund?
[14:33] <waltman> jedijf: Easy -- we name the BAD spots!
[15:00] <SamuraiAlba> Good bacon to all!
[18:07] <waltman> mmm, bacon
[21:24] <JonathanD> rmg51: yes, yes you are.
[21:24] <JonathanD> teddy said he wants to go
[21:49] <rmg51> JonathanD: Teddy can go anyplace he wants
[21:49] <rmg51> all he has to do is find a way to get there
[21:50] <rmg51> I may have to take Mom places on Sat.
[22:18] <waltman> Take Mom to FOSSCON!
[22:19] <rmg51> if you baby sit her ;-)


[02:41] <chloric> evening
[14:11] <reya276> Morning Everyone
[14:14] <DammitJim> morning reya276
[14:14] <DammitJim> guys, how dangerous are aliases in bash?
[14:14] <DammitJim> or in the shell in genearl?
[14:16] <maxolasersquad> DammitJim: As dangerous as you want them to be.
[14:16] <DammitJim> lol
[14:16] <maxolasersquad> I've never heard anyone argue against alias'.  If they are useful to you, then by all means use them.
[14:19] <dantalizing> morning
[14:22] <DammitJim> morn
[14:26] <mhall119> monring


[10:47] <hisacro> gehidore: /o\
[10:47] <hisacro> any queries?
[10:48] <hisacro> I'm just hanging here hoping one day I get to try a smart phone
[10:48] <hisacro> :)
[17:43] <gehidore> hisacro at this point I'll be doing a pixel 3a xl if they finally send me the right one on Tuesday
[17:43] <gehidore> they keep sending me the wrong model which isn't oem unlocked


[04:44] <pitti> Good morning
[04:45] <pitti> infinity: I don't think they were
[04:45] <pitti> infinity: I checked the upload log, and there was just one package that it tried to upload to ppa.launchpad.net, failed with "connection refused", and then it stopped
[04:46] <pitti> nothing else
[04:46] <pitti> infinity: the log timestamps coincide with the failed upload log at least
[04:46] <pitti> WTF??
[04:47]  * pitti mass-rejects
[04:49] <pitti> infinity: so this remains a complete and utter mystery to me; PPA upload seems broken again (firewall changes?), but then the script should (and according to the log, did) break, not upload to other places
[04:56] <pitti> infinity: oooh *headdeask* I know what happened
[04:59] <pitti> infinity: I guess the next time it auto-uploaded quantal packages, the failed list of precise/lucid packages were still in "updated-packages" (the file with the upload list), and so it uploaded those along
[04:59] <pitti> I'm not sure how that dodged the "if test -s updated-packages; then exit 1" command, though
[05:00] <StevenK> test -s updated-packages && exit 1 ? :-)
[05:00] <pitti> well, there's an echo in between as well
[05:00] <pitti> StevenK: but that should essentially be the same?
[05:01]  * pitti asks IS for fixing firewall rules
[05:01] <StevenK> pitti: Yeah, that's why I suggested it, it avoids an if, but since there's an echo there's no point.
[05:05] <pitti> aah, I know
[05:05]  * pitti fixes
[06:57] <dholbach> good morning
[07:13] <jamespage> morning all
[07:46] <tjaalton> i've forgot again.. how to disable multiarch on quantal? just getting rid of /etc/dpkg/dpkg.cfg.d/multiarch isn't enough
[07:46] <tjaalton> not that useful on chroots
[07:47] <tjaalton> at least when not mirroring i386 locally, making sbuild-update fail
[08:31] <jodh> /whois Daviey Daviey
[08:31] <jodh>
[08:32] <jodh> @pilot in
[09:33] <ev> mpt: we're getting kernel crashes sent to daisy.ubuntu.com. I know this because the code mistakenly attempts to insert their very large core files into Cassandra.
[09:34] <mpt> ev, that's a problem then, because (as far as I could tell from the code) the UI for that class of error doesn't exist, so whatever UI is being used to send them is bound to be confusing.
[09:35] <mpt> (doesn't exist yet, anyway)
[09:35] <ev> KernelCrash?
[09:35] <mpt> Hm, did I just read it and then completely forget it existed? :-]
[09:36]  * mpt looks again
[09:39] <mpt> ev, it calls get_system_application_title(), which shows "Sorry, Ubuntu has experienced an internal error." I guess that's strictly accurate, but not the intended text. <https://wiki.ubuntu.com/ErrorTracker#kernel-oops>
[09:41] <ev> indeed
[09:41] <ev> mind that we're only seeing these a few times a day
[09:41] <ev> and we don't have the ability to retrace them yet
[09:42] <ev> (lp:apport, bin/apport-retrace:354)
[09:42] <ev> that's not to say we shouldn't fix the dialog
[09:44] <mpt> Sure, though fixing bug 1033902 would be much more important if it happens much more often
[09:44] <ev> yeah, definitely
[09:45] <mpt> Annoying that that missed UI Freeze
[09:45] <mpt> ev, so do you think we're getting only a small percentage of kernel crashes from typically-reporting machines? "A few times a day" might actually be right, compared with (for example) 173/day for the current #1.
[09:46] <ev> I think so. If you look at https://errors.ubuntu.com/oops-local, any exception with MaximumRetryException is likely a kernel crash.
[09:49] <cjwatson> slangasek: A ucf prompt that isn't actually displayed to you seems like it must be a package management bug rather than a bug in the package
[09:51] <ev> mpt: I'll silently drop them at daisy.ubuntu.com and increment a counter for the day period so we at least know how many we would be getting
[09:55] <cjwatson> tjaalton: dpkg --remove-architecture i386
[09:57] <cjwatson> @pilot in
[10:02] <mpt> ev, there are four bugs apparently reducing the proportion of kernel errors reported: bug 401370, bug 480421, bug 527026, and bug 624562.
[10:03] <mpt> and I just reported bug 1051891 about the UI text.
[10:04] <ev> mpt: to be clear, kernel crashes and kernel oops are different
[10:04] <ev> the former is when you get a full kernel panic and it dumps its brain into a file (if it even can)
[10:04] <ev> the latter is a sort of recoverable error
[10:04] <ev> things keep chugging along and you get an OOPS! in the syslog
[10:05] <mpt> Ok ... they're treated the same in apport-gtk currently.
[10:05] <mpt> So, an oops *should* have the "Ubuntu just had an internal error" text, then
[10:05] <mpt> it's only a crash that shouldn't
[10:05] <ev> yes, I reckon
[10:05] <mpt> ?
[10:05] <ev> correct
[10:06] <ev> at least that's my understanding
[10:07] <mpt> updated the bug report
[10:10] <mpt> fixed the specification too <https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=97&rev1=95>
[10:14] <tjaalton> cjwatson: thanks, found it on the debin wiki too, added to the askubuntu question
[10:54] <didrocks> xnox: hey, is ubiquity still in gtk2 or using pygi?
[10:55] <xnox> didrocks: it's using pygi & python3
[10:55] <akheron> cjwatson: currently installing quantal beta 1 to another machine from exactly the same usb stick, and seems to work great
[10:55] <cjwatson> akheron: ok, I still have a task for today to investigate it though
[10:55] <akheron> cjwatson: fwiw, I had to use the nomodeset kernel option with the first one
[10:55] <xnox> didrocks: some elements do not use width-for-height widgets, e.g. there are GtkBox here and there.
[10:55] <cjwatson> nomodeset -> not my problem
[10:55] <akheron> with the machine that fails
[10:55] <akheron> ok
[10:56] <cjwatson> akheron: I didn't mean to say that the name server was broken, BTW, only that something had gone wrong with resolver configuration within the target chroot
[10:56] <didrocks> xnox: hum, ok, I'm wondering about bug #1049215 as gnome-bluetooth stacktrace is about using pygi as well
[10:56] <cjwatson> This is a plausible enough failure mode, sadly
[10:56] <didrocks> not sure what imported gobject
[10:56] <akheron> cjwatson: yeah
[10:56] <cjwatson> didrocks: ubiquity doesn't even support python2 any more
[10:57] <cjwatson> didrocks: but if it's calling some external process which uses python2, that's a different mattere
[10:57] <cjwatson> -e
[10:57] <cjwatson> yeah, bluetooth-applet
[10:57] <didrocks> cjwatson: I guess it's the case
[10:57] <cjwatson> nowt to do with ubiquity
[10:57] <cjwatson> it's pretty obvious from the traceback :)
[10:57] <didrocks> cjwatson: hum? bluetooth-applet is using pygi
[10:57] <didrocks>     from gi.repository import GObject
[10:57] <didrocks> ?
[10:58] <cjwatson> Wait, that's actually ubiquity's substitute bluetooth-agent
[10:58] <xnox> hmmm.... I totally missed that....
[10:59] <pitti> didrocks: I usually sudo vi /usr/share/pyshared/gobject/constants.py and do something like raise TypeError("not static")
[10:59] <didrocks> cjwatson: you lost me :)
[10:59] <pitti> this will give a proper backtrace which sub-sub-submodule imports the static bindings
[10:59] <cjwatson> didrocks: I lost myself for a bit
[10:59] <xnox> didrocks: ubiquity-dm fakes a desktop session and half of indicators to provide "ubuntu style session" which only shows ubiquity =)
[11:00] <xnox> but I didn't think bluetooth was one of them.
[11:01] <cjwatson> I can run the imports at the top of ubiquity-bluetooth-agent without any problem though
[11:01] <cjwatson> Puzzling.  Anyway I should get back to piloting ...
[11:02] <didrocks> xnox: cjwatson: I confirm gnome-bluetooth is using pygi
[11:02] <didrocks> xnox: did you reproduce it?
[11:02] <pitti> I've seen this strange EOFError on a totally different context recently (in a bug report); I think doko attributed it to mis-installation
[11:02] <pitti> bug 1029683
[11:02] <didrocks> xnox: if so, you can do what pitti is telling to know which component is the guilty one :)
[11:02] <xnox> didrocks: if you cannot reproduce, maybe something else happened, e.g. somebody yanked their installation media hence that file was actually empty / EOF =)
[11:03] <didrocks> possibly
[11:03] <doko> pitti, wasn't this one where the reporter even did say that the machine was hanging?
[11:03] <pitti> but as that's the third report in a few days, I'm beginning to become suspicious
[11:03] <cjwatson> didrocks: gnome-bluetooth is irrelevant
[11:03] <pitti> perhaps something does create zero-byte files somewhere
[11:03]  * didrocks retarget on xnox's plate then :)
[11:03] <cjwatson> didrocks: casper dpkg-diverts away the bluetooth-agent from gnome-bluetooth, and replaces it with a symlink to ubiquity-bluetooth-agent
[11:03] <pitti> doko: no, not this one; there might be more dupes, though
[11:04] <didrocks> cjwatson: ah ok, so the /usr/bin/ is not the one we can expect, thanks for the info :)
[11:04] <cjwatson> tumbleweed: looking at bug 1049343 and slightly puzzled by it being a sync - doesn't the reporter say there's a patch to be reapplied?  and he seems to be right
[11:05] <xnox> didrocks: ok ;-)(
[11:05] <xnox> didrocks: ok ;-)
[11:05] <tumbleweed> cjwatson: ah, whoops, I forgot about that
[11:06] <tumbleweed> cjwatson: I did ask him on IRC to prepare the patch, a week ago, and clearly he hasn't
[11:06] <tumbleweed> (and today, I just saw that it built, and remembered that it had seemed reasonable)
[11:07] <xnox> didrocks: looking at the code, there were GObject vs Gobject typos fixed in the past, maybe this is a bug report from an acient image?!
[11:07] <didrocks> xnox: hum, I think you would get an import error and not this "library mixture" error one (pygtk was gobject, not Gobject)
[11:08] <cjwatson> xnox: the report makes the image version clear
[11:09] <xnox> didrocks: cjwatson: yeah, it's a recent image and the import is the correct gi one GObject.
[11:45] <didrocks> hum, seems I can't nominate for Quantal anymore? https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1045845/+nominate
[11:45] <cjwatson> didrocks: screenshot?
[11:46] <ogra_> hmm, same for me with that link
[11:47] <ogra_> nothing between the precise and r-series checkboxes
[11:47] <didrocks> right, same
[11:47] <didrocks> cjwatson: do you still want a screenshot?
[11:47] <cjwatson> Yes.
[11:47] <cjwatson> Oh, wait, I see what you mean.  No.
[11:48] <didrocks> ok :)
[11:48] <cjwatson> You can't nominate for quantal because apparently it was already nominated for quantal and that bug task was then deleted.
[11:48] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1045845/+activity
[11:48] <didrocks> cjwatson: oh interested, I didn't know about that feature :)
[11:48] <ogra_> http://people.canonical.com/~ogra/quantal.png
[11:49] <ogra_> oh,. wow
[11:49] <cjwatson> You'll find you can nominate other bugs just fine.
[11:49] <didrocks> ok, but I guess jamespage just nominated them by error and then reverted
[11:49] <cjwatson> It's arguably a Launchpad bug that you can't re-nominate, so please make sure that's filed.
[11:49] <cjwatson> Well, re-target.
[11:49] <didrocks> but no way to give it back then?
[11:49] <cjwatson> Not that I can see.
[11:49] <cjwatson> Please file an LP bug.
[11:49] <didrocks> cjwatson: will do, thanks :)
[11:50] <jamespage> didrocks, gah - sorry - I was not aware of that bug
[11:50] <didrocks> jamespage: well, I wasn't as well :)
[11:53] <didrocks> bug #1051918
[12:10] <melodie> hi
[12:10] <melodie> can someone help me understanding a piece of bash in a cron daily script ? it's related to the permissions on a file
[12:11] <melodie> it's about this version of mlocate : http://packages.ubuntu.com/precise/mlocate
[12:12] <cjwatson> Sure.  What don't you understand?
[12:13] <melodie> hi cjwatson : I would like to know if the file /usr/bin/updatedb.mlocate is supposed to be executable. is it, or is it not ? and is the cron supposed to make it executable "on the fly" ?
[12:13] <geser> it should be executable (at least it's here)
[12:14] <melodie> it's lines number 3 to 5 whic make me think so: http://pastebin.com/N2CWL1TR
[12:14] <cjwatson> melodie: It's shipped executable in the package.
[12:14] <cjwatson> melodie: There is no reason the cron script should need to change its permissions.
[12:14] <melodie> cjwatson, ok, I thank you.
[12:14] <melodie> geser, thank you too
[12:14] <cjwatson> The -x test there is really just "is it there", actually.  -f would have been fine too but -x is a bit more exact.
[12:14] <melodie> all right
[12:15] <cjwatson> (Or -e, for that matter.)
[12:15] <cjwatson> But it's correct as it is.
[12:15] <melodie> is this package issued from Debian sid, or Debian testing ? in testing they have the same version number, but I am unable to find how the permissions are setup in the package (which bugs me)
[12:16] <cjwatson> It doesn't matter where it came from.  Testing comes from unstable.
[12:16] <geser> melodie: as you can remove the package (but leave the configuration files installed incl. the cron-snippet), the cron-snippet has to check if the binary is still there
[12:16] <cjwatson> I expect that the permissions are not explicitly set up at all.  The compiler will emit binaries as executable right from the start.
[12:16] <melodie> oh ! I see !
[12:17] <cjwatson> There's no need to override permissions explicitly when they're correct already.
[12:18] <melodie> cjwatson, so if the permissions are not right, it can be the fault of the configurations done in the compiler ?
[12:23] <Laney> Most packages will run the dh_fixperms program during building which does some normalisation of permissions and owners (by default).
[12:24] <cjwatson> melodie: Are the permissions wrong, or is this theoretical?
[12:24] <cjwatson> melodie: In fifteen years of working on Unix I have never seen the compiler get this wrong, so I don't think the theoretical point is interesting.
[12:25] <melodie> cjwatson, the permissions are wrong in my virtualbox machine. Your information allowed me to eliminate a possible source for this issue. the guilty one is the vbox machine.
[12:25] <cjwatson> melodie: Is this an environment that has been upgraded from some earlier version?
[12:25] <cjwatson> And does reinstalling the mlocate package fix it?
[12:25] <melodie> the original system has the right permissions. the spin has wrong permissions
[12:26] <cjwatson> "spin"?
[12:26] <melodie> a remix if you prefer
[12:26] <cjwatson> I still don't know what you're talking about :)
[12:26] <cjwatson> *Which* remix?
[12:26] <melodie> a project I am training on in a vbox machine. :)
[12:27] <cjwatson> Does reinstalling the mlocate package fix it?
[12:27] <melodie> nothing very important but I was wondering if there was a bug somewhere
[12:27] <melodie> cjwatson, this could be, I am going to check.
[12:27] <cjwatson> I expect this is a bug in the remix's image build process.
[12:28] <melodie> I think it can also come from something in the virtualbox machine. I am not hundred percent sure that using it for remix is a good idea
[12:29] <melodie> cjwatson, reinstalling does fix the issue. thank you !
[12:30] <geser> cjwatson: got the embedded image of grub2 bigger with the recent package upload? because I got hit by bug #1051154 with the recent updated (it worked till now with RAID and LVM)
[12:31] <cjwatson> geser: wouldn't be surprising.  I'll look later
[12:31] <cjwatson> geser: may not be terribly fixable
[12:31] <cjwatson> 62 sectors is very little space to fit anything useful in ...
[12:32] <cjwatson> wait, "embedding area is unusually small" means there's even less than 62 sectors
[12:33] <cjwatson> I wonder if that's lying, since it doesn't match the fdisk output there
[12:33] <cjwatson> anyway, must finish piloting first.
[12:35] <geser> I can add my fdisk output too to that bug later (if it helps)
[12:36] <cjwatson> sure
[12:39] <alkisg1> cjwatson: re: LP bug #978654, I believe the correct thing to do there is to leave the .decode() call for as long as pkcompat.py is python2 (i.e. 12.04/12.10). When it's ported to python 3, that change should be reverted.
[12:40] <alkisg1> cjwatson: it's not the only call to dbus.String(), and I don't think we want to change all the calls to include the decode() + the guard if...
[12:43] <jodh> @pilot out
[12:45] <cjwatson> alkisg1: No, I disagree.  Leaving timebombs around for ourselves is unwise.
[12:45] <cjwatson> alkisg1: The guard I suggested is safe in Python 2 as well.
[12:45] <cjwatson> alkisg1: Unless pkcompat will *never* be ported to Python 3.
[12:45] <alkisg1> cjwatson: there are multiple dbus.String() calls in the code, a wrapper function for dbus.String() should probably be defined then
[12:45] <cjwatson> In fact, there is already a python3-aptdaemon.pkcompat package.
[12:46] <alkisg1> cjwatson: my idea is that when it's ported to python3, decode() won't be needed, so it should only be there until it is
[12:46] <cjwatson> So the "it's only Python 2" argument is definitely invalid.
[12:46] <cjwatson> A better counterargument, if you wanted to avoid this, would be to demonstrate that last_update can never be assigned a Unicode string.
[12:46] <cjwatson> But I don't know whether that's true.
[12:47] <alkisg1> So, you'd vote for a call-dbus-string() wrapper for all of the calls?
[12:47] <alkisg1> Or just for this one call?
[12:47] <cjwatson> I don't know enough of the context.  It would depend.
[12:48] <cjwatson> I suggest you look into how these functions are called (i.e. answer my question above).
[12:48] <alkisg1> aptdaemon$ grep -r dbus.String * | wc -l
[12:48] <alkisg1> 109
[12:48] <alkisg1> I think that looking into 109 calls would be too much work
[12:49] <cjwatson> Well, I'm not going to sponsor a change when I'm not convinced it's safe
[12:49] <alkisg1> I.e. some wrapper would be easier. Or, just leave it without a wrapper, since it's more clearly written for python 3, and only fix that one call for the python2 in 12.04/12.10 problem
[12:49] <ogra_> you could train your sed skills with it ;)
[12:49] <cjwatson> But since this is implementing a (presumably) defined interface, why not look into what defines that interface ...
[12:50] <cjwatson> I wouldn't have expected most of those calls to be relevant; many of them may well be operating on always-bytes data
[12:50] <cjwatson> Or, sorry, I mean always-text (Unicode)
[12:50] <cjwatson> As usual with Python 2/3 porting you need to make sure that you know whether each object is binary or text.
[12:51] <alkisg1> So the idea is that the code should be python2 compatible even if it's ported to python3?
[12:52] <alkisg1> What I don't understand is why would we want the decode() functions in a python3 port of the code
[12:52] <cjwatson> We don't want to have to maintain separate Python 2 and 3 versions.
[12:52] <cjwatson> It's a horrendous hassle.
[12:53] <alkisg1> OK, I thought the python2 version wouldn't be developed anymore
[12:53] <cjwatson> For most packages, as long as they still build Python 2 versions, they should be written in code that's compatible with both.
[12:53] <cjwatson> That's not usually how it works.
[12:53] <alkisg1> Gotcha
[12:53] <cjwatson> The Python 2 binary package comes from the same source package as the Python 3 one.
[12:54] <alkisg1> OK, then it's a bigger problem than what I have time for. I can't study someone else's code for 109 occurances of possible time bombs...
[12:54] <alkisg1> Thank you very much for your input, I'll unassign the bug
[12:54] <cjwatson> Looking at the code, it seems clearly possible for this method to receive text input.
[12:55] <cjwatson> alkisg1: I think you're overreacting
[12:55] <cjwatson> alkisg1: You don't need to do any such study
[12:55] <cjwatson> alkisg1: You're proposing a change to this one method, and it may well be that in practice this is the only method where this is a problem
[12:55] <alkisg1> cjwatson: my idea was that this would be a quick patch, and that the person undertaking the python3 port would solve it properly
[12:56] <cjwatson> alkisg1: If written in the style I suggest, this change would be harmless; it might not fix everything, but it would be an improvement
[12:56] <alkisg1> I.e. either make a wrapper function for all dbus.string calls, or fix the ones that need decoding, etc
[12:56] <cjwatson> alkisg1: You seem to be suggesting that no change should be made until it is perfect, which is not usually a wise approach
[12:56] <cjwatson> All I'm saying is that this change should be written in a way that means it's clearly not a regression
[12:57] <cjwatson> I'm not saying you need to audit all those dbus.String calls, at all
[12:57] <alkisg1> Well, currently the script isn't runnable with python3
[12:57] <alkisg1> So it wouldn't be a regression
[12:57] <cjwatson> Which script?
[12:57] <alkisg1> pkcompat.py
[12:57] <cjwatson> The file you're editing is shipped in python3-aptdaemon.pkcompat
[12:58] <cjwatson> It may have '#!/usr/bin/env python' at the top, but it is principally a module to be imported from other programs, not principally a script to be run standalone
[12:58] <cjwatson> So I don't consider the #! line very relevant
[12:59] <alkisg1> OK, I thought it was to be revisited by someone for python3 compatibility
[12:59] <cjwatson> If you run python3 you can then say 'from aptdaemon import pkcompat' and it works
[12:59] <cjwatson> It has already been ported to Python 3
[12:59] <cjwatson> I suspect that in fact the reported problem that you're debugging only exists in Python 2
[13:00] <alkisg1> True, dbus.String() can accept unicode strings in python3
[13:00] <cjwatson> So it's not a lack of port to Python 3, it's (perhaps) a slightly overenthusiastic port, if anything
[13:00] <cjwatson> dbus.String can accept Unicode strings in Python 2
[13:00] <cjwatson> as well
[13:00] <cjwatson> What it can't accept is a Unicode string encoded as bytes
[13:01] <cjwatson> >>> dbus.String(u"é")
[13:01] <cjwatson> dbus.String(u'\xe9')
[13:01] <cjwatson> >>> dbus.String(u"é".encode("UTF-8"))
[13:01] <cjwatson> Traceback (most recent call last):
[13:02] <cjwatson> If you pass bytes to dbus.String() in Python 3, in an odd reversal of the usual situation, it doesn't crash, but it produces incorrect results due to the behaviour of str(bytes):
[13:02] <cjwatson> >>> dbus.String("é")
[13:02] <cjwatson> dbus.String('é')
[13:02] <cjwatson> >>> dbus.String("é".encode("UTF-8"))
[13:02] <cjwatson> dbus.String("b'\\xc3\\xa9'")
[13:03] <cjwatson> So this demonstrates that in both Python 2 and 3 you *must* pass text (Unicode) to dbus.String and it is incorrect in both worlds to do otherwise
[13:03] <alkisg1> Aaah I didn't realize that part
[13:03] <cjwatson> Thus, I'd suggest that perhaps you should be looking further up in the traceback heree
[13:03] <alkisg1> I did say it wrongly above (unicode instead of utf8 strings), but I thought python3 would correctly handle utf8 strings (byte sequences)
[13:04] <cjwatson> i.e. don't change last_package_setter at all - leave its interface as being defined to take Unicode strings only
[13:04] <alkisg1> What I'm saying though, is that someone needs to have a look at all those calls
[13:04] <alkisg1> My only part in this is because students get an apport dialog
[13:04] <cjwatson> For this bug, somebody needs to have a look at *this* call
[13:04] <cjwatson> Please don't let the perfect be the enemy of the good
[13:04] <alkisg1> And instead of disabling apport, I thought I'd invest a few minutes to help there
[13:04] <alkisg1> I understand the problem, and I really think it's a job for the maintainer
[13:05] <cjwatson> It shouldn't need to be
[13:06] <alkisg1> I really thank you for your time, and I'm not avoiding this due only to time constrains. I really feel that it's a bigger problem that I shouldn't tackle. It needs a better solution, and personally I'd go for a wrapper function, to avoid all possible cases at once.
[13:07] <cjwatson> I really don't think that's right
[13:07] <cjwatson> A wrapper function is missing the point
[13:07] <cjwatson> These functions are (implicitly) defined to take Unicode strings only - a wrapper function would be masking bugs elsewhere
[13:07] <cjwatson> In this case, I believe I see the bug
[13:08] <cjwatson> Look in 'def _get_id_from_version'
[13:08] <cjwatson> origin = version.origins[0].label
[13:08] <alkisg1> A wrapper function could log + fix the problems elsewhere
[13:08] <cjwatson> No
[13:08] <cjwatson> I'm not going to pursue that
[13:08] <alkisg1> I.e. have the devs notified without having the users apps breaking
[13:08] <cjwatson> I bet (though I'll check) that version.origins[0].label is bytes, not text
[13:10] <cjwatson> alkisg1: What is the URL for the PPA you used in your example (https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/978654/comments/12)?
[13:10] <alkisg1> cjwatson: https://launchpad.net/~ts.sch.gr/+archive/ppa/+packages
[13:11] <cjwatson> Thanks
[13:13] <alkisg1> We have about 20 papercut-like problems in schools here. E.g. we can't type greek due to lightdm not supporting multiple layouts, we have aptd, colord, apport etc crashes, sshfs problems... we try to help where the fixes are simple, but we don't have time to dive + properly fix all those cases
[13:14] <davmor2> pitti: I'm just wondering if bug #1051951 could be related to bug #952933  but I'm pretty sure I saw you and seb128 say that you would push the fix upstream to debian, it's just it has the exact same symptoms
[13:14] <cjwatson> Sure, you can do whatever you like locally of course, but this is a merge proposal into Ubuntu so I want to do the right thing and not mask bugs
[13:14] <alkisg1> So e.g. for lightdm we're using an /etc/X11/Xkbmap override, and we have to leave the proper fix up to the maintainer, even if it needs more than 1 year now
[13:14] <cjwatson> Especially since it doesn't look too hard to do the right thing here
[13:15] <cjwatson> In fact, add-apt-repository has a similar problem (still :-/)
[13:16] <juliank> cjwatson: Origin's label has Python's standard string type.
[13:17] <cjwatson> Indeed.
[13:17] <cjwatson> So in Python 2 that needs to be encoded if the desired type is in fact text.
[13:25] <doko> tjaalton, yeah for http://people.canonical.com/~ubuntu-archive/nbs.html \o/
[13:25] <doko> what did break the build dependencies?
[13:25] <tjaalton> doko: libglu not accepted yet?
[13:25] <cjwatson> eh, that's transient
[13:25] <tjaalton> it's in NEW I think, mesa dropped it
[13:26] <cjwatson> yeah
[13:26] <cjwatson> doko: feel free to process that in NEW :)
[13:26] <doko> ok, looking at it
[13:26] <juliank> cjwatson: Yes, and placing something like get_dbus_string() in tests/regressions/aptdaemon/core.py into a common module would be useful for fixing this aptdaemon bug. (try: return dbus.String(text), except ...: return dbus.String(text.encode("utf-8"))
[13:27] <cjwatson> juliank: Well, I think the fix in aptdaemon actually belongs several layers up.
[13:29] <doko> tjaalton, all the code was in mesa before?
[13:30] <tjaalton> doko: yes
[13:31] <tjaalton> should be safe to accept
[13:31] <juliank> cjwatson: I don't think it can be fixed on any other level. The fact is that python-apt has a 'str' API, and python-dbus a 'unicode' API. You could change python-dbus to accept utf-8 encoded byte strings, but I don't think this is sensible. You can also change the applications to set the default encoding to UTF-8, which fixes this as well.
[13:31] <tjaalton> packaging was copied straight from it, debian/copyright should be accurate etc :)
[13:32] <cjwatson> juliank: I think you're misunderstanding me.
[13:32] <cjwatson> juliank: The fix in aptdaemon belongs at the point where it retrieves data from python-apt, not in the methods that construct dbus.Strings from values.
[13:33] <cjwatson> juliank: These are several layers apart in the call stack.
[13:33] <cjwatson> juliank: I didn't mean to say that it should not be fixed in aptdaemon; it clearly should.  I meant several layers up *within aptdaemon* from where alkisg1 was suggesting.
[13:34] <doko> accepted
[14:02] <cjwatson> alkisg1: It seems fairly complicated to set up a reproduction environment for this bug.  Would you mind testing http://paste.ubuntu.com/1211094/, which I believe should fix it?
[14:03] <alkisg1> cjwatson: sure, give me a minute to test with the other guy that set up the reproduction environment...
[14:05] <cjwatson> Hah, although python-aptdaemon.pkcompat has actually been removed from quantal
[14:05] <cjwatson> But this won't hurt and will provide a better basis for an SRU
[14:08] <alkisg1> cjwatson: works as expected :)
[14:08] <alkisg1> (tested with python2, precise)
[14:09] <cjwatson> Hooray
[14:11] <cjwatson> alkisg1: Perhaps somebody could add a test case to the bug description, in the form required by https://wiki.ubuntu.com/StableReleaseUpdates?
[14:11] <alkisg1> I can try to
[14:14] <cjwatson> @pilot out
[14:16]  * dholbach hugs cjwatson :)
[14:20] <cjwatson> alkisg1: I've uploaded a fix to precise-proposed, pending approval.  The test case will help that. :-)
[14:20] <alkisg1> cjwatson: ty, /me is still writing... :)
[14:27] <alkisg1> cjwatson: done, as well as I could write those... :)
[14:40] <cjwatson> alkisg1: thans
[14:40] <cjwatson> *thanks
[14:40] <alkisg1> np, thank you too and sorry for not doing it myself the way you pointed
[14:40] <cjwatson> np
[14:41] <alkisg1> I just feel that larger bugs should be handled by the maintainers... /me is probably just getting too old for this... :)
[14:42] <cjwatson> Well, I'm not an aptdaemon maintainer
[14:42] <cjwatson> So unless you're saying I shouldn't have handled it ...
[14:42] <ogra_> age is not an excuse
[14:42] <ogra_> (i think colin is older than you :P )
[14:45] <alkisg1> I surely appreciate that you've handled it, but shouldn't the maintainer have a look at all the other 108 dbus.String() calls?
[14:46] <cjwatson> No, because that's a red herring
[14:46] <cjwatson> The problem is not dbus.String; the problem is the interaction with a different string model in python-apt
[14:47] <cjwatson> And I grepped for other uses of Origin.label, and fixed the one other case of that
[14:48] <doko> bryceh, about 1050674: is this a copy of the existing driver packaging, or are these maintained somehow together?
[14:48] <cjwatson> It's sometimes a mistake to microfocus on the bottom level of the traceback - what you want is for types to be correct all the way through the program
[14:49] <alkisg1> So e.g. "BackendAuthor": dbus.String(__author__), => are we sure that won't be utf8?
[14:49] <cjwatson> Yes, because it is a hardcoded constant!
[14:50] <alkisg1> And  we're sure no e.g. chinese guy will be the author in the next year?
[14:51] <cjwatson> Any future changes will be to the Python 3 code where this won't arise.
[14:51] <cjwatson> Since "..." is a Unicode type in Python 3.
[14:51] <alkisg1> I thought we wanted to maintain a python2 + python3 compatible version
[14:51] <cjwatson> Can you just drop it?
[14:51] <alkisg1> Sure
[14:51] <cjwatson> python-aptdaemon.pkcompat actually no longer exists in quantal.
[14:51] <alkisg1> I don't mean to chat just for the ...fun of it
[14:52] <alkisg1> We both have lots of things to better invest our time in :)
[14:52] <alkisg1> Thank you again.
[14:52] <cjwatson> And the reason I'm not harping on dbus.String is that any problems of that form would be *separate bugs*.
[14:52] <cjwatson> They wouldn't really be the same as this one; they would need to be addressed in entirely separate ways.
[14:52] <cjwatson> I don't think it's worth doing a full audit for that.
[14:53] <cjwatson> This bug isn't really about dbus.String, it's about incorrectly fetching information from python-apt.
[14:53] <cjwatson> So I focused on the general case of that, not on the general case of dbus.String handling.
[14:53] <alkisg1> Much appreciated; let's move on to other matters :)
[14:54] <cjwatson> I don't mean to snap; I just feel you were pushing me about a generalisation of the problem that I don't actually think is the right generalisation to be looking at.  I did look at the generalised version of what I felt was the correct characterisation of the bug.
[14:56] <alkisg1> cjwatson: I honestly have/had etc no hard feelings or anything else bad for you; I also didn't mean to push anywhere etc. I _am_ actually not always understanding the way you (and all ubuntu devs) choose to handle some stuff.
[14:57] <alkisg1> That's probably because after 4 years I'm still not sure where the upstream / distro maintainer / bug triager seperation is, exactly
[14:57] <melodie> hi again
[14:59] <alkisg1> I think after 20 years of being upstream for some programs, it's hard for me to think as a bug reporter / distro maintainer
[14:59] <melodie> I do have a general question. I have tried to follow the "UbuntuFromScratch" howto at the Ubuntu website and I have almost reached the end of it (while building the way it is explained). At the end, I see things that I am almost sure I will not be able to handle without some extra help, either because I don't understand, or because it might be outdated for some parts. Is there a chan where I could get help on making a Remix (from scratch)
[14:59] <melodie>  ?
[15:00] <cjwatson> Well, ideally upstream (who's mostly glatzor) would have addressed this, but since it's mostly a legacy Python 2 matter I decided to just go ahead and fix it and he can pick up the patch if he wants to.
[15:46] <bryceh> doko, the packaging is maintained in the same git tree as the normal driver, on its own branch.  So yes to both.
[15:53]  * Laney is glad that he enjoys playing whack a mole on broken fontconfig configuration files
[15:58]  * ogra_ wonders why such a little script http://paste.ubuntu.com/1211296/ actually reserves 3MB when running it
[15:58] <ogra_> gtk2-perl clearly got bloated since i looked last
[16:45] <infinity> pitti: So, I assume you rejected all those lucid uploads?
[16:46] <infinity> pitti: If so, you missed the ones in NEW.
[16:46]  * infinity finds the others in the rejected queue and confirms before dumping the new ones too.
[17:47] <blackbug> I have a fix for a bug, how can I submit?
[17:47] <xnox> blackbug: attach a patch to that bug?!
[17:52] <blackbug> xnox: sorry, i am doing this first time on ubuntu. By path you mean, tarball of the package in which i have fixed? or in some other form?
[17:52] <blackbug> i mean patch*
[17:54] <xnox> blackbug: by patch I mean: $ diff -r -U 4 original-dir/ modified-dir/
[17:54] <xnox> blackbug: google for "how to create a patch", or google for "how to create a merge proposal"
[17:55] <blackbug> xnox: thanks, i will google for the same. As of now, i have created branch using lp and did my changes over that.
[17:55] <xnox> blackbug: great
[17:55] <xnox> blackbug: $ bzr diff --old lp:ubuntu/package
[17:55] <xnox> will make a patch
[17:56] <xnox> blackbug: or simply go to your branch web page and click "Propose a merge"
[17:57] <blackbug> xnox: Thanks for the guidance :) . I will do as suggested.
[18:00] <cjwatson> -U 4?  Weirdo. :-)
[18:06] <blackbug> xnox: just 1 last question, after running bzr diff --old lp:ubuntu/package i got the differences on the console. So, I need to redirect them to a file or some patch file is created somewhere? ( posting again, as I got disconnected )
[18:09] <cjwatson> blackbug: redirect
[18:10] <cjwatson> it's a straightforward Unix command, it outputs to standard output by default :)
[18:11] <blackbug> cjwatson: Thanks, I will redirect. I thought may be its creates some compress file in background, and also shows output on console :). Thanks :)
[18:11] <cjwatson> No.
[18:34] <sbeattie> doko: so one issue I'm noticing with openjdk-7/precise is that update-manager doesn't want to install it because it needs to remove icedtea-7-jre-cacao, which got pulled in by default because openjdk-7-jre-headless used to recommend it.
[18:36] <blackbug> cjwatson: one more question......i redirected the output to text file. When i tried to upload it as patch on launchpad, it displayed "Attachment, doesnt seem to be a patch file, Are you sure its patch?". So, everything is cool or I need to change the format?
[18:45] <jdstrand> @pilot in
[19:39] <slangasek> cjwatson: yep, found where the prompt went and filed a bug on u-m
[19:59] <pitti> infinity: ah, forgot the NEW ones, indeed; but they should be rejected either way; thanks!
[21:24] <doko> sbeattie, what do you suggest? adding a conflict?
[22:15] <sbeattie> doko: I *think* we need an empty stub icedtea-7-jre-cacao package (for precise only), but perhaps slangasek has a better idea?
[22:35] <jdstrand> @pilot out
[23:00] <StevenK> RAOF: Using Do's MPD plugin makes my computer sad
[23:00] <RAOF> StevenK: In what way sad?
[23:01] <StevenK> RAOF: Every action creates a zombie mpc process
[23:01] <ogra_> resident evil Do
[23:01] <RAOF> StevenK: Ah, yeah.
[23:02] <RAOF> StevenK: That's actually a mono bug I should track down.
[23:02] <StevenK> RAOF: Yeah, I got annoyed enough to read the plugin code
[23:03] <StevenK> When I found the process code and found it looked suspiciously like the example code on microsoft's site, I figured it was probably lower down the stack.
[23:03] <RAOF> Yeah. Something in the BCL isn't waiting properly on the child.


[00:06] -queuebot:#ubuntu-release- Unapproved: gallery-dl (focal-backports/universe) [1.24.4-1~bpo20.04.1 => 1.24.5-1~bpo20.04.1] (no packageset)
[00:09] -queuebot:#ubuntu-release- Unapproved: yt-dlp (jammy-backports/universe) [2023.01.06-1~bpo22.04.1 => 2023.02.17-1~bpo22.04.1] (no packageset)
[00:17] <bdmurray> guiverc: the email is out
[00:17] <guiverc> thanks bdmurray ; I just noted secs before, but i do appreciate the ping ! so Thank You !
[01:21] <kc2bez> Thanks to the release team!
[01:55] -queuebot:#ubuntu-release- New binary: rustc [riscv64] (lunar-proposed/main) [1.67.1+dfsg0ubuntu1-0ubuntu2] (i386-whitelist)
[07:44] <ricotz> doko, hi, python3.10-minimal 3.10.10-1 fails to configure
[08:22] <didrocks> hey, it’s been too long I had some issues with britney. adsys (in main) has a dep on sssd | krb5-user. First one is in main, not the second. Why then it’s blocked as the first alternative should fullfil it, no?
[08:24] -queuebot:#ubuntu-release- New binary: libcupsfilters [amd64] (lunar-proposed/universe) [2.0~b4-0ubuntu5] (no packageset)
[08:25] -queuebot:#ubuntu-release- New binary: libcupsfilters [s390x] (lunar-proposed/universe) [2.0~b4-0ubuntu5] (no packageset)
[08:25] -queuebot:#ubuntu-release- New binary: libcupsfilters [arm64] (lunar-proposed/universe) [2.0~b4-0ubuntu5] (no packageset)
[08:25] -queuebot:#ubuntu-release- New binary: libcupsfilters [ppc64el] (lunar-proposed/universe) [2.0~b4-0ubuntu5] (no packageset)
[08:26] <arraybolt3> didrocks: I would assume because if a user swaps out krb5-user it will break things (assuming that krb5-user is regressing it). The ProposedMigration Wiki page states "All of its (the package's) dependencies must either be satisfiable by packages already in the release pocket, or be satisfiable by the group of packages which are going to be installed at the same time". Which implies that
[08:26] <arraybolt3> all of the *needed* dependencies being satisfied isn't sufficient - it has to be *all* the dependencies.
[08:26] -queuebot:#ubuntu-release- New binary: libcupsfilters [armhf] (lunar-proposed/universe) [2.0~b4-0ubuntu5] (no packageset)
[08:28] <didrocks> arraybolt3: the issue might be linker related, it seems that it linked directly against it for some reason, I will investigate, thanks!
[08:28] <arraybolt3> AFAIK, Britney doesn't discriminate between the various repos in Ubuntu. I don't believe it cares about what is in Main and what is in Universe and stuff like that.
[08:28] <LocutusOfBorg> xnox, why shouldn't I just take the Ubuntu dkms delta and upload to Debian?
[08:28] <arraybolt3> didrocks: Glad I was able to help!
[08:28] <LocutusOfBorg> and not forward upstream=
[08:29] <LocutusOfBorg> deal.ii failed again with no logs... cjwatson some tail -f please?
[08:37] <arraybolt3> didrocks: Interesting, it appears I may have been wrong about Britney not discriminating between repos. Now that I'm actually looking at the output, it looks like it really hates that there's a universe dependency in there. I searched the entire ProposedMigration page for "Main", "Universe", "Restricted", and "Multiverse", so I though I was right.
[08:37] <arraybolt3> *thought
[08:38] <arraybolt3> In that instance I guess I don't know why it wouldn't be let through.
[08:43] <didrocks> arraybolt3: I find it, actually, some linkage added the direct dep
[08:43] <didrocks> so eliminating the alternative
[08:43] <arraybolt3> Well, hey, at least part of what I said was good for something!
[08:55] -queuebot:#ubuntu-release- New binary: libcupsfilters [riscv64] (lunar-proposed/universe) [2.0~b4-0ubuntu5] (no packageset)
[09:03] -queuebot:#ubuntu-release- Builds: 27 entries have been added, updated or disabled
[09:41] <LocutusOfBorg> vorlon, hello, do you think a merge of google-perftools can heal i386 builds?
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [arm64] (lunar-proposed) [2.0~b4-0ubuntu1]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [s390x] (lunar-proposed) [2.0~b4-0ubuntu1]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [arm64] (lunar-proposed) [2.0~b4-0ubuntu2]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [s390x] (lunar-proposed) [2.0~b4-0ubuntu2]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [arm64] (lunar-proposed) [2.0~b4-0ubuntu3]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [ppc64el] (lunar-proposed) [2.0~b4-0ubuntu3]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [amd64] (lunar-proposed) [2.0~b4-0ubuntu4]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [armhf] (lunar-proposed) [2.0~b4-0ubuntu4]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [s390x] (lunar-proposed) [2.0~b4-0ubuntu4]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [arm64] (lunar-proposed) [2.0~b4-0ubuntu5]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [ppc64el] (lunar-proposed) [2.0~b4-0ubuntu1]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [ppc64el] (lunar-proposed) [2.0~b4-0ubuntu2]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [armhf] (lunar-proposed) [2.0~b4-0ubuntu3]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [arm64] (lunar-proposed) [2.0~b4-0ubuntu4]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [amd64] (lunar-proposed) [2.0~b4-0ubuntu5]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [ppc64el] (lunar-proposed) [2.0~b4-0ubuntu5]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [s390x] (lunar-proposed) [2.0~b4-0ubuntu5]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [amd64] (lunar-proposed) [2.0~b4-0ubuntu2]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [s390x] (lunar-proposed) [2.0~b4-0ubuntu3]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [armhf] (lunar-proposed) [2.0~b4-0ubuntu5]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [amd64] (lunar-proposed) [2.0~b4-0ubuntu3]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [riscv64] (lunar-proposed) [2.0~b4-0ubuntu5]
[09:46] -queuebot:#ubuntu-release- New: accepted libcupsfilters [ppc64el] (lunar-proposed) [2.0~b4-0ubuntu4]
[09:47] -queuebot:#ubuntu-release- New: accepted libcupsfilters [amd64] (lunar-proposed) [2.0~b4-0ubuntu1]
[09:51] <doko> ricotz[m]: why do you need 3.10?
[10:00] <LocutusOfBorg> autopkgtest for boost1.81/blacklisted: arm64: Regression ♻
[10:01] <LocutusOfBorg> what is the point of having icu not migrate due to a blacklisted regressed test that won't be ever run?
[10:01] <LocutusOfBorg> I remember this question was already asked but I forgot the answer...
[10:03] <LocutusOfBorg> and I can't see on hints-ubuntu git repo the actual hint...
[10:04] <LocutusOfBorg> (same for dgit and ros-ros-comm)
[10:06] <zhsj> LocutusOfBorg: migration-reference/0 has been run, so probably it will sort out itself.
[10:14]  * LocutusOfBorg fingers crossed
 "ricotz: why do you need 3.10?" <- It is still installed, so just saying it miscompiled again
[11:18] <doko> apt remove is your friend
[11:28] <ricotz> doko, I guess even the iso still includes python3.10
[12:52] <xnox> LocutusOfBorg:  you can upload anything you want to debian; but please do not forcesync dkms package to Ubuntu. we were unable to migrate kernels for months now, in part due to massive amounts of tests that dkms triggers; regressions that it introduced; behaviour change that is unsuitable for Ubuntu; and a bug in migration that caused dkms to migrate with a regression.
[12:53] <xnox> LocutusOfBorg:  note, that in Debian, kernels do not vendor in dkms modules that are available in the archive, like Ubuntu kernels do. thus there needs to be a policy/social decision if what new dkms upstream does makes sense or not.
[12:53] <xnox> LocutusOfBorg:  DO NOT FORCESYNC dkms even if you upload the delta to Debian, as that will again invalidate the expensive ongoing testing, further delaying work of my team in Ubuntu.
[12:54] <xnox> LocutusOfBorg:  at the moment the highest priority is to maintain status quo w.r.t. `apt install zfs-dkms` and get linux kernels migrated, without any new churn of the dkms package.
[13:16] <LocutusOfBorg> xnox, any idea w.r.t. xtrx-dkms/lunar/ppc64el?
[13:16] <LocutusOfBorg> https://autopkgtest.ubuntu.com/packages/x/xtrx-dkms/lunar/ppc64el
[13:16] <LocutusOfBorg> well, forcesync is the way, doing
[13:33] <xnox> LocutusOfBorg:  i'm sorry i don't understand "well, forcesync is the way, doing" => please do not make any dkms uploads into Ubuntu right now.....
[13:35] <xnox> LocutusOfBorg:  xtrx-dkms that last build is not compatible with v6.1 in luna-release, but i see an upload in lunar-proposed that claims to fix that https://launchpad.net/ubuntu/+source/xtrx-dkms/0.0.1+git20190320.5ae3a3e-3.2
 LocutusOfBorg:  xtrx-dkms that last build is not compatible with v6.1 in luna-release, but i see an upload in lunar-proposed that claims to fix that https://launchpad.net/ubuntu/+source/xtrx-dkms/0.0.1+git20190320.5ae3a3e-3.2
[13:47] <LocutusOfBorg> ^^ that was the forcesync I mentioned
[13:47] <LocutusOfBorg> :)
[13:58] <xnox> ah, ok
[13:58] <xnox> =)
[13:58] <xnox> $foo-dkms forcesyncs are fine =) ^dkms$ is the problematic one
[13:58] -queuebot:#ubuntu-release- Unapproved: lxc (bionic-proposed/main) [3.0.3-0ubuntu1~18.04.1 => 3.0.3-0ubuntu1~18.04.2] (ubuntu-server)
[13:59] <xnox> stgraber:  turns out our kernel testing team has been hand hinting by-hand every run of lxc tests on every hwe kernel upload into bionic since forever, by manually reading logs to ensure only the one subtest fails..... ^
[13:59] <xnox> it would be nice if you could review that sru.
[14:24] <LocutusOfBorg> xnox, the idea of the forcesync of xtrx-dkms was to speedup dkms migration :)
[16:09] <ricotz> LocutusOfBorg, hi, why is boost1.81/arm64 denylisted for autopkgtests? it seems to be last bit blocking icu?
[16:14] <juliank> ricotz: it has too many tests, and instance creation inevitably fails at some point (each test creates new instance), causing the test to temporary fail and be retried ad infinitum
[16:15] <ricotz> juliank, ok, what is the conclusion here? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#icu
[16:15] <juliank> ricotz: I think IS turned off the broken cloud host for new instances, so maybe bdmurray is happier now
[16:15] <juliank> ricotz: jawn-smith is working on manually testing boost and then it should be skiptested
[16:15] <ricotz> ah, great :)
[16:27] <luna_> anyone knows the irc channel for Ubuntu on Air?
[16:33] <luna_> found it #ubuntu-on-air there is soon a stream about the new minor LTS version updates
[16:36] <vorlon> utkarsh2102, seb128, sil2100, teward, kanashiro[m]: could one of you please accept the invitation for ~ubuntu-core-dev to join https://launchpad.net/~unity7maintainers/ ?
[16:36] <vorlon> or rbasak or bdmurray
[16:42] <kanashiro[m]> vorlon: it was apparently done by someone else
[16:49] <vorlon> kanashiro[m]: ah - only just, it was 'pending' when I asked :) anyway, thanks to whoever
[17:09] <luna_> Delayed until 5th March lets watch Mountainbytes demoparty then
[17:37] <LocutusOfBorg> vorlon, autopkgtest for rapiddisk/8.2.0-2ubuntu2: amd64: No test results, arm64: No test results, armhf: Pass, i386: Regression ♻ , ppc64el: No test results, s390x: No test results
[17:37] <LocutusOfBorg> hint please on i386?
[17:37] <LocutusOfBorg> usual kernel nbs on i386
[17:45] -queuebot:#ubuntu-release- New source: rust-bindgen-0.56 (lunar-proposed/primary) [0.56.0-0ubuntu1]
[18:14] <vorlon> LocutusOfBorg: so shouldn't this clear with a baseline retest instead of a manual hint?
[18:30] <vorlon> Setting up node-qs (6.11.0+ds+~6.9.7-3) ...
[18:30] <vorlon> [...]
[18:30] <vorlon> autopkgtest: WARNING: package node-qs is not installed though it should be
[18:30] <vorlon> you don't say
[18:39] <LocutusOfBorg> ack vorlon
[20:01] <vorlon> sil2100: hmm you didn't take my suggestion in https://code.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/+git/ubuntu-cdimage/+merge/437218 to treat the removals of stale flavors as a separate commit :/
[20:07] -queuebot:#ubuntu-release- Unapproved: rabbitmq-server (focal-proposed/main) [3.8.2-0ubuntu1.3 => 3.8.2-0ubuntu1.4] (ubuntu-server)
[20:39] -queuebot:#ubuntu-release- Unapproved: fwupd-efi (lunar-proposed/main) [1:1.2-3ubuntu1 => 1:1.4-1] (no packageset)
[20:40] -queuebot:#ubuntu-release- Unapproved: fwupd-efi (lunar-proposed/main) [1:1.4-1 => 1:1.4-1] (no packageset)
[20:40] -queuebot:#ubuntu-release- Unapproved: fwupd-efi (lunar-proposed/main) [1:1.4-1 => 1:1.4-1] (no packageset)
[21:04] <jbicha> vorlon: could you review mutter from lunar NEW?
[21:58] <vorlon> jbicha: is there an FFe for a post-FF soname change?
[21:59] <vorlon> jbicha: or I guess you're squeaking under the line of when the email went out vs when the source upload happened ;P
[22:10] <vorlon> jbicha: I: mutter-12-tests: hardening-no-fortify-functions [usr/libexec/installed-tests/mutter-12/mutter-screen-cast-client]
[22:12] -queuebot:#ubuntu-release- New: accepted mutter [amd64] (lunar-proposed) [44~beta-3ubuntu2]
[22:12] -queuebot:#ubuntu-release- New: accepted mutter [armhf] (lunar-proposed) [44~beta-3ubuntu2]
[22:12] -queuebot:#ubuntu-release- New: accepted mutter [riscv64] (lunar-proposed) [44~beta-3ubuntu2]
[22:12] -queuebot:#ubuntu-release- New: accepted mutter [arm64] (lunar-proposed) [44~beta-3ubuntu2]
[22:12] -queuebot:#ubuntu-release- New: accepted mutter [s390x] (lunar-proposed) [44~beta-3ubuntu2]
[22:12] -queuebot:#ubuntu-release- New: accepted mutter [ppc64el] (lunar-proposed) [44~beta-3ubuntu2]
[22:13] <jbicha> we set hardening=+all in debian/rules 🤷
[22:24] <arraybolt3> That kind of thing happens in a lot of Lubuntu packages. When hardening=+all is set and the warning is still generated, we just ignore it.
[22:26] <tsimonq2> ¯\_(ツ)_/¯ depends on the package
[22:44] <Eickmeyer> ignore that
[22:45] <arraybolt3[m]> Eickmeyer: You may have too many windows opened, since I think you meant that for #ubuntu-studio:matrix.org
[22:48] <arraybolt3> nvm, sorry
[22:49] <Eickmeyer> arraybolt3: Actually, it was supposed to be an internal IRC client command that went haywire and went everywhere. *facepalm*
[23:00] -queuebot:#ubuntu-release- New sync: libdex (lunar-proposed/primary) [0.1.0-1]
[23:24] <tsimonq2> ubuntu-release: Please note me as the development contact for both Lubuntu and Kubuntu, given some recent extenuating circumstances. I'll be happy to elaborate more via email or PM if needed.


[03:06] <sarnold> pymagic: what are you seeing?
[03:07] <pymagic> sarnold, boot repair gives me this: http://paste.ubuntu.com/p/d6qyFx9mY2/ -- I am trying to boot from nvme0n1p2
[03:07] <pymagic> Booting just boots me into bios
[03:09] <sarnold> bummer :( this probably would have been a few seconds to fix before the reboot but at this point will require booting to rescue media to fix
[03:10] <amurray> pymagic: I think you need to set the boot order to specify Ubuntu
[03:10] <pymagic> sarnold, I've rescue media
[03:10] <pymagic> I booted into kubunt and can mount the drive
[03:10] <pymagic> I tried boot-repair - no use
[03:10] <sarnold> pymagic: start with these "physical machine" instructions to get into a rescue environment, chrooted to your install: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass#Physical_machine
[03:11] <pymagic> I can try those commands
[03:12] <sarnold> pymagic: yeah, I don't think anyone's taught boot-repair how to fix incorrectly configured debconf settings -- once you're in the rescue environment, chroot'ed to your installation, sudo dpkg-reconfigure grub-efi-amd64
[03:12] <pymagic> k - trying
[03:12] <pymagic> booting into kubuntu - will take some time, thanks
[03:13] <pymagic> sarnold, what will be ROOT_PARTITION value?
[03:14] <sarnold> pymagic: it'll be the largest partition on your nvme drive; that might be nvme0n1p2 but check gdisk -l /dev/nvme0n1 to double-check
[03:14] <pymagic> yes, it is that
[03:21] <pymagic> sarnold, grub-efi-amd64 is not installed
[03:22] <pymagic> I could do those steps in prepare the chroot
[03:23] <sarnold> pymagic: are you sure you're inside the chroot? line 12 of your paste:
[03:23] <sarnold> The default repair of the Boot-Repair utility will reinstall the grub-efi-amd64-signed of
[03:23] <sarnold> .. so I certainly expected it to be installed :)
[03:23] <pymagic> The paste I did came out of boot-repair utility - maybe they installed it? uninstalled it?
[03:23] <pymagic> not sure
[03:23] <pymagic> All the steps in chroot - went through cleanly for me
[03:24] <pymagic> last command was mount /boot/efi
[03:24] <sarnold> try an apt install grub-efi-amd64   perhaps? see what that does?
[03:25] <pymagic> sarnold, if i do dpkg --list | grep nvidia - I do see driver-440 - which is what was installed on my machine
[03:25] <pymagic> I also see other packages that I installed that are not on kubuntu
[03:25] <sarnold> pymagic: aha, good idea
[03:26] <pymagic> I do have grub-gfxpayload-liss and grub-pc installed
[03:26] <pymagic> they are going to be removed if i install grub-efi-amd64 - ok
[03:26] <sarnold> grub-pc? that's for BIOS machines, not EFI machines
[03:26] <pymagic> I've not clue how it was working so far
[03:26] <sarnold> me neither
[03:27] <pymagic> I had selected UEFI in the bios and could boot
[03:27] <pymagic> it says EFI Variables are not supported on this system.../sys/firmware/efi/efivars not found, aborting
[03:27] <pymagic> grub-probe : error: cannot find a GRUB drive for /dev/sdc1 - check your device.map
[03:28] <pymagic> not sure why sdc1 is even a candidate  for grub
[03:28] <sarnold> curious and curiouser.. try getting another terminal, and check the /sys/firmware/efi/efivars directory from outside the chroot
[03:29] <pymagic> nothing else
[03:29] <sarnold> man this is confusing
[03:29] <sarnold> efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
[03:29] <sarnold> that's what I've got on mine..
[03:30] <pymagic> I dont
[03:30] <pymagic> I have /sys/firmware/ -> acpi dmi and memmap
[03:30] <pymagic> This is a new Ryzen 3900X X570 machine. AORUS bios
[03:30] <sarnold> maybe try a mount -tefivars efivars /sys/firmware/efi/efivars/    ... I don't know if the --bind means it's got to be done from outside the chroot, or if it can go from inside the chroot ..
[03:31] <sarnold> and if that works, then apt install -f  ?
[03:31] <pymagic> could it be that i booted using "Legacy" instead of UEFI into kubuntu
[03:31] <pymagic> could that do it?
[03:31] <sarnold> yeah, that'll cause chaos :)
[03:32] <pymagic> reboot and try again?
[03:32] <sarnold> if you *want* to keep the legacy thing, then reinstall that grub-pc! if you want to switch to uefi, then, yeah, reboot, flip the switch..
[03:32] <pymagic> Let me uefi - rebootin
[03:33] <pymagic> bios is uefi :( csm support = on, storage boot = uefi , other pci device = uefi
[03:35] <pymagic> In kubuntu, there is an option in grub which says "UEFI firmware settings" - when i clicked it, it took me to bios...where uefi settings were
[03:38] <sarnold> pymagic: aha, turn off csm and try again :)
[03:38] <sarnold> csm == legacy
[03:38] <pymagic> I thought csm = uefi option?
[03:38] <sarnold> csm is some cursed thing :)
[03:38] <pymagic> k - disabling it and trying again
[03:46] <pymagic> sarnold, Intramfs -unpacking failed - decoding...its trying to boot now
[03:46] <pymagic> sarnold, but /sys/firmware now has efi :)
[03:47] <pymagic> sarnold, now it says grub-efi-amd64-signed is already newest version
[03:48] <pymagic> update-grub?
[03:49] <pymagic> or perhaps update-grub2? not sure
[03:51] <pymagic> I reinstalled that package using --reinstall
[03:51] <pymagic> will try to reboot and see if that wrks
[03:53] <sarnold> pymagic: so, next up is dpkg-reconfigure grub-efi-amd64  and make sure it thinks to install it in the correct place
[03:54] <pymagic> ah - k - i'll have to get back into chroot again. I rebooted after i --reinstalled it
[03:55] <pymagic> its now in a black screen - nothing on there
[03:56] <pymagic> rebooting into kubuntu
[04:01] <pymagic> sarnold, the reconfigure is askin me for Linux Command Line
[04:02] <sarnold> pymagic: whatever it's got is probably fine
[04:02] <pymagic> I think it had a legacy line or it was empty - it did not show me anything
[04:02] <sarnold> you pastebin shows empty
[04:02] <pymagic> leave it empty?
[04:03] <sarnold> yeah
[04:03] <pymagic> linux default command line: quiet splash -ok
[04:04] <pymagic> update nvram variables to automatically boot into debian? !
[04:04] <pymagic> yes or no
[04:05] <pymagic> sarnold, ?
[04:06] <sarnold> pymagic: default sounds good, and yes, if you want to keep booting into ubuntu by default
[04:06] <pymagic> sarnold, its now asking grub efi partition
[04:06] <pymagic> and the only option it gives me is /dev/nvme0n1p1 - and not p2?
[04:07] <pymagic> 536 Mb /boot/efi
[04:07] <pymagic> say ok and select that - since i dont have a choice?
[04:07] <sarnold> pymagic: yeah
[04:08] <sarnold> pymagic: this is the EFI boot partiion, a smallish fat32 filesystem shared by all operating systems and uefi firmware on the system
[04:08] <pymagic> now - reboot?
[04:09] <sarnold> pymagic: if you're all done, yeah, give it a shot and lets see how it goes :)
[04:12] <pymagic> sarnold, back to the bios screen
[04:12] <pymagic> sarnold, :(
[04:13] <sarnold> pymagic: oh no :( I had really hoped that dpkg-reconfigure was going to solve it all
[04:13] <pymagic> sarnold, in my bios it only shows ubuntu 4.0 - 2TB - so it does not show the 512MB partition to boot from
[04:13] <pymagic> isnt that an issue?
[04:13] <sarnold> pymagic: that's probably fine
[04:15] <pymagic> is there a way to chroot and see dmesg perhaps? - I am not even sure if the bios even tried to boot grub - it just hops back into the bios
[04:15] <sarnold> pymagic: probably not.. try the rescue media again, and try efibootmgr -v -- here's my output https://paste.ubuntu.com/p/7bCc8qqWHr/
[04:16] <sarnold> pymagic: note that I've got windows listed here even though wiping windows was the first thing I did. the bootorder line describes which entries to try in which order.. and it takes the first 'working' one..
[04:17] <pymagic> sarnold, Trying
[04:19] <pymagic> sarnold, with or without chroot?
[04:20] <sarnold> pymagic: shouldn't matter, this one reads from the firmware settings
[04:20] <pymagic> thanks - trying to boot into kubuntu
[04:24] <pymagic> sarnold, http://paste.ubuntu.com/p/2KxWpWY6Ft/
[04:27] <pymagic> sarnold, not sure how i got ubuntu/grub to work with legacy mode so far - but it did work. The only thing that broke the system was - in some grub setting i changed GRUB_TIMEOUT=2 from 0, and ran update-grub - and that broke the system. Not sure if that helps
[04:29] <sarnold> pymagic: well, I'm pretty well confused :( the order suggests using 1, 0, 2
[04:30] <sarnold> pymagic: 1 is labeled "flash drive" but has both "cdrom" and "usb" in the string
[04:30] <sarnold> pymagic: 0 looks like the thing you want to boot..
[04:30] <pymagic> when i try 0 it goes back to bios after trying to boot - no grub screen
[04:31] <sarnold> pymagic: try: efibootmgr -o 0,1,2  ?
[04:31] <pymagic> k it set that
[04:31] <pymagic> 0 = ubuntu
[04:31] <pymagic> the problem is "ubuntu" = 0 - when i set it up from bios - tries to boot - then comes back to bios
[04:32] <pymagic> I can reboot and try agian
[04:32] <pymagic> efibootmgr -o 0,1,2 worked fine
[04:32] <sarnold> pymagic: alright, I'm running very out of ideas, and it's time to run :(
[04:32] <pymagic> I fired a reboot
[04:32] <pymagic> Thanks for the help sarnold
[04:33] <sarnold> pymagic: my last thought -- try getting back in to the rescue chroot, and from there, apt install --reinstall grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-common
[04:33] <pymagic> k - will give it a try- thanks
[04:34] <sarnold> https://paste.ubuntu.com/p/DhYyvj2gQ6/
[04:34] <sarnold> turns out I've also got a grub2-common package installed. no idea why there's several.
[04:34] <pymagic> sarnold, 0 = ubuntu - did not boot - same problem
[04:34] <sarnold> :(
[04:34] <pymagic> ubuntu 20.04lts?
[04:36] <sarnold> pymagic: good luck, I hope you can sort this thing out :) I'm cautiously optimistic with the --reinstall approach.. I hope it's not too much trouble ;)
[04:38] <pymagic> thanks
[04:46] <pymagic> sarnold, got it :)
[04:46] <pymagic> Thanks for all the help.
[13:54] <kre10> hey guys, how are you? Can you please help me with something. By my mistake, I added 2 eth0 address on my ubuntu 64 server(raspberry pi 4). And now I have 2 eth0 addresses which is very confusing.
[13:59] <sdeziel> kre10: how did you add them?
[13:59] <kre1073> sdeziel hey there
[14:00] <kre1073>  sudo dhclient -r
[14:00] <kre1073> and sudo dhclient
[14:03] <sdeziel> kre10: a simple trick would probably be to reboot, if you can
[14:04] <kre10> yep, I rebooted a few times
[14:04] <sdeziel> kre10: after rebooting, if you don't run those manual dhclient commands, do you still have the extraneous IPs?
[14:04] <kre10> yes
[14:05] <sdeziel> could you pastebin the output of 'ip a'
[14:05] <kedar_apte> kre10: xenial or bionic or focal?
[14:05] <kre10> focal
[14:05] <kedar_apte> can you see anything in the netplan?
[14:06] <kedar_apte> in the folder /etc/netplan/
[14:06] <kedar_apte> there will be a yaml file
[14:06] <kre10> just a second
[14:06] <kedar_apte> are u able to see two interfaces in the file?
[14:06] <kre10> eth0:
[14:06] <kedar_apte> only one interface?
[14:06] <kre10> no, actually
[14:07] <kre10> yes
[14:07] <kedar_apte> can you paste bin what u see?
[14:07] <kre10> Uploaded file: https://uploads.kiwiirc.com/files/e001cd861f42b0206e066e3601058174/pasted.txt
[14:07] <kedar_apte> what is shown when u type .......... ip r
[14:08] <kedar_apte> can u screen shot that and imgur it
[14:08] <kre10> OK
[14:09] <kre10> https://www.screenpresso.com/=qv43f
[14:10] <kedar_apte> are you running bridged networks?
[14:10] <kedar_apte> like for containers?
[14:10] <kedar_apte> lxc / lxd / docker?
[14:11] <kre10> yes, I'm using docker
[14:11] <kedar_apte> are u on the physicall server or ssh into the server?
[14:12] <kedar_apte> can u exit and ssh again.... on the top you will see the disk usage and network details
[14:12] <kedar_apte> can u screenshot that
[14:12] <kre10> ssh
[14:12] <kre10> ok
[14:13] <kre10> https://www.screenpresso.com/=NI5Zf
[14:15] <kedar_apte> how many yaml files are you seeing in /etc/netplan/ ?
[14:16] <kre10> 1
[14:16] <kre10> -rw-r--r-- 1 root root 416 Apr  1 20:23 50-cloud-init.yaml
[14:17] <kedar_apte> have you tried doing this? ....... ip addr flush eth0
[14:18] <kedar_apte> also try doing this: ip link set dev eth0 down
[14:19] <kedar_apte> u might loose connection with the server
[14:19] <kedar_apte> do only if you have the ability to reboot or be on the server console
[14:20] <kre10> so after this command, I won't be able to login in the Pi?
[14:20] <kedar_apte> not sure... wait a second.....just finding something usefl
[14:21] <kre10> ok
[14:22] <kedar_apte> try this.... sudo ip addr del <ip address you want to remove> /24 dev eth0
[14:22] <kre10> sudo ip addr del <IP_ADDRESS> /24 dev eth0
[14:22] <kre10> ?
[14:22] <kedar_apte> do not delete the ip adress with which you have ssh'd in the server
[14:22] <kre10> OK
[14:23] <kre10> now ?
[14:23] <kedar_apte> have u run the command?
[14:23] <kedar_apte> what was the output?
[14:24] <kre10> no output, still 2 IP's
[14:24] <kre10> should I reboot the system?
[14:24] <kedar_apte> I doubt that will help... but no harm trying
[14:25] <kre10> I doubt too :(
[14:26] <kedar_apte> no harm in trying
[14:26] <kre10> ok
[14:29] <kedar_apte> if it has restaryed.... can u run this and tell me what it is ....... ps aux | grep dhc
[14:32] <kre10> zzlatev@playstation:~$ ps aux | grep dhc
[14:32] <kre10> root         243  0.0  0.0      0     0 ?        I<   17:26   0:00 [sdhci]
[14:32] <kre10> root        1271  0.0  0.0   3172  2376 ?        Ss   17:26   0:00 /usr/sbin/dhcpcd
[14:32] <kre10> zzlatev     3898  0.0  0.0   7684   660 pts/0    S+   17:31   0:00 grep --color=auto dhc
[14:32] <kre10> sorry about that
[14:32] <kre10> kedar_apte still 2 IP's :(
[14:33] <kedar_apte> systemctl disable dhcpcd.service
[14:33] <kedar_apte> systemctl stop dhcpcd.service
[14:33] <kedar_apte> and reboot
[14:33] <kre10> I think that 2 users are using eth0? because I ran this command with the new user - zzlatev which I created
[14:33] <kre10> OK
[14:33] <kedar_apte> wait
[14:33] <kedar_apte> wait
[14:33] <kre10> OK
[14:33] <kedar_apte> both of the ip addresses are dhcp?
[14:34] <kre10> I think so, yes
[14:34] <kre10> both are from the router
[14:34] <kedar_apte> ae both the ips reachable?
[14:34] <kre10> but I have to say that I have pihole which IP is the second one <IP_ADDRESS>
[14:35] <kre10> <IP_ADDRESS> is registred as reserved dhcp client in the router
[14:35] <kedar_apte> also is the mac ip same for both or it is shwoing different? you can check that mac ip in the router dhcp list
[14:35] <kre10> ok
[14:36] <kre10> there's isn't a client with <IP_ADDRESS>
[14:36] <kedar_apte> have you made any chage to /etc/network/interfaces?
[14:38] <kre10> nope
[14:38] <kedar_apte> are all your containers using the same NIC?
[14:38] <kre10> sorry, NIC?
[14:38] <kedar_apte> what is the default gateway for all containers?
[14:38] <kedar_apte> NIC - network card
[14:39] <kre10> in /etc/network I have 4 folders - if-down.d , if-post-down.d , if pre-up.d, if-up.d
[14:39] <kedar_apte> is there just one nic card?
[14:39] <kre10> I have one network card
[14:39] <kedar_apte> what is the default gateway for all all containers?
[14:39] <kedar_apte> what ip is being used as default gateway for all containers?>
[14:39] <kedar_apte> 109 or 111
[14:40] <kre10> 111
[14:41] <kedar_apte> and which IP is reserved on the router?
[14:41] <kre10> but I have access to the docker portainer with both IP's
[14:41] <kre10> 111 is reserved on the router
[14:42] <kedar_apte> Honestly...I dont know... I have used up all my KB 🤔
[14:42] <kre10> here's all networks in docker
[14:42] <kre10> https://www.screenpresso.com/=reNlc
[14:42] <kedar_apte> someone else could help
[14:42] <kre10> OK, thank you for trying! I appreciate it!
[14:42] <kedar_apte> sure
[14:47] <kre10> hm, ifconfig -a shows only one eth0
[14:50] <RoyK> kre10: just learn to use the ip command and forget about ifconfig
[14:51] <kre10> Can you help me with it?
[14:51] <kre10> ip -s -s a f to <IP_ADDRESS>/24
[14:51] <kre10> should I try this?
[16:56] <Slashman> hello, is there a way to skip the media integrity check for ubuntu server?
[16:56] <Slashman> (20.04.1)
[16:57] <lotuspsychje> Slashman: press the key combo it suggests
[16:57] <lotuspsychje> ctrl + C it was?
[16:57] <Slashman> didn't see that on ubuntu server media
[16:58] <lotuspsychje> didnt test myself on server, but i assume the integrity checks are on all ubuntu 20.04 iso's
[17:07] <Slashman> lotuspsychje: https://ibb.co/5rX9mkD
[17:07] <Slashman> nothing I can do
[17:07] <Slashman> super fun when installing from idrac where any read is from the network and ultra slow on a media that was already verified
[17:07] <lotuspsychje> Slashman: you need to early press the combo
[17:08] <lotuspsychje> Slashman: there used to be a bug on that, but it should be resolved by now
[17:09] <Slashman> lotuspsychje: I should do a video, but there is no time
[17:09] <Slashman> no message, nothing
[17:10] <Slashman> I select expert mode, then it immediately goes to check integrity
[17:13] <lotuspsychje> Ubuntu now defaults to checking the integrity of the medium in use when booting into live sessions. This can be skipped by hitting Ctrl-C, but due to a bug the message that tells you to hit this key is not shown in some flavours
[17:13] <lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1870018
[17:14] <lotuspsychje> Slashman: wich iso did you use please?
[17:18] <Slashman> lotuspsychje: http://www.releases.ubuntu.com/20.04/ubuntu-20.04.1-live-server-amd64.iso
[17:18] <lotuspsychje> ok tnx Slashman lemme poke some ppl
[17:19] <Slashman> lotuspsychje: thanks
[17:23] <lotuspsychje> Slashman: did you wait long enough till the test is skipped, it might take some time on older machines/media
[21:19] <fretegi> howdy guys
[21:20] <fretegi> quick question, have a running ubuntu server, bought a replacement.. both intel chipsets, dif gen tho.  will the new board in theory boot the old drive?
[21:20] <fretegi> to the point of being able to SSH in, from there i can obviously do what i need to do
[21:21] <fretegi> server is running 16.04 if that helps
[21:23] <RoyK> fretegi: should work unless the chipset is too new for the kernel to support it
[21:23] <RoyK> fretegi: usually that'll be ethernet or wifi drivers
[21:24] <RoyK> fretegi: you might want to try a usb live boot with the same distro version on the new motherboard first, just in case
[21:24] <fretegi> royk, i was hoping for that!  should be good i would think, current server is skylake, new one is haswell, intel nics in both cases
[21:25] <RoyK> fretegi: or - well - just replace it and if the nics don't get online, make sure you have a console handy
[21:25] <fretegi> well catch is.... i dont have a vga input monitor ha
[21:25] <RoyK> heh
[21:25] <fretegi> exactly lol
[21:25] <fretegi> so hoping this thing boots my current install as i can ssh in and do what i need
[21:25] <fretegi> just need a running environment
[21:26] <RoyK> what sort of boot disk or disks do you have on the old system?
[21:26] <fretegi> so i have 1 drive that the complete OS and then a raid array of data drives
[21:26] <fretegi> data already backed up etc.  so gonna build a new array on the new machine
[21:27] <RoyK> ok, so perhaps put the new mobo on some non-conducting surface (a table cloth?) and connect the bootdisk and let it start up and check for results
[21:27] <RoyK> should be a quick test
[21:28] <fretegi> thats a thought, just never tried to boot one OS drive in another machine before
[21:29] <RoyK> it usually works fine
[21:29] <fretegi> Ubuntu installs pretty much all kernel modules right? loading whats needed at boot?
[21:29] <RoyK> it's not like old windoze shite where everything is hardwired to whatever chipset you have
[21:29] <shibboleth> it has separate module packages, -modules and -modules-extra
[21:30] <fretegi> so unless u have hardware so new that proper support doesnt exist on  your installed kernel, should be good
[21:30] <RoyK> fretegi: the kernel will autoload whatever it finds needed according to the pci IDs. Those change sometimes with newer hardware, so it usually works, but not always
[21:30] <shibboleth> the latter typically don't get installed if you choose a virt/minimal baseline
[21:30] <fretegi> RoyK, fortunately for me, actually in a sense downgrading haha.  going to older, but yet more capable gear
[21:31] <RoyK> then it will probably work just fine :)
[21:31] <fretegi> shibboleth, honestly dont recall, pretty sure i did a standard ubuntu server install
[21:32] <shibboleth> dpkg -l | grep linux-modules
[21:32] <fretegi> may even be the same nic chips, checking now and for modules
[21:32] <fretegi> shibboleth, yup exactly, remoting in now
[21:33] <RoyK> fretegi: really, if going to an older intel board, I don't see a problem here
[21:33] <fretegi> shibboleth, yea got both linux-modules && linux-modules-extra should be solid!
[21:33] <fretegi> RoyK, yea me neither.  Perfect well thanks for confirming im not totally nuts guys
[21:33] <fretegi> well at least with this anyhow
[21:34] <shibboleth> also: later kernels (hwe) might enable support for more hw
[21:38] <fretegi> shibboleth, yea good point
[21:45] <fretegi> thanks guys, wish me luck, gonna fiddle with it this weekend if not sooner
[21:59] <RoyK> shibboleth: if it's older hardware, I doubt that'll be a problem
[22:17] <kre10> hey guys, how are you? Can you please help me with something. By my mistake, I added 2 eth0 address on my ubuntu 64 server(raspberry pi 4). And now I have 2 eth0 addresses which is very confusing.


[12:23] <segfault> should we translate the ubuntu logo?
[03:42] <jeffsch> segfault: ping
[03:47] <segfault> pong
[03:53] <jeffsch> segfault: i think i have a solution to your faq guide build problem
[03:53] <jeffsch> can i send you a makefile so you can test it?
[03:56] <segfault> sure
[03:56] <jeffsch><EMAIL_ADDRESS>[03:56] <segfault> yeap
[03:57] <jeffsch> ok
[03:59] <jeffsch> ok, sent
[04:00] <jeffsch> i hope it works :)
[04:01] <jeffsch> if it does, we should find some spot on the wiki for it, so other translators can use it
[04:03] <segfault> ok, i'll test it know
[04:08] <segfault> shouldn't the makefile have a call for xml2po?
[04:08] <jeffsch> hmmm.... that would be good.
[04:09] <jeffsch> for now though, can you do xml2po manually, and then use the makefile?
[04:09] <jeffsch> i can add xml2po and then fix up any problems with the makefile
[04:10] <segfault> yeah, just a minute
[04:11] <jeffsch> we should add an aboutubuntu target also
[04:14] <segfault> that's weird, i'm getting some segfaults while trying to convert some xmls
[04:14] <segfault> Converting C/applications.xml...
[04:14] <segfault> ./pt_BR.sh: line 3: 19098 Segmentation fault      xml2po -p pt_BR/pt_BR.po "$i" >pt_BR/$(basename $i)
[04:14] <jeffsch> hmm...
[04:15] <jeffsch> ok, i know what it is
[04:16] <jeffsch> rob stoffers just changed the faqguide to all one big file about an hour ago
[04:16] <jeffsch> you don't need to convert each one individually any more
[04:16] <segfault> is it on branches/breezy?
[04:17] <jeffsch> i think so. I don't have branches/breezy, only trunk
[04:18] <segfault> lemme see
[04:18] <segfault> Checked out revision 1801.
[04:18] <segfault> nothing new
[04:19] <segfault> well, your script worked for the C stuff
[04:19] <segfault> i guess it is know a problem in our translations
[04:20] <segfault> err, s/know/now
[04:22] <jeffsch> open applications.xml and see if there is anything there
[04:24] <segfault> humm, it worked
[04:24] <segfault> :)
[04:24] <jeffsch> ok good.
[04:24] <segfault> with some hacks, here's what i did:
[04:25] <segfault> for i in C/*xml
[04:25] <segfault> do
[04:25] <segfault>         echo "Converting $i..."
[04:25] <segfault>         xml2po -p pt_BR/pt_BR.po "$i" > pt_BR/$(basename $i)
[04:25] <segfault> done
[04:25] <segfault> so, i parse every xml file..
[04:25] <segfault> then i go up one level, and run your makefile
[04:26] <segfault> it couldn't load some external entities, so i did some symlinks to bypass it:
[04:26] <segfault> lrwxrwxrwx  1 segfault segfault    12 Sep 18 23:23 common -> ../../common
[04:26] <segfault> lrwxrwxrwx  1 segfault segfault    17 Sep 18 23:24 menus -> ../../gnome/menus
[04:26] <segfault> and ran the makefile again, and it generated the html translated files
[04:33] <jeffsch> ok. what can we do to make this easier?
[04:33] <jeffsch> i can change the target to faq instead of faqi386
[04:33] <jeffsch> i can add a target 'au' for about ubuntu
[04:34] <jeffsch> i can add a LANG variable, so you only have to modify the language in one place
[04:34] <jeffsch> is there anything we can do about the symlinks?
[04:36] <segfault> wait..
[04:37] <segfault> just did a cp -r C pt_BR, and ran the make again
[04:37] <segfault> and it built without errors
[04:38] <segfault> and without the symlinks
[04:41] <segfault> i'm trying to find where those entities come from
[04:42] <segfault> global.ent
[04:47] <jeffsch> hmm... you should run the makefile in gnome/ and not generic/
[04:48] <segfault> but the faquide is inside generic
[04:49] <jeffsch> i know. but the makefile contents are copied from the gnome/Makefile
[04:49] <jeffsch> all the directories are relative from gnome/
[04:49] <jeffsch> about ubuntu is in gnome too
[04:50] <jeffsch> a big mess
[04:50] <segfault> hehe
[04:50] <jeffsch> we have a lot of fixing to do after breezy release
[04:50] <jeffsch> live and learn :)
[04:51] <jeffsch> ok i have to go
[04:52] <segfault> me too, tomorrow we can make new tests
[04:52] <segfault> cya, and thanks for the help
[04:52] <jeffsch> np. cya.
[05:31] <Burgundavia> robitaille, which docs?
[05:32] <robitaille> do we talk about the screensaver anywhere?
[05:32] <Burgundavia> don't think so
[05:32] <robitaille> so we're fine  I guess
[05:45] <Burgundavia> robitaille, the faqguide talks little about what is on the system. It mostly talks about what you need to add
[05:52] <Burgundavia> salut jsgotangco
[05:52] <jsgotangco> hi Burgundavia
[05:52] <jsgotangco> how's quickguide?
[05:52] <Madpilot> hi everyone
[05:52] <jsgotangco> i finally got my dsl back
[05:53] <Burgundavia> jsgotangco, there are some edits on my laptop that I need to get off, didn't have a chance to get them off last night
[06:02] <jsgotangco> pinay, hi
[06:03] <pinay> jsgotangco: hi, how is up diliman?
[06:05] <jsgotangco> up pa rin hehehe...seriously though, its been a while since ive been there, but the last time i went there, i did a talk
[06:06] <pinay> jsgotangco: the up campus looked so different when i went home last december, even my school (miriam/maryknoll) looked so different. nakakalito ang katipunan.
[06:07] <jsgotangco> Burgundavia, what does Rosetta mean that it can't handle plurals?
[06:08] <jsgotangco> pinay, its so different now, with the MRT and traffic re-routing
[06:08] <Burgundavia> jsgotangco, I think that is a gettext limitation. I really don't understand it
[06:08] <jsgotangco> i guess manual pot work would be the workaround instead of Rosetta
[06:09] <pinay> jsgotangco: yes, i tried driving there and what a mistake that was
[06:10] <Burgundavia> jsgotangco, I don't think that it is a rosetta thing. it is an underlying gettext thing
[06:11] <pinay> jsgotangco: my husband asked me if i'd be interested in translating documentation for ubuntu, as i am not technical, i told him i'll try
[06:11] <jsgotangco> pinay, are you aware of Rosetta? It's a web interface that allows you to translate
[06:11] <tritium> jsgotangco, I haven't shown her anything yet...
[06:11] <pinay> jsgotangco: no i'm not
[06:12] <jsgotangco> tritium, about-ubuntu is open for translation, its a short doc. the faq guide has a plurals issue with tagalog
[06:12] <jsgotangco> https://launchpad.net/products/ubuntu-doc/+translations
[06:12] <tritium> jsgotangco, okay.  We'll take a look at it.
[06:13] <tritium> Thanks
[06:13] <jsgotangco> a "steve torrefranca" has also contributed
[06:13] <Burgundavia> rob^, shouldn't you have killing the various files that bits of the faqguide?
[06:14] <jsgotangco> tritium, there's also the downloadable pot file but i wouldn't recommend her doing that
[06:15] <tritium> jsgotangco, okay.  If she can do the translating, I can work the the pot file
[06:16] <pinay> jsgotangco: I'll do my best
[06:17] <tritium> jsgotangco, is registration on launchpad enough to get her started?
[06:17] <jsgotangco> pinay, good luck! its fun
[06:17] <jsgotangco> yeah
[06:17] <tritium> awesome, thanks
[06:17] <pinay> jsgotangco: salamat po
[06:17] <jsgotangco> there were a lot of translations of apps pulled from debian already
[06:18] <jsgotangco> the d-i didn't make it though but is currently in sid
[06:18] <jsgotangco> im going to grab a sandwhich for lunch, bbl
[06:18] <tritium> see you
[08:02] <rob^> Burgundavia, ?
[08:05] <Burgundavia> rob^, you emptied the files of contents but didn't delete the files themselves
[08:05] <rob^> Burgundavia, no I didn't did I
[08:05] <rob^> does it matter?
[08:05] <Burgundavia> not really, just making sure that is what you intended
[08:06] <rob^> yeah
[08:06] <jsgotangco> Burgundavia, i have the MS OEM CD here with me FYI
[08:06] <rob^> Whoever did the xinclude tags missed a whole chapter
[08:09] <jsgotangco> why is work being done in trunk?
[08:10] <jsgotangco> Burgundavia, the WindowsXP OEM Preinstallation kit contains a ton of documents and scripts, but it has a basic document called Step-by-Step Guide mabye this is the one you are looking for?
[08:14] <Burgundavia> jsgotangco, ya, that is likely what i looking to replicate
[08:15] <Burgundavia> jsgotangco, but the whole kit would be nice to parse
[08:15] <Burgundavia> jsgotangco, how did you get yours?
[08:15] <jsgotangco> Burgundavia, that's hard, I was browsing at the cd now and it looks terribly complicated really
[08:15] <jsgotangco> the step by step alone is 48 pages
[08:15] <Burgundavia> ouch
[08:15] <Burgundavia> we can do better than that
[08:16] <jsgotangco> well the oem stuff has branding covered as well
[08:16] <jsgotangco> like adding logos and stuff
[08:16] <Burgundavia> yes, that is other side I was looking at
[08:17] <jsgotangco> now if we had a working OEM cd, when a user clicks about ubuntu, it would probably show diagnostics and the logo of the oem
[08:17] <Burgundavia> hmm
[08:18] <jsgotangco> wonder where gnome can do something like that
[08:20] <Burgundavia> the diags?
[08:20] <jsgotangco> i think the same docs/apps can be pulled from microsoft.com/oem
[08:20] <jsgotangco> but that defeats the purpose of the oem
[08:20] <jsgotangco> heh
[08:22] <Burgundavia> nto really
[08:22] <Burgundavia> a lot fo the windows oem branded stuff is extra programs
[08:22] <Burgundavia> oems are in the business of services and hardware, not software develoment
[08:22] <Burgundavia> remember, even the largest OEM is a minnow to MS. We can and are different
[08:22] <jsgotangco> our best conservative target is just to make a guide for now
[08:22] <Burgundavia> yes
[08:22] <jsgotangco> Burgundavia, what's your jabber id?
[08:24] <Burgundavia><EMAIL_ADDRESS>[08:30] <jsgotangco> Burgundavia, looks like our OEM stuff is non-existent in the help department i couldn't even find it on the cd
[08:31] <Burgundavia> we have no OEM help
[08:38] <jsgotangco> nice
[08:38] <Burgundavia> hence why I started thinking about it
[08:42] <Madpilot> in the context of help, what is OEM help, vs any other sort
[08:42] <Madpilot> ?
[08:42] <jsgotangco> a guide to have ubuntu pre-installed
[08:42] <jsgotangco> its a system builder thing
[08:43] <Madpilot> ah, OK. got it.
[08:43] <Madpilot> so the target would be the computer companies themselves, and/or the resellers?
[08:44] <Burgundavia> anybody that needs to put Ubuntu on a machine and sell it
[08:44] <jsgotangco> the the computer manufacturters is a different level
[08:57] <jsgotangco> night
[09:48] <dholbach> hi
[09:48] <jsgotangco> hi dholbach fancy seeing you here =)
[09:49] <dholbach> hey jerome :)
[09:49] <dholbach> i asked this already some days ago - do you cover gnome-bittorrent on any screenshots or somewhere in the documentation?
[09:49] <dholbach> somebody wnats me to change the menu entry to say something else
[09:49] <jsgotangco> somebody is influential? =)
[09:50] <dholbach> somebody is "Evandro Fernandes Giovanini<EMAIL_ADDRESS>:)
[09:50] <jsgotangco> im not sure if its in the faqguide...
[09:50] <dholbach> or in a menu editor screenshot or something
[09:51] <dholbach> if it isn't, i'll ask mdz/kamion for approval
[09:51] <dholbach> and then upload it :)
[09:51] <jsgotangco> change the name to what?
[09:51] <dholbach> from GNOME BitTorrent to BitTorrent
[09:52] <jsgotangco> not sure how big an impact that is but documentation wise, it shouldn't be that much on an effort
[09:52] <jsgotangco> unless there are already finished docs that are translated
[09:52] <jsgotangco> its only 1 string
[09:53] <dholbach> yeah, that's what i thought
[09:53] <dholbach> the change would make sense for me
[09:53] <pedri2> hello jsgotangco
[09:53] <jsgotangco> hi irvin
[09:54] <irvin> how was linuxworld?
[09:54] <jsgotangco> awesome
[09:54] <jsgotangco> i had a pic with 3 MS booth girls
[09:54] <dholbach> haha :)
[09:54] <irvin> i've been so busy
[09:54] <jsgotangco> dholbach, yeah we had an MS booth
[09:55] <jsgotangco> it was BIGGER han Red Hat's booth
[09:55] <irvin> i had to migrate two internet shops to kubuntu
[09:55] <jsgotangco> ahh
[09:55] <jsgotangco> irvin, we're planning a hackfest sometime in november, its possible RMS will come
[09:55] <irvin> really? nice if i could join
[09:56] <jsgotangco> sure its supposed to be open not like linuxworld
[09:57] <irvin> what did you talk about in linuxworld?
[09:57] <jsgotangco> since stallman is working with the undp and iosn lately, he's more than willing to go over here
[09:58] <irvin> it would be a wonderful opportunity for him to meet with politicians to push through open source
[09:58] <irvin> its about time
[09:59] <irvin> i'm doing my share here in the province
[09:59] <jsgotangco> sure marvin (pascual) got to have dinner with him in bangkok
[09:59] <jsgotangco> PLUG is already recognized by the IOSN and UNDP
[10:00] <irvin> that is good news. what we need are stronger lobbyists in congress
[10:01] <jsgotangco> irvin, let's move to #ubuntu-ph (this is a doc channel btw)
[10:01] <irvin> i'll be writing to my congressman soon
[10:01] <irvin> i see
[10:01] <irvin> sorry didn't know
[10:01] <jsgotangco> no worries
[10:07] <sivang> morning all
[04:34] <mgalvin> hi all, long time no see


[10:44] <Fudge> have their been any regressions with at-spi for precise. Last few days I have been experiencing strange workplace issues and at times it seemed like my alt commands were not working and had to ltask switch through the launcher. unity-2d
[23:02] <TheMuso> Fudge: Not so far as I know.
[23:03] <TheMuso> Fudge: You could try reverting back to at-spi2-core 2.4.1 to be sure.
[23:25] <Fudge> thanks


[18:07] <omar> hello
[18:08] <omar> is there software in edubuntu that can be used t monitor desktop and limit internet usage
[18:08] <omar> im new to edubuntu
[18:26] <highvoltage> italc could possible do what you need for viewing desktops
[18:46] <bencrisford> highvoltage: is there a meeting tonight?  I just remembered what day it is
[18:50] <highvoltage> bencrisford: yep
[18:51] <highvoltage> bencrisford: and for a change I'll have some things to report again!
[18:51] <bencrisford> highvoltage: I can't wait :).  1900 UTC?
[18:53] <omar> highvolatge thanks for that suggestion .. free open source -- thanks a million
[18:54] <mhall119> dang, same time as the #ubuntu-youth meeting
[19:21] <highvoltage> mhall119: btw, have you made any progress with the gnome session for qimo?
[19:30] <mhall119> highvoltage: honestly, I haven't started anything for the next round of Qimo yet
[19:30] <mhall119> been dealing with family issues
[19:31] <highvoltage> mhall119: ok, I was thinking in terms of what we should include in the installer as options
[19:32] <mhall119> I think the gnome session is going to require some gconf changes, so I'll have to figure out how to make that play nice with the regular Gnome session
[19:33] <highvoltage> mhall119: what's the problem there? I can help if you want?
[19:34] <mhall119> I just need to make sure my gconf settings are kept separate from the other session's gconf settings
[19:35] <highvoltage> mhall119: why?
[19:35] <mhall119> so there can be separate "Qimo Session" and "Gnome Session"
[19:35] <highvoltage> ah, ok
[19:36] <mhall119> otherwise when I apply panel configs in Qimo Session, they'll be applied in Gnome Session too
[19:36] <highvoltage> yeah I didn't think of it as so much of a problem, but it would be nice being able to have the option at login time
[19:36] <mhall119> for Xfce, I had to change the value of XDG_CONFIG_HOME to be ~/.qimo instead of ~/.config
[19:37] <mhall119> that's the way it currently is, Qimo has a Qimo Session, and also an Xubuntu Session
[19:38] <mhall119> does Edubuntu have it's own Session?
[19:38] <mhall119> separate from Gnome Session?
[19:41] <Lns> mhall119: no
[19:41] <Lns> Edubuntu isn't a window manager/DE
[19:41] <mhall119> neither is Qimo
[19:41] <mhall119> or Xubuntu
[19:42] <Lns> right
[19:42] <Lns> totally different concepts
[19:42] <mhall119> but both Qimo and Xubuntu have their own Sessions
[19:42] <mhall119> separate from the Xfce Session
[19:42] <Lns> they do?? lol
[19:43] <Lns> that's....weird
[19:43] <mhall119> Session == WM/DE + Default settings
[19:43] <mhall119> Qimo Session = Xfce + Qimo settings
[19:44] <mhall119> no reason Edubuntu can't be Gnome + Edubuntu settings
[19:44] <Lns> so a session can apply specific gconf settings? What's the scope of "Default settings" ?
[19:44]  * Lns thinks an LTSP "Session" is in order to fix a LOT of problems regarding networked X
[19:44] <mhall119> in the case of Qimo, it keeps Xfce configs separate from the Xubuntu session
[19:44] <mhall119> Qimo's default settings are things like panel layout, launchers, gtk theme and wallpaper
[19:45] <Lns> wow, i had no idea sessions incorporated things like that
[19:45] <mhall119> they can
[19:45] <highvoltage> mhall119: edubuntu just changes the default gconf keys
[19:45] <mhall119> just change where it gets the default settings and where it stores them under ~
[19:46] <mhall119> highvoltage: in that case, maybe we can do both a qimo-session-gnome and edubuntu-session-gnome
[19:50] <mhall119> Lns: http://img39.imageshack.us/img39/8941/qimosession.png
[19:50] <mhall119> the same user can jump between Qimo session and Xubuntu session, without changes made to one bleeding over into the other
[19:51] <Lns> that is fantastic!
[19:51] <Lns> that would be very useful in a heterogeneous ltsp/workstation environment
[19:53] <mhall119> the thing with gconf, though, is that we really only want to keep separate gnome settings
[19:54] <mhall119> there's no reason to keep Qimo's gedit settings for a user separate from their Gnome Session gedit settings
[19:58] <highvoltage> on an installed edubuntu system, there really wouldn't be much difference between an edubuntu session and a gnome session anyway
[19:59] <highvoltage> (although that might not always be the case in the future)
[19:59] <highvoltage> Edubuntu meeting time :)
[20:00] <bencrisford> woo :)
[21:06] <mhall119> highvoltage: apt-cache show desktop-profiles
[21:32] <mhall119> highvoltage: looks like I can set an environment variable to change the placement of the user's gconf data, but it's going to be all or nothing
[21:43] <mhall119> which I guess isn't that bad
[21:44] <mhall119> I'll talk to you later about it, heading home now


[10:10] <simar> what is the purpose of the driver package kbd, evdev, mousedev are these part of kernel or x?
[19:08] <Sarvatt> anyone know how to fix all these undocumented parameter warnings in libxcb's tests? http://sarvatt.com/downloads/libxcb_1.6%2bgit20100703.75ff427d-0ubuntu0sarvatt2_i386.build
[19:16] <Sarvatt> i guess its a doxygen problem, WARN_IF_UNDOCUMENTED   = NO is set in xcb.doxygen.in and isn't getting honored
[22:08] <Sarvatt> hope i can get away only updating libxcb and xcb-proto, xcb-util has a few soname bumps and i dont fancy breaking the things depending on libxcb-icccm1 and libxcb-event1
[22:09] <Sarvatt> someone emailed me saying libxcb needed updating past 1.6 because it was breaking things with the newer libx11 in xorg-edgers
[22:11] <Sarvatt> isn't libX11 1.3.4 in debian too? http://cgit.freedesktop.org/xcb/libxcb/commit/?id=b0525e242368fffbc77ebb45293f34e80847e65a is apparently needed with it
[22:12] <jcristau> no, still 1.3.3
[22:19] <Sarvatt> ah not released yet, thought i saw it merged on debian-x
[22:24] <Sarvatt> I'm just a user running into a nasty bug: libxcb 1.6's release doesn't have necessary updates (already in git) vs. libX11 1.3.4. The result is (at times) low performance, with the ability for various apps (including compiz) to completely stop responding. How to trigger it, and what it does, are extremely inconsistent even just over time because the code is made racy. compiz and dolphin-emu (from another PPA) are both keen on triggering this bug,
[22:24] <Sarvatt>  but other compositing window managers (such as kwin and mutter) can also experience (on my machine) up to a 40% drop in performance, when they don't hang.
[22:27] <Sarvatt> and hesays that libxcb commit fixes it as does downgrading to libx11 1.3.3