| Rcart | I've been working in this bug 710132, forwarded the patch to Debian using submittodebian: http://bugs.debian.org/614311 | 00:26 |
|---|---|---|
| ubottu | Launchpad bug 710132 in nted (Ubuntu) "NtEd in menu is without caption" [Undecided,New] https://launchpad.net/bugs/710132 | 00:26 |
| Rcart | I'd like if it's better to wait Debian response, or include a branch in the LP bug report | 00:27 |
| Rcart | *to know | 00:27 |
| micahg | what's the proper way to handle fgets failures? | 00:37 |
| arand | using dh7, I have a gzipped file in my source which will need to gunzipped into the same location at some point, how would I do that? | 00:53 |
| c2tarun | Can anyoone please tell me what exactly is a gold-linker? I have a page on DSOLinking, on that page gold linker is used many times, but never explained. | 01:48 |
| c2tarun | !gold-linker | 01:49 |
| alucardni | hello everyone, I've been working on LP bug #682461, I found that parts of patch 00-debian.patch are in upstream code and patch doesn't apply cleanly. | 01:51 |
| ubottu | Launchpad bug 682461 in logjam (Ubuntu) "Version upgrade available, please update in repo" [Wishlist,Triaged] https://launchpad.net/bugs/682461 | 01:51 |
| RAOF | c2tarun: It's binutils-gold, the new linker. We've got that in our toolchain, so you need to care about what DSOLinking says ;) | 01:52 |
| c2tarun | RAOF: sorry to ask this, but what is a linker? | 01:53 |
| RAOF | c2tarun: Two parts - the bit which takes all the compiled object files and *links* them together into a binary (by resolving references to functions, etc). | 01:53 |
| alucardni | should I manually edit the patch to fix it? | 01:53 |
| RAOF | And the run-time linker, which resolves references to functions in shared libraries and other stuff. | 01:54 |
| c2tarun | alucardni: why you need to edit the patch manually? apply the patch, do the changes and remove the patch, all changes will be stored in it. | 01:55 |
| c2tarun | alucardni: and if the changes are applied than check whether full patch is applied properly or not, if it is applied completely than drop it. | 01:57 |
| alucardni | c2tarun: I have identified the parts of the patch that are in upstream code | 01:58 |
| c2tarun | alucardni: And assign the bug to yourself first and set its status in progress, while working on it. | 01:58 |
| alucardni | c2tarun: ok, thanks for the hints. | 01:58 |
| c2tarun | alucardni: are you sure that only certain parts are applied and not the full patch? Let me have a look | 01:58 |
| alucardni | c2tarun: yes I'm sure. | 01:59 |
| alucardni | the other two patches in debian/patches/series are applied in upstream code, but only parts of the first patch are in upstream | 02:00 |
| c2tarun | alucardni: hmm... did you pop all patches first before checking on them? | 02:02 |
| alucardni | c2tarun: yes | 02:04 |
| c2tarun | alucardni: which part of the patch is not applied, because I found that whole patch is not applied. | 02:05 |
| alucardni | c2tarun: the changes in src/music.h and src/music.h and the changes in Makefile.in | 02:06 |
| c2tarun | alucardni: yup that part is also not applied, just check that MUSIC_SOURCE_XMMS line is still in the music.h file and other lines to be added are not. | 02:08 |
| c2tarun | alucardni: try to run "quilt pop -a" first | 02:08 |
| alucardni | c2tarun: ok | 02:08 |
| c2tarun | alucardni: If possible go through this page once, its small and really good explanation http://wiki.debian.org/UsingQuilt | 02:10 |
| alucardni | c2tarun: I still got this http://pastebin.ubuntu.com/569889/ | 02:12 |
| alucardni | after quilt pop -a | 02:12 |
| c2tarun | alucardni: what message did you get after runnin quilt pop -a? | 02:13 |
| c2tarun | s/runnin/running | 02:13 |
| alucardni | c2tarun: my system is in spanish, so I got 'No se eliminarion parches', something like No patches deleted | 02:15 |
| c2tarun | alucardni: hmm... something went wrong, because when I executed quilt pop -a it removed patches one by one from the stack, I think you should pull the fresh source and start again. | 02:18 |
| alucardni | c2tarun: I was thinking to do that | 02:19 |
| alucardni | I'll start all over again and see what happend | 02:19 |
| alucardni | thanks again c2tarun | 02:19 |
| c2tarun | alucardni: np :) | 02:19 |
| alucardni | c2tarun: by the way, this is my first time upgrading (or should I say trying to upgrade) a package | 02:21 |
| c2tarun | alucardni: I am also new, upgraded only three or four packages :) | 02:21 |
| alucardni | c2tarun: I forgot to tell that I grabbed the new upstream tarball using uscan. How did get the upstream tarball? | 02:38 |
| c2tarun | alucardni: oh,,, I didn't noticed the version. sorry wait | 02:41 |
| c2tarun | alucardni: I can see that the source file is changed and so patch is failing. In this case I think you should drop that patch. But wait for someone more experienced to reply. | 02:44 |
| c2tarun | RAOF: ping | 02:44 |
| RAOF | Yah? | 02:44 |
| c2tarun | can you please look at alucardni problem, the patch is failing because the source file is changed. Should we drop the patch? | 02:45 |
| c2tarun | RAOF: ^^ | 02:45 |
| RAOF | No, you want to update the patch for the new upstream version. | 02:47 |
| RAOF | That means you want to work out what the patch was doing, “quilt push -f” the patch, fix up the rejects, then “quilt refresh” | 02:47 |
| c2tarun | RAOF: how to edit a patch? | 02:48 |
| alucardni | RAOF: some parts of the patch are in upstream already | 02:49 |
| RAOF | You edit the files the patch was patching. | 02:49 |
| RAOF | alucardni: Then you don't have to do anything for those files, but you need to update the rest. | 02:49 |
| alucardni | RAOF: got it, thank you | 02:50 |
| c2tarun | actually the lines that the patch will change is shifted below some new lines added, and that's why patch is failing | 02:50 |
| micahg | for fgets failures, can I just close the resource? | 03:53 |
| jmarsden | micahg: I think that depends on what the code does after that, and how critical the file being fgets-ed is to continuing operation, doesn't it? | 04:02 |
| micahg | jmarsden: yeah, there is a piece later in that loop that closes the source on another condition, I guess there's no right answer here, thanks | 04:04 |
| jmarsden | micahg: You're welcome. | 04:04 |
| dholbach | good morning | 07:11 |
| seiuno | good morning | 07:20 |
| micahg | dholbach: BTW, do you have time to fix merges.ubuntu.com? | 07:54 |
| dholbach | no | 07:55 |
| dholbach | and I don't have access to it I think | 07:55 |
| dholbach | sorry | 07:55 |
| micahg | ok | 07:55 |
| * micahg is noticing a lot of orphaned packages from Debian that have not been removed in Ubuntu | 08:44 | |
| Rhonda | If they are orphaned but still in Debian, why should they get removed from Ubuntu? | 08:47 |
| Rhonda | Some orphaned packages in Debian receive outstanding attention by QA team members. :) | 08:48 |
| Rhonda | … unless by writing "orphaned" you actually really mean "removed" | 08:48 |
| micahg | Rhonda: oops, meant orphaned and remvoed | 08:50 |
| Rhonda | Those are two different things. | 08:51 |
| micahg | yes, sorry for the confusion | 08:51 |
| Rhonda | Either it's orphaned, or it's removed. It can't be both. :) | 08:51 |
| micahg | removed because of orphanage? | 08:51 |
| Rhonda | The reason for removal doesn't matter. ;) | 08:52 |
| Rhonda | orphaned is a state of a package, removed is a different state of a package. | 08:53 |
| Rhonda | orphaned means the package is still included and looked after by the QA team (which could be seen similar to MOTU) | 08:53 |
| micahg | Rhonda: right, but stuff that actually is removed doesn't seem to be necessarily removed from Ubuntu which in most cases, leaves us with out of date software that no one wants to maintain, I wonder if there should be a page on ubuntuwire listing packages recently removed from Debian | 08:58 |
| geser | micahg: not directly what you are looking for but there is http://qa.ubuntuwire.com/multidistrotools/all.html#notinA | 09:04 |
| persia | micahg: Anything we've ever touched never gets autoremoved, which is likely what affects that. That said, inspect *why* things were removed: lots of useful stuff gets removed because nobody cares (and it ought to have been orphaned). | 09:05 |
| persia | Given the ~1000 packages in Ubuntu that aren't maintained in Debian (and haven't been uploaded to Ubuntu in years) Debian removals is not a significant source of stale packages. | 09:06 |
| micahg | geser: that's perfect, thanks | 09:08 |
| micahg | persia: I'm referring to stuff we haven't touched | 09:08 |
| * micahg now at least has a nice resource to try to clean up removed from Debian that no one in Ubuntu cares about packages | 09:09 | |
| persia | Don't be too aggressive. Like I said before, there's *lots* of packages we don't care about that aren't in Debian: unless you have some other source of motivation, it's likely better to apply the same criteria to both sets (although there is richer information available on those removed from Debian) | 09:10 |
| micahg | persia: oh, I was just cleaning up upgrade requests and found packages long ago orphaned | 09:10 |
| persia | If there's an upgrade request for a long-ago-orphaned (or even long-ago removed) package, I think that's an argument against removal: someone clearly wants it. | 09:11 |
| persia | Extra points for becoming the Debian maintainer and all that, but still. | 09:12 |
| micahg | persia: yes, but without someone to maintain it, it's an extra burden on the already stretched thin MOTUs, I encourage people in the bug to offer to maintain the package in either distro | 09:12 |
| persia | I understand what you are saying. What I don't understand is how this differs from the thousand packages never in Debian that nobody updates. | 09:13 |
| micahg | persia: doesn't really, you're right, both sets should be looked at | 09:14 |
| persia | My position is that if it has a user active enough to file an upgrade request, we, as MOTU, ought be willing to give it the same care we give to all the other underloved packages because we're making at least one user happy. | 09:14 |
| persia | That doesn't mean we should upgrade it, but removing something as "unmaintained" from the domain of MOTU just because it has an active user seems to send the wrong signal. | 09:15 |
| micahg | well, in one case, last upstream release is 5 yrs old, in the other is was 2 yrs old | 09:16 |
| persia | So? Does it work? | 09:17 |
| persia | We have lots of packages that haven't had an update since warty. Last time I went hunting in them to find an excuse to update them, most of the ones I checked worked fine: there was no reason to reupload (and no open bugs, for Ubuntu or Debian) | 09:17 |
| persia | Plus, if there's an *upgrade* request, there's probably some value in the new upstream (even if it's taken us 5 years to get to it). | 09:19 |
| Rhonda | Hmm, shouldn't be too hard to do that. Actually I have done something similar for backports, see here: http://backports.debian.org/lenny-backports/NA/ | 09:19 |
| micahg | so, it shouldn't be removed if it was removed from Debian if it still works? | 09:19 |
| persia | Rather, I don't believe we should make a special effort to remove stuff just because it's not in Debian. | 09:19 |
| Rhonda | persia: Well … Packages often get removed from Debian not because noone is caring for it anymore but mostly because upstream is dead. | 09:19 |
| persia | I don't object to the autoremover, although sometimes I grumble, and I sometimes reupload things that were removed if I liked them. | 09:20 |
| Rhonda | persia: I think it's not within the powers of MOTU to play upstream for all the outdated and unmaintained (upstreamwise) packages out there. | 09:20 |
| micahg | well, one failed the archive rebuild a couple months back, one didn't | 09:20 |
| persia | Rhonda: I agree, but I set my criteria based on it being RCbuggy, not simply on nobody being home. | 09:20 |
| persia | If it's not significantly more trouble to keep it in, may as well. If there are hard bugs, etc. then by all means, lets drop it. | 09:21 |
| persia | (and in those cases, I usually try to drop it from Debian, if it's not dropped there already) | 09:21 |
| micahg | the other package uses qt3 which will be dropped from Debian soon anyways | 09:25 |
| persia | Failing rebuild is worth a quick look: if it's one of the N trivial FTBFS cases, just fix it. | 09:26 |
| Rhonda | persia: Actually packages do get removed from Debian _because_ they are RC buggy, not because someone is funny. | 09:27 |
| persia | Porting from qt3 to qt4 requires someone with real dedication: it's not completely outside the scope of MOTU, but someone that dedicated may do well to help revive upstream. | 09:27 |
| Rhonda | persia: Just because those RCs aren't forwarded to launchpad doesn't mean they aren't there. But if you prefer I could setup some tracking job that does forward such bugs to launchpad to ease the decision for you, if that's needed … | 09:27 |
| persia | Rhonda: I've seen RoM cases where it isn't, but yes, most of the time. | 09:28 |
| * persia tends to check BTS bugs anyway, and hopes most MOTU do | 09:28 | |
| micahg | the one I filed was: RoQA; orphaned, outdated, unused | 09:28 |
| Rhonda | Hopefully more after my developer week IRC session. ;) | 09:28 |
| persia | micahg: See, my issue with those is that they don't show it needs anyone to care. I don't believe we can judge "unused" | 09:29 |
| micahg | persia: ok, hmm, maybe I'm too hasty to remove stuff, I'll temporarily mark the removal requests invalid to see if the packages can be saved, but my problem with that is, that takes time away from stuff that we definitely would like to keep in the archive (including the ~700 archive rebuild failures) | 09:34 |
| persia | Whose time does it take? | 09:34 |
| Rhonda | rather incomplete? | 09:34 |
| micahg | anyone who wants to contribute in general, but not specifically interested | 09:34 |
| persia | I hold my beliefs. I don't require you to hold them. I'm perfectly happy if you ignore all those. | 09:34 |
| mok0 | I am looking for documentation on application icons. I notice that many packages place icons in /usr/share/icons/hicolor/... and /usr/share/pixmaps | 10:13 |
| persia | mok0: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html | 10:14 |
| persia | No, that's not it. | 10:15 |
| persia | http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html | 10:15 |
| persia | hicolor is from XDG_DATA_DIRS, and pixmaps is the constant fallback | 10:15 |
| mok0 | hi persia, thanks. | 10:18 |
| mok0 | persia: are the icons scaled on the fly by the apps that need them? | 10:21 |
| mok0 | persia: there seems to be no consensus on what image dimensions are supplied | 10:21 |
| persia | Sometimes | 10:21 |
| persia | So, if you provide an SVG, it's always scaled. | 10:22 |
| mok0 | I see 64x64, 48x48, 32x32, ... etc | 10:22 |
| persia | If you provide other formats, I believe it looks for best-fit, then scalable, then bad-fit (and scales). | 10:22 |
| persia | Depends on the implementation of course, so the different DEs may well do it differently. | 10:22 |
| c_korn | how can I set the working directory of an application? problem: data files are under /usr/share/2ManDVD and executable is under /usr/lib/2ManDVD. now there is a symbolic link in /usr/share/2ManDVD to the executable. if I call it from there the executable does not find its resources because it says the working directory is /usr/lib/2ManDVD | 13:19 |
| mok0 | c_korn: specify full path to resources? | 13:24 |
| mok0 | c_korn: otherwise, there's a system call "chdir" | 13:26 |
| c_korn | mok0: the (qt) app uses qApp->applicationDirPath() to determine its directory. and this returns the directory where the executable is and not where it is started from. | 13:33 |
| mok0 | c_korn: aren't you saying that it uses the wrong path? | 13:35 |
| c_korn | yes, it uses /usr/lib/2ManDVD which in my eyes is wrong because the executable is started from /usr/share/2ManDVD and therefore this should be its working directory or am I wrong ? | 13:37 |
| mok0 | c_korn: why do you want to start the program from /usr/share? | 13:37 |
| mok0 | c_korn: sounds like it's a plugin or helper program | 13:37 |
| c_korn | because there are its resource files | 13:38 |
| mok0 | c_korn: why can't you specify the full path to the resources? | 13:38 |
| c_korn | and the app expects them to be in the same directory. but as policy forbids to place executables under /usr/share I installed it into /usr/lib and created the link | 13:39 |
| mok0 | c_korn, sounds like program author is not doing things right | 13:40 |
| c_korn | yes, I thought there would be a "sh" or "bash" way to tell an application its working directory | 13:41 |
| c_korn | but seems like I had to patch the code here. | 13:41 |
| mok0 | c_korn: you mean like creating a wrapper` | 13:44 |
| mok0 | ? | 13:44 |
| mok0 | c_korn: I'd patch the code to an absolute path | 13:44 |
| c_korn | yes, like cd/usr/share/2ManDVD ; ./2ManDVD $@ <-- the executable here being a link to /usr/lib/… | 13:45 |
| c_korn | mok0: ok, I will try the chdir command you suggested and inform the author about the problem. | 13:45 |
| mok0 | c_korn: don't make that link, just place the app where is should be (usr/lib) and patch the code so it can find its resources in /usr/share | 13:45 |
| c_korn | you mean the app should be in /usr/bin directly ? | 13:46 |
| mok0 | c_korn: if it's a user-called program, then yes | 13:47 |
| mok0 | c_korn: if it's an executable only meant to be called by another app, then it should go in /usr/lib | 13:47 |
| c_korn | mok0: ok, thanks. | 13:48 |
| === dholbach_ is now known as dholbach | ||
| acarpine | I'm editing a changelog file with dch and I don't understand why I put "maverick" on distribution. | 15:18 |
| acarpine | I believed the default choice is the development release... | 15:18 |
| persia | Which release are you running? | 15:19 |
| acarpine | maverick | 15:19 |
| c2tarun | Can anyone please tell me some simple ftbfs bugs to start with I am new to it. | 15:19 |
| persia | Yeah, I thought that was changed to natty just at the end. | 15:19 |
| acarpine | ok, so I put natty. | 15:20 |
| acarpine | But, in general, how I know the name of the release where I have to upload my package? | 15:21 |
| acarpine | just the last? | 15:21 |
| acarpine | c2tarun: You could look at http://qa.ubuntuwire.org/ftbfs/ | 15:23 |
| acarpine | c2tarun: and searching for smthing simple | 15:24 |
| c2tarun | acarpine: there are lot :( can you suggest one? | 15:25 |
| persia | c2tarun: My recommendation would be to start looking through them until you find something that seems to make sense. Then replicate it locally, and try to fix it. | 15:26 |
| acarpine | c2tarun: I would...but I have the same problem :) I knew that solve ftbfs should be easy but many times it's not so easy for me. | 15:28 |
| c2tarun | acarpine, persia: can you suggest me anything like any manual or something that I should read before solving such bugs? | 15:29 |
| persia | I'd actually recommend not reading anything first: there are just too many options. Once you find a specific problem, that should give you some indication as to what documentation to read. | 15:30 |
| acarpine | c2tarun: I perfectly understand your situation... Start seems so difficult | 15:31 |
| c2tarun | ok, I just looked at a package named gamgi, in debian the version present is 0.15.1-1 and when I looked at the changelog this is the first entry I got http://paste.ubuntu.com/570085/ how can some merge a version from debian when it is not in debian? | 15:32 |
| acarpine | c2tarun: there is a proposal of write a guide about this topic for help people to solve this type of problems https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/718640 | 15:33 |
| ubottu | Ubuntu bug 718640 in Ubuntu Packaging Guide "Guide to fix FTBFS bugs" [Undecided,New] | 15:33 |
| c2tarun | second entry of changelog show that there is a release for debian as well, but I can't find that with rmadison | 15:33 |
| acarpine | c2tarun: you could just write a comment with your opinion | 15:34 |
| persia | c2tarun: Check rmadison again: notice the presence of 0.15-4 and 0.15.1-1. These are both newer than 0.15-3, so 0.15-3 was probably removed from unstable (as superceded) | 15:36 |
| c2tarun | persia: ohhh ya. I didn't noticed that. ok the prob is that the package failed to build on i386. how should I change the changelog entries? because I tried to build the source package and it got signed by someone else signature | 15:38 |
| persia | If you're working locally, I recommend appending "-us -uc" to all calls to debuild and dpkg-buildpackage. | 15:38 |
| c2tarun | persia: can you please help me with this error? http://paste.ubuntu.com/570115/ | 16:39 |
| maxb | I would suggest that means something is wrong in the debian/rules file. Investigate, or pastebin it if you need help | 16:44 |
| c2tarun | maxb: http://paste.ubuntu.com/570134/ this is the rules file | 16:48 |
| Bachstelze | c2tarun: there should be a file named "override_dh_auto_configure", but it is not present | 16:49 |
| maxb | Bachstelze: no, why do you say that? | 16:49 |
| Bachstelze | so line 16 of debian/rules fails | 16:49 |
| Bachstelze | maxb: because that's what the logs say? | 16:49 |
| Bachstelze | well | 16:50 |
| Bachstelze | maybe the file shouldn't really be there, but debian/rules expects it to be | 16:50 |
| maxb | c2tarun: The override_dh_auto_configure rule expresses a dependency on src/make_local, but no rules define how to make src/make_local. The debian/rules file has been written by someone with insufficient knowledge of how make works | 16:50 |
| c2tarun | maxb: So what do you suggest for fixing this bug? I mean I have not much knowledge about rules file by myself | 16:52 |
| maxb | The rules file needs to be fixed by someone who has adequate skills in make | 16:52 |
| c2tarun | maxb: how can i learn more about rules file,like how to create them? | 16:53 |
| maxb | the entire override_dh_auto_configure: block as it stands is pretty broken right now | 16:53 |
| persia | c2tarun: http://www.gnu.org/software/make/manual/make.html is worth reading anyway: this is an excellent time because you can use the knowledge gained immediately | 16:54 |
| c2tarun | persia: thanks :) I'll read it and try to come back this bug as soon as possible. | 16:54 |
| Bachstelze | maxb: you are wrong, src/make-local need not be a rule, it can also be a file | 17:01 |
| Bachstelze | and I presume that's what it is | 17:01 |
| maxb | Bachstelze: Undoubtably it is a file, but it is missing a rule to define how to remake it | 17:02 |
| Bachstelze | right | 17:03 |
| Bachstelze | that's not what causes the FTBFS, though | 17:03 |
| persia | Not every file needs a rule to make it: some may be assumed. | 17:04 |
| maxb | A more pressing concern is using $@ where $< is apparently intended | 17:04 |
| * Bachstelze nods | 17:04 | |
| maxb | Though I'm fairly sure that making a pseudotarget like override_dh_anything depend on a file doesn't make much sense anyway | 17:06 |
| maxb | You already want such a pseudotarget to execute whenever it is invoked, so what purpose does a dependency serve? | 17:06 |
| Bachstelze | none, but that's up to the debian maintainer to fix IMO | 17:07 |
| Laney | that was fixed in Debian already | 17:11 |
| Laney | I would be inclined to merge the new version | 17:12 |
| === yofel_ is now known as yofel | ||
| === didrocks1 is now known as didrocks | ||
| arand | should a game binary be installed in /usr/games or /usr/bin | 17:47 |
| debfx | arand: /usr/games | 17:48 |
| ari-tczew | hggdh: around? | 17:52 |
| hggdh | ari-tczew: yes | 17:52 |
| ari-tczew | hggdh: please run update-maintainer on your ncmpcpp branch | 17:53 |
| Laney | usually for that kind of trivial change I'll just do it and tell the contributor when uploading. | 17:53 |
| ari-tczew | Laney: That's right, but it's a bzr branch and if I'd set Approve on branch without updated Maintainer field, it'd bad. | 17:54 |
| Laney | you can merge it and do another commit | 17:54 |
| hggdh | ari-tczew: will do | 17:54 |
| ari-tczew | Laney: It can't go as merged bzr since it's a SRU and there's no branch lucid-proposed. | 17:55 |
| hggdh | Laney: in this case ari-tczew is pretty much raising up what I misswed, and should not miss again | 17:55 |
| Laney | hggdh: I understand. But I'm just saying that I would usually avoid the round-trip and just tell you what I did so that you know for the next time. | 17:55 |
| hggdh | Laney: oh, OK | 17:56 |
| Laney | btw if you have DEBEMAIL set to an @ubuntu address then you'll get an error when building the source package if you forget to run it | 17:56 |
| hggdh | ari-tczew: updated, and pushed | 17:57 |
| ari-tczew | Laney: (not in this case) Student usually has to fix issues themselve, then he knows which was wrong and how to avoid it next time. | 17:57 |
| hggdh | hum. will check. This is a new machine, and I had to rebuild a lot of my working env | 17:57 |
| ari-tczew | Laney: why are you not yet added to DMB team on LP? | 18:02 |
| Laney | don't know. ask persia. | 18:02 |
| persia | Because I suck. | 18:03 |
| persia | It's absolutely the next thing on my list. | 18:03 |
| alucardni | guys it's ok to add Build Depends when updating a package? | 18:07 |
| persia | alucardni: If they are required, certainly | 18:07 |
| alucardni | persia: without them, the updated package did not build in pbuilder | 18:08 |
| ari-tczew | bdrung: could you help in reduce sponsors queue before 24th? | 18:13 |
| ari-tczew | hggdh: and last issue: 1) Please use revision: (0.4.1-1ubuntu0.1) lucid-proposed; | 18:15 |
| ari-tczew | hggdh: you used -updates, I asked for -proposed | 18:15 |
| === Quintasan_ is now known as Quintasan | ||
| hggdh | ari-tczew: done, thank you and sorry | 18:42 |
| ari-tczew | hggdh: n | 18:42 |
| ari-tczew | np | 18:42 |
| jploz | Hello, what is the current status of the sponsor queue? | 19:22 |
| ari-tczew | jploz: http://reports.qa.ubuntu.com/reports/sponsoring/index.html | 19:23 |
| jploz | ari-tczew: yes, that is the current queue. I wonder what is the state of current activity regarding the queue? Does anybody process sponsor requests, currently? | 19:25 |
| ari-tczew | jploz: if someone has got time, yes | 19:26 |
| ari-tczew | jploz: if you really want something get into natty as soon as possible, ask here on #ubuntu-devel | 19:26 |
| ari-tczew | s/here on/here or | 19:27 |
| jploz | ari-tczew: why? I thought MOTU is responsible for universe and my package is in universe? | 19:27 |
| ari-tczew | jploz: yes, MOTU is responsible for universe/multiverse, but we are volunteers and we work when we have free time. | 19:29 |
| ari-tczew | jploz: anyway, I didn't see your question for sponsor yet. | 19:30 |
| jploz | actually, the request in question is from 2011-02-15, package sbackup, last comment by peer.loz. I only ask here because last time it took just a few hours and I began to ask myself whether i've missed something. if anything is ok and there is just a lack of resources, no problem. I completely understand. | 19:39 |
| ari-tczew | jploz: join #ubuntu-devel, look on the topic who is patch pilot right now and ask him for review giving a link to branch or bug | 19:42 |
| jploz | ari-tczew: ok, many thanks for your help. | 19:43 |
| ari-tczew | jploz: You're welcome. | 19:43 |
| bdrung | ari-tczew: i have processed all remaining sync and merge requests | 19:48 |
| ari-tczew | bdrung: yay, nice! it's appreciated. have you got time for review upgrade requests as well? | 19:49 |
| bdrung | ari-tczew: are there requests for main? | 19:49 |
| ari-tczew | bdrung: yes | 19:50 |
| ari-tczew | bdrung: e.g. bug 720905 | 19:50 |
| ubottu | Launchpad bug 720905 in gnupg (Ubuntu) "[Merge] gnupg 1.4.11-3 from debian (unstable)" [Undecided,New] https://launchpad.net/bugs/720905 | 19:51 |
| bdrung | ari-tczew: hm, it wasn't detected as merge | 19:51 |
| ari-tczew | bdrung: maybe due to bzr branch | 19:51 |
| bdrung | ari-tczew: no, because "[Merge]" was used instead of "Merge" | 19:52 |
| ari-tczew | bdrung: also jploz asked some minutes ago for review bug 719264 | 19:52 |
| ubottu | Launchpad bug 719264 in sbackup (Ubuntu) "New upstream release 0.11.4" [Wishlist,Confirmed] https://launchpad.net/bugs/719264 | 19:52 |
| arand | When I have a src package that splits into multiple packages, is that the cause for DESTDIR to become ~/pkgsrc/debian/_tmp_/usr/games ? I'm asking because whe I try to build it returns cp: ...No such file or directory | 19:53 |
| bdrung | the sponsor overview should use a regular expression instead of "word in title" | 19:53 |
| ari-tczew | bdrung: I sent a mail to dholbach that patch pilots without upload rights are not efficient. | 19:53 |
| arand | It doesn't feel right to define that directory in debian/dirs, or should I? | 19:53 |
| micahg | ari-tczew: the goal of the patch pilot isn't just sponsorship | 19:53 |
| bdrung | ari-tczew: they are valuable even without upload rights | 19:53 |
| bdrung | arand: DESTDIR=$(CURDIR)/debian/tmp for packages with multiples binary packages | 19:54 |
| ari-tczew | micahg, bdrung: from economical point of view, effective is review + sponsorship | 19:54 |
| ari-tczew | for the same costs | 19:54 |
| bdrung | ari-tczew: you forget the learning effect | 19:55 |
| ari-tczew | bdrung: the best learning effect is contributing, 4 hours per month is too small to get a big knowledge about flow of work | 19:56 |
| arand | Ok, I have a package which initially used "cp game ../bin/" in it's makefile, and I've used quilt to set it to "cp $(DESTDIR)/usr/games/game" but I obviously need to make it general, what's the normal thing to do in a makefile like this | 19:58 |
| bdrung | arand: before the copy command, you need to create the directory (mkdir -p <dir>) | 19:59 |
| arand | So I should patch the source Makefile to create them? I though that seemed a bit odd.. | 20:01 |
| bdrung | arand: yes (and then send the patch to upstream) | 20:02 |
| bdrung | arand: you should patch Makefile.am or Makefile.in (if they are present) | 20:02 |
| ari-tczew | before patching please check whether there is a patch system by command 'what-patch' | 20:03 |
| arand | Nope, just Makefile, and the source is setup in this way to easily allow for in-place recompiling of binary, it doesn't do system installation as far as I can tell | 20:04 |
| Laney | use install | 22:52 |
| bdrung | arand: ^ while you are patching the makefile, replace "cp" with "install" | 22:53 |
| Laney | you can use -D to create the directory too | 22:54 |
| arand | cool | 22:54 |
| arand | Now I'm just trying to figure out how to do the menu item, and why for some reason an .desktop file refuses to run a binary which runs fine if ececuted otherwise... | 22:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!