[01:00] Where can I find info on the Ubuntu ISO build process -- how a Ubuntu desktop CD gets created from a package list and pointers to repositories? Debian has live-helper, which sort of works for Ubuntu, but doesn't seem to be "the official way". Is there a wiki page or a package or *something* that I can look at to see "how Ubuntu generates its official ISOs"? [01:02] jmarsden: live-cd rootfs generates the live filesystem for the iso. i don't know where the scripts live that actually generates the iso from that, though [01:02] OK, that's a start, thanks. [01:04] if you're trying to build your own livecds, https://help.ubuntu.com/community/LiveCDCustomizationFromScratch is good and is "close enough for government work" to what ubuntu generates [01:14] hrm... I'm trying to do a redirection in a bash for loop and the shell keeps giving me the > prompt like it wants more... I guess it is interpreting the > early rather than as the body of the for loop... I tried escaping it with \ and that did not help [01:16] nevermind... must have had a typo === yofel_ is now known as yofel [01:24] jmarsden, More comprehensively: the the seeds are processed by launchpad to generate tasks with cron.germinate, and the tasks are used in livecd-rootfs to build the life filesystems. The live filesystems are embedded into the images with debian-cd (check the branch on LP, not the package: the package is unmodified in Ubuntu) [01:25] The images are then built using ubuntu-cdimage (check LP for branches), but this is just a collection of cronjobs and utilities that drive debian-cd. [01:26] persia: Thanks :) germinate I know of, debian-cd I did not know about until you mentioned it :) [01:28] jmarsden, At a high level, what are you trying to accomplish? A remix? A new flavour? Troubleshooting an issue? Just tweaking images? [01:29] Troubleshooting an issue with the latest Lubuntu Alpha2 (checksum mismatch) and also hopefully understanding this enough to help Julien with Lubuntu until such time as it is official enough to use Ubuntu build infrastructure. [01:30] persia: So my goal is to see if I can duplicate "how Ubuntu does it" locally, as a first major step. [01:30] Right. I've been procrastinating about Lubuntu too long. I'll put something on the wiki (note that it will only be draft) [01:30] Thanks :) [01:31] "How Ubuntu Does it" gets a little complicated: livecd-rootfs runs in a natty environment on target architecture, but debian-cd runs on lucid on i386. [01:32] Hmmm.... OK... well, I use virtualbox VMs quite a bit, maybe I need to get into kvm instead to set this all up. [01:32] I think the natty environment is essentially a buildd chroot. [01:33] Well, with some extra packages installed. [01:33] And, unless something is going wrong, it oughtn't matter that debian-cd is running on lucid, because it's branch code anyway. [01:34] (sometimes things do go wrong: I remember backporting some boot thingy to hardy at one point to fix one of them) [01:35] OK. My primary workstation here is Lucid... so it sounds like I should do the livecd-rootfs stuff in a Natty VM to be safe? [01:37] I'd suggest a natty chroot. [01:38] If you have ubuntu-dev-tools installed, `mk-sbuild natty` may be enough (I forget if that was lucid or maverick) [01:38] If that doesn't work, pbuilder is probably the best quick choice. === Amaranth_ is now known as Amaranth [04:10] broder: hey, for package description guidelines https://wiki.ubuntu.com/SoftwareCenter/PackageDescriptions is the start [04:12] broder: we still need to co-ordinate with debian to get their guidelines updated, the person in-charge of that task retired from Ubuntu, so I'll have to pickup the tasks or find someone who is free.. [04:12] thanks, that's helpful [04:12] np.. [04:14] vish, If you're involved in that, could you encourage folk to get descriptions to also meet the following two guidelines: [04:15] 1) The short description should complete the cloze "${PACKAGE} is ${SHORT DESCRIPTION}" [04:15] 2) The long description should provide enough information, even if the package name and short description are not presented. [04:16] * micahg thought having the package name in the short description gives a lintian error [04:17] micahg, It does. It can be confused by capitalisation changes, etc. [04:17] persia: why does short description have to repeat the package name? [04:17] * vish curious.. [04:17] It doesn't. [04:17] It completes the cloze. [04:18] and what does "cloze" mean ? :) [04:18] It should not include the package name, or any copula, but rather assume both will be presented by the package manager. [04:18] clause :) [04:18] No, cloze [04:18] http://en.wikipedia.org/wiki/Cloze [04:19] yea, i dint expect persia making two consecutive typos :) [04:19] One is indeed common though :) [04:20] persia: the second is already dictated by Policy, i think [04:20] So... the short description "is an exercise, test, or assessment" ? [04:21] broder, Both are dictated by policy. Sometimes the folks that put together the user experience specifications aren't intimately familiar with policy. [04:21] yea, the (2) is is given, long descriptions are not meant to depend on the short description, but i dont see any harm in adding that guideline.. [04:21] * vish still trying to understand (1) [04:21] So, let's say I have a package lksdf [04:21] vish: it means the short description sholud be something like "a tool to do foo", so that if you stick "PACKAGE is" before the short description, the whole sentence makes sense [04:22] ah! [04:22] And I want the description to be "lksdf is a utility to render any text meaningless" [04:22] So, I need to have a short description "utility to render any text meaningless" [04:22] or "a utility to render any text meaningless" [04:23] persia: yea, right, that is what is already mentioned in the guidelines [04:23] or was ? [04:23] I didn't see it in a quick read. I'll look again. [04:23] let me check, but i recall discussing that with mpt, he dint want the package name repeats in the description [04:24] In the long description? [04:24] vish: lintian should yell at you if you do that [04:24] Not all the package managers show the package name when showing the long description. [04:24] broder, No, lintian only complains about the short description. [04:24] ah, sure [04:25] * micahg keeps learning new words from persia [04:25] yea, long descriptions, in some of the description i updated last cycle, i made sure the descriptions are in line with your (1) [04:25] * persia learned "cloze" in this channel years ago. [04:27] I'm not that fussed about whether long descriptions have the package name, but I don't think it's easy to write a paragraph or two about anything without naming it, unless one uses "this package" or "it" a lot, which I think is stylistically poor. [04:28] persia: in the avoid section, the "this package" one.. too many long descriptions start with that, but yea, it is not as clear as you mention [04:29] Saying "lksdf was written to provide auto-generated text with similar character frequency, average word length, and paragraph breaks to original text, while obscuring the original text, for use in typesetting and visual design applications." seems better to me than forcibly trying to avoid using the package name when describing it. [04:29] yup, http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis first line is your (1) [04:35] more than the package name, the descriptions starting with "this package" were the offending one.. [04:35] Indeed. Those are bad. [04:36] It is because of those that my rule (2) exists. [04:36] (not that it's my rule, but that I numbered them) [04:38] i think we would need to update the debian guidelines too, http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-desc mentions " Assume that the user has already read the package synopsis." [04:39] which does not necessarily mean long desc needs to depend on the short, but having that line is misleading.. [04:40] That's just guidelines. Not ideal, but easily worked around. http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions is the bit to ensure you aren't violating without deep discussion. [04:41] Changing the guidelines may be as simple as filing a bug, and following up on it. [04:41] broder, And it appears we're both wrong: rule (2) above isn't mandated by policy, although rule (1) is somewhat implied by policy. [08:12] Hi, is a new packages with need-packaging tag must subscribed to ubuntu-sponsors? [08:12] a source already landed in revu [08:12] Is the packaging complete? If so, sure. [08:12] Or you can ask for a review here. [08:12] Which package? [08:12] persia, yup complete [08:12] wait.. [08:13] persia, gkamus [08:13] http://revu.ubuntuwire.com/p/gkamus [08:13] http://revu.ubuntuwire.com/p/gbilling-client [08:14] http://revu.ubuntuwire.com/p/gbilling-server [08:17] udienz: For gkamus debian/docs contains "NEWS" and "TODO" which just aren't interesting for end-users. I'm suspicious that README is similarly uninteresting. [08:19] ah.. ok. so it's better to removing d/docs? [08:19] Or just don't create it in the first place :) [08:19] I can't read README, so it might be interesting, but I suspect you'd do better to extract the interesting bits into debian/README.Debian [08:21] persia, ok, i'm writing in english in d/README.Debian [08:21] Also, you've Debian-style versioning. You want -0ubuntu1 if you're going straight to Ubuntu. That said, this happens to be a great time to upload to Debian. [08:22] I'd recommend fiddling with dversionmangle in debian/watch for gbilling-client: this would be better with version 0.3.1~rc1-1 [08:23] udienz: I'm commenting on revu for gkamus [08:24] udienz: For both of them, I'm not sure why you need debhelper >= 7.0.50~ when you're using CDBS. [08:26] persia, i'm not tested this packages in debian, so i'm not confident to uploading to debian [08:26] gbilling-server has all the same points as gbilling-client. [08:26] i will ask debian-id to testing [08:27] micahg, thanks [08:27] Heh, makes sense. It ought work about the same. [08:28] persia, and about debhelper it must be 7? [08:28] I don't know why you need debhelper 7. [08:28] Most CDBS packages do fine with debhelper 6. [08:29] But it doesn't matter how you do it, as long as you know why you are doing it that way. [08:30] udienz: generally debhelper >=7.0.50~ is used the dh short for overrides are used [08:30] s/the/when [08:36] micahg, what lintian option you used? i use -iIEv --pedantic *.changes before i uploading to revu and i not got an errors [08:37] udienz, Did you build a binary and run it the binary changes as well? [08:37] udienz: on the source or binary changes file? [08:37] source is lintian clean, binary is not [08:37] persia, yes. in ppa and running very well in my laptop [08:38] udienz, But did you run lintian on the binary? [08:38] micahg, source ah.. thanks [08:38] persia, no sorry. i will fixing it [08:39] No need to apologize: that's why we do reviews :) [08:39] We all make mistakes, especially when packaging something new, because there's so many things to think about. [08:40] hehe [08:52] Did anyone attend http://www.fosdem.org/2011/schedule/event/opengazer_dasher last weekend? [08:56] The upstream website I found seemed to indicate it was deprecated, but with the talk, I wonder if I'm just looking in the wrong place. [09:08] I had ubuntu 9.04 installed on a windows xp partition. I upgraded directly to 10.10. Post installation I was prompted to restart. Upon boot I immediately get to a screen resembling windows command prompt. The error on screen is 'no such device : 9f5f4016-f31a-4af6-852f-4502712a528f. Then the next line is grub rescue> [09:08] I can access BIOS but can't even access the selection to boot winxp [09:08] This isn'T a support channel: you might try #ubuntu. [09:09] In general, the recommended upgrade path would be 9.04 -> 9.10 -> 10.04 -> 10.10 [09:09] oops thanks :) [09:09] You might get away with 9.04 -> 10.04 -> 10.10, but no effort has been spent checking or testing 9.04 -> 10.10. [09:38] ari-tczew, around? [09:38] udienz: yea. hi. [09:38] ari-tczew, Hello.. [09:39] about bug 717654, both CVE already apllied in debian unstable [09:39] Launchpad bug 717654 in squid3 (Ubuntu) "Please merge squid3 3.1.6-1.2 (universe) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/717654 [09:39] ubottu: I saw and I'm looking on squid3 right now :-) [09:39] Error: I am only a bot, please don't think I'm intelligent :) [09:41] udienz: open your debdiff and look on line 25 [09:42] this is a change in d/changelog [09:42] it's wrong [09:42] lines 25-34 === almaisan-away is now known as al-maisan [09:43] you can remove it manually before submitting debdiff on launchpad [09:44] ari-tczew, ok [09:47] udienz: I won't require forward a patch to Debian since there is new upstream available and I'd like to see fixed FTBFS on new tarball. [09:48] ari-tczew: you should still upstream it and let Debian fuzz it when applying to the new upstream [09:48] micahg: still upstream it? sorry, I don't understand [09:49] ari-tczew: FTBFS patch? [09:49] micahg: do you mean forward to upstream? [09:49] ari-tczew: forward the linker fix to Debian anyways, no need to wait for new upstream version [09:49] Or forward it to Debian: warn the maintainer that they may have to do some work when importing the new upstream. [09:51] udienz: OK do it what they say above ^^ [09:51] but personally I disagree [09:52] ari-tczew: Why? [09:52] ari-tczew, i'll send it [09:53] persia: I have a lot cases when new upstream has got fixed FTBFS or FTBFS message was another than fixed in old tarball. [09:53] I had * [09:54] Oh, sure. They key thing is that there is a potential issue, not that there is a real and firm issue. [10:00] what is a symbol file and what is its use? [10:00] persia: when we will get to know new DMB crew? [10:01] ari-tczew: After the next meeting [10:01] c2tarun: https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols [10:02] ari-tczew, i send to debian and upstream [10:03] udienz: OK [10:09] udienz: I updated your debdiff and will upload it. [10:09] ari-tczew, ok thanks! [10:10] bp [10:10] np * === al-maisan is now known as almaisan-away [10:17] udienz: did you look on bug 690068 ? [10:17] Launchpad bug 690068 in erlang (Ubuntu) "Please merge Erlang 1:14.a-dfsg-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/690068 [10:18] ari-tczew, yes. i try to fixing it in early days [10:28] I found this line in manual of dpkg-shlibdeps "dpkg-shlibdeps calculates shared library dependencies for executables named in its arguments." what is meaning of executables here? [10:28] c2tarun: binary files that are run [10:29] c2tarun: ELF binaries, usually... things you can run [10:29] can you please give me an example? [10:29] /bin/ls [10:30] /usr/bin ;) [10:30] Right :) [10:31] Well, I have /bin/ls on my system here... [10:31] ari-tczew: /usr/bin is a directory :), not all files in there qualify (i.e. /usr/bin/firefox) [10:31] micahg: I know I wanted to fix directory of jmarsden's [10:31] ah [10:32] ari-tczew: type which ls and see what your system shows [10:32] ari-tczew: no, he's right :P [10:32] oO [10:32] but usually /usr/bin/* [10:32] :> [10:32] ok so dpkg-shlibdeps looks for the dependencies needed for buiding a package and add them to var file substvars. am I right? [10:33] but if there is no symbols files or shlibs files then? [10:33] c2tarun: Needed for *running* the executables in a package, I think. By the time it runs you have already built the package... [10:34] So the build deps are already installed... [10:34] jmarsden: I think the questions is about filling ${shlibs:Depends} in the binary depends [10:35] sorry I am not getting, what do you mean by running the "executables in a package"? [10:35] micahg: Right, so that is not something "needed for buiding a package", but something needed at package run time... [10:35] jmarsden: ah, right :) [10:36] c2tarun: if you have a package that compiles hello.c into hello and installs that as /usr/bin/hello, then dpkg-shlibdeps will check what shared libraries the binary file hello which you compiled needs. [10:36] c2tarun: For example, run ldd /bin/ls to see what shared libraries that program needs :) [10:37] This then populates ${shlibs:Depends} so that you don't have to fiddle with nm and set the dependencies manually. [10:44] jmarsden: ldd works fine and I am getting the list of dependencies. but I failed to find any file in /var/lib/dpkg/info/package.shlibs OR package.symbols [10:45] Not all packages currently in existence come with symbols files. Most likely coreutils does not provide such a file. [10:46] c2tarun: What is the real reason for all your experimenting with dpkg-shlibdeps ? What exactly are you needing to do? [10:47] jmarsden: I was reading this manual page on symbols https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols I fixed on upgrade bug and the one who sponsored my bug suggested me to use symbol files from next time as this may be useful for them. [10:48] OK. So the sponsor is telling you this would be a useful enhancement to that particular package. Not that all packages already have symbols files. [10:51] Only packages that supply shared libraries should have symbols files. [10:52] bug 713492 started all this [10:52] Launchpad bug 713492 in ccscript (Ubuntu) "Newer Version Available" [Wishlist,Fix released] https://launchpad.net/bugs/713492 [10:52] jmarsden: please check bug 713492 and second last domment [10:52] micahg: yup :) I was looking for that bug only :) [10:56] hm, transmission requires libevent version 2.x. in natty there is still 1.x. [10:56] c_korn: so get libevent 2.x. :) [10:58] micahg: all got busy :( anyway can you suggest me something about symbol files. Should I look deeper into it? [10:58] ari-tczew: that affects a lot of packages in main, it should be discussed if the desktop and server teams want that transition this cycle [10:59] c2tarun: The sponsor is suggesting you could add a symbols file to that package, the next time you update it (sponsor seems to imply he hopes you will continue to have a relationship with this package!). Sounds like a good idea to me :) [10:59] c2tarun: seems like you've been pointed in the right direction [11:00] ari-tczew: it is still in experimental… http://packages.debian.org/experimental/libevent-dev [11:00] jmarsden, micahg: Thanks :) I'll try to understand about symbol file and include them from next time [11:00] micahg: I'm not suprised. natty+1 will include a lot of transitions and rebuilds [11:01] c_korn: I'd suggest filing a bug if there's not one already, if we're not doing the transition, transmission should probably be downgraded [11:03] micahg: what do you mean with downgraded? transmission 2.21 (which requires libevent 2.x) is not even in natty [11:03] c_korn: oh, ok, I thought you were referring to 2.13 [11:04] no, this one still depends on the old libevent [11:04] ah, good :) [11:05] ok, bug 701471 is about the transition [11:05] Launchpad bug 701471 in libevent (Ubuntu) "Sync libevent 2.0.10 from Debian experimental" [Wishlist,Incomplete] https://launchpad.net/bugs/701471 [11:07] hm, can't be installed side-by-side with 1.x. and has a rather long reverse depends list on the universe repository [11:10] so what needs to be done is to install the libevent 2 package and to see whether all reverse depends still build from source and work properly ? [11:10] I'd vote for not doing that transition this cycle since there's enough to do already before release [11:14] my concerns are mainly about the transmission package. we would stay out of date for another six months and we already are only shipping 2.13 in natty while upstream released 2.21. another option would be to patch it to use libevent 1.x if it is possible. [11:16] c_korn: I'd suggest bringing that up to the desktop team [11:18] should I subscribe the team to the bug? [11:19] c_korn: that's one way, or you can send a mail to the ubuntu-desktop ML === yofel_ is now known as yofel [11:38] please *don't* do anything with libevent until you've spoken to kklimonda first. I'm sure he has already looked at the feasability of upgrading that [11:38] and from what i remember, there is a good reason we are still on the old version [11:38] c_korn: 4 packages ftbfs with 2.0.10 [11:38] there we go :) [11:39] c_korn: one can be dropped, one I've probably ported, one has to be updated by the debian maintainer after testing (and he hasn't told me yet what the status of his tests is) [11:39] kklimonda: are those the main packages or the universe ones [11:40] c_korn: that leaves us with one package that fails its tests because of some internal changes in the libevent http implementation [11:40] micahg: In practice, both need porting, really. [11:40] and, because this one fails tests after successfully building, I'm not really sure what's the status of all the other packages that did build. [11:40] persia: indeed, just wondering if the universe ones have been looked at at all ;) [11:41] micahg: all that fails are in universe [11:42] c_korn: I'll add this to the bug report, along with the link to the PPA, where I did try a transition [11:50] kklimonda: ok, thanks for the detailed information. so for now I will just follow the bug report if there isn't anything else I can help you with the transition … [11:56] c_korn: well, if you know C you can read my comment in bug 701471 - actually, you can read it anyway, but if you know C you could help me with ladvd and honeyd :) [11:56] Launchpad bug 701471 in libevent (Ubuntu) "Sync libevent 2.0.10 from Debian experimental" [Wishlist,Incomplete] https://launchpad.net/bugs/701471 [11:59] what is package-build-dir [12:01] c_korn: if I can get those two ported, and lua-event updated, we could go with transition and work on any bugs after they are reported. [12:02] if not I'll poke Transmission devs to rebundle libevent2 with their source, or do it myself. [12:02] kklimonda: for honeyd: I didn't look yet at the errors but also saw some warnings about implicit declarations, it would be good to add the missing headers to those source files [12:03] geser: I can give you the patch for honeyd, I have ported it already :) [12:03] but I'd like someone to check it, and maybe help me testing it. [12:03] honeyd from your PPA is not ported yet? [12:03] geser: no, I'm uploading it now [12:07] c2tarun, Usually the directory that contains the debian/ directory, although it's possible to arrange things differently with some build systems. [12:09] persia: ok, can you please tell me how to use dpkg-gensymbol I tried by this command "dpkg-gensymbols -pccscript -Pccscript-4.2.0/" but got errors that no changelog found [12:09] Where did you run that command? [12:10] just outside of the folder that contains debian [12:10] And does debian/changelog exist? [12:11] persia: yup it exist look at this pastebin http://paste.ubuntu.com/566609/ [12:12] ccscript-4.2.0 is the folder that contains debian/changelog [12:16] You need to be in ~/source/ccscript/ccscript-4.2.0/ when you run it, not in ~/source/ccscript [12:18] persia: I think it worked (because there is no error) but where is the symbol file? [12:20] I forget: been a while since I did it. Might be in debian/ but I seem to recall it being printed to stdout [12:22] persia: I am not able to understand stdout but on running this "dpkg-gensymbols -pccscript -Pccscript-4.2.0/ > temp.sym" I found an empty temp.sym file [12:24] This is after you built the package? That's unexpected. [12:24] I think your -P parameter isn't quite right — are you in a tree with the package built? [12:25] Laney: what do you mean by "tree with the package built"? [12:25] are the build results somewhere under debian/? [12:26] c2tarun, Have you previously run something like `debuild -b` in the package directory? [12:26] Laney: I dont think so if by build results u mean the source.build file then they are outside of ccscript-4.2.0 [12:26] persia: ya debuild -S [12:27] c2tarun, That only builds the source. You need to build the binary locally before you can run dpkg-gensymbols [12:27] persia: how to do that? [12:27] persia: and what is difference between building the source and building the binary locally? [12:28] `debuild -b` [12:28] It generates a binary package, rather than a source package. It also builds everything so you have the unpacked build in the packaging directory. [12:29] dpkg-gensymbols works by scanning the actual .so files to see which symbols are exported, and for that you need to have them available i.e. you have to have built the package [12:30] persia: I got this error http://paste.ubuntu.com/566614/ [12:31] Then install your build-dependencies. [12:34] persia: ok, they are getting installed it will take some time. I have one question by source package you mean source.build file? [12:34] No. [12:35] Then? [12:35] A source package is a .dsc file and any files referenced in that .dsc file. [12:35] A binary package is a .deb file. [12:36] persia: ok :) got it. [12:37] * persia begins to wonder if a binary package ought be considered the union of a .deb and a .ddeb [12:54] kklimonda: is it enough for testing to have a natty chroot ? [12:56] c_korn: for packages that don't have a gui it should be enough [12:57] Even for packages with a GUI, it can be enough, if the package doesn't care about what X server it is rendering against (most packages don't) [12:57] But it can be a little tricky setting up a chroot to connect to a local X server (schroot -p contains most of the magic, and there are other ways) [13:00] great, gearmand has been synced and its tests also fail with libevent2 [13:00] I have already a maverick schroot here. [13:04] hmm, may be my fault.. [13:04] or not.. hmm [13:06] can someone take a look at http://tinyurl.com/6xydhg3 (built fine) and http://tinyurl.com/6dran36 (failed) and tell me if they see any difference? [13:06] the failed build seems to be running tests twice.. [13:09] well the libevent version is a difference of cource. but I doubt you mean that… [13:10] no, but it does seem to break something subtle in tests.. it may not be a good idea to touch it now after all. [13:11] meh, I still have some time to work on it. I'll try it later [13:16] ok, my natty schroot is now ready [13:20] ok, so this is the rdepends list http://pastebin.com/3tMzEKXq [13:21] yes - you can get new packages from https://launchpad.net/~kklimonda/+archive/libevent2/+packages, we can split it between two of us and see how many of them we can test [13:22] c_korn: transmission will work, so should php5 [13:22] ok, fine [13:23] we could create a quick wiki page, where we put things we have tested, what we are testing, and what should be tested [13:23] this way we can coordinate it [13:24] good idea. better coordination than pastebin texts :) [13:25] if we split it this way? http://pastebin.com/xUs0U2db [13:26] I have lunch now. will begin work after it. [13:26] bbl === em is now known as emma [13:28] c_korn: I'd rather do it this way: create a list of packages to test in a simple table, where we can put TESTED, TESTING, NEEDS TESTING states. This way we don't have to reevaluate the split at some point when one of us runs out of things to work on ;) [13:32] c_korn: something like this: https://wiki.ubuntu.com/KrzysztofKlimonda/Libevent2Transition === emma is now known as em [13:37] kklimonda: you might also want to check with the server team to see if they're ok with this transition [13:37] micahg: good point [13:38] kklimonda: for main, it you + 3 packages the server team owns [13:38] s/owns/cares about/ :) [13:38] *nods* [13:53] if a sponsor is interested in sponsoring some merge how should he proceed? Should he remove ubuntu-sponsors from the reviewers, and add himself to indicate that he's working on it? [13:53] kklimonda: yes [13:53] micahg: so the merge disappears from the sponsorship queue [13:54] kklimonda: you can set to in progess and assign to you, then unassign before uploading [13:54] micahg: now, if there are issues with the merge, it can take a while to do that. [13:54] kklimonda: well, a few hours is fine, a few days, less so [13:55] indeed, but the bottom line is that someone else may not be aware of this merge, and will upload his version instead. [13:55] (which did happen with my merge of hamster-applet ;)) [13:56] kklimonda: if there's a merge bug filed, someone should check that before working on it [13:56] micahg: sure, but LP is slow ;) [13:56] kklimonda: shouldn't be that slow anymore [13:57] kklimonda: BTW, I'm unsubscribing sponsors from the libevent bug [13:58] micahg: sure [13:58] there is nothing to sponsor yet :) [14:11] kklimonda: ok, thanks for the list. I am testing now === tarun is now known as c2tarun [14:27] I got this error while building the binary package http://paste.ubuntu.com/566647/ [14:27] c2tarun: update pbuilder [14:28] ari-tczew: actually I have multiple chroot environments of pbuilder so i use pbuilder-dist. how to update that? [14:28] c2tarun: pbuilder-dist natty update [14:29] ari-tczew: but I think it failed to download some files, is it really due to not updating? [14:30] c2tarun: do it [14:30] c2tarun: those versions don't exist anymore, so the files fail to download [14:30] ari-tczew: sure :) I executed the command it'll take some time as I have very slow connection. [14:31] c2tarun: you need to keep your pbuilder updated (similar to your normal system) to let it know which packages in which version are in the archive [14:31] micahg: so updating will solve the prob? [14:31] c2tarun: yes, it should [14:31] micahg: ok, thanks :)( [14:37] !ping [14:37] ping-pong, a fun game for all the family [14:37] salam === tarun is now known as Guest70368 [14:41] wa alaykom as-salamu wa rahmatu Ullahi wa barakatoh [14:45] anant : thx [14:45] alhamddullilah [14:47] !language | AnAnt petanilinux [14:47] AnAnt petanilinux: Please watch your language and topic to help keep this channel family-friendly, polite, and professional. [14:47] I mean english. :-) [14:48] AnAnt: barry said "looks like a bogus pychecker warning to me" to your git-buildpackage problem [14:49] ari-tczew, me indonesian langueage [14:50] petanilinux: nice, but here we prefer english :) [14:50] as universal language [14:50] oke , no problem [14:51] geser: yeah, I saw that. But then what ? [14:51] geser: angelabad uploaded git-buildpackage with the old patch (disabling pychecker), but I am not sure that this is the right solution [14:51] not sure, probably disable it for this file [16:13] geser, persia: could you update DMB for date? [16:14] (DMB wiki agenda) [16:16] Howdy, MOTU. Can I bump bug 666849 (backport bug -- anyone around from backports)? [16:16] Launchpad bug 666849 in maverick-backports "Please backport arduino (0021+dfsg-2) from natty to maverick" [Undecided,Confirmed] https://launchpad.net/bugs/666849 [16:16] it builds clean, and was tested [16:16] looks like it's just stalled [16:17] paultag: MOTU and backports team aren't all the same people. I'll have a look at it. [16:18] ScottK: thanks, I'm a bit lost on the Ubuntu package teams - I've never been too involved with it :) [16:18] so, please excuse the out-of-place remark :) [16:24] after compiling libdnsres with libevent2 it does not depend on libevent any longer. http://pastebin.com/hjwBipTB [16:25] paultag: No trouble. [16:26] c_korn: that looks like two things could have happened -- you ended up with those functions implicitly declared, or the shlibs of libevent2 are broken [16:29] paultag: Approved. [16:30] ScottK: cheers! [16:32] how can I see the shlibs of the installed package ? [16:36] c_korn: on a binary or on the package? [16:36] on the installed package. I know I could also look in the package's DEBIAN/shlibs file [16:36] c_korn: either ldd on a binary, or shlibs [16:36] ah [16:37] humm, I don't know there's something for that [16:37] this is the shlibs file in the libevent-2.0.5 package: libevent-2.0 5 libevent-2.0-5 (>= 2.0.10-stable) [16:40] c_korn: not sure, really [16:41] c_korn: if you're looking for what a binary is linked against, ldd might help, but other then that, I'm not sure there's much in place [16:42] c_korn: and if you're working on that package, it has hella issues [16:42] what package do you mean? [16:42] lintian -IE --pedantic libevent*changes | wc -l [16:42] 27 [16:42] c_korn: libevent [16:48] those are the libevent errors/information http://pastebin.com/niiCg1zN [16:58] c_korn: http://pastebin.com/LKgnuv5v [16:59] paultag: you are checking the older version :) [16:59] kklimonda: ahhha. Thanks! :) [16:59] * paultag finds some coffee :) [17:03] hm, my first FTBFS http://pastebin.com/Zfuq3CzK [17:04] c_korn: you don't really have to rebuild the. I did that already. But the problem is the successful rebuild doesn't indicate a properly working package :) [17:04] c_korn: this FTBFS is related to linking no add needed [17:04] yes, I also test the executable [17:04] c_korn: the ppa with all reverse dependencies is in https://launchpad.net/~kklimonda/+archive/libevent2 and I did mention it. [17:05] c_korn: you cat get packages from there, I've fixed two or three that did fail [17:05] Hey, anyone up for reviewing l2tp-ipsec-vpn? It's a little applet to configure and manage L2TP IPsec VPN connections. I've just uploaded a new candidate. http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn [17:05] c_korn: I did fix getstream for example already, so you can get a source packages from there :) [17:06] c_korn: if you want fix it, you have to add link -levent [17:08] ok, but I can't test it anyway. don't have a DVB-S transponder xD [17:09] enough testing work for today [17:09] c_korn: thanks for that, I see you did test quite a lot of them already :) [17:10] np [18:18]