[00:06] general packaging question: if, for the sake of argument, you have a source package which produces multiple binaries, and the install list for one of those binaries is empty, is that package just skipped entirely? [00:06] i.e. if i put foo.so and bar.so into different binary packages, but foo.so only builds on one arch, is that a problem? [00:08] directhex: No and Yes. === blueyed_ is now known as blueyed [00:27] question about dpatch, how do I convert a normal patch to a dpatch? I am trying dpatch-edit-patch new.dpatch old.dpatch per instructions at https://wiki.ubuntu.com/PackagingGuide/Complete#Patch%20Systems, but no new.dpatch is created [00:34] sevenseeker: you can just add the usual boilerplate (at least "@DPATCH@" I think) and add it to debian/patches/00list [00:35] I think dpatch expect -p1 style diffs [00:35] ok, so if I have a normal style patch it will still work, just have to make sure it is p1 directory compliant? [00:35] and have the boilerplat [00:35] e [00:35] where do I add the @DPATCH@ at? [00:36] at the top [00:36] just look at some other dpatch using package [00:36] I see [00:36] ok, I am still hunting around :) [00:36] thanks guys, one other question [00:36] does dpatch also create new dpatches just like diff does? [00:36] I don't understand the question [00:37] if I want to create a new dpatch between two files or directories, how do I go about doing that? [00:38] just manually edit a normal patch as with this one already in existence? [00:38] a dpatch is just a regular diff/patch with @DPATCH@ on top [00:38] heh, ok... I thought it might potentially have more [00:38] thanks again, keep up the good work guys [00:43] hey azeem [00:43] heya [00:44] how goes it azeem [00:45] tiiired [00:46] just back from the pub [00:46] if I keep on going, I can just as well watch the debate in a couple of hours I guess :-/ [00:46] you? [01:20] azeem, run down FTBFS, trying to force lenny out the door === emma is now known as joe-the-plumber === joe-the-plumber is now known as emma [02:30] Anyone around to give a little insight on some bugs? There's been a significant uptick in bugs reported for kompozer in Intrepid, but the kompozer package itself hasn't changed at all, so it seems likely to be related to a dependency. [02:46] tonyyarusso: or more people using it. but yes, possibly a dependancy [02:47] Hobbsee: Fair point, but it's a Mozilla-related app that's based on what is now a VERY old base compared to Firefox and kin, so things are probably flat out missing. [02:48] tonyyarusso: Dunno if it's related, but the Firefox packages (with Firefox 2.0) was recently removed from Intrepid entirely. [02:48] And their locales and other bits [02:48] hmm [02:50] Blah. [02:50] ichthux-desktop still wants kio-sword [02:50] Well, here's what I have listed in the Depends: libatk1.0-0, libc6, libcairo2, libfontconfig1, libgcc1, libglib2.0-0, libgtk2.0-0, libidl0, libpango1.0-0, libstdc++6, libx11-6, libxft2, libxt6, zlib1g [02:50] The application apparently will build and run, but certain actions cause it to segfault. [02:51] tonyyarusso: Get a backtrace from it? [02:51] StevenK: I believe someone made one - lemme look quick. [02:52] StevenK: there are a couple of files on https://bugs.edge.launchpad.net/ubuntu/+source/kompozer/+bug/283400, but I'm not sure if they're what you're looking for. [02:52] Launchpad bug 283400 in kompozer "kompozer-bin crashes frequently when displaying menus (dup-of: 263441)" [Undecided,New] [02:52] Launchpad bug 263441 in kompozer "kompozer crashes in intrepid" [Undecided,Confirmed] [02:58] StevenK: Do those look right or should I try to make one myself? [02:59] tonyyarusso: The first one doesn't [02:59] tonyyarusso: Install debug libraries and try and get a stack trace [02:59] okeydoke [03:27] howdy, I am updating a library package that went from a lib.so.6 to lib-7.so, how do I specify the shlibs file line for that library? Use a 0 for the 'version' field? [04:30] <_Andrew> Could anyone look at this and tell me why my dependencies can't be resolved? http://pastebin.com/d450e8afb [04:33] It's been some time since I used pbuilder, but that output looks normal so far - where's the rest? [04:34] <_Andrew> http://pastebin.com/d503b6f03 [04:36] <_Andrew> It says Aptitude couldn't satisfy the build dependencies [04:38] It does indeed. That's fairly strange. [04:40] Um, so I'm trying to collect a backtrace of something, but it's not actually quitting completely. [04:40] Run it in gdb? [04:40] There's a segfault, which shows up in the terminal with gdb, but the process hangs and I end up having to use 'kill' to get things done. [04:40] Or attach to it in gdb. [04:40] Hmm, what is it? [04:40] I attached while it was running, yes. [04:40] It's kompozer. [04:41] What does bt say? [04:41] Could be its signal handler dieing, thus giving nice recursion. [04:41] erm, could you be more specific please? [04:41] Type 'bt' in gdb. [04:42] wgrant: If Kompozer has a SEGV handler, they're even more on crack that I thought [04:43] StevenK: It has a K and a z in its name. What do you expect? [04:43] SDL does, so why not Kompozer? [04:43] Hah [04:43] wgrant: SDL is a framework, though [04:43] True. [04:44] There's some KDE people in here, I'm sure. Where in the name of all that is holy can I add a program to my session under 3.5? (Hint: Control Centre->Session Manager is a lie). [04:44] wgrant: working on getting to that point again - one sec [04:44] <_Andrew> Would this be because I have a package that doesn't exist? Depends on package1 or unknown package ? [04:44] <_Andrew> or would it just ignore the unknown package? [04:45] _Andrew: No, it'd die in the way you've seen if it was depending on a non-existent package. But libboost-regex-dev _isn't_ a virtual package, at least in Intrepid. [04:45] wgrant: http://pastebin.com/m50786a4 [04:46] <_Andrew> This is for hardy [04:46] <_Andrew> sorry I should have mentioned that [04:46] Oh. It looks Mozillary. I'm running away no. [04:46] s/no/now/ [04:47] It is a Mozilla stepchild, yes. [04:47] I get that reaction a lot....... [04:48] hey wgrant [04:49] _Andrew: So, it would seem likely that something's messed up in your pbuilder setup. Have you run 'pbuilder update' recently? [04:52] <_Andrew> same result [04:53] Care to pastbin the output of "pbuilder update"? [04:55] _Andrew: you have a warning that could explain your problem: W: /home/andrew/.pbuilderrc does not exist [04:56] Could you create that file with COMPONENTS="main restricted universe multiverse" in it [04:56] ? [05:04] fabrice_sp: That warning isn't a problem. [05:11] ScottK: I know that it isn't a problem, but I had a similar dependency problem, and it solved it. In this case, the missing lib are in main, so it shouldn't help. You're right === fabrice_sp_ is now known as fabrice_sp [05:18] fabrice_sp: No, I mean lack of a per user config file isn't a source of problems. Not having a .pbuilderrc isn't wrong if the right options are set elsewhere [05:20] ScottK: sure. In this case, as it seems that it's his first use of pbuilder, I assumed that he could miss that other options, so creating .pbuilderrc with the right options could have helped [05:23] <_Andrew> RAOF: Well, I can't figure out why this is, I didn't change any of the dependencies from the package. [05:24] <_Andrew> I don't think it's pbuilder.. [05:24] <_Andrew> http://packages.ubuntu.com/hardy/libcegui-mk2-1 [05:25] <_Andrew> I took that package [05:26] <_Andrew> ah I think I know [05:27] <_Andrew> no universe packages [05:29] <_Andrew> yep that it, hehe woops.. [05:29] <_Andrew> thanks guys === lacqui_ is now known as lacqui [06:58] good morning [08:11] hey dholbach [08:12] hi NCommander [08:13] how goes it dholbach [08:13] good good, how 'bout you? [08:39] mornin'! [09:49] morning :) [09:56] huhu sistpoty|work :) [09:56] hi sebner [09:57] hey sistpoty|work [09:57] hi NCommander [09:57] sistpoty|work, how goes it? [09:58] NCommander: quite good [09:59] sistpoty|work, that's good. I'm working to improve REVU. We now have trustroot status [10:00] (or in other words, go try logging in on REVU and see the new message ;-)) [10:00] what's that? trustroot? [10:03] laga_, it means REVU can pull trusted information over openid such as email addresses [10:03] NCommander: excellent! [10:04] laga_, go try logging in on REVU,a nd take a close look at the text [10:04] There is a message from canonical on it ;-) [10:18] sistpoty|work: So, why haskell-devscripts from *testing*, we sync from unstable? [10:19] StevenK: because I haven't looked over the changes that are in between testing and unstable yet [10:19] sistpoty|work: I'm not sure that I can sync from testing [10:19] hm... [10:19] StevenK: give me a few minutes, to look at what changed, ok? [10:23] StevenK: I've requested it before and it was done [10:23] james_w: Shh! [10:23] :-P [10:23] :-) [10:25] StevenK: haskell-devscripts 0.6.14 is likewise sane :) [10:25] sistpoty|work: Please comment on the bug [10:26] StevenK: done [10:39] hm. i need to refresh an autoreconf patch [10:47] directhex, have you made the necessary sacarifies? [10:47] NCommander, i've decided to work on a different package and pretend this one doesn't exist :) [10:48] you gave up on mono ;-)? [10:49] meebey is working on mono. [10:49] i've done gluezilla, libgdiplus, and mono-basic [10:51] http://monoport.com/37751 [10:53] thankfully, the 2.0 components i've done so far don't actually need 2.0 to build/install === sistpoty|work changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Intrepid Feature Freeze: https://wiki.ubuntu.com/FreezeExceptionProcess | https://merges.ubuntu.com/universe.html | QA targets available from http://qa.ubuntuwire.com | TODAY - Steady on: we're in FinalFreeze (aka ReleaseFreeze)! | Next MOTU meeting: Fri, October 3rd 12:00 UTC === asac_ is now known as asac [11:03] Hi all, does every upload now require motu-release ACK? There have been possibly conflicting statements [11:03] james_w, For hardy, we did it that way post-final-freeze. [11:04] james_w, Generally, my experience is that someone glances at the debdiff, and says "sure", assuming it's small and prevents an SRU. [11:04] (or otherwise does something critically good) [11:05] oh yeah, I know it's a smooth process usually, I'm just wondering whether I should start bugging members of the release team yet [11:05] james_w, Note that I've not yet received the freeze mail, so you might have a couple hours left before that applies. [11:05] * persia hopes so, as the timidity debdiff isn't exactly small [11:05] I've got Steve's, and the archive is frozen [11:05] james_w: a IRC ACK is usually enough (they did so for hardy) [11:06] Ah. I do have it, I just hadn't pulled my mail in an hour :( [11:06] and the mail he pointed to from the hardy release suggests that everything now requires approval [11:06] but the other day in response to my question about universe for "RC freeze this Thursday" Scott said [11:06] "I don't think it means anything more than the other freeze have meant. The [11:06] weekend before the final freeze we'll want to start approving all uploads. [11:06] Exactly when is dependent on when Ubuntu Release intends too final freeze." [11:07] Well, this is final freeze, so this would be the beginning of that weekend. [11:07] yay for slipping a final mono release out of the door, then [11:07] ok, I'll request exceptions, thanks [11:10] james_w: I don't think you need to do that. [11:11] really? [11:11] ScottK, What's the policy for FinalFreeze then? [11:11] I faintly recall that it is usually the final week that is universe FinalFreeze, but it happens so rarely that I can't remember. [11:11] next MOTU meeting is a fortnight ago? /topic needs a poke [11:12] persia: Final freeze would be the one before release, not before RC. I'm rereading the referenced mail and will work on a clarification. === persia changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Intrepid Feature Freeze: https://wiki.ubuntu.com/FreezeExceptionProcess | https://merges.ubuntu.com/universe.html | QA targets available from http://qa.ubuntuwire.com | TODAY - Steady on: we're in FinalFreeze (aka ReleaseFreeze)! | Next MOTU meeting: Fri, October 17th 20:00 UTC [11:12] that's better :) [11:12] ScottK, The freeze applied today is the last freeze listed at https://wiki.ubuntu.com/IntrepidReleaseSchedule [11:13] see, this is why I request a mail stating the policy from the release team [11:13] RC and FinalFreeze were at the same time in previous cycles : I think FinalFreeze got moved up one week this time. [11:14] jaunty debianimportfreeze is ~xmas, then? [11:14] Right. I'll work on clarification. [11:14] directhex, Somewhere around there. [11:14] directhex, Might even be as late as mid-january, depending. [11:14] persia: Ahh, that makes more sense. [11:14] I didn't think FinalFreeze was so long. [11:15] wgrant, Except it doesn't match wiki history. It appears FinalFreeze was introduced in Hardy, and was a week before RC. [11:15] (10th April) [11:15] Hrmph. [11:17] Anyway, I still want to push bug #281276 and various timidity stuff. Do I need explicit permission from someone? [11:17] Launchpad bug 281276 in linux-rt "Upgrade linux-rt to 2.6.27" [Undecided,New] https://launchpad.net/bugs/281276 === tbielawa is now known as freebot === freebot is now known as fsgbot [11:19] sistpoty|work, TheMuso, DktrKranz, (and norsetto if you show up): I just sent mail to the MOTU list asking about when we start approving all uploads. Please read and reply. [11:28] ScottK: replied, thanks [11:36] persia: for -rt stuff, linux-meta-rt needs some adjustments too (IIRC, there are packages pointing to *-restricted-extra which are not available). [11:37] DktrKranz, Yep, and something needs to depend on linux-firmware. I believe Alessio is planning to finalise everything tonight (in light of KernelFreeze). [11:37] persia: good. I sponsored uploads of it, if needed just give a shout [11:38] dholbach, persia, geser, nixternal, soren: what is the hold up on smarter's MOTU application? [11:38] DktrKranz, I'll probably upload it when it's done : I just want to make sure I've gotten any required approvals. Kernel team did a preliminary recently, so I'm feeling pretty good about stability. Regression risk is nil as the current -rt doesn't work at all. [11:39] persia: thanks (from a linux-rt user POV) [11:40] apachelogger: afaics only nixternal and I voted +1 up until now - I'll prod the others again to vote [11:40] apachelogger, Just the usual extreme slowness. Waiting for three more MC comments. [11:41] :) it's been > 12 days already https://wiki.ubuntu.com/UbuntuDevelopers#MOTU [11:42] apachelogger, Yeah. The 12 days bit was something that nobody ever accepted as binding, unfortunately. [11:43] Maybe you could discuss this some time? Either it should be accepted as binding or removed from that page. [11:43] *nod* [11:48] sistpoty|work: Launchpad provides no facility to freeze just some components. [11:48] wgrant: ah thanks [11:49] gmoin [11:50] motu-release: thanks for the speedy establishment of a clear guideline. === sistpoty|work changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Intrepid Feature Freeze: https://wiki.ubuntu.com/FreezeExceptionProcess | https://merges.ubuntu.com/universe.html | QA targets available from http://qa.ubuntuwire.com | TODAY - Steady on: we're in ReleaseFreeze, be extra careful when uploading | Next MOTU meeting: Fri, October 17th 20:00 UTC [11:52] Mightn't it be best to put that up the front? [11:53] And merge it with the FF item. [11:53] That should improve readability, at least [11:53] And perhaps drop MoM, as the topic is overly long now. [11:53] or maybe even drop it altoghether? [11:53] * sistpoty|work tries again === sistpoty|work changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Intrepid Feature Freeze: https://wiki.ubuntu.com/FreezeExceptionProcess | QA targets available from http://qa.ubuntuwire.com | Next MOTU meeting: Fri, October 17th 20:00 UTC [11:54] hm... [11:54] As there are no further restrictions in this freeze, that should be OK. [11:54] otherwise I'll leave it to whomever has better ideas :) [12:38] @motu-release: OK to upload this vlc update: http://paste.ubuntu.com/58308/ to intrepid? [12:39] according to sistpoty's mail at https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html it is okay to ping you on irc [12:40] siretart: we're not yet in final freeze for universe/multiverse, so only "normal" feature freeze applies [12:40] siretart, According to https://lists.ubuntu.com/archives/ubuntu-motu/2008-October/004849.html you don't have to ask until next week. [12:40] hi siretart btw. ;) [12:41] ah, then I misread steve's mail. great [12:41] heyha sistpoty|work! hi persia [12:41] siretart, Hi :) And no, you didn't misread the mail, the policy was just updated *very* recently. [12:42] persia: ah, I see. perhaps a followup u-d-a would prevent further confusion? [12:42] is there a wiki page which explains the policy? i don't want to read hundreds of different opinions on the ML, just the definite point [12:43] laga_, No. [12:43] laga_: http://wiki.ubuntu.com/UbuntuDevelopment [12:43] if something is missing there, I'd consider it as a bug [12:44] (including the referenced wiki pages from there) [12:44] by "explains", i meant a page that simply states the current policy [12:45] Hrm. Good point. [12:45] it shouldn't be an insider only thing :) [12:46] laga_, It's very much not an insider-only thing. It's just that nobody has yet taken the recent decision from the mailing list and put it in the wiki. If you did that, I'm sure your efforts would be appreciated. [12:49] is bzr 1.7 going to hit intrepid? [12:51] It's unlikely at this point, unless someone gets special approval. I haven't heard of a special bug. === nhandler_ is now known as nhandler [13:01] I think it might be a good idea, particularly as bzr isn't well known for regressions, and LP seems to want bzr 1.7. And bzr 1.7 is fast. [13:04] james_w, Any guidance from upstream on which bzr for intrepid? [13:04] But it's in main, so it's not likely. [13:05] they would probably like 1.7, but it was released after feature freeze and I didn't push it [13:05] as long as we are >=1.6.1 it's a good start [13:05] james_w, OK. Do we lose compatibility with LP the way we did in hardy with 1.3? [13:06] not 1.6->1.7 [13:06] can't speak for the future though [13:07] Understood. 1.6 -> 1.7 is the interesting part, as it would fall into RC land. [13:09] I'll probably be organising backports of some version to hardy, so I could do the same for Intrepid [13:13] Hey, what's the feature-freeze for jaunty>? [13:14] lfaraone, Probably sometime in February, although the schedule is yet to be established. [13:15] persia: crap. [13:15] !ohmy [13:15] Please watch your language and topic to help keep this channel family friendly. [13:15] persia: the project I'm packaing for releases march 3rd. [13:15] lfaraone, That aside, why? [13:15] (sugar) [13:16] lfaraone, That might not be an issue if you plan well. Make sure the snapshots make FeatureFreeze, and you should only have bugfix updates for the last few weeks. [13:16] (at least assuming sugar follows a features-first-then-bugfix development model) [13:17] persia: yeah, RC comes out feb 13th, and betas are as early as dec 21 [13:18] lfaraone, You might be a bit tight on RC, but going from RC to final is just a matter of helping the sugar team not add any features post RC. [13:20] persia: Bad news: debian upstream maintainer is slow to package. Would we be able to send in updated versions bypassing debian if they will be too late? [13:21] lfaraone, Yes, although perhaps working with the Debian maintainer to collaborate would be better. [13:22] persia: we'll send him our patches :) [13:22] lfaraone, Rather, you might want to engage in a deeper dialogue to collaborate. === LucidFox_ is now known as LucidFox [14:23] stefanlsd: hi, I still can''t install bugzilla [14:24] stefanlsd: http://paste.ubuntu.com/58348/ [14:33] james_w: is this within a pbuilber or chroot? [14:33] yeah pbuilder chroot [14:37] james_w: i suspect it may be related to that. Did you get the debconf dialog stuff? [14:38] stefanlsd: yeah [14:38] I told it not to use dbconfig-common [14:42] wgrant: k. im getting the same thing. i will investigate [14:42] bleh [14:42] james_w: ^ [14:46] ScottK, DktrKranz, TheMuso: I'm just about to post a follow up about current universe/multiverse freeze handling: http://paste.ubuntu.com/58351/ [14:46] * ScottK looks [14:47] any corrections? anything I missed? [14:47] sistpoty|work: I'd add a mention that the last opportunity for uploads will likely be sometime next weekend depending on when ubuntu-release decides to freeze the archive solid. [14:48] What's there is good. [14:49] Will we still be able to push RC stuff post solid-freeze for unseeded stuff, or are we not doing that this cycle? [14:50] * DktrKranz looks too [14:51] persia: unlikely. [14:51] persia: (dak import) [14:51] sistpoty|work, Could you put a note in there about the universe flavours? CD testing is happening next week, and it'd be unfortunate to break something. [14:52] Hobbsee, Hrm? [14:52] persia: the final, solid, no more packages accepted freeze? [14:52] no, you cant' push packages after that ( a couple of days before release) [14:52] prior to that, *shrug* [14:52] Hobbsee, This is new. I've previously pushed until about 2 hours before a release. [14:53] persia: nwo that would be odd - usually the import is started way before that. [14:53] unless it got pushed to -updates or something [14:53] No, into the main repos. [14:53] persia: I think you are mis-remembering. [14:54] * Hobbsee agreeswith ScottK - and suspects persia also doesn't mean the final release. [14:54] Or perhaps I have the time of release wrong. [14:54] The last two releases, the final uploads happened on Sunday or Monday before release. [14:54] I remember pushing the aolserver4 changes *very* late. [14:54] I remember that and it was before the archive froze, not release. [14:57] Yeah. That was Monday night (~13:00 UTC). I am misremembering. [14:59] next try: http://paste.ubuntu.com/58354/ [14:59] slangasek: is final release scheduled directly at oct 30th? (not that I give wrong dates in the follow up *g*) [15:00] * ScottK notes that http://qa.ubuntuwire.com/bugs/rcbugs/ is working again and it's a good place for people to look for easy wins. [15:03] if no one has responded to bugs that I reported few days ago, what should I do ? [15:04] AnAnt, Not much you can do, except wait. If you think it's critical, and you have some ideas, you could see if anyone wants to talk about it. [15:04] sistpoty|work: two/four, but otherwise good. [15:05] sistpoty|work: bug 257110 [15:05] Launchpad bug 257110 in libgems-ruby "libgems-ruby1.8 conflicts with rubygems1.8" [Undecided,Confirmed] https://launchpad.net/bugs/257110 [15:05] sistpoty|work: when you reverted, did you revert the previous upload in its entirety? [15:05] is bug 281696 critical ? [15:05] Launchpad bug 281696 in compiz "Compiz core dumps in Intrepid" [Undecided,New] https://launchpad.net/bugs/281696 [15:06] james_w: yep, that's what I did [15:07] persia: I have that feeling that you didn't try sl-modem yet [15:08] AnAnt, It may be for certain hardware, or if it affects many users. I'd ask about that in #ubuntu-desktop [15:08] And you'd be right about sl-modem :) It's on my to-be-tested list, and about #5, but not quite at the top. [15:09] ok [15:10] ah, it's in NBS [15:10] anybody want to teach me about how to clear a package from NBS? [15:10] sistpoty|work, Oh, and thanks for adding the note about the flavours. Looks good to me. [15:11] james_w, I'd be happy to in ~20 minutes, if nobody else does. [15:11] persia: great, I'll go get lunch in the mean time [15:12] james_w: The short version is figure out what's in the archive that depends on it and make the dependency go away. [15:19] nhandler: man those encoding errors will get me mad :P === dholbach_ is now known as dholbach [15:26] good morning everyone [15:27] I am updating a library package where the numbering of the so lib changed from something like foo.so.1 to foo-2.so, how can I use a foolib.shlibs in my package in that scheme? [15:31] sistpoty|work: Would you be able to help me with a library package update? I have a new upstream that has a bunch of important fixes, but also bumped the minor version of the soname. I'd like an expert review to see if it's potentially sensible to include in Intrepid. [15:31] ScottK: sure [15:32] sistpoty|work: The package is libspf2. You can grab the Intrepid on and I'll put the candidate somewhere you can get it. One moment. [15:35] sistpoty|work: http://kitterman.com/test/libspf2_1.2.8.dfsg-0ubuntu1.dsc [15:37] ScottK: wow, that's a huge diff... might take a while to review [15:38] sistpoty|work: I'm not asking for a full source review, but just the abi/api. Is that huge? [15:39] ScottK: well, this also means to review the headers... [15:42] Ah. Well from what I can tell the package was fairly broken before in a number of subtle ways. It'd be good to get it in if we could. [15:43] ah, I found https://wiki.ubuntu.com/UbuntuDevelopment/NBS which is pretty good [15:44] james_w, That's the output of my last session :) Let me know if you have questions. [15:44] ah, cool [15:44] nice work [15:45] Much of the credit goes to the wiki editors : it started as an IRC log. [15:46] turns out this one is dead simple [15:46] persia: do you know how I would package a lib that is named foo-1.so with no version at the end for the libfoo.shlibs file? [15:47] sevenseeker, Only very vaguely : shlibs generally confuse me. Generally, you want a versioned .so anyway, as otherwise things tend to break. [15:48] sevenseeker: The versioning is pretty much essential. [15:48] persia: I am not that familiar with the build practices in regards to naming conventions, could I change the make file to generate one with a version? [15:48] for example, it is actually foo-1.5.11.so, could I rename to foo-1.5.so.11? [15:49] persia: I assume the package in question being in "|" group in Depends won't keep it from being removed? [15:49] sevenseeker: No. [15:49] james_w, In cases like that, sometimes it's helpful to give a hint to the archive-admins. Once you clear an entire set, just mention in #ubuntu-devel that something can be NBS'd. [15:50] broonie: james_w: thank you for your feedback [15:50] looks like I should deal with the upstream guys or just ignore shlibs for now :( :( :( [15:50] sistpoty|work: I have upstream on another IRC channel if you have questions. [15:50] The latter is a recipe for pain. [15:50] ScottK: nope, haven't got questions yet... still reading ;) [15:50] OK. [15:51] sevenseeker: Yes, SONAME really needs to come from upstream since it should ideally be consistent over all distibutions, not just Ubuntu. [15:51] broonie: I am glad you confirmed that [15:58] ScottK: though I've only read through the header diffs right now, I think there is a tiny ABI incompatibility [15:58] sistpoty|work: OK. Would you mail/paste me details? [15:58] ScottK: in one structure, an int is replaced with a size_t, which has a different storage size on amd64 at least (didn't know that myself yet ) [15:59] sistpoty|work: I think that's a bug fix. [15:59] ScottK: there: http://paste.ubuntu.com/58378/ [15:59] Did you look in our patches to see if we'd patched it (I will if you didn't) [16:00] ScottK: even if size_t looks more correct, that still breaks the abi [16:00] ScottK: nope, haven't done that yet [16:00] OK. I'll look [16:00] hm... I guess that's why I dislike patch systems *g* [16:02] ScottK: there's also one in /src/include/spf_request.h [16:02] change from int to size_t [16:03] The one you pastebinned we already patched, so it's no change [16:04] The second one we didn't patch, but should have. [16:05] sistpoty|work: So I can check the source of the rdepends to see if they use that include, right? [16:06] ScottK: yes [16:06] OK. Is that the only one or are you still looking? [16:07] I'm guessing it didn't get patched because no one used it and no one complained, but I'll look. [16:07] ScottK: that *seems* to be the only one, but I haven't looked at symbols yet [16:07] OK. [16:08] * ScottK waits with baited breath ... [16:08] ScottK: most probably you'll want to grep any rdepends if they create/use a SPF_request_t somewhere [16:09] Heya folks [16:09] ScottK: because that would then be 4 bytes too small on amd64 :( [16:09] hi bddebian [16:09] Heya sistpoty|work [16:10] ScottK: Ideally, libspf2 would have an SONAME bump upstream-wise [16:10] ScottK: but in the lack of it, I'm quite assured that rdepends will still build [16:10] It went from 2.0 to 2.1 IIRC [16:11] ScottK: but the name of the binary package didn't change? [16:12] sistpoty|work: Because I didn't change it. [16:12] ScottK: ah, then I guess you'd better change it ;) [16:12] Hi bddebian [16:13] Heya geser [16:13] sistpoty|work: Yeah. I'm not ready to upload it yet. I'm trying to get this sorted to see if I can. [16:13] ScottK: then, I don't even need to look at symbols, since rdepends would still need a rebuild [16:15] nxvl: and porthose : hey [16:16] sistpoty|work: Well I'd like to know if it's sane to think it'd work. Also what should I name the new binary package? [16:16] huats: hey [16:16] ScottK: what lintian tells you to ;) (it should reflect the soname) [16:16] the rules are somewhere in the library packaging guide, but lintian also knows the bits [16:17] huats: i'm ok with the date [16:17] :D [16:18] nxvl: porthose so it is now right ? [16:18] :) [16:18] huats: yes, channel? [16:18] -meeting :) [16:18] huats: :) [16:18] sistpoty|work: OK. IIRC it didn't complain about the old name. [16:19] is it ok to include three .desktop files in one package or should it be split into 3 packages? [16:20] one for kubuntu, xubuntu and gnome.. [16:21] csilk: why do you need different .desktop files? [16:21] csilk, Unless you're *really* careful with OnlyShowIn, you might want three. Often you want to split the frontends anyway, so people don't have too many dependencies. [16:22] persia, ok three packages it shall be [16:22] this is the kind of info the wiki lacks [16:22] ScottK: do you happen to have an amd64 binary of the new package? (then I wouldn't need to build it myself) [16:22] csilk, It's actually a fairly uncommon question. I've seen it asked thrice since I've been following IRC. [16:23] sistpoty|work: No. All I have it i386 [16:23] ok [16:23] sistpoty|work: It's a quick build. [16:23] persia, yeah I usually wouldn't bother but upstream is insisting the packages works just as well in kubuntu and xubuntu as it will in gnome [16:23] *work [16:24] csilk, Wait. How do the .desktop files differ? [16:25] <_Andrew> Is there anyone around that can help me? My ppa won't compile because the build machines aren't installing the packages. [16:25] _Andrew: hi, point me to the broken buildlog [16:25] <_Andrew> ok 1 sec [16:25] persia, at the moment they don't as I haven't started on them [16:25] <_Andrew> did you want a url or package name? [16:25] _Andrew: url [16:26] <_Andrew> http://launchpadlibrarian.net/18603984/buildlog_ubuntu-hardy-i386.ogre_1.6.0~ppa2_MANUALDEPWAIT.txt.gz [16:26] _Andrew: nvidia-cg-toolkit is trying to download stuff. [16:26] <_Andrew> It fails when it trys to install nvidia-cg-toolkit . [16:27] <_Andrew> yeah, so how can I get it to install the toolkit [16:27] persia, the only difference in them should be icon and menu population related things [16:27] csilk, OK. Unless you're generating different binaries for the front-ends, there's usually little point to adjusting the .desktop files. If you are generating different binaries, then you need it, of course :) [16:28] Why a different icon? [16:28] And the menu population should be the same : they are all XDG-compliant environments. [16:28] I assumed the way you would popualte a kde menu would differ from gnome? [16:28] _Andrew: soyuz builds are explicit forbidden to access external sources. I don't know exactly what motu guys does to workaround this and the related legal issues involved. [16:29] csilk, It shouldn't. [16:29] in that case I wouldnt need more than one .desktop file would I? [16:30] Unless you have different front-ends, or you need to pass some argument to hint at the interface, you shouldn't. [16:31] No, the front end should be consistent accorss all the distros [16:31] <_Andrew> oh.. Then who can I talk to, to get it working? [16:31] *across [16:31]