[00:01] <zooko> Oh, ok.
[00:22] <TomaszD> this is madness, gdebi reports my package as broken, but dpkg installs it without ever complaining
[00:23] <TomaszD> lintian does not offer any help, everything seems to be fine
[00:23] <TomaszD> *sigh*
[00:24] <ScottK> TomaszD: If dpkg installs it, but gdebi doesn't then I'd call that a bug in gdebi.
[00:25] <TomaszD> ScottK, I just hacked up the linux-image deb, adding a few drivers, adding md5sums, put it back together, installed it on a test machine using dpkg, works great, gdebi complains
[00:26] <ScottK> So complain back.
[00:26] <TomaszD> ScottK, I'm still not sure if it's my fault
[00:26] <TomaszD> I didn't update the changelog, for one
[00:27] <ScottK> If dpkg understands  it, not your fault is a reasonably safe assumption.
[00:27] <TomaszD> I'll see what lintian says about the original package and then I'll complain
[00:28] <TomaszD> huh, exactly the same results, it's not my fault then
[00:29] <stefanlsd> Is there anyway to get stats on how many people use a certain package?
[00:30] <Flannel> stefanlsd: kinda sorta not really.
[00:31] <stefanlsd> heh. was just wondering how you figure out if a package should be removed
[00:31] <TomaszD> ok, lol, my fault it is, left a test file that obviously doesn't have an md5 in md5sums :P
[00:31] <ScottK> stefanlsd: It's more commonly dead upstream, serious unfixed bugs for a long time, stuff like that, not user base.
[00:32] <stefanlsd> ScottK: mm. ok.  Im busy looking at a sync request for diald and there's an upstream version also, but it was last done in 2001 and it hardly compiles without changing stuff
[00:33] <stefanlsd> ScottK: but i see the debian guys for the previous version did change some of the stuff that wasnt changed upstream
[00:33] <ScottK> Then you probably want to keep the Debian fixes.
[00:47] <directhex> stefanlsd, debian has opt-in tracking for what's installed, to show how many people use a given package
[00:49] <ScottK> directhex: Ubuntu has the same.
[00:49] <directhex> ScottK, so it does. i don't like recommending debianish packages, in case they're not directly applicable
[00:50] <directhex> not searchable though. how annoying
[01:25] <stefanlsd> Would anyone know why this happens in pbuilder when i try build - /usr/bin/install -c -d -m 0755 /etc/pam.d        [new line]    /usr/bin/install -c -o root -g root -m 0644 config/diald.pam //etc/pam.d/diald     [new line]      /usr/bin/install: cannot create regular file `//etc/pam.d/diald': Permission denied
[01:29] <slangasek> stefanlsd: because your package needs to redirect the upstream build rules to not try to install files in the real root directory
[01:30] <slangasek> stefanlsd: it needs to be installing to a subdirectory of your build tree instead, where the installed files can then be gathered back up for packaging
[01:32] <stefanlsd> slangasek: ok. thanks. i see thats happening in the Makefile.in
[02:06] <emgent> hello
[02:37] <gastoni> I want to upload a package to REVU
[02:38] <gastoni> I already have my launchpad account and I have setted my pgp key
[02:38] <gastoni> this is what is confusing me: dpkg-buildpackage -S -sa -rfakeroot
[02:40] <RAOF> What part of that is confusing?
[02:41] <gastoni> not sure of what It'll do, I've read the motu wiki, bt still not clear
[02:42] <gastoni> the output of that command, is what I have to puload?
[02:43] <RAOF> Yes.
[02:44] <RAOF> Well, rather, the _source.changes file.
[02:44] <dldc> hello
[02:44] <dldc> i need help on packaging, someone around ?
[02:44] <persia> gastoni: Specifically, that command will build a source package from the modified local sources.
[02:46] <gastoni> my package has this name: conkygui_v12_all.deb
[02:46] <gastoni> how do I issue the command, I can't get it to work
[02:49] <dldc> http://pastebin.ubuntu.com/33213/
[02:49] <dldc> error:
[02:49] <dldc>  debian/rules build
[02:49] <dldc> dh_testdir
[02:49] <dldc> # Add here commands to configure the package.
[02:49] <dldc> cp -f /usr/share/misc/config.sub config.sub
[02:49] <dldc> cp -f /usr/share/misc/config.guess config.guess
[02:49] <dldc> ./configure --host=i486-linux-gnu --build=i486-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info CFLAGS="-g -O2" LDFLAGS="-Wl,-z,defs"
[02:49] <dldc> ./configure: 6: Syntax error: "(" unexpected
[02:49] <dldc> make: *** [config.status] Error 2
[02:49] <dldc> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[02:49] <dldc> pbuilder: Failed autobuilding of package
[02:50] <dldc> Can you help me? :-]
[02:50] <persia> gastoni: How did you create your ,deb file?
[02:51] <persia> dldc: It looks like you've some syntax error in ./configure.  Have you looked there?
[02:51] <dldc> persia: http://pastebin.ubuntu.com/33213/
[02:51] <dldc> is good
[02:52] <gastoni> with the dpkg -b command, http://ubuntuforums.org/showthread.php?t=876537
[02:52] <persia> dldc: The problem isn't with debian/rules, it's with ./configure
[02:53] <persia> gastoni: Ah.  I wouldn't start from there :)
[02:53] <persia> !packaging
[02:53] <persia> gastoni: You might do well to review the packaging guide.  That will help you construct a source package (you have a binary package now).  REVU only accepts source packages.
[02:54] <dldc> persia http://pastebin.ubuntu.com/33214/
[02:54] <gastoni> awh damn
[02:54] <gastoni> persia: so, to build a source package with java, which is the general idea?
[02:55] <gastoni> to package the sources with a shell script that will compile them druing installation?
[02:55] <dldc> persia found error? :-[
[02:55] <persia> gastoni: Usually one uses ant or something rather than a shell script, and calls it from debian/rules
[02:56] <gastoni> wouldn't people need JDK if they want to install my package, then?
[02:56] <persia> dldc: No, but I suspect it is in the function definition
[02:57] <persia> gastoni: They would.  Your package should Depend on the JDK
[02:57] <dldc> if i put only "./configure" in debian/rules same error :-[
[02:58] <persia> dldc: Yes.  You need to verify that the function definition works with dash
[02:58] <dldc> but, if i run in my box ./configure work fine
[02:58] <gastoni> persia: but a normal user doesn't install JDK, they just use JRE. right?
[02:58] <gastoni> persia: wouldn't that be an annoyance for the common user?
[02:59] <dldc> oh no wrong
[02:59] <dldc> same error if i run it in my box
[02:59] <dldc> :-[
[02:59] <persia> gastoni: I think http://www.debian.org/doc/manuals/debian-java-faq/ch6.html#s6.5 is roughly what you want (although, yes, there should be a better one)
[03:00] <persia> gastoni: There are two sorts of packages: source packages and binary packages.
[03:00] <dldc> persia Suggests to solve it ?
[03:00] <persia> Developers work on source packages, and make the changes there.  These source packages are then fed to the buildds, which run sbuild against them to generate binary packages, which are installed on user machines.
[03:01] <persia> Your source package will need a JDK to build, but your binary package probably only needs a JRE
[03:01] <gastoni> damn, packaging is a lot harder than I though
[03:02] <gastoni> I'll stick to the binary for while
[03:03] <persia> gastoni: OK.  I'm fairly sure there will be a MOTU School session on Java packaging in the next few months: you may want to watch for that, and try again then.
[03:03] <gastoni> AH, perfect
[03:03] <gastoni> how can I see/read those sessions?
[03:04] <gastoni> anyone here is interested to join me in my project, Conky GUI, as a packager?
[03:05] <persia> dldc: Looks like dash doesn't support "function".  Patching that away might help.
[03:14] <jmarsden> gastoni: See https://wiki.ubuntu.com/MOTU/School for school sessions.  Is your package currently build using GNU Autotools?
[03:24] <gastoni> GNU autotools?? I just made the control file and dpkg took care of everything else
[03:33] <jmarsden> gastoni: No, I meant for building the .jar from sources, for example... looks like you just used Ant instead...
[03:33] <gastoni> jmarsden: oh, I just clicked "build" in netbeans
[03:34] <jmarsden> gastoni: OK.... that won't work too well for automated builds in REVU, for example :-)
[03:36] <RAOF> Or be in any way acceptable to the archive-admins.
[03:36] <gastoni> ah ok, so i have to compile by hand, geez
[03:37] <RAOF> If it's not built from source, we don't want it.
[03:39] <crimsun> (in universe.)
[03:39] <gastoni> it si buitl from source, I wrote the program
[03:39] <wgrant> crimsun: We've lived without it for years, so we don't want it in multiverse either.
[03:39] <gastoni> which is the difference???
[03:39] <wgrant> gastoni: It needs to be automatically buildable.
[03:40] <crimsun> wgrant: oh I agree, I'm just thinking of the many source packages that either retrieve binaries from the 'net or simply bundle a binary.
[03:41] <crimsun> e.g., flashplugin-nonfree and eagle, respectively
[03:41] <wgrant> Right.
[03:41] <gastoni> wgrant: what does "automatically buildable" means?
[03:41] <wgrant> gastoni: I should be able to build it by running dpkg-buildpackage.
[03:41] <wgrant> s/should/must/
[03:42] <gastoni> it is enough if its build by running dpkg --build ???
[03:44] <wgrant> I don't believe so.
[03:44] <gastoni> ok ok, I guess I'll have to read more about all this
[03:45] <jmarsden> gastoni: See https://wiki.ubuntu.com/PackagingGuide/Complete
[03:45] <RAOF> gastoni: Basically, running dpkg-source -x on the source package, editing the source files in the tree it extracts, and then running dpkg-buildpackage should result in your changes propogating to the package that gets built.
[03:50] <gastoni> a ok thank you for all your help
[04:02] <ScottK> Three cheers for packages using the new Debhelper 7 format so I have to be inside an Intrepid chroot to even build the source package.
[04:03] <ion_> ;-)
[04:03] <ion_> Progress hurts.
[04:07] <persia> ScottK: You probably wanted to be in a intrepid chroot for building the source package anyway: that way you get any modifications to the tools that run debian/rules clean
[04:09]  * ScottK starts to wonder about some control file entry for source package versioned build depends.
[04:10] <persia> Yeah, well, that's been a persistent issue for more years than Ubuntu existed.  I suspect that the current requirement that Debian uploads include a sid binary is in part an attempt to work around it.
[04:22] <ScottK> I can understand perhaps using the simplified debhelper 7 rules for a new package.  I don't get rewriting an exisiting and working rules file ...
[04:23] <RAOF> I can perhaps think of a time when I'd do that, but in general, no.  What package is that?
[04:24] <ScottK> libnet-ssleay-perl.
[04:24] <ScottK> It's just a fricking Perl module.
[04:24] <ion_> Refactoring code is usually a good thing, and what you’re talking about is just hiding stuff you don’t need to care about behind an interface that handles the dirty work, so that future maintenance becomes more enjoyable.
[04:25] <ScottK> I guess that's one way to look at it.  I look at it more like doing work to change something from something that works to something that works.
[04:26] <RAOF> But debian/rules isn't terribly complicated to begin with, and unless you're starting out it's a bit impolite to require intrepid to do anything to the package.
[04:27] <ScottK> The Debian guy isn't required to worry that he's inconveniencing me, I just think it's an odd way to spend your time.
[04:28] <persia> RAOF: But it's acceptable to require lenny to do anything with a package targeted at lenny, which we inherit.
[04:28] <RAOF> persia: Right.  I was thinking this was an Ubuntu change.
[04:28] <ScottK> No, I'm updating a merge.
[04:28] <persia> RAOF: Oh.  I can't think of a good excuse for that.
[04:29] <ScottK> The new uploader in Debian managed to add a lintian over-ride for a line to long somewhere, but missed our patch that fixed an FTBFS on 64bit.
[04:29] <RAOF> Whoops.
[04:30] <ScottK> I'm going to see if they have it in their BTS already or not.
[04:31] <ScottK> Of course it was uploaded on Lenny freeze day, so it may have been a bit hurried.
[04:31] <persia> may?
[04:31] <ScottK> It could have been planned for then all along.
[04:32] <ScottK> Ah, it builds on Debian OK anyway.
[04:32] <persia> I suppose, although I'd think the one-week warning would have caused most of those to go in a day or two ahead of schedule
[04:32] <ScottK> Cheers for Debian/Soyuz sbuild differences.
[04:33] <persia> I don't mind that so much: it's the Ubuntu/Soyuz sbuild differences that catch me every time.
[04:33] <ScottK> It's funny how the freeze stuff goes.
[04:34] <ScottK> I maintain 9 packages in Debian.  I knew one needed some minor work and uploaded that 2 days before the freeze.
[04:34] <ScottK> In the 48 hours before the freeze I uploaded 4 of the other 8.
[04:35] <ScottK> All for stuff I didn't know about more than 48 hours before the freeze.
[04:35] <ScottK> All the planning in the world wouldn't have helped me.
[04:43] <NCommander> RainCT, ping
[05:02]  * No1Viking is away: BBL
[05:10] <bd_> Is there a procedure or tag or something for requesting a (no source changes) rebuild in universe?
[05:23] <LimCore> hello
[05:23] <LimCore> Im trying to package FLTK 2 library
[05:23] <LimCore> what do you think about following directory layout for it
[05:24] <LimCore> prefix="/usr/lib/fltk2/"   so  /usr/lib/fltk2/lib/*.a  /usr/lib/fltk2/include/*.h*  and /usr/lib/fltk2/bin/fltk-config
[05:24] <LimCore> it would reasemble closelly upstream (and overall development libs practise)
[05:24] <RAOF> No, I don't think it would.
[05:24] <LimCore> why not?
[05:25] <RAOF> Firstly, *.a is probably not very useful.  Secondly, headers go in /usr/include, thirdly the libs should go in /usr/lib
[05:25] <LimCore> yeah, I ment libfltk2-dev
[05:25] <LimCore> not just for users
[05:26] <LimCore> Hmm, /usr/lib/fltk2/*  seems more organized to me, then having bunch of files in /usr/include/ from various libs.
[05:26] <RAOF> So, you want to be reading the library packaging guide.
[05:27] <RAOF> LimCore: With the big disadvantage that nothing will link against anything in /usr/lib/fltk2
[05:27] <LimCore> yes Im going to do that,  but Im wondering about selecting this pathes
[05:27] <RAOF> It's not in LD_LIBRARY_PATH
[05:27] <RAOF> LimCore: The path you should use are spelled out in that policy.
[05:27] <LimCore> hmm
[05:28] <LimCore> well, it's not like Jesus stepped down and give us the policy on 2 stone blocks, never to be upgraded? :)
[05:28] <RAOF> Correct.  On the other hand, the way to upgrade it is to discuss in on debian-devel.
[05:28] <LimCore> not on ubuntu-devel?
[05:29] <RAOF> If it doesn't follow the policy (or have good reasons where it doesn't), it's not going in the archive.
[05:29] <RAOF> I'd say debian-devel; this is very much a Debian level policy.
[05:29] <LimCore> fltk2 can follow it, no problem.  I was just thinking thta I would organize it other way, to have each lib more self contained dir
[05:29] <LimCore> mhm ok
[05:30] <RAOF> Welcome to linux.  We do things differently :)
[05:31] <LimCore> what do you mean?  I liked the defaul FLTK (and wx.. and probably most libs?) behaviour, where all library files go to one dir, and are in {$prefix}lib  ${prefix}include  etc
[05:31] <LimCore> on linux
[05:32] <RAOF> Certainly, includes go in $prefix/include, generally as a sub-directory.
[05:32] <RAOF> But all the libraries go in /usr/lib, because if they're _not_ there then nothing can link against them.
[05:33] <LimCore> uhm wait.. ok..  the /usr/local/LIBNAME  was my idea <_< not fltk2 default huh
[05:33] <LimCore> stil I think its a good idea =)
[05:34] <LimCore> ok anyway, I will make it for  prefix=/usr/
[05:35] <LimCore> about the linking problem, are you sure?  Isnt extra option for proper LD_ included in the binary when it is build on system where libs are in say /usr/local/libname/
[05:35] <RAOF> Well, yes.  You have to use prefix=/usr
[05:35] <RAOF> LimCore: Nope.  In fact, having such an RPATH is against policy, and you should strip it out.
[05:35] <LimCore> mhm
[05:35] <LimCore> so, ELF can contain extra path to look for libs, but it should be not used right?
[05:35] <RAOF> Correct.
[05:36] <LimCore> ok
[05:36] <RAOF> Applications should say "I need libfoo.so.6", and it's up to the ld.so to provide that to it.
[05:36] <LimCore> on a similar topic
[05:37] <LimCore> how about making more packages using  ~/etc/ instead brain dead ~/.foo for configs?
[05:37] <persia> bd_: Not really.  They require a new source upload (changelog changes only).
[05:37] <bd_> persia: oh.
[05:37] <ion_> limcore: A freedesktop spec says ~/.config/appname
[05:37]  * LimCore hates how ~ is littered with 100 config files
[05:37] <persia> LimCore: /etc/ is used for system-wide config, ~/.foo is used for user-specific configs.
[05:37] <LimCore>  ~/etc  not /etc
[05:38] <RAOF> LimCore: XDG basedir spec
[05:38] <LimCore> ion_: I know, and I think, with respect to freedesktop etc etc, this is totally stupid idea
[05:38] <persia> No, ~/etc is just not idea.  ~/.config/ is a little better, although it's just hiding stuff that was hidden anyway (that's the leading .)
[05:38] <persia> s/not idea/not ideal/
[05:38]  * persia uses ~/etc for other things
[05:38] <LimCore> afair, ~/etc/ is a standard among some developers, but it got adopted only in some places (BSD?)
[05:39] <ion_> persia: Not only hiding stuff, but grouping things with the same function into their own subdirectory. I like that.
[05:39] <LimCore> which is sad...  consider backing up your configuration files.   And consider when in time ~ is filled with like 150 config files making it look chaotic
[05:39] <LimCore> more exactly,   ~/etc/appname   or  ~/etc/.appname
[05:40] <persia> ion_: I guess, although I rarely want to perform an operation on all of them, and tend to treat each application differently.
[05:40] <ion_> I’ve never seen an application using ~/etc (and i’d hate to see one), but i seem to have 36 entries in ~/.config
[05:40] <persia> LimCore: Why is it important that the subdirectory of the home directory be called "etc"?  What is wrong with ".config"?
[05:40] <LimCore> .config is also good
[05:41] <persia> LimCore: Ah, so you don't think ~/.config/ is a totally stupid idea :)
[05:41] <LimCore> no, its good
[05:42]  * persia misinterpreted backscroll then
[05:42] <ion_> Dotti
[05:42] <ion_> Uh. Ditto
[05:42] <LimCore> what I do not like, is to have 100 directories directly inside ~  because   1) its littering my home   2) its harder to backup
[05:42] <persia> 1) is supposed to be covered by the convention that .??* is hidden from view.  I don't understand why you claim 2)
[05:43] <NCommander> RAOF, you got a minute
[05:43] <LimCore> overall I want to see hidden files
[05:44] <LimCore> persia:  tar ... ~/.config      overall, one big directory with all configs (like ~/.config/) is more organized, therefore easier to backup, restore, compare, etc
[05:44] <persia> LimCore: I guess.  I tend to backup /home
[05:44]  * NCommander just does a recursive backup of /home/mcasadevall
[05:45] <NCommander> tar cjmgf
[05:45] <ion_> persia: Splitting e.g. ~/.foorc, ~/.bardatabase and ~/.bazcache (things of all three categories in the same tree level) to ~/.config/foo/rc, ~/.local/share/bar/database and ~/.cache/baz/whatever is really nice. Although .cache could have been .local/cache IMO.
[05:45] <LimCore> so, since some apps are already using .config   how hard would it be to make most use it?
[05:45] <ScottK> Hard.
[05:45] <LimCore> ion_: that is a nice idea too
[05:46] <persia> LimCore: Typically a trivial source change.  Mind you, it's probably 10,000 individual changes.
[05:46] <persia> Also, it's the sort of change that is typically only accepted upstream.
[05:46] <ScottK> Death of 1,000 cuts.  Hard.
[05:46]  * LimCore 's program will have a --path-etc 
[05:46] <ion_> Not to mention making them migrate from old config to ~/.config
[05:47] <persia> ion_: I see the point, although I'm skeptical of the value of trying to do it at a distro-level.
[05:47] <persia> LimCore: How about --user-config to make it clear to more people?
[05:47] <ion_> persia: I’m not advocating doing that, though i’d prefer upstreams to migrate to XDG basedirs.
[05:48] <persia> ion_: I guess.  I'm not happy with XDG basedirs for lots of other reasons: mostly having to do with i10n
[05:48] <LimCore> whats the problem, persia
[05:49] <persia> LimCore: strcmp("Desktop", "デスクトップ"); doesn't return true.
[05:49] <jmarsden> LimCore: tar zcf /path/to/backup/somefile.tar.gz ~/.[!.]*   # should do your config backup for you
[05:50] <LimCore> jmarsden: unless I have ~/.myporn
[05:50] <LimCore> not all hidden files in ~ are configs
[05:50] <ion_> I have my “Desktop” in ~/.local/share/desktop ;-)
[05:50] <ion_> One thing less polluting my precious ~
[05:51] <persia> ion_: It's not that way by default.  If that is how XDG basedirs is supposed to be implemented, all the better.
[05:51]  * LimCore installs VISTA to ion_'s ~
[05:51] <NCommander> LimCore, thats just evil
[05:51] <ion_> Yeah, not by default, but thanks to Gnome’s XDG basedir compliance, i was able to move it there easily.
[05:51]  * NCommander watches gameplay of Deadly Towers
[05:52] <persia> ion_: Do you have some fancy run-time overlay that maps localised names in ~ to ./local/share/foo ?
[05:52] <persia> (if so, I want it)
[05:52] <ion_> persia: I just set XDG_DESKTOP_DIR="$HOME/.local/share/desktop" in ~/.config/user-dirs.dirs and moved the directory.
[05:52] <persia> ion_: Ah, so it's still a specific localised name :/
[05:53] <LimCore> names like Desktop should not be localized
[05:53] <LimCore> thats just idiotic
[05:53]  * LimCore mv /usr /użytkownika  ; mv /lib /biblioteki
[05:53] <persia> LimCore: Why?  Many people don't understand the word "Desktop", and may not be able to read any of those characters.
[05:54] <LimCore> I mean the directory names
[05:54] <LimCore> GUIs could translate it
[05:54] <persia> Yes, so do I.
[05:54] <LimCore> why?  for same reason /home is not /dom
[05:54] <persia> Erm.  It's a lot easier for there to be a filesystem overlay that provides the localised names rather than having *every* GUI change.
[05:54] <LimCore> or just ln -s
[05:55] <persia> LimCore: Well, at a primitive level that works, but tends to get awkward if you switch your locale.
[05:55] <jmarsden> LimCore: I don't want 15000 symlinks cluttering up my ~ thankyou... how many langauges are there... :-)
[05:56] <ion_> jmarsden: The symlink way is not the perfect solution, but it wouldn’t have to implemented *that* badly. :-)
[05:56] <LimCore> ln -s Desktop Desssssssssssktop # python language
[05:56] <jmarsden> ion_: How woudl you decide which languages to provide symlinks for?
[05:56] <persia> Hundreds, and there are 7 basedir names
[05:56] <ion_> jmarsden: By looking at the user’s locale settings.
[05:57] <persia> jmarsden: One way would be to generate symlinks on session start, and clean up on session end (or do cleanup on session start for crash recovery).
[05:57] <ion_> I’m not advocating the proposed symlink way, just speaking hypothetically.
[05:58] <jmarsden> Then I log in in one language but start thinking in another and ... aargh, my dirs are not there they disappeared... ugh.
[05:58] <persia> Ah.  ISO 639 provides for 17,029 possible languages (not all are currently implemented)
[05:59] <LimCore> wtf
[05:59] <LimCore> some countires really should stop heaving more then 5 languages heh
[05:59] <persia> jmarsden: Presumably you tend to log in to a locale in which you think, or are doing specific testing.  If you need multiple simultaneous language support, there are greater issues.
[05:59] <persia> That said, on-the-fly locale switching would be interesting (if tricky to implement)
[06:02] <persia> Also, if one implements it with something like ~/.local/share/$(XDGNAME) one has a static representation available for scripting, etc.
[06:04] <jmarsden> Yes, the current implementation offers to rename them at session startup, which could make locale-independent scripting awkward
[06:06] <persia> Yes indeed.
[06:07] <persia> I still think a FUSE layer to generate the apparent directories without bothering with symlinks would be even better, but it's probably more work.
[06:08] <NCommander> persia, maybe not, writing FUSE plugins isn't qutie as bad as most other things
[06:08] <NCommander> (although file system plugin development is the kings displine)
[06:08] <NCommander> persia, mind if I steal you for a moment to get an advocation of a package ;-)
[06:08] <persia> NCommander: Fell like giving it a shot?  A plugin would also work.
[06:08] <persia> NCommander: Yes, because I just got the phone call saying I'm supposed to head somewhere else.
[06:09] <NCommander> persia, d'oh :-P. Bad timimg on my part
[06:09] <NCommander> persia, I've only been half paying attention to the conversation
[06:09] <LimCore> if I would develop small LGPL user application, and provide correct ubuntu scripts/package, how long can it take to take it to officiall repos?
[06:10] <NCommander> LimCore, not long, post it to revu, and then ask some MOTUs to sponsor
[06:10] <NCommander> LimCore, once its in the archive, just post an updated .diff.gz/dsc file as a bug, and add universe sponsors to update it
[06:10] <ion_> Anyone feel like reviewing http://revu.tauware.de/details.py?package=compcache-setup? Thanks.
[06:17] <LimCore> btw
[06:17] <LimCore> how about naming binaries with some extension?
[06:17] <LimCore> like  foo.elf
[06:18] <LimCore> the default of empty extension for binaries is unfortunate for scripting, processing, sorting, etc
[06:18] <LimCore> (obviously common utilities like cp mv ls must always remain how they are)
[06:21] <bluefoxicy> why?
[06:21] <bluefoxicy> file /bin/ls
[06:21] <dholbach> good morning
[06:24] <ion_> limcore: The fact that some pieces of software opt to decide the file type based on its extension is very unfortunate.
[06:25] <ion_> The filenames are *only* for humans. If it is deemed beneficial for humans that the name also tells its type, fine, but software should not base its decision of the type only on it.
[06:25] <LimCore> ion_: I don't agree, considerf
[06:26] <LimCore> * consider, how would you write a script to resize all your jpg images?
[06:26] <ion_> In a perfect world, find foo -mime image/jpeg blahblah
[06:27] <LimCore> noone does that
[06:27] <LimCore> plus, your solution would try to resize my  randomdata.nr04329432 file
[06:27] <LimCore> and/or my dump of encrypted partition, etc
[06:28] <ion_> No, it wouldn’t.
[06:29] <LimCore> file utility does FULL parsing of a jpeg image, or just looks and part of file that /seems/ to be a header
[06:29] <LimCore> but also can be random data
[06:30] <LimCore> I think perfect script would find *.jpg[e] , and then file them to confirm
[06:30] <LimCore> .jp[e]g
[06:31] <ion_> That would fail with images/Foo, which happens to contain JPEG data.
[06:32] <LimCore> so "Foo" is the file name?
[06:32] <ion_> See Windows® for the worst example: deciding that it’s executable because its human identifier happens to end with the string “.exe”
[06:33] <ion_> s/example/case/
[06:33] <LimCore> this is a good example, if you think about it more
[06:33] <LimCore> I mean, its the right thing to do
[06:33] <ion_> Ha! :-)
[06:33] <LimCore> at first look, it looks noob
[06:33] <jmarsden> Since when is executing a JPG the right thing to do?
[06:33] <LimCore> but then, using some data as JPG just because first N bytes /seem/ to look like jpeg, is as wrong
[06:34] <LimCore> jmarsden: executing?  we talk about finding jpeg's (to resize them, in script)
[06:34] <jmarsden> If you have one named foo.exe then by your reasoning the right thing to do with ti ti always to execute it.
[06:35] <jmarsden> s/ti ti/it is/
[06:35] <LimCore> no
[06:35] <LimCore> do action for jpeg, if file is named *.jp[e]g AND if it is the proper file type (header)
[06:36] <jmarsden> You said that  deciding that it’s executable because its human identifier happens to end with the string “.exe”  is "the right thing to do"  -- I think!?
[06:36] <LimCore> yes, but still check the actuall file type (header)
[06:38] <jmarsden> If you can determine a file's type from the header, then it's type is independent of its name.  If you can;t fully do so because of random weird exceptions, then requiring both name.exe *and* a header still doesn't get you 100% (encrypted filesystem saved as junk.exe)...
[06:38] <LimCore> overall the point was:    file extensions are helpfull for people to sort and oraganize files, obivously.  Too bad that executables are human-identified by an EMPTY extension.  How about introducing another extension, like  .run  or .elf    That would make it nicer for users.
[06:39] <jmarsden> LimCore: Only for users who identify files that way.. as in, users trained in the ways of MSDOS.
[06:39] <LimCore> why that way is wrong?
[06:39] <jmarsden> Better to absorb a little of the culture they are migrating into.
[06:39] <LimCore> jmarsden: foo.jpg.  What is it?  (normally) ?
[06:39] <ion_> A typo :-) It’s jpeg.
[06:39] <LimCore> foo.html is what?
[06:39] <LimCore> and foo is...?
[06:40] <ion_> media/text/todo: UTF-8 Unicode text
[06:40] <LimCore> on windows world, "foo.exe" is executable.  Nicer to talk about it, search for it, etc.  Linux lacks this
[06:41] <LimCore> Linux user can say "send me the JPEGs" or "send me the PDF version"  but can not say "send me the exe"
[06:41] <jmarsden> Different OS worlds have different conventions and different expectations.  If you prefer those of one world, live and work and play in that one... :-)
[06:41] <LimCore> we could fix that by adding say .elf
[06:41] <LimCore> or .run  (I do not like .bin)
[06:42] <LimCore> jmarsden: windows/dos got that one better then linux, so we could incorporate the better idea.  Unless "foo" is nicer for humans then "foo.run" for some reason?
[06:42] <ion_> Then you would lose the possibility to replace the file with an alternative implementation in a different format.
[06:42] <jmarsden> LimCore: It is shorter to type, too.
[06:42] <LimCore> I like foo.elf,  but since not all is ELF as ion_ noted,  foo.run could be generic
[06:42] <ion_> Yeah, much better than Linux. Just look at all the virus attachments called foo.jpeg.exe, with the OS helpfully hiding part of their human name. :-)
[06:42] <jmarsden> and I used Linux when the standard binary executable format was a.out ...
[06:43] <LimCore> ion_: how this argument makes any sense? is it FUD =) ?
[06:43] <ion_> Just pointing out the system’s idiocy.
[06:43] <LimCore> which doesnt have nothing to do with good/bad evaluation of foo.run right?
[06:44] <jmarsden> So what are .BAT files in Windnows... why are they not named .EXE since they are executable?  Likewise, if I install a JRE do I need to rename all *.jar files to *.exe or *.run now, since they just became executable?  The whole thing breaks down.
[06:44] <LimCore> hidding part of file name is stupid. assuming there is just one "." in file is stupid too.  I'm not proposing either of that
[06:45] <ion_> Feel free to call it foo.run if you deem it to be helpful for a human, but please don’t kill the functionality which parses the file’s header to decide how to run it. :-)
[06:45] <ion_> File names are only for humans. Computers could live with plain inode numbers.
[06:45] <LimCore> jmarsden: lets leave .sh and .jar  as they are.  But add .elf for elf flies.   And .run as general indication that this file is some program
[06:45] <ion_> Btw, calling stuff in $PATH foo.run is not helpful for humans.
[06:45] <ScottK> I thought that was .exe
[06:45] <LimCore> ion_: yes, this is my idea.  renaming to .foo does not brake file, but it helps humans
[06:46] <LimCore> ion_: leave standard tools like  ls mv dd tar apt-get etc, as they are.  Use new for bigger new applications.
[06:46] <LimCore> I think some applicaions do that already
[06:46] <jmarsden>  for i in /bin/* /usr/bin/* ; do file $i |grep -sq executable && mv $i $i.run ; done  # would be cool on your system, then, right?  Go ahead and try it :-)
[06:47] <LimCore> yes they do:  /usr/lib/openoffice/program/soffice.bin
[06:47] <ion_> Either of the facts that it has the executable bit on *and* it resides in the binary directory is enough for me as a human. :-)
[06:47] <LimCore> ion_:  www.omg.com/foo  what is it?
[06:47] <LimCore> ion_:  www.omg.com/foo.exe  what is it?
[06:47] <LucidFox> Gah, why does _every_ management program for iriver only support MTP?
[06:48] <LucidFox> Does nobody use UMS, or what?
[06:48] <LimCore> (and don't start FUD with "its a virus" =)
[06:48] <ion_> limcore: http://www.w3.org/Provider/Style/URI “What to leave out”
[06:49] <LimCore> ion_: .run will not change
[06:49] <ion_> limcore: I’ve replaced multiple http://something/foos where foo is a JPEG with a HTML page that displays the JPEG without the URLs breaking.
[06:49] <LimCore> its for another use case
[06:50] <LimCore> "Download https://test.com/foo.exe"  - this is obviously an information to get a program
[06:50] <LimCore> in linux world this is not as comfortable
[06:50] <ion_> Please don’t abuse the word FUD. The fact that Windows® doesn’t require an executable bit to be set for it to run stuff is just plain wrong. That statement is not spreading FUD.
[06:51] <jmarsden> LimCore: Now imagine files on a shared filesystem that are executable on PPC machines ... should they be named .run even if they do not run on x86 machines?  Or do we have to create special file system overlays so only files that are executable on one particular architecture are seen as being .run files?
[06:51] <LimCore> it is indeed worng; I was saying that it would be FUD to say that there shouldnt be any binaries on www anyway
[06:51] <jmarsden> LimCore: In the Linux world we do not geenrally pass random executable binaries around...
[06:51] <LimCore> jmarsden: I would name them  foo.i386.run  foo.ppc.run etc
[06:51] <jmarsden> Very short to type... nice... ?
[06:52] <LimCore> https://x.com/foo
[06:52] <LimCore> https://x.com/foo.i386.run
[06:52] <ScottK> Heaven help us no.  Please don't try to make the file names mean anything.
[06:52] <LimCore> and once it is downloaded,  ln -s, desktop & menu shortcut,  and bash completion
[06:53] <jmarsden> LimCore: This adds complexity and mess, and gains us what, exactly?
[06:53] <ScottK> It sounds like a lot of work for no gain.
[06:53]  * LimCore renames all ScottK's .jpeg .png .mp3 .odt .pdf .txt .c .cpp .h and .sh to extention-less format. Cool?
[06:54] <ion_> Well, my photos are already under a photos directory, my music is in a music tree, my text files are in a text directory. Sure, go ahead.
[06:54]  * NCommander does one better, and attachs resource forks and filetype meta data to LimCore's files
[06:54] <ScottK> If those things had ways of knowing otherwise, I'd be in favor.
[06:54] <LimCore> jmarsden: way for users to know that file is an probably executable just by knowing file name,  same as foo.jpg - you know it (should be) an image.
[06:54] <NCommander> ScottK, can I get you to look over a package in REVU when you have a moment?
[06:54] <ScottK> NCommander: No.  I'm about to fall over.
[06:55] <LimCore> ion_: ~/from_alice/my_story/    camp.jpg  camp.mp3  camp.pdf    would you like to have this extenion-less?
[06:55] <NCommander> Man, MOTU's dropping like flies
[06:55] <ion_> I wouldn’t mind all programs showing the file’s type (based on its MIME type) in a column next to the filename.
[06:55] <ScottK> NCommander: Also I just finished writing my thoughts on the Launchpad 3.0 specs.
[06:55] <NCommander> ScottK, do I need to wear flame-resistant firegear, or will normal sunblock work ;-)
[06:55] <ScottK> NCommander: I'm grumpy even for me as a result.  You don't want me reviewing your package right now.
[06:55] <LimCore> ion_: I wouldnt too.  But .run is good for other cases
[06:55] <NCommander> eh
[06:55]  * NCommander gets his bunker gear on, and hugs a charged hose
[06:56] <ScottK> NCommander: The top 5 things on my list weren't on theres.
[06:56] <LimCore> ScottK: why so grumpy missed your meal? Here, have a chilloutburger
[06:56] <ion_> chilloutburger.food, you mean.
[06:56] <NCommander> ScottK, Eh, I already have my beef with LP 3.0
[06:56] <Hobbsee> LucidFox: the default one works fine with UMS....
[06:56]  * LimCore cooks  chilloutburger.food
[06:56] <NCommander> Hobbsee, what is UMS? (I keep thinking of the Sony disc)
[06:56] <ScottK> NCommander: #2 was please make the U/I suck less by putting the old one back.
[06:57] <LucidFox> Hobbsee> What default one?
[06:57] <jmarsden> LimCore: cooks.verb chilloutburger.human.food ?
[06:57] <NCommander> ScottK, what was 1, and 3-5?
[06:57] <Hobbsee> LucidFox: iriverplus or something.
[06:57] <Hobbsee> NCommander: it's the mass storage device thing
[06:57] <ScottK> #1 was fix security by signing PPAs and not leaving signed .sources files around where anyone can find them.
[06:57] <LimCore> People, this is simple.  For most formats you can say cool.JPG  cool.MP3  and people know instantly "its an image"  "its music".   You can NOT do that with binaries on linux (only on dos and windows). We miss this option
[06:57] <LucidFox> Proprietary and Windows-only? You think I'm EVER going to install that?
[06:58] <Hobbsee> LucidFox: wine, no?
[06:58] <ScottK> #3 was feature parity with the email interface since I know #2 isn't happening.
[06:58] <ScottK> I don't remember the rest.
[06:58] <LucidFox> I said "proprietary" just in case "Windows-only" isn't enough.
[06:58] <Hobbsee> LucidFox: heh, fair enough.  i don't know of linux-based ones, sorry.  do tell me if you find some good ones
[06:58] <NCommander> ScottK, you need caffiene. As for #1, there's been a lot of talk about how to implement that sanely in one of Soyuz's bugs
[06:58] <LucidFox> I was going to write one, actually, because I couldn't find any
[06:59] <jmarsden> LucidFox: Tried iriverter?
[06:59] <LucidFox> Or maybe tweak one of the existing ones to work with UMS
[06:59] <Hobbsee> NCommander: yes, there's been talk.  and no action.
[06:59] <ScottK> NCommander: The only sane way to do it would have been before they released the feature.
[06:59] <LucidFox> jmarsden> it's just a converter
[06:59] <NCommander> ScottK, which would have been what?
[07:00] <Hobbsee> ScottK: no, they can retroactively fix it.
[07:00] <LimCore> sometimes I think linux could use some centrallized leadership (like its kernel has)
[07:00] <ScottK> NCommander: The only sane way to have handled signing PPAs would have been to have it that way from the beginning.
[07:00] <ScottK> Whatever happens now can only reduce the insanity, not eliminate it.
[07:01] <Hobbsee> ScottK: no, they can stop it from causing more damage
[07:01] <ScottK> Hobbsee: That's true.
[07:01] <Hobbsee> presumably they can say "right, we've accepted all these packages.  we'll never accept them again"
[07:01] <ScottK> Hobbsee: With the current DNS cache poisoning issues, I've deleted all the packages out of my PPAs.
[07:01] <ScottK> I encourage others to do the same.
[07:02] <Hobbsee> ScottK: they're still in librarian.
[07:02] <AnAnt> Regarding the swt-gtk build failure (http://launchpadlibrarian.net/16468843/buildlog_ubuntu-intrepid-i386.swt-gtk_3.4-1_FAILEDTOBUILD.txt.gz), it seems that the problem is actually with openjdk-6-jdk that it doesn't depend on libxt-dev, can someone confirm this ?
[07:02] <ScottK> True, but at least they aren't apt-getable.
[07:03] <LimCore> you don't pgp sign PPas?
[07:03] <ScottK> Since my PPA revision numbers are lower than the archive's, grabbing the .changes files, while a potential problem elsewhere, isn't a problem for the stuff I had in PPAs.
[07:03] <ScottK> LimCore: The uploads are signed, but the repositories are not.
[07:03] <ScottK> So no signed binaries.
[07:04] <LimCore> because lunchpad do not have users priv keys right?
[07:04] <Hobbsee> correct.
[07:04] <Hobbsee> and they're not getting them.
[07:04] <ScottK> They could use a distro key or something.  Binaries in Ubuntu are typically signed by the archive.
[07:04] <Hobbsee> ScottK: twitch.
[07:04] <ScottK> What?
[07:04] <Hobbsee> ScottK: what's the betting any keys end up being stored on librarian too.
[07:04] <ScottK> Yeah.
[07:05] <ScottK> Because who could possibly find them there.
[07:05] <LucidFox> AnAnt> I can test this in pbuilder
[07:05] <LimCore> how about: 1) lunchpad signs binary with lunchpad's key   2) user downloads binary and checks lunchpad's sign  3) user signs lunchpad's sign with his own key and re-uploads that
[07:05] <LimCore> this could be scripted
[07:05] <LucidFox> Why does SWT depend on Xt, though?
[07:05] <ion_> lunchpad :-)
[07:05] <LucidFox> GTK doesn't
[07:05] <ScottK> LimCore: It's a proprietary system.  I"ll let them design it.
[07:05] <AnAnt> LucidFox: swt-gtk builds in ppc arch but not other archs
[07:06] <jmarsden> Maybe we need to design its successor, dinnerpad?
[07:06] <Hobbsee> LimCore: wrong place for any such discussions.
[07:06] <LimCore> ScottK: you dont like propertiary too much do you?  Its not like SCO
[07:06] <AnAnt> LucidFox: I found the reason is that default-jdk depends on openjdk on all archs except for ppc
[07:06] <AnAnt> LucidFox: in ppc, default-jdk depends on gcj's jdk
[07:06] <ion_> jmarsden: I’m already using breakfastpad.
[07:06] <ScottK> LimCore: I consider dependency on proprietary tools a business risk.
[07:06] <AnAnt> LucidFox: it's openjdk-6-jdk that depends on xt
[07:07] <ScottK> LimCore: I would suddenly like the way Launchpad works if they open the source.
[07:07] <ScottK> err
[07:07] <ScottK> would no
[07:07] <ScottK> ach
[07:07] <ScottK> I would not suddenly ...
[07:07] <ScottK> Yes, I need to go to bed.
[07:07] <LimCore> you wouldnt like it even if it would be open source?
[07:08] <ScottK> I think the current design is crap.
[07:08] <LimCore> dunno
[07:08] <ScottK> Open source wouldn't make it less so.
[07:08] <ScottK> The fact that it's proprietary is worse.
[07:08] <ion_> Being open-source doesn’t magically make software/services/interfaces/whatever good. :-)
[07:08] <ScottK> Exactly.
[07:08] <LimCore> I think linux *do* need commerciall
[07:09] <LimCore> (on a related topic)
[07:09] <ScottK> Go ponder the elegance of a design that needs over 400 database queries to render one web page.
[07:09] <LimCore> reversecache ftw? =)
[07:09] <LimCore> but, yeah.
[07:09] <LimCore> is source of their page open?
[07:10] <ScottK> No.
[07:10] <LimCore> how do you know then?
[07:10] <LucidFox> ScottK> WHAT?!
[07:10] <jmarsden> They embed that info into the page as a comment
[07:10] <ScottK> But embedded in each Launchpad page in an html comment at the bottom is the number of queries and how long they took
[07:10] <LimCore> oh
[07:10] <LimCore> well, it does work fast
[07:10] <LucidFox> Holy.....
[07:11] <ScottK> Just to pick a bug page I have open: <!-- at least 442 queries issued in 4.60 seconds -->
[07:11] <LimCore> perhaps this IS faster for their DB system
[07:11] <LimCore> then 10 huge queries
[07:11] <LucidFox> *facepalm*
[07:11] <LimCore> well, probably not
[07:11] <ScottK> Launchpad pages are substantially slower than Debian BTS.
[07:12]  * Hobbsee advises that all launchpad talk should go to #launchpad, and is offtopic here.
[07:12] <jmarsden> Hobbsee: So was adding .run to all ELF binaries :-)
[07:13]  * LimCore smacks jmarsden with an Ballmer for FUD =)
[07:13] <ScottK> Hobbsee: I disagree.  We're stuck with it and MOTU were asked for input on 3.0.  I think to say we can only discuss that on #launchpad is wrong.
[07:13] <ScottK> But I'm going to go to be anyway, so it doesn't matter.
[07:13] <ScottK> Good night.
[07:13] <Hobbsee> jmarsden: well, i can forward that elsewhere too
[07:13] <LimCore> jmarsden: /usr/lib/openoffice/program/oosplash.bin  Notice the .bin. I like it.  Lets make it more official. And .run not .bin IMHO
[07:14] <ion_> I wonder how many FUD cards limcore has in his pocket. :-)
[07:14] <Hobbsee> ion_: too many.
[07:14] <LimCore> ion_: I hope I will not have to use any mor
[07:14] <LimCore> -e
[07:15] <LimCore> ok, does anyone here can make some bigger chane in ubuntu, that requires some balls, all is it not the place?   Linux is quite good because Linus makes decisions when needed
[07:16]  * ion_ has an urge to question the quality of OpenOffice’s architecture as a design model, but instead bites his tongue. ;-)
[07:16] <LucidFox> LimCore> Uhm
[07:16] <LimCore> if .run is a bad idea then why; if it is good, then lets do it
[07:16] <LucidFox> You're obviously not familiar with the Linux kernel development process.
[07:16] <jmarsden> LimCore: Go ahead, on your own PC, do it.
[07:16] <LucidFox> If you think Linus alone decides everything.
[07:16] <LucidFox> And that his word is law.
[07:17] <LimCore> LucidFox: his word is law,  but he dont have time to make decissions on ALL topic
[07:17] <LucidFox> LimCore> [citation needed]
[07:17] <LimCore> jmarsden: I did
[07:18] <LimCore> jmarsden: works good
[07:18] <ion_> Even he himself says he’d like more Linux branching to exist. :-)
[07:19] <LimCore> sure, but Linus finally accepts (or not) other trees to official linux vanilla kernel
[07:19] <jmarsden> LimCore: For all ELF binaries?  OK.  Now find out how many scripts just broke :-)
[07:19] <LimCore> jmarsden: I written that 2 times alrady, can you scrollback?
[07:20] <LimCore> [07:16] <LimCore> (obviously common utilities like cp mv ls must always remain how they are)
[07:20] <LimCore> idea would be for new applications
[07:21] <ion_> Yeah, since everyone loves inconsistency.
[07:21] <LucidFox> LimCore> Mono already uses exe and dll.
[07:21] <jmarsden> And who decides what is common vs uncommon?  And how does it help the user who now has to learn two schemes, one for common utilities and one for new ones???
[07:21] <LimCore> ion_: unless you got other idea? legacy is a **** but what can you do.  And "ls" is nice and short
[07:21] <LimCore> what is there to learn?
[07:22] <LucidFox> Under Linux, whether or not a file is executable is decided by permissions
[07:22] <ion_> How about this for an ”other idea”: let’s keep it as it is and not switch to an ugly legacy scheme from MS-DOS. :-)
[07:22] <LucidFox> And you aren't supposed to send executables by mail anyway
[07:22] <LimCore> scheme from MS-DOS is better, for the reasons presented, unless someone can show they where false
[07:22]  * LimCore minus the 8.3 part =)
[07:23] <LucidFox> The extension is used to signal the file format.
[07:23] <AnAnt> LucidFox: got my point ?
[07:23] <ion_> lucidfox: For humans, not computers.
[07:23] <LucidFox> "Executable" is not a file format, it's what you can do with the file.
[07:23] <LimCore> This is really simple:  all linux files have extension that allow users to quickly know what it is (should be).  With the exception of ELF binaries, that use empty-extension.  WHY?!
[07:24] <LucidFox> Not just ELF binaries. All files in /usr/bin.
[07:24] <LucidFox> Which may be ELF binaries, shell scripts, Python scripts, etc
[07:24] <LimCore> shell scripts are named .sh  and python .py
[07:24] <ion_> If it’s in $PATH and it has the executable bit on, you might be correct assuming it’s executable. :-)
[07:24] <LimCore> unless they are in /usr/bin
[07:25] <LimCore> python files are .py  Unless in /usr/bin - they there have extension trunacted
[07:25] <LimCore> lets do exactly THE SAME, for ELF binaries.
[07:26] <LucidFox> Proprietary software distributors already do that :p
[07:26] <Hobbsee> LimCore: fwiw, you won't get a consensus on irc, that will actually affect the distro.
[07:26] <Hobbsee> LimCore: so, you're effectively wasting your breathe.
[07:26] <Hobbsee> -e
[07:26] <LimCore> LucidFox: why?
[07:27] <LimCore> LucidFox: I find it nice and helpfull.  This isnt to help them (like binary blobs), so it must be to help end users (works for me)
[07:27] <dholbach> bobbo: congratulations!
[07:28] <LimCore> Hobbsee: I never consider discussion with good developers a waste
[07:28] <LucidFox> Per dholbach
[07:28] <Hobbsee> LimCore: well, it depends on what your aims are.  if you actually want to see stuff change...
[07:28] <LimCore> then I will later present it on ml
[07:29] <Hobbsee> filed that backport request yet?
[07:29] <LimCore> no, chence the later part
[07:29] <LimCore> s/later/laaaaaaaaater
[07:29] <Hobbsee> yeesh.  you have strange ideas of being productive.
[07:30] <LimCore> it's called ideas, and works good with delegating
[07:31] <LimCore> like, I would prefer to pay someone say 100$ and they would do the realtivelly easy task of making "paperwork". Perhaps buy ubuntu support? Will see.
[07:31] <NCommander> LucidFox, ping?
[07:32] <LucidFox> NCommander> Yes?
[07:32] <LimCore> Hobbsee: you seem to not like this idea? If all brilliant ubuntu developers would be doing easy stuff, we will be getting nowwhere
[07:32] <NCommander> LucidFox, can I steal you for 10 minutes to review a package on REVU?
[07:32] <AnAnt> LucidFox: did you get my point about openjdk ?
[07:33] <LucidFox> AnAnt> What point?
[07:33] <LucidFox> NCommander> Sure
[07:33] <AnAnt> 09:05 <AnAnt> LucidFox: swt-gtk builds in ppc arch but not other archs
[07:33] <AnAnt> 09:06 <AnAnt> LucidFox: I found the reason is that default-jdk depends on openjdk on all archs except for ppc
[07:34] <AnAnt> 09:06 <AnAnt> LucidFox: in ppc, default-jdk depends on gcj's jdk
[07:34] <AnAnt> 09:06 <AnAnt> LucidFox: it's openjdk-6-jdk that depends on xt
[07:34] <NCommander> LucidFox, http://revu.ubuntuwire.com/details.py?package=pangomm
[07:34] <LucidFox> Why don't we change swt-gtk to build with gcj, then?
[07:34] <LucidFox> :)
[07:34] <AnAnt> you were asking why swt-gtk depends on xt, I think it's openjdk that depends on xt, not swt-gtk
[07:34] <Hobbsee> LimCore: well, this comes from someone who complains that bugs are not getting fixed.  And then has many repeated rants, in many channels, after being told what he can do to actually get his bug fixed.  But chooses not to do it.
[07:34] <Hobbsee> LimCore: you can't have it both ways.
[07:35] <LucidFox> NCommander> looking
[07:35] <Hobbsee> ideas are great, yes, but if you & everyone else never end up doing the work to bring them to action, then you've not gained anything.
[07:35] <LimCore> Hobbsee: no, I ment for others to get this fixed. While it sounds probably selfish/whatever, the point is, I see myself as doing more complicated contributions (in tasks where I could help), instead of doing things that are easy, or which I do not have expeericne with (and therefore wasting my time)
[07:35] <LucidFox> control.in? ewwww
[07:36] <AnAnt> LucidFox: hello ?
[07:36] <LimCore> Hobbsee: or, I could just donate $$ so that someone would do that. If my next contract works out, I will
[07:36] <NCommander> LucidFox, it's going to be included in main as a GNOME package, and the Desktop team has great love of CDBS, so I honoured that request
[07:37] <Hobbsee> LimCore: i would ask that you go on that path to more complicated contributions, and not continue your various rants here, then.
[07:37] <LucidFox> Uhm... CDBS doesn't imply control.in
[07:37] <LimCore> Hobbsee: however, Im looking forward to have time to fix /some/ bugs by hand, even to excercise.  Yeah, Im doing that.
[07:38] <LimCore> Hobbsee: I do no "various rants here", btw :)
[07:38] <Hobbsee> simple.  spend less time ranting in multiple channels :)
[07:38] <NCommander> LucidFox, I've never seen a CDBS package that doesn't use it
[07:38] <NCommander> (I wasn't even aware that CDBS packages could support regular control files and not require control.in (which I do find is ugly)
[07:38] <Hobbsee> NCommander: i beg to differ.
[07:39] <LimCore> Hobbsee: sure I do that already
[07:39] <NCommander> Hobbsee, I said I never seen, I didn't say they didn't exist :-P
[07:39] <NCommander> Every GNOME package however uses control.in and CDBS
[07:39] <Hobbsee> NCommander: most of the ones that i've touched are by cdbs, and don't seem to have a control.in.  Check out kde stuff :P
[07:39] <ion_> How soon will LimCore use one of his many FUD cards on Hobbsee? On another note, someone should come up with a good verb for using a FUD card inappropriately. :-)
[07:40] <NCommander> So KDE is nicely packaged and less hackish ;-)
[07:40] <NCommander> ion_, fuc*ed ;-)
[07:40] <LucidFox> NCommander> smplayer
[07:40] <Hobbsee> ion_: he won't suceed.  *shrug*
[07:40] <LucidFox> and a zillion more CDBS packages
[07:41] <LucidFox> The Ubuntu Packaging Guide doesn't recommend control.in with CDBS
[07:41] <LimCore> ion_: as soon as soon someone will spread missinformation et
[07:41] <NCommander> LucidFox, the only CDBS packages I touch are the ones used by GNOME
[07:41] <LucidFox> ah
[07:41] <AnAnt> FUD=Fear, Uncertainty & Doubt ?
[07:41] <NCommander> LucidFox, tell that to the desktop team :-/
[07:41] <LimCore> yes
[07:41] <LucidFox> well, they use it - I'm not sure why
[07:41] <NCommander> gucharmap, gtkmm, glibmm, and quite a few others use CDBS with controlin
[07:41] <LucidFox> What's the postinst file for?
[07:41] <NCommander> LucidFox, ldconfig
[07:41] <NCommander> You need to run it after installing a shared library so the dynamic linker knows it exists
[07:42] <NCommander> (it's per Debian policy)
[07:44] <ion_> ncommander: dh_makeshlibs automatically adds ldconfig to postinst.
[07:44] <NCommander> ion_, it trips a lintian error if it isn't there explicately
[07:44] <ion_> Huh. That sounds strange.
[07:45] <NCommander> ion_, http://lintian.debian.org/tags/postinst-must-call-ldconfig.html
[07:47] <NCommander> might be a bug in lintian though
[07:47] <ion_> Perhaps dh_makeshlibs doesn’t get called from debian/rules, or debhelper additions don’t make it into the final postinst.
[07:47] <NCommander> ion_, it does end up in the postrm
[07:47] <LucidFox> just checked cairo and cairomm - they don't use .postinst files
[07:48] <NCommander> Should I write it off as a bug in lintian that it tripped that?
[07:48] <LucidFox> cairo calls dh_makeshlibs, cairomm uses cdbs
[07:48] <LimCore> ion_: jmarsden: do you want to read my idea with your remarks added (and possible fixes of them), and comment revised version?
[07:48]  * ion_ takes a quick look at ncommander’s packaging...
[07:48] <NCommander> Might be a weird fluke
[07:48] <NCommander> I started packaging on Hardy, and then upgraded to intrepid somewhat in
[07:49] <ion_> The #DEBHELPER# tag is in the postinst, and debian/rules includes cdbs/1/rules/debhelper.mk. Huh.
[07:50]  * NCommander is not going to figure it out
[07:50] <NCommander> As I said, I used CDBS more as a convience to help get it upstream into Debian
[07:50] <NCommander> But all of my other packages use normal non-CDBS rules
[07:51] <LucidFox> NCommander> Commented
[07:52] <NCommander> LucidFox, the "This packaging is under the GPL" refers to stuff in the debian folder
[07:52] <LucidFox> yes, I know
[07:52] <NCommander> Not the actual software
[07:52] <LucidFox> but it's recommended to have it match upstream
[07:52] <NCommander> No, no
[07:52] <LucidFox> so that patches can be sent to upstream
[07:52] <NCommander> Upstream as in Debian
[07:52] <ion_> ncommander: Would you mind sharing a built binary on which lintian gives the complaint? I’d like to look at the generated postinst, and i’m too lazy to build it myself. :-)
[07:52] <NCommander> It's going into Debian GNOME's archive
[07:52] <LucidFox> No, upstream as in upstream
[07:52] <NCommander> ion_, I don't have one ATM
[07:52] <NCommander> LucidFox, GNOME has no intention of including debian folders
[07:53] <LucidFox> Not debian folders, patches
[07:53] <NCommander> LucidFox, those patches are from their tracker
[07:53] <LucidFox> Future patches
[07:53] <NCommander> But I'll change the debian licensing to LGPL :-P
[07:53] <NCommander> Or permissive
[07:53] <LucidFox> You can't use permissive :)
[07:54] <LucidFox> because the package is a derivative work of the upstream software
[07:54] <NCommander> SO how can packages use GPL packaging for packages that are under a GPL incompatible license
[07:54]  * NCommander has never heard of this arguement before
[07:54] <LucidFox> So for LGPL 2.1+, that means that it legally can only be LGPL or GPL
[07:54] <LucidFox> NCommander> They can't.
[07:54] <slangasek> the debian packaging is almost certainly not a derivative work of the upstream software
[07:55] <LucidFox> Really?
[07:55] <LucidFox> What about patches?
[07:55] <NCommander> LucidFox, Less then 10 lines usually means they aren't copyrightable
[07:55] <LimCore> heh... http://brainstorm.ubuntu.com/idea/10930/
[07:55] <slangasek> the common sense interpretation of "packaging" doesn't include patches :)
[07:56] <LucidFox> NCommander> They are, the question is whether it can be enforced
[07:56] <NCommander> As for the patch writer, that's up to them to decide what license to submit it under
[07:56] <LucidFox> slangasek> I'm just retelling what I was told
[07:56] <NCommander> Both patches I include are from the bugzilla tracker
[07:56] <LucidFox> For videotrans, I was told to change the license from GPL to the upstream permissive license
[07:56] <NCommander> (and a generic patch that makes it possible to build without running autoconf in the build environment)
[07:56] <LucidFox> patches being cited
[07:57]  * NCommander just makes it LGPL and kills the arguement right here and now
[07:57] <NCommander> LucidFox, changes made and building
[07:58] <LucidFox> NCommander> heh
[07:58] <NCommander> LucidFox, built, uploading
[07:58] <NCommander> (ccache is an awesome thing ;-))
[07:59] <LucidFox> I think this should be discussed at the mailing list, though
[07:59] <NCommander> LucidFox, well, I resolved it for this package, but yeah, I agree, might be worth bringing up on u-motu/d-devel
[08:00] <NCommander> LucidFox, care to advocate it once it pops up on REVU, and you confirm it builds?
[08:00] <NCommander> BTW, LucidFox you need to merge your accounts if you want your MOTUness status back :-P
[08:01] <NCommander> er, wait
[08:01] <NCommander> Hold on, ignore that upload
[08:02] <LucidFox> NCommander> I did merge my accounts
[08:02] <NCommander> Oh
[08:02] <NCommander> crud
[08:02] <LucidFox> I said it twice on the mailing list, in fact
[08:02] <NCommander> Were all of your accounts MOTU?
[08:02] <LucidFox> only one
[08:02] <LucidFox> the other wasn't
[08:02] <NCommander> (you must have merged one that wasn't, and lost your reviewer status"
[08:02] <NCommander> It's a slightly hiccup in the merge system
[08:02] <LucidFox> so I'll now need to re-merge the MOTU one?
[08:02] <NCommander> If you have more then one accounts, and they aren't all contributor ...
[08:02] <NCommander> No
[08:02] <NCommander> I need to tweak teh DB
[08:02] <NCommander> and remake you one manually
[08:03] <NCommander> SInce your old accounts were deleted after merging
[08:03] <LucidFox> By the way, is it safe to use debhelper 7 with cdbs? (I don't know)
[08:04] <NCommander> LucidFox, no idea
[08:04] <NCommander> revu1@spooky:/srv/revu-production$ scripts/alter_user.py -n sikon -l reviewer
[08:04] <NCommander> Altering sikon to level reviewer
[08:04] <NCommander> Ok, your in business
[08:06] <NCommander> LucidFox, CDBS works fine with debhelper 7
[08:07] <AnAnt> why is ubuntu-java always dead ?!
[08:07] <NCommander> (I tried changing the compat file to 6, and my build broke because 6 can't on move rename)
[08:09] <NCommander> LucidFox, as soon as this revision appears on REVU (at 09:20 REVU time, can you advocate since I resolved everything?)
[08:10] <LucidFox> I'll build it in pbuilder first
[08:10] <NCommander> Of course :-P
[08:11]  * NCommander has gotten better at packaging verus the 20 or so uploads codeblocks took :-)
[08:12] <LucidFox> heh
[08:12] <LucidFox> Well, codeblocks _was_ a complex package
[08:12] <NCommander> It has four seperate attempts at packaging it
[08:13] <NCommander> So yeah
[08:13] <NCommander> That was fun
[08:13] <NCommander> Upstream rebuffed my efforts to make changes
[08:13] <NCommander> (something to the sound of "**** off, we don't care")
[08:13] <LucidFox> Well, upstreams tend to do that
[08:14] <LucidFox> It's been a year since I've been trying to get the lsb_release patch into psi upstream, and they've _just_ set the bug to "assigned"
[08:14] <NCommander> Very few people care about lsb
[08:14]  * NCommander rolls eyes
[08:14] <LucidFox> Well
[08:14] <NCommander> Even Debian isn't lsb compatible out of the box
[08:14] <LucidFox> It's not exactly related to USB
[08:14] <LucidFox> * LSB
[08:14] <NCommander> YOu need to use alien to convert LSB packages
[08:14] <NCommander> Or install RPM :-P
[08:15] <LucidFox> That patch is so that Ubuntu isn't misidentified as Debian
[08:15]  * NCommander tackles DktrKranz 
[08:15] <LucidFox> ScottK> In case you're interested, I've uploaded the KDE version of subtitlecomposer
[08:15] <NCommander> DktrKranz, can I get you on a +1 on a REVU package after LucidFox finishs checking it over?
[08:15]  * DktrKranz hides
[08:16] <LucidFox> lol
[08:16] <DktrKranz> NCommander, everything has a price, I start from 150 euros
[08:16] <LucidFox> hahaha
[08:16] <NCommander> Crap, thats more money then the US has spent on the Iraq war with current conversion rates
[08:16] <DktrKranz> I have family
[08:16] <NCommander> I have poverty
[08:17]  * DktrKranz is unsure about which one is worse
[08:17] <ion_> I have IRC – http://heh.fi/tmp/i_have
[08:17] <NCommander> family, cause they just suck more money out of the bank :-P
[08:17] <NCommander> LucidFox, its up
[08:18] <DktrKranz> NCommander, when REVU is up, I can maintain family, just ask my review ;)
[08:18]  * NCommander hears his joke lameness meter explode
[08:18] <NCommander> Bah
[08:19] <NCommander> Now I need to go apt-get another one
[08:20] <NCommander> Oh, crud
[08:20] <NCommander> Chrono Trigger for the Nintendo DS
[08:20] <NCommander> There goes my life all over again
[08:20] <LucidFox> By the way, if any MOTU is up for reviewing Java libraries, I have http://revu.ubuntuwire.com/details.py?package=libbrowserlauncher2-java
[08:20]  * NCommander can predict his contribution rate to Ubuntu dropping to zero
[08:20] <LucidFox> Consoles? Meh.
[08:21] <NCommander> Chrono Trigger is just an awesome game
[08:21] <NCommander> Sealed Door is still an awesome tune
[08:21] <NCommander> I used it as a ringtone for awhile
[08:22] <LucidFox> 334 kb diff.gz?!
[08:22] <LucidFox> hmm, autoconf patch
[08:22] <DktrKranz> NCommander, I always dreamt to drive Epoch ;)
[08:22] <NCommander> DktrKranz, so I take it you didn't crash it into Lavos?
[08:23] <LucidFox> it has autom4te.cache
[08:23]  * NCommander listens to "World Revolution"
[08:23] <DktrKranz> NCommander, I did it intentionally
[08:23] <NCommander> d'oh
[08:23] <NCommander> Fatality on my part
[08:24] <NCommander> DktrKranz, fighting Lavos's out shell isn't too bad, you just need to beat it, get to the save point, and use the portal to return to the End of Time to recover
[08:24] <NCommander> *outer
[08:25] <DktrKranz> my Chrono was too powerful, I killed it at the Millenarian Fair ;)
[08:25] <DktrKranz> just choose right teleporter and enjoy the figth
[08:25] <NCommander> Wow, you didn't revive Crono?
[08:25] <NCommander> Oh, THAT one
[08:25] <NCommander> Yeah, you get the quickie ending, but you can only do that on New Game+ though O_o;
[08:26] <LucidFox> Oooh, webkit is in main now
[08:26] <DktrKranz> of course, being at level 4 isn't a good choice to die an horrible death :)
[08:26] <NCommander> First time through, I spent a week figuring out all the side quests
[08:26] <LucidFox> webkit, openjdk and KDE4 - what a trio
[08:27] <DktrKranz> LucidFox, so... evolution webkit backend should come in soon
[08:27] <LucidFox> Well, I use Thunderbird, so I don't care about that
[08:27] <LucidFox> if yelp switches to it, though...
[08:27] <NCommander> I'd like to see a GNOME based browser that used webkit vs. gecko
[08:28]  * NCommander remembers Black Omen
[08:28] <DktrKranz> anyone knows where seahorse-agent landed? seahorse changelog states it has been moved to another source, but I can't find it
[08:30] <LucidFox> I: libpangomm-1.4-1: no-symbols-control-file usr/lib/libpangomm-1.4.so.1.0.30
[08:32] <NCommander> LucidFox, O_o?
[08:32] <NCommander> I don't get that
[08:33] <LucidFox> hmm
[08:35] <slangasek> well, -I is informative stuff only
[08:35] <ion_> See dpkg-gensymbols(1)
[08:36] <slangasek> dpkg-gensymbols ftw, but not at all mandatory :)
[08:36] <LucidFox> gtkmm, cairomm and Qt don't have symbols files either
[08:36] <LucidFox> so I guess I'll ignore that one
[08:37] <NCommander> heh
[08:37] <NCommander> Thank you
[08:37] <NCommander> Adding it would require patching cdbs
[08:37] <NCommander> ANd that sounds like as much fun as poking a sleeping dragon
[08:37] <slangasek> no, it wouldn't
[08:38] <slangasek> you would create a debian/libpangomm-1.4-1.symbols file statically, and debhelper (via cdbs) would use it automatically
[08:38] <LucidFox> NCommander> Posted the one remaining objection I do have
[08:38] <ion_> ncommander: cdbs calls dh_makeshlibdeps, which calls dpkg-gensymbols
[08:39] <ion_> Also, adding a dpkg-gensymbols verification manually wouldn’t have required patching cdbs.
[08:39] <LucidFox> What good would a symbols file be for a C++ library, anyway?
[08:40] <slangasek> the same good it would be for every other library?
[08:40] <NCommander> LucidFox, new upload is already up with it gone
[08:40] <slangasek> why would C++ be different?
[08:40] <LucidFox> Oh.
[08:42] <NCommander> LucidFox, so I get a +1 ;-)
[08:44] <LucidFox> Well, apart from the fact that "consistant" is spelled "consistent"...
[08:44] <LucidFox> slangasek> Is a misspelling in a patch file name a blocker?
[08:44] <slangasek> uh
[08:44] <slangasek> not for me? :)
[08:45]  * NCommander twichs
[08:45] <NCommander> Most patch files don't have comments added by the authors :-P
[08:47] <LucidFox> NCommander> Advocated
[08:47] <NCommander> Score
[08:48] <NCommander> slangasek, can I convience you to look at it, poke it with a stick, and maybe get a second advocation
[08:48] <NCommander> ^?
[08:49] <slangasek> where am I meant to be looking?
[08:49] <LucidFox> http://revu.ubuntuwire.com/details.py?package=pangomm
[08:49] <NCommander> http://revu.ubuntuwire.com/details.py?package=pangomm
[08:50] <slangasek> strange that this isn't in the archive before now, neh?
[08:50] <NCommander> slangasek, it was split from gtkmm on the last release
[08:50] <slangasek> ah
[08:50] <NCommander> It actually had quite a few bugs that needed to be fixed
[08:50] <NCommander> (there are about three bugzilla bugs open about the issues with pangomm's configure scripts)
[08:50]  * NCommander starts writing a MIR
[08:50] <LucidFox> NCommander> Why does my last comment get duplicated every time I refresh the page?
[08:51] <NCommander> LucidFox, old bug that resurfaced when RainCT changed the templating engine I think
[08:54] <slangasek> NCommander: an MIR for... pangomm?
[08:54] <slangasek> hopefully the MIR comment was about an unrelated package :)
[08:55] <NCommander> slangasek, no, its for pangomm, it was split from gtkmm, and now new versions of gtkmm and glibmm require it
[08:55] <LucidFox> http://revu.ubuntuwire.com/details.py?package=tvbrowser <-- "Other Uploads: *** Error: The encoding for this string is wrong. ***"
[08:55] <LucidFox> Does REVU has a BTS? :)
[08:55] <NCommander> LucidFox, it's a bug in mako, I need RainCT to run it down, I'm not sure what's causing it
[08:55] <NCommander> LucidFox, revu LP project
[08:55] <slangasek> NCommander: and neither gtkmm nor glibmm are in main
[08:56] <slangasek> so I fail to see why you would be MIRing it
[08:56] <LucidFox> lol
[08:56] <NCommander> slangasek, er ...
[08:56]  * NCommander fails
[08:56] <NCommander> For some reason I thought they were
[08:56] <NCommander> Well, a good thing you saved me work slangasek
[08:57] <LucidFox> There should be a quote database for this channel
[08:57] <slangasek> :-)
[08:57] <NCommander> LucidFox, what would you like to quote?
[08:57] <NCommander> (and I have a spare machine that could become an #ubuntu quote db)
[08:57] <LucidFox> For example, what you and slangasek just said :)
[08:59] <ion_> “:-)”
[09:00] <NCommander> For some reason, when I think of creating an ubuntu quote db, I feel like we would be categorizing our stupidity for future generations to use and take reference to
[09:00] <NCommander> It feels a very russian thing to do.
[09:00] <LucidFox> lol
[09:00] <ion_> .addquote <NCommander> For some reason, when I think of...
[09:01] <LucidFox> Well, I already have this: http://qdb.lucidfox.org/quotes
[09:01] <LucidFox> it's for #wookieepedia, though
[09:01] <slangasek> NCommander: why do you have yourself listed as XSBC-Original-Maintainer?  In what sense is this true?
[09:02] <NCommander> The problem with categorizing and recording stupidity is that it would lead to emulation
[09:02] <slangasek> (that field is, TTBOMK, meant to be used for packages merged from other repositories)
[09:02] <NCommander> slangasek, if thats the case, I need to patch every package that went into the archive via REVU since your the first to say that
[09:03] <slangasek> hmm :)
[09:03] <NCommander> (I was under the impression that if you are the person who packaged it (ubuntu0), then you put yourself there until the package is synced from Debian)
[09:03] <LucidFox> All packages that are -XubuntuY have this field
[09:03] <LucidFox> and Lintian complains if they don't
[09:03] <slangasek> ah, so it's because of a lintian bug, ok ;)
[09:03] <NCommander> LucidFox, unless its an @ubuntu.com address
[09:04] <slangasek> lintian shouldn't complain about the absence of an XSBC-Orig-Maintainer field, because there are packages which legitimately don't have an orig-maintainer
[09:04] <NCommander> slangasek, I personally think the Debian Maintainer policy should be waved for Ubuntu specific packages, OR packages where the Debian maintainer wants to recieve bug reports
[09:04] <NCommander> (via that mechanism)
[09:06] <slangasek> well, I think Ubuntu-specific packages are already adequately addressed under the official policy (whereas lintian sounds like it's being overly complainy), and I don't think the latter warrants waiving the rule on using an ubuntu.com maintainer field
[09:06] <Shish_> hi , i was told to come here for my question regarding emesene?
[09:06] <Shish_> am i in the right place?
[09:07] <slangasek> that might depend on what your question is
[09:07]  * ion_ blows the dust off his crystal ball.
[09:07] <NCommander> slangasek, it's also dpkg-source that bitchs
[09:07] <LucidFox> NCommander> When I log in to REVU from the main page, it redirects me to http://revu.ubuntuwire.com/index.p
[09:07] <NCommander> (it used to error out in older versions vs just warn)
[09:08] <Shish_> tryin to update to 1.0.1 -- cant see my contact list, and heard that was the fix... but i have no idea on how to upgrade, and/or what to do
[09:08] <NCommander> LucidFox, That's because that's how the revu configuration file was setup, I don't have permission to change that
[09:09]  * NCommander waits for the slangasek seal of approval, or the hammer of needs-work-ness
[09:10] <Shish_> so i guess my question is how do i go abouts upgrading my emesene, so i can see my contact list?
[09:10] <NCommander> Shish_, are you running Hardy or Intrepid?
[09:10] <Shish_> NCommander: hardy
[09:10]  * NCommander looks to see what versions are released for each release
[09:11] <SWAT> I've submitted 2 new packeges to revu (freeorion and libgigi) and am waiting for comments/advocates. These packages aren't in Debian yet. Is the cooperation with Debian good enough that these also will be added to the Debian repos?
[09:11] <slangasek> NCommander: s/Originall/Originally/ in the package description :)
[09:11] <slangasek> I don't care about spelling in patch names, but descs should be spelled write ;-)
[09:11] <NCommander> Shish_, it appears that emesene is only getting updates in intrepid
[09:12] <slangasek> NCommander: and s/convient/convenient/
[09:12] <slangasek> lintian needs aspell
[09:12] <slangasek> or ispell, or whatever the new hotness is
[09:12] <Shish_> NCommander: hmmm...   i didnt know intrepid was already out...?  soo, do i get intrepid, or just use amsn instead?
[09:12] <slangasek> NCommander: s/internationization/internationalization/ :)
[09:12] <NCommander> I just need to learn how to spell
[09:13] <Shish_> NCommander: or any suggestions on an messenger like client
[09:13]  * NCommander hates being cursed with a spelling impairment
[09:13] <NCommander> Shish_, intrepid isn't out
[09:13] <slangasek> Shish_: the latest version of emesene in intrepid is 1.0-dist, and intrepid is not a released version of Ubuntu; it's possible that whoever sent you here intended that you ask the Ubuntu developers to package a new version, but that doesn't seem like a good solution for you in the short term
[09:13] <NCommander> Shish_, its not been backported to Hardy
[09:14] <slangasek> NCommander: s/devlopment/development/ (see, lintian needs ispell support so it can do this job for me ;P)
[09:14] <LucidFox> Should .desktop files specify the full path to the executable?
[09:14] <LucidFox> e.g. /usr/bin/foo
[09:14] <NCommander> LucidFox, where was the other typo?
[09:14] <Shish_> slangasek: hmmm... i agree with you there... any ideas on what a good short term solution is then?
[09:14] <LucidFox> NCommander> Other typo?
[09:14] <NCommander> Shish_, grab the source package and build it
[09:14] <LucidFox> I found only one
[09:15] <slangasek> Shish_: I had never heard of emesene before you joined the channel, so... not really
[09:15] <NCommander> LucidFox, yeah, where was it
[09:15] <LucidFox> "consistant"
[09:15] <Shish_> NCommander: k, i should have said that im totally new to all of this.... no idea what that meant... lol, sorry!
[09:15] <Shish_> slangasek: k, thank you tho
[09:16] <slangasek> NCommander: why do you have a debian/control.in that's identical to debian/control?
[09:17] <NCommander> slangasek, I only have control.in in the first place to make it uniform with every other package in the Debian GNOME packaging repo
[09:17] <slangasek> NCommander: hrm, but the other packages in that repo have it because substitutions are performed on the file to generate debian/control :)
[09:17] <slangasek> NCommander: and your control.in is missing the relevant wildcard :)
[09:18] <NCommander> slangasek, they seem to have it regardless if its required or not -_-;
[09:18] <NCommander> I can scratch it without loosing much sleep though
[09:18] <NCommander> (if someone complains, its not much effort to readd it)
[09:19] <NCommander> slangasek, actually, the GNOME support scripts require it
[09:19] <NCommander> since it does a GNOME_TEAM replacement on control.in
[09:19] <NCommander> (which once this goes into Debian it will get)
[09:19] <slangasek> ok
[09:19] <Shish_> well thanks guys, i think im gonna try and install amsn instead -- appreaciate the time and patience..thank you again!
[09:20] <NCommander> Shish_, wish we could do more to help. I personally use pidgin with MSN, but it may not work for your needs
[09:20] <Shish_> NCommander: cool, thanks a lot
[09:20]  * NCommander swears
[09:22] <slangasek> NCommander: I object to simple-patchsys because it's opaque to debdiff reviews, but I'll not let that keep me from giving approval :)
[09:23] <NCommander> slangasek, again, trying to keep uniform with the rest of the desktop team packages
[09:23] <NCommander> (I use dpatch on everything else, and quilt can burn as far as I am concerned; very few packages need that complexity)
[09:23] <slangasek> heh
[09:23] <NCommander> The only packages I can think off hand that really need quilt are GCC and glibc
[09:24] <slangasek> php5, samba, openldap, pam
[09:24] <NCommander> ^that I've worked on
[09:24] <slangasek> neither gcc nor glibc uses quilt anyway, they use much worse patchsystems :P
[09:24]  * NCommander thought they used quilt
[09:24] <slangasek> no
[09:24] <NCommander> I stopped trying to directly patch GCC's packaging and submit debdiffs
[09:24] <NCommander> Now they just get plain packages
[09:24] <slangasek> maybe that's why you have an oddly bad impression of quilt :)
[09:24] <NCommander> SOmeone else can deal with braindeadness
[09:25] <NCommander> No, I loath using quilt for fixing FTBFS fixes
[09:25] <NCommander> I didn't get into touching GCC until later in my hurd porting carrier when I fixed profiling
[09:26]  * NCommander has two patches in GCC in Debian. One to fix gnu99 mode on m68k, and another to fix profiling on hurd
[09:26] <slangasek> why does pangomm build-depend on chrpath?  it's not mentioned anywhere in debian/rules
[09:26] <NCommander> slangasek, oh, argh, that was from an older version of the rules
[09:26] <NCommander> There was concern in gtkmm about an rpath slipping in
[09:27] <slangasek> ok
[09:27] <NCommander> I had their rule using chrpath in there until I determined the bug was fixed
[09:27] <slangasek> do you need me to record this feedback in REVU, or is here sufficient?
[09:27] <NCommander> I removed it from the rules, forgot to remove it from the package
[09:28] <NCommander> slangasek, well, I could technically fake your advocation vote since I'm a REVU admin, but that would be unethetical, so yeah, a comment would be needed once I upload an updated package :-P
[09:28] <slangasek> heh
[09:28] <NCommander> Trust me
[09:28] <slangasek> I meant, do you need me to repeat my spell checking etc. comments on the website :)
[09:28] <NCommander> Fighting the urge to advocate my own packages is a pain
[09:28] <NCommander> Maybe someday I'll be an MOTU
[09:28] <NCommander> Oh, no
[09:28] <NCommander> Just "We fixed it on IRC, +1)
[09:28] <NCommander> Actually, its got two advocations
[09:29] <NCommander> You can upload if you feel up to the task
[09:29] <NCommander> wow, lot of new MOTUs
[09:30] <slangasek> sorry, it's too mild of an archive change for me to upload it at this time of night, I only upload crazy stuff this late ;)
[09:30] <RAOF> Well, contributors.
[09:30] <NCommander> slangasek, so you enjoy playing with dak/soyuz on a lack of caffiene?
[09:30] <NCommander> RAOF, care to upload?
[09:31] <slangasek> oh no, I always have caffeine
[09:31] <NCommander> heh
[09:31] <NCommander> caffine is awesome
[09:32] <RAOF> NCommander: I'm about to mess around with some GNOME Do PPA packages, but I'll see what ya got.
[09:32] <NCommander> RAOF, no, it already has two advocations
[09:32] <NCommander> It just needs an actual upload
[09:32] <NCommander> unless you want to make it +3
[09:32] <RAOF> Why didn't the second advocate upload?
 sorry, it's too mild of an archive change for me to upload it at this time of night, I only upload crazy stuff this late ;)
[09:33] <RAOF> NCommander: Want to package the Google Data Sharp libs for me?
[09:33] <RAOF> :)
[09:33] <NCommander> IT BURNS
[09:33] <RAOF> Didn't think so.
[09:33] <NCommander> RAOF, only if you say yes to me being an MOTU when the time comes
[09:34] <NCommander> ;-)
[09:34] <RAOF> I don't think I'd have much of a problem there.  In a little while, though, I think.
[09:35]  * NCommander wonders how many braincells will go packaging a C# package
[09:35] <slangasek> NCommander: is it deliberate that you're creating a /usr/share/doc/pangomm-1.4 directory that doesn't correspond to a binary package?
[09:35] <NCommander> RUnning down mono bugs already fried my head
[09:35] <NCommander> sladen, it should be renamed via dh_install (in the doc install rule)
[09:35] <NCommander> One of the new features of dh7
[09:36] <slangasek> NCommander: not sure what you think should be renaming it, but I'm looking at the actual binary package produced; I have a libpangomm-1.4-dev package that contains both /usr/share/doc/pangomm-1.4 and /usr/share/doc/libpangomm-1.4-dev
[09:36] <NCommander> Wow O_O;
[09:36] <NCommander> that shouldn't be happening
[09:37] <NCommander> er wait
[09:37] <NCommander> ...
[09:37] <NCommander> Yeah it should, but it shouldn't be leaving the old folder behind
[09:37] <NCommander> or ...
[09:37]  * NCommander feels his head hurt
[09:37] <NCommander> the pangomm-1.4 folder is empty, right?
[09:38] <slangasek> no, it contains the docs
[09:38] <NCommander> I think I'm doing something stupid
[09:38] <NCommander> hold on
[09:38] <NCommander> Yup
[09:38] <NCommander> It's confirmed
[09:38] <NCommander> The packager is an idiot :-)
[09:39] <slangasek> oh, well, then you already know more about where the bug is than I do ;)
[09:39] <NCommander> Hrm
[09:40] <NCommander> the libpangomm-1.4-dev package is created by the deb installation
[09:41] <NCommander> Ok
[09:41] <NCommander> I think I see what's going wrong here :-)
[09:43] <slangasek> "something totally non-apparent, yay cdbs"
[09:43] <NCommander> sladen, I had a usr/share in the .install, and then the subdirectories in -doc.install
[09:44] <NCommander> So the doc package would end up empty, and everything would be in dev
[09:44] <slangasek> oh
[09:44] <NCommander> Yeah -_-;
[09:44] <slangasek> my question was why the dir name doesn't correspond to a binary package name, really
[09:44] <NCommander> Great moment of brilliance there
[09:44] <NCommander> slangasek, that's how gtkmm does it
[09:45] <slangasek> great, let's file a bug on gtkmm :)
[09:45] <slangasek> ./usr/share/doc/pangomm-2.4 -> libpangomm-2.4-doc
[09:45]  * NCommander falls over
[09:45] <slangasek> that also looks wrong in the doc package
[09:45]  * NCommander figures out where he shove a mv in cdbs to move the files in the right location
[09:45] <NCommander> I already had enough fun fixing automake scripts, this is going to fall in the dirty fix category
[09:51] <NCommander> slangasek, ok, I got it fixed
[09:52] <slangasek> new upload to REVU coming, then?
[09:52] <NCommander> slangasek, yeah
[09:53] <NCommander> slangasek, it builds fast in pbuilder here ;-)
[09:54] <NCommander> sladen, ok, its uploaded, so it should appear within the next five to ten minutes
[09:56] <NCommander> and NOW norsetto comes back to life? (with a list of 16 questions)
[09:57]  * NCommander sighs
[09:57] <NCommander> I think its time to go to bed, and deal with this braindamage in the morning
[09:57] <stefanlsd> I think i need a mentor
[09:58] <NCommander> I think I need a. life b. sleep. c. my LP account added to MOTU ;-)
[09:58] <stefanlsd> i take d
[09:58] <stefanlsd> none of the above
[09:59] <stefanlsd> how critical are gcc warnings when pbuilder runs.  ie. do they not include it - or does it all depend on the warning?
[10:00] <NCommander> stefanlsd, I'll glance at them to see if there is something like (this will cause program to crash, etc.), but otherwise, I don't go out of my way to fix it
[10:00]  * NCommander steals the lsd from stefanlsd 
[10:00] <NCommander> This is a drug-free zone :-P
[10:00] <NCommander> and now I know I'm too tired
[10:00] <NCommander> so
[10:01] <stefanlsd> mm. lsd will keep you up for another good 12 hours
[10:01] <LimCore> plus, you can then contribute to HURD
[10:02] <NCommander> LimCore, I have CVS commit access to hurd
[10:03]  * NCommander lobs a Hurd bomb at slangasek 
[10:04]  * NCommander figures if he can convert an archive admin, he can get ubuntu-hurd off the ground
[10:04] <stefanlsd> i just built a whole package and realised i should of merged from debian first
[10:04] <NCommander> stefanlsd, I've done worse
[10:04] <NCommander> I repackaged something that was already in the archive
[10:04] <stefanlsd> hehe. yeah
[10:05]  * stefanlsd goes to read the wiki on merging. sigh.
[10:05] <NCommander> I'll return
[10:06] <stefanlsd> I am doing this right right -   debian has a new revision of the package im working with.  So first i merge that.   Then i update the merged version with the upstream?     or should i just go from our current version to new upstream.
[10:06] <stefanlsd> debian has fixed some bugs thou that arnt fixed upstream that we will have to refix if we dont merge
[10:07] <slytherin> stefanlsd: A merge is adviced. Upstream update can happen anytime before feature freeze. By the way, check - http://merges.ubuntu.com/
[10:09] <stefanlsd> slytherin: thanks. will try
[10:23] <laga> what is a "universe contributor"?
[10:24] <Laney> laga: https://wiki.ubuntu.com/UbuntuDevelopers#ContribDev
[10:25] <stefanlsd> What would be the process i should be following if the merge isnt in MoM or DaD - and I need to merge the files manually from debian. I have the deb   dsc and the ubuntu older version dsc...
[10:25] <slytherin> laga: in simple words, one who has helped substantially with packaging tasks.
[10:25] <slytherin> stefanlsd: which package are you referring to?
[10:25] <stefanlsd> slytherin: im looking at diald.
[10:26] <laga> thanks.
[10:26] <stefanlsd> slytherin: there was a bug open for a sync request with debian (which i said i'd do) - but was told the maintainters do syncs. not us.  So i thought i'd update it to version 1.0 with upstream..
[10:27] <stefanlsd> slytherin: so it really needs a sync and then an upstream update..
[10:27] <dholbach> Laney: that reminds me.... you didn't apply yet :)
[10:27] <Laney> dholbach: ;) I am considering it
[10:27] <Laney> but I have the same concerns as james_w in that I don't have any particular sponsors
[10:28] <slytherin> stefanlsd: a sync needs to be confirmed by a MOTU, assuming the package is in universe. Also there should be roer reasoning in the bug why ubuntu changes should be dropped, if there were any.
[10:28] <dholbach> Laney: feel free to CC me as your sponsor - I reviewed quite some of your review requests
[10:28] <james_w> Laney: I think you should, but I see the problem.
[10:29] <DktrKranz> hey dholbach, welcome back :)
[10:29] <geser> good morning *
[10:29] <stefanlsd> slytherin: mm. ok. so in this case of diald - what exactly should i be doing...
[10:29] <dholbach> hi DktrKranz :)
[10:29] <dholbach> hey geser
[10:29] <geser> Hi dholbach
[10:29] <slytherin> stefanlsd: can you point me to sync bug?
[10:29] <stefanlsd> slytherin: i wanted to add a watch file to diald (thats how i even started looking at it...)
[10:30] <Laney> dholbach: Thanks :) I will apply in the next days then! A nudge is what I needed
[10:30]  * dholbach hugs Laney
[10:31] <stefanlsd> slytherin: https://bugs.launchpad.net/ubuntu/+source/diald/+bug/253675
[10:32] <Laney> stefanlsd: If it's been orphaned in Debian, maybe you could do the update there?
[10:33] <stefanlsd> Laney: How would i know if its been orphaned?  Its in sid...
[10:33] <Laney> stefanlsd: http://packages.qa.debian.org/d/diald.html
[10:33] <Iulian> dholbach: Hey, would you like to ack 253732 too please?
[10:34] <dholbach> bug 253732
[10:34]  * Hobbsee notes that dholbach is definetly back and working
[10:34] <Laney> dholbach: Hope you had a nice holiday, btw
[10:35] <dholbach> Laney: it was absolutely fantastic - I just have so much stuff to catch up with that I didn't have the time to blog about it yet
[10:35] <dholbach> everybody has been nudging me to upload pictures (hello james_w!)
[10:35] <stefanlsd> Laney: It says it has been orphaned with no maintainer, but last update was 2008-07-24.  I have no real personal interest in diald - but there is an upstream 1.0 i've managed to compile successfully - but i also dont really know how many people are interested in it...
[10:36] <Laney> stefanlsd: Well if you're going to update to 1.0 anyway, you might as well do it in Debian.
[10:36] <Laney> Then more people will benefit from it
[10:36] <james_w> Debian is frozen though
[10:36] <Laney> sid can still take updates though, right?
[10:36] <james_w> you may have difficulty getting it in, unless you can show that it fixes some important bugs
[10:37] <Iulian> And hopefully someone will have a look at 1.0 and adopt it.
[10:37] <Laney> I thought it was just lenny
[10:37] <stefanlsd> james_w: naa. its kinda an old piece of software thou. last upstream was 2001 and have to patch a whole bunch of depricated stuff just to get it to compile.
[10:37] <james_w> Laney: yes, it can, but it's preferred not to as it makes it harder to get a targeted bugfix in
[10:37] <Laney> Ah
[10:37] <Laney> Well there's always uploading to experimental anyway
[10:37] <james_w> Laney: I think anyway, I may be wrong
[10:38] <james_w> Laney: yep, that's a possibility
[10:39] <james_w> stefanlsd: you could email the Debian QA team to ask what to do
[10:39] <Laney> Woah, the outstanding bugs on diald are pretty old
[10:39] <Laney> stefanlsd: If your update fixes any of those then you might have a case for getting it into lenny if you move fast
[10:39] <Laney> Debian QA will be able to give you better advice anyway :)
[10:39]  * Laney -> shower
[10:41] <slytherin> stefanlsd: I can't really advice about diald.
[10:41] <slytherin> dholbach: next time you come to India, make sure you come to southern part. :-)
[10:42] <dholbach> slytherin: noted :)
[10:42] <stefanlsd> slytherin: heh. yeah. bit at a loss on what the right thing to do is...    - would be cool if we could see stats - like how many people are using it so we could see if its even worth keeping..
[10:43] <slytherin> dholbach: I was wondering what all would be needed to propose India as UDS destination?
[10:44] <dholbach> slytherin: good question - what about a PR campaign on planet Ubuntu and make Mark aware of it? :-)
[10:44] <slytherin> dholbach: :-D
[10:45] <joaopinto> Could someone review http://revu.ubuntuwire.com/details.py?package=amoebax ? Thanks
[10:46] <slytherin> dholbach: Well only suitable for UDS in India is around October. So we have to wait one year.
[10:47] <dholbach> slytherin: that'd depend on which part of India - which would you propose?
[10:49] <slytherin> dholbach: Most of the people would propose one of the Delhi, Bangalore, Mumbai. In any case summer here around March is too hot for outsiders.
[10:50] <dholbach> so April: Berlin, October: India - you have my vote! :)
[10:50] <Hobbsee> now that does sound tempting...
[10:51] <slytherin> :-)
[10:51] <Laney> stefanlsd: http://qa.debian.org/popcon.php?package=diald
[10:51] <Laney> So you'd be making at least some people happy ;)
[10:52] <dholbach> I'm just not sure though I have a vote there :)
[10:52] <stefanlsd> Laney: hey wow. didnt know that existed... does ubuntu have something similair?
[10:52] <Laney> stefanlsd: Yeah, ubuntu has popcon too
[10:52] <Laney> http://popcon.ubuntu.com/
[10:53] <Laney> I don't see how to get a graph of a single package like that though
[10:53] <Hobbsee> and ubuntu does'nt turn on popcon by default, either
[10:54] <Laney> Does Debian?
[10:54] <slytherin> geser: any idea about this error? http://paste.ubuntu.com/33316/ some problem with openjdk
[10:55] <geser> slytherin: no, perhaps doko has an idea
[11:08] <bobbo> thanks dholbach :)
[11:12] <Iulian> Congrats bobbo ;)
[11:13]  * warp10 hugs bobbo
[11:13] <dholbach> Laney: done
[11:13]  * dholbach hugs bobbo - it was well-deserved :)
[11:13] <jpds> congrats bobbo!
[11:13] <dholbach> oops... Iulian: done :)
[11:13] <warp10> hey dholbach, welcome back! :)
[11:13] <dholbach> hey warp10 - thanks
[11:14] <Iulian> dholbach: Danke
[11:14]  * dholbach goes back to triaging his inbox
[11:17] <Laney> dholbach: What is? :O
[11:18] <Iulian> Laney: That was for me.
[11:18] <Laney> aha
[11:18] <dholbach> excusez-moi
[11:32] <txwikinger> persia: I have fixed the dependency problems in ichthux
[11:34] <joaopinto> janito@ubuntu:/home/schroot$ schroot -c intrepid.i386
[11:34] <joaopinto> E: boost::filesystem::create_directory
[11:34] <joaopinto> any idea on this error ?
[11:34] <joaopinto> I did a plain debootstrap and thent created a tar from it for the schroot
[11:35] <joaopinto> (I am using intrepid amd64)
[11:35] <dholbach> vorian: your interview is online :)
[11:44] <joaopinto> uff, another bug report
[11:47] <persia> txwikinger: Excellent.  Thanks :)
[11:48] <RAOF> Hm.  How would you write a watchfile to match http://foo/Google Data APIs SDK(1.2.1.0).zip?
[11:48] <RAOF> I'm off for dinner.  If anyone feels like hitting their head with uscan, please ping me with backscroll :)
[11:52] <stefanlsd> RAOF: 'http://foo/Google Data APIs SDK\(.*\).zip'  ?
[11:54] <stefanlsd> you maybe wanna just \ the spaces also.  Google\ Data\ APIs\ SDK   ......
[12:17] <txwikinger> persia: Should I make it available now, or can it wait until I have done some of the adjustments for KDE4?
[12:18] <persia> txwikinger: Your choice.  I think it's best to strive for continual installability, but ichthux isn't the only broken flavour just now.
[12:18] <txwikinger> well.. it is on my ppa now and it installs
[12:18] <persia> If you think it will take more than a couple weeks to migrate to KDE4, maybe upload now.  If you think you'll have time to get to it soon, maybe better to wait.
[12:19] <txwikinger> I would only have to take the ppa out of the version name
[12:19] <RAOF> stefanlsd: A reasonable guess, but that was my first try :)
[12:19] <txwikinger> persia: I will see how much I get done in the next couple of days
[12:21] <txwikinger> btw.. what architectures do we support now.. Was powerpc and sparc dropped?
[12:22] <persia> txwikinger: I believe we support amd64, powerpc, i386, ia64, lpia, hppa, and sparc currently, although hppa seems to get less support than the others.
[12:23] <txwikinger> Well... somehow I could not get any powerpc and sparc from the repo
[12:23] <txwikinger> on intrepid
[12:23] <wgrant> They're on ports.ubuntu.com
[12:24] <txwikinger> Ah.. I have to try that
[12:34] <RAOF> stefanlsd: If you're interested, the correct answer is to url-escape everything.
[12:35] <stefanlsd> RAOF: can you post the correct url here...
[12:35] <RAOF> http://google-gdata.googlecode.com/files/Google%20Data%20APIs%20SDK%28(.*)%29.zip
[12:36] <stefanlsd> oh ok. cool
[12:50] <Laney> Anyone know of a PPA (or other) build of epiphany-webkit?
[12:52] <RAOF> Laney: How about the one in Intrepid?
[12:53] <Laney> RAOF: Hm, I thought that was still gecko. The epiphany-browser package in Intrepid is webkit, you say?
[12:55] <james_w> epiphany-webkit | 2.22.3-1ubuntu2 | intrepid/universe | amd64, i386
[12:58]  * Laney attempts to bakport
[12:58] <Laney> backport
[12:58] <nxvl> dholbach: hi! how was india?
[12:58] <dholbach> nxvl: hey man! congratulations! good work on the video!!!
[12:58] <sebner> nxvl: congratulations :D
[12:59]  * dholbach hugs nxvl
[12:59] <dholbach> nxvl: it was fantastic - I'll just need some more catching up with stuff before I post a blog entry with lots of pictures :)
[12:59] <james_w> congratulations nxvl
[12:59] <sebner> james_w: to you too
[12:59] <sebner> xD
[12:59] <sebner> dholbach: soo many new members O_o
[12:59] <james_w> sebner: thanks
[13:00] <vorian> nxvl, james_w, congrats :)
[13:00] <sebner> bobbo: to you too ^^
[13:00] <james_w> thanks vorian, you too
[13:00] <dholbach> sebner: yeah, I was very pleased to see applications coming in
[13:00] <dholbach> I'm sure there are a lot of good candidates still out there
[13:01] <bobbo> thanks sebner :)
[13:01] <nxvl> dholbach: it's harder than it looks to make a video
[13:01] <nxvl> dholbach: i needed to re-make it like 5 times
[13:01] <nxvl> thank you all!
[13:01] <sebner> dholbach: btw, what has happened to the discussion about u-u-c on the ML? the one started a month ago?
[13:01] <dholbach> nxvl: I re-made the first one like 41 times
[13:01] <nxvl> yeah
[13:02] <nxvl> you always make mistakes, even stupid ones, but miskatakes
[13:02] <nxvl> mistakes*
[13:02] <dholbach> nxvl: Jono was just great, until the end he managed to keep a straight face even if I got the text wrong for the umpteenth time :)
[13:03] <dholbach> sebner: can you give me a bit more context?
[13:03] <sebner> dholbach: hmm don't remember either ^^ /me has to search the ML
[13:04] <nxvl> yeah
[13:04] <sebner> nxvl: what video? link :D
[13:04] <nxvl> mi girlfriend hited the record button and then go to play wii until she didn't hear any noice
[13:04] <nxvl> sebner: you will see
[13:05] <sebner> nxvl: ahh still secret :)
[13:05] <nxvl> sebner: "getting started" in spanish
[13:05] <nxvl> nope
[13:05] <dholbach> nxvl is a real hero
[13:05] <nxvl> nah
[13:05] <dholbach> he stepped up and took the "More MOTU Videos" challenge
[13:05] <sebner> dholbach: getting started in german? made by you of course :P
[13:05] <nxvl> just a developer with energy and some free time
[13:05] <nxvl> :D
[13:06]  * dholbach hugs nxvl
[13:06]  * nxvl HUGS dholbach back
[13:06]  * sebner hugs the person who gives him the link to the new video
[13:06] <dholbach> nxvl: replied to your mail
[13:07] <nxvl> dholbach: got it :D
[13:07] <nxvl> sebner: http://nvalcarcel.aureal.com.pe/stuff/introduccion.ogg
[13:07] <nxvl> sebner: but it's in spanish
[13:08]  * sebner hugs nxvl :P
[13:09] <Laney> I should try to learn Spanish from my La Oreja de Van Gogh songs ;P
[13:09] <sebner> lol
[13:11] <nxvl> juas!
[13:12] <Laney> OK, webkit is quite an epic build. My poor CPU is now at 78C :<
[13:19] <directhex> Laney, she cannae take any more, cap'n! the core's gonnae breach!
[13:20]  * Laney bails out
[13:20] <Laney> ...it seems to be holding up alright, at 80 now
[13:20]  * Laney needs better cooling
[13:21] <stefanlsd> move to greenland
[13:21] <Laney> good plan
[13:22] <Laney> England just doesn't cut it for coldness any more
[13:23] <laga> i also need to upgrade cooling.. the stock intel cooler is quite loud in summer
[13:23] <txwikinger> move to the Antarktis
[13:23] <directhex> moar fans!
[13:23] <laga> hum, i can probably tweak that in the BIOS
[13:23] <laga> directhex: ugh
[13:24] <laga> directhex: got 4 already, that's got to be enough
[13:24] <afflux> morning. anyone from u-u-s for bug 106583? :)
[13:28] <directhex> i find myself vexed that AAC creation on linux blows goats
[13:32] <mouz> I uploaded touchfreeze to REVU about one hour ago. It does not appear in the list. There were no signs of things going wrong when I uploaded.
[13:34] <wgrant> mouz: You shouldn't be uploading a new upstream release to REVU.
[13:35] <mouz> https://wiki.ubuntu.com/SponsorshipProcess says I should?
[13:36] <wgrant> I believe that use of REVU in this situation is largely discouraged.
[13:36] <wgrant> Upload a .diff.gz instead.
[13:36] <mouz> attach to bug?
[13:37]  * Laney nods
[13:37] <mouz> thanks
[13:37] <azeem> slangasek: FTR, NCommander doesn't really have that much to do with Hurd upstream
[13:44] <azeem> nor debian-hurd, for that matter
[13:56] <stefanlsd> anyone have an idea why i cant use virt-manager to create a new kvm vm.  It gets to the assign storage space screen and clicking forward doesnt do anything...
[14:02] <stefanlsd> looks like https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/221746
[14:07] <ScottK> stefanlsd: --> #ubuntu-server
[14:15] <mouz> wgrant: what is the reason to not use REVU for this (getting new upstream version packages reviewed)?
[14:15] <emgent> moin
[14:16] <wgrant> mouz: Because that's not what REVU is for.
[14:16] <wgrant> But I must now head to bed.
[14:25] <persia> mouz: The main issues are 1) someone needs to verify the upstream orig.tar.gz (which REVU doesn't do), 2) new upstreams only require 1 ACK, so the workflow is different (which was confusing), and 3) We needed to track a bug anyway to avoid collisions (there were several examples of this happening when REVU was accepted for new upstreams)
[14:44] <bddebian> Heya gang
[14:49] <mouz> persia thanks. I updated 2 wiki pages for it.
[14:54] <persia> mouz: Thank you.  The wiki deeply appreciates the attention :)
[14:58] <ScottK> persia: The only examples of collision I remember being involved in were with Launchpad bugs and someone not refreshing the page before uploading.
[14:59] <ScottK> I was discussing #1 with Ncommander the other day and I thin it's solvable.
[14:59] <persia> ScottK: Yes, but I remember you being involved in three of them :)
[14:59] <ScottK> thin/think
[15:00] <persia> There ought have been none, but having more than one way to do it, while handy for programming languages, isn't ideal for collaborative sponsorship.
[15:00] <ScottK> We also have issues with collision when people don't look at the Launchpad bugs.
[15:00] <persia> Yes, which is part of why I advocate processes that involve looking at LP bugs.
[15:00] <ScottK> You can't force that however.
[15:01] <persia> Unfortunately :(
[15:02] <ScottK> I seriously appreciate REVUs capability to diff multple uploads of the same version.  I think it'd be useful for upgrades too.
[15:03] <ScottK> The other thing that'd be nice to hav for upgrades is a diff of the diff.gz.
[15:04] <persia> Indeed.  Maybe someone ought file some LP bugs about this.
[15:05] <persia> I know there was discussion in Boston about a new model involving LP to do this, but it seems to have gotten lost, and the code review LP feature assumes bzr, which is good for most projects, but not so much for Ubuntu.
[15:05] <ScottK> Personally I'd rather see it done on REVU where there's likely to be a design requiring fewer than 400 database queries to render on web page.
[15:06] <ScottK> Which fits in well with my estimation of Launchpad's development priority.
[15:06] <persia> Well, maybe, but I'd want REVU to grow the ability to show other outstanding bugs: compare the list of closed bugs to the list of open bugs and wonder why others may not have been fixed.
[15:06] <persia> That might be a bit of a stretch for the current codebase.
[15:07] <ScottK> When I reviewed the Launchpad 3.0 specs my "No, please don't do this" list was longer than my, "Yes, this would be good" list.
[15:07] <persia> More generally, I don't really care where it lives, so long as people are checking bugs.  We have lots of bugs.  We should close them.
[15:07] <persia> Well, that's the point of conversation: without interaction, those who don't know remain ignorant.
[15:08] <ScottK> persia: Fortunately the new U/I seems to have reduced the number of bugs reporting (this is purely a subjective assessment based on my perception of my bugmail).
[15:08] <persia> I'm not convinced that's a good thing.
[15:08] <ScottK> This is an open project.  If Launchpad developers would like to learn how it works, there's nothing stopping them.
[15:08] <persia> Further, I'm not sure it is the UI: it might be that people aren't closing bugs, so reporters aren't learning that opening bugs fixes things.
[15:09] <ScottK> persia: I was being sarcastic.  I agree.  I think the new U/I is seriously repelling people and stuff isn't getting reported.
[15:09] <persia> I'm seeing more random workarounds being posted without associated bugs these days.
[15:10] <ScottK> Perhaps.
[15:10] <ScottK> I'm not sure of the cause.  I just see a lot less bugmail.
[15:10] <persia> ScottK: Well, maybe.  I'm not much of a UI person, so can't say for certain.  I find the new one confusing, but that may just be because it is different (I was typically confused by each change to the UI since the bugzilla import)
[15:11] <ScottK> Up until yesterday I idled in #launchpad since I became aware of it.
[15:11] <ScottK> In that entire time I saw two people show up with positive comments.
[15:11] <ScottK> I didn't count the negatives, but it was a lot.
[15:11] <persia> Well, part of that is that people prefer to complain about services (and praise other people).  Then again, there could be other factors.
[15:12] <ScottK> I did praise them for keeping the quality of the no CSS design.
[16:12] <tacone> ScottK: forgive me being obvious, but.. it's summer. Could be just that the less bugmail reason, couldn't it ?
[17:24] <Lutin> Iulian: would you please mind adding comments on http://qa.ubuntuwire.com/bugs/rcbugs/ when asking for syncs which fix RC bugs in debian ?
[18:15] <ScottK> tacone: It's only summer in half the world.  There are certainly a lot of possibilities.  I recognize it's hard to tell the actual reason(s)
[18:16] <tacone> in the half which perhaps contains the most part of the community :-) I agree on the rest
[18:25] <jbicha> does anyone know why http://www.youtube.com/watch?v=zKLabbXTqMc is not available?
[18:25] <jbicha> Learning MOTU Packaging Part 1
[18:26] <Laney> jbicha: Seems to work here
[18:26] <Laney> but you can also get it at http://videos.ubuntu.com/motuvideos/
[18:27] <jbicha> ok, thanks; on youtube, it says "We're sorry. This video is no longer available"
[18:51] <sommer> top
[18:52] <sommer> woops
[19:03] <Laney> Anyone know of a good example of a library packaged with cdbs? Or is this not done?
[19:23] <james_w> Laney: hey, nice work on bug 254181, I was just filing other bugs on that when I hit yours
[19:24] <james_w> I'd love it if you could forward the change to Debian, as I have been discussing this feature with Debian, and they want the patches now
[19:24] <james_w> well, not forward that change, but forward the new diff to Debian to disable the stop links
[19:55] <stefanlsd> Im still confused.  If there is an ubuntu bug to do an upgrade to a newer version of a package, and the older same version exists in debian, do we do the ubuntu build or the debian build?
[20:03] <directhex> stefanlsd, where possible, liase with the debian maintainer & prepare a new debian package
[20:03] <directhex> stefanlsd, only make a 0ubuntu1 package if you need to. note that debian is now in freeze for lenny, so you may need to
[20:04] <stefanlsd> directhex: are they in freeze for sid stuff also?
[20:04] <directhex> stefanlsd, yes, that's how packages enter lenny - via sid
[20:05] <directhex> stefanlsd, BUT, some more active DDs may be happy to put new things in experimental
[20:05] <stefanlsd> directhex: ok ok.
[20:05] <stefanlsd> Do you know exactly what this means and how i should deal with it - NOTICE: 'curlftpfs' packaging is maintained in the 'Svn' version control system at: svn://svn.debian.org/collab-maint/deb-maint/curlftpfs/trunk/
[20:06] <stefanlsd> I also see from the changelog - it says the package is orphaned and belongs to debian QA
[20:08] <directhex> it means all the "downstream" packging stuff (i.e. the debian/ folder) is stored in svn
[20:11] <stefanlsd> directhex: kk. will see if i can find a debian doc on that
[20:14] <jmarsden> stefanlsd: I think that if the package is orphaned (has no Debian maintainer), you'll most likely have to create a 0ubuntu1 to get your bug fixed!
[20:14] <directhex> yes, true
[20:15] <directhex> or you could get commit access to the collab-maint svn
[20:17] <stefanlsd> jmarsden: i had a look at the actual debian orphan bug and someone adopted it on the 7th march 2008.  There was a later request by a debian dev on the 29th jul asking if he had done the new release. So it seems like they would like it. I will post on the bug and offer assistance, failing a response i will build a -0ubuntu1.  I think it may close a couple of LP bugs that are open with it.
[20:18] <jmarsden> stefanlsd: Sure.  If it has a new Debian maintainer, contact that maintainer by email too, maybe?
[20:19] <stefanlsd> jmarsden: cool. will do
[20:26] <SUNWjoejaxx> haha
[20:26] <SUNWjoejaxx> i forgot how to upload to revu
[20:26] <SUNWjoejaxx> hello rawler
[20:26] <SUNWjoejaxx> bah
[20:26] <SUNWjoejaxx> RainCT: *
[20:28] <RainCT> SUNWjoejaxx: dput revu ..._source.changes
[20:28] <SUNWjoejaxx> RainCT: yeah :) i just meant it has been a long time :P
[20:32] <SUNWjoejaxx> wi Run
[20:32] <SUNWjoejaxx> bah
[20:39] <rawler> SUNWjoejaxx: hello.. (yes, late, I know)
[20:39] <SUNWjoejaxx> :)
[21:03] <SUNWjoejaxx> well that stinks
[21:03] <SUNWjoejaxx> the software i was going to package is already in debian
[21:06] <directhex> damn those debian people
[21:08] <SUNWjoejaxx> haha
[21:09] <ion_> Reducing the work you have to do, how dare they?
[21:10] <SUNWjoejaxx> bah
[21:10] <SUNWjoejaxx> not reducing
[21:10] <SUNWjoejaxx> increasing
[21:10] <SUNWjoejaxx> ;)
[21:10] <SUNWjoejaxx> now i have to find another piece of software that i am interested in to package
[21:43] <anirudh0> hi...i have a warning whenever i try running python scripts...pastebin here http://pastebin.com/m7672065e
[21:44] <anirudh0> this happened recently...after i installed a python package from source..via python setup.py install..but this is about pytz, which is a std lib package..hence i was concerned
[21:45] <anirudh0> is this the right place to ask?
[21:50] <smallfoot-> please put Songbird, Flock or iFolder in repo
[21:52] <jpds> smallfoot-: You are more than welcome to do it yourself.
[21:53] <smallfoot-> im a noob, i cant do nothing
[21:53] <jpds> !packguide | smallfoot-
[21:53] <smallfoot-> i dont never understand nothing
[21:53] <smallfoot-> but its like reading a big book, and you need be smart for it
[21:53] <smallfoot-> im a dumbass
[21:54] <jpds> Time to dig in and start a new adventure? :)
[21:54] <smallfoot-> too difficult and long
[21:54] <jpds> All good things take time.
[21:54] <\sh> smallfoot-: another mozilla big package of source crap in our archives without a functioning security community? (re: songbird)
[21:55] <smallfoot-> \sh, i have no idea
[21:55] <Flannel> \sh: songbird isn't mozilla
[21:56] <\sh> Flannel: it was developed on the mozilla codebase..
[21:56] <\sh> Flannel: I just mention "XUL" ;)
[21:57] <Flannel> \sh: it runs on XUL, sure, but I don't think its related to mozilla at all.
[21:57] <afflux> \sh: ni ni ni :)
[21:57] <\sh> Flannel: it is..;)
[21:57] <\sh> afflux: lol
[21:57] <Flannel> \sh: Got a link?
[21:58] <smallfoot-> you could probably learn programming in less time than it takes to learn how to make a package
[21:58] <smallfoot-> the wiki is overwhelming
[21:58] <smallfoot-> its like reading a book
[21:58] <\sh> Flannel: I'm just searching for the history...right now, which can be easily found is: "Songbird is a media player built on top of Mozilla's XULRunner framework."
[21:58] <\sh> http://wiki.songbirdnest.com/Developer/Developer_Intro
[21:58] <Flannel> smallfoot-: That's because there's a lot to know.  It's not undoable though.
[21:58] <\sh> smallfoot-: that's wrong
[21:59] <smallfoot-> Flannel, it needs to be simpler
[21:59] <Flannel> \sh: Yeah, but using XUL and being created/associated with Mozilla are two different things.
[21:59] <afflux> the about page reads: We give a thankful super-crazy double dag-nasty dirty-style squawk to the Mozilla Foundation, the VLC team, the SQLite dude and all the innovating free and open source software developers.
[21:59] <\sh> Flannel: when songbird started, we didn't even have a common codebase for xulrunner these days...I think it was the time, when mozilla and firefox diverted totally...
[22:00] <\sh> Types of APIs for Extending Songbird
[22:00] <crimsun> ok, pedantry aside, what \sh is attempting to say is that there doesn't seem to be an active presence here in #ubuntu-motu caring for security issues related to all the code.
[22:00] <\sh> "New functionality is generally implemented in extensions which are client-side installable add-ons.  Because we're built on Mozilla"
[22:00] <Flannel> afflux: because they use XUL.  Unless you're implying that they also have people who work with sqlite and vlc
[22:01] <crimsun> meaning "it would be nice to have songbird in Ubuntu, but someone is going to have to step up and make sure the security issues are handled in the Ubuntu package"
[22:01] <\sh> crimsun: thx :) that was the real intention
[22:01] <afflux> Flannel: hehe, right. I actually didn't intend to say anything with that quote ;)
[22:01] <smallfoot-> how long does it take to make a package?
[22:02] <\sh> between 5 minutes and >1week ,-)
[22:03] <smallfoot-> oh
[22:03] <smallfoot-> there are over 500 software that needs be packaged
[22:03] <\sh> smallfoot-: there is more :)
[22:03] <crimsun> yeah, many more than 500.
[22:03] <smallfoot-> ubuntu-motu should have a package marathon
[22:03] <\sh> this wouldn't help anyone
[22:03] <crimsun> then fund one.
[22:04] <smallfoot-> im not bill gate
[22:04] <crimsun> you don't have to be.
[22:04] <\sh> a package == security, srus, people who are interested in those packages, a community who wants those software
[22:04] <directhex> don't make a package you won't personally use.
[22:04] <directhex> directhex's rule #1
[22:04] <smallfoot-> why not?
[22:04] <crimsun> smallfoot-: remember, it's a /team/ effort.  You're not expected to know everything.
[22:05] <directhex> because if you won't use it, how can you say whether it's been done properly? where's the motivation to help fix problems, or track new versions?
[22:05] <smallfoot-> please make package Flock, Songbird, iFolder
[22:05] <crimsun> smallfoot-: why not be(come) a catalyst?
[22:05] <directhex> the mozilla team is huge. needing to track security updates for flock is a terrifying idea
[22:05] <smallfoot-> directhex, better old version than no version
[22:06] <smallfoot-> crimsun, i dont know what is
[22:06] <crimsun> smallfoot-: what is what?
[22:06] <smallfoot-> crimsun, cataclyts
[22:06] <\sh> mez made some packages these days for ifolder...it had issues regarding the license..afaik...I don't know how it is nowadays
[22:06] <smallfoot-> oh
[22:06] <smallfoot-> wikipedia says is gpl
[22:06] <GreySim> smallfoot-: Have you looked at getdeb.net for any of those packages? (Dunno if linking websites like that is allowed or discouraged, so sorry if so.)
[22:07] <crimsun> getdeb is discouraged from within the confines of this channel.
[22:07] <\sh> WIKIPEDIA IS NOT ALWAYS CORRECT, NEVER BE, AND NEVER WANTS TO BE CORRECT
[22:07] <GreySim> crimsun: My apologies then, won't happen again.
[22:07] <smallfoot-> GreySim, no, but i want them in official repo
[22:07] <directhex> if it's on the internet, it's true!
[22:07] <directhex> just look at boycottnovell.com!
[22:07] <smallfoot-> i think so
[22:07] <crimsun> GreySim: no need to apologise.  Just be aware of other developers' ... displeasure with that site.
[22:08]  * directhex hides his unofficial repo behind a wooly mammoth
[22:09] <GreySim> For what it's worth, I haven't had to use any of their packages in a release or two, and only a few PPA's for fast-moving projects.
[22:09]  * \sh hunts directhex's mammoth and eats it ;)
[22:09] <\sh> PPA...that reminds me, I have to write the release announcement of leonov ,-)
[22:09] <directhex> in my defence, my repo is done with assistance from the debian and ubuntu packagers of the apps i include, and i'm pretty responsive to bug reports
[22:10] <directhex> i should check my logs, i wonder how many people use it these days
[22:11]  * \sh is harvesting youtube to get all kiss videos
[22:12] <jpds> \sh: Using clive?
[22:12] <\sh> jpds: no...
[22:13] <\sh> jpds: using amarok and a small script which sends "search requests" to youtube
[22:13] <jpds> \sh: Ah, okay.
[22:14]  * \sh needs to write an addon to count the hits on most mentioned concert locations..like "Kiss Irvine  CA 1996"
[22:14]  * directhex is pleasantly surprised by Banshee 1.2 as a media player
[22:15] <smallfoot-> put frostwire in repo
[22:16] <crimsun> smallfoot-: just a note:  it's likely more productive to file wishlist bug requests against 'Ubuntu' using bugs.launchpad.net
[22:16] <smallfoot-> it already exis
[22:16] <smallfoot-> flock been requested for over a eyar
[22:16] <smallfoot-> nothing is done
[22:16] <smallfoot-> frostwire been requsted loooong time ago, nothing happens
[22:16] <crimsun> smallfoot-: have you considered helping packaging?  Asking here won't speed up the process.
[22:17] <smallfoot-> i cant help, im a noob, and you have to read a 100000 page guide, its thicker than the bible
[22:17] <jpds> smallfoot-: So, look at the videos.
[22:17] <\sh> but the bible is totally wrong in things like packaging, really...no joke
[22:17] <smallfoot-> there are videos?
[22:17] <smallfoot-> at least bible have dragons and stuff
[22:18] <crimsun> yes, there are videos.
[22:18] <smallfoot-> oh
[22:18] <\sh> on youtube actually
[22:18] <\sh> just search for ubuntu developer channel
[22:18] <smallfoot-> http://video.google.com/videoplay?docid=-6726522426109060914 oh that 56 minutes
[22:18] <crimsun> http://www.youtube.com/ubuntudevelopers
[22:19] <jpds> smallfoot-: https://wiki.ubuntu.com/MOTU/Videos
[22:19] <smallfoot-> ok
[22:19]  * NCommander fights with barry
[22:20] <azeem> bddebian: ?
[22:20] <azeem> eh, bddebian?
[22:21] <\sh> now ways..
[22:21] <\sh> bddebian never fights
[22:21] <azeem> dude, he's a marine
[22:21] <james_w> smallfoot-: https://edge.launchpad.net/~fta/+archive
[22:21] <\sh> azeem: so?
[22:22] <james_w> smallfoot-: it looks like fta is working on it
[22:22] <james_w> smallfoot-: you could join #ubuntu-mozillateam and see what you could do to help
[22:22] <\sh> azeem: he's lazy, yes, but he doesn't fight ;)
[22:22] <bddebian> I'm a pushover :)
[22:22] <bddebian> HEY
[22:22] <\sh> bddebian: sorrya..I'm a d*ck ,->
[22:23] <\sh> damn..this release announcement gives me a headache
[22:24] <\sh> bddebian: what do I need to do to make you writethis announcement?
[22:24] <crimsun> \sh: ping me if you need someone to proof it.
[22:24] <\sh> crimsun: the problem are not the facts..the problem is more the "intro"
[22:25] <bddebian> \sh: Give me a brain transplant? :)
[22:25] <\sh> it needs to rock it needs to shock...
[22:25] <crimsun> "So you hate Web 2.0."
[22:25] <\sh> bddebian: I think I'll have to force you to code python
[22:26] <bddebian> heh
[22:26] <\sh> crimsun: rock
[22:26] <\sh> that's something
[22:26] <crimsun> (yes, that's why we don't have ops here.)
[22:27] <\sh> hmm?
[22:27] <crimsun> nothing related to the announcement ;)
[22:28]  * jpds whistles.
[22:28]  * ScottK-laptop wonders about context.
[22:28] <\sh> -ENOCONTEXTNEEDED
[22:28] <ScottK-laptop> OK.
[22:29] <\sh> harhar
[22:29] <\sh> crimsun: really thx...I just got the right song
[22:29] <crimsun> \sh: anytime
[22:29] <ScottK-laptop> Well clearly I need to work harder on my bug work.  I've filed 22 launchpad bugs in 15 days.  That's ~1.5 per day.  Nowhere near 5.
[22:30] <\sh> crimsun: actually it was the very first song I decideded to use..but now I'm convinced
[22:35] <\sh> crimsun: http://www.youtube.com/watch?v=692DSE-M7Es <- this will be the intro ,-)
[22:37] <directhex> erm, wtf. i count almost six thousand unique IPs pulling down Packages.gz from my repository in the month of july
[22:37] <SUNWjoejaxx> directhex: haha lol
[22:38] <SUNWjoejaxx> i wonder how many people use me as a perl mirror
[22:38] <directhex> SUNWjoejaxx, that's for my own packaging though, not a mirror of anything
[22:39] <\sh> damn...I was just to enter "pkginstall SUNWjoejaxx"
[22:40] <directhex> who uses solaris-based systems without apt? O_o
[22:41] <\sh> ,-)
[22:43] <SUNWjoejaxx> \sh: rofl!
[22:45]  * ScottK-laptop takes note of the state of his battery and shuts down ....
[23:00] <emgent> heya
[23:02] <RoAkSoAx> nxvl, congrats!!
[23:08] <jmarsden> How can I enable rebuilding manpages in a package that has a Makefile.in with a line such as   @ENABLE_REGENERATE_MAN_TRUE@README: pam_limits.8.xml limits.conf.5.xml    in it?
[23:08] <nxvl> RoAkSoAx: thanks
[23:09] <jmarsden> I updated a .xml file, the manpages are not getting updated by default...
[23:11]  * \sh goes to bed...
[23:11] <jpds> g'nacht \sh