[07:00] <dholbach> good morning
[07:03] <ajmitch> morning dholbach
[07:03] <dholbach> hi ajmitch
[07:30] <ronin___> hi dholbach
[07:30] <dholbach> hi ronin___
[07:31] <iulian> Morning.
[07:31] <ronin___> morning iulian
[08:09] <hakermania> tumbleweed, thanks for the review. About the too many system calls, could we avoid it? I think that we only call it so as to set the desktop background, call the music players and to delete things
[08:09] <hakermania> Maybe the last one could be "C++azed"
[08:09] <hakermania> but the others seem fine, to me :/
[08:20] <jtaylor> you should be able to control everything over dbus
[08:21] <hakermania> jtalor, I think im  good sending dbus messages, xD. Any other info about this? Should I send messages to the system so as to tell it what to run?
[08:21] <hakermania> jtaylor, .
[08:36] <tumbleweed> hakermania: I was just suprised to find a C++  program that was half-shell
[08:37] <tumbleweed> hakermania: they could all handle errors a bit better (use && instead of ; or use set -e)
[08:37] <tumbleweed> hakermania: btw, the sounsd aren't included in the binary package
[08:45] <hakermania> tumbleweed, thanks. I was surprised to find out that the build didn't work for you. Also I thought that the watch file was looking in a specific folder of sourceforge where i've placed the source. But it seems that it looks for the file that sourceforge considers as last
[08:46] <hakermania> And I don't know how to change it to the real last source (V2.0 GNOME 3)
[08:59] <tumbleweed> hakermania: the problem with the watch file is that you're matching .* as a version. maybe you should use [0-9.]+
[09:01] <hakermania> tumbleweed, thanks. About the sound files, why aren't they included into the binary package? I mean they are into the DEB file and when zi did a complete unistallation of the program and re-installed through the DEB the sound files where there
[09:01] <tumbleweed> hakermania: they aren't in the deb I built
[09:01] <tumbleweed> "debc" will show you what's in the deb that just built
[09:02] <hakermania> tumbleweed, I thought you said "Package doesn’t build", how did you manage to build the DEB? Also in what environment are you building? This source doesn't build in Natty but in Oneiric it does
[09:02] <tumbleweed> hakermania: by overriding dh_auto_install, as I mentioned in the comment
[09:02] <tumbleweed> oneiric, of course, hang on, I'll give you a build log
[09:04] <tumbleweed> http://paste.ubuntu.com/669042/
[09:07] <jtaylor> :( pypy does not work in oneiric anymore :( needs libffi.so.5
[09:07] <jtaylor> and my machine is not powerful enough to rebuild it
[09:07] <tumbleweed> hakermania: your 'make install' calls 'make clean' That could be problematic :P
[09:08]  * tumbleweed pokes a pypi developer
[09:08] <tumbleweed> err pypy
[09:09] <hakermania> tumbleweed, I am a bit confsed with the clean step. Should it done at the end or at the begginning? In my case it is done in the beginning...
[09:09] <hakermania> Also, you said I should run 'make clean' before uploading or something, while the source seems clean (no .o files, no binary etc)
[09:09] <hakermania> tumbleweed: Fetched 74.8 MB in 3s (21.3 MB/s) o.O?
[09:10] <tumbleweed> local mirror
[09:10] <jtaylor> apt-cacher-ng ftw :)
[09:10] <tumbleweed> hakermania: the source package includes some foo~ files
[09:11] <hakermania> tumbleweed, I hate gedit -_-
[09:11] <tumbleweed> clean is what you do when you're done and want to build everything from scratch again. you probably don't want to do it inbetween building and installing
[09:13] <hakermania> tumbleweed, Ok, I'll take care of it. But now im more confused :/ you said that dist-clean should remove debian/wallch* and debian/files etc plus wallch (the exectuable), so I assume you need a total clean, leaving the source as it was initially
[09:13] <hakermania> So, why not having the 'make clean'?
[09:13] <tumbleweed> hakermania: no I didn't say that
[09:13] <tumbleweed> err
[09:14] <tumbleweed> I said you don't need to remove those manually in debian/rules, distclean will take care of the upstream parts, and debhelper will take care of the debhelper parts
[09:14] <tumbleweed> you don't need your clean rule in debian/rules at all
[09:14] <hakermania> Yes, but apparently (at least in my case), distclean leaves the wallch untouchable and also the debian/wallch* and debian/files files are not removed. So, somebody's not doing its job well (i assume me xD)?
[09:15] <tumbleweed> hakermania: no I don't mean *you* must run distclean
[09:15] <tumbleweed> I mean running debian/rules clean (without your clean rule in it) should do the trick, because debhelper will clean up after itself and will run make distclean
=== almaisan-away is now known as al-maisan
[09:16] <hakermania> tumbleweed, yes but it doesn't
[09:17] <tumbleweed> it does for me
[09:17] <tumbleweed> if you remove the clean rule from debian/rules
[09:17] <hakermania> tumbleweed, oh you mean that it finds that a clean rule exists and so it doesn't run its clean rules?
[09:18] <tumbleweed> yes, you are stopping "dh clean" from running
[09:18] <hakermania> Ok thanks :)
[09:19] <tumbleweed> jtaylor: actaully, debmirror. I can live with being a bit out of sync, although some people call that herecy :P
[09:22] <hakermania> tumbleweed, I found out why the source didn't build for you. You need to run 'sudo debuild -S', because during installation I call update-desktop-database which needs root
[09:23] <hakermania> I do that to associate the new mime type with the desktop file
[09:23] <tumbleweed> hakermania: that would be wrong
[09:23] <hakermania> tumbleweed, it's the only way I think
[09:23] <tumbleweed> we don't need the buildd to have an up to date desktop file database
[09:24] <hakermania> tumbleweed, without this rule the DEB file doesn't associate the desktop file with the mime type
[09:24] <tumbleweed> hakermania: you're missing my point
[09:24] <hakermania> Yes probabl
[09:24] <hakermania> y
[09:24] <tumbleweed> hakermania: update-desktop-database updates the database of the machine you run it on, not the machine you install the deb on
[09:25] <hakermania> tumbleweed, can't we assume that it would be the same machine? If not, how would I make it work :( ?
[09:25] <tumbleweed> it's pretty safe to assume it isn't the same machine. I don't think our build daemons have desktop backgrounds that need changing
[09:27] <tumbleweed> hakermania: but guess what. dh_installmime detects that you are installing a mimetype, and adds "update-mime-database /usr/share/mime" to the postinst script that gets run when your deb installs
[09:30] <hakermania> tumbleweed, i think that's not enough
[09:31] <hakermania> that updates the system's mime lists but does not associate it with the desktop file
[09:32] <tumbleweed> hakermania: then add *that* to the postinst
[09:33] <hakermania> tumbleweed, should I edit a debian/^ file to do so?
[09:34] <tumbleweed> yes
[09:46] <hakermania> tumbleweed, in the current status, 'uscan --report' shouldn't output anything, right?
[09:47] <tumbleweed> yes. With a --verbose it should tell you you have the latest version
[09:49] <hakermania> -_- http://qa.debian.org/watch/sf.php/wall-changer/ failed: 500 Can't connect to qa.debian.org:80 (Bad hostname 'qa.debian.org')
[09:49] <philipballew> QUESTION: there is software in the current ubuntu repos that has updated versions but the version in the ubuntu repos is from 08. can this be fixed?
[09:52]  * philipballew is willing to fix it to
[09:52] <tumbleweed> hakermania: that sounds like a problem on your end :)
[09:53] <hakermania> tumbleweed, you mean its my ISP's fault? Also, when do I call libglib2.0-bin through system()?
[09:53] <tumbleweed> philipballew: of course it can. The question is how important is it to update these packages (we are in feature freeze) and who maintains them (why hasn't it been updated yet)
[09:53] <jtaylor> philipballew: which software?
[09:54] <tumbleweed> hakermania: gsettings?
[09:54] <hakermania> tumbleweed, I see. What about the 1st question? My browser connects to qa.debian.org normally
[09:55] <tumbleweed> maybe it was a spurious error then
[09:55] <tumbleweed> (your ISPs DNS resolvers just suck)
[09:55] <hakermania> ok thanks :P
[09:56] <philipballew> jtaylor, kismet
[09:58] <jtaylor> philipballew: the package seems orphaned in debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534884
[09:58] <ubottu> Debian bug 534884 in kismet "new version and core of kismet" [Normal,Open]
[09:59] <philipballew> jtaylor, i see. so basically noone is packaging it anymore?
[09:59] <jtaylor> last upload of that maintainer was in 2008
[09:59] <jtaylor> it probably needs a new maintainer
[10:00] <philipballew> i see. well it appears jtaylor that the kismet team is making their own deb's for people and their own repo for people to add for their sources list
[10:01] <philipballew> if a maintainer is needed I can be that, but i am really bad at packaging. could learn, but whatever
[10:01] <hakermania> tumbleweed, as for the copyright, should I just change the 'Format' field to the latest? (http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?revision=174)
[10:02] <hakermania> Because as I see there aren't any major format changes...
[10:03] <tumbleweed> hakermania: fine, I was just pointing it out
[10:04] <jtaylor> philipballew: if you want to do that you should ask in #debian-mentors on irc.debian.org for advice, maybe also ask fourmond@debian.org who did two non-maintainer uploads recently if he has plans with this package or contact to the original maintainer
[10:04] <hakermania> tumbleweed, I just think that the url I provided above isn't the correct one. I mean it does point out to the latest format but the page doesn't look like this: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=152
[10:05] <hakermania> it is the previous format I used. And replacing 152 with 174 returns error
[10:05] <tumbleweed> hakermania: we know about that, don't worry it was the correct one
[10:05] <hakermania> Ok thanks
[10:10] <hakermania> tumbleweed, what's the problem in installing to /usr/share?
[10:12] <tumbleweed> hakermania: please elaborate?
[10:15] <hakermania> tumbleweed: "The upstream makefile probably should be installing to /usr/local not /usr/share"
[10:16] <jtaylor>  /usr/share is package manager land, trespassers will be shot
[10:17] <tumbleweed> that's not an issue for this package, it's an issue for people who install it from source
[10:21] <hakermania> tumbleweed, so, source should install to /usr/local/ and package to /usr/share/? How can I achieve this? For somebody who builds from source it's like doing the same thing with building the deb but actually installing it immediately to his system (copying files etc immediately)
[10:22] <jtaylor> your makefile should support DESTDIR, default to /usr/local and the package overwrittes it to /usr
[10:23] <tumbleweed> you can achive this by making your upstream makefile use /usr/local as PREFIX. dh_auto_configure will pass PREFIX=/usr to qmake
[10:23] <tumbleweed> jtaylor: this is qmake, so it uses INSTALL_ROOT rather than DESTDIR. Also, aren't you mixing up DESTDIR and PREFIX?
[10:24] <hakermania> Wait, and then through the code how would I call a sound file if I don't know where it is located?
[10:24] <jtaylor> don't know qmake, but in normal Makefiles DESTDIR is the same as PREFIX
[10:24] <jtaylor> http://www.gnu.org/prep/standards/standards.html#DESTDIR
[10:25] <tumbleweed> hakermania: you know at build time, because you can use PREFIX
[10:25] <tumbleweed> jtaylor: PREFIX is where it will be installed, DESTDIR diverts the installation (e.g. into debian/tmp)
[10:25] <jtaylor> oh
[10:25] <jtaylor> ok then I mixed them  up
[10:26] <hakermania> tumbleweed, I think i'm missing something. Let's say that somewhere in the code it says 'system("canberra-gtk-play /usr/share/wallch/a.ogg");
[10:27] <hakermania> How am I supposed to change it if user builds from source?
[10:27] <hakermania> (and the it will be /usr/local not usr/share
[10:27] <hakermania> )
[10:27] <tumbleweed> you'd play PREFIX + "/share/wallch/a.ogg"
[10:28] <hakermania> Where PREFIX would be /usr or /usr/local, got it
[10:35] <hakermania> Does qmake knows which prefix to use each time :/ ?
[10:36]  * hakermania feels a bit noob
[10:36] <tumbleweed> export DH_VERBOSE=1 and you'll notice that qmake is called with PREFIX=/usr by dh
[10:37] <tumbleweed> obviously users installing at home wouldn't do that, so it would use the default (which you should make /usr/local)
[10:42] <hakermania> tumbleweed, so, to make it clear, the prefix that dh uses is '/usr' no matter the default (being '/usr/local'). Also, the default should be specified during the creation of makefile (qmake PREFIX=/usr) or inside the project file? I suspect the latter
[10:43] <tumbleweed> inside the project file
[11:04] <hakermania> tuumbleweed, it's the first time I use the PREFIX variable. Do I call it straightly in my program as you told previously (PREFIX+"/share/etc)? Also guys on #qt doesn't seem to know anything about PREFIX :P
[11:08] <tumbleweed> hakermania: read the gnu coding standrds (that jtaylor linked to). You'll also need to modify your qmake project to make it pass -DPREFIX=$PREFIX to g++
[11:11]  * hakermania is something like http://bit.ly/qYeDvs
=== al-maisan is now known as almaisan-away
[11:32] <hakermania> tumbleweed, how does the dh overrides the default PREFIX?
[11:34] <tumbleweed> hakermania: 12:36 < tumbleweed> export DH_VERBOSE=1 and you'll notice that qmake is called with PREFIX=/usr by dh
[11:47] <hakermania> tumbleweed, I think I've found it!!!! It should look like this inside the makefile: http://paste.ubuntu.com/669150/ doesn't it????
[11:48] <Laney> who has a lucid i386 installation on bare metal and wants brownie points?
[11:49] <tumbleweed> hakermania: yes, you need to make qmake generate that
[11:49] <tumbleweed> Laney: only have a lucid i386 kvm vm
[11:50] <Laney> nah, not tricksy enough, cheers though
[11:51] <tumbleweed> Laney: actually, I do have one of those
[11:51] <Laney> yeah? fancy test building mono from oneiric? :-)
[11:52] <hakermania> tumbleweed, I did it!!!!
[11:52] <hakermania> Whola!
[11:52] <tumbleweed> should it build with nothing special?
[11:52] <Laney> an oneiric chroot should be fine
[11:52] <Laney> don't know about the backport
[11:53] <tumbleweed> aah
=== almaisan-away is now known as al-maisan
[11:53] <Laney> nobody can reproduce this ftbfs, but i don't think any of us have a similar enough setup to the buildds
[11:54] <Laney> vms are no good, oneiric kernel is no good
[11:54] <Laney> i386-on-amd64 is no good
[11:54] <tumbleweed> heh
[11:55] <jtaylor> squeeze kernel is no good
[11:55] <ajmitch> i386 kernel with i386 oneiric vm on amd64 host is no good
[11:55] <ajmitch> we've been having a fun time building
[11:55] <Laney> woe is the debian mono group
[11:56]  * tumbleweed is debootstrapping...
[11:56] <ajmitch> it's a sad day when we're disappointed that the build works fine
[11:56] <Laney> so if you can reproduce, it's bisectin' time
[11:57]  * tumbleweed should probably ionice this a bit, it *is* a production fileserver, but I don't think anyone will notice
[11:57] <ajmitch> production? who cares about that, packages are on the line here!
[11:58] <tumbleweed> it's for an unmaintained lab with 5 year old hardware, if they can log in, that's better than average
[11:58] <Laney> there won't *be* a production if we don't fix this!
[11:59] <nigelb> Laney: lucid i386?
[11:59] <nigelb> I do
[12:00] <hakermania> Should I have the Makefile in the orig.tar.gz?
[12:00] <hakermania> NO!
[12:00] <Laney> nigelb: you can also try rebuilding mono from oneiric if you want :-)
[12:00] <nigelb> lp-pull-source and put it into a pbuilder?
[12:01] <Laney> pull-lp, yeah
[12:01] <nigelb> do I need to make any changes?
[12:01] <ajmitch> nope
[12:01] <nigelb> trying now
[12:01] <nigelb> need to find if  still have a lucid pbuilder though
[12:01] <Laney> if it's pbuilder-oneiric
[12:01] <ajmitch> 2.10.4-2 is what failed on a couple of buildds
[12:01] <Laney> we want oneiric guest, lucid host
[12:02] <nigelb> my pbuilder is probably lucid pbuilder
[12:02] <nigelb> oooh
[12:02] <ajmitch> update it!
[12:02] <nigelb> put it throgh an oneiric pbuilder?
[12:02] <ajmitch> yes
[12:02] <nigelb> also, source package name
[12:02] <nigelb> mono?
[12:02] <ajmitch> 'mono'
[12:03]  * ajmitch hopes it's not stupidly hardware dependent somehow
[12:03] <nigelb> getting source
[12:03] <nigelb> anyone seen persia around lately?
[12:03] <ajmitch> see you in a couple of hours
[12:03] <Laney> no
[12:03] <tumbleweed> nigelb: not since debconf
[12:04] <nigelb> hmm
[12:04] <nigelb> *facepalm* ssh'd into a machine and typed up arrow for byobu. The last command was reboot.
[12:04] <nigelb> s/typed/pressed/
[12:04] <ajmitch> well done :)
[12:05] <tumbleweed> better than halt :)
[12:05] <Laney> didn't it need a password?
[12:05] <nigelb> no passwd
[12:05] <nigelb> or whatever that settign is in /etc/sudoers
[12:05] <Laney> ssh root@...
[12:05] <tumbleweed> Laney: how long until expected build failure?
[12:05] <Laney> depends how fast your hardware is
[12:06] <Laney> it was about 40 minutes on the buildd
[12:06] <tumbleweed> dual-xen 3Ghz, 2G RAM
[12:06] <tumbleweed> xeon
[12:06] <Laney> builds a load of native stuff, then mcs [basic] stuff, then [net_2_0], then [net_4_0], then mdoc which is where it fails
[12:07] <tumbleweed> ok, it's building, I'm going to go out for a bit
[12:09] <nigelb> dammit, I have so much source code lying around that I have no more space.
[12:10] <ajmitch> mono will take a fair bit
[12:10] <hakermania> Ok, about the code now, you told me that I could solve the system calls through sending dbus messages. How-to?
[12:10] <ajmitch> about 1.1GB used on my clean VM's ~ so far
[12:12] <nigelb> Firefox source + compiled code eats my space.
[12:21] <sladen> nigelb: reboot & history -r
[12:26] <nigelb> sladen: heh, I just typed it out manually instead of arrows
[12:26] <nigelb> later, I'll find who did the exit instead of Ctrl + D :)
[12:39] <nigelb> everytime, I see the gpg key password dialog box
[12:39] <nigelb> I remember UDS lighting talks and james_w :)
[13:30] <hakermania> tumbleweed, OK, now that I made qmake take PREFIX, how do I use it inside my code? What is it? char?
[13:30] <hakermania> Should I define it?
[13:32] <tumbleweed> hakermania: you are defining it with -D
[13:32] <tumbleweed> so yes, it' sa string instrted by the preprocessor, you can do "foo " PREFIX "/share/bar"
[13:37] <tumbleweed> Laney: my mono has got as far as running make check
[13:37] <Laney> tumbleweed: alright, that's too far then
[13:38] <Laney> you can't reproduce it either, thanks for trying :(
[13:38] <Laney> directhex:
[13:39] <directhex> sigh
[13:41] <Laney> shall we ask that guy for a shell yet?
[13:41] <hakermania> tumbleweed, what about the 'uninstall' scipt? Should it check if wallch is installed in /usr/share or /usr/local/ or automatically trying to remove from /usr/local/ ?
[13:43] <tumbleweed> hakermania: it'll only be run by people who installed from source, so it sholud only remove from /usr/local
[13:45] <hakermania> GOT IT
[13:46] <hakermania> tumbleweed, as for the pictures, the monitor comes from a site with NO WARRANTY and we've send some emails to request for the other images (i assume we should have done so before using them :P)
[13:47] <hakermania> tumbleweed, also: error: ‘PREFIX’ was not declared in this scope
[13:48] <tumbleweed> hakermania: then you aren't declaring it with -DPREFIX=whatever
[13:48] <tumbleweed> hakermania: "NO WARRANTY" does not equate to claming copyright for it and distributing to others under the GPL
[13:54] <hakermania> tumbleweed, http://www.clker.com/disclaimer.html
[13:59] <tumbleweed> hakermania: that does say that everyone uploading to the site certifies their artwork is in the public domain. You should probably state where you got it from in your licence information
[14:01] <hakermania> No I don't think so
[14:03] <hakermania> tumbleweed, I made PREFIX to work but it seems like a straight /usr/local inside the program... For example "a" + PREFIX + "b" returns: usr/local was not declared in this scope
[14:08] <tumbleweed> hakermania: you don't think so?? you probably want to define it with quotes around the value.
[14:15] <hakermania> tumbleweed, I already have (DEFINES +="PREFIX=\"/usr/local\"") and I get the same errors. And yes, I think that the site is quite clear that anybody can do anything with its pictures unless it has to do with porn or breaking a law
[14:18] <tumbleweed> hakermania: and the way you avoid archive-admins / ftp-masters asking the same questions I did is by including the necessary informationn in debian/copyright.
[14:21] <hakermania> Ok, so should I make debian copyright say Files: Pictures/monitor.png and then License? What?
[14:22] <tumbleweed> DEP5 explains how you should handle public domain
[14:49] <AnAnt> dholbach: Hello, thanks for the ACK.
[14:49] <AnAnt> dholbach: you've been away for a while ?
[14:49] <dholbach> AnAnt, yes, I was on holidays for 2 weeks :)
[14:50] <AnAnt> dholbach: note, I will just fix the title of #819692, it is -11 to be sync'ed not -10
[14:50] <dholbach> sounds good
[14:57] <AnAnt> dholbach: do I really have to comment on 812120 ?
[14:57] <AnAnt> dholbach: I mean , the changelog speaks for itself
[14:58] <Laney> Why should we break the freeze for this version — i.e. does it fix any bugs that are present in Ubuntu currently?
[15:00] <AnAnt> Laney: not that I know of
[15:00] <dholbach> I talked to Colin about it and it was his suggestion - I can see why somebody would be a bit hesitant to update a package which virtually every other package build depends on :/
[15:01] <AnAnt> yes
[15:01] <AnAnt> well, I filed it before freeze actually, but since we are after freeze, the changes in changelog might be scary
=== al-maisan is now known as almaisan-away
=== bdrung_vacation is now known as bdrung
[16:16] <tumbleweed> cyphermox: I just got one of your usb-modeswitch segfaults
[16:16] <cyphermox> tumbleweed: yeah
[16:17] <tumbleweed> the bug's still marked as incomplete, need anything tested?
=== JanC_ is now known as JanC
[16:37] <cyphermox> tumbleweed: does the workaround at the end work for you? and can you reproduce and see where it crashed if you were to run this in ltrace or something?
[16:38] <cyphermox> I'd really like to understand why it's crashing, which is what I don't have now, just a change in how the file handles are redirected, and I don't understand why it makes it work
[16:40] <tumbleweed> cyphermox: the workaround seems crazy to me, esp as that code path isn't involved
[16:41] <tumbleweed> cyphermox: it doesn't segfault under strace (loops through something big, forever), but it does under ltrace
[16:42] <cyphermox> ah?
[16:42] <cyphermox> as run manually or though the udev script?
[16:42] <tumbleweed> run manually
[16:42] <tumbleweed> damn, it just worked
[16:43] <cyphermox> see, the problem is no matter how much I try it always works for me, except the first time I tried to reproduce it; at which point I obviously had nothing ready to catch where the bug was ;)
[16:44] <cyphermox> if your system is looping through things for a long while, your 3g dongle likely needs scsi attributes; which is a little less well tested.
[16:45] <cyphermox> but if you can give me some piece of info more than just the segfault message from syslog (I can't parse that, unfortunately), then it's going to be a win already :)
[16:45] <tumbleweed> yeah, let me spenda little more time on it (and grab some debug symbols)
[16:46] <cyphermox> even just a the usb_modeswitch.log from /var/log if you enable logging in /etc/usb_modeswitch.conf first, is good
[16:49] <tumbleweed> can't trigger it if I enable logging :/
[16:53] <cyphermox> tumbleweed: maybe that's why I can't reproduce it either
[16:54] <cyphermox> do you have the ltrace output where it failed?
[16:55] <tumbleweed> commented on the bug, but it's only ltrace, no output from usb_modeswitch_disptatcher
[16:56] <tumbleweed> yeah if I try to catch stdout and stderr, it doesn't segfault
[17:09] <cyphermox> so it's got to be something about file handles
[17:10] <tumbleweed> cyphermox: got it in gdb, see bug
[17:11] <cyphermox> amazing, you rock
[17:13] <tumbleweed> righ,t now I can go to pub quiz and leav you to fix it :)
[17:15] <cyphermox> yup
[17:15] <cyphermox> found two issues with the data you gave there
[17:15] <cyphermox> thanks!
[17:15] <tumbleweed> np
=== medberry is now known as med_out
[18:34] <lfaraone> micahg: myself, I'd prefer to just  have the new upstream version packaged and SRUed, but I think that's about a snowball's chance in hell of happening.
[18:34] <micahg> lfaraone: I think SRUing version 2 would be better, even though it has new features as the current version is totally broke, but IANA release team member
[18:35] <micahg> lfaraone: no, if the current version worked it would be a problem, but it doesn't :)
[18:36] <lfaraone> micahg: hm. I'll repeat my offer, want to maintain another package in Debian? :)
[18:37] <micahg> lfaraone: I'm still working on the first :), I have no inherent interest in blogtk, there seems to be interest in UBuntu for it though as the original bug for deprecating python-gtkhtml keeps getting a ping on blogtk
[18:38] <micahg> lfaraone: but if the package isn't too bad, maybe I can get the ball rolling on it
[18:41] <lfaraone> micahg: I've seen more lintian warnings. https://launchpad.net/~jayreding/+archive/ppa/+files/blogtk_2.0%7Eppa6%7Elucid.dsc
=== med_out is now known as med
=== med is now known as medberry
[20:03] <hakermania> tumbleweed, DEP5 says that "If a work has no copyright holder (i.e., it is in the public
[20:03] <hakermania>      domain), that information should be recorded here."
[20:04] <hakermania> And it refers to the Copyright, field
[20:04] <hakermania> But how?
[20:04] <hakermania> Should we include the site's name?
[20:04] <hakermania> Along with our names?
[20:12] <hakermania> Also what about the straight PREFIX?
=== yofel_ is now known as yofel
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== medberry is now known as med_out
=== Amaranthus is now known as Amaranth