[00:00] can I just run patch against that file and paste in the diff output? [00:00] If you're jumping across multiple upstream versions, it's better to take the time and track down the specific upstream versions where the new symbols were added [00:01] don't suppose anyone knows the nm or objdump magic to show which version of a symbol something either declares or wants? [00:02] why bother if they weren't packaged? [00:02] psusi: You don't know that they weren't === HawksWin is now known as Pilif12p [00:02] I don't think you can do that penguin... you can just see that it needs a symbol, which is why it is important that symbols not change, only add new ones, then you can see what version the new one was added with this symbol file apparently [00:02] ebroder, well they aren't in debian or Ubuntu ;) [00:03] psusi: There exist packages outside of Debian and Ubuntu [00:03] I don't think I care enough to bother... especially since I"m taking it from .54 to .74, so 20 upstream releases [00:04] updating the symbols on each one would be a royal pita [00:06] (readelf is the answer to symbol versions) [00:29] Hmm looks like linux-source-2.6.36 was put in universe instead of main [00:34] usual hiccup [00:34] * ScottK is learning about fixing linker failures. [00:35] So far ~ half the Universe packages I've touched FTBFS with the new linker behavior. [00:35] fun [00:36] This is the one where you...start linking libraries you only indirectly depend on? [00:36] Or is it stop? [00:36] new linker behavior? [00:40] ebroder: It's the indirect one. [00:40] psusi: See doko's "Natty open for development" message to u-d-a. [00:41] k [00:42] Wait - are we switching to gold, or just changing how the old linker works? [00:45] debuild is trying to sign with an invalid email that's not set in the changelog nor DEBEMAIL. Where else could it be getting it from? [00:46] so if I understand this correctly, if you call function foo in lib bar, and you link to lib bar but not lib snoz, but lib bar does... in gcc 4.4 the linker ended up mashing them all together and thus, resolving references you make to libsnoz? and now it doesn't? [00:47] ebroder: Apparently changing how the old one works. [00:47] psusi: Yes. [00:47] Wait, is that it, or is it s/function foo in lib bar/function foo in lib snoz/? [00:47] goofy... so basically the fix is to add the -l directives that should have been there all along but weren't? [00:48] We've gone a couple of cycles now without a toolchain change that made us fix a bunch of stuff to get things that built before to build again. [00:48] psusi: Yes. [00:48] "Developers are frequently lazy; film at 11" [00:50] as evidenced by the several quilt patches in lvm2 that have no documentation [00:50] fortunately, I managed to either fix to apply, or determine upstream integrated already, about half of them [00:50] the other half... not sure what they are for so if they didn't cleanly apply, I just dropped for now [00:52] it's funny, at first I didn't like the buttons on the left of the window thing... but I went to the Renesas DevCon this week and there was a lab using Fedora... I kept trying to click the left when the buttons were on the right === Pilif12p is now known as Pilif12p|afk === drizztbsd_ is now known as drizztbsd [01:55] wohoo! new version of lvm merged, built, and running... now to finish the changelog entry, push the branch to lp and see if I can get someone to review and merge it ;) [01:56] after I play with merging snapshots a bit... === Pilif12p|afk is now known as Pilif12p === asac_ is now known as asac === Pilif12p is now known as Pilif12p|afk === Pilif12p|afk is now known as Pilif12p [04:36] has anyone seen something like this in natty? http://pastebin.ubuntu.com/514787/ [04:37] micahg: GCC 4.5's behaviour has changed. [04:38] wgrant: I know, but this seems unusual with 2 libraries having the same symbols [04:38] ld won't let you link against symbols that you only pull in indirectly. [04:38] oh, right, I guess that's what it is :-/ [04:39] http://fedoraproject.org/w/index.php?title=UnderstandingDSOLinkChange [04:39] wgrant: great, thanks [05:37] cjwatson: Hi! I have a problem with grub2 from a freshly installed Maverick to boot Windows XP: when just pressing enter on the WinXP entry in the boot menu, WinXP cannot find autochk and fails to boot. However, if I select the entry in the boot menu, press 'e' and then crtl+x without changing anything, then WinXP boots without problems. Any idea? [05:55] cjwatson: forget it... configuration mistake. :) 'insmod parttool' and 'insmod'chain' were missing. [06:46] cjwatson: gaa... no, that didn't fix it, problem is still there... anyways: bug #662015 [06:46] Launchpad bug 662015 in grub2 (Ubuntu) "WinXP fails to boot from boot menu, but boots fine from edit mode" [Undecided,New] https://launchpad.net/bugs/662015 === Pilif12p is now known as Pilif12p|afk [09:38] ArneGoetje: bizarre. no ideas off the top of my head, unfortunately ... [09:58] cjwatson: could you remove from merge-o-matic/main these packages? libfile-basedir-perl , myspell-sk [10:24] ari-tczew: done [10:24] thanks [10:35] cjwatson: I'm currently merging vim and asking myself if the python3 interpreter support should also be enabled for the basic builds or still only the python2 one? [10:38] geser: good question, I don't know. does it add dependencies not currently in main? [10:39] and do they conflict in any way? [10:39] probably not (have to check the b-d to be sure) but it build-depends on python3-dev which is already in main [10:40] I suppose it would add libpython3.1 or something to vim's footprint [10:40] but it doesn't seem obviously wrong to me to enable python3 support [10:40] cjwatson: probably no conflict as for ALLINTERPRETERS both get enabled [10:40] not, if a vim package ends up with dependencies on both 2 and 3 [10:41] we changed in the the past NOINTERPFLAGS to enable python also in the basic builds and now there is also an option for python3 [10:41] doko_: does that mean "not obviously wrong" or "no we shouldn't do it"? [10:44] I'm wondering if it's even possible to configure with both interpreters, and what you end up with. so I don't know about the former, but we shouldn't do that, if it results in a binary/package pulling python3 on the cd's. if a separate binary package is built, which is not on the CD, ok [10:45] which vim variant is on the CDs? [10:47] vim is on the server CD, not desktop [10:48] vim-tiny is on everything [10:50] I'll do a test-build and check the resulting dependencies then [11:00] cjwatson: vim gets now compiled with "--with-modified-by=NAME name of who modified a release version" set to the Debian Vim maintainers mailing list. Should I left it like this or set it to ubuntu-devel-discuss@ ? [11:01] I don't know, use your judgement === hunger_ is now known as hunger [11:48] cjwatson: could you remove xf86-input-evtouch and mochikit from merge-o-matic/universe? [11:52] cjwatson: also could you take a look why zsh-beta exist in merge-o-matic/universe as Updated merges? === elmo changed the topic of #ubuntu-devel to: forums and wiki down for 5m for emergency maintenance | 10.10 released on 10/10/10 at 10:10:10UTC!! | Natty is open, more SRUs for Maverick | 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 h === elmo changed the topic of #ubuntu-devel to: 10.10 released on 10/10/10 at 10:10:10UTC!! | Natty is open, more SRUs for Maverick | 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 === dendro-afk is now known as dendrobates [14:49] hi, i'm working on a ubuntu-based distro, trying to change the distro name in ubiquity. (the files use a ${RELEASE} variable, not sure where that's set.) anyone know where to set it? (if this isn't the right channel, pls advise the right one!) [14:50] (to be more exact, it's the distro name displayed in the ubiquity gui screens that i'd like to change) [14:55] doko_, cjwatson: I've tried compiling vim 7.3 with dynamic loading of python2 and python3. The resulting deb has no dependency on python (or libpython) at all and vim tries loading libpython2.6 or libpython3.1 when one uses :py or :py3 commands. It this acceptable to let both enabled (with dynamic loading)? [15:02] dan4dm: are the strings coming from debian-installer underneath? [15:03] dan4dm: but apt-get source ... && grep -r 'RELEASE ?=' [15:16] AHA got it [15:16] it's in /usr/share/ubiquity/ubiquity/misc.py ! [15:16] thanks [15:52] tumbleweed: Are you sure about marking kicad for lucid as invalid, won't the lucid-updates build of libwx-gtk break the kicad that's there at the moment? [16:01] penguin42: it started up fine for me with libwxgtk2.8-0=2.8.10.1-0ubuntu1.2 [16:05] that's curious, I wonder how that works === bjf is now known as bjf[afk] [16:09] tumbleweed: Could you do readelf -s libwx_gtk2u_aui-2.8.so.0 | grep -i _ZTI12wxAuiToolBar and the same on the kicad ? [16:18] penguin42: can't see any linkage to libwx_gtk2u_aui at all in the lucid version [16:18] hmm well that would explain why it didn't break [16:19] although what the heck a KDE app is doing being linked to a gtk library I'm not sure [16:20] ah, it's not KDE [16:21] hmm oh well, if it works === Pilif12p|afk is now known as Pilif12p [16:37] http://gitorious.org/puredyne-packages/pa [16:37] (wrong channel sorry) === Pilif12p is now known as Pilif12p|afk === Pilif12p|afk is now known as Pilif12p === ogra_ac_ is now known as ogra_ac [17:28] doko_: did the "buffer overflow" checker in gcc-4.5 got improved compared to gcc-4.4? As I've trouble to compile my merged vim package in natty because of a "buffer overflow" when trying to run the binary. Compiling it with gcc-4.4 or gcc-4.5 -O0 works. (The current vim package in the archive shows the same problem when getting build in natty) [17:29] doko_: it seems to be relate with the usage of "di_key[1]; /* key (actually longer!) */" as last member of a struct (di_key gets overflowed on purpose) === Ng_ is now known as Ng [17:47] hi [17:47] where can i report a bug in gi18n-lib.h in ubuntu 10.10? [17:47] i can't find a suitable bug tracker for thsi [17:49] mattn: libglib2.0-dev: /usr/include/glib-2.0/glib/gi18n-lib.h (on Debian at least). dpkg -S and apt-file search are helpful. [17:50] mattn: Then just run ubuntu-bug libglib2.0-dev [17:51] thanks [17:51] mattn: #ubuntu-bugs for help reporting bugs, #ubuntu for general support [18:02] hi there, am I in the right place to ask for package patching? [18:05] lyhana8: Generally if it's a bug or wishlist add a bug [18:05] penguin42: it's about a patch on the ATI driver package [18:06] the bug is marked as fixed [18:06] patch is to be done on fglrx kernel module to compile again on kernels with CVE-2010-3081 fixed [18:06] The compat_alloc_user_space functions in include/asm/compat.h files in the Linux kernel before 2.6.36-rc4-git2 on 64-bit platforms do not properly allocate the userspace memory required for the 32-bit compatibility layer, which allows local users to gain privileges by leveraging the ability of the compat_mc_getsockopt function (aka the MCAST_MSFILTER getsockopt support) to control a certain length value, related to a "stack pointer underflow" issue, [18:06] (as explain by someone on #ati) [18:07] hello [18:07] as I was installing 10.10 the other day, I noticed a translation mistake [18:07] I need this one to work on ubuntu 10.04 n_n [18:08] lyhana8: Well you can file a bug or comment on that bug; you could try asking in #ubuntu-x or #ubuntu-kernel as well [18:16] penguin42: k, thx [18:17] Kartagis: please file a bug against the package and open a project task for ubuntu-translations [18:21] micahg, okay thanks [18:21] micahg, the package? I'm talking about installation. what package would that be? [18:22] Kartagis: ubiquity I think [18:22] okay thanks [18:22] bye [18:54] hi everyone [18:57] Hi Bugs [19:34] Hello BUGabundo :) [19:35] olá Ian_Corne [19:35] you won't believe what I've been up all weeking [19:35] uploading pics and preping blog post [19:35] :D [19:35] you will drewl [19:37] python-paramiko: [19:37] Depends: python-crypto (>=2.1.0-2) but 2.0.1+dfsg1-4ubuntu2 is to be installed [19:37] ahh natty.... to good to be true [19:37] :D [19:37] I upgraded just fine :) [19:38] BUGabundo: you should wait at least till a1 ;) [19:39] your just weak [19:39] hell yeah! I like my system in usable state ;) [19:39] mine is [19:40] wont be for long i guess ;) [19:40] not much stuff uploaded to natty yet [19:40] it always is till feature freeze LOL [19:40] that's why I hate stable releases [19:40] they give me more probs then devel stuff [19:41] and there will likely be lots of build failures due to toolchain changes [19:41] ofc [19:41] well, the feature freeze means "upload all the crack you can now, before it's too late" ;) [19:41] .... but you will get what you asked for :) [19:41] ogra_ac: but I've been doing this since 2007 [19:41] so nothing is new to me [19:42] I know my away around most repo related probs [19:42] and what else breaks, goes into LP or nagging a dev [20:10] ari-tczew: xf86-input-evtouch, mochikit, zsh-beta merges removed. (zsh-beta showed as Updated because it's been uploaded in natty.) [20:10] "orbital-eunuchs-sniper"? package names get weirder and weirder [20:11] cjwatson: they'll become ship names before long [20:11] I could see milter renamed as 'the-grey-area' for instance [20:12] :-) [20:12] sendmail => The GCU You Really Didn't Want To Do That, Did You [20:45] cjwatson: nice === Guest16378 is now known as jelmer === jelmer is now known as Guest5922 [21:41] PID MINFLT MAJFLT VSTEXT VSIZE RSIZE VGROW RGROW MEM CMD 1/4 [21:41] 25926 38 6 48656K 1.1G 373.1M 0K 160K 9% chromium-brows [21:41] 30302 0 0 500K 589.5M 317.9M 0K -8K 8% eog [21:41] 2927 4841 3 48656K 1.0G 286.4M 0K 1268K 7% chromium-brows [21:41] 10956 145 11 48656K 1.1G 264.7M 0K 440K 7% chromium-brows [21:41] 1525 389 18 35K 864.1M 213.8M 0K 1232K 5% java [21:41] stupid chromium [22:03] cjwatson: This might not be a bad time to re-run your very stale merges script and point out ones that ought to be looked at. === nixternal_ is now known as nixternal === dendrobates is now known as dendro-afk === jelmer__ is now known as jelmer