[15:10] <odra> Hello
[15:13] <odra> Are strings like "Open File..." and "Save File..." where the first letter of each word is capitalized permitted in English?
[15:13] <odra> That is, it is correct English?


[00:41] <infinity> Daviey: It's on my TODO.
[01:08]  * infinity wonders what the new mesa broke in EGL that makes qt4 unhappy.
[01:11] <broder> slangasek: ok. just uploaded the insserv SRUs; apologies for the stalling
[01:13] <maco> cyphermox: woooooah, somebody's actually looking at that bug
[01:13] <maco> i forgot about it
[01:20] <RAOF> infinity: Oh, what's happening?
[01:21] <infinity> RAOF: qt4-x11 no buildy on arm{el,hf}, whining about GLES not functioning.
[01:22] <RAOF> Hm.  Got a buildlog url handy to save me the trouble?
[01:22] <infinity> RAOF: I haven't looked into it yet, in the (perhaps misguided) hope that the folks who uploaded the shiny new mesa upstream may either be (A) aware of it, or (B) prepared to take responsibility and dig deeper.
[01:22] <cyphermox> maco: yeah, at it would take the best of 50 seconds to implement ;)
[01:22] <infinity> RAOF:
[01:22] <infinity> https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.0-1ubuntu8
[01:22]  * RAOF would be one of the people responsible for mesa, so…
[01:23] <infinity> RAOF: Same failure pattern on armel and armhf, so pick randomly.
[01:24] <RAOF> Huh.  Cannot find -lEGL on armel and armhf, but not i386 or amd64?  Oddness.
[01:24] <infinity> RAOF: Not odd in the least, x86 links against OpenGL, arm links against OpenGLES.
[01:25] <infinity> RAOF: So, EGL is /probably/ broken on all platforms, but it's only showing up on ARM because QT4 uses GLES on ARM.
[01:25] <RAOF> Right.
[01:26] <JontheEchidna> fwiw, the latest updates (dist-upgrade) wants to remove the egl stack from my computer.
[01:28] <RAOF> JontheEchidna: You're probably seeing multiarch archive skew.
[01:29] <JontheEchidna> yes, I did notice some 386 packages involved
[01:29] <JontheEchidna> ah, yeah. looks like the ia32libs update is causing the issues
[01:31] <RAOF> EGL doesn't *seem* to be broken on amd64.
[01:35] <infinity> RAOF: Hrmph.  So the breakage was tailor-made just for ARM?  How kind. :P
[01:35] <RAOF> Hm, no.
[01:35] <RAOF> Aha.  There it is.
[01:36] <smoser> hey...i shoved a 'ps w' into initramfs, and see http://paste.ubuntu.com/854829/
[01:36] <smoser> does that seem right?
[01:36] <smoser> bah. first one missing some. second
[01:36] <smoser> http://paste.ubuntu.com/854831/
[01:36] <infinity> smoser: Could be a tiny bit excessive.
[01:37] <RAOF> infinity: Ah, yeah.  We dropped a symlink on the floor.
[01:37] <infinity> smoser: Is it actually eating CPU time, or is it just a ton of idle chilren spawned during the initial event storm on boot?
[01:37] <infinity> RAOF: Glad it's something that simple.
[01:38] <smoser> well, its not the cpu time i'm concerned about.
[01:38] <smoser> i was debugging bug 937352
[01:38] <RAOF> infinity: Presumably you'd like that to make B1? :)
[01:38] <infinity> RAOF: If you could be so kind.
[01:39] <smoser> and trying to find out what might cause 'BLKRRPART: Device or resource busy'
[01:39] <smoser> i'm not sure that any of the processes in that output have an open handle (as this run didn't fail to resize)
[01:43] <smoser> infinity, you think each of those udevadm processes is handling an event ?
[01:43] <infinity> s/adm/d/
[01:43] <infinity> smoser: No, they're probably all idle.
[01:43] <infinity> smoser: But on a massive event storm (such as initial boot), a ton of children can spawn to handle them.
[01:44] <smoser> ah.
[01:44] <infinity> smoser: In theory, they get reaped.
[01:44] <infinity> smoser: (And on the pivot to real root, I think udev gets restarted, which effectively reaps them anyway)
[01:45] <infinity> slangasek: Can explain it all better than I, but I'm assured that it's basically like a ghetto implementation of apache's prefork child model, and "nothing to be concerned about" (as long as they're not spinning your CPU to death)
[01:45] <infinity> Err, s/://
[01:46] <smoser> yeah.. i'm not too concerned about it.
[01:46] <smoser> but basically, for that bug, i'm trying to figure out what it is that had a open handle on /dev/vda
[01:46] <smoser> to see what was keeping it busy
[01:48] <infinity> I don't suppose your growroot code shares any common ancenstry with jasper_growroot?
[01:48] <smoser> the current suspicion is that there are some udev processes (like blkid) around at that time, and in racey conditions, i'm hitting sfdisk failure.
[01:48] <infinity> Cause I remember fixing a few races in that last cycle.
[01:48] <smoser> if that is the case, then udevadm settle would fix it
[01:48] <smoser> no relation to jasper_growroot.
[01:49] <smoser> i dont know which came first
[01:49] <infinity> Hrm.  Maybe they should consider mating.
[01:49] <smoser> but i only learned of jasper_growroot a while ago.
[01:49] <smoser> yeah.
[01:49] <infinity> Duplicate code offends me. ;)
[01:50] <smoser> link to jasper growroot source?
[01:50] <infinity> But given that we do the same basic thing on SD cards (which, due to their horrible speed, are WAY more racy than anything you're writing to), maybe it's just an ordering thing, or something.
[01:51] <smoser> well... you might be surprised at disk speed.
[01:51] <infinity> I might be. :)
[01:51] <smoser> this particular case is qcow disk backed by a file on a filesystem.
[01:51] <infinity> Still not sure that beats SD.
[01:52] <smoser> so even reads are going read -> qcow-delta -> qcow-backing file -> filesystem file -> disk
[01:52] <infinity> Anyhow, lp:ubuntu/jasper-initramfs is the source.
[01:52] <infinity> It's hackish (your is probably prettier, though I haven't looked, it's a fair assumption), and makes assumptions about device names, but the general step-by-step resizing bit is solid and doesn't seem to break no matter how we stress it.
[01:53] <smoser> the next big move is to ditch the initramfs code all together.
[01:53] <smoser> as psusi (probably spelling name wrong) says that new kernel features allow us to resize a partition that is mounted
[01:53] <maco> cyphermox: i know you're an ubuntu member. does lwn.net say you are or arent a subscriber?
[01:54] <infinity> smoser: Yup.  Moving jasper-initramfs resize into partman in d-i is on my agenda.
[01:54] <infinity> smoser: At which point, I might be able to reach some magical fairytale land of being able to do preinstalled/copy installed to/from the same media!
[01:55] <smoser> well, in my case it doesn't have to be in initramfs or installer (cloud images)
[01:55] <smoser> it would just run on first boot
[01:55] <smoser> (or every boot, and do nothing if not needed)
[01:55] <infinity> smoser: (ie: use "normal" live media to both do a live install to another disk, or to just resize itself)
[01:56] <smoser> you maybe shoudl look at 'growpart' which is the primary code in 'growroot'
[01:56] <smoser> (growroot just calls growpart)
[01:56] <smoser> and it may be prettier, i dont know.
[01:56] <smoser> same basic idea, using sfdisk.
[01:56] <infinity> I didn't write jasper, and if asked, Oliver will admit that it's hideous. ;)
[01:57] <infinity> But yeah, when the "move it all to d-i" thing happens, I'll rewrite, and look at other implementations.
[01:57] <smoser> growpart is in cloud-utils. it has a dry-run, so you can test it out.
[01:59] <cyphermox> maco: I think I didn't have an account. I may be able to respond tomorrow, assuming their system updates regularly for this stuff
[01:59] <maco> cyphermox: oh ok. nvm then
[02:00] <infinity> RAOF: If you fix mesa for me, be sure to poke me, so I can massage it through the queue.
[02:01] <RAOF> I'm fixing now.  I'll prod you once I've uploaded.
[02:01] <infinity> RAOF: My hero. ;)
[02:04] <infinity> Sweetshark: Does libreoffice-voikko need some massaging to build with the new LibO upstream?
[02:04] <infinity> Sweetshark: https://launchpadlibrarian.net/94071457/buildlog_ubuntu-precise-armhf.libreoffice-voikko_3.2-2_FAILEDTOBUILD.txt.gz
[02:04] <infinity> Sweetshark: (Or perhaps the new LibO is missing some SDK bits?)
[02:08] <micahg> infinity: new version in sid, don't know if that'll fix it
[02:09] <infinity> micahg: Hard to say, since it built against LibO 3.4.5 in sid.
[02:10] <micahg> one way to find out, /me kicks off a build
[02:16] <micahg> infinity: nope, doesn't work
[02:19] <micahg> infinity: would you be willing to process removals from Ubuntu that happened in Debian?  /me wants to fix FTBFS over the weekend, but figures quite a few are in that category
[03:27] <RAOF> infinity: Sitting in the queue now.
[03:29] <slangasek> broder: insserv> yay, thanks
[03:37] <scientes> where is KMOD?
[05:55] <pitti> Good morning
[05:59] <nigelb> Morning pitti
[06:05] <scientes> where is the ubuntu kmod?
[06:07] <pitti> scientes: we don't have it yet; it's a bit too young to put into an LTS at this time, we'll get it next cycle
[06:07] <broder> pitti: did we not at least get it into universe?
[06:07] <pitti> seems not; we don't need it anywhere yet, and it will quickly get outdated, so backports etc. sound better for this
[06:08] <micahg> pitti: I see some upgrade failures because cups can't be configured, can you take a look (bug 939977 and bug 939979)
[06:10] <pitti> micahg: yes, in a sec
[06:11] <micahg> sure, no rush
[06:42] <pitti> infinity: linux-meta-armadaxp builds a linux-tools-armadaxp which depends on a nonexisting linux-armadaxp-tools-3.0.0-1500
[06:42] <pitti> infinity: is that supposed to exist, or copy&paste error when creating the -meta?
[07:27] <infinity> pitti: The tools build is turned off in the kernel temporarily because it was broken and getting a kernel uploaded was more important than fixing the tools, AIUI.
[07:27] <pitti> infinity: ack; so it's supposed to be there and will come back then?
[07:27] <pitti> erk, I just got another wubi build failure due to ext4
[07:28] <infinity> pitti: In theory, the tools will come back, yeah.  If not, we'll drop them from the meta.
[07:28] <infinity> pitti: And, err.  ext4 failures shouldn't happen anym--... Unless I forgot to pull my branch on nusakan.
[07:28] <infinity> Which I did. >:(
[07:29] <infinity> pitti: Fixed now.
[07:29] <pitti> infinity: cheers
[07:35] <dholbach> good morning
[07:37] <micahg> janimo`: did libreoffice-voikko build for you?  it failed for me earlier this evening
[07:40] <infinity> micahg: And just failed on all the buildds.
[07:40] <micahg> infinity: we had this conversation 6 hours ago ;)
[07:40] <infinity> micahg: But at least the sync has the advantage of hilighting that it's not an arch-specific problem, so someone will perhaps fix it. :P
[07:40] <micahg> infinity: the archive rebuild did that :P
[07:41] <infinity> micahg: People pay less attention to rebuilds than I'd like. :/
[07:41] <infinity> (We need to figure out how to fix THAT)
[07:41] <micahg> we've fixed >100 since the last rebuild happened
[07:42] <micahg> ~270 failures superseded
[08:14]  * nixternal remembers when micahg used to be in bed at like 9pm here in chicago
[08:14] <nixternal> grr, that was supposed to be in a totally difference channel. hit enter instead of alt+p to get to our chicago chan. sorry
[08:15] <micahg> heh
[08:15] <slangasek> now we know about your secret backchannel
[08:16] <slangasek> you'll all have to move to Wisconsin
[08:16] <micahg> or Portlandia :)
[08:18] <nixternal> Wisconsin? that place still exists?
[08:19] <micahg> it's Dellicious :)
[08:19] <slangasek> is that the new catch phrase?
[08:19] <nixternal> didn't the government go on strike there? though I shouldn't joke about that, since our government here in Illinois & Chicago is constantly going to prison
[08:36] <infinity> micahg: So, voikko upstream claims 3.3 works with LibO 3.5 (in fact, is has 3.5-specific features), so I suspect the failure is in our LibO packaging breaking the SDK.
[08:36] <micahg> ok, so that means Sweetshark^^ :)
[08:38] <RAOF> Hm.  How hard is it to create a C++ function that takes a unary function and returns a nullary function?
[08:38] <infinity> micahg: (I have no hard evidence to back up my assertion, mind you) :P
[08:41] <Sweetshark> infinity, micahg: oh, great. I will have a look.
[08:42] <infinity> Sweetshark: Thanks.
[08:43] <micahg> Sweetshark: Mirv is the Debian maintainer, so it shouldn't be too hard to coordinate :)
[08:43] <pitti> RAOF: creating functions on the fly in C++?
[08:43] <pitti> RAOF: or just returning a pointer to one out of N existing functions?
[08:44] <RAOF> Creating functions on the fly.
[08:45] <RAOF> Now that I *say* this, I know it's possible, but that I'll be overloading operator ().
[08:45] <pitti> RAOF: in C++? (or any compiled language for that matter..)
[08:46] <RAOF> pitti: Well, it's more: take a function f(x) taking a single parameter, and a parameter z, and return a function which evaluates to f(z)
[08:46] <pitti> RAOF: haskell FTW
[08:46] <pitti> RAOF: so just "return f(z)" is too simple, I guess
[08:47] <ion> Haskell ♥
[08:47] <RAOF> Right.  I need a nullary function :)
[08:47] <pitti> i. e. you really want f o z, and want to call it yourself
[08:47] <Sweetshark> RAOF: 'on the fly' as in 'not known at compiletest' => impossible. of course you could write an interpreter *mumble* every language becomes a dialect of lisp at some point in time.
[08:48] <slangasek> RAOF: is the function type fixed?
[08:48] <RAOF> Sweetshark: Well, the underlying function f is known at compile time; I basically want to specialise a closure.
[08:48] <slangasek> or do you have to cope with arbitrary function signatures? :P
[08:48] <Sweetshark> ROAF: functors/function objects are your friend then
[08:48] <Sweetshark> RAOF: for variable meanings of friend
[08:48] <RAOF> slangasek: Indeed it is fixed.  Now that I've said this out loud I know I (a) can do it, (b) can get the outcome I want without all this faffing around.
[08:49] <slangasek> ok :)
[08:50] <Sweetshark> RAOF: http://www.boost.org/doc/libs/1_48_0/doc/html/lambda/le_in_details.html#lambda.bind_expressions <- if you want to get nifty
[08:51] <RAOF> Yeah, I think I'll keep my niftiness for features rather than arcane language extensions :)
[08:57] <Sweetshark> RAOF: yes, that kind of niftiness caused a coworker of mine preaching to gcc, MSVC and SunStudio compilers from his Bjarne-C++-Standardbook, because once he had it so that MSVC wouldnt complain anymore, SunStudio would barf at him -- with both implementations being valid C++ by the book.
[08:57] <RAOF> Ah, Mr Undefined Behaviour!
[08:58] <Sweetshark> RAOF: it not so much an issue with one compiler.
[08:58] <Sweetshark> RAOF: No, it was defined behaviour, but MSVC and SunStudios brains were to small for the insanities of the C++ standard.
[08:59] <RAOF> Ah.  Right, that other form of C++ fun.
[08:59] <ion> Some quotes from a #haskell bot. :-) <lambdabot> mikeash says: you may have noticed that templates being turing complete theoretically allows you to add any language capability to C++.... so did the boost guys.   <lambdabot> kmc_ says: you should take a look at Boost, they implement things like Maybe and tuples in only a few thousand lines of C++
[08:59] <Sweetshark> (and did spit out template errormessages pagewise)
[09:01] <ion> Also, http://pikersden.eu/~eclipser/err.txt
[09:01] <Sweetshark> ion: what to have a fibonacci sequence, but you dont have execution rights on your /home? use templates as an interpreted language: http://blog.emptycrate.com/node/271
[09:02] <ion> heh
[09:02] <Sweetshark> ion: boost::spirit is its own kind of insanity.
[09:03] <Sweetshark> ion: also boost is just a implementation of greenspuns 10th rule of programming
[09:06] <broder> RAOF: C++11 has lambdas
[09:08] <broder> though i'm not sure if you can represent a function type in pure C++ or if you need to pull in boost::function
[09:09] <broder> i guess you can just use a function pointer? the memory management there isn't really clear
[09:16] <Sweetshark> broder: http://ask.slashdot.org/comments.pl?sid=2659339&cid=38964635
[09:18] <broder> i think as long as i capture by value i can do what RAOF wants
[09:19] <broder> http://paste.ubuntu.com/855140/
[09:19] <broder> (build with g++ -std=c++0x)
[09:20] <RAOF> Turns out I can do it just as easily with a static class funtior.
[09:21] <RAOF> Although I forgot how crazy initialising a static member in C++ is.
[09:29] <Sweetshark> infinity, micahg: openclipart and voikko soon fixed upstream at debian it seems.
[09:29] <Sweetshark> (kudos to _rene_)
[09:30] <infinity> Sweetshark: Kay.  So, not a LibO packaging goof?  I just heard the buildds breathe a sigh of relief.
[09:32] <Sweetshark> infinity: no. from 3.5 on the basis-link stuff has changed and that needs to be adjusted in packages relying on it.
[09:32] <infinity> Sweetshark: Fair enough/
[09:32] <Sweetshark> infinity: I have enough fun for the buildds in the pipe still :/
[09:33] <Sweetshark> infinity: btw I made the disc usage of the package quite a bit smaller by using hardlinks/symlinks in the build and testinstall ...
[09:33] <infinity> Sweetshark: *cups his hands over the Pandas' ears*
[09:34]  * Sweetshark pads pandas on the heads.
[09:34] <Sweetshark> They do a good job. Much faster than the old buildds.
[09:35] <infinity> Yup.  We have much faster hardware in the pipe, we just need to get some vendors to admit it exists and, like ship it.
[09:46] <dholbach> Happy Fix It Friday!
[09:52] <sladen> dholbach: https://wiki.ubuntu.com/Membership/LWN  is that ACLed?
[09:52] <sladen> dholbach: I'm trying to update it to add the details about expiry
[09:53] <dholbach> sladen, unless I'm VIP, no
[09:53] <sladen> dholbach: you were the last person to edit it (in 2009)
[09:54] <Guest43539> Hi, I joined ubuntu-mobile yesterday however that channel now seems closed. I am interested in the Ubuntu for Android project and well helping in contributing towards it's development. Can anyone direct me to the right place?
[09:54] <dholbach> sladen, are you logged in?
[09:54] <sladen> dholbach: yes
[09:55] <dholbach> does logging in/out fix it? I wouldn't know how to unACL it or where to check if it is
[09:55] <ajmitch> dholbach: if it's an ACL, it should be at the top of the raw text
[09:55] <ajmitch> (iirc)
[09:56] <dholbach> ajmitch, no, there's nothing there :/
[09:56]  * ajmitch can edit the page, so it doesn't look to be locked
[09:59] <janimo`> micahg, no it does not build. I just synced form Debian so we get it FTBFS on all arches and it does not look like an armhf specific thing which may lead people down the wrong paths
[10:00] <janimo`> was that a bad thing to do?
[10:02] <infinity> janimo`: It's all good, _rene_ is all over fixing it in Debian and filing bugs.
[10:02] <janimo`> infinity, yes, noticed just a few mionutes ago in the LibO-dev channel
[10:02] <infinity> janimo`: But the sync was probably unnecessary, people were aware it wasn't arm-specific.
[10:03] <ajmitch> sladen: manage to edit it?
[10:03] <janimo`> infinity, I was not, and maybe other arm ftbfs hunters were in the same boat
[10:03] <janimo`> I automatically skip all-red rows in the table whereas arm column only jump out :)
[10:03] <infinity> sladen: My usual advice for wiki ACL issues is "hit Ctrl-R harder".
[10:04] <janimo`> I then saw there was an i386 bug filed on voikko, from the autobuilds
[10:04] <infinity> sladen: (It has no ACL that I can see)
[10:13] <apw> ev, i just got a package installation error and when the crash detect stuff fired, it said 'This report is damaged and cannnot be processed.", reporting an IOError(13, 'Permission denied')
[10:18] <sladen> infinity: dholbach: ajmitch: ta.  Eventually managed it using a separate 'lynx' sessions running in a terminal
[10:18] <dholbach> wow
[10:19] <ajmitch> that's pretty special
[10:20] <ajmitch> useful to know about the expiry time though
[10:20] <sladen> the crash reporting process about the crash crashed, so we've fired up a crash reporting process to report the crash that was being reported when it crashed
[10:21] <infinity> drwatson used to have that bug...
[10:21] <infinity> Infinite watsons on early NT4 was no end of fun.
[10:26] <ogra_> hmpf, why are the sound settings so screwed up since yesterdays upgrade
[10:27] <ogra_> the hardware tab is gone, so i cant select the mode my BT headset uses anymore
[10:27] <pitti> that hardware tab was really confusing
[10:27] <pitti> ogra_: the mode is in the output tab now
[10:28] <ogra_> pitti, well, its the only way for me to make my BT headset not run in hifi mode (e.g. as an actual headset to use the mic)
[10:28] <exco> what package do I file bugs in carl9170 against?
[10:28] <pitti> ogra_: hm, that seems to work fine here
[10:28] <ogra_> its greyed out (as it always was ... apart from the HW tab i could set it nowhere)
[10:29] <pitti> ogra_: oh, indeed; same here
[10:30] <ogra_> pitti, i could imagine that settings that can only apply globally (in *and* output) become greyed out
[10:30] <pitti> diwic: ^ who worked on that again?
[10:30] <ogra_> i can select output for the builtin speaker vs the plugged headset
[10:31] <ogra_> but cant change a thing for settings that need to apply for both, in and out at the same time anymore
[10:31] <diwic> pitti, me and ronoc
[10:31] <pitti> ogra_: in the past I didn't even have to -- my headset just used the low-quality bidir mode in mumble and friends
[10:31]  * ogra_ wonders if there is a cmdline way to tell his BT headset to not use hifi mode
[10:32] <diwic> ogra_, there is
[10:32] <diwic> ogra_, want me to tell you? :-p
[10:32] <ogra_> diwic, that would be awesome :)
[10:33] <diwic> ogra_, anyway the easiest workaround is to install pavucontrol which is an alternative GUI
[10:33] <ogra_> ok
[10:33]  * ogra_ does so
[10:33] <diwic> ogra_, you should be able to set profile from the "configuration" tab in that application
[10:34] <ogra_> ok
[10:34] <diwic> ogra_, but also file a bug against the gnome-control-center package, please
[10:34] <ogra_> will do
[10:35] <diwic> ogra_, out of interest, what profiles can you select between?
[10:36] <ogra_> HSP/HFP and A2DP
[10:36] <diwic> ah, same as here then
[10:36] <diwic> I should be able to reproduce it
[10:43] <ogra_> hmpf, the mumble setup wizard just hangs after i selected the device :(
[11:35] <Sweetshark> that would mean rolling back the sacjava, libbase MIRs as they are only needed for reportbuilder and (no libloader=no reportbuilder). meh.
[11:35]  * Sweetshark needs to take a walk.
[11:40] <pitti> Sweetshark: don't worry about the rollback; they will semi-automatically fall out of main again as soon as you drop the b-deps
[11:40] <jibel> slangasek, re upgrade of main - no idea why apt-term.log shows only removals. It looks like a bug in update-manager.
[11:41] <jibel> slangasek, the only log file I found which shows which packages have been upgraded is dpkg.log. It is attached to the test results
[11:42] <jibel> slangasek, I saved the VM if any one want to look into this.
[12:27] <infinity> Sweetshark: Are you already aware of the need for a !armhf fix for the libreoffice-report-builder-bin depdency in the libreoffice metapackage?
[12:28] <infinity> Sweetshark: (Or, alternately, building it for armhf, I guess, but it's not currently)
[12:30] <Sweetshark> infinity: unfortunately the solution is dropping it, as reportbuilder pull in a huge java mess called maven in.
[12:30] <infinity> Sweetshark: Actually, I'm confused now.  Is it built anywhere anymore?
[12:30] <infinity> Sweetshark: The version in the archive on other arches seems to be stale.
[12:31] <infinity> Sweetshark: So, that dep should just be dropped from the metapackage entirely, for all arches...?
[12:33] <TLE> pitti: hallo
[12:34] <Sweetshark> infinity: yes, I enabled building it in the last upload, but it turned out it would require MIRs we cannot fullfill. So I am not building it anymore, and drop the dep in the metapackage.
[12:34] <infinity> Sweetshark: And I should clean the old NBS libreoffice-report-builder-bin binaries from the archive, so this stops looking like an arm-specific issue.
[12:39] <TLE> pitti: I was wondering what the status is of the natty lang pack export
[12:40] <infinity> Sweetshark: Alright, the stale binaries are removed.  When do we see the upload with the fixed meta deps? :P
[12:40] <Sweetshark> infinity: source package is building
[12:56] <Sweetshark> infinity, pitti: libreoffice_3.5.0-1ubuntu4 in /home/bjoern on chinstrap
[12:56] <infinity> Sweetshark: Poking it with a stick.
[12:56] <Sweetshark> infinity: it hisses
[12:57] <Sweetshark> pitti: so only now only the libexttextcat automake1.7 dep remains right?
[13:03]  * infinity watches debdiff cripple his laptop.
[13:03] <infinity> La la la.
[13:04] <pitti> Sweetshark: ah, you dropped the extra build deps?
[13:04] <pitti> infinity: oh, are you sponsoring already?
[13:04] <infinity> pitti: Yeah.
[13:04] <pitti> TLE: sorry, I didn't deal with that yet, too much stuff going on
[13:06] <infinity> pitti: Well, if this command ever returns, I'm reviewing and sponsoring. ;)
[13:06]  * infinity goes to find a coffee and cigarette.
[13:08] <Sweetshark> infinity: argh, that one it buggy still
[13:08] <infinity> Sweetshark: Oh.  Then I'll wait for another. ;)
[13:08] <Sweetshark> (additional comma at the end of the deps)
[13:08] <infinity> Oops.
[13:09] <infinity> Sweetshark: I'll go find that coffee, ping me when the shiny new one's up.
[13:09] <Sweetshark> infinity: well, I removed the last dep in the list :/
[13:23] <TLE> pitti: no problem, let me know when you find the time
[13:24] <doko_> jamespage, maven wants to promote again ...
[13:24]  * jamespage sighs
[13:24] <Daviey> jamespage / doko_ : For 12.10, should we look at allowing maven in main?
[13:25] <doko_> Daviey, if it's maven3, maybe
[13:25] <doko_> jamespage, ahh, scroll up, it's libreoffice reportbuilder
[13:26] <jamespage> doko_, I was just gazing at this - http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[13:27] <doko> jamespage, Sweetshark: and libloader ...
[13:28] <jamespage> doko, Sweetshark: if that is what is pulling it in it might be possible to drop maven by disabling testing in libbtm-java
[13:29] <jamespage> Daviey, we could but the star chart is impressive - http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[13:32] <Daviey> jamespage: happy, happy, joy joy
[13:32] <jamespage> doko, Sweetshark: or demote libehcache-java to Suggests? I'm not familiar with libloader
[13:33] <pitti> it's being handled Sweetshark already has a new version prepped
[13:33] <pitti> (image a comma there)
[13:34] <pitti> argh TGIF -- "imagine"
[13:34]  * jamespage stands down
[13:34] <pitti> jamespage: it's not just the recommends, it's also build deps
[13:34] <pitti> I guess c-m gets a bit confused with so many packages
[13:34] <jamespage> pitti, looks like it - I see
[13:35] <jamespage> pitti, Sweetshark - what fix are you going for?
[13:35] <pitti> Sweetshark | pitti: so only now only the libexttextcat
[13:35] <pitti> jamespage: so I guess he dropped the new build deps again
[13:36] <pitti> LibO has some stripped down internal libraries, I guess he's using those
[13:36] <pitti> in sum they'd probably take much less space like this, too
[13:36] <pitti> libexttextcat can be fixed to use automake instead of -1.7
[14:39] <Sweetshark> infinity, pitti: 3.5.0-1ubuntu4 FIXED on chinstrap.
[14:42] <vanhoof> herton: hi
[14:42] <herton> vanhoof, hi
[14:44] <vanhoof> herton: dont think we're going to get the ack on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/906832 from the original reporter
[14:44] <vanhoof> we (hwe) got involved with that one since it's quite similar to two others (different device ids) in this current SRU
[14:45] <vanhoof> but we don't have that specific chip in house yet to verify on our own
[14:45] <vanhoof> have even emailed the guy directly a few times.
[14:45] <vanhoof> assuming the deadline is COB today?
[14:46] <herton> vanhoof, yes, looks like the guy isn't going to test it. We can wait until monday, since this is verification week.
[14:46] <vanhoof> herton: ack ok
[14:46] <vanhoof> herton: if i hear back in email I'll let you know
[14:47] <vanhoof> herton: and post to the bug :)
[14:47] <herton> vanhoof, ok, thanks
[14:52] <jibel> slangasek, the problem with upgrade test of main seems to be a bad interaction with the way we capture debconf prompts
[14:53] <didrocks> cnd: ping me when you are around, some remarks on xorg-tests package
[14:53] <cnd> didrocks, pong
[14:53] <didrocks> oh, already? :)
[14:53] <jibel> slangasek, I disabled debconf prompt capture, re-ran the test and it seems to proceed with the upgrade. result in 4 hours
[14:53] <didrocks> let's switch to pm to not annoy people :)
[15:29] <jibel> slangasek, it was faster than expected. Now main upgrade failed but for a good reason :)
[15:31] <pitti> Sweetshark: roger, uploading
[15:35] <pitti> Sweetshark: so this is the good one for b1? or does anything else need to be sorted out?
[15:35] <pitti> Sweetshark: it basically reverts to ubuntu2, right?
[15:36] <Sweetshark> pitti: it revert parts, but not all. some MIRs went well, so lets keep them.
[15:36] <pitti> Sweetshark: ah, good
[15:37] <Sweetshark> now, if I am not mistaken we only need to drop the automake1.7 dep in libexttextcat.
[15:37]  * Sweetshark has a source package already.
[15:37] <pitti> yes
[15:37] <pitti> Sweetshark: toss it over? It's a good thing to fix either way
[15:37]  * Sweetshark fuddles it out of the virtualbox
[15:39] <pitti> Sweetshark: ubuntu4 uploaded (CC: infinity)
[15:43] <Sweetshark> pitti: tweaked libexttextcat in on chinstrap
[15:44] <pitti> Sweetshark: can you please upload libexttextcat_3.2.0-1ubuntu1.dsc?
[15:44] <pitti> Sweetshark: (you uploaded libexttextcat_3.2.0-1.dsc)
[15:44] <Sweetshark> pitti: ugh
[15:45] <Sweetshark> pitti: done
[15:46] <pitti> Sweetshark: uploaded; would be nice if you could send this to Debian, too
[16:08] <bkerensa> https://code.launchpad.net/~bkerensa/ubuntu/precise/ubuntu-wallpapers/fix-for-296538/+merge/92592
[16:31] <pitti> bkerensa: ^ lots of conflicts
[16:31] <pitti> bkerensa: also, it needs to be called .png for backwards compat reasons
[16:49] <pitti> barry: how much would you hate me when we switch lsb-release back to py2.7 and drop python3 from the CDs again? we are a bit despearate on size now
[16:50] <pitti> barry: and we only carry it for the tiny lsb-release script
[16:50] <pitti> barry: from next cycle on we'll have bigger images and can keep it, promised
[16:51] <pitti> barry: (already talked to stgraber, doko, ScottK, and skaet)
[16:51] <barry> pitti: i will hate you forever
[16:51] <barry> pitti: kidding :)  do what you have to do
[16:52] <pitti> barry: thanks, taking the bullets *sob*
[16:52] <barry> pitti: i'm very happy with the progress we made, and i'm confident we'll see py2 relegated to universe for 14.04!
[16:53] <pitti> sounds like a plan
[16:53] <pitti> barry: and indeed, lots of new py3 modules in precise, including py3-dbus which was a major blocker indeed
[16:53] <pitti> barry: now we just need launchpadlib
[16:54] <barry> pitti: yep, we'll get there
[16:56] <pitti> Sweetshark: now, that's much better: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[16:56] <Sweetshark> pitti: nifty!
[16:57] <pitti> Sweetshark: promoting textcat now
[16:57] <pitti> Sweetshark: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt has the demotions now, doing them as well
[16:58] <Sweetshark> pitti: although its a bit boring. It invokes the same urge in me as precise did in chrisccoulson (according to the quotes page): "Can I break it?!"
[17:00] <slangasek> jibel: oh, you mean it wasn't doing the upgrade at all? :(
[17:01] <pitti> Riddell: will calligra drop the recommends: lyx? (http://people.canonical.com/~ubuntu-archive/component-mismatches.svg)
[17:01] <pitti> Daviey: ^ on the same page, do you know the status of the keystone MIR?
[17:01] <pitti> this has been there for months
[17:01] <slangasek> jibel: thanks for identifying the problem, though
[17:01] <Riddell> pitti: I don't know, wasn't aware of it, but I expect it can yes
[17:01] <jibel> slangasek, it was doing the upgrade, but not completely
[17:02] <jibel> slangasek, there is a bug in apt or update-manager here any way
[17:02] <Daviey> pitti: yes.. it's blocked
[17:02] <Daviey> pitti: The underlying code is being changed next week
[17:02] <Daviey> (rewrite from scratch)
[17:03] <Daviey> Once that is introduced into the platform, jstrand's team will need to re-do the audi.. sadly.
[17:28] <pitti> Daviey: new nova needs new MIRs: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[17:28] <pitti> Riddell: ^ FYI
[17:29] <pitti> will depwait, so no immediate archive breakage
[17:29]  * pitti waves good bye, have a nice weekend everyone
[17:29] <dholbach> pitti, you too
[17:42] <slangasek> jibel: where did you see that the upgrade was incomplete then?
[17:48] <m_3> cjohnston: hi.. how many django app servers are typically used in a single summit deployment?
[17:49] <cjohnston> m_3: just 1
[17:49] <m_3> cjohnston: gracias!
[17:50] <cjohnston> :-)
[18:40] <chrysn> once again, i'd need some help finding out why my ppa builds don't work:
[18:41] <chrysn> in the chrysn/openscad ppa, i'm trying to build opencsg-1.3.2-2lucid1, for which i've collected some backports in the same repository
[18:41] <chrysn> i've previously made the experience that the builder uses the ppa itself to satisfy build-depends.
[18:43] <chrysn> but now, it complains about missing build dependencies "libglew-dev (>= 1.5.4)" -- but the build dependency says "libglew-dev (>= 1.5.4) | libglew1.6-dev | libglew1.5-dev (>= 1.5.4)", and i provide libglew1.6-dev in the ppa
[18:45] <chrysn> admittedly, libglew-dev is (in that ubuntu version) also a virtual package whose version can't be satisfied, but it shouldn't bee too uncommon to have alternative build-depends whereof the first is virtual
[18:50] <Ampelbein> chrysn: I think the sbuild version LP uses doesn't support resolving alternate dependencies.
[18:50] <arand> chrysn: I'm not sure, but the log seems to indicate that you should not use the metapackage?
[18:51] <micahg> it doesn't support alternatives where the one is versioned
[18:52] <micahg> bug 594916
[18:54] <chrysn> thanks you all. i guess i'll work around it by building an explicitly depending pakcage for the moment
[18:55] <chrysn> arand, the reason i'm using the "metapackage" is that the newest version (1.7) doesn't build a libglew1.7-dev but a generic libglew-dev
[18:57] <adam_g> anyone have any knowledge of the squid -> squid3 transition? are there blueprints from last cycles around, or mailing list discussion anywhere to get some context around the decision?
[19:09] <ansgar> Hi, I was wondering if Ubuntu might want to sync libquvi and cclive from experimental.  It not really usable right now (#874554).
[19:14] <ansgar> For your entertainment this would also include a soname change, but libquvi only has two reverse dependencies (cclive and one other).
[19:15] <micahg> ansgar: I count 3 reverse dependencies in the archive, but feel free to file the request if it's broke (requestsync -e -d experimental), by the way, what's keeping them from being uploaded to unstable?
[19:16] <micahg> it'll still need release team approva
[19:16] <micahg> *approval
[19:16] <ansgar> micahg: Waiting for Debian's release team to ack the upload to unstable.
[19:16] <micahg> ah, ok
[20:31] <maco> >_>   <_<   new vm wants to use nano when i type "dch -i" setting EDITOR=/usr/bin/vim in bashrc and sourcing it didn't change this. where does dch keep its notion that i want nano?
[20:35] <cody-somerville> maco, try running select-editor
[20:35] <maco> ooh didnt know that existed
[20:35] <maco> thanks cody-somerville
[20:35] <maco> my next guess was going to involve ln -s
[20:35] <cody-somerville> maco, dch uses sensible-editor which will look at VISUAL and then EDITOR
[20:36] <maco> cody-somerville: its been a while since ive doen this. whats that thing for making pbuilders real easy, and what package is it in?
[20:38] <cody-somerville> maco, There are a number of different things out there - but the only thing that I know of that is packaged is pbuilder-dist in ubuntu-dev-tools
[20:39] <cody-somerville> maco, I personally just use a .pbuilderc file and environmental variables: http://pastebin.ubuntu.com/855806/
[20:39] <maco> pbuilder-dist is what i was thinking of. thanks!
[20:40] <cody-somerville> maco, You're most welcome :)
[20:41] <cody-somerville> If you have any further questions, don't hesitate to ping me.
[20:43] <slangasek> stgraber: should the values on dns-nameservers lines always be numeric?
[20:43] <slangasek> stgraber: to be precise: does [0-9.]+ cover it as a regexp?
[20:43] <slangasek> (thinking specifically of ipv6 here)
[20:43] <stgraber> slangasek: if you extend your definition of numeric to contain ":" then we should be fine, yes
[20:44] <slangasek> ok
[20:44]  * stgraber is quickly checking on a system using dns-nameservers with ipv6
[20:44] <slangasek> some things like to put ipv6 addresses in brackets, didn't know if this was one
[20:45] <stgraber> slangasek: at least resolv.conf doesn't use brackets but I'll quickly check for resolvconf
[20:45] <slangasek> stgraber: also, I believe we have to remember that a-f are numbers for this purpose? :)
[20:45] <slangasek> does netcfg give us upper or lower case?
[20:46] <stgraber> good questions, it's probably taking them as-is from the RA so I'd say lowercase
[20:46] <slangasek> the RA is text?! :)
[20:48] <beuno> so, switching workspaces is broken, right?
[20:50] <bryceh> beuno, try <super><shift><arrow> ?
[20:50] <stgraber> slangasek: netcfg doesn't deal with RDNSS directly at the moment, it uses rdnssd if around which returns the IP in lowercase
[20:51] <slangasek> stgraber: ok
[20:51] <stgraber> slangasek: I'm checking what's dhclient's behaviour for dhcpv6 now
[20:54] <stgraber> slangasek: actually, netcfg doesn't write these to /etc/network/interfaces, it'll just mark the interface "iface ethX inet6 auto" or "inet6 dhcp"
[20:54] <beuno> bryceh, nope, not working either
[20:54] <slangasek> stgraber: so we only have ipv4 to worry about?
[20:54] <beuno> tried it, it's what the overlay says now
[20:54] <stgraber> slangasek: so the only case where dns-nameservers contains an IPv6 value as a result of an install is when installing with static
[20:54] <stgraber> slangasek: and in static, it's whatever the user entered
[20:55] <slangasek> stgraber: ok, so upper+lower case are valid
[20:55] <stgraber> yep
[20:55] <bryceh> beuno, dunno then.  does the icon switcher thingee work?
[20:56] <beuno> bryceh, it does
[20:56] <beuno> I'll file a bug
[20:56] <beuno> thanks bryceh
[20:56] <slangasek> stgraber: how's this look to you? ;)
[20:57] <slangasek> grep -Eq '^[[:space:]]*(iface[[:space:]]+.*[[:space:]]+inet[[:space:]]+dhcp|dns-nameserver[[:space:]]+[0-9A-Fa-f.:]+[[:space:]]*(#.*)?$)' /etc/network/interfaces
[20:58] <barry> slangasek: can you sanity check something for me?  try to apt-get the oneiric source for kexec-tools and build the source package w/debuild -S.  does it work or fail for you?
[20:58] <stgraber> I think we could extend to cover "inet6 dhcp" too but it's not going to be a common use case ;)
[20:59] <stgraber> it needs to be "dns-nameservers" (plural)
[20:59] <stgraber> and can be dns_nameservers
[20:59] <slangasek> barry: build it on what environment? oneiric, precise?
[21:00] <stgraber> other than these, it looks good (though my brain's regexp parser is far from perfect ;))
[21:00] <slangasek> yeah, I fed it a couple of examples here
[21:00] <slangasek> but of course I missed the variable name misspelling
[21:00] <slangasek> thanks
[21:06] <slangasek> stgraber: resolvconf uploaded, then
[21:06] <slangasek> stgraber: I'll have a look at ifupdown a little bit later
[21:06] <stgraber> slangasek: thanks!
[21:07] <stgraber> slangasek: btw, blog post published, will see how many people complain about it in the comments ;)
[21:09]  * infinity starts trolling stgraber's blog.
[21:10] <slangasek> stgraber: just block everything from quagga_fan_in_calgary
[21:10] <infinity> >:(
[21:10]  * broder resists the urge to make canada jokes
[21:11] <stgraber> slangasek: I'll just add a new static route to my quagga to route quagga_fan_in_calgary to a blackhole ;)
[21:15] <barry> slangasek: i'm just trying to get a source package built :/
[21:15] <slangasek> barry: yes, but which environment are you trying to build it in :)
[21:16] <barry> slangasek: i've tried on precise, but also in an oneiric chroot.  i've tried from apt-get source and from the udd branch, all fail in the same way
[21:17] <infinity> barry: With the build-deps installed?
[21:17] <barry> infinity: doesn't even get that far.  `debian/rules clean` fails because it can't unpatch
[21:17] <slangasek> barry: ok, having a look
[21:17] <infinity> barry: But, I dunno, if you're just patching the pristine source, and thus don't need a clean, cheat and debuild -S -nc :P
[21:17] <infinity> barry: Yes, but unpatch may rely on the build-deps being installed.
[21:17] <barry> infinity: yeah, may have to do that ;)
[21:18] <slangasek> barry: right, 'debian/rules clean' isn't guaranteed to work without the build-depends installed
[21:18] <slangasek> debian/rules:12: /usr/share/dpatch/dpatch.make: No such file or directory
[21:18] <slangasek> make: *** No rule to make target `/usr/share/dpatch/dpatch.make'.  Stop.
[21:18] <slangasek> like so
[21:18]  * infinity nods.
[21:18] <barry> gotcha, okay, thanks
[21:18] <infinity> You could just install dpatch.
[21:18] <infinity> But if you're sure you're doing things cleanly, -nc is fine.
[21:18] <slangasek> in a chroot in a container in a vm in a pocket universe
[21:18] <slangasek> where it won't contaminate anything
[21:18] <barry> i actually thought i had it installed but apparently not ;)
[21:18] <infinity> Just double-check your debdiff after an -nc build to make sure you didn't introduce cruft.
[21:20] <barry> slangasek, infinity actually, no.  on precise i *do* have dpatch installed.  installing build-deps in an oneiric chroot does pull in dpatch, but `dpatch deapply-all` still fails
[21:20] <barry> so i will try -nc, but this seems like a problem with the package
[21:21] <infinity> Or a problem with how you fiddled with patches in your upload?
[21:21] <infinity> After you do that -nc build, dpkg-sourc -x it to a new directory and make sure it builds. :P
[21:21] <barry> infinity: i haven't uploaded anything yet, just apt-get source && debuild -S
[21:21] <infinity> Oh.
[21:22] <infinity> Though it may now be dirty from previous sadness.
[21:22] <infinity> That would be a bug, mind you. :P
[21:22] <infinity> clean making things unclean isn't, sadly, uncommon.
[21:22] <barry> infinity: that's what i was looking for :)
[21:22] <barry> :(
[21:23] <infinity> (That said, we expect build-deps to be installed for all steps, so if it works correctly from a fresh download with build-deps installed, the rest is a wash)
[21:23] <barry> cool, infinity, slangasek thanks for the confirmation
[21:23] <barry> infinity: right, but it doesn't so i'll file a bug
[21:23] <barry> actually, i should check the precise version.  it's not worth an sru
[21:24] <slangasek> but you're doing an SRU anyway? :)
[21:24] <slangasek> so it might be worth fixing the build system along the way
[21:25] <barry> slangasek: think so?  i thought it was generally frowned on to mishmash fixes.  but if not, and it's an easy-ish fix, it would be wroth it
[21:25] <barry> worth it even
[21:26] <barry> slangasek, infinity yep, precise is happy
[21:26] <infinity> I'm curious how the original source package was built if it is, indeed, broken.
[21:26] <barry> infinity: my question too!
[21:26] <micahg> well, it's using dpatch, that's strike 1 :)
[21:26] <barry> yes :)
[21:26] <slangasek> it's frowned upon to include low-priority fixes in an SRU; but fixing things like "the build system is fubar" warrant coming along for the ride
[21:27] <infinity> Indeed.
[21:27] <infinity> Let me double-check this.
[21:27] <barry> fair enough, yep, and thanks
[21:34] <infinity> barry: I hate to be the bearer of confusing news for you, but in an oneiric chroot, with build-deps installed (all build-deps, mind you), a freshly-unpacked kexec-tools source builds itself just fine.
[21:35] <infinity> Even several times in a row.
[21:35] <barry> infinity: dang, but okay that's very interesting and makes me more optimistic.  thanks for the confirmation
[21:36] <infinity> barry: I suspect you're working in a dirty source tree from previous no-build-deps-installed clean failures, or sometihng.
[21:36] <infinity> barry: So, a fresh download, a fresh unpack, and making sure ALL the build-deps are installed before you build your source should do it.
[21:37] <barry> infinity: trying that...
[21:37] <infinity> (The kicker being that it not only needs dpatch to build the source, but also autoconf/automake)
[21:37] <infinity> But just check with dpkg-checkbuilddeps before you build. :P
[21:51] <barry> infinity: the combination of building in the distroseries chroot + installing build-deps before debuild -S seems to solve the problem
[21:54] <infinity> barry: Good deal.
[23:10] <slangasek> adam_g, zul: is this new upstream version of glance needed/wanted/expected for beta-1?  (currently sitting in the freeze queue)
[23:11] <slangasek> and should it have a FFe for the new upstream version?
[23:26] <adam_g> slangasek: hmm, im not sure? the other parts of openstack were uploaded at the same time
[23:27] <adam_g> slangasek: that new upload does have a new dependency that is not in main, though
[23:27] <slangasek> adam_g: well, that new dep is already on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt due to nova
[23:27] <slangasek> so that wouldn't seem to be a blocker IMHO
[23:39] <adam_g> slangasek: hm then im not sure, the new version is expected to be uploaded with the rest of openstack every week, not sure why it'd need a FFE in this case
[23:40] <slangasek> adam_g: n/m, there's a standing FFe that I wasn't aware of
[23:40] <slangasek> so that's good to go in
[23:40] <slangasek> but someone probably needs to fix those new deps on universe
[23:43] <adam_g> slangasek: what is the policy on new MIRs for such things this late?
[23:44] <slangasek> adam_g: MIRs aren't subject to the freeze
[23:44] <slangasek> it's the changes to the packages already in main that are usually dubious :)
[23:44] <slangasek> (in this case it's fine, and someone needs to follow through on the MIR)
[23:45] <adam_g> slangasek: gotcha


[00:08] <asac> fta: 274187
[00:08] <asac> fta: i have to rework this tomorrow - before subscribing motu folks
[00:09] <asac> fta: feel free to supplement the bug description ... i am not really awake right now ;)
[00:11] <fta> ok, thanks
[00:11] <fta> i'm on the new cairo right now. it's badly broken.
[00:14] <asac> brave ;)
[00:18] <asac> sigh ... so nss will not make the beta freeze :/
[00:19] <fta> why?
[00:19] <asac> because the SONAME is "empty"
[00:19] <asac> and dpkg-gensymbol just ignores everything then
[00:19] <asac> (though the binary bits appear to work fine)
[00:19] <fta> that's what i meant ealier today
[00:19] <asac> fta: right
[00:20] <fta> but i got distracted
[00:20] <asac> fta: well. i think we have to reintroduce half of the soname patch again
[00:20] <asac> but just dont use the suffix
[00:20] <asac> fta: or fix dpkg-gensymbols ... or just maintain the symbol files manually ;)
[00:22] <asac> 19:39 < asac> fta: if you look at rev 38 on nspr.dev do you understand why expression like: DSO_LDOPTS='-shared -Wl,-soname  -Wl,$(notdir $@)' now give an empty SONAME
[00:23] <fta> i'm a bit out of context right now.
[00:23] <fta> fighting with git and those f*g revno
[00:24] <asac> fta: either $(notdir $@) == empty OR $(notdir $@) == libnss3.so, but ld just removes it implicitly from the .so headers
[00:24] <asac> both sounds strange
[00:27] <asac> fta:
[00:27] <asac> $ gcc -olibtest.so -shared -fPIC -Wl,-soname -Wl,libtest.so t.o
[00:27] <asac> asac@hector:/tmp/c$ objdump -x libtest.so | grep SONAME SONAME               libtest.so
[00:27] <asac> so ... apparently its just empty in make
[00:27] <asac> e.g. $(notdir $@) is nothing
[00:27] <asac> i have the feeling that its a problem with how we build
[00:28] <asac> most likely upstream build has a SONAME, but libnss3.so
[00:29] <asac> fta: $ objdump -x libnss3.so | grep SON SONAME               libnss3.so
[00:29] <asac> fta: oh. only nspr is broken
[00:29] <asac> that explains a lot
[00:30] <asac> so in principal all works :)
[00:30] <asac> yeah upstream has libnspr4.so
[00:30] <asac> as SONAME of libnspr4.so
[00:38] <asac> ok i think i have it ;)
[00:39] <asac> good ;)
[00:44] <asac> fta: nspr fixed.
[00:44] <asac> rev 40
[00:44] <fta> good
[00:45] <fta> i'll cairo tomorrow, my brain is working backward
[00:46] <asac> fta: ok. could you push nspr and nss to your ppa?
[00:47] <asac> fta: but cool phrase: "I'll cairo tomor..."
[00:52] <asac> ok nspr fix works quite nicely from the auto-dependency perspective
[00:52] <asac> soname looks good
[00:52] <asac> ffox still starts ;)
[00:52] <asac> which is actually the miracle of the week imo ;)
[01:06] <fta> FIREFOX_3_0_3_BUILD1
[01:07] <XioNoX> there are still people here ?
[01:09] <asac> fta: yea
[01:10] <asac> fta: intrepid is fixed already
[01:10] <asac> hardy will see the sun tomorrow again i hope
[01:11] <asac> XioNoX: yep ... tonight or tomorrow the archive will be shut down :/
[01:11] <XioNoX> asac, I just come back from a party
[01:11] <XioNoX> and I still have the ubufox thing
[01:11] <asac> XioNoX: i was drinking beer for 3hours two :)
[01:12] <XioNoX> asac, ok
[01:12] <asac> fta: ok nspr and nss pushed to mt
[01:12] <asac> hopefully i will be long enough to test the outcome :/
[01:12] <XioNoX> asac, I still don't understand why i don't see the menu idem with flash alternative
[01:12] <asac> XioNoX: yeah. thats a mistery
[01:13] <asac> the only explanation i would usually have is a) you have clutter in your profile or b) you have the wrong version ;)
[01:13] <asac> XioNoX: i mean ... if the statusbar thing might not apear fine, but if the menu entry is not there it means that the chrome isnt used
[01:13] <asac> XioNoX: only thing might be tranlsations.
[01:13] <XioNoX> yeah, but the notification bar appear when I update firefox
[01:13] <asac> XioNoX: try en_US
[01:14] <XioNoX> yes, right
[01:14] <asac> XioNoX: start LANG=en_US firefox
[01:14] <asac> we had issues with restart notification because of missing translations
[01:14] <asac> maybe the alternative has the same problem
[01:14] <XioNoX> asac, it works
[01:14] <asac> yeah ;)
[01:14] <asac> good
[01:14] <asac> well not so good
[01:15] <XioNoX> Will it be translated ?
[01:15] <asac> i should have properly reviewed everything when fixing the same bug for restart thing a few hours ago
[01:15] <asac> but well
[01:15] <asac> XioNoX: hopefully we will get that sorted. yes
[01:16] <XioNoX> asac, It is magic, I can switch from adobe to gnash in a clic !
[01:16] <asac> XioNoX: yeah
[01:16] <XioNoX> and thanks to add my name in the about of ubufox :)
[01:16] <asac> did i do that? welcome
[01:17] <asac> we still need to fix the plugins to properly install their files in the ubufox plugins directory ;)
[01:17] <asac> but that has to happen after beta
[01:17] <asac> one of the big things outstanding :/
[01:17] <XioNoX> asac, the statusbar icon appear on all pages
[01:17] <asac> XioNoX: on all ... i think it displays on the initial tab if there is any other tab with a plugin
[01:17] <asac> but i cant confirm that its on every tab when i switch
[01:18] <XioNoX> yes
[01:18] <asac> e.g. if its on the first tab and i switch back and forth it goes away (given that the first tab doesnt have flash)
[01:18] <XioNoX> I've went on youtube
[01:18] <XioNoX> and then come back on google homepage
[01:18] <XioNoX> and I still have the icon
[01:19] <asac> XioNoX: indeed
[01:19] <XioNoX> and about flash, should I install libflashsuport in intrepid or not ?
[01:19] <asac> didnt notice that
[01:19] <asac> most likely we dont remove the "attribute" from the browser object
[01:19] <asac> XioNoX: no
[01:19] <asac> libflashsupport is dead
[01:20] <asac> whoever uses that is on its own
[01:20] <XioNoX> because there are a "intrepid" version of it in repos
[01:21] <asac> yeah
[01:21] <asac> non of my business
[01:21] <XioNoX> ok
[01:21] <XioNoX> I need to go to sleep... School at 8 :(
[01:22] <XioNoX> see you ;)
[01:23] <XioNoX> good night
[08:17] <rzr> hi
[08:17] <rzr> asac: about tuxguitar you bugged it must depends on abrowser
[08:17] <rzr> but swt needs mozilla libs
[08:18] <rzr> maybe abrowser is provided only by mozilla browsers
[08:18] <rzr> i'll check later
[09:45] <gnomefreak> do i really have to send 10 emails to find out problem with mailing list :(
[09:50] <gnomefreak> anyone use claws-mail?
[10:33] <asac> rZr: huh?
[11:02] <gnomefreak> asac: fabrice_sp|away what is icedove-dispmua?
[11:03] <asac> no idea ;)
[11:07] <gnomefreak> you really dont?
[11:08] <gnomefreak> i would say its tbird without Moz branding
[11:08] <gnomefreak> but not sure what the dispmua is
[11:12] <gnomefreak> its an icon?
[11:24] <XioNoX> hi!
[11:42] <XioNoX> asac, there are plans to remove the bulb systray icon witch say that we have to restart firefox?
[11:43] <asac> XioNoX: not sure
[11:43] <asac> XioNoX: if you dont run ubufox it might still be useful
[11:44] <XioNoX> or at least don't show if ubufox is installed
[11:44] <fta2> it is buggy (at least without ubufox)
[11:44] <asac> fta2: it is yes. thats why we did the ubufox solution in the first place
[11:45] <fta2> it sometimes pops up even when ff is not running
[11:45] <XioNoX> because when we update firefox, we have the notification bar, and the bulb. And when we restart firefox, the bulb is still here
[11:45] <asac> XioNoX: not sure what we can do about that
[11:45] <asac> ;)
[11:45] <asac> XioNoX: maybe fix the update-notifier
[11:45] <XioNoX> and we have to clic it to show the dialog and close it...
[11:45] <asac> it should detect that ffox has a "new" process id
[11:45] <fta2> a graceful restart would be nice to have
[11:45] <asac> and remove the notification i think
[11:45] <asac> fta2: what do you mean?
[11:46] <asac> fta2: more than the ubufox solution?
[11:46] <fta2> xul is very bad with upgrades, most probably due to the .jar files leading to all sorts of weirdnesses
[11:47] <asac> fta2: yes. but thats the ubufox solution tries to cover: http://people.ubuntu.com/~asac/screenshots/ubufox_restart_notification_intrepid.png
[11:47] <fta2> ubufox is evil for me, it keeps changing my prefs so i dropped it
[11:48] <asac> fta2: it shouldnt do that
[11:48] <asac> fta2: it has certain default preferences that might be different, but it shouldnt reset anything
[11:48] <asac> (at least not with the fix we have)
[11:48] <fta2> it does each time you upgrade it
[11:49] <asac> fta2: no
[11:49] <asac> thats a long long time ago
[11:49] <asac> thats a bug in ffox
[11:49] <asac> if it still does that its a bug. but i cannot reproduce that anymore
[11:49] <asac> (but a bug in firefox)
[11:49] <fta2> why is that bar in ubufox and not in ff ?
[11:50] <asac> fta2: why? because its a ubuntu only solution
[11:50] <asac> fta2: and we need to reach consent on what to do among distros first
[11:50] <fta2> most of our patches are ubuntu only
[11:51] <fta2> and that bar could be posted upstream
[11:51] <asac> fta2: we dont have any features in firefox patches
[11:51] <asac> (except the know your rights thing - which is an exception)
[11:51] <fta2> well, in xul, all the plugin stuff
[11:52] <asac> fta2: upstream wont accept that because they have their own upgrade mechanism. they will only accept it when we find a way to do it in a distro independent fashion
[11:52] <asac> fta2: plugin stuff?
[11:52] <fta2> what about a pref or a configure flag?
[11:52] <asac> fta2: you mean that GRE_DIR is considered?
[11:53] <fta2> it's one of them, yes
[11:53] <asac> fta2: thats not a feature visible in the UI. howveer, thats something i would like to see upstream, but benjamin disagreed
[11:53] <XioNoX> benjamin ?
[11:54] <asac> fta2: the general policy is: dont add features. if we really need that feature put it in ubufox ... if that proves to be useful, try to get it properly upstream
[11:54] <asac> fta2: so the user experience of a firefox install in ubuntu should be as close to upstream as possible (without breaking packaging policies et al)
[11:54] <fta2> sysprefs, lockpref, gre extension plugins, sysplugins, that's a lot of ubuntu only changes, no?
[11:55] <asac> fta2: thats all not feature. thats all just system install and xul split related
[11:55] <asac> fta2: imo our only patches are still xul split related. everything else should definitly go upstream. and even the xul split should
[11:56] <asac> fta2: ok lets review the patches now :)
[11:57] <asac> fta2: http://paste.ubuntu.com/50439/
[11:57] <asac> thats ffox
[11:57] <asac> awesome_browser_branding_install.patch
[11:57] <asac> -> not upstream
[11:57] <asac> browser_branding.patch
[11:57] <asac> -> not upstream
[11:57] <asac> bz368428_attachment_308130.patch
[11:57] <asac> bz386904_config_rules_install_dist_files.patch
[11:58] <asac> bz412610_att335369_realpath_overflow.patch
[11:58] <asac> bz421977_att334578.patch
[11:58] <asac> bz436133_att322801.patch
[11:58] <asac>  => all those need to land upstream. i think we should bug reed to help us here
[11:58] <asac> bzXXX_reload_new_plugins.patch
[11:58] <asac> => we should forward that
[11:58] <asac> dont_depend_on_nspr_sources.patch
[11:58] <asac>  installer_shouldnt_copy_xulrunner.patch
[11:58] <asac>  installer_use_stdout_for_missing_files.patch
[11:58] <asac> => ubuntu only i guess
[11:59] <asac> lp185622_system_path_default_browser.patch
[11:59] <asac> => ubuntu only ... not sure how a proper upstream solution would look like
[11:59] <asac> lp269656_know_your_rights.patch
[11:59] <asac> => will eventually end up upstream
[11:59] <asac> (we are working with mozilla on that)
[11:59] <asac> nspr_flags_by_pkg_config_hack.patch
[11:59] <asac> => again xul split stuff i think
[11:59] <asac> ubuntu_no_app_updates.patch
[12:00] <asac> => not suitable for upstream (maybe with a configure flag we could make that go upstream)
[12:00] <asac> ubuntu_codes_amazon.patch
[12:00] <asac> => ubuntu only
[12:00] <asac> fta2: ok in xul the situation is better
[12:00] <asac> fta2: all those that have bzXXX should really go upstream ... my fault for sure
[12:01] <asac> fta2: http://paste.ubuntu.com/50442/ those are the only patches not marked as "upstream-suitable"
[12:01] <asac> maybe the jemalloc patch
[12:02] <asac> i dont see how the rest could be done in upstream fashion
[12:02] <asac> XioNoX: bsmedgberg
[12:03] <asac> err
[12:03] <asac> bsmedberg ;)
[12:03] <asac> == Benjamin
[12:03] <asac> fta2: ok. lets talk about the restart notification bar  - as i think thats probably one of the things that could be done proper
[12:03] <asac> for distro builds across the line
[12:04] <asac> fta2: to do it properly ffox would need to export dbus server and get notifications fromt he distro upgrade tool that an upgrade happened
[12:10] <asac> XioNoX: ok i am talking to mvo to see if we can make that bubble disappear when firefox was restarted
[12:39] <fta2> dbus is supported in xul now, there are some bugs to make use of it like for addons notifications
[12:43] <XioNoX> back
[12:43] <XioNoX> asac, ok
[12:46] <asac> fta2: dbus is used client wise not server side
[12:46] <asac> fta2: or has server supporte landed now too?
[12:50] <fta2> why would need the server?
[13:11] <asac> fta2: to receive update events?
[13:12] <asac> fta2: e.g. restart notifications need to get pushed to ffox
[13:12] <asac> fta2: did you manage to test nspr/nss?
[13:12] <asac> fta2: i uploaded both to mt +archive
[14:04] <XioNoX> asac, how works translations for ubufox ?
[14:22] <asac> XioNoX: the idea is to include the lp-export .mk thing
[14:22] <asac> in rules
[14:22] <asac> so it gets imported into launchpad
[14:22] <asac> and from there gets translated
[14:22] <asac> jtv: do we need to enable a package like ubufox before we can translate it in distro?
[14:22] <asac> jtv: hi ;)
[14:23] <jtv> asac: hi!
[14:23] <jtv> asac: by "enable" you mean turn on Translations?  For packages, that is done in the distro.
[14:23] <asac> jtv: what does that mean in my case?
[14:23] <asac> jtv: or does it just mean that you dont know what it means in my case ;)
[14:25] <XioNoX> asac, will it be in roseta before intrepid ?
[14:26] <asac> XioNoX: thats what i am currently trying to figure out
[14:27] <fta2> asac, what do you expect to happen from 274187 ?
[14:27] <XioNoX> ok
[14:28] <XioNoX> but how it was working before ?
[14:29] <asac> XioNoX: before it was saivann who sent out a call for translations
[14:30] <asac> and aggregated those to a branch i could merge in before release
[14:30] <jtv> asac: projects have an option "translate in Launchpad," which enables the Translations application.  That's what you mean by "enable" here, no?
[14:30] <XioNoX> ok, not the easier way
[14:30] <asac> jtv: no. what i mean is that when i emable the translation export in the package, launchpad will automatically (i think) upload the .xpi to launchpad during build.
[14:30] <XioNoX> asac, https://translations.launchpad.net/ubufox
[14:31] <asac> jtv: i was wondering if something needs to be flipped on on launchpad side to prevent that that upload doesnt get dropped/rejected
[14:31] <asac> XioNoX: right
[14:31] <asac> XioNoX: thats the way to do translations in the project itself
[14:31] <XioNoX> ok
[14:31] <asac> XioNoX: the other way is to translate it in the distro
[14:31] <asac> XioNoX: but maybe we shoudl really enable it here
[14:32] <XioNoX> it seam easier to translate for the project
[14:32] <asac> XioNoX: well. but most likely not as many translations we would get
[14:32] <asac> jtv: the translations of a project wont show up when people work on distro translations right?
[14:33] <asac> XioNoX: i guess when we put ubufox in the distro translation we might get up to 40 translations
[14:33] <asac> jtv: so projects like https://translations.edge.launchpad.net/ubufox would need their own translation community?
[14:34] <jtv> asac: enable translation export?  I'm not sure what that means.
[14:34] <jtv> asac: (getting some lag here)
[14:34] <asac> jtv: doesnt matter for your side.
[14:34] <asac> jtv: what matters is that you get the templates and translations uploaded at the end of the build
[14:34] <jtv> asac: right, the "project" and the "package" live separate lives (although translations for the one's individual messages will automatically show up as suggestions for the other)
[14:35] <asac> jtv: do you understand my question?
[14:35] <asac> jtv: my question is: "if a new package is introduced in ubuntu, do you need to do something on launchpad side before that shows up in distro translations"?
[14:36] <asac> maybe just too stupid of a question ;)
[14:36] <asac> jtv: i just thought you might need to enable "xpi"-mode manually for certain packages ;)
[14:37] <asac> but if thats not the case then we will see :)
[14:37] <jtv> asac: no, just be sure to upload the template in XPI format.  :-)
[14:37] <asac> jtv: ok.
[14:37] <asac> jtv: wasnt sure about the _first_ upload case
[14:37] <jtv> asac: the package should just show up with an invitation to upload a template.
[14:37] <jtv> asac: tbh I've never created a package.  Try it on staging!  :)
[14:38] <asac> jtv: nevermind. i will see what happens ;)
[14:38] <asac> jtv: i will setup the template for the project though ... will ping you when that needs to be approved
[14:38] <asac> jtv: does the import understand multiple languages in one  xpi now?
[14:38] <jtv> asac: no, still one language per XPI.
[14:38] <asac> or do i need to split them to import inital one
[14:39] <asac> ok
[14:39] <jtv> asac: we do need to approve the XPI, yes.  You may want to talk to Arne about that as well.
[14:39] <asac> jtv: why arne?
[14:40] <jtv> asac: because he's an Ubuntu guy.  I just develop the app.  :-)
[15:00] <asac> jtv: well. but arne certainly doesnt know most details ;) ... yeah the import he might know
[15:01] <jtv> asac: he can approve an Ubuntu import, and it's good for him to be aware of what goes on.
[17:20] <fta2> asac, you touched nspr.dev ? why not nspr.head ?
[17:34] <asac> fta2: i think i pointed that out yesterday
[17:35] <asac> nspr.head was quite outdated so i wasnt sure and wanted to first discuss what we want to do with nspr.head
[17:35] <asac> fta2: but well. we can merge to .head after this release
[17:36] <fta2> in think both were equally outdated, but a merge is good enough.
[17:42] <asac> fta2: no ... .dev was ahead ... it had at least two releases on top of .head
[17:42] <asac> i think i did the last releases on .dev because it wasnt clear to me if nspr.head would be used to track the real trunk
[17:43] <asac> but since we appear to have settled on not doing that i think its ok to go back to the standard scheme
[17:44] <fta2> dev was diverged for me, i had to overwrite it
[17:45] <asac> fta: he?
[17:45] <asac> overwrite what? .head?
[17:46] <asac> thats fine.
[18:44] <fta> asac, no .dev was diverged
[18:45] <fta> (asynchronous chat is painful)
[18:49] <asac> fta: ok your local copy
[18:49] <asac> fta: yeah sorry
[18:49] <asac> i forgot that you already pulled from it
[18:49] <asac> maybe i uncommitted the topmost thing
[20:20] <fta> Error: [Exception... "Component is not available"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: file:///usr/lib/firefox-3.1b1pre/components/nsSessionStore.js :: sss_saveState :: line 1987"  data: no]
[20:20] <fta> Source File: file:///usr/lib/firefox-3.1b1pre/components/nsSessionStore.js
[20:20] <fta> Line: 1987
[20:21] <asac> fta: did you post that already at some point? reads familiar
[20:21] <fta> http://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/src/nsSessionStore.js#1987
[20:22] <fta> no sure, but it's still there
[20:22] <asac>  var stateString = Cc["@mozilla.org/supports-string;1"].
[20:22] <asac> that appears to not exist
[20:24] <wikz> asac: we have flags to use system telepathy,dbus and libpurple libs.Just FYI :)
[20:24] <wikz> sorry to get in between
[20:25] <asac> wikz: you dont get in between anything here ;)
[20:25] <asac> wikz: good (system libs)
[20:27] <fta> asac, should we wait for something for 274187? maybe subscribe someone else otherwise i doubt anything will happen
[20:29] <wikz> asac: Also we have no trademarks or EULA .
[20:29] <fta> lol
[20:29] <wikz> no forky-porky business
[20:35] <wikz> fta: I changed everything to spicebird now but the shortcut at /usr/bin/spicebird still symlinks to /usr/lib/spicebird-0.7/spicebird instead of  /usr/lib/spicebird/spicebird .why ?
[20:35] <fta> this is correct
[20:35] <fta> this is the mozilla way
[20:35] <wikz> so I'm wrong where ?
[20:35] <fta> nope
[20:36] <fta> /usr/lib/spicebird-0.7/spicebird is correct according to mozilla build system
[20:36] <fta> we use the same in ubuntu, but debian doesn't
[20:37] <wikz> ok
[20:37] <wikz> so my files in the debian dir should be spicebird.desktop or spicebird-0.7.desktop ?
[20:39] <fta> spicebird.desktop
[20:39] <fta> i used the -3.0 for tb because we also have 2.0
[20:40] <wikz> but the thunderbird shortcut points to ../lib/thunderbird/thunderbird ?
[20:40] <wikz> ok
[20:40] <wikz> so how do I rectify the problem
[20:40] <fta> tb2 is from debian
[20:40] <wikz> Ohh k
[20:40] <fta> tb3 isn't
[20:40] <wikz> yeah
[20:49] <fta> mozilla bug 366509
[21:02] <fta> Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIINIParserFactory.createINIParser]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///usr/lib/xulrunner-1.9.1b1pre/components/nsUpdateService.js :: getLocale :: line 508"  data: no]
[21:02] <fta> Source File: file:///usr/lib/xulrunner-1.9.1b1pre/components/nsUpdateService.js
[21:02] <fta> Line: 508
[21:28] <fta> asac, i'm now using the new nspr/nss
[21:28] <fta> pushed to my ppa too
[21:29] <asac> fta: great
[21:29] <asac> fta: i am not sure about the 3.1 bug. are there other points that speak for 3.1?
[21:29] <asac> if not we can subscribe motu-release now
[21:30] <asac> otherwise we should rephrase the description and extend it with better reasons
[21:30] <fta> i posted 3
[21:32] <asac> wikz: the .desktop file should be unversioned
[21:32] <asac> oops
[21:32] <asac> i scrolled back ... forgot and answered an old question ;)
[21:33] <asac> fta: ok ... subscribing motu-release
[21:34] <asac> fta: let the lottery begin ;)
[21:34] <fta> k
[23:27] <armin76> asac: Mozilla/5.0 (X11; U; Linux armv4l; en-US; rv:<IP_ADDRESS>) Gecko/2008092518 Gentoo Firefox/3.0.2 <- bumb!
[23:28] <fta> armin76, firefox-3.0 | 3.0.3+build1+nobinonly-0ubuntu1 | http://archive.ubuntu.com intrepid/main Packages
[23:28] <fta> we win
[23:29] <armin76> fta: well, i was talking about arm :P
[23:29] <fta> there's no ubuntu arm


[10:04] <Guest60> hi guys , does anybody know  how  maas's  tftp  worked?
[10:04] <Guest60> 有人知道maas的tftp是如何工作的吗
[10:06] <parlos> Guest60, what do you mean?
[10:09] <parlos> MAAS dhcpd catches any requests, and if a PXE boot, sends a response that may include a tftp. The tftp is a standard tftp. AFAIK just used for the PXE boot, most other communications/ is via http/s.


[01:01] <RAOF> So, people have been talking about wlcs again in #_oftc_#wayland:matrix.org, and Daniel Stone brought up a [licensing point](https://matrix.to/#/!SMVhYgTjRgVBkaCWjA:matrix.org/$FV8Xz7zxYEXF_Y8rGf13hY9rsNTH4hArDQJB8mdqjaw?via=matrix.org&via=gnome.org&via=kde.org) I had not otherwise considered (consultancy being paid to implement a specific extension).
[02:35] <RAOF> Boo! We need a bunch more wlcs work before a test for #2621 can be usefully written. :(
[05:09] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2621](https://github.com/MirServer/mir/pull/2621): Bind shm textures when we create the buffers
[05:09] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] closed [issue #2620](https://github.com/MirServer/mir/issues/2620): Latest swaybg (on 22.10) doesn't paint on Mir
[07:38] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq opened [pull request #2641](https://github.com/MirServer/mir/pull/2641): Revert "Merge #2622"... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/a3a14fc3f21efbeec1667c0db77f1c18ac3e1847>)
[07:54] <Saviq> If this is another GCC-12 irk, this isn't funny anymore
[07:58] <alan_g[m]> It affects 20.04 as well?
[08:00] <Saviq> Yeah it does. So not a 12 bug, and the fix is likely just:... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/721891eafc10fa1633f8a7cb594915536403e370>)
[08:00] <Saviq> Here:
[08:00] <Saviq> https://github.com/MirServer/mir/pull/2622/files#diff-f810b494f93934426a29e31ec7d1a41c50c20979123b4c37b933cfc6462d24a9R818
[08:01] <Saviq> Hmm or not
[08:02] <Saviq> `timestamp` is used below, but indeed never initialized
[08:02] <alan_g[m]> We need better reproduction of the PPA build environments before uploading
[08:02] <alan_g[m]> Or even merging
[08:03] <Saviq> That's https://github.com/MirServer/mir/pull/2530
[08:03] <Saviq> Let me rebase on that to confirm it would catch
[08:04] <Saviq> *rebase that on main
[08:30] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2641](https://github.com/MirServer/mir/pull/2641): Revert "Merge #2622"
[09:05] <Saviq> So yeah, #2530 did fail in the same way the PPA did. If only I could get ccache to work there…
[09:27] <alan_g[m]> That would be nice
[10:09] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2633](https://github.com/MirServer/mir/pull/2633): Add quirks for false-positive compiler warnings
[10:17] <Saviq> OK so that should mean a 100% working PPA build. I think.
[11:04] <alan_g[m]> 🎆 I have my background back on 22.10+ppa:mir-team/dev+Miriway
[12:23] <Saviq> Hmm mine's gone again…
[12:25] <Saviq> Back with `/dev`, my local build must've been messing with it
[12:36] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq closed [issue #2639](https://github.com/MirServer/mir/issues/2639): Shutdown crash when OSK is running
[15:36] <Saviq> OK this is looking promising
[15:36] <Saviq> `cache hit rate                     20.47 %`
[15:37] <Saviq> Now I need to work out how to fix precompiled headers with ccache in the mix
[15:37] <Saviq> But that's a tomorrow problem. See you all o/
[16:17] <alan_g[m]> I would guess a good cache hit rate is going to help more than precompiled headers
[16:30] <Saviq> Right, but we want PCH to reproduce PPA builds
[16:31] <Saviq> It's only clang that complained
[17:25] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww opened [pull request #2642](https://github.com/MirServer/mir/pull/2642): Verify serials again
[17:25] -GitHub[m]:#mir-server-
[17:25] -GitHub[m]:#mir-server- > This reverts commit 71a40e7, reversing changes made to 387705a. I fixed the obvious uninitialized use in xwayland_surface.cpp that seemed to cause the PPA failure. Not sure why neither local builds nor CI picked up on that but PPA did.
[17:46] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww opened [issue #2643](https://github.com/MirServer/mir/issues/2643): Cursor only updates once per enter on XWayland
[17:46] -GitHub[m]:#mir-server-
[17:46] -GitHub[m]:#mir-server- > When the cursor enters an X11 window it is correctly set. After that as it moves around the window the cursor is not updated until it leaves and re-enters. I suspect this is to do with #2617, but I need to investigate.
[23:57] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww opened [pull request #2644](https://github.com/MirServer/mir/pull/2644): Improve Client class lifetime management
[23:57] -GitHub[m]:#mir-server-
[23:57] -GitHub[m]:#mir-server- > Libwayland notifies us that clients are destroyed before it cleans up all of the client's resources. The `wl_client` isn't freed until that is done. Previously, our WlClient class being destroyed before the resources, and logic was needed to prevent using using it after. This Makes `Client` an interface in `mir/wayland` and had `Resource` hold a shared pointer to it. This way the client isn't destroyed until it's last resource is. It also
[23:57] -GitHub[m]:#mir-server- makes the client class more readily available.


[13:37] <mup> Bug #1573033 opened: [2.0 beta 3] api output is not consistent <MAAS:New> <https://launchpad.net/bugs/1573033>
[13:38] <mup> Bug #1573035 opened: [2.0 beta 3] list-boot-images should report 'status' in lowercase <MAAS:New> <https://launchpad.net/bugs/1573035>
[14:02] <mup> Bug #1573046 opened: 14.04 images not available for commissioning as distrio-info --lts now reports xenial <kanban-cross-team> <landscape> <MAAS:Confirmed> <https://launchpad.net/bugs/1573046>
[14:32] <mup> Bug #1573072 opened: Cannot commission KVM node with 16.04 (xenial) <MAAS:Triaged> <https://launchpad.net/bugs/1573072>
[14:38] <mup> Bug #1573072 changed: Cannot commission KVM node with 16.04 (xenial) <MAAS:Triaged> <https://launchpad.net/bugs/1573072>
[14:47] <mup> Bug #1573072 opened: Support Xenial as commissioning image in 1.9 <MAAS:Triaged> <https://launchpad.net/bugs/1573072>
[17:03] <jalt> Hi, I'm playing with MAAS (fresh 16.04 install, amd64) which shows Version 2.0.0 (beta3+bzr4941), yet is affected by https://bugs.launchpad.net/maas/+bug/1467584, which shows as fixed. When I tried to switch to the (stable) ppa, I noticed that it only has version 1.9.  Any hints/suggestions?
[17:08] <jalt> For context, I need the CLI to change the DHCP pool range, because from the GUI I assigned it to a range that was too wide (your docs were a bit misleading in that they only mention the static/sticky IPs too late, way after the initial pool is set), and there is no way (that I could find) to change it from the GUI.
[20:18] <mup> Bug #1573219 opened: Deleting user in UI leads to 500 <landscape> <MAAS:New> <https://launchpad.net/bugs/1573219>
[20:31] <jalt> Is it possible to have WoL show up as a power type for a node? I.e. without proper IPMI or other BMC?
[22:18] <mup> Bug #1573264 opened: enlistment fails: /tmp/sh.UZ7qJT/bin/maas-enlist: archdetect: not found <arm64> <MAAS:New> <https://launchpad.net/bugs/1573264>
[23:39] <mup> Bug #1573301 opened: list-boot-images fails when rack has no boot images <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1573301>
[23:39] <mup> Bug #1573304 opened: maas-provision causing connection refused with TFTP back-end <MAAS:New> <https://launchpad.net/bugs/1573304>


[12:24] <mamarley> santa_: It looks like the kio 5.113.0 in noble-proposed is causing Dolphin to always crash on start with "*** buffer overflow detected ***: terminated".  That didn't happen for the same version of the package in staging-frameworks.
[12:28] <mamarley> It looks like it might only occur when browsing to a directory with a symlink, but my home directory has several of those, which results in crashing on start.
[12:52] <mamarley> It looks like the toolchain might have started setting "-D_FORTIFY_SOURCE=2" by default.  I bet that has something to do with it.
[13:03] <RikMills> that would be a change in dpkg
[13:04] <RikMills> https://launchpad.net/ubuntu/+source/dpkg/1.22.1ubuntu4
[13:04] <RikMills> I think
[13:09] <mamarley> Ah, OK.  I just guessed it was in the toolchain, sorry.  I noticed it because a package I build started FTBFSing with an error about _FORTIFY_SOURCE being redefined.
[13:13] <mamarley> You're definitely right though, the PPA build was done with _FORTIFY_SOURCE=2 and the archive build with _FORTIFY_SOURCE=3.
[13:16] <mamarley> So what's the proper way to deal with this?
[13:19] <RikMills> maybe force =2 in debian/rules?
[13:19] <RikMills> not sure
[13:19] <RikMills> assuming this is the cause
[13:21] <mamarley> I was going to do some empirical testing and find out.  I'm not quite sure how to set _FORTIFY_SOURCE in debian/rules though.  (I'm just an amateur at this whole debian packaging thing.)
[13:24] <BluesKaj> Hi all
[13:25] <mamarley> It looks like I could turn off hardening altogether by using export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-fortify, but that's not what I want.
[13:29] <RikMills> maybe something like https://salsa.debian.org/postfix-team/postfix-dev/-/commit/d1d1217d8560ae6ffe0ed670610d267bb9d3737d
[13:29] -ubottu:#kubuntu-devel- Commit d1d1217 in postfix-team/postfix-dev "Bump _FORTIFY_SOURCE to level 3"
[13:29]  * RikMills shrugs
[13:30] <mamarley> That should do the trick, thanks!  (I wasn't aware that DEB_CPPFLAGS_MAINT_APPEND existed,)
[13:37] <mamarley> Yes, that works.  I rebuilt kio with "export DEB_CPPFLAGS_MAINT_APPEND = -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2" in debian/rules and Dolphin no longer crashes on start.  Thanks for the help!
[19:25] <RikMills> mamarley: https://launchpad.net/ubuntu/+source/kio/5.113.0-0ubuntu2
[19:25] <RikMills> :)
[20:20] <mamarley> Thanks!


[18:19] <marcoceppi> launchpadlib and lazr.restfulclient 0.13.4 seem broken in vivid
[18:20] <marcoceppi> http://paste.ubuntu.com/12265175/ thsi command runs fine in trusty with 0.13.3-1 build of python-lazr.restfulclient
[18:25] <marcoceppi> https://bugs.launchpad.net/lazr.restfulclient/+bug/1491971
[18:25] <mup> Bug #1491971: charm promulgate fails with lazr.restfulclient (0.13.4) <Juju Charm Tools:Won't Fix> <lazr.restfulclient:Confirmed> <https://launchpad.net/bugs/1491971>
[19:04] <cjwatson> marcoceppi: I use it all the time in vivid.  What does "ls /usr/lib/python2.7/dist-packages/lazr/" say?
[19:05] <marcoceppi> cjwatson: it works on my fresh vivid, i'm working with two users on two systems who reported it to charm-tools, let me drag them in here
[19:06] <cjwatson> note it's my evening, can't guarantee to be around synchronously
[19:06] <marcoceppi> cjwatson: thanks, I'm talking to them now
[19:06] <cjwatson> I suspect this is namespace packages ftl
[19:07] <cjwatson> /usr/lib/python2.7/dist-packages/lazr/__init__.py is probably missing for some reason
[19:07] <marcoceppi> cjwatson: http://paste.ubuntu.com/12265709/
[19:07] <cjwatson> hm, no
[19:07] <marcoceppi> had him do a --reinstall, no avail
[19:08] <cjwatson> afraid I don't immediately know and I have to go.  I'd try getting an strace and see what it's actually trying to load
[19:08] <marcoceppi> cjwatson: ack, ta
[19:08] <marcoceppi> I may have them do a purge then re-install
[19:09] <cjwatson> get an strace first, don't destroy the evidence
[19:09] <marcoceppi> cjwatson: sure, ack, will do


[06:00] <IZh> I'm just studying optimal developers/QA ratio in similar projects. Wiki says that Canonical currently is about 550 people. But how many of them are QA and testers? 30%, 50%, 70%?..
[06:01] <tsimonq2> IZh: A lot of Ubuntu community members aren't Canonical employees :)
[06:02] <IZh> tsimonq2: Wiki says that there are 142 community testers
[06:02] <IZh> :-)
[06:02] <tsimonq2> IZh: Some people on this list work for Canonical: https://launchpad.net/~ubuntu-testing/+members
[06:03] <IZh> Just curious how many people needed to keep such a project in shape. :-)
[06:04] <tsimonq2> From what I can tell, the stats aren't 100% clear for Ubuntu
[06:04] <tsimonq2> Lots of people do Quality-related things in their daily uploads
[06:04] <tsimonq2> I can guarantee not all of them are on that list
[06:04] <tsimonq2> And vice versa, not all QA people are "Ubuntu Developers"
[06:04] <IZh> E.g. SUSE has about 1000 people, and RH is about 8000, but its areas of interest is bigger than simply RHEL/Fedora.
[06:05] <tsimonq2> Sure
[06:05] <tsimonq2> But also keep in mind that Canonical has other QA teams besides Ubuntu
[06:05] <IZh> Hmm...
[06:05] <tsimonq2> Canonical is a small company compared to them
[06:06] <tsimonq2> I think 700 is the right number for how many employees Canonical has...
[06:06] <tsimonq2> But yeah
[06:06] <tsimonq2> IZh: It's going to be hard to find all of them ;)
[06:07] <IZh> I don't need exact number. :-) Just an order of magnitude. :-) Want to know, e.g. if you have 1000 packages in distro, then how many QA/testers do you need to ship stable product. :-)
[06:11] <tsimonq2> IZh: The numbers are going to be muddy anyways because we pull a *lot* from Debian
[06:13] <IZh> tsimonq2: Surely, but I suppose you are testing what you are pullinh
[06:13] <IZh> ;-)
[06:14] <tsimonq2> True.
[06:14] <tsimonq2> Not always, though. :P >__>
[06:14] <IZh> :-))


[16:09] <cgroza> What is the purpose of this channel?
[17:08] <deem> !help
[17:08] <ubot2> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)