=== dendrobates is now known as dendro-afk [02:37] bdrung: Have you released a version of ubuntu-dev-tools with SPONSOR_PATCH_BUILDER yet? Because I want to factor that code into a library that sponsor-patch and backportpackage share, at which point it should probably be UBUNTU_TOOLS_BUILDER or something [02:37] (If you've released it already, I can just leave some backwards compatibility code lying around) === ssj6akshat|bed is now known as ssj6akshat === Amaranth_ is now known as Amaranth === ssj6akshat is now known as ssj6akshat|schoo === _LibertyZero is now known as LibertyZero [06:27] freeflying, I added https://launchpad.net/~ubuntu-sru to the bug I reported, is this right? [06:29] hychen_: subscribed? [06:29] freeflying, yes [06:33] hychen_: is the package in universe or main? [06:33] freeflying, universe [06:33] freeflying, it is from debian [06:33] in most cases subscribing ubuntu-sru isn't correct anymore as the SRU team reviews in teh upload queue [06:34] freeflying, I also have a question, when pkg in proposed goes to update archive? [06:35] hychen_: after ftp-master check and approve it [06:35] micahg: so, in hychen_'s case, he gonna seek for a sponsor to upload it into maverick-proposed? [06:35] freeflying, so the issue also need to be fix in next release? [06:36] freeflying: so, ubuntu-sponsors should be subscribed, not ubuntu-sru [06:37] also, Ubuntu doesn't have ftpmasters, the archive admins will move an update from -proposed to -updates after the test case has been verified and it's been in -proposed for a week [06:37] how can i contribute ? I am a experienced C,c++ programmer [06:38] micahg, is any wiki page mentioned this? [06:38] micahg: same job, different titles [06:38] hychen_: which thing? [06:39] hychen_: you can send me debdiff, I will upload it for you :) [06:39] hychen_: should all be here: https://wiki.ubuntu.com/StableReleaseUpdates [06:40] micahg, thanks , I think I miss some important sections, I'll reviewed it again [06:42] freeflying, the debdiff is http://tinyurl.com/28ylvl7, but I don't know how to version the package correctly [06:42] freeflying, should I change the series to maverick-proposed? [06:43] hychen_: in which version did you find it? [06:43] freeflying, 1.3.7.20100910-1 in debian [06:43] freeflying, and is already sync to Natty [06:44] actually, 1.3.9.2-1 is in sid and natty [06:45] micahg, it is ibus-chewing not ibus [06:45] hychen_: the one in maverick is ibus-chewing-1.3.6.20100730? [06:45] freeflying, yes [06:45] ibus is at 1.3.8-1 [06:46] micahg, you are right, my information is old, sorry [06:46] hychen_: A minimal patch applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to get a general approval from the SRU team first. [06:47] hychen_: maybe you shall consider of backport it from natty [06:49] freeflying, follow https://help.ubuntu.com/community/UbuntuBackports . right? [06:51] hychen_: I think so [06:51] There isn't a lp:ubuntu/libtool [06:51] libtool doesn't show up on merges.ubuntu.com (although it should?) [06:51] hychen_: btw, ibus-chewing is in main [06:51] and it's outdated [06:51] * xnox libtool is wonderful [07:00] xnox: no, it's only newer in experimental (that doesn't mean it can't be merged though) [07:00] micahg, will be a bit of pain without lp:ubuntu/libtool and lp:debian/libtool [07:01] xnox: you should have bzr branches available [07:03] micahg, http://package-import.ubuntu.com/status/libtool.html [07:03] AssertionError: Can't find the needed upstream part for version 2.2.6a-4 [07:04] xnox: oh well, I guess not [07:05] xnox: just diff natty against sid and apply to experimental [07:05] that's my plan =) [07:07] Anyone ever used pull-debian-debdiff? [07:07] hmm, fascinating [07:09] micahg, I'll use import-dsc to import the three packages - base, mine, other, just to use merge-package [07:09] =) [07:10] xnox: ok, but that seems like a lot harder [07:10] micahg, but I will be able to diff without pain =) push to lp and use a recipe for test builds :-P [07:11] or $ bzr bd-p [07:11] bzr alias bd-p='bd --builder="pdebuild"' [07:11] xnox: there's no Ubuntu branch from what I can tell [07:12] So? =) I can still push to lp:~/libtool/udd-fail [07:12] xnox: if you like :) [07:12] xnox: you can also check for a bug on teh udd project [07:17] micahg, [07:17] $ bzr merge-package ../experimental/Text conflict in debian/patches/series [07:17] 1 conflicts encountered. [07:17] The merge resulted in 1 conflicts. Please resolve these and commit the changes with "bzr commit". [07:17] * xnox loves bzr-bd =))))) [07:20] good morning [07:37] good morning! [07:38] Good morning [07:39] pitti: good morning, can you take a quick look at a response for me to a bug before I send it? http://pastebin.ubuntu.com/542951/ for bug 688781 [07:39] Launchpad bug 688781 in sqlite3 (Ubuntu) "Please update to 3.7.3 or 3.7.4 in Maverick" [Undecided,Confirmed] https://launchpad.net/bugs/688781 [07:43] micahg: it's certainly an answer I can agree to :) we did put new upstream microversions into stables in the past, and sqlite has tons and tons of tests, but if people want to go ahead with that, we need to review the upstream changelog [07:43] micahg: if .2 -> .3 is just three bug fixes, we might as well take it as it is [07:43] if it has 50 changes, then backporting is better [07:43] (IMHO) [07:44] pitti: I can only find one instance of an update of sqlite3 and it was for a single patch in jaunty [07:44] micahg: I mean for other packages, not for sqlite [07:44] pitti: ah, ok [07:44] pitti: .3 adds 2 interfaces, not just bug fixes [07:45] http://www.sqlite.org/releaselog/3_7_3.html [07:45] micahg: I guess it's then worth looking at a diff, and checking if that just adds new code (that should be rather harmless, as existing sw doesn't use it) [07:46] micahg: anyway, this kind of research should be done by the requestor of the SRU [07:47] anyone know what's happening in bug 689345? (ancient amd64 deb still published in natty, arch:any package only seems to get built on i386 these days) [07:47] Launchpad bug 689345 in python-kinterbasdb (Ubuntu) "3.2-3ubuntu3 still in natty/amd64" [Undecided,New] https://launchpad.net/bugs/689345 [07:49] pitti: ok, I watch the bugs because xulrunner depends on it, also, this started because of a OMGBuntu post, so I'm guessing the users on the bug are less technical [07:49] micahg: I guess in this case your response is just fine :) [07:51] pitti: if you think it's worthwhile, I can review the upstream changes [07:54] micahg: it's a lot of testing and risk involved (sqlite is used by a lot of software), so I'd still like the requestor to at least do a more through analysis of the changes [07:54] pitti: I definitely agree with that, I'll post my comment, thanks [07:54] micahg: "I" wouldn't go ahead with it on my own personally [07:55] pitti: I'm also adding a line about a lot of apps using it and the burden of testing [08:03] pitti: thanks, I have trouble sometimes deciding how much work the reporter should do [08:04] micahg: of course, if you would like to do that, please do [08:05] pitti: not really, I just wanted to make sure I wasn't asking too much === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === smb` is now known as smb === doko_ is now known as doko === nenolod_ is now known as nenolod [09:10] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smb [09:10] * smb has little clue yet how to go on... === axp2_ is now known as axp2 [09:16] hey seb128! [09:18] dholbach, hey! how are you? [09:18] great - thanks - how are you? [09:18] I'm fine thanks [09:18] we was nice [09:19] I just have to catch up on 3 days backlog now ;-) === Tm_T_ is now known as Tm_Tr [09:33] doko: is the pastewebkit sync in cocoplum:~lp_archive/syncs/ yours? perhaps you meant to flush it? [09:35] cjwatson: yes, forgot to sync [09:46] doko: shall I flush it now? [09:48] cjwatson: sorry, otp. done now [09:49] ok, thanks [10:00] jhunt: maw-neeng [10:14] doko, moin, should I be able to dist-upgrade a maverick chroot to natty by now or is that still known to be broken (it seems one I started last week still does not get ahead, but maybe I should start over)? [10:16] smb: which package version of python is currently on your system> [10:16] ? [10:17] doko, Well it is python2.7-minimal that fails with pycompile:240: requested versions not installed. But python2.6 seems still installed [10:18] smb: that was not my question. what does dpkg -l python show [10:18] ? [10:19] python 2.6.6-2ubuntu1 [10:19] (ii) [10:20] and dpkg -l python-dev python-dbg ? (start the lines with ii?) [10:22] no [10:22] both un [10:23] As noted, I started that upgrade last week. Probably some upgrade path was not right then. And now it won't get out. But I can easily just start over [10:24] smb: please get the packages python-minimal and python from https://launchpad.net/ubuntu/+source/python-defaults/2.7.1-0ubuntu3/+build/2094391 [10:25] then do install these two deb's with sudo dpkg --unpack python*deb [10:25] and run sudo dpkg --configure --pending [10:25] then run an apt-get update && apt-get dist-upgrade [10:30] doko, python depends on python2.7 which is not installed [10:32] smb: ok, then get this too from the archive, and dpkg --unpack that too [10:33] pitti: hello. Did my previous upload to libgphoto2 introduce a langpack related regression or was that always there (the one you just fixed) ? [10:33] janimo: langpack? [10:33] janimo: the one I fixed came from Debian [10:33] doko on the lp page you pointed me to, is that a special name? Cause I do not see a python2.7_... [10:33] I sent the fix there, too [10:34] pitti: ok,, I got some mail related to Chinese .po [10:34] a few days after uploading [10:34] janimo: ah, ignore those [10:34] well, they are bugs in the .po files [10:34] but we don't touch them in Ubuntu [10:34] pitti: ok, thanks [10:34] frankly these are mostly spamn [10:35] smb: dpkg -l python2.7-minimal python2.7 ? [10:36] ii python2.7-mini 2.7.1-1ubuntu1 A minimal subset of the Python language (ver [10:36] No packages found matching python-2.7. [10:36] But I guess I need to follow https://launchpad.net/ubuntu/+source/python2.7 [10:36] not python-default [10:42] doko, Ok, with manually installing python2.7, python (2.7) and python-minimal (2.7), the installation seems to sort itself out [10:42] smb: ok, thanks for confirming [10:43] doko, sure. thanks for sorting it out. [10:47] Laney: hello [10:49] Laney: ghc6 ftbfs on armel again, but this time it looks like a hung build after 18h+ and not package specific problems. [10:57] the funny thing about that exim security notice is that I'd given up with exim and purged it from my mail server about one minute before kees' mail arrived [10:57] ebroder: i released it already, but we can change it [11:00] bdrung: I went ahead and wrote up the compatibility code, but whatever you prefer [11:01] ebroder: it's up to you to drop the compatibility code [11:02] bdrung: Fine. If you're going to make me make the call, I'll leave it since it's already written [11:02] ok === diwic is now known as diwic_afk [11:09] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: [11:09] * smb -> lunch [11:10] Keybuk: OOC, are you planning to have Upstart create implicit jobs from .service files for D-Bus activation, or make people that want to use it write proper Upstart jobs? [11:10] implicit jobs? [11:11] I'm not sure what exactly I'd call them. "Use /usr/share/dbus-1 as a configuration source" [11:11] you mean jobs that are based on different configuration parsers? [11:12] Why yes, that's exactly what I was fumbling to say [11:12] the main use case for that is parsing /etc/init.d - which is already done by someone else [11:12] so es [11:12] yes [11:12] I'm not sure there'd be a benefit to parsing /usr/share/dbus-1 as long as there's a dbus-daemon [11:12] since that's parsing it anyway [11:12] you'd need to somehow tell dbus-daemon to ignore its own configuration and send upstart events instead [11:12] janimo: really? looks built to me [11:13] Keybuk: I had sort of figured that's what you would do. Otherwise what's the point of D-Bus activation? [11:13] Laney: I'll check again, I looked on Saturday and it said it waskilled fter a timeout of 15 minutes [11:13] janimo: don't know if it works though [11:13] Laney: I'll check, thanks [11:14] ebroder: the end goal of having init do is that it means dbus-daemon doesn't have to any longer [11:14] and means we could get rid of dbus daemon in the future [11:14] plus you can combine it with other things only init knows about, e.g. init can know that it can't activate that job right now, because its other requirements aren't met [11:15] Keybuk: Sure. It seems like a useful intermediate state would be to do exactly what you described, and have D-Bus use Upstart for service supervision [11:17] Keybuk: It doesn't seem like replacing the service starter with an Upstart event emitter should be that bad. Presumably dbus-daemon already has to separate service activation from actually delivering the message that spawned the service, since the message doesn't get delivered until the service finishes initializing itself [11:21] right indeed [11:21] I have that bit on my work items for this release [11:21] Keybuk: I know, I've been following. I was just seeing if I understood the plan correctly [11:21] not expecting it to take more than a week to get working [11:21] yeah initially the plan is to just have dbus emit the event though [11:21] not for upstart to also parse dbus's config for it [11:21] ebroder: the builder class needs an "update" function [11:22] if that turns out to be necessary [11:22] then it's not hard [11:23] bdrung: "update" as in "run apt-get update; apt-get dist-upgrade in this chroot"? [11:23] Keybuk: Got it. Thanks [11:23] ebroder: yes. for pbuilder "sudo pbuilder update" [11:24] ebroder: and then a command line parameter for updating the builder before building [11:25] bdrung: I'm happy to do that, but can I do it as a separate branch? The backportpackage branch is already starting to become sort of massive [11:25] bdrung: I can open a ticket about it and assign it to myself [11:26] ebroder: yes [11:51] janimo: looks broken: see bug 689496, trying the patch there now [11:51] Launchpad bug 689496 in ghc6 (Ubuntu) "ghci can’t load unix package (/usr/lib/libpthread.so: invalid ELF header)" [Undecided,New] https://launchpad.net/bugs/689496 [11:51] Laney: hmm so it builds packages but does not make them correct? [11:52] right [11:52] ok [12:06] Laney: at least Setup.hs built, since some of the packages progressed on retry [12:08] janimo: It's in the RTS, so I hope the next version will fix it [12:08] great [12:16] cjwatson: would you mind if I test/apply the patch in bug 415038 before you consider it for Debian? [12:16] Launchpad bug 415038 in debconf (Ubuntu) "port GNOME frontend to GtkAssistant" [Medium,Triaged] https://launchpad.net/bugs/415038 [12:27] pitti: it's on my queue to review today-ish [12:27] pitti: I'd prefer if I reviewed it before we applied it [12:27] there are all sorts of amusing things that could go wrong with a broken frontend [12:27] cjwatson: ok; it needs some porting to the current version, so I'll do that and attach the patch [12:27] non-trivial porting? [12:28] yes [12:28] hm, ok [12:28] the current version disables some window functions (close button, etc); should be "easy", but not just simple fuzz [12:28] and I generally want to test it with synaptic and s-c before we roll this out [12:29] I want to test some of the more obscure features of debconf [12:30] cjwatson: right; so it sounds we'll work on different things then [12:30] I'll wait 'til you attach your current version before starting [12:32] ebroder: the "# TODO: Add "retry" and "update" option" was for adding a option to ask_for_manual_fixing() to update the builder from there [12:32] cjwatson: is there a quick method to use "test_debconf.pl" or similar with the gnome frontend? (quicker than rebuild/install/synaptic install xdm) [12:34] aah [12:34] DEBIAN_FRONTEND=gnome samples/demo [12:36] yes [13:08] pitti: whats the status of the kernel SRU for bug 651370 ? [13:08] Launchpad bug 651370 in linux (Ubuntu Maverick) "ec2 kernel crash invalid opcode 0000 [#1]" [Medium,Fix committed] https://launchpad.net/bugs/651370 [13:10] asac: it awaits regression testing from our QA team [13:11] pitti: thanks. is that happening automatically? or should we send a reminder? [13:11] asac: reminder already happened [13:12] kk [13:18] cjwatson: I ported janimo's patch, but it apparently doesn't return correct values now; I'll investigate further after lunch [13:22] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smb === alecu_ is now known as alecu === dendro-afk is now known as dendrobates === jtechidna is now known as JontheEchidna [14:00] Hm, for requests that ask for merging newer debian versions into ubuntu and there is a debdiff. Is there a simple way to get the new orig.tar.gz or do I have to search? [14:01] you can set up chdist to have a configuration pointing to Debian unstable, and then use 'chdist apt-get unstable -d source ' [14:01] man chdist [14:01] smb: I usually download it from the PTS (http://packages.qa.debian.org/pkgname) or my unstable chroot [14:02] pitti, Ah thanks. Dumb follow up: what does PTS stand for? [14:02] smb: Package Tracking System [14:02] Package Tracking System [14:03] Heh, ok. Thanks [14:04] cjwatson: I have a C/POSIX-ish query for you [14:04] I always love those [14:04] need a competant lawyer to validate my idae [14:04] (and my spelling) [14:04] would this be wrong? [14:04] union { [14:04] struct tm tm; [14:05] int bits[7]; [14:05] }; [14:05] what were you then planning to do with that union? [14:06] well, the idea is that bits[0] is then directly equivalent to tm.tm_sec [14:06] bits[3] is tm.tm_mday [14:06] in the library with the revolver [14:06] bits[6] is tm.tm_wday [14:06] and use the array as a way of indexing the components of the struct [14:06] my gut feel is that that's the sort of thing where strict-aliasing trips you up [14:08] which would be likely to cause optimisation difficulties aside from anything else [14:08] though are you asking if the alignment is guaranteed to be identical? [14:08] ah, but it's a union [14:09] strict-aliasing doesn't apply to unions [14:09] (that's kinda the point of them) [14:09] um [14:09] sort of [14:09] is the ordering of that even vaguely guaranteed to be portable? [14:10] penguin42: that's kinda my question really [14:10] I'm pretty sure that a struct of 7 ints is directly equivalent to an array of 7 ints [14:10] and have put the book down [14:10] http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html points out that using unions for that is technically undefined unless one of the punned elements is a char * [14:10] (although widely supported anyway) [14:11] (best explanation I've found of strict-aliasing and related issues) [14:13] yeah I was reading that [14:14] the idea of my hack above is that by putting the tm and int array into the union [14:14] you're declaring to the compiler that they *do* share the same memory location [14:15] it's not a pointer to the tm, it's the tm itself that's in the union [14:16] OK, so. structs are memory-ordered in declaration order (6.2.7.1(5,13)). There may be unnamed padding within a struct (6.2.7.1(13)). Arrays are "contiguously allocated" (6.2.5(20)), while structs are merely "sequentially allocated". [14:16] I think you're in an area that in practice will always work but is not technically defined thus [14:16] (because for it not to work, you'd have to need alignment for ints, which would be a strange implementation choice) [14:17] even if you had alignment for ints, both the array and struct would have to align on that boundary, no? [14:17] it'd only not work if the struct as a whole was aligned to something far wider than the int alignment [14:17] that's not how I read "contiguously allocated" [14:17] e.g. each member of the struct was on an 8-byte boundary [14:17] on a platform with a 2-byte boundary [14:17] which I guess the compiler is allowing for [14:17] arrays don't get to have internal alignment, even if that's what the platform would normally want [14:18] cjwatson: sure they do, otherwise &(a[2]) wouldn't be valid [14:18] you can't take the address of an unaligned object [14:18] s/compiling is allowing for/standard is allowing for/ [14:18] err. char a[16]; &(a[3]) is permitted on any platform, AIUI. [14:18] sure because the alignment rules of char * are 1 [14:19] pitti, is there any thing blocking moving cloud-init into lucid-updates. (0.5.10-0ubuntu1.5 bug 683890) [14:19] Launchpad bug 683890 in cloud-init (Ubuntu Lucid) "config-grub does not run" [High,Fix committed] https://launchpad.net/bugs/683890 [14:19] none of this means that arrays ever have internal alignment [14:19] show me an example where they ever do [14:19] ok, hypothetical platform [14:19] my understanding is that that's explicitly forbidden by "contiguous allocation" [14:19] this platform has 8-byte alignment for int [14:19] but 4-byte ints [14:20] otherwise, what does the difference between "contiguous" and "sequential" mean? [14:20] if you had an array of two ints that was 4-byte aligned rather than 8-byte aligned [14:20] then: [14:20] int *a = &(a[1]); [14:20] would be useless [14:20] you couldn't retrieve *a or assign to *a without breaking the platform's alignment rules [14:20] pitti, Another of my stupid questions: in the maintainers section is a change from "Ubuntu Core Developers" to "Ubuntu Developers" correct? [14:21] I was suggesting that the standard is allowing the struct to use a wider alignment if it needs to [14:21] e.g. even if the int was 4-byte aligned, it could choose to 8-byte align the struct members [14:21] (perhaps it aligns them to the largest alignment of any member) [14:21] that works as a reductio ad absurdum, but only if the alignment of ints is the only reason why the platform might insert internal padding into a struct [14:21] right, and *that* would break your model. but in practice I doubt it will happen ... [14:21] yeah, it'd be an odd thing to do :p [14:21] smb, we changed to "Ubuntu Developers" (https://wiki.ubuntu.com/DebianMaintainerField) [14:22] deliberately inserting space into structs would be curious [14:22] but maybe the standard isn't disallowing it [14:22] thus the difference in terminology [14:22] smb, so we don't distinguish between packages that are in main or in universe [14:22] the standard doesn't forbid it, that's all. and since you were asking for standards lawyering :) [14:22] dholbach, Ok, thanks. Then it is correct as it is [14:22] (likewise in practice, no platform I've ever heard of uses anything other than word or int-sized alignment for int types) [14:22] right [14:23] so I guess it's a decision of whether to err on the side of "this works, and gcc doesn't even complain" or not [14:23] wait, one other question [14:23] POSIX doesn't, AFAICS, guarantee the *ordering* of struct tm members [14:23] it says "The header shall declare the tm structure, which shall include at least the following members:" [14:23] but nothing about what order they come in, whether extra things can be inserted in between, ... [14:24] ah [14:24] good catch [14:24] I imagine most new platforms copy and paste the sequence from POSIX, but I'm not sure about legacy platforms [14:24] so glibc could randomly move that around between releases [14:24] Laney: how did you find out about the missing -lpthread in ghc6? [14:24] well, I don't really care about legacy platforms [14:24] but I do care about Drepper having a brain-wave and breaking code [14:25] where "legacy" means "anything that was initially created before POSIX" [14:25] though that'd be an ABI break I guess [14:25] (er, yeah, slightly eccentric meaning of "legacy" there) [14:25] dholbach, Hm, reading the link you posted. Should then, instead of XSBC-Original-Maintainer", the "Debian-Maintainer" be used? [14:26] Linux's documentation explicitly declares the order of the fields, of course [14:26] smb, no XSBC-Original-Maintainer should be fine (update-maintainer from ubuntu-dev-tools usually does that for me :-)) [14:26] smb: the poll said Debian-Maintainer, but we never used that in practice [14:27] Ah, ok. [14:27] * smb is just looking at the changes from a debdiff [14:27] Keybuk: right, and it would indeed be pretty hard (impossible?) to change without breaking existing binaries [14:27] impossible, certainly [14:27] Keybuk: again, not sanctioned by standards but probably OK in practice [14:28] yaeh, hmm [14:29] likewise you couldn't actually change the alignment of the struct :p [14:29] so if it works now, it'll work forever [14:29] and break when we roll out a new architecture [14:29] yeah, nothing to stop a new arch having whatever field ordering it feels like - in theory [14:37] * `A member of a union object is accessed using a member of a [14:37] different type (C90 6.3.2.3).' [14:37] The relevant bytes of the representation of the object are treated [14:37] as an object of the type used for the access. *Note [14:37] Type-punning::. This may be a trap representation. [14:37] .. [14:37] It's a Trap! [14:39] smoser: bug 683379 hasn't been verified yet, but otherwise it looks ok [14:39] Launchpad bug 683379 in grub2 (Ubuntu Natty) "user prompted twice on ec2 grub-pc upgrade from 1.98-1ubuntu7 to 1.98-1ubuntu8" [High,Confirmed] https://launchpad.net/bugs/683379 [14:40] cjwatson: hmm, reading a bit more [14:41] apparently it's *recommended practice* for a compiler to align struct members by the most restrictive member [14:41] rather than the individual member's own alignment [14:41] (c-faq) [14:41] ok [14:41] I think I've persuaded myself out of doing that now [14:45] pitti, i had verified that last week, just forgot to mark the tag on that bug (since really the 3 bugs fixed were the same bug) [14:45] i'll go ahead and put a quick verify in though. [14:49] stock natty + unity, dist-upgraded this morning; everything across the top bar disappeared (ie, no netwok manager, no sound indicator, no messaging menu) [14:49] suggestions? [14:50] (besides "reboot into classic desktop") [14:50] kirkland: Do you see a seg of unity-panel-ser in your dmesg? [14:52] penguin42: yeah, there is a video related segfault [14:52] kirkland: I'm trying to file abug against unity-panel-ser but apport is refusing most annyoyingly [14:53] penguin42: cool, thanks, subscribe me (kirkland) when you do [14:53] kirkland: uninstall indicator-datetime [14:53] kirkland: and restart compiz [15:00] Ok, so that debdiff looks mostly ok. What would be the usual mode to go on. Ask the person that has provided the debdiff to bzr pull request? Do it ourselves? [15:01] didrocks: okay, thanks, will do in a few minutes [15:04] cjwatson: ping about bug #688839 [15:04] Launchpad bug 688839 in dpkg (Ubuntu Natty) "proposal to turn dh_shlibdeps warning into an error" [High,New] https://launchpad.net/bugs/688839 [15:08] doko: I'm not confident with that - please bring it up with the Debian dpkg folks [15:08] doko: I suspect that the proposed change would break plugins [15:10] but buxy will know more [15:10] cjwatson: yes, it would. but making this an error for anything in /usr/lib would be a good thing [15:11] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=unresolved-symbols-so;users=peter.fritzsche@gmx.de [15:12] doko, it seems it would bring extra work for no real reason [15:13] can't we just set it as a soft goal for natty? [15:13] rather than forcing people to have to deal with builds breaking now [15:14] seb128: I don't consider unresolvable symbols at runtime a soft reason [15:15] doko: I'm not going to take responsibility for making this change - please discuss it with buxy et al, they have more facts than I do [15:15] cjwatson: I'll do [15:15] doko: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558872 is listed there and I happen to know that that library would break if you didn't allow that unresolved symbol [15:16] it's a slightly weird library that requires the application to supply that symbol [15:16] doko: misbuilds on armel [15:16] geser reported it to me [15:16] cjwatson: however I know buxy's reply. debian doesn't build with --no-add-needed, so why do you report it here ... [15:16] sorry, ftbfs not misbuilds [15:16] doko: why not let buxy reply rather than putting words in his mouth? [15:17] anyway, for me, Debian bug 558872 is an example of why this shouldn't be an error across the board - there has to be a way to override it [15:17] Debian bug 558872 in src:libcgic "Resolve unresolved symbols in shared libraries" [Wishlist,Open] http://bugs.debian.org/558872 [15:17] well, I got similiar replies from him on dpkg-gensymbols ... [15:18] doko: Anyway, I think I can revert the explicit linking on -lpthread as it was only needed for the bootstrap afaics [15:19] the real fix was a patch I grabbed from the upstream tracker together with the one in ubuntu3 [15:19] Laney: ahh, ok. just wanted to understand why it was needed [15:20] http://hackage.haskell.org/trac/ghc/ticket/4523 [15:20] that ticket [15:21] doko: I have a question that you might help me with :). I have a package that FTBFS because of the --no-add-needed thingy... So I modify Makefile.am, but the changes don't apply in build time. So, do I also have to manually modify the Makefile.in or should I run autoreconf to recreate the .in file? [15:22] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smb, sconklin [15:23]