[00:00] civija: It doesn't look like it -- unless you also change the section to contain "universe" [00:02] fwiw, I just tried it with the hello package and it worked fine [00:02] updated the maintainer to ubuntu-core-dev [00:03] Laney: try the --section switch... [00:03] mok0_: I just shut down my eee :( [00:03] Laney: --section=universe [00:03] eeek [00:03] mok0_: update-maintainer *should* change Maintainer to XSBC-Original-Maintainer, any time that it succeeds in doing anything [00:03] :-) [00:04] though sometimes you have to tell it which section your package is going to, yes [00:14] civija: does the most recent version of the package (ie. the first line in debian/changelog) contain 'ubuntu' ? [00:16] Adri2000: no [00:16] I'd like to change the versioning of a kernel module package to use the kernel ABI in the first part, but the package is currently at version 15 already. Looks like I need an epoche, correct? [00:16] civija: that's why it won't change the maintainer then [00:17] Adri2000: so i should first run dch -i, write change ..., and then run update-maintainer? [00:17] blueyed: e.g., or a suffix appended with + [00:17] civija: yes [00:18] Adri2000: ok, tnx [00:18] i'll try that [00:18] crimsun: i.e. 15+2.6.24-12.1? (15 is the current version) [00:19] blueyed: that's the idea, though I suppose I tend to match the 12.x portion against the headers, so I think 12.22? [00:20] blueyed: (though, if you're tweaking it, that's up to you) [00:25] crimsun: well.. I've thought that it wouldn't be important for the package and therefore I use my revision there at the end. [00:25] blueyed: fair enough. [00:26] It should get moved to linux-ubuntu-modules anyway in the long term I think, so.. [01:11] Heya gang [02:05] heya bddebian. === Yasumoto is now known as [CA]Yasumoto === tritium is now known as [NM]tritium [02:08] Hi ScottK2 === [NM]tritium is now known as tritium[NM] [02:20] Nightrose: ? [02:21] (evolution-jescs given back) [03:52] hi. Pbuiler is returning me an error message i just can't understand why... It says it can't install libjack-dev [03:53] does anyone know a possible reason for it? [03:54] You don't have universe enabled in your pbuilder environment? [03:55] StevenK, how can I enable it? [03:55] uhm, strange problem.. when i try to edit control and add Maintainer, when i debuild, change Maintainer with original.. [03:55] some idea? [03:56] emgent: There's a debian/control.in file? [03:56] phpmyadmin package.. [03:56] uhm just a moment [03:56] Legendario: Um, add universe to your components and pbuilder update with --overwrite-config [03:57] !pbuilder | Legendario [03:57] Legendario: pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto [03:57] Legendario: actually follow ^& [03:58] StevenK: no only control [03:58] hum, no. There is only a debian/control file, not a debian/control.in [03:58] trye [03:58] *true* [03:58] StevenK: other idea? :° [03:58] emgent: Then I'd need to read a build log [03:59] i saw that in debdiff [03:59] when i run debuild, cleaned my edit in debian/control file [04:00] strange.. [04:00] emgent: Yes, so something in the build process is changing it. So I'd need to read a build log to point out what is doing it. [04:04] ok, so, i had to edit my ~/pbuilderrc file, right? Thanks guys [04:05] StevenK: i think this "yada rebuild control" [04:06] Nooooooooooooo [04:06] * StevenK runs screaming [04:07] yada has a "Please break my builds in hard to track, near-random ways" option? [04:07] Yes. That is its default mode of operation [04:07] * RAOF shudders [04:09] * RAOF gets around to actually _filing_ his "sensors-applet does nothing but segfault" bug. === adorablepupp1 is now known as adorablepuppy [04:14] uhm... [04:15] Hi. === ZarroBoogs is now known as Pici [04:18] StevenK: some idea to bypass yada rebuild ? [04:18] emgent: Don't use yada. yada is bad. [04:19] I thought it was your favorite? [04:19] StevenK: is in the package, i only applied security patch [04:19] hy cody [04:20] heya emgent :) [04:21] emgent: Since it's yada, I'd suggest skip the maintainer mangling, explain to the security team why you did it, and then let them figure it out if they really care. [04:22] i will do, thanks :) [04:22] LaserJock: don't wind the poor chap up [04:24] Heya ajmitch [04:24] good afternoon [04:24] ajmitch: heh [04:24] Good to seeing you around. I've been missing your smiling face. [04:25] * ajmitch isn't here [04:26] ajmitch: While your not here, is your RC bug tracker by chance running elsewhere too? [04:26] nope [04:27] * ajmitch has no static IP address to serve it from [04:28] is ubuntuwire still down?? [04:28] LaserJock: AFAIK yes. Still no imbrandon [04:28] * ScottK2 has had the flu this week and didn't get around to calling him again. [04:29] * ajmitch hasn't seen imbrandon on irc for a long time [04:29] partly because I don't usually watch irc now [04:29] Well it is nice to see you again even if you aren't here. [04:29] * ajmitch is usually in channel, at least [04:30] just not often talking to people [04:30] * ajmitch would think that the rc bug tracker thing isn't as useful now anyway [04:31] ajmitch is a stalker [04:31] true story, that [04:31] ajmitch: Why not? [04:32] * ajmitch has been mercilessly stalking laserjock, watching his every movement [04:32] ScottK2: because of other lists of bugs that should say similar things [04:34] ajmitch: OK. Maybe I need to go look around for other lists then. Your is the one I always used. [04:35] that 'really fix-it' list would help a bit, if the bug link has been set in launchpad [04:35] ScottK ScottK2 ping [04:35] * ajmitch would need to find somewhere sane to put the rc bugs list [04:35] https://bugs.launchpad.net/gutsy-backports/+bug/202049 [04:35] Launchpad bug 202049 in gutsy-backports "Please backport new MythTV themes from Hardy" [Undecided,New] [04:36] superm1 informed me that you wanted to see those tested seperately [04:37] I'm getting the feeling that Hardy's gonna get release without quite a few good new upstream release and bug fixes [04:37] things are really moving fast at this point [04:37] that's expected [04:37] rhpot1991: Yes. I'd also like to see the depwait for the basic mythtv backport cleared up too. [04:37] yeah, just a bit disappointing [04:37] * ajmitch is going to wander home now, nice talking to you again :) [04:38] cya ajmitch [04:38] ScottK2, sorry i've been busy with some other stuff than to look into the details of why that happened on the non standard arch's [04:38] i'll get to it soon === Frogzoo_ is now known as frogzoo [04:39] ajmitch: See ya. Thanks for stopping in. [04:39] * ScottK2 wonders if he highlights on php? [04:41] ajmitch! [04:41] emgent: then fix the package. [04:42] yep [04:42] first I'd like talk with keescook [04:42] then i will do :P [04:43] (hi Hobbsee) :) [04:43] hiya [04:50] Hobbsee, Would you do me a big fat favour and regenerate and upload xubuntu-meta for me? :) [04:58] ScottK2, it looks like they are sorting themselves out some how [04:59] only lpia is failing now [04:59] and its because of missing libx264-dev [04:59] which is in gutsy multiverse... [04:59] Hobbsee: yes? [04:59] just not on lpia [05:00] Hobbsee: I'll take care of the above xubuntu-meta update [05:00] slangasek, thanks :) [05:02] superm1: OK. Well that's progress. Is libx264-dev actually missing no lpia? [05:02] ScottK2, https://launchpad.net/ubuntu/gutsy/+source/x264/+builds [05:02] it failed to build on lpia [05:02] looking [05:02] on gutsy at least [05:02] worked on hardy though [05:03] ah i see why [05:03] superm1: Why? [05:03] in hardy it has nasm [i386 lpia] as build depends [05:03] slangasek: thanks [05:03] ajmitch: hello [05:03] failed due to missing nasm in gutsy [05:04] on lpia [05:04] superm1: Maybe an SRU then? [05:05] well i guess that really depends on how important mythtv on lpia is to gutsy [05:05] Probably not very. [05:06] But I like to see things complete. [05:06] i gathered as much :) [05:06] It's not such a big deal, but if it's an easy fix it'd be nice. [05:06] superm1: Let me know when you think the plugins are ready to go... [05:07] so i'm not sure the extra effort to right that is worth it. If someone complains that they want their mythtv 0.21 on an lpia gutsy (who has those other than developers for moblin stuff)?, i'll take care of it [05:07] ScottK2, you mean the themes? [05:07] Yeah' [05:07] That [05:07] the themes look fine to me, rhpot1991 has a gutsy box that i asked him to do the backport to his ppa and install to [05:07] none of them failed to build or anything similar [05:07] so i'd say not a worry there [05:08] rhpot1991: Did you finish testing them all? [05:08] * ScottK2 notices the time, remembers he has the flu, and decides to go to bed. [05:08] Good night all. [05:09] ScottK2, yeah as indicated in the bug, they all built and installed [05:09] see ya though [05:10] pm me the bug and I'll look at it tomorrow. [05:11] alrighty [05:11] night [05:14] i am having the following error message: error: could not create '/usr/lib/python2.5/site-packages/blueman': Permission denied [05:16] what am i supposed to do? [05:18] Legendario: what are you *trying* to do? [05:18] building a package? [05:18] yes [05:19] you need to tell the upstream rules to install to a subdirectory of debian/ instead of to the root filesystem [05:19] I don't know what the convention is for python modules; for stuff that uses autoconf, the convention is make DESTDIR=debian/tmp install [05:20] i think it's python setup.py --destdir debian/tmp install [05:20] or something [05:20] i dunno, python project that use setup.py should die :) [05:21] cody-somerville: I can do xubuntu-meta if nobody else has started on it already. [05:21] The convention for python modules depends on what debhelper you're using, pretty much. [05:21] TheMuso, slangasek said he'd do it. [05:21] slangasek, Have you started on xubuntu-meta yet? :) [05:21] oh ok [05:22] cody-somerville: started dput, yes [05:22] TheMuso, Okay. Thanks anyhow :) [05:22] cody-somerville: np [05:22] slangasek, what to do if a package already in gutsy-backports just needs to be rebuilt? Should I file another backport bug, or can you just press a magical dch -i "no changes, just rebuilding"? [05:23] superm1: I don't have any magical buttons for that; I think a sourceful upload on your part is going to be the most straightforward [05:24] slangasek, directly to gutsy-backports, or where to? [05:24] superm1: yes [05:24] slangasek, okay i'll take care of that [05:24] thanks [05:24] superm1: oh, are you in the backporters group? If not you probably should clear it with jdong or ScottK first [05:24] RAOF, what do you mean by the convention for python modules depends on what debhelper you're using? [05:24] slangasek, no i'm not in the backporters group. [05:25] let me do a test build then and put it in a proper bug so that they dont need to think much [05:25] superm1: right :) [05:25] should i edit the setup.py file or a file in the debian folder? [05:26] I thought backports were automatic copies of hardy source packages [05:26] there are sourceful backports as well [05:27] Legendario: normally you should not have to edit setup.py. I think the suggestion Amaranth gave you first looks most promising [05:29] slangsek, sorry. but i didn't understand what to do exactly [05:31] could you please be more specific? [05:34] slangasek [05:36] Legendario: you know that debian/rules is the file that controls how packages are built? [05:36] Legendario: you need to edit that file; either in a straightforward way based on Amaranth's suggestion, or perhaps in a non-obvious way if you're using cdbs [05:38] slangasek, this is a line in my debia/rules: $(MAKE) DESTDIR=$(CURDIR)/debian/blueman install [05:39] is this what i was supposed to do? [05:39] I don't know [05:39] or do i have to add something else? [05:39] you haven't given any context about your package, that I can see [05:39] I can't tell you what's right or not without ever seeing the package in question [05:40] slangasek, well, it is a python software but it has a make file and a setup.py file [05:40] I can tell you that line will pass the DESTDIR variable to the upstream makefile when calling 'make install'. I don't know whether that will do the right thing for this upstream software. [05:44] should i substitue the $(MAKE) DESTDIR=$(CURDIR)/debian/blueman install, for python setup.py --destdir debian/tmp [05:46] ? [05:47] Legendario: What I meant was: where you want the modules to end up depends on whether you're using pysupport or pycentral. [05:50] RAOF, i don't understand a thing about python, so need straighter directions. Does it help? http://paste.ubuntu-nl.org/59562/ [06:01] Legendario: That doesn't have enough context to be very useful. debian/rules would be good, as would be information about what you're actually trying to package and how to build it (can you build it without trying to make a package?) [06:02] ok [06:05] RAOF, i don't think this is going to help much, since it is a normal debian/rules file [06:05] http://paste.ubuntu-nl.org/59564/ [06:11] Legendario: Right, so it's practically a dh-make template. [06:11] Legendario: So, the other question remains. Can you actually build this program without trying to package it? [06:12] If you can't do that, you've got no hope of packaging it :) [06:15] RAOF, i didn't try to build the source. You can take a look on the program site: http://blueman.tuxfamily.org/ [06:16] Legendario: Heh. So, a fundamental part of packaging is to encapsulate the build processes of the thousands of packages we have. If you don't know how to build it, you can't package it :) [06:17] And, that website ( http://blueman.tuxfamily.org/index.php?option=com_content&view=article&id=50&Itemid=60 ) tells me you're building it wrong. [06:19] RAOF, what am i supposed to do? [06:19] Well... "to install run sudo python setup.py install". [06:20] So your debian/rules is going to have to call setup.py at some point :) [06:21] What you actually want to do is to work out what parameters their setup.py takes, what the build actually does (ie: if it builds any arch-dependent code such as shared libraries, you'll probably need to call setup.py once for each python version, etc) [06:36] slangasek, how is the xubuntu-meta upload going? [06:38] cody-somerville: well enough, aside from me forgetting to accept it from the queue [06:38] slangasek, :) [06:39] RAOF, i could do it. thanks RAOF [06:52] could do it. if someone can review it, i would apreciate it: http://revu.tauware.de/details.py?package=blueman [09:13] good morning [09:15] Someone care to remind me of the "right" way to do a diff for a small (like 6-character) change to a source package? Something like diff -rN somesuch I think. [09:17] diff -ruN? [09:17] That's the one. [09:18] rock! :) [09:18] I also need a little bit of versioning advice. [09:19] I'm dealing with nvu --> kompozer, which basically amounts to a renaming as far as our users are concerned, but they have different versioning schemes. The version of nvu in the repos is 1.0-0ubuntu4 and 1.0final-2ubuntu2 for dapper and edgy, respectively, [09:20] while the version of kompozer is 0.7.10-0ubuntu3. I need to make the virtual package 'nvu' provided by the kompozer source package such that any users with nvu installed will be upgraded to kompozer. [09:22] So basically, I a) need some scheme for making virtual packages have a different version than their source package, and b) need a suggestion for a version higher than 1.0 that I can assign it. [09:27] dholbach: any idea how to approach that? [09:27] you'll need to add an epoch [09:28] (1:0.7.10-0ubuntu3) [09:28] do we [09:28] http://www.debian.org/doc/debian-policy/ch-controlfields.html [09:28] readin' [09:28] do we get that package from debian? [09:29] if so we should coordinate the epoch change with debian [09:29] it might permanently prevent us from syncing if our version is higher than the one in debian [09:29] 5.6.12 Version [09:30] dholbach: It does not yet exist in Debian. (I'm hoping to have a chance to start addressing that next week) [09:30] right [09:30] so adding an epoch should be fine [09:30] So I apply the epoch change to the entire source package I take it? [09:31] you add it to the version in your debian/changelog entry [09:31] (do epochs show in things like apt-cache policy?) [09:31] gotcha [09:31] daniel@lovegood:~$ LC_ALL=C apt-cache policy gthumb [09:31] gthumb: [09:31] Installed: 3:2.10.6-0ubuntu1.1 [09:31] Candidate: 3:2.10.6-0ubuntu1.1 [09:31] Version table: [09:31] *** 3:2.10.6-0ubuntu1.1 0 [09:31] ... [09:31] so 1:0.7* > [presumed 0:]1.0* [09:32] yes [09:32] It never ceases to amaze me how many things the dpkg people already thought of. [09:32] daniel@lovegood:~$ dpkg --compare-versions 1:0.7 gt 1.0 && echo true [09:32] true [09:32] daniel@lovegood:~$ [09:32] yeah, that's right :-) [09:33] the shoulders of giants :) [09:33] hehe [09:42] Does a printing JOB run as user? [09:42] If i try to print something i get D [14/Mar/2008:10:33:21 +0100] [Job 35] Error: /usr/Brother/inf/brFAX1940CNrc :cannot open file !! [09:51] dholbach: So do I need to touch _anything_ other than debian/changelog for this? [09:52] do the normal update you intended to do, make all the changes necessary, then add the epoch [09:52] that should be it [09:53] The epoch issue is the only thing I'm addressing today, so yeah. [09:54] dholbach: oh, one thing though - should I bump the ubuntu version, ie 1:0.7.10-0ubuntu4, or leave it as 1:0.7.10-0ubuntu3? [09:56] as it's a new upstream version, I'd say 1:0.7.10-0ubuntu1 [09:57] Oh. I guess that makes sense. [09:58] ROCK [09:59] Paper? [10:01] So something like "diff -ruN kompozer-0.7.10/ sourced_for_diff/kompozer-0.7.10/ > debdiff.txt", and attach debdiff.txt to the bug? [10:05] you can use debdiff old.dsc new.dsc [10:08] And iirc, that's since I only made changes to debian/, but diff -ruN would be needed if there were any changes in the actual source - is that right? [10:08] or same thing both ways? [10:14] you don't need to keep two directories if you run debdiff on the .dsc files [10:15] but you can use diff -ruN too [10:16] gotcha [10:17] All righty, "should" all be set to go at Bug #200349. [10:17] Launchpad bug 200349 in kompozer "Versioning for nvu virtual package wrong" [Undecided,New] https://launchpad.net/bugs/200349 [10:28] tonyyarusso: errrrm [10:28] dholbach: crud, what'd I do wrong? [10:29] ahhhhh, now I understand [10:29] excusez-moi :) [10:29] yay! [10:29] Does that mean I'm not getting ratted out today? :P [10:33] tonyyarusso: uploaded [10:33] dholbach: sweetness - thanks a bunch! [10:33] * tonyyarusso checks off one of the todo items, goes to test the bugs he has "needs info" === cpro1 is now known as cprov [10:44] tonyyarusso: weird... upload was rejected - I'l try again [10:45] dholbach: odd [10:45] any kind of useful message? [10:46] "MD5 sum of uploaded file does not match existing file in archive...." [10:47] tonyyarusso: I'll try ubuntu4 instead and see if that works [10:47] that might be it [10:47] but that'd be weird [10:55] tonyyarusso: seems the right thing to do is the ubuntu4 upload [10:56] dholbach: all righty then. Not quite sure why, but whatever works. [10:56] look at the generated dsc file [10:56] it says: [10:56] Files: [10:56] 42e0d7dddb19a7db5315906ea7c29cbd 806 web optional kompozer_0.7.10-0ubuntu1.dsc [10:56] b387cd9e1328c8c11517cd59d9b2be32 23882 web optional kompozer_0.7.10-0ubuntu1.diff.gz [10:56] tonyyarusso: Colons aren't always safe to use in filenames. [10:56] these files already were accepted by the buildd with different md5sums [10:56] Epochs aren't present in the filenames. [10:57] I see. [11:03] hey dholbach long time no chat [11:04] hey jsgotangco [11:04] jsgotangco: how are you doing? [11:04] not bad just busy lately with all these travels and deadlines [11:05] I can imagine [11:05] * dholbach hugs jsgotangco [11:06] heh === \sh_away is now known as \sh [11:37] Hey [11:39] * Hobbsee waves [11:40] * Hobbsee points at jsgotangco - it's spam! [11:45] lol [11:55] ,prmomg [11:55] ugh...morning [11:56] <\sh> moins zul [12:09] hi folks [12:09] hi [12:09] hi sistpoty|work [12:09] hi Hobbsee === fabo_ is now known as fabo [12:16] Hobbsee, ScottK, TheMuso: bug 201962 for gfortran transition... opinions? [12:16] Launchpad bug 201962 in petsc "gfortran transition" [Undecided,In progress] https://launchpad.net/bugs/201962 === santiago-php is now known as santiago-ve === cody-somerville_ is now known as cody-somerville [12:34] ScottK: all packages in the bug need to be transitioned, but I cannot really remember how many new upstream versions there are (nor did I look out for these too hard). [12:42] sistpoty|work: The gfortran transition is a LOT of work, because it might entail more than just changing the packaging. I've sometimes had to work hard to get a program to compile under gfortran. [12:43] mok0: Debian has done the vast majority already. [12:43] That's where I've got most of the bits that I've done (which was just finishing stuff that doko had started). [12:43] Well, the list on LP is still very long [12:43] mok0: yes, there should be only 2-3 packages not done in debian left [12:43] It was made more difficult by the fact that they all FTBFS due to one of doko's other changes. [12:43] sistpoty|work: so it's mostly merging? [12:44] mok0: I hope mostly syncing :) [12:44] ok... phew [12:44] sistpoty|work, The test builds were successful. [12:44] sistpoty|work: Are there any more than mopac7 and its rdepends (libghemical, so also ghemical) that aren't done in Debian? [12:44] sistpoty|work, ghc6 is ready for upload :) [12:44] cody-somerville: excellent! I'll look in sponsoring ghc6 tonight, once I'm home [12:45] * sistpoty|work looks [12:47] Fujitsu: libextutils-f77-perl w.o. patch, some more with a patch in BTS (5-8, depends on if we want to follow unstable removals as well) [12:49] sistpoty|work: Still, not too bad, and they might have fixed them within a couple of weeks. [12:49] Fujitsu: yes [12:53] jono, ping [12:53] cody-somerville: hey [12:53] cody-somerville: skype? [12:54] jono, Sounds good. [12:54] jono, Just let me do a sound test [12:55] * cody-somerville sighs. [12:55] I get it to work last night and ofcourse it stops working today. One second, a reboot should fix it [13:09] dholbach: around? [13:09] How do you make use of the crash_report that is attached to some bugs? [13:09] hellboy195: yes [13:10] dholbach: I edited the debdiff. And it seems that it's only a newline missing, right? electricsheep [13:11] hellboy195: searching the bug [13:11] dholbach: bug #201417 [13:11] Launchpad bug 201417 in electricsheep "Merge electricsheep 2.6.8-9 from Debian(Unstable)" [Undecided,Confirmed] https://launchpad.net/bugs/201417 [13:12] hellboy195: alright [13:12] dholbach: I added a newline after line 214 and it seems to work [13:13] dholbach: make a new debdiff or will you try at you own? [13:13] I tried it and it seems to work [13:13] dholbach: ok. sry again. I edited the debdiff and removed the useless entries ,... [13:17] hellboy195: uploaded [13:17] dholbach: thank you :) [13:18] brb [13:19] Heya gang [13:20] bddebian: hey [13:20] Hello jpatrick [13:29] <\sh> if anyone is interessted, I uploaded php5-amfext to my ppa.... [13:30] I have an application who gives this message "Can't find xulrunner-xpcom, mozilla-xpcom or firefox-xpcom" [13:30] I can not find a xpcom pakage :( [13:31] firefox-dev or libxul-dev ? [13:32] ahh libxul-dev [13:32] thx a lot [13:32] np, is just a guess [13:33] <\sh> oh hell...I just hacked the best memory profiling tool ever [13:35] <\sh> nixternal: lol...chatting over twitter is even more sick ;) [13:35] hahaha [13:35] it took me a second to realize just who you were :) [13:35] then you said bad old Germany and I knew right away [13:36] <\sh> nixternal: lol... [13:37] <\sh> nixternal: but there is a bed waiting for you ;) [13:37] I have been watching these shows on PBS here where they go through and talk about different countries in Europe..there is a person talking about the different things, but the video is nothing more than high definition flyover from a helicoptor [13:37] Germany, the countryside, is exactly what I invision as my dream location for living [13:37] the countryside of France is beautiful too [13:39] <\sh> nixternal: oh good to know...french frontier is just less then an hour drive from my place ;) actually it's only 2 km to the Rhine and you can see france already ;) [13:40] <\sh> nixternal: if you have a motorized boat, you could be there in less then 10 mins ;) [13:40] I gotta get away from mansions, SUVs, and O'Hare airport :) [13:41] right now, I live 30 minutes outside of the city (Chicago), and when we moved here back in the 80s, it was all country...now it is all part of the city/suburb life and it isn't my cup of tea anymore [13:58] dholbach: I was trying to fix the evolution-scalix package. I have patched the configure.in and configure script and it goes past configuration problem. But it fails in actual compilation. I am not able to figure out what the problem is as I am not very good with C. Do you think you can take it further if you have got time? [14:03] in case someone missed it: "Policy checker linda removed from testing/unstable". See http://permalink.gmane.org/gmane.linux.debian.devel.announce/1187 [14:06] I wonder why. :-) [14:14] maybe because of the previous article: http://permalink.gmane.org/gmane.linux.debian.devel.announce/1186 "Lintian has been under fairly active development for the past couple of years" [14:23] Ok I found the answer in the article itself [14:31] ScottK: ping === G0SUB_ is now known as G0SUB === ogra_cmpc__ is now known as ogra_cmpc === dholbach_ is now known as dholbach === \sh is now known as \sh_away [15:01] ScottK: ping too :) [15:01] geser: I had the chance to test new dietlibc on amd64, it worked fine and I uploaded new revision. I'm going to manage rebuilds soon, please tell me if you want to proceed with bglibs. [15:04] DktrKranz2: good to hear. I'll look at bglibs. [15:06] There are two bugs related to bglibs, 184625 and 163774. They will hopefully be solved. [15:07] happy Âpi day! [15:07] i mean, good morning [15:08] yes, both could be fixed with it [15:08] nxvl: Hi [15:08] geser: :D [15:09] you too a happy π day [15:09] DktrKranz2: dod you take a look at Bug #179790 ? i have merged with other 2 bugs as you requested [15:09] Launchpad bug 179790 in tinyerp-server "postgresql listens on :5432" [Undecided,Confirmed] https://launchpad.net/bugs/179790 [15:10] nxvl: thanks for merging. I haven't had a look at it yet, yesterday I was mostly out, but I'll probably have a look in the weekend after set up VMs again on Sid. === \sh_away is now known as \sh [15:11] nxvl: does the logfile from tinyerp get rotated? [15:14] DktrKranz2: ok, thnx [15:21] geser: dunno, i just apply a patch someone send [15:22] geser: but, that's syslog work [15:22]