=== ScottK2 is now known as ScottK === FourDoll1rs is now known as FourDollars === almaisan-away is now known as al-maisan === SWAT__ is now known as SWAT [07:19] good morning [07:19] hi dholbach [07:20] hi ajmitch [07:24] Morning. [07:27] hi iulian === al-maisan is now known as almaisan-away === dholbach__ is now known as dholbach === almaisan-away is now known as al-maisan [10:50] Hello [11:35] Hi [11:39] hello geser [11:39] hello AnAnt [11:41] can someone sync bug 832692? [11:41] Launchpad bug 832692 in gtk-gnutella (Ubuntu) "FFe: Sync gtk-gnutella 0.97-2 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/832692 [11:42] Hi sladen [11:45] hrw: you don't need a FFe for that as fixing a FTBFS isn't a new feature (FFe is more for new upstream revisions or when a new feature gets added to a package (e.g. enable linking against an additional library to enable a feature)) [11:48] does somebody know if the LP sync button is already in the web UI or only in the API? [11:48] geser: thx [11:50] geser: web ui, but we'd like everyone to use the API [11:50] also, be aware that it won't currently close bugs on upload [11:51] How many hours remain till last-last-last Freeze??? [11:52] hakermania: wiki.ubuntu.com/OneiricReleaseSchedule [11:53] tumbleweed, the exception is till Final Freeze? [11:53] what is that for an error: http://paste.ubuntu.com/673760/ [11:54] tumbleweed: doesn't the web ui use the same LP API call? [11:54] geser: yes [11:54] but I have to use the (updated) syncpackage script and can't push a button on the web ui? [11:55] geser: bug 830584 for some of the issues we have wit hthe web ui [11:55] Launchpad bug 830584 in Launchpad itself "Concerns about the use of +localpackagediffs in Ubuntu" [High,Invalid] https://launchpad.net/bugs/830584 [11:57] * tumbleweed has a quick look at adding sync blacklist support to syncpackage [11:57] jtaylor: that usually happens when there are no files to build the deb from (e.g. when the package uses only build_indep but some packages in debian/control mention they are arch-specific) [11:58] ah ok [11:58] its a i386 and I'm trying to build on amd64 [11:58] Laney: I'm up to 5 caches in 5 days, need to do one today still. :) [11:59] Hello [11:59] AnAnt, hi :P [11:59] tumbleweed: thanks for the bug number [12:00] it would be quite handy to just press a button in the web browser to sponsor a sync request [12:07] geser: yeah. The plan was always to make sponsor-patch handle sync sponsoring too (responsible sponsors test-build :) ) [12:09] Rhonda: still without a gps? [12:10] Geo-caching without a GPS? [12:10] Sorry, the feature freeze exception is till the final freeze? [12:10] yes [12:10] Nice! Much more time :) [12:10] erm, not really [12:11] it gets harder to justify the addition of new stuff as the release comes closer [12:13] Laney, why so? Because of loads of work? [12:14] because we need to be concentrating on fixing bugs and not introducing new things, and as new source packages take up a lot of time (as you are seeing with your reviews) there needs to be a good reason for them. [12:16] Laney, they take a lot of time as for the uploader, not as for the reviewer, I think... See, this is the try of one of the reviewers to build my package. It failed but it took no more than a minute: http://paste.ubuntu.com/669042/ [12:17] right [12:17] so tumbleweed has not spent much time working with you on this package? [12:17] jtalyor too [12:18] Laney, yes ofcourse they have. But that's only because I'm newbie :| [12:18] as a reviewer, I'd argue reviewers probably spend more time reviewing things than some people spend preparing them [12:20] tumbleweed, that's doesn't apply on me actually, being a new coder and packager, is a hard work understanding how things work or should have worked. But thanks to you guys now all are more clear. Also, an experienced packager wouldn't need so much guidance and repeatation. [12:21] Laney: yes, still without gps. [12:21] geser: yep. :) [12:21] :) === al-maisan is now known as almaisan-away [12:21] the one on my phone works well enough [12:22] the one in google maps works well enough [12:22] At least within a city as Vienna [12:22] i find openstreetmap better as it marks more features [12:28] hakermania: of course, just responding to "they take a lot of time as for the uploader, not as for the reviewer, I think..." [12:29] tumbleweed, I'd really one day have as a hoppy fixing bugs :D [12:29] there's a certain amount of general archive maintenance work which kind of mounts up for every extra package in the archive, and packages introduced too late can be problematic there [12:29] love^ [12:29] it's not just review time [12:30] cjwatson, do you refer to the new packages after FF? [12:30] right, it's not just about regressions or bugs in the distribution, it is about the time of people who have to deal with them [12:31] hakermania: I do [12:31] * cjwatson notes that he has spent most of the last week doing very little else but cleaning up after packages people weren't keeping properly up to date in various ways [12:31] Laney: well, google maps is integrated directly in geocaching.com website [12:32] you can get on OSM there too [12:32] "View dynamic map" or similar [12:32] cjwatson: we need to do more to get people to care for transitions they start, certainly [12:32] cjwatson, this is unhappy, does this come from unresponsible uploaders? Uploaders don't care if their packages don't build in new ubuntu versions? [12:34] not all the problems are easy for people to notice, and many of the packages are just synced from Debian and don't have a specific Ubuntu uploader but need to be poked for Ubuntu in some way [12:34] but yes, some of them are just semi-abandoned [12:34] a lot of stuff certainly could have been predicted (libav...) [12:34] yes [12:34] I don't know why that was left for so long; I assume somebody got busys [12:34] *busy [12:36] but anyway, this contributes to more caution about adding extra packages late [12:37] cjwatson, that's one reason why having a package 1stly go through debian and then import it to ubuntu is not a good idea? [12:37] no no no no no [12:37] please do that whenever you can === almaisan-away is now known as al-maisan [12:37] xD [12:37] for the most part it's much less work for us and does more good for more people [12:38] but people do need to keep an eye on health in Ubuntu as well [12:38] I absolutely think people should work through Debian whenever it make sense [12:38] *makes [12:39] cjwatson, So, mainly, the best way is to build a package wherever, test it that it works both on debian and ubuntu, send it to debian and import it to ubuntu :) [12:39] yes :) [12:40] just like fixing a bug in the kernel is better served in linux, and not here in Ubuntu [12:40] the problems I'm working on are not about things that worked at the time they were first built, they're about keeping up to date with library changes and the like [12:40] packages don't tend to exist in glorious isolation with no changes required [12:44] I feel a bit guilty for sending my package to revu now ._. But Ubuntu is so excellent and up-to-date that it *HAS* to have its very-own programs [12:45] hakermania: it's actually not that much more up to date then Debian [12:45] hakermania: you might be thinking of debian stable? Unstable and Testing both have really up to date stuff. It's where we pull from for Ubuntu [12:45] something crazy like upwards of 75% of our packages are direct clones from Debian [12:46] huh, I went to look at the graph but it looks like MoM is borked and didn't generate the entire page [12:46] https://merges.ubuntu.com/universe-now.png [12:46] I don't think you should feel *guilty* about it, but it might be worth considering sending your next one to Debian [12:47] paultag, I downloaded the last version of debian (the one with a space rocket or similar, lol) and when i tried installing there my package it said that multiple dependencies were missing, though the debian system itself was up-to-date [12:47] hakermania: it's rock solid here. The reason Ubuntu's so stable is because Debian is. We have a great relationship with them [12:47] Laney: *cough* looks like I might have left the lock held when I was last working on MoM disk space :-/ [12:47] fixed I hope [12:47] heh [12:48] paultag, I understand [12:48] bdrung, cjwatson: sync blacklist detection for syncpackage proposed [12:48] Rhonda: I placed a cache outside my office window — sometimes I get to watch people looking for it :-) [12:48] (like now) [12:49] hakermania: you can't necessarily take a package built on Ubuntu or on a newer Debian version and install it on Debian stable; this is also true of building a package on oneiric and trying to install it on, say, lulcid [12:49] *lucid [12:49] tumbleweed: do you have the time to add a bug closing feature to the tool? [12:49] it needs to be built for the release in question [12:49] bdrung: working on that next [12:49] bdrung: although I see talk of that happening in LP now [12:50] cjwatson, so how can you test your program in both Debian and Ubuntu? [12:50] wouldn't it be nice if launchpad had a real blacklist feature? [12:50] tumbleweed: at least -b should work (or throw an error) [12:50] hakermania: note that you said that, I diddn't [12:50] hakermania: but building it on the *oldest* usually works; or just build it for both [12:50] building it for both isn't usually necessary unless you depend on fast-moving libraries [12:51] cjwatson, 'you' was general, thanks for the info [12:51] usually testing it on the one you upload to is sufficient [12:56] tumbleweed: is_blacklisted could get a comment [12:56] fair enough [12:58] tumbleweed: login_anonymously is enough for the old sync way [12:58] bdrung: yes, but I don't see the point of that (and the launchpad people really don't seem to like people using anonymous logins) [12:59] they weren't very interested in ubuntu-sponsoring breaking when logged in anonymously [13:00] tumbleweed: but why should syncpackage require the credentials if it is not needed? [13:01] bdrung: no, but I think that'll be a minority use case [13:01] tumbleweed: but not impossible [13:02] bdrung: [13:02] < lifeless> we only really support anonymous API access for folk doing experimentation in browsers etc - thats the primary anonymous use case. [13:03] < tumbleweed> lifeless: I wish that were better documented. I use anonymous API access whenever I can [13:04] hm, okay [14:34] Ubuntu-humour :P https://wiki.ubuntu.com/FinalFreeze [14:35] that sounds like robbie. [14:35] yep, robbie. [14:53] hi all! anyone interested in helping me test my software: tomld? security related stuff. I'm about to release my first stable version soon. I gladly take any opinions or feedback of it. my site: http://log69.com/tomld_en.html [15:01] log69, hi! You can also make a post at ubuntuforums.org about this. [15:08] hakermania: ok === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === _LibertyZero is now known as LibertyZero === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [18:42] Laney, what does this guy says here: bug 824102 ? :( I thought it was till FinalFreeze :'( [18:42] Launchpad bug 824102 in Ubuntu "FFE: Wallch 2.0" [Undecided,Confirmed] https://launchpad.net/bugs/824102 [18:45] hakermania: firstly, it's not a guy. And I don't think the UI Freeze is relevant here. But I also don't think the FFe is valid forever. [18:47] tumbleweed, you said that because it's a woman? Sorry for the slang, but I use 'guy' for everyone :) I knwo FFe is not valid 4ever, it's till September 29th. [18:49] at some point it should be re-evaluate is what I'm saying. I've asked her why she thinks UI freeze applies here [18:50] hakermania: is it ready for another review? or are there still issues? [18:53] tumbleweed, my co-developer just noticed something in the Help Files (Contents) so fixing it and it will be ready [18:59] hakermania: Every single day counts here and thus if you wait till the 29th of September, I'm afraid that it's not gonna get in. You have to be utterly lucky to find an archive admin to review new packages that late in the cycle. [19:00] iulian, I am optimistic enough to believe that the package is fine [19:00] It will be advocateed soon [19:00] The sooner the better. [19:00] iulian, not in bed o.O [19:00] Er? [19:01] iulian, nothing :D [19:01] considering that some of us spent half the last feature freeze looking at it too, I'd be only to glad to see it accepted :) [19:02] (which begs the question of why it took so long. and in future, please try to get new versions in before FF) [19:03] tumbleweed, I know. I was a #%$#&$ (censored) doing so but we are in the last year of school and the most vital for our life, so we didn't have enough time to develop the application prior to FF [19:06] tumbleweed, thanks :D When I told my dad about how helpful and patient some people are answered that that's the reason why this world will always tend to become better even if it seems things go bad [19:06] I dunno if that's true :) [19:07] np. We also didn't put much effort into reviews for you before FF. But that's part of the problem with REVU [19:13] tumbleweed, if you can, please delete the older build tries stored at revu. They don't need to take web space there. [19:13] sorry, I'm not a revu admin. I assume everything is kept purposely. It can be deleted when uploaded to Ubuntu === med_out is now known as medberry [19:46] tumbleweed: if you do review wallch now, don't! We forgot to remove the freeware non-commercial icons from the mime types :(((((((((( [19:46] don't worry, I'm waiting for you to tell me to [19:47] ouf [19:47] glad you don't trust me hehe === hannesw_ is now known as hannesw === 13WAAOXQJ is now known as sum1nil [20:30] morning [20:32] ajmitch, it 23:31 here :P [20:32] it's* [20:32] yes, it'll always be night somewhere in the world :) [20:33] tumbleweed, if we have made a synthesis of 2 files from a public domain should we mention that in copyright? Or the copyright of the file has passed to us as GPL3 now? [20:34] mention it, if you don't document it, you'll forget, and then if anyone asks... [20:35] +1 === almaisan-away is now known as al-maisan [20:50] tumbleweed, I tell you to D [20:50] xD [20:51] hakermania: ok, I'll look in half an hour or so [20:52] tumbleweed, excellent :) [20:53] hello there, can somebody please shed light on the "install_egg_info" action/target, I am seeing this while building a source package in pbuilder: http://pastebin.ubuntu.com/674131/ [20:54] it's a python package FWIW [21:01] al-maisan: it's metadata used by distribute / setuptools / pkg-resources [21:01] Is there a way to turn this off? Or should I leave it alone? [21:01] leave it be [21:02] ok, thanks tumbleweed ! === paul__ is now known as Elbrus === al-maisan is now known as almaisan-away [22:01] I shouldn't have approved that ffe until the package was closer to being ready [22:01] it's not an open ended "now you can take as long as you want" ticket [22:03] Laney: this is how we learn :) [22:04] Laney: I'll have to file a FFe for you to approve & then leave it until a day before release, shall I? :) [22:05] Laney: oh, I'd appreciate it i fyou could play with/review my syncpackage merges [22:05] tumbleweed: tomorrow [22:06] tumbleweed: i have to write in my diary and then go to bed [22:06] bdrung: thanks [22:06] tumbleweed: ups, you asked Laney - i was highlighted due to the keyword syncpackage :) [22:07] bdrung: heh [22:07] tumbleweed: after a quick look. test cases! test cases! test cases! [22:07] heh [22:07] does syncpackage work in new & interesting ways now? [22:07] yeah, that's why it needs some manual testing [22:07] ajmitch: native package sync [22:07] ajmitch: especially interesting ways ;) [22:08] bdrung: really I wish I could, but that's a *massive* job [22:08] right, I saw mention of that on irc, wasn't sure if it was in production LP yet [22:08] tumbleweed: i know, but someone needs to start. otherwise the quality won't improve [22:09] at least most of the testing should have been done on the server side :) [22:09] ajmitch: it will be announced once the new syncpackage is released (and hopefully after some blocker bugs are fixed) [22:09] bdrung: right [22:09] ajmitch: well, we found a whole buch of issues when we started trying to use it... [22:10] tumbleweed: that's the nature of it [22:11] yeah [22:11] it'll be good to lessen the load on archive admins, even if it was relatively straightforward [22:12] right, which is why we want a client interface that works nicely [22:14] * tumbleweed promised quick turnaround on that dh_python2 ffe /me better look at it [22:15] that reminds me, I think I have one ffe I need to file for that [22:16] tumbleweed, translations are Ok, seriously [22:17] hakermania: ohreally? http://paste.ubuntu.com/674171/ [22:18] tumbleweed, see ./usr/share/wallch/translations/ ? [22:18] Files are in there [22:19] I just create the .qm files, move them to data/to_usr_share/wallch/translations and copy recursively this folder to $PREFIX [22:20] hakermania: if they were there, they'd be listed. They aren't. [22:20] i'll test it again :/ [22:22] tumbleweed: http://i.imgur.com/JZlmc.png [22:22] See the md5sum [22:23] hakermania: the md5sum will be different every time you build it. run debc, and you'll also see they aren't there [22:24] tumbleweed, watch seriously the screenshot, the /usr/share/wallch doesn't exit ('ls' says it) and wallch binary isn't there ('which' says it), I run dpkg -i *.deb and then I ls /usr/share/wallch/translations and files are there [22:25] All these plus the md5sum are in the screenshot [22:25] And the md5sum of the DEB with the one I uploaded to revu are *exactly* the same [22:26] hakermania: it's not about the deb you upload, it's about what deb gets produced when *I* (or anyone else) builds it [22:26] why should be different? [22:26] especially as only source packages are uploaded to ubuntu, so what counts is the binary package that the buildds produce [22:26] it shouldn't [22:26] tumbleweed, why it IS? [22:27] hakermania: have you run debc on the deb you built. Are the translations there? [22:28] tumbleweed, it says it can't read the .changes file [22:28] point it at the _i386.changes file [22:28] oh [22:29] tumbleweed, yes, they are http://i.imgur.com/6H0WO.png [22:29] why is the man page in section 2? [22:29] hrm, interesting [22:29] tumbleweed, yes, indeed :D [22:30] possibly a missing build-dependency for building translations [22:30] cjwatson, are you talking to me? [22:30] yes [22:31] cjwatson, lintian told me that it should be there (it is wallch 2.0 no 1.0) [22:31] you misread it [22:31] :| [22:31] the version number of the software is irrelevant [22:31] section 2 is for system calls - the interface between the kernel and userspace [22:31] cjwatson, omg :) [22:31] manual pages for ordinary user programs belong in section 1 [22:32] cjwatson, well, I will fix this ;) [22:32] thanks [22:32] lintian was probably identifying some other real problem, but without seeing the exact warning it gave you it's hard to say exactly what [22:39] hakermania: it was actually due to the --parallel. Your changes to the qm file installation aren't parallel-make-safe [22:40] tumbleweed, Yeah, i can understand why. [22:41] They are built and then moved to $prefix/share/wallch/translations, if this isn't done with the right order nothing will be moved [22:41] right, and make doesn't guarantee the order rules will be run in [22:41] So, should I just remove the parallel? [22:41] I'd fix the makefile :) [22:42] tumbleweed, hm, a clever thought would be to make the same rule building and moving the files, I'll try this, but I won't be able to test if it will work or not :/ I may still work for me but not for you [22:42] How could I test it? [22:43] It* [22:43] dependencies are the usual way to force things in the correct order [22:44] also data/mime contain a wallch.xml file which is ours, so I will prefer the data/mime/x/* format [22:44] I find it hard to believe that --parallel gains you any significant amount of build time [22:44] cjwatson, sorry but i don't get you. The only thing i know about dependencies are the build ones and the normal ones :/ [22:44] in this case install_helpfiles_and_translations builds the translations, install_configfiles installs them [22:44] it really should just be tidied [22:45] Yeah, I see [22:45] the concept is explained in make's documentation, although I haven't looked at your build system in any detail [22:45] cjwatson: yeah I askedb for that because I'd built it a few times, and it's nice to have something build almost 8 times as fast... [22:45] ccache :) [22:45] * tumbleweed hasn't set that up in my sbuild [22:49] tumbleweed, yes, it should be tidied but I assumed that while I INSTALLS 1stly the one and then the other the job will be done correctly [22:50] tumbleweed, about the synthesized image, i'd like to completely remove the info from the copyright, we are the holders and this goes to * [22:50] Files: *^ [22:51] hakermania: fine, I don't care that much (I've made you review the copyright on the images, that was the most important thing) [22:51] if install_configfiles depends on things from install_helpfiles_and_translations, it should depend on install_helpfiles_and_translations [22:52] really I think you should separate the translations and helpfiles (tehy got to separate places) and remove configfiles (you don't have any) [22:55] tumbleweed, I thought separating the helpfiles from translations, removing completely translations and making unix:configfiles.extra and there making the translation binaries [22:56] it's all in one, they are moved by configfiles and build from configfiles, i'm just saying [22:57] If the unix commands are run firstly and then it installs the target to path, problem solved. One moment to test it :D [22:57] oh also when chaining commands together you should probably use && rather than ; [22:57] hm [22:57] ok, thanks [22:57] otherwise if one of the ones in the middle fails, you'll never know [23:07] yeah, it is as I said [23:10] cjwatson: I don't think that I didn't understood correctly, the error is: W: wallch: manpage-section-mismatch /usr/share/man/man1/wallch.1.gz:1 1 != 2 [23:10] ohhh [23:10] just change the 1.gz to 2.gz? [23:11] no absolute not [23:11] *absolutely [23:11] it says that because the .TH field in your manual page says 2. change it to 1 [23:11] if you run the output from lintian through the lintian-info program, it will give you more information [23:11] http://lintian.debian.org/tags/manpage-section-mismatch.html [23:14] cjwatson, I am curious to know why the error was gone when I moved it to man2 [23:15] because then the file name and the .TH header matched - that's all that check tests [23:15] that doesn't mean that the admittedly consistent state you ended up in was correct [23:15] cjwatson, thx :) === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [23:24] Of :) there's a new upload... enough for today I think, goodnight it's almost hald past too and I miss my bed :P thanks guys again for all the help :) === medberry is now known as med_out === yofel_ is now known as yofel