[00:15] <Keybuk> cjwatson: I always find the final resolution of the "Mount time in future" bug entertaining
[00:16] <Keybuk> not because of the bug itself
[00:16] <Keybuk> but because after years of bitching about Ubuntu
[00:16] <penguin42> which one is that?
[00:16] <Keybuk> it turned out that the bug was in the ext4 code after all
[00:17] <cjwatson> did you see the resolution of the dpkg-fsync-slowness bug?
[00:17] <Keybuk> no?
[00:17] <Keybuk> did Ted blame Bunnies?
[00:17] <cjwatson> it turned out that fsync was slow after all and now dpkg uses sync_file_range and prays nothing explodes
[00:18] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605009#75
[00:19] <Keybuk> eep
[00:21] <ion> Oh? I inferred from Ted’s messages that the sync_file_range way is Correct™ and Rainbows and Ponies.
[00:21] <Keybuk> I enjoy how Ted thinks it's reasonable behaviour for a filesystem to require the filesystem maintainer themselves to have to investigate obscure sequences of little-used commands to get reasonable behaviour
[00:22] <cjwatson> ion: after years of saying that applications should just use fsync
[00:22] <ion> I mean, of course it would be good if the filesystem didn’t go to Las Vegas to meet some alcohol and drink some hookers every time you do an fsync, but is what dpkg does now not secure in terms of worst-case filesystem corruption?
[00:23] <cjwatson> oh, I'm sure it is  [note: this comment should not be taken to mean actual sureness]
[00:23] <Keybuk> ion: the irony is that dpkg doesn't care about filesystem corruption
[00:23] <Keybuk> all dpkg actually cares about is that things happen in a sensible order
[00:23] <cjwatson> i.e. atomicity not durability, as several people pointed out in that bug to resounding silence
[00:25] <cjwatson> "i.e." is probably wrong but that's the relevant property heree
[00:26] <Keybuk> I suspect the problem is that filesystem developers don't actually understand the difference
[00:26] <Keybuk> they're so (naturally) focussed on durability, they don't understand the need for atomicity
[00:32] <penguin42> is it atomicity or just ordering?
[00:32] <Keybuk> in dpkg's case it's just atomicity
[00:33] <Keybuk> you have a "FILE" A at a "PATH" (where "FILE" is both content and meta-data, etc.)
[00:33] <cjwatson> obviously ordering matters too but I think posix's guarantees are sufficient there
[00:33] <Keybuk> dpkg adds a new "FILE" B
[00:33] <Keybuk> all dpkg wants guaranteed is that if it places "FILE" B at "PATH", in case of any error or system crash, etc. either A or B are at "PATH"
[00:34] <penguin42> ah ok
[00:34] <Keybuk> the belief was that rename() was sufficient for this, because it happens to provide that atomicity for POSIX file operations
[00:34] <Keybuk> but filesystem authors claim what applies to POSIX file operations doesn't apply to POSIX file systems
[00:34] <Keybuk> (which is a valid, but irritating claim)
[00:42] <lifeless> Keybuk: have you followed the debian-devel thread on dpkg performance?
[00:42] <Keybuk> lifeless: no
[00:43] <lifeless> it got v. messy ;)
[00:43] <Keybuk> I can believe it
[00:43] <lifeless> and now there is another thread about the general pattern being 'broken'
[00:43] <lifeless> etc
[00:43] <Keybuk> :-)
[00:43] <lifeless> cjwatson: how feasible would it be to carry a barrier() patch set, do you think?
[00:45] <cjwatson> I'm not carrying anything Ubuntu-specific here
[00:45] <cjwatson> no way
[00:46] <cjwatson> I didn't follow the debian-devel thread because I figured it was a cesspit; but I was of the understanding that 1.15.8.7 pretty much resolved the practical problems
[00:46] <lifeless> for dpkg
[00:46] <cjwatson> no idea, you'd have to ask a dpkg developer
[00:46] <lifeless> I mean 'the problems for dpkg are resolved'
[00:46] <lifeless> bzr has the same issue, as does git
[00:47] <lifeless> gnome config files too
[00:47] <cjwatson> I don't know and don't really want to know :)
[00:48] <cjwatson> the whole thing depresses me and makes me want to do something more fun, like chewing nails
[00:48] <lifeless> :)
[00:49] <CarlFK> cjwatson: a friend wants to give up programming in favor of raising goats.  I am thinking he is onto something.
[00:49] <lifeless> but are they web scale?
[00:49] <CarlFK> it is much more fun than chewing nails.
[00:50] <CarlFK> lifeless: what country are you in?
[00:50] <lifeless> nz
[00:50] <ion> I’m already doing goats 2.0
[00:50] <CarlFK> the mogo is webscale ting was done by a friend of mine
[00:50] <lifeless> cool
[00:51]  * lifeless waves
[00:51] <lifeless> afk for a while
[00:51] <CarlFK> I have a mongo db shirt wiht a blank back.  I know where the silk screen thing is to fix it :)
[01:04] <psusi> blast... still no new e2fsprogs
[01:24] <Keybuk> ugh, I hate just how much stuff you need to do to initialise an init daemon these days :-/
[01:28] <MattJ> dbus yet? :)
[01:28] <Keybuk> MattJ: how do you mean?
[01:30] <MattJ> nm, upstart at least does indeed depend on dbus
[01:30] <Keybuk> indeed, all IPC to/from upstart is via dbus
[01:30] <Keybuk> either via the bus daemon or a private peer-to-peet socket
[07:37] <didrocks> good morning
[08:05] <uBUXUBu> this 10.04 is a good
[08:05] <uBUXUBu> nice job
[08:07] <pitti> Good morning! Happy new year!
[08:08] <ebroder> happy new year, pitti
[08:08] <uBUXUBu> i want to submit something, i have the initial draft done now.
[09:08] <pitti> siretart: happy new year!
[09:09] <pitti> siretart: can you please reupload x264 with a fixed LP: # syntax in the changelog for bug 690296? Thanks!
[09:34] <tkamppeter> pitti, happy new year.I got a patch to fix bug 465916 from Tim Waugh, applied and uploaded it and it has taken me most of the time between XMas and Year++ to fix several, bugs, especially segfaults in the patch. Now ity works great.
[09:34] <pitti> tkamppeter: gesundes Neues!
[09:34] <pitti> tkamppeter: yep, I saw; I'll upload it to sid soon, thanks for this!
[09:34] <pitti> nice to have a good avahi integration in both directions now
[09:40] <tkamppeter> pitti, before you could only actively create a queue pointing to a printer or a remote CUPS queue which advertized itself by DNS-SD. Now CUPS can automatically/implicitly offer a queue locally if a remote CUPS server broadcasts via DNS-SD only (usually Mac in default config). In addition, the local queues are advertized via DNS-SD and so appear on a Mac automatically.
[09:40] <pitti> tkamppeter: right, the latter was missing with the old "bonjour compat" patch, right?
[09:42] <tkamppeter> pitti, onot only the latter, only tyhe first one (you create actively a queue, using the discovery by the *backend*) was available. CUPS (the *daemon*) did not automatically pick up the DNS-SD broadcasts of a Mac.
[09:43] <tkamppeter> pitti, Now it is the case that if you shre a printer on a Mac, you get it automatically (if you accept broadcasts). If you share a printer, the Macs in the network (which accept broadcasts) get it automatically.
[12:11] <siretart> pitti: "frohes neues" to you as well! :-)
[12:11] <pitti> siretart: danke :)
[12:11] <siretart> pitti: reuploaded now
[12:11] <siretart> pitti: do you know if kenvandine is on vacation or something? he didn't react at all to my pings regarding this bug
[12:12] <pitti> siretart: he probably was until today; he should wake up in a few hours
[12:12] <siretart> ah, I see
[12:27] <pitti> @all heads-up: the WI tracker has kept crashing for the last few days; someone apparently changed the launchpadlib checkout on people, and didn't test it
[12:27] <udevbot> Error: "all" is not a valid command.
[12:28] <elmo> pitti: it's the python-launchpadlib from lucid - see the motd
[12:28] <pitti> elmo: it's using /home/platform/desktop/versions/lpbinding/launchpadlib/ apparently
[12:29] <elmo> pitti: ah, ok
[12:29] <pitti> I'll deal with it, but lunch first
[12:29] <elmo> pitti: well FWIW, the box is now on lucid - that may be the root cause
[12:29] <pitti> elmo: ah, did that change recently?
[12:29] <pitti> elmo: I get tons of warnings, too; lucid should be recent enough, so that we can drop the local checkout and PYTHONPATH hackery
[12:30] <elmo> pitti: yeah, over the holidays
[12:30] <pitti> elmo: "change recently" -> i. e. did lillypilly get a lucid upgrade recently?
[12:30] <pitti> elmo: ah, thanks for the heads-up
[13:56] <geser> is the DIF already in effect?
[14:05] <cjwatson> geser: yes - I'll send a mail about it tomorrow
[14:18] <geser> cjwatson: do you know when the last sync was done? (so I know from when I should look at debian-devel-changes for important changes)
[14:21] <ScottK> barry: https://launchpad.net/ubuntu/+source/git-buildpackage/0.5.12/+build/2106718/+files/buildlog_ubuntu-natty-i386.git-buildpackage_0.5.12_FAILEDTOBUILD.txt.gz looks like it might be python2.7 related.
[14:21] <BlackZ> geser: https://lists.ubuntu.com/archives/natty-changes/2011-January/004535.html - seems like this is the last one done
[14:22] <Laney> BlackZ: that isn't an autosync though
[14:22] <Laney> the last autosync run is what is relevant here
[14:24] <geser> BlackZ: this one looks like from a sync request as we don't auto-sync from Debian experimental
[14:24] <BlackZ> geser: ah, do you mean the last auto-sync? :)
[14:24] <Laney> O_O
[14:24] <geser> BlackZ: yes
[14:25] <geser> so I can look for any security-related uploads to Debian which we should get too (if possible)
[14:25] <barry> ScottK: thanks
[14:26] <ScottK> barry: You're welcome.  I figure it's a new year and you're looking for stuff to do.
[14:27] <barry> ScottK: i was hoping to skate along at least until next week. :)  happy new year to you
[14:27] <ScottK> ;-)
[14:30] <diwic> are comboboxes known to be broken in natty?
[14:31] <diwic> Makes it kind'a hard to do anything :-)
[14:33] <mvo> hey popey - thanks for the nice blog post about squid-deb-proxy. looks like you hit bug #666014, there is a sru for this, I will check why its not in the -updates archive yet
[14:38] <popey> mvo: np, thanks for making it :)
[14:43] <diwic> ok, it wasn't all comboboxes
[14:47] <hggdh> cjwatson: good morning, can you please see bug 694772?
[14:57] <cdbs> doko: ping, I have seen a few package uploads that have in changelog: Fix FTBFS due to binutils-gold. If I try to investigate the upload, I find that the package neither has binutils-gold in b-d, nor is it mentioned anywhere in the source. Infact, the package uses the standard linker (not ld.gold) and the ftbfs fix seems to be a simple fix for ld --no-add-needed. So, this means two things: 1) I am mistaken 2) The uploader falsely thinks ld.gld 
[14:59] <cdbs> In other words, I mean to ask: is gold the standard linker in natty? or is the uploader in such cases getting confused?
[14:59] <doko> "ld --no-add-needed" and "gold" should have the same behaviour in this regard
[14:59] <doko> no, gold is not the standard
[14:59] <cdbs> of course it ain't
[15:00] <cdbs> doko: but doesn't gold have many more changes than that? is this an effort to ease moving to gold in the future?
[15:01] <ScottK> cdbs: People are incorrectly using gold as a synonym for "ld --no-add-needed" in their changelog entries.
[15:01] <cdbs> :o
[15:01] <cdbs> Thanks for the confirmation ScottK
[15:02] <doko> cdbs: yes, but don't make all changes at once
[15:02] <cdbs> thanks doko
[15:03] <ScottK> doko: Thanks for fixing up gpgme1.0.
[15:07] <micahg> doko: since we're already on the topic of the toolchain, I've noticed people patching the Makefiles instead of configure for linker flags and not adding the libraries as build depends, is there a standard for this?
[15:08] <doko> micahg: depends on the context which approach is the correct one. any concrete example?
[15:09] <micahg> doko: http://launchpadlibrarian.net/61382381/gnome-web-photo_0.8-0ubuntu5_0.8-0ubuntu6.diff.gz
[15:09] <ScottK> micahg: I would say though that if one makes a package link against another one it ought to be added to build-depends (I don't think that's context dependent).
[15:10] <micahg> right, I thought that was part of the point of not violating encapsulation
[15:10] <ari-tczew> IMO if package built fine without adding new Build-Depends then is OK
[15:11] <micahg> ari-tczew: that defeats half the purpose of adding the libs in the first place
[15:11] <doko> micahg: I think the patch does the right thing, and yes, maybe the libs shouldn't be specified directly, but some macros (X11_LIBS?) used instead. but otoh, there's already one library mentioned explicitly
[15:12] <micahg> right, I was thinking that's a bad example, let me dig up another one
[15:12] <ari-tczew> doko: what's the conclusion: do we have to add linked library to Build-Depends or not?
[15:14] <ScottK> ari-tczew: If you don't, you're depending on the fact that some other package you build-depend on pulls it in.  You've no guarantee that won't change in the future, so not adding them is a fragile solution at best.
[15:15] <doko> ari-tczew: well, it doesn't hurt, but otoh these should already be fulfilled by dependencies
[15:15] <ari-tczew> ScottK: OK, got it!
[15:15] <micahg> doko: here's a patch that builds fine, but I haven't sponsored since I thought it was wrong: http://launchpadlibrarian.net/61338534/firestarter_1.0.3-8ubuntu2.dsc.debdiff
[15:16] <tumbleweed> I'm happy to have inferior interim solutions in Ubuntu if we can get tell upstream about the issue, and get a better fix down the line
[15:17] <doko> +-FIRESTARTER_CFLAGS = @FIRESTARTER_CFLAGS@
[15:17] <doko> ++FIRESTARTER_CFLAGS = @FIRESTARTER_CFLAGS@ -lX11
[15:17] <doko> micahg: this is the only wrong thing which I can see
[15:17] <doko> the change in .am is correct
[15:17] <doko> now you could look at Makefile.in, if it has an X11_LIBS macro and use this instead
[15:18] <micahg> doko: ok, so we don't have to change configure to add -lX11 to FIRESTARTER_LIBS?
[15:19] <ari-tczew> tumbleweed: changes which we are adding could be included upstream? or upstream should prepare another way to fix?
[15:20] <tumbleweed> ari-tczew: yeah, obviously forward your solution, and do the best you can, but upstream probably knows their build system better than you do
[15:26] <doko> micahg: well, you can do this too, yes. but then, add a check for X11 too
[15:27] <micahg> doko: ok, is one way any more correct?
[15:28] <doko> micahg: both approaches fix the issues with --no-add-needed correctly. I assume the upstream likes fixing configure.in more
[15:29] <micahg> doko: ok, thanks
[15:29] <doko> adding x11 to PKG_CHECK_MODULES should be enough
[15:34] <rickspencer3> doko, hello
[15:35] <doko> rickspencer3: hi
[15:35] <rickspencer3> doko, thanks for the work on LibreOffice, too bad about your vacation though
[15:35] <rickspencer3> anyway, good news, I think the desktop team has a maintainer starting maybe this week for Libre Office
[15:36] <doko> rupture of muscle fiber ...
[15:36] <rickspencer3> doko, that sounds painful
[15:38] <doko> rickspencer3: afaik it's Feb 01
[15:39] <rickspencer3> doko, oh well, Feb will be here before we kjnow it
[15:39] <rickspencer3> thanks for getting us started!
[15:40] <ScottK> doko: What's the issue with KDE integration?
[15:40] <doko> ScottK: see the issue list. I don't have build log anymore
[15:41] <doko> ScottK: re-enable kde in debian/rules and check ...
[15:44] <ScottK> doko: The natty bug doesn't have a build log.  Was the error the same as in the lucid bug?
[15:45] <doko> ScottK: no, therefore the separate report
[15:45] <ScottK> Sigh.
[15:45] <doko> ok, starting a build ...
[15:47] <mvo> popey: uploaded new version to maverick-proposed it would be nice if you could give it a go once it hits the archive so that this bug can (hopefully) be closed
[15:49] <doko> ogra: shadow build failure ("first thing to fix in 2011" ;p)
[15:50] <ogra> doko, yeah, yeah, i just finished my vacation, give me a day to wade through the 5000 mails that piled up
[15:50] <ogra> doko, und frohes neues  :)
[15:51] <doko> you too
[15:58] <mvo> does anyone know why avahi-browse would return a IPv4 record that starts with fe80:: (a ipv6 address)? that does not seem to make a lot of sense
[16:21] <doko> ScottK: patch attached
[16:29] <ricotz> doko, thanks for the libreoffice packages!
[16:47] <tseliot> cjwatson: is there a problem with installing empty files in packages in Natty? As I'm getting the following: http://launchpadlibrarian.net/61568238/buildlog_ubuntu-natty-amd64.fglrx-installer_2%3A8.801-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:52] <geser> tseliot: does that file exist in your debian/ directory after a fresh unpacking of the source package?
[16:52] <SpamapS> so I'm working on the eglibc component of bug #672177 .. the postinst needs to not call 'telinit u' if init is upstart .. but I'm wondering about how we support an upgrade from hardy ... if upstart is installed before the new eglibc .. then 'telinit u' won't work..
[16:53] <tseliot> geser: ah, good point, let me check. BTW it works fine if I add a line that's commented out
[16:57] <geser> tseliot: when looking more closely at the error I wonder about the double debian in "debian/tmp/debian/fglrx.grub-gfxpayload"
[17:00] <tseliot> geser: that should be fine
[17:00] <tseliot> I guess
[17:02] <asac> directhex: hey ... someone claimed you managed to get banshee working?
[17:02] <asac> (on arm)
[17:06] <geser> tseliot: I fetched now the source package and there is no debian/fglrx.grub-gfxpayload file. My guess it that empty files don't get created by the diff.gz
[17:07] <directhex> asac, i haven't observed issues with it when testing with an efikamx. just sorta works
[17:08] <asac> directhex: hmm. strange. thats ubuntu or debian on it?
[17:08] <asac> e.g. armv7 binaries?
[17:08] <tseliot> geser: ok, good catch then. I'll add that line and fix the FTBFS
[17:08] <tseliot> thanks
[17:09] <directhex> asac, maverick
[17:10] <directhex> my arm equipment is at home, and i'm in cambridge this week
[17:11] <asac> kk
[17:11] <asac> GrueMaster: ^^ ... *shrug*
[17:11] <asac> ogra: ^^
[17:17] <SpamapS> oohh.. init was already upstart in hardy.. so we only have to consider the dapper upgrade to lucid case..
[17:17] <janimo> micahg: hi, is firefox planned to be built against the xulrunner package (I remember you said tbird does not work that way)
[17:21] <ScottK> SpamapS: dapper to lucid is not a supported upgrade path.
[17:21] <ScottK> SpamapS: It's have to be dapper -> hardy -> lucid.
[17:21] <micahg> janimo: no, why?
[17:21] <janimo> micahg: the usual, to not have to fix the same bugs twice :)
[17:21] <SpamapS> ScottK: this may be an issue for dapper -> hardy .. but I think actually its ok anyway.
[17:21] <janimo> in this case armel ftbfa
[17:22] <micahg> janimo: ah, yeah, we're stuck with that if we want to use the firefox branding ;)
[17:22] <micahg> janimo: is that all we need to fix it, that flag in the bug?
[17:22] <SpamapS> ScottK: the sequence of events is .. upgrade libc and init (upstart or sysvinit), run configuration of libc6, touch /var/run/init.upgraded, then tell user to reboot, which runs 'telinit u'
[17:22] <janimo> micahg: well, I set that flag and the build is happily marching on well past thte failure point
[17:23] <janimo> with the proper mach arg visible on the output
[17:23] <micahg> janimo: awesome, thank you, I'll upload later tonight if chrisccoulson doesn't get to it first
[17:23] <SpamapS> ScottK: what may be broken is that telinit may not have the capability to restart sysvinit, which is what I'm concerned about.
[17:23] <janimo> micahg: great, thanks
[17:23]  * ScottK nods
[17:24] <janimo> micahg: the flag is explicitly set by upstream on android builds but not for regular linux
[17:24] <SpamapS> ScottK: and given that dapper is going EOL in approximately 6 months (right?) we may have a lot of people doing upgrades over the next year. ;)
[17:24] <ScottK> SpamapS: Yes, but you need to solve it for Hardy, not Lucid.
[17:25] <micahg> janimo: ah, idk if we can ask for that since different distros build for different ARM compatibility versions
[17:26] <SpamapS> ScottK: indeed, I'm looking at that scenario right now.
[17:26] <janimo> micahg: indeed, I was just mentioning it
[17:26] <micahg> janimo: thank  you, it's still nice to know why stuff is the way it is even if one can't do anything about it :)
[17:26] <janimo> so mozilla know about the flas, luckily we are not the first ines tetsing with armcv7+thumb2
[17:26] <janimo> s/flas/flag/
[17:27]  * micahg still has to get his arm box working
[17:37] <doko> asac: is the banshee mir now complete?
[17:37] <doko> asac: please could you have a look at the libwpd mir?
[17:42] <asac> doko: yes, took the assignment
[17:42] <doko> ok, promoting banshee
[17:43] <ogra> bah
[17:44] <ogra> all that arm ignorance
[17:44] <asac> ogra: i tried hard
[17:45] <ogra> yeah, just wanted to rant a bit :)
[17:46] <cdbs> lool: Why did you assign bug to yourself?
[17:47] <cdbs> I said I am working on it :)
[17:47] <cdbs> lool: I just attached the correct debdiff, could you look at it, please?
[17:49] <lool> cdbs: I didn't see you were working on it, I was working on it as well; I've actually uploaded a real fix rather than a workaround
[17:49] <cdbs> lool: which is?
[17:49] <cdbs> lool: Does that fix the selftest issues as well?
[17:50] <lool> cdbs: Defining different readline() functions
[17:50] <lool> cdbs: I didn't check whether it fixes selftest
[17:50] <cdbs> lool: but still, the selftests fail, and that is a serious issue
[17:50] <cdbs> lool: it causes corruption of the .bzr directories
[17:50] <cdbs> it was better for bzr to be unusable than to have data corruption
[17:51] <cdbs> That was the main reason I opted for a temporary workaround
[17:53] <lool> cdbs: Indeed
[17:55] <cdbs> lool: noooooo! That is exactly the fix which I tried earlier!
[17:56] <cdbs> lool: It will build well on all archs except i386, where it will report many test failures
[17:56] <cdbs> but the problems it will report are applicable for all archs
[17:57] <lool> cdbs: I reverted to ubuntu1 and uploaded an ubuntu3 using python2.6 with your second debdiff
[17:57] <cdbs> okay thanks lool
[17:58] <cdbs> finally, we will have a good and usable bzr
[17:58] <cdbs> :)
[18:16] <SpamapS> looks like the package-import failed in a weird way for eglibc
[18:16] <SpamapS> http://package-import.ubuntu.com/status/eglibc.html#2010-12-17 18:14:30.871947
[19:14] <soren> cjwatson, persia, cody-somerville, bdrung, geser: DMB meeting in #ubuntu-meeting.
[19:37] <kees> pitti: hi! around? what's the state of the karmic proposed kernel?
[19:38] <bdmurray> Riddell: does bug 692636 really need a maverick task?
[19:51] <ari-tczew> bdmurray: it doesn't.
[19:53] <bdmurray> ari-tczew: okay thanks, that is what I was thinking
[20:06] <SpamapS> mmmm eglibc build
[20:06] <SpamapS> Finished at 20110103-1205
[20:06] <SpamapS> Build needed 01:46:26, 1871068k disc space
[20:42] <SpamapS> hrm, so upgrading to natty switched me to unity, which doesn't play at all nicely with my nvidia multi monitor setup. :-(
[21:26] <hallyn> SpamapS: 'ubuntu classic desktop' doesn't give you your old desktop?
[21:26] <geser> SpamapS: there is still the "Ubuntu Classic Desktop".
[21:31] <SpamapS> Yes I just think unity is way sexier. ;)
[21:31]  * SpamapS is searching for bug reports right now before reporting
[21:34] <kees> doko: does gcc-4.5 compile for you on natty? I'm seeing:
[21:34] <kees> configure: error: cannot compute suffix of object files: cannot compile
[21:35] <doko> kees: huh? which arch?
[21:35] <hallyn> SpamapS: yeah, as soon as that settles down a bit, i'm hoping to do a tiling compiz module and have my dream wm at last :)
[21:35] <kees> amd64. I suspect my chroots
[21:35] <kees> doko: also, I've almost got gcc-4.6 ready with the hardening patch updates
[21:35] <kees> doko: should I just email you the diff?
[21:36] <doko> kees: for other archs I would suspect the binutils update, but that ftbfs on amd64
[21:36] <doko> kees: or a bug report
[21:36] <kees> will LP let me open a bug for a package no in the archive yet?
[21:37] <doko> use gcc-snapshot
[21:37] <kees> okay
[21:38] <jcastro> SpamapS: the only multimonitor regression I have in Unity is the panel stretching over both panels, if you have more please report them
[21:41] <SpamapS> jcastro: I'm using the nvidia proprietary drivers..
[21:41] <jcastro> me too, twinview?
[21:41] <SpamapS> yeah
[21:41] <SpamapS> when I enable the second monitor, which has a different resolution, I get the band across the screen and the icons on the left display wrong
[21:42] <SpamapS> will screenshot.. looking through a few of the other nvidia related bug reports
[21:42] <jcastro> oh, does the launcher appear as if it's using the resolution of the smaller monitor to determine its size?
[21:42] <SpamapS> Also for some reason even though chrome is my default browser links clicked open firefox.. but thats unrelated. :-P
[21:43] <jcastro> yeah I have that one too
[21:43] <tumbleweed> anyone know a bug number for that?
[21:43] <tumbleweed> aah bug 670128
[21:53] <kees> doko: okay, LP: #696990 for gcc-4.6 with hardening re-enabled.
[21:54] <doko> \o/
[21:54] <kees> the only weird part is relro.
[21:54] <doko> ?
[21:54] <kees> it looks like it used to be applied on top of the gold-and-ld patch
[21:54] <kees> so I tried to make it a little more agnostic (which also removes the linaro-specific bit)
[21:54] <doko> yeah, I need to update that one and forward it ...
[21:55] <kees> anyway, the linker spec changed so gold-and-ld doesn't apply, and since relro is right in there too, it blew up as well.
[21:55] <kees> one of the testsuite patches got taken upstream completely.
[21:55] <kees> so I dropped that.
[21:55] <kees> a few source files got moved around, so I fixed those.
[22:17] <SpamapS> ok, 15 compiz crashes later, I reported bug #696996
[22:41] <robert_ancell> @pilot in
[22:45] <cjwatson> geser: I did an autosync on the morning of 30 Dec, although there are still a few bits and pieces I need to iron out (I've kept a safe copy of Sources files)
[22:45] <kees> doko: uh-oh. gcc-4.6 behaves very differently than 4.5 on things...
[22:45] <cjwatson> hggdh: holiday today, will look tomorrow
[22:46] <cjwatson> soren: sorry - national holiday today, forgot to tell the DMB list
[22:48] <doko> which things?
[22:48] <kees> doko: for example, I cannot unset _FORTIFY_SOURCE any more. (see the bug report 696990) I put an example up.
[22:49] <kees> COLLECT_GCC_OPTIONS='-v' '-U_FORTIFY_SOURCE' '-O2' '-o' 'test' '-mtune=generic' '-march=x86-64'
[22:49] <kees> vs
[22:49] <kees> COLLECT_GCC_OPTIONS='-v' '-U' '_FORTIFY_SOURCE' '-O2' '-o' 'test' '-mtune=generic' '-march=x86-64'
[22:50] <doko> nice
[22:50] <kees> and stack protector wasn't on... still looking for that.
[22:55] <kees> doko: ah, ssp was disabled twice. an additional patch is up now on the bug.
[22:56] <hggdh> cjwatson: cool, thanks
[22:57] <kees> doko: so, since the spec file expects -U_FORTIFY_SOURCE, how do I change it to allow -U _FORTIFY_SOURCE ?
[22:58] <doko> kees: ENOCLUE. would have to look myself. I know that option handling was revamped by jsm28
[22:59] <kees> hmpf
[22:59] <Laney> They should have taken the lead with the first real attempt on goal just before the half-hour mark when Troy Brown's header from Leadbitter's cross was excellently tipped over the bar by Forest keeper Lee Camp.
[22:59] <Laney> Connor Wickham was a constant thorn in the side of the visitors' defence, but despite increasing pressure as the match wore on, the hosts failed to work Camp often enough.
[22:59] <Laney> argh
[22:59] <Laney> just in case you were interested in nottingham forest's fate... /me runs
[22:59] <kees> heh
[23:15] <kees> doko: ah, I think I've found a solution.
[23:18] <kees> doko: I'll send and updated debdiff after I verify it.