[00:00] <psusi> can I just run patch against that file and paste in the diff output?
[00:00] <ebroder> 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] <penguin42> don't suppose anyone knows the nm or objdump magic to show which version of a symbol something either declares or wants?
[00:02] <psusi> why bother if they weren't packaged?
[00:02] <ebroder> psusi: You don't know that they weren't
[00:02] <psusi> 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] <psusi> ebroder, well they aren't in debian or Ubuntu ;)
[00:03] <ebroder> psusi: There exist packages outside of Debian and Ubuntu
[00:03] <psusi> 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] <psusi> updating the symbols on each one would be a royal pita
[00:06] <penguin42> (readelf is the answer to symbol versions)
[00:29] <lool> Hmm looks like linux-source-2.6.36 was put in universe instead of main
[00:34] <ogra_ac> usual hiccup
[00:34]  * ScottK is learning about fixing linker failures.
[00:35] <ScottK> So far ~ half the Universe packages I've touched FTBFS with the new linker behavior.
[00:35] <ogra_ac> fun
[00:36] <ebroder> This is the one where you...start linking libraries you only indirectly depend on?
[00:36] <ebroder> Or is it stop?
[00:36] <psusi> new linker behavior?
[00:40] <ScottK> ebroder: It's the indirect one.
[00:40] <ScottK> psusi: See doko's "Natty open for development" message to u-d-a.
[00:41] <psusi> k
[00:42] <ebroder> Wait - are we switching to gold, or just changing how the old linker works?
[00:45] <vadi21> 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] <psusi> 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] <ScottK> ebroder: Apparently changing how the old one works.
[00:47] <ScottK> psusi: Yes.
[00:47] <ebroder> Wait, is that it, or is it s/function foo in lib bar/function foo in lib snoz/?
[00:47] <psusi> goofy... so basically the fix is to add the -l directives that should have been there all along but weren't?
[00:48] <ScottK> 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] <ScottK> psusi: Yes.
[00:48] <ebroder> "Developers are frequently lazy; film at 11"
[00:50] <psusi> as evidenced by the several quilt patches in lvm2 that have no documentation
[00:50] <psusi> fortunately, I managed to either fix to apply, or determine upstream integrated already, about half of them
[00:50] <psusi> the other half... not sure what they are for so if they didn't cleanly apply, I just dropped for now
[00:52] <psusi> 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
[01:55] <psusi> 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] <psusi> after I play with merging snapshots a bit...
[04:36] <micahg> has anyone seen something like this in natty? http://pastebin.ubuntu.com/514787/
[04:37] <wgrant> micahg: GCC 4.5's behaviour has changed.
[04:38] <micahg> wgrant: I know, but this seems unusual with 2 libraries having the same symbols
[04:38] <wgrant> ld won't let you link against symbols that you only pull in indirectly.
[04:38] <micahg> oh, right, I guess that's what it is :-/
[04:39] <wgrant> http://fedoraproject.org/w/index.php?title=UnderstandingDSOLinkChange
[04:39] <micahg> wgrant: great, thanks
[05:37] <ArneGoetje> 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] <ArneGoetje> cjwatson: forget it... configuration mistake. :) 'insmod parttool' and 'insmod'chain' were missing.
[06:46] <ArneGoetje> cjwatson: gaa... no, that didn't fix it, problem is still there... anyways: bug #662015
[09:38] <cjwatson> ArneGoetje: bizarre.  no ideas off the top of my head, unfortunately ...
[09:58] <ari-tczew> cjwatson: could you remove from merge-o-matic/main these packages? libfile-basedir-perl , myspell-sk
[10:24] <cjwatson> ari-tczew: done
[10:24] <ari-tczew> thanks
[10:35] <geser> 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] <cjwatson> geser: good question, I don't know.  does it add dependencies not currently in main?
[10:39] <cjwatson> and do they conflict in any way?
[10:39] <geser> 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] <cjwatson> I suppose it would add libpython3.1 or something to vim's footprint
[10:40] <cjwatson> but it doesn't seem obviously wrong to me to enable python3 support
[10:40] <geser> cjwatson: probably no conflict as for ALLINTERPRETERS both get enabled
[10:40] <doko_> not, if a vim package ends up with dependencies on both 2 and 3
[10:41] <geser> 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] <cjwatson> doko_: does that mean "not obviously wrong" or "no we shouldn't do it"?
[10:44] <doko_> 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] <geser> which vim variant is on the CDs?
[10:47] <cjwatson> vim is on the server CD, not desktop
[10:48] <cjwatson> vim-tiny is on everything
[10:50] <geser> I'll do a test-build and check the resulting dependencies then
[11:00] <geser> 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] <cjwatson> I don't know, use your judgement
[11:48] <ari-tczew> cjwatson: could you remove xf86-input-evtouch and mochikit from merge-o-matic/universe?
[11:52] <ari-tczew> cjwatson: also could you take a look why zsh-beta exist in merge-o-matic/universe as Updated merges?
[14:49] <dan4dm> 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] <dan4dm> (to be more exact, it's the distro name displayed in the ubiquity gui screens that i'd like to change)
[14:55] <geser> 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] <sladen> dan4dm: are the strings coming from debian-installer underneath?
[15:03] <sladen> dan4dm: but  apt-get source ...  && grep -r 'RELEASE ?='
[15:16] <dan4dm> AHA got it
[15:16] <dan4dm> it's in /usr/share/ubiquity/ubiquity/misc.py    !
[15:16] <dan4dm> thanks
[15:52] <penguin42> 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] <tumbleweed> penguin42: it started up fine for me with libwxgtk2.8-0=2.8.10.1-0ubuntu1.2
[16:05] <penguin42> that's curious, I wonder how that works
[16:09] <penguin42> tumbleweed: Could you do   readelf -s libwx_gtk2u_aui-2.8.so.0 | grep -i _ZTI12wxAuiToolBar   and the same on the kicad ?
[16:18] <tumbleweed> penguin42: can't see any linkage to libwx_gtk2u_aui at all in the lucid version
[16:18] <penguin42> hmm well that would explain why it didn't break
[16:19] <penguin42> although what the heck a KDE app is doing being linked to a gtk library I'm not sure
[16:20] <penguin42> ah, it's not KDE
[16:21] <penguin42> hmm oh well, if it works
[16:37] <dan4dm> http://gitorious.org/puredyne-packages/pa
[16:37] <dan4dm> (wrong channel sorry)
[17:28] <geser> 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] <geser> 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)
[17:47] <mattn> hi
[17:47] <mattn> where can i report a bug in gi18n-lib.h in ubuntu 10.10?
[17:47] <mattn> i can't find a suitable bug tracker for thsi
[17:49] <ansgar> mattn: libglib2.0-dev: /usr/include/glib-2.0/glib/gi18n-lib.h (on Debian at least).  dpkg -S <file> and apt-file search <file> are helpful.
[17:50] <penguin42> mattn: Then just run ubuntu-bug libglib2.0-dev
[17:51] <mattn> thanks
[17:51] <penguin42> mattn: #ubuntu-bugs for help reporting bugs, #ubuntu for general support
[18:02] <lyhana8> hi there, am I in the right place to ask for package patching?
[18:05] <penguin42> lyhana8: Generally if it's a bug or wishlist add a bug
[18:05] <lyhana8> penguin42: it's about a patch on the ATI driver package
[18:06] <lyhana8> the bug is marked as fixed
[18:06] <lyhana8> patch is to be done on fglrx kernel module to compile again on kernels with CVE-2010-3081 fixed
[18:06] <lyhana8> (as explain by someone on #ati)
[18:07] <Kartagis> hello
[18:07] <Kartagis> as I was installing 10.10 the other day, I noticed a translation mistake
[18:07] <lyhana8> I need this one to work on ubuntu 10.04 n_n
[18:08] <penguin42> 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] <lyhana8> penguin42: k, thx
[18:17] <micahg> Kartagis: please file a bug against the package and open a project task for ubuntu-translations
[18:21] <Kartagis> micahg, okay thanks
[18:21] <Kartagis> micahg, the package? I'm talking about installation. what package would that be?
[18:22] <micahg> Kartagis: ubiquity I think
[18:22] <Kartagis> okay thanks
[18:22] <Kartagis> bye
[18:54] <BUGabundo> hi everyone
[18:57] <penguin42> Hi Bugs
[19:34] <Ian_Corne> Hello BUGabundo :)
[19:35] <BUGabundo> olá Ian_Corne
[19:35] <BUGabundo> you won't believe what I've been up all weeking
[19:35] <BUGabundo> uploading pics and preping blog post
[19:35] <Ian_Corne> :D
[19:35] <BUGabundo> you will drewl
[19:37] <BUGabundo> python-paramiko:
[19:37] <BUGabundo>   Depends: python-crypto (>=2.1.0-2) but 2.0.1+dfsg1-4ubuntu2 is to be installed
[19:37] <BUGabundo> ahh natty.... to good to be true
[19:37] <kklimonda> :D
[19:37] <Ian_Corne> I upgraded just fine :)
[19:38] <kklimonda> BUGabundo: you should wait at least till a1 ;)
[19:39] <BUGabundo> your just weak
[19:39] <kklimonda> hell yeah! I like my system in usable state ;)
[19:39] <BUGabundo> mine is
[19:40] <ogra_ac> wont be for long i guess ;)
[19:40] <ogra_ac> not much stuff uploaded to natty yet
[19:40] <BUGabundo> it always is till feature freeze LOL
[19:40] <BUGabundo> that's why I hate stable releases
[19:40] <BUGabundo> they give me more probs then devel stuff
[19:41] <ogra_ac> and there will likely be lots of build failures due to toolchain changes
[19:41] <BUGabundo> ofc
[19:41] <kklimonda> well, the feature freeze means "upload all the crack you can now, before it's too late" ;)
[19:41] <ogra_ac> .... but you will get what you asked for :)
[19:41] <BUGabundo> ogra_ac: but I've been doing this since 2007
[19:41] <BUGabundo> so nothing is new to me
[19:42] <BUGabundo> I know my away around most repo related probs
[19:42] <BUGabundo> and what else breaks, goes into LP or nagging a dev
[20:10] <cjwatson> ari-tczew: xf86-input-evtouch, mochikit, zsh-beta merges removed.  (zsh-beta showed as Updated because it's been uploaded in natty.)
[20:10] <cjwatson> "orbital-eunuchs-sniper"?  package names get weirder and weirder
[20:11] <lifeless> cjwatson: they'll become ship names before long
[20:11] <lifeless> I could see milter renamed as 'the-grey-area' for instance
[20:12] <cjwatson> :-)
[20:12] <cjwatson> sendmail => The GCU You Really Didn't Want To Do That, Did You
[20:45] <lifeless> cjwatson: nice
[21:41] <BUGabundo>   PID MINFLT MAJFLT      VSTEXT  VSIZE  RSIZE  VGROW  RGROW  MEM CMD     1/4
[21:41] <BUGabundo> 25926     38      6      48656K   1.1G 373.1M     0K   160K   9% chromium-brows
[21:41] <BUGabundo> 30302      0      0        500K 589.5M 317.9M     0K    -8K   8% eog
[21:41] <BUGabundo>  2927   4841      3      48656K   1.0G 286.4M     0K  1268K   7% chromium-brows
[21:41] <BUGabundo> 10956    145     11      48656K   1.1G 264.7M     0K   440K   7% chromium-brows
[21:41] <BUGabundo>  1525    389     18         35K 864.1M 213.8M     0K  1232K   5% java
[21:41] <BUGabundo> stupid chromium
[22:03] <ScottK> 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.