[01:00] <jmarsden> 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] <broder> 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] <jmarsden> OK, that's a start, thanks.
[01:04] <broder> 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] <psusi> 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] <psusi> nevermind... must have had a typo
[01:24] <persia> 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] <persia> 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] <jmarsden> persia: Thanks :)  germinate I know of, debian-cd I did not know about until you mentioned it :)
[01:28] <persia> jmarsden, At a high level, what are you trying to accomplish?  A remix?  A new flavour?  Troubleshooting an issue?  Just tweaking images?
[01:29] <jmarsden> 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] <jmarsden> persia: So my goal is to see if I can duplicate "how Ubuntu does it" locally, as a first major step.
[01:30] <persia> 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] <jmarsden> Thanks :)
[01:31] <persia> "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] <jmarsden> 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] <persia> I think the natty environment is essentially a buildd chroot.
[01:33] <persia> Well, with some extra packages installed.
[01:33] <persia> 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] <persia> (sometimes things do go wrong: I remember backporting some boot thingy to hardy at one point to fix one of them)
[01:35] <jmarsden> 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] <persia> I'd suggest a natty chroot.
[01:38] <persia> If you have ubuntu-dev-tools installed, `mk-sbuild natty` may be enough (I forget if that was lucid or maverick)
[01:38] <persia> If that doesn't work, pbuilder is probably the best quick choice.
[04:10] <vish> broder: hey, for package description guidelines https://wiki.ubuntu.com/SoftwareCenter/PackageDescriptions is the start
[04:12] <vish> 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] <broder> thanks, that's helpful
[04:12] <vish> np..
[04:14] <persia> vish, If you're involved in that, could you encourage folk to get descriptions to also meet the following two guidelines:
[04:15] <persia> 1) The short description should complete the cloze "${PACKAGE} is ${SHORT DESCRIPTION}"
[04:15] <persia> 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] <persia> micahg, It does.  It can be confused by capitalisation changes, etc.
[04:17] <vish> persia: why does short description have to repeat the package name?
[04:17]  * vish curious..
[04:17] <persia> It doesn't.
[04:17] <persia> It completes the cloze.
[04:18] <vish> and what does "cloze" mean ? :)
[04:18] <persia> It should not include the package name, or any copula, but rather assume both will be presented by the package manager.
[04:18] <jmarsden> clause :)
[04:18] <persia> No, cloze
[04:18] <persia> http://en.wikipedia.org/wiki/Cloze
[04:19] <vish> yea, i dint expect persia making two consecutive typos :)
[04:19] <persia> One is indeed common though :)
[04:20] <broder> persia: the second is already dictated by Policy, i think
[04:20] <jmarsden> So... the short description "is an exercise, test, or assessment"  ?
[04:21] <persia> broder, Both are dictated by policy.  Sometimes the folks that put together the user experience specifications aren't intimately familiar with policy.
[04:21] <vish> 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] <persia> So, let's say I have a package lksdf
[04:21] <broder> 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] <vish> ah!
[04:22] <persia> And I want the description to be "lksdf is a utility to render any text meaningless"
[04:22] <persia> So, I need to have a short description "utility to render any text meaningless"
[04:22] <persia> or "a utility to render any text meaningless"
[04:23] <vish> persia: yea, right, that is what is already mentioned in the guidelines
[04:23] <vish> or was ?
[04:23] <persia> I didn't see it in a quick read.  I'll look again.
[04:23] <vish> let me check, but i recall discussing that with mpt, he dint want the package name repeats in the description
[04:24] <persia> In the long description?
[04:24] <broder> vish: lintian should yell at you if you do that
[04:24] <persia> Not all the package managers show the package name when showing the long description.
[04:24] <persia> broder, No, lintian only complains about the short description.
[04:24] <broder> ah, sure
[04:25]  * micahg keeps learning new words from persia
[04:25] <vish> 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] <persia> 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] <vish> 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] <persia> 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] <vish> yup, http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis  first line is your (1)
[04:35] <vish> more than the package name, the descriptions starting with "this package" were the offending one..
[04:35] <persia> Indeed.  Those are bad.
[04:36] <persia> It is because of those that my rule (2) exists.
[04:36] <persia> (not that it's my rule, but that I numbered them)
[04:38] <vish> 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] <vish> which does not necessarily mean long desc needs to depend on the short, but having that line is misleading..
[04:40] <persia> 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] <persia> Changing the guidelines may be as simple as filing a bug, and following up on it.
[04:41] <persia> 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] <udienz> Hi, is a new packages with need-packaging tag must subscribed to ubuntu-sponsors?
[08:12] <udienz> a source already landed in revu
[08:12] <persia> Is the packaging complete?  If so, sure.
[08:12] <persia> Or you can ask for a review here.
[08:12] <persia> Which package?
[08:12] <udienz> persia, yup complete
[08:12] <udienz> wait..
[08:13] <udienz> persia, gkamus
[08:13] <udienz> http://revu.ubuntuwire.com/p/gkamus
[08:13] <udienz> http://revu.ubuntuwire.com/p/gbilling-client
[08:14] <udienz> http://revu.ubuntuwire.com/p/gbilling-server
[08:17] <persia> 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] <udienz> ah.. ok. so it's better to removing d/docs?
[08:19] <persia> Or just don't create it in the first place :)
[08:19] <persia> 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] <udienz> persia, ok, i'm writing in english in d/README.Debian
[08:21] <persia> 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] <persia> 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] <micahg> udienz: I'm commenting on revu for gkamus
[08:24] <persia> udienz: For both of them, I'm not sure why you need debhelper >= 7.0.50~ when you're using CDBS.
[08:26] <udienz> persia, i'm not tested this packages in debian, so i'm not confident to uploading to debian
[08:26] <persia> gbilling-server has all the same points as gbilling-client.
[08:26] <udienz> i will ask debian-id to testing
[08:27] <udienz> micahg, thanks
[08:27] <persia> Heh, makes sense.  It ought work about the same.
[08:28] <udienz> persia, and about debhelper it must be 7?
[08:28] <persia> I don't know why you need debhelper 7.
[08:28] <persia> Most CDBS packages do fine with debhelper 6.
[08:29] <persia> But it doesn't matter how you do it, as long as you know why you are doing it that way.
[08:30] <micahg> udienz: generally debhelper >=7.0.50~ is used the dh short for overrides are used
[08:30] <micahg> s/the/when
[08:36] <udienz> micahg, what lintian option you used? i use -iIEv --pedantic *.changes before i uploading to revu and i not got an errors
[08:37] <persia> udienz, Did you build a binary and run it the binary changes as well?
[08:37] <micahg> udienz: on the source or binary changes file?
[08:37] <micahg> source is lintian clean, binary is not
[08:37] <udienz> persia, yes. in ppa and running very well in my laptop
[08:38] <persia> udienz, But did you run lintian on the binary?
[08:38] <udienz> micahg,  source ah.. thanks
[08:38] <udienz> persia, no sorry. i will fixing it
[08:39] <persia> No need to apologize: that's why we do reviews :)
[08:39] <persia> We all make mistakes, especially when packaging something new, because there's so many things to think about.
[08:40] <udienz> hehe
[08:52] <persia> Did anyone attend http://www.fosdem.org/2011/schedule/event/opengazer_dasher last weekend?
[08:56] <persia> 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] <Jayant> 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] <Jayant> I can access BIOS but can't even access the selection to boot winxp
[09:08] <persia> This isn'T a support channel: you might try #ubuntu.
[09:09] <persia> In general, the recommended upgrade path would be 9.04 -> 9.10 -> 10.04 -> 10.10
[09:09] <Jayant> oops thanks :)
[09:09] <persia> 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] <udienz> ari-tczew, around?
[09:38] <ari-tczew> udienz: yea. hi.
[09:38] <udienz> ari-tczew, Hello..
[09:39] <udienz> about bug 717654, both CVE already apllied in debian unstable
[09:39] <ari-tczew> ubottu: I saw and I'm looking on squid3 right now :-)
[09:41] <ari-tczew> udienz: open your debdiff and look on line 25
[09:42] <ari-tczew> this is a change in d/changelog
[09:42] <ari-tczew> it's wrong
[09:42] <ari-tczew> lines 25-34
[09:43] <ari-tczew> you can remove it manually before submitting debdiff on launchpad
[09:44] <udienz> ari-tczew, ok
[09:47] <ari-tczew> 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] <micahg> ari-tczew: you should still upstream it and let Debian fuzz it when applying to the new upstream
[09:48] <ari-tczew> micahg: still upstream it? sorry, I don't understand
[09:49] <micahg> ari-tczew: FTBFS patch?
[09:49] <ari-tczew> micahg: do you mean forward to upstream?
[09:49] <micahg> ari-tczew: forward the linker fix to Debian anyways, no need to wait for new upstream version
[09:49] <persia> Or forward it to Debian: warn the maintainer that they may have to do some work when importing the new upstream.
[09:51] <ari-tczew> udienz: OK do it what they say above ^^
[09:51] <ari-tczew> but personally I disagree
[09:52] <persia> ari-tczew: Why?
[09:52] <udienz> ari-tczew, i'll send it
[09:53] <ari-tczew> 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] <ari-tczew> I had *
[09:54] <persia> Oh, sure.  They key thing is that there is a potential issue, not that there is a real and firm issue.
[10:00] <c2tarun> what is a symbol file and what is its use?
[10:00] <ari-tczew> persia: when we will get to know new DMB crew?
[10:01] <persia> ari-tczew: After the next meeting
[10:01] <persia> c2tarun: https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols
[10:02] <udienz> ari-tczew, i send to debian and upstream
[10:03] <ari-tczew> udienz: OK
[10:09] <ari-tczew> udienz: I updated your debdiff and will upload it.
[10:09] <udienz> ari-tczew, ok thanks!
[10:10] <ari-tczew> bp
[10:10] <ari-tczew> np *
[10:17] <ari-tczew> udienz: did you look on bug 690068 ?
[10:18] <udienz> ari-tczew, yes. i try to fixing it in early days
[10:28] <c2tarun> 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] <micahg> c2tarun: binary files that are run
[10:29] <jmarsden> c2tarun: ELF binaries, usually... things you can run
[10:29] <c2tarun> can you please give me an example?
[10:29] <jmarsden> /bin/ls
[10:30] <ari-tczew>    /usr/bin ;)
[10:30] <jmarsden> Right :)
[10:31] <jmarsden> Well, I have /bin/ls on my system here...
[10:31] <micahg> ari-tczew: /usr/bin is a directory :), not all files in there qualify (i.e. /usr/bin/firefox)
[10:31] <ari-tczew> micahg: I know I wanted to fix directory of jmarsden's
[10:31] <micahg> ah
[10:32] <jmarsden> ari-tczew: type which ls and see what your system shows
[10:32] <micahg> ari-tczew: no, he's right :P
[10:32] <ari-tczew> oO
[10:32] <ari-tczew> but usually /usr/bin/*
[10:32] <ari-tczew> :>
[10:32] <c2tarun> 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] <c2tarun> but if there is no symbols files or shlibs files then?
[10:33] <jmarsden> c2tarun: Needed for *running* the executables in a package, I think.  By the time it runs you have already built the package...
[10:34] <jmarsden> So the build deps are already installed...
[10:34] <micahg> jmarsden: I think the questions is about filling ${shlibs:Depends} in the binary depends
[10:35] <c2tarun> sorry I am not getting, what do you mean by running the "executables in a package"?
[10:35] <jmarsden> micahg: Right, so that is not something "needed for buiding a package", but something needed at package run time...
[10:35] <micahg> jmarsden: ah, right :)
[10:36] <jmarsden> 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] <jmarsden> c2tarun: For example, run    ldd /bin/ls    to see what shared libraries that program needs :)
[10:37] <persia> This then populates ${shlibs:Depends} so that you don't have to fiddle with nm and set the dependencies manually.
[10:44] <c2tarun> 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] <jmarsden> Not all packages currently in existence come with symbols files.  Most likely coreutils does not provide such a file.
[10:46] <jmarsden> c2tarun: What is the real reason for all your experimenting with dpkg-shlibdeps ?  What exactly are you needing to do?
[10:47] <c2tarun> 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] <jmarsden> 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] <persia> Only packages that supply shared libraries should have symbols files.
[10:52] <micahg> bug 713492 started all this
[10:52] <c2tarun> jmarsden: please check bug 713492 and second last domment
[10:52] <c2tarun> micahg: yup :) I was looking for that bug only :)
[10:56] <c_korn> hm, transmission requires libevent version 2.x. in natty there is still 1.x.
[10:56] <ari-tczew> c_korn: so get libevent 2.x. :)
[10:58] <c2tarun> micahg: all got busy :( anyway can you suggest me something about symbol files. Should I look deeper into it?
[10:58] <micahg> 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] <jmarsden> 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] <micahg> c2tarun: seems like you've been pointed in the right direction
[11:00] <c_korn> ari-tczew: it is still in experimental… http://packages.debian.org/experimental/libevent-dev
[11:00] <c2tarun> jmarsden, micahg: Thanks :) I'll try to understand about symbol file and include them from next time
[11:00] <ari-tczew> micahg: I'm not suprised. natty+1 will include a lot of transitions and rebuilds
[11:01] <micahg> 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] <c_korn> micahg: what do you mean with downgraded? transmission 2.21 (which requires libevent 2.x) is not even in natty
[11:03] <micahg> c_korn: oh, ok, I thought you were referring to 2.13
[11:04] <c_korn> no, this one still depends on the old libevent
[11:04] <micahg> ah, good :)
[11:05] <c_korn> ok, bug 701471 is about the transition
[11:07] <c_korn> 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] <c_korn> 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] <micahg> I'd vote for not doing that transition this cycle since there's enough to do already before release
[11:14] <c_korn> 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] <micahg> c_korn: I'd suggest bringing that up to the desktop team
[11:18] <c_korn> should I subscribe the team to the bug?
[11:19] <micahg> c_korn: that's one way, or you can send a mail to the ubuntu-desktop ML
[11:38] <chrisccoulson> 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] <chrisccoulson> and from what i remember, there is a good reason we are still on the old version
[11:38] <kklimonda> c_korn: 4 packages ftbfs with 2.0.10
[11:38] <chrisccoulson> there we go :)
[11:39] <kklimonda> 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] <micahg> kklimonda: are those the main packages or the universe ones
[11:40] <kklimonda> c_korn: that leaves us with one package that fails its tests because of some internal changes in the libevent http implementation
[11:40] <persia> micahg: In practice, both need porting, really.
[11:40] <kklimonda> 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] <micahg> persia: indeed, just wondering if the universe ones have been looked at at all ;)
[11:41] <kklimonda> micahg: all that fails are in universe
[11:42] <kklimonda> 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] <c_korn> 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] <kklimonda> 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:59] <c2tarun> what is package-build-dir
[12:01] <kklimonda> 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] <kklimonda> if not I'll poke Transmission devs to rebundle libevent2 with their source, or do it myself.
[12:02] <geser> 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] <kklimonda> geser: I can give you the patch for honeyd, I have ported it already :)
[12:03] <kklimonda> but I'd like someone to check it, and maybe help me testing it.
[12:03] <geser> honeyd from your PPA is not ported yet?
[12:03] <kklimonda> geser: no, I'm uploading it now
[12:07] <persia> c2tarun, Usually the directory that contains the debian/ directory, although it's possible to arrange things differently with some build systems.
[12:09] <c2tarun> 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] <persia> Where did you run that command?
[12:10] <c2tarun> just outside of the folder that contains debian
[12:10] <persia> And does debian/changelog exist?
[12:11] <c2tarun> persia: yup it exist look at this pastebin http://paste.ubuntu.com/566609/
[12:12] <c2tarun> ccscript-4.2.0 is the folder that contains debian/changelog
[12:16] <persia> You need to be in ~/source/ccscript/ccscript-4.2.0/ when you run it, not in ~/source/ccscript
[12:18] <c2tarun> persia: I think it worked (because there is no error) but where is the symbol file?
[12:20] <persia> 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] <c2tarun> 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] <persia> This is after you built the package?  That's unexpected.
[12:24] <Laney> I think your -P parameter isn't quite right — are you in a tree with the package built?
[12:25] <c2tarun> Laney: what do you mean by "tree with the package built"?
[12:25] <Laney> are the build results somewhere under debian/?
[12:26] <persia> c2tarun, Have you previously run something like `debuild -b` in the package directory?
[12:26] <c2tarun> 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] <c2tarun> persia: ya debuild -S
[12:27] <persia> c2tarun, That only builds the source.  You need to build the binary locally before you can run dpkg-gensymbols
[12:27] <c2tarun> persia: how to do that?
[12:27] <c2tarun> persia: and what is difference between building the source and building the binary locally?
[12:28] <persia> `debuild -b`
[12:28] <persia> 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] <Laney> 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] <c2tarun> persia: I got this error http://paste.ubuntu.com/566614/
[12:31] <persia> Then install your build-dependencies.
[12:34] <c2tarun> 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] <persia> No.
[12:35] <c2tarun> Then?
[12:35] <persia> A source package is a .dsc file and any files referenced in that .dsc file.
[12:35] <persia> A binary package is a .deb file.
[12:36] <c2tarun> 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] <c_korn> kklimonda: is it enough for testing to have a natty chroot ?
[12:56] <kklimonda> c_korn: for packages that don't have a gui it should be enough
[12:57] <persia> 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] <persia> 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] <kklimonda> great, gearmand has been synced and its tests also fail with libevent2
[13:00] <c_korn> I have already a maverick schroot here.
[13:04] <kklimonda> hmm, may be my fault..
[13:04] <kklimonda> or not.. hmm
[13:06] <kklimonda> 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] <kklimonda> the failed build seems to be running tests twice..
[13:09] <c_korn> well the libevent version is a difference of cource. but I doubt you mean that…
[13:10] <kklimonda> 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] <kklimonda> meh, I still have some time to work on it. I'll try it later
[13:16] <c_korn> ok, my natty schroot is now ready
[13:20] <c_korn> ok, so this is the rdepends list http://pastebin.com/3tMzEKXq
[13:21] <kklimonda> 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] <kklimonda> c_korn: transmission will work, so should php5
[13:22] <c_korn> ok, fine
[13:23] <kklimonda> 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] <kklimonda> this way we can coordinate it
[13:24] <c_korn> good idea. better coordination than pastebin texts :)
[13:25] <c_korn> if we split it this way? http://pastebin.com/xUs0U2db
[13:26] <c_korn> I have lunch now. will begin work after it.
[13:26] <c_korn> bbl
[13:28] <kklimonda> 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] <kklimonda> c_korn: something like this: https://wiki.ubuntu.com/KrzysztofKlimonda/Libevent2Transition
[13:37] <micahg> kklimonda: you might also want to check with the server team to see if they're ok with this transition
[13:37] <kklimonda> micahg: good point
[13:38] <micahg> kklimonda: for main, it you + 3 packages the server team owns
[13:38] <micahg> s/owns/cares about/ :)
[13:38] <kklimonda> *nods*
[13:53] <kklimonda> 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] <micahg> kklimonda: yes
[13:53] <kklimonda> micahg: so the merge disappears from the sponsorship queue
[13:54] <micahg> kklimonda: you can set to in progess and assign to you, then unassign before uploading
[13:54] <kklimonda> micahg: now, if there are issues with the merge, it can take a while to do that.
[13:54] <micahg> kklimonda: well, a few hours is fine, a few days, less so
[13:55] <kklimonda> indeed, but the bottom line is that someone else may not be aware of this merge, and will upload his version instead.
[13:55] <kklimonda> (which did happen with my merge of hamster-applet ;))
[13:56] <micahg> kklimonda: if there's a merge bug filed, someone should check that before working on it
[13:56] <kklimonda> micahg: sure, but LP is slow ;)
[13:56] <micahg> kklimonda: shouldn't be that slow anymore
[13:57] <micahg> kklimonda: BTW, I'm unsubscribing sponsors from the libevent bug
[13:58] <kklimonda> micahg: sure
[13:58] <kklimonda> there is nothing to sponsor yet :)
[14:11] <c_korn> kklimonda: ok, thanks for the list. I am testing now
[14:27] <c2tarun> I got this error while building the binary package http://paste.ubuntu.com/566647/
[14:27] <ari-tczew> c2tarun: update pbuilder
[14:28] <c2tarun> ari-tczew: actually I have multiple chroot environments of pbuilder so i use pbuilder-dist. how to update that?
[14:28] <ari-tczew> c2tarun: pbuilder-dist natty update
[14:29] <c2tarun> ari-tczew: but I think it failed to download some files, is it really due to not updating?
[14:30] <ari-tczew> c2tarun: do it
[14:30] <micahg> c2tarun: those versions don't exist anymore, so the files fail to download
[14:30] <c2tarun> ari-tczew: sure :) I executed the command it'll take some time as I have very slow connection.
[14:31] <geser> 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] <c2tarun> micahg: so updating will solve the prob?
[14:31] <micahg> c2tarun: yes, it should
[14:31] <c2tarun> micahg: ok, thanks :)(
[14:37] <petanilinux> !ping
[14:37] <petanilinux> salam
[14:41] <AnAnt> wa alaykom as-salamu wa rahmatu Ullahi wa barakatoh
[14:45] <petanilinux> anant : thx
[14:45] <petanilinux> alhamddullilah
[14:47] <ari-tczew> !language | AnAnt petanilinux
[14:47] <ari-tczew> I mean english. :-)
[14:48] <geser> AnAnt: barry said "looks like a bogus pychecker warning to me" to your git-buildpackage problem
[14:49] <petanilinux> ari-tczew, me indonesian langueage
[14:50] <ari-tczew> petanilinux: nice, but here we prefer english :)
[14:50] <ari-tczew> as universal language
[14:50] <petanilinux> oke , no problem
[14:51] <AnAnt> geser: yeah, I saw that. But then what ?
[14:51] <AnAnt> geser: angelabad uploaded git-buildpackage with the old patch (disabling pychecker), but I am not sure that this is the right solution
[14:51] <geser> not sure, probably disable it for this file
[16:13] <ari-tczew> geser, persia: could you update DMB for date?
[16:14] <ari-tczew> (DMB wiki agenda)
[16:16] <paultag> Howdy, MOTU. Can I bump bug 666849 (backport bug -- anyone around from backports)?
[16:16] <paultag> it builds clean, and was tested
[16:16] <paultag> looks like it's just stalled
[16:17] <ScottK> paultag: MOTU and backports team aren't all the same people.  I'll have a look at it.
[16:18] <paultag> ScottK: thanks, I'm a bit lost on the Ubuntu package teams - I've never been too involved with it :)
[16:18] <paultag> so, please excuse the out-of-place remark :)
[16:24] <c_korn> after compiling libdnsres with libevent2 it does not depend on libevent any longer. http://pastebin.com/hjwBipTB
[16:25] <ScottK> paultag: No trouble.
[16:26] <hyperair> 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] <ScottK> paultag: Approved.
[16:30] <paultag> ScottK: cheers!
[16:32] <c_korn> how can I see the shlibs of the installed package ?
[16:36] <paultag> c_korn: on a binary or on the package?
[16:36] <c_korn> on the installed package. I know I could also look in the package's DEBIAN/shlibs file
[16:36] <paultag> c_korn: either ldd on a binary, or shlibs
[16:36] <paultag> ah
[16:37] <paultag> humm, I don't know there's something for that
[16:37] <c_korn> 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] <paultag> c_korn: not sure, really
[16:41] <paultag> 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] <paultag> c_korn: and if you're working on that package, it has hella issues
[16:42] <c_korn> what package do you mean?
[16:42] <paultag> lintian -IE --pedantic libevent*changes | wc -l
[16:42] <paultag> 27
[16:42] <paultag> c_korn: libevent
[16:48] <c_korn> those are the libevent errors/information http://pastebin.com/niiCg1zN
[16:58] <paultag> c_korn: http://pastebin.com/LKgnuv5v
[16:59] <kklimonda> paultag: you are checking the older version :)
[16:59] <paultag> kklimonda: ahhha. Thanks! :)
[16:59]  * paultag finds some coffee :)
[17:03] <c_korn> hm, my first FTBFS http://pastebin.com/Zfuq3CzK
[17:04] <kklimonda> 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] <ari-tczew> c_korn: this FTBFS is related to linking no add needed
[17:04] <c_korn> yes, I also test the executable
[17:04] <kklimonda> c_korn: the ppa with all reverse dependencies is in https://launchpad.net/~kklimonda/+archive/libevent2 and I did mention it.
[17:05] <kklimonda> c_korn: you cat get packages from there, I've fixed two or three that did fail
[17:05] <wejaeger> 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] <kklimonda> c_korn: I did fix getstream for example already, so you can get a source packages from there :)
[17:06] <ari-tczew> c_korn: if you want fix it, you have to add link -levent
[17:08] <c_korn> ok, but I can't test it anyway. don't have a DVB-S transponder xD
[17:09] <c_korn> enough testing work for today
[17:09] <kklimonda> c_korn: thanks for that, I see you did test quite a lot of them already :)
[17:10] <c_korn> np
[18:18] <c2tarun> need help in creating the symbol file. I build the source package and binary package.
[18:25] <c2tarun> persia: ping
[18:39] <ari-tczew> siretart: around?
[18:40] <siretart> ari-tczew: hi
[18:40] <ari-tczew> siretart: did you see my mail?
[18:40] <siretart> ari-tczew: I've uploaded your patch a few minutes ago :-)
[18:41] <siretart> ari-tczew: http://packages.qa.debian.org/libv/libva/news/20110213T181722Z.html
[18:42] <ari-tczew> siretart: very nice, I'll file a sync request and let you know about it, OK?
[18:42] <siretart> sure!
[18:42] <siretart> ari-tczew: please note that I didn't try to build it in natty yet
[18:42] <ari-tczew> siretart: I did it.
[18:43] <siretart> cool!
[18:43] <ari-tczew> siretart: then I'll attach a buildlog to sync request.
[18:45] <ari-tczew> siretart: what do you think about if I'll prepare a merge of ffmpeg and you will sponsor it?
[18:46] <siretart> ari-tczew: don't you want to rather join pkg-multimedia and do the merge in that team? ;-)
[18:47] <siretart> ari-tczew: I use git to maintain the ffmpeg package for ubuntu as well, and that merge is next on my list
[18:49] <ari-tczew> siretart: but delta is only ubuntu-specific, how do you want get it into Debian?
[18:49] <siretart> ari-tczew: http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=shortlog;h=refs/heads/ubuntu
[18:50] <ari-tczew> siretart: not sure whether I have a time for new membership
[18:58] <siretart> ari-tczew: uh my, it seems I there are a number of bits that should go into the debian pacakge :-/
[18:59] <ari-tczew> siretart: do you mean ffmpeg?
[18:59] <siretart> yeah
[19:01] <ari-tczew> siretart: so do we should wait for next ffmpeg revision?
[19:06] <siretart> ari-tczew: I'm already working on it
[19:06] <ari-tczew> siretart: OK
[19:10] <ari-tczew> siretart: do you know how to fix this FTBFS? http://paste.ubuntu.com/566726/
[19:14] <geser> ari-tczew: I looked once at a similar FTBFS and it looks like linux-libc-dev doesn't ship that file anymore
[19:14] <geser> only the V4L2 header file
[19:16] <ari-tczew> geser: I tried to find videodev.h in another package but no results.
[19:18] <geser> ari-tczew: linux-libc-dev in maverick has them, but not the natty one
[19:19] <geser> I don't know if v4l is still supported in natty or only v4l2 (linux/videodev2.h)
[19:22] <siretart> no, v4l is dead. port packages to v4l2
[19:22] <siretart> or if v4l support is optional, disable it.
[19:44] <ari-tczew> so next transition
[20:06] <c2tarun> bug 718150 can anyone please explain me the last comment.
[20:26] <geser> c2tarun: there is no real connection between upstream version and API/ABI version of a library
[20:27] <c2tarun> geser: not getting API/ABI version means?
[20:28] <geser> that's the "version" number of the programming interface (API) or call interface (ABI) which other application use of a library
[20:29] <geser> if upstream doesn't change any public functions (API) or size of data structures (ABI) in one release there is to reason to bump the library version
[20:31] <c2tarun> geser: ok, but what do you mean by there is no connection b/w the version. Version in our archives is 3.2.0 and the one I downloaded by uscan is 4.1.1.
[20:34] <c2tarun> geser: ^^
[20:34] <geser> the library version you can "see" in the filename "libucommon.so.3". Because of the "3" the package is names libucommon*3*
[20:35] <geser> many upstream try to keep the major upstream version match the library version but there is no requirement for it
[20:36] <c2tarun> geser: I tried to pull the package of name libucommon3 but It directed me to ucommon package. and sorry but I failed to find libucommon.so.3
[20:37] <geser> the binary package name is "libucommon3" and it's build by the source package "ucommon"
[20:37] <geser> libucommon.so.3 is a filename from the libucommon3 package
[20:38] <atagar> Hi, a package I maintain (tor-arm) just got accepted into debian unstable. What is the process for requesting a sync from ubuntu and does that make it available in all ubuntu distros?
[20:38] <c2tarun> geser: is there any way of building binary package of different name than source package. still the file I uploaded is debian.tar.gz file. I dont think its the binary package.
[20:39] <atagar> (for a bit more context: http://packages.debian.org/sid/tor-arm)
[20:40] <geser> c2tarun: the contents of debian/control describe all packages build from that source package (there are also some other files in debian/ named after a package name to tell debhelper scripts which file belong to which package etc.)
[20:41] <geser> atagar: see https://wiki.ubuntu.com/SyncRequestProcess for the sync and it will be only available for the next Ubuntu release (natty) but once it's in natty you can ask for a backport for older releases
[20:41] <c2tarun> geser: ok, i just checked, I think there are four packages build from this ucommon source package. so what should I do :( I am understanding my mistake, but don't know how to solve it?
[20:42] <atagar> geser: thanks!
[20:44] <geser> I didn't look yet at the package but most likely replace any occurance of libucommon3 with libucommon4 (as the library version has changed according to comment #2) (debian/control, debian/libcommon3.install if it exists and similar files, check debian/rules if libucommon3 is used somewhere)
[20:45] <geser> c2tarun: is this your first package? an upgrade of a library with a transition is not the best pick for someone unexpierenced as you need to learn pretty much in short time
[20:46] <c2tarun> geser: well technically its not my first, but ya you can say so. I am not much experienced. And sorry but I was not aware that it was a library. How can I check that the package I want to upgrade is an library or an application?
[20:46] <atagar> geser: If it won't be available until the next release anyway then is a sync request necessary? I thought most new debian packages were automatically available in the ubuntu repos of new releases.
[20:47] <geser> c2tarun: by looking at which packages it builds: if they start with lib then it's a library
[20:48] <c2tarun> geser: ok, so I should leave this bug and look for some simple packaging one?
[20:49] <geser> atagar: only in the first stage of a development cycle new and updated packages get auto-imported into Ubuntu. After DebianImportFreeze (which was on 2010-12-31) only on request. New packages can only get synced till FeatureFreeze which is on Feb 24th.
[20:50] <atagar> great, thx
[20:50] <geser> c2tarun: up to you, but it seems you have done the most part already. what's missing is the renaming of the binary packages.
[20:52] <c2tarun> geser: ok, so i should grep libucommon3 into all the files of debian and simply replace them by libucommon4? and some occurences like libucommon3-dbg to libucommon4-dbg?
[20:53] <geser> c2tarun: I didn't want to discourage you, just inform you that what you picked isn't an "easy" task
[20:53] <geser> c2tarun: yes
[20:54] <c2tarun> geser: its ok :) I'll leave this bug and look for a new one. One more question, If I get stuck on some error that occurs while building the binary package like http://paste.ubuntu.com/566758/ then what should I do?
[20:54] <geser> (of course don't replace it in old changelog entries as it's a documentation of the package history)
[20:55] <c2tarun> geser: ya sure changelog and copyright entries should not be messed :) so do you think that I should finish this library bug ?
[20:56] <geser> yes, it's a good expierence and you will learn much in short time
[20:56] <geser> if you have any problems, asking here for help is the right place
[20:57] <geser> and currently I don't have an idea of how to fix this FTBFS
[20:58] <c2tarun> geser: ok no prob:), regarding that library bug In control file there is an entry of libucommon3 in Depends section of one of the libraries that are build from this source. should this be changed to libucommon4?
[20:58] <geser> yes
[20:58] <c2tarun> geser: ok,
[20:58] <geser> it's for the -dev package right?
[20:59] <c2tarun> geser: yup
[21:00] <geser> that's right, if you build an other package with libucommon-dev, you need the matching library to link with which is in libucommon4
[21:00] <c2tarun> geser: ok, these changes should be mentioned in changelog or not?
[21:01] <geser> yes, but something like "Renaming libucommon3 to libucommon4" is enough here
[21:02] <c2tarun> geser: ok
[21:03] <c2tarun> geser: and there is file of name libucommon3.install should the name of file be changed to libucommon4.install?
[21:04] <geser> yes, it describes which files end in the libucommon4 package
[21:05] <c2tarun> geser: I think the debian folder is ready now. Is there any way I can show it to you?
[21:08] <geser> I guess the easiest way would be a new attachment to the bug
[21:10] <c2tarun> geser: ok , sure :) I'll do that. just wait a second please
[21:11] <c2tarun> geser: its done can you please take a look. bug 718150
[21:12] <geser> c2tarun: will look at it later, I'm currently not using my Ubuntu so can't check things as easy as I'm used to
[21:13] <c2tarun> geser: sure :) Thanks a lot.
[21:15] <c2tarun> geser: If you can than can you please tell how do you guys check? I mean is there any tool for checking or just by looking at the debian.tar.gz file/
[21:16] <geser> c2tarun: I usually look at the contents of the files
[21:16] <c2tarun> geser: ok
[21:16] <geser> there is a tool (lintian) to check for common errors but it doesn't catch everything
[21:17] <c2tarun> geser: okay, so its all just by experience? thats cool :)
[21:21] <c2tarun> geser: ok its 3 am I have to go :( I'll wait for your comment on that bug, and I'll try to fix any error possible. and Thanks a lot :)
[21:22] <geser> sleep well
[22:31] <grunthus> Hi, is there a good guide to using pbuilder with bzr branches?
[22:34] <ari-tczew> grunthus: general guide about pbuilder: https://wiki.ubuntu.com/PbuilderHowto
[22:35] <grunthus> Hi ari-tczew, thanks, I've been working through that guide, but it doesn't mention bazaar branches.
[22:35] <ari-tczew> grunthus: bzr branch lp:~foo/bar && cd bar && rm -rf .bzr && debuild -S -sa && pbuilder-dist natty ../file.dsc
[22:35] <grunthus> Seems pbuilder build is looking for a dsc file
[22:35] <grunthus> ^thanks
[22:36] <maco> why rm th e.bzr/
[22:36] <maco> *?
[22:36] <ari-tczew> maco: problematic for building source
[22:36] <maco> O_o
[22:36] <maco> bzr-builddeb -S
[22:37] <maco> then it won't complain
[22:37] <maco> and you don't have to lose bzr history and be unable to commit and push up a merge request
[22:39] <grunthus> I'd want to be able to have merge request
[22:40] <tumbleweed> bzr bd --builder=pdebuild ?
[22:43] <grunthus> Hmm. Hit a problem with debhelper.mk: No such file, however debhelper package is installed.
[22:44] <maco> cdbs
[22:46] <ari-tczew> grunthus: install cdbs package in your system
[22:47] <grunthus> cheers maco, ari-tczew, just did that , plus another (python-distutils-extra).
[22:48] <grunthus> I'm attempting to build ubuntuone-control-panel with pbuilder. Now complaining "cant build with soure format 3.0 quilt: no orig.tar.gz...
[22:49] <grunthus> Perhaps this would be easier if I started with apt-get source instead of bzr branch?
[22:49] <maco> bzr bd shouldnt need a .orig.tar.gz
[22:49] <ari-tczew> maco: pbuilder...
[22:51] <grunthus> so pbuilder wrong way to try to build from bzr branch?
[22:52] <micahg> grunthus: no, it should work fine
[22:52] <micahg> grunthus: you can't delete .bzr if you're using bzr-builddeb
[22:52] <grunthus> ah. TOo late then. I'll need to clean up and bzr branch again?
[22:52] <micahg> grunthus: yes
[22:53] <grunthus> OK, np.
[22:55] <grunthus> Right, started again. bzr-builddeb -S
[22:58] <grunthus> Much better, 'fraid to say, debuild failed to sign  changes and dsc files, secret key not available.
[22:58] <grunthus> googling
[22:59] <micahg> grunthus: that's ok for pbuilder, but if you need to upload, you can use debsign on the source.changes file
[23:01] <maco> grunthus: can add "-- -uc -us" to make it shut up about that too
[23:02] <grunthus> Thanks, that's better.
[23:03] <grunthus> I can sign the changes file when I'm finished with a fix for this bug (I hope!)
[23:04] <micahg> grunthus: you won't need to, you can just push your branch up to launchpad, lp:~you/ubuntu/package/branchname or lp:~you/project/branchname
[23:04] <grunthus> OK.
[23:04] <micahg> grunthus: and then propose a merge
[23:10] <maco> put the release as UNRELEASED if you do that
[23:10] <maco> the person who sponsors the upload will change it from UNRELEASED to natty (or whatever)
[23:32] <grunthus> successfull build, thanks for the help.


[04:39] <valorie> anybody planning on attending SeaGL?
[04:39] <valorie> #seagl The Seattle GNU/Linux Conference | Oct. 25-25, 2014


[00:00] <Noskcaj> jarkko, yep
[00:01] <valorie> yes, or apt-get
[00:01] <valorie> easy-peasy
[00:03] <jarkko> have you tried it?
[00:03] <jarkko> that it works and dont break x
[00:04] <ahoneybun> jarkko: I installed Ubuntu then Kubuntu-desktop package and I;m fine
[00:05] <jarkko> well i am happy with kde, but i would like to it to start a bit faster
[01:51] <ahoneybun> yofel: what did lintain tell us?
[01:51] <yofel> oh sorry, got distracted :/
[01:51] <yofel> ok, lets see where we left off
[01:51] <ahoneybun> thats ok
[01:53] <yofel> now that we have the built package, lintian can not only check for common errors in the source, but also in the finished package
[01:53] <yofel> you can find the explenation of the tags on lintian.debian.org, e.g. http://lintian.debian.org/tags/copyright-refers-to-deprecated-bsd-license-file.html
[01:54] <yofel> for now we'll leave lintian, and check for the next script output
[01:54] <yofel> list-missing
[01:55] <ahoneybun> there is nothing there
[01:55] <yofel> that tells whether there are any files that are not in any deb
[01:55] <yofel> in this case, it's empty, so all files are installed and we're good
[01:56] <ahoneybun> cool
[01:57] <yofel> for library packages this would be the point where you would check for symbol diffs in the log, but here we don't have any so we're done looking at the log for now
[01:57] <yofel> so we see all debs are built
[01:58] <yofel> the result folder also has the build log in it should you want to take another look at it later
[01:59] <ahoneybun> no 32 bit build?
[01:59] <yofel> we only did one pbuilder build, and that defaults to the host architecture. You could build for 32bit too, but that would require another build and a 32bit pbuilder chroot
[02:00] <yofel> easy to do, but normally checking just one arch is fine
[02:00] <ahoneybun> as it would build for both for sure
[02:00] <yofel> pbuilder doesn't make a difference between the packages it builds on specific archs like launchpad does
[02:00] <yofel> it always builds everything
[02:02] <yofel> as the package built fine, the package is done from a technical standpoint
[02:03] <yofel> what we still have to do is update the copyright information in debian/copyright and fix the lintian warnings that are fixable
[02:04] <yofel> updating the copyright information is possibly the most boring and tricky thing to do for a package
[02:04] <yofel> lets take a look at the current file
[02:05] <yofel> in the file you see a small header, then every file is listed with it's respective license and the copyright holders
[02:06] <yofel> at the bottom of the file you find the short descriptions of the licenses with references to the full ones, or if a license doesn't have a short form then you see the whole license there
[02:07] <ahoneybun> I see
[02:07] <yofel> there is sadly no fully automated way of updating the information
[02:07] <ahoneybun> so what magic script tells us what has changed lol
[02:08] <yofel> so what I usually do is take the file, and check whether the information is still correct by combinding licensecheck, grep, cut and some shell magic
[02:08] <yofel> I think there's a bit easier way to do it, but that's how I do it
[02:09] <ahoneybun> oh ok then
[02:09] <yofel> at this point: a small lesson in byobu: You can create shell tabs with F2 and switch with F3/F4
[02:10] <yofel> it would be nice if it was that easy :S
[02:10] <yofel> I'll show you how licensecheck works
[02:11] <yofel> so, licensecheck nicely shows us under which license a file is
[02:13] <yofel> it can also show what copyright it has, but at least to me that's of limited use as it's hard to filter
[02:13] <yofel> nice for small packages, but for something as large as tomahawk.. not really
[02:14] <yofel> so I usually go and filter by license (as that's how the copyright file is grouped)
[02:14] <yofel> the full syntax of the debian/copyright file is documented on http://dep.debian.net/deps/dep5/ btw.
[02:14] <ahoneybun> so we do that on for both packages? and then change as neeeded?
[02:15] <yofel> both packages? You only need to update the new one
[02:15] <ahoneybun> well you need to see what it was before
[02:16] <yofel> that's already documented in the copyright file
[02:16] <yofel> you *could* ofc. make a full source diff of 0.6 to 0.7 and parse the changed copyright information out of that
[02:17] <yofel> I'll show you how I usually do it
[02:17] <ahoneybun> where does it say that a license is different
[02:18] <yofel> well, we have nothing that can compare that, so finding that out is up to you
[02:18] <yofel> making a diff will show the license as changed
[02:18] <yofel> or you could go and essentially re-create the copyright file which is kinda what I do
[02:19] <yofel> you can ask the others too how they do it, maybe they have a better procedure ^^
[02:19] <ahoneybun> this is a bit over my head I have a headache lol
[02:20] <yofel> licensing is always headache material. Sometimes you could really use a lawyer for this -.-
[02:21] <ahoneybun> just this altogether I mean
[02:21] <ahoneybun> not something I'm used too
[02:21] <ahoneybun> *to
[02:21] <yofel> you'll get used to it, it takes some practice though ^^
[02:21] <ahoneybun> heck I don't even understand what your writing
[02:22] <yofel> in the shell you see what I usually do: get the licenses, filter files by license, then get just the filename from the list, grep for copyright in those files, then filter by user
[02:22] <ahoneybun> what is happening
[02:22] <ahoneybun> lol
[02:22] <yofel> it's magic :P
[02:23] <ahoneybun> a script doing this for you is magic
[02:23] <ahoneybun> this is something that can't be said over irc
[02:23] <yofel> well, there have been attempts, haven't really seen a good working one for dep5 though
[02:23] <yofel> nor do I really remember where they are
[02:25] <ahoneybun> oh
[02:25] <ahoneybun> lol
[02:25] <yofel> so at this point, I would check the output whether the copyright information for that user is still correct
[02:25] <yofel> in this case, just make sure all copyright years are documented
[02:26] <yofel> which is ok, so now I go and filter that user out
[02:26] <yofel> and filter for the next user
[02:27] <yofel> now repeat that for every user, and every license, and at some point you're done
[02:28] <yofel> if one would like to do it the diff way, I guess it would go like this
[02:29] <yofel> so make a diff, then look for added/removed/changed copyrights and update the file accordingly
[02:29] <yofel> now you can try yourself at this a bit if you want to
[02:30] <yofel> as I'll have to sign off for today
[02:30] <yofel> it's 3:30AM and i'm slowly falling asleep :/
[02:34] <ahoneybun> oh ok then ll
[02:34] <ahoneybun> you have to sleep
[08:57] <lordievader> Good morning.
[13:45] <BluesKaj> Hiyas all
[18:32] <tester56> I think I have figured out my first patch for kdelibs (in kdelibs/kio/kfile/kpropertiesdialog.cpp)
[18:33] <tester56> but I have no experience with compiling such large stuff ... is it possible to compile kpropertiesdialog standalone?
[18:36] <tester56> or is it necessary to compile whole kdelibs?
[18:48] <Peace-> tester56:you need to compile everything
[18:48] <tester56> Peace: okay, and how do I test? do I really have to replace the system files?
[18:49] <Peace-> tester56: i have tried a patch for dolphin for example
[18:49] <Peace-> tester56: and i have compiled it again with my modifications => http://nowardev.wordpress.com/2013/11/18/automatic-video-audio-preview-with-dolphin-kde-hovering-a-file/
[18:49] <Peace-> tester56: try to figure out reading how i have compiled it ...
[18:50] <Peace-> tester56: read this step THIRD STEP : COMPILE DOLPHIN AND INSTALL IT
[18:50] <Peace-> tester56: in that tutorial you get a debian pacakge
[18:51] <Peace-> tester56: so if someting goes wrong just reinstall the default debian pacakge and you are done
[19:04] <tester56> i want to check out if the bug i have found is already fixed in frameworks, where can I find kio in neon?
[19:04] <tester56> Peace: thanks, I will try it
[19:06] <tester56> kio is not listed here: https://launchpad.net/~neon/+archive/kf5
[19:07] <tester56> is it part of any of the listed packages?
[19:10] <yofel> tester56: project-neon5-kio
[19:11] <tester56> yofel: yeah i am an idiot, i was not able to go to page 2
[19:11] <yofel> ^^
[19:11] <yofel> easy to miss on launchpad :P
[19:15] <tester56> yofel: could you say me how to get it with bzr? I seems to be too stupid for that too ...
[19:18] <tester56> because i need the code and not the package ...
[19:19] <yofel> tester56: I don't think we have bzr imports for those, use:
[19:19] <yofel> git clone git://anongit.kde.org/kio
[19:20] <tester56> yofel: thanks
[19:21] <Riddell> valorie: how did it go?
[19:29] <jussi> what state is 14.04 in right now?
[19:42] <tester56> when i simply run cmake when compiling kdelibs, the install directory is the default one, meaning it will replace system files, right?
[19:42] <tester56> (when running make install)
[19:44] <yofel> no, it should default to /usr/local/
[19:44] <yofel> you could simply replace the lib you want to test if you know which one it is
[19:45] <yofel>  /usr/local/ should be hiding the system libs when installed though, just remember to make uninstall them later
[19:46] <tester56> so when i make install, the newly compiled ones will be used?
[19:46] <yofel> jussi: usable, mostly. My issues on my notebook are nvidia driver crashes somehow related to opengl, kernel sometimes not waking from suspend and for some reason virtuoso does nothing but crash on this one system
[19:46] <yofel> other than that it runs fine for me
[19:50] <tester56> yofel: and the path used by kubuntu is /usr ?
[19:51] <yofel> yes
[19:51] <tester56> so setting path to /usr will override the right files?
[19:55] <jussi> yofel: ok, nice. might go ahead and do the update then... especially as I have intel on this machine...
[19:58] <yofel> tester56: yes, should be -DCMAKE_INSTALL_PREFIX=/usr I think. But I wouldn't really recommend that, if you can patching and rebuilding the package would be safer
[20:04] <tester56> yofel: btrfs snapshots should help in that case ;-)
[20:04] <yofel> agreed ^^
[20:15] <tester56> okay something went wrong ...
[20:16] <tester56> in CMakeLists.txt in kdelibs:
[20:16] <tester56> set (KDE_VERSION_MAJOR 4)
[20:16] <tester56> set (KDE_VERSION_MINOR 15)
[20:16] <tester56> set (KDE_VERSION_RELEASE 70)
[20:17] <tester56> so after installing, all kde applications should show 4.15.70 as version, right?
[20:17] <tester56> (in about KDE)
[20:24] <tester56> :-(
[20:24] <yofel> they should show whatever kde4-config --version shows
[20:24] <yofel> I don't know where that comes from though
[20:25] <tester56> when i ran make install there are many of those entries: Installing: /usr/include/kio/jobclasses.h
[20:25] <tester56> why are source files installed?
[20:25] <yofel> those are library headers
[20:26] <yofel> you need those to build anything that uses the libs
[20:34] <tester56> yofel: but the install seems to have gone right: http://pastebin.com/Lkk649Fz  or?
[20:34] <yofel> looks right.. I think
[20:40] <tester56> yofel: okay i think i understand what i did wrong ...
[20:40] <tester56> yofel: if dolphin uses kdelibs/kio/kfile/kpropertiesdialog.cpp i have to compile dolphin against it, right?
[20:41] <yofel> not if the so version of the lib that the code is in is still the same
[20:42] <yofel>  /usr/lib/libkio.so.5 I guess?
[20:42] <tester56> yofel: not sure ...
[20:43] <tester56> yofel: I have changed something there but I do not see the changes applied ...
[20:46] <tester56> yofel: plasma is in kdelibs, right?
[20:46] <yofel> plasma is in kde-workspace
[20:47] <yofel> ah
[20:47] <yofel> libplasma3 is part of kdelibs though
[20:49] <tester56> yofel: so you say it is not necessary to rebuild dolphin?
[20:50] <yofel> it shouldn't be, but if you're unsure you can always try to do that.
[20:50] <yofel> I'm not familiar enough with kdelibs and don't have enough time to take a close look at this to give a definite answer
[20:51] <tester56> yofel: okay thanks for your great help !
[20:58] <tester56> yofel: okay there seems to be somethin wrong
[20:58] <tester56> kmailservice -v outputs KDE Development Platform: 4.12.1
[20:59] <tester56> in the build folder in bin it outputs KDE Development Platform: 4.15.70
[20:59] <tester56>  as expected
[20:59] <tester56> yofel: that means the systemfiles did no replaced
[21:00] <yofel> try to reload the session? Some libs might still be loaded
[21:00] <tester56> i have rebooted after installing
[21:00] <yofel> if the install went ok then that's the only thing I can think of
[21:00] <yofel> dunno then, maybe #kde-devel knows more
[21:03] <tester56> yofel: i do not understand the world atm ... it installed /usr/bin/kmailservice according to the output ...
[21:03] <tester56> then i test the two binaries and they do not match ... WTF?
[21:04] <tester56> trying again now
[21:05] <yofel> it could be that an RPATH was set and it's loading libs from different locations
[21:05] <yofel> wild guess
[21:06] <tester56> yeah but i ran the path it installed it too and it did not match  ^^
[21:06] <tester56> i did a btrfs snapshot before installing though ...
[21:06] <tester56> could that be related?
[21:07] <yofel> unlikely... unless you're running the wrong snapshot or so
[21:08] <tester56> yofel: anyway building whole kdelibs now ... before I only build kio ...
[21:11] <tester56> yofel: there kde4-config is included now :-)
[21:16] <ahoneybun_> yofel: is that shared chroot running?
[21:16] <yofel> ahoneybun_: should be
[21:19] <ahoneybun_> yep
[21:21] <ahoneybun_> what is the key to remove a shell yofel?
[21:24] <yofel> ahoneybun_: just close it with ctrl+d
[21:25] <ahoneybun_> look in debian/copyright correct?
[21:25] <ahoneybun_> for the licenses and such
[21:26] <yofel> right, that's where we left off
[21:32] <ahoneybun_> I have th 0.6 and 0.7 debian/copyright files open but see no difference
[21:33] <yofel> right, as I said yesterday, the 0.7 file is a copy of the 0.6 file
[21:33] <ahoneybun_> oh
[21:33] <yofel> it now has to be updated with the 0.7 license information
[21:33] <yofel> that is documented in the tomahawk source
[21:33] <ahoneybun_> looking
[21:33] <yofel> the debian/copyright file is essentially a documentation of all the copyright headers in the source
[21:34] <yofel> no, that's something else
[21:35] <yofel> do you remember licensecheck?
[21:36] <ahoneybun_> does it matter where I run it?
[21:36] <yofel> yes, as you need to tell it which files to check
[21:36] <yofel> -r *
[21:36] <yofel> does the trick if you're in the package root
[21:37] <yofel> uhm
[21:37] <yofel> * ?
[21:39] <ahoneybun_> I don't remember the use of grep and such though
[21:39] <ahoneybun_> to filter
[21:40] <yofel> ok, I guess we'll do it my way
[21:40] <yofel> that'll take a while though
[21:40] <ahoneybun_> well I don't know anyway but kinda yours
[21:40] <yofel> ok, lets go back to the copyright file
[21:40] <ahoneybun_> I mean I can look though that long list
[21:40] <ahoneybun_> and compate
[21:40] <ahoneybun_> compare
[21:41] <yofel> right... but that would probably take ages for tomahawk - would still work ofc. ^^
[21:41] <yofel> Files: *
[21:42] <ahoneybun_> so you look though licensecheck and put each file in the right license in the copyright file?
[21:42] <yofel> means that we assume that all files that aren't specified in another section are
[21:42] <yofel> License: GPL-3+
[21:43] <yofel> kinda. You need to document what files have what copyright, and who holds the copyright on that
[21:44] <yofel> so I usually update the file starting from the top
[21:44] <ahoneybun_> from the first license
[21:44] <ahoneybun_> I'm trying to see the command
[21:45] <yofel> ok, so now I've filtered out all files that are GPL-3+
[21:45] <ahoneybun_> so just the license so options or anything
[21:45] <yofel> right, works better for me for filtering
[21:45] <yofel> as I need only the file list
[21:45] <yofel> now some shell magic
[21:46] <yofel> that'll cut the output apart on the colon and give me only the first part
[21:46] <yofel> now some more magic
[21:47] <yofel> xargs will append the file list after the 'grep -i copyright'
[21:47] <yofel> that way we can grep through all the listed files
[21:48] <yofel> yay, and it's listing all the copyright holders for the GPL-3+ files
[21:48] <yofel> now we have tons of duplicates ofc. so I filter only one person out
[21:48] <ahoneybun_> after this we can just copy and paste no?
[21:48] <yofel> well, we only need every person *once*
[21:49] <ahoneybun_> yea
[21:49] <yofel> so we need to merge all the copyright years
[21:49] <ahoneybun_> oh boy
[21:49] <yofel> currently we have 2010-2012, so I'll filter for 2013 as that's the only thing that could've been added
[21:50] <yofel> nothing, great
[21:50] <yofel> so nothing to do for that person
[21:50] <ahoneybun_> hard part is to remember these command
[21:50] <ahoneybun_> and options
[21:51] <yofel> now, as I'm done with him, I add -v to grep, which changes behaviour from 'filter for' to 'filter out'
[21:51] <yofel> just to make sure we didn't have 2 christians ^^
[21:52] <yofel> ahoneybun_: you can just copy the ~/.bash_history file later
[21:52] <yofel> that should have most of the commands inside
[21:52] <yofel> now to the next person
[21:53] <yofel> ok, no update for leo either
[21:54] <yofel> ahoneybun_: so, do you kinda see what I do?
[21:54] <ahoneybun_> yea let me try for a sex
[21:54] <ahoneybun_> sec
[21:54] <ahoneybun_> sec
[21:54] <ahoneybun_> crap
[21:55] <ahoneybun_> nothing new from him
[21:56] <yofel> Quintasan: you were asking what  kinda weird shell magic I do to filter licenses, it looks like this :P
[21:56] <yofel> licensecheck -r * | grep GPL | grep v3 | grep later | cut -f 1 -d : | xargs grep -i copyright | grep -i -v christian | grep -i -v franchi | grep -i mitchell | grep 2013
[21:57] <Quintasan> okay
[21:57] <Quintasan> that's magic allright
[21:57] <Quintasan> :D
[21:57] <ahoneybun_> new things
[21:57] <yofel> right
[21:57] <yofel> so now you can change the year range to 2010-2013
[22:01] <yofel> stop
[22:02] <ahoneybun_> ops
[22:02] <yofel> that's why I like to only append grep 2013 in the second run
[22:02] <ahoneybun_> already updated
[22:02] <yofel> so I'm sure I did filter right in the first try
[22:05] <ahoneybun_> i see
[22:07] <yofel> that's the packager coyprights, you won't find those anywhere
[22:07] <yofel> you may add yourself there btw ;)
[22:07] <ahoneybun_> I don't really feel that I have done enough to earn that right
[22:07] <yofel> nobody cares about that ;P
[22:08] <yofel> as the list above was done, you should now check for new people
[22:08] <ahoneybun_> do I keep all these names for the next list?
[22:09] <ahoneybun_> I see I can't save
[22:09] <yofel> huh
[22:10] <yofel> what's the shortcut for that?
[22:10] <ahoneybun_> crtl-s pops that message
[22:10] <yofel> aha, never saw that before ^^
[22:10] <yofel> but then again, I don't use nano
[22:10] <yofel> now give me a sec to check something
[22:10] <ahoneybun_> how did you check for new people?
[22:11] <ahoneybun_> see our changes did not save
[22:12] <ahoneybun_> seems it did
[22:12] <yofel> oh well, it saves on exit
[22:14] <yofel> hm, I wonder why nokia wasn't added
[22:15] <yofel> anyway
[22:15] <yofel> to check for anything new that's missing, just filter out everything we checked before, and look at the leftovers
[22:16] <yofel> which in this case is some code, nokia, and a copyright entry for a different license (that part of  FdoNotifyPlugin.cpp is GPL-2+)
[22:17] <yofel> IMO, nokia does belong into the copyright file, so can you please add it?
[22:18] <yofel> it's already open
[22:19] <yofel> ahoneybun_: wait
[22:19] <yofel> what license are we checking?
[22:20] <ahoneybun_> I thought to add the file
[22:20] <yofel> well, which license are we checking?
[22:21] <ahoneybun_> we just check gpl 3+
[22:21] <yofel> ok, and what license is that section of the file for?
[22:21] <yofel> (see 2 lines below)
[22:22] <ahoneybun_> gpl 2+
[22:22] <yofel> no
[22:22] <yofel> LGPL-2
[22:22] <yofel> and that's not GPL-3+
[22:22] <yofel> our GPL-3+ section was at the top of the file
[22:23] <yofel> again
[22:23] <yofel> that's GPL-2+
[22:23] <ahoneybun_> I'm trying to add that nokia file
[22:23] <yofel> ok, I'll do it
[22:23] <yofel> we were checking GPL-3+
[22:24] <yofel> oh come on
[22:25] <Riddell> ahoneybun_: getting into packaging?
[22:26] <yofel> he is, tomahawk simply wasn't the best thing to start with. I'm trying to teach him how to do the copyright file
[22:26] <yofel> tomahawk is a licensing chaos :S
[22:26] <ahoneybun_> Riddell: mostly watching
[22:27] <yofel> src/libtomahawk/utils/StyleHelper.h (C) nokia gpl-3+
[22:27] <yofel> src/libtomahawk/utils/StyleHelper.cpp (C) nokia gpl-3
[22:27] <yofel> no +
[22:28] <ahoneybun_> bbl crap
[22:28] <yofel> k
[23:08] <valorie> Riddell: went well
[23:08] <valorie> I might blog about it today
[23:09] <ahoneybun_> back
[23:12] <yofel> ahoneybun_: wb
[23:12] <ahoneybun_> thanks
[23:13] <yofel> ok, so lets do things strictly by handbook and add nokia
[23:13] <yofel> as our first section is for any file, we don't need to add any
[23:14] <yofel> now, annoyingly one file is only gpl-3, so lets add that
[23:17] <yofel> and add a new full section for the GPL-3, as that was missing
[23:18] <yofel> ahoneybun_: so that concludes our work for GPL-3+
[23:18] <yofel> on to the next license..
[23:18] <ahoneybun_> ok then
[23:19] <yofel> licensecheck didn't find anything GPL-3-only, so that's fine too
[23:19] <yofel> next one is GPL-2+
[23:20] <yofel> here we now have a different license than the package default, so we need to list the affected files
[23:20] <ahoneybun_> ?
[23:20] <yofel> for GPL-3+, we just had "Files: *"
[23:20] <yofel> now we have a list of files - that are GPL-2+, not GPL-3+
[23:21] <yofel> as in: all files in the package are GPL-3+, *except* ...
[23:21] <ahoneybun_> that works no?
[23:22] <yofel> it does, if it weren't for those 2 id3v2tag.* files
[23:22] <yofel> better :)
[23:23] <yofel> now go by the pattern from before
[23:29] <yofel> sorry
[23:30] <ahoneybun_> ? nothing new there
[23:30] <yofel> nope
[23:30] <yofel> wait
[23:31] <yofel> always do a check whether any new people are there now
[23:31] <ahoneybun_> so that is how you do that
[23:31] <ahoneybun_> ok let me add them
[23:33] <ahoneybun_> cant copy and paste?
[23:33] <yofel> hm, should work..
[23:33] <yofel> the files are already there though
[23:33] <ahoneybun_> I forgot shift
[23:33] <yofel> first 2 at least
[23:35] <yofel> wait, those are wildcards
[23:35] <ahoneybun_> ?
[23:35] <yofel> no need for * if you put the full filename
[23:35] <yofel> * means 'any character 0 or unlimited times'
[23:36] <yofel> the colons shouldn't be there
[23:36] <yofel> they're just part of the grep output
[23:37] <ahoneybun_> right?
[23:37] <yofel> right
[23:37] <ahoneybun_> cool
[23:38] <ahoneybun_> good?
[23:38] <yofel> right intention
[23:39] <yofel> but shortened too much
[23:39] <yofel> 2002 wasn't in the list
[23:39] <ahoneybun_> I see
[23:40] <yofel> ok
[23:40] <yofel> now let me check something
[23:40] <ahoneybun_> k
[23:41] <yofel> ok fine, I like looking at the headers themselves just to make sure it's not some weird combined license that licensecheck misunderstood
[23:41] <yofel> not the case here )
[23:42] <yofel> ok, we're done with the GPL section
[23:42] <yofel> now to check if there's anything else GPL-like
[23:43] <yofel> oh yay, LGPL with kde clause
[23:44] <yofel> hm, now that's LGPL-2.1+, not LGPL-3+ as the copyright file says
[23:46] <yofel> as there is no LGPL-2.1+ explained at the bottom, we need to add that
[23:47] <yofel> and as there is no file with LGPL-3+ anymore we can remove that part
[23:48] <yofel> now we're done with anything GPL (for now)
[23:48] <yofel> so lets look for any other licenses
[23:48] <yofel> or hm
[23:49] <yofel> lets stay with the LGPL ones for now
[23:51] <yofel> kdsingleapplicationguard is a problem because it shows a limitation of licensecheck that doesn't fit with the real world
[23:51] <yofel> by default licensecheck only looks through source code files to find licenses
[23:52] <yofel> kdsingleapplicationguard does it... differently :/
[23:53] <yofel> ahoneybun_: wait
[23:54] <yofel> ahoneybun_: I was checking something for a sec, where are you now?
[23:54] <ahoneybun_> checking lgpl for kertz
[23:55] <yofel> ok
[23:55] <ahoneybun_> that does not work
[23:56] <yofel> see the output from before
[23:56] <ahoneybun_> just those
[23:56] <yofel> licensecheck doesn't understand the kde clause in the file, so can't tell the version
[23:56] <ahoneybun_> so check each file?
[23:56] <yofel> yes
[23:58] <yofel> ahoneybun_: tip: first grep for copyright, so you see which files are worth checking
[23:58] <yofel> most in there have nothing in them
[23:58] <ahoneybun_> let me see
[23:58] <ahoneybun_> show me that please
[23:59] <yofel> so we see there's only one file with copyright information
[23:59] <yofel> and that's the part we're interested in


[10:48] <oblio> hi all
[10:49] <troy_s> greets oblio
[10:52] <oblio> I want to do a mouse-pointer for the left-handed users: an arrow aiming to N-E. It seems such a package has been introduced in the Fedora-6 distro. Many thanks for any idea !
[10:55] <troy_s> oblio: It is very easy to do
[10:56] <troy_s> If you want to just mirror the current cursors, simply go get jimmac's work from his site
[10:56] <troy_s> and flip them using gimp
[10:56] <troy_s> from there, you compile them into cursors using xcursorgen if i recall.
[10:59] <oblio> anyway the command :  xsetroot -cursor_name right_ptr    'rezists'  some seconds...
[11:01] <oblio> many thanks ! I'll try...Thank you...
[11:04] <oblio> by all !linux