| === Alcine is now known as jalcine | ||
| Resistance | if a package is submitted without the debian/copyright, will the build fail? | 01:44 |
|---|---|---|
| Resistance | hypothetically | 01:44 |
| Resistance | (in PPA) | 01:44 |
| StevenK | It will not. | 01:44 |
| StevenK | But that's bad, fix that. | 01:44 |
| Resistance | indeed | 01:44 |
| StevenK | Actually, it might. | 01:44 |
| * StevenK paws at debhelper | 01:44 | |
| broder | i think it will build | 01:45 |
| Resistance | but of course, omitting the file is bad form | 01:45 |
| Resistance | but its a hypothetical nonetheless :P | 01:45 |
| StevenK | dh_installdocs may fail | 01:45 |
| broder | no, it unfortunately checks to make sure the file exists | 01:46 |
| StevenK | s/un// | 01:47 |
| broder | i'd rather it failed | 01:47 |
| Resistance | personally i agree with you, broder, it should fail if that file isnt included | 01:48 |
| StevenK | If it wasn't a PPA, it would get kicked out of NEW pretty damn quick. | 01:48 |
| Resistance | mhm | 01:48 |
| broder | you know, you say that, but i recently fixed a universe package that had a debian/copyright file, but didn't install it | 01:48 |
| Resistance | heh | 01:49 |
| broder | http://lintian.ubuntuwire.org/tags/no-debian-copyright.html | 01:49 |
| Resistance | broder: well the project that wants their package without a debian/copyright comes with a docs/LICENSE file... | 01:49 |
| Resistance | *shrugs* | 01:49 |
| Resistance | but debian/copyright *SHOULD* be included | 01:49 |
| broder | "(80 packages, 80 tags, plus 1 overrides)" | 01:50 |
| Resistance | broder: question regarding debian/install | 02:45 |
| Resistance | i take it any extraneous blank lines in the debian/install file will cause it to error? | 02:45 |
| Resistance | for whoever writes the install file to be able to see the different directories being installed in their own respective chunks | 02:46 |
| === almaisan-away is now known as al-maisan | ||
| Resistance | whats the command to update the pbuilder chroot? | 13:46 |
| Resistance | or i should say, the pbuilder tarballs for each release of Ubuntu (lucid, natty, etc.) | 13:46 |
| Zhenech_ | pbuilder --update? | 13:51 |
| Resistance | i'll try that next | 13:51 |
| Resistance | fwiw, my pbuilder base tarballs are about a year old | 13:51 |
| Resistance | i might just rebuild them | 13:51 |
| === Resistance is now known as EvilResistance | ||
| === al-maisan is now known as almaisan-away | ||
| jtaylor | how does one get gcc not to crash all the time in qemu armel pbuilder ... | 18:05 |
| === yofel_ is now known as yofel | ||
| gnuvince_ | Is there a document that would give a way to "follow" a Debian package? I'm on the UbuntuGIS packaging team, and we follow the development of DebianGIS packages. I'm looking for a way to maintain our own changes while still making it easy to import the changes made by DebianGIS. They use git, so I thought of using that, but I cannot come up with a repo structure that would make it easy to pull their changes and make our own. | 18:54 |
| Laney | gnuvince_: the best way is to not have to make any changes, and just join the Debian team. If some changes are essential then you can track them as Ubuntu specific branches in Debian's git repository (or host it elsewhere). Or you could set up Launchpad imports of their branches and keep your changes as bzr branches of those on LP somewhere, if you like bzr. | 18:56 |
| Laney | Really the best thing is to work with the Debian team directly as much as you can. | 18:57 |
| psusi | gnuvince_: what do you mean "structure"? you just pull and git merges their changes | 18:57 |
| gnuvince_ | Laney: so the best Ubuntu package is an unmodified Debian package? | 19:00 |
| Laney | absolutely | 19:00 |
| Zhenech_ | and the best Ubuntu is Debian *duck* | 19:01 |
| Laney | but if you can't avoid changes then still working with the Debian maintainers is great | 19:01 |
| Laney | technically psusi is right though: it's easy to keep Ubuntu changes on a git branch and merge with the Debian branch whenever you need to. | 19:02 |
| * Laney pats Zhenech_ | 19:02 | |
| Alison_Chaiken | Hey jtaylor, my packages now install in a clean Qemu-kvm: https://secure.flickr.com/photos/99725460@N00/6629492495/in/photostream | 19:03 |
| Alison_Chaiken | Hmm, I get a directory /debian with two files in it afterward. | 19:04 |
| Alison_Chaiken | Oh well, the binary does run as expected, the headers do install. Progress is being made! | 19:04 |
| gnuvince_ | I also have a question about the changelog file | 19:04 |
| Alison_Chaiken | And my lintian is almost clean. It didn't complain about those /debian files in the package. | 19:04 |
| Alison_Chaiken | Thanks so much to geser, amitch, wgrant and jtaylor for their ultrapatient help. You are true ubuntu-motu. | 19:05 |
| gnuvince_ | Let's say I need to update a package for lucid, natty and oneiric. How should I manange the changelog file? Should I remove the information that I built for natty when i build for oneiric? | 19:05 |
| jtaylor | gnuvince_: each package gets its own fork of the changelog | 19:08 |
| jtaylor | oneiric does not need to know about natty sru's | 19:08 |
| psusi | each branch gets its own changelog... when you merge from one to the other, you will probably need to do some manual merging of the changelog | 19:09 |
| gnuvince_ | ok | 19:10 |
| Laney | that is why we have dpkg-mergechangelogs | 19:10 |
| gnuvince_ | So would a good way of packaging be to take the git repo of Debian, make branches for lucid, natty, oneiric, etc. and maintain the changelog in those branches? | 19:12 |
| gnuvince_ | Or is there a simpler way? | 19:13 |
| jtaylor | thats pretty much the simplest way | 19:14 |
| gnuvince_ | ok | 19:14 |
| gnuvince_ | What aout sharing those branches with other UbuntuGIS developers? | 19:15 |
| jtaylor | git clone? | 19:15 |
| jtaylor | pull/fetch etc | 19:15 |
| jtaylor | collaboration is pretty much was git is built for, you'll have a hard time finding a better tool | 19:16 |
| gnuvince_ | Do they need to clone from me, or can they clone from DebianGIS and pull the branches from me? | 19:16 |
| gnuvince_ | (I'm more of an hg guy) | 19:17 |
| psusi | either way | 19:17 |
| jtaylor | as long as all repos have the same ancestry (which they will unless you screw up bad) it does not matter who pulls from whom | 19:17 |
| jtaylor | of course the ubuntu branches will ahve to be pulled from you unless you also get the hosted in debiants git | 19:18 |
| psusi | most people prefer to set up a central repo hosted somewhere for the group to all clone from and work on your branches, then you can also fetch from the debian repo and merge into your branches when appropriate, then push back to the central repo | 19:18 |
| gnuvince_ | So that'd go [ DebianGIS ] ---> [ UbutnuGIS ] <---> [ UbuntuGIS Devs] ? | 19:19 |
| psusi | yea | 19:19 |
| gnuvince_ | ok | 19:19 |
| achiang | when is the next auto-sync from debian/testing? | 19:20 |
| psusi | of course, the line between debiangis and ubuntugis doesn't need to be one way either, the debian devs can pull from ubuntugis | 19:20 |
| psusi | you can do it just about any way you like with git... an ubuntugis dev can pull directly from a debiangis dev's repo.. or an ubuntugis dev can push to ubuntugis repo, and another ubuntugis dev can pull from it, then email patches to a debiangis dev to apply to his repo and push to debiangis | 19:24 |
| EvilResistance | is there any way to create a pbuilder base tarball for precise? putting pbuilder --create --distribution precise errors out | 19:37 |
| Ampelbein | "Errors out" isn't an error message. | 19:41 |
| Ampelbein | ;-) | 19:41 |
| EvilResistance | one sec | 19:42 |
| Ampelbein | EvilResistance: I would use the pbuilder-dist script in ubuntu-dev-tools, it is a very easy wrapper to support multiple distributions. | 19:42 |
| Ampelbein | But generally, it should work with pure pbuilder, of course. | 19:43 |
| EvilResistance | https://pastebin.com/BSfQT7Qc <-- that's the errors | 19:43 |
| EvilResistance | and i have that installed so... | 19:44 |
| jtaylor | just symlink the script of a different distro to that name | 19:45 |
| jtaylor | their all the same | 19:45 |
| Ampelbein | EvilResistance: what jtaylor says, if you are running natty or earlier. | 19:45 |
| EvilResistance | yeah i'm on natty, it has oneiric though, strangely enough :/ | 19:46 |
| Ampelbein | EvilResistance: because on natty, oneiric was the next devel release. | 19:46 |
| Ampelbein | Current stable includes a script to stable+1 | 19:47 |
| EvilResistance | oic | 19:47 |
| EvilResistance | wth the debootstrap scripts for everything still point to a gutsy one o.O | 19:48 |
| blair | Thanks for everyones help, the package I was interested in getting into 12.04 got in this last week via Debian :) | 19:50 |
| Laney | yay | 19:58 |
| micahg | great | 19:59 |
| jtaylor | what do I do when a SRU fails to build on one arch? | 21:14 |
| Laney | did it build before? | 21:14 |
| jtaylor | yes | 21:14 |
| jtaylor | libqxt, some armel symbol issue, I don't really get why it failed in the oneiric-proposed but worked in precise | 21:15 |
| jtaylor | sru did only install some extra files | 21:16 |
| Laney | i guess it really ought to be fixed, not sure what the sru team would say though | 21:16 |
| broder | jtaylor: but it didn't build before the sru on armel either | 21:16 |
| broder | for similar reasons | 21:16 |
| jtaylor | what oO | 21:16 |
| jtaylor | gna I'm blind | 21:16 |
| broder | https://launchpad.net/ubuntu/+source/libqxt/0.6.1-3ubuntu1/+build/2809334 | 21:16 |
| jtaylor | well then its no regression and fine? | 21:17 |
| broder | i'd say so | 21:17 |
| micahg | umm, why not just updated the symbols file for armel? | 21:17 |
| jtaylor | that would be possible, I just can't test it because I fail to get a armel chroots to work | 21:18 |
| jtaylor | gcc always crashes :/ | 21:19 |
| jtaylor | say it would have built on armel before, what would be the route to fix that? | 21:20 |
| jtaylor | just upload another fix to -proposed? | 21:20 |
| Laney | yeah | 21:21 |
| Laney | but it looks fixable anyway if you look at the changes in -5 | 21:22 |
| jtaylor | yes, but the diff there does match the diff in the log | 21:22 |
| jtaylor | I'd like to try it but ... | 21:22 |
| jtaylor | I wonder why it worked in precise without that | 21:23 |
| Laney | the Debian changelog says why | 21:24 |
| jtaylor | Fix symbols files for some architectures.? it doesn't tell me :( | 21:25 |
| jtaylor | precise does not have -5 | 21:25 |
| Laney | no, this | 21:25 |
| Laney | +override_dh_makeshlibs: | 21:25 |
| Laney | +dh_makeshlibs -- -c0 | 21:25 |
| Laney | makes it not fail | 21:25 |
| micahg | right, but don't we want a proper symbols file on the arch? | 21:26 |
| Laney | there is still a diff in the logs if you see | 21:26 |
| Laney | I am not saying that is what you should do, just explaining why it doesn't fail any more | 21:26 |
| jtaylor | the sru has that too? is that a new flag in precise? | 21:28 |
| Laney | in -4 | 21:28 |
| jtaylor | ah, I'm slow today ._. | 21:29 |
| Laney | jtaylor: if you are fixing it, it looks like there might be a mistake in libqxt-gui0.symbols line 75-76 in -5 though | 21:34 |
| jtaylor | yes I saw | 21:35 |
| jtaylor | I'll wait until the maintainer sorts it out and merge it to precise | 21:35 |
| Laney | does he know? | 21:36 |
| jtaylor | probably, I'll mail him | 21:36 |
| Laney | isn't a blocker though because -- -c0 is still there | 21:37 |
| Laney | more appropriate for the sru | 21:37 |
| jtaylor | oO why does quilt recommend citadell now | 22:45 |
| jtaylor | ... it recomends a mta for some little script in share | 22:47 |
| === RoAkSoAx_ is now known as RoAkSoAx | ||
| Laney | er, I see it as a suggests | 22:49 |
| Laney | oh, not released yet | 22:51 |
| Laney | will be in -2 | 22:51 |
| jtaylor | a nice | 22:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!