| Logan_ | ScottK: Still around? | 01:14 |
|---|---|---|
| ScottK | Logan_: Sort of | 02:03 |
| Logan_ | ScottK: https://launchpadlibrarian.net/134960037/buildlog_ubuntu-raring-armhf.cdrdao_1%3A1.2.3-1ubuntu2_UPLOADING.txt.gz | 02:03 |
| Logan_ | No mention of armv7l, still... | 02:03 |
| Logan_ | I think it's because the ARM builders for PPAs are virtual. | 02:03 |
| ScottK | That shouldn't matter. | 02:05 |
| ScottK | Point me to the source package though and I'll try to build it on real hardware. | 02:05 |
| Logan_ | ScottK: https://docs.google.com/file/d/0B77anyH872rJamJzRjBtZXpVck0/edit?usp=sharing | 02:19 |
| === jtechidna is now known as JontheEchidna | ||
| ScottK | Logan_: A link to the .dsc from your PPA would be fine. | 03:07 |
| Logan_ | ScottK: https://launchpad.net/~logan/+archive/arm/+files/cdrdao_1.2.3-1ubuntu2.dsc | 03:08 |
| ScottK | Got it. | 03:09 |
| ScottK | Logan_: Problems with my arm stuff, so I can't check it. | 05:00 |
| Logan_ | :/ | 05:00 |
| Logan_ | Should we assume that it'll build with the arm patch still in Ubuntu and apply the merge? | 05:01 |
| Logan_ | Worst case scenario, it's in raring-proposed, and arm users can still download the previous version | 05:01 |
| ScottK | If you build with and without the patch and the build logs are the same, it's reasonable to assume it's not needed. | 05:09 |
| === Altair is now known as Guest13890 | ||
| Guest13890 | Packaging question: I have downloaded a source tar ball, but it contains some compiled code. I wanted to add the original source unmodified to the new debian source package, but when I uploaded my DEB file to my PPA,it was rejected, with the reason that it contains binaries and sources. | 07:52 |
| Guest13890 | What can I do ? | 07:52 |
| siretart | Guest13890: make sure that you never call dput on anything else than *_source.changes. Do not try to "cheat" with renaming your existing files, you really need to create a debian source package | 08:01 |
| siretart | Guest13890: also, make sure to not confuse the terms "binaries" vs "sources" and "binary package" vs. "source package". | 08:02 |
| === Logan__ is now known as Logan_ | ||
| Guest13890 | <siretart> : I followed a tutorial. I was told to include the original source.tar.gz in that package. And as I said, that package contained some binaries. I'm not trying to cheat. As far as I understood the original source tar ball is supposed to be unmodified. | 08:08 |
| siretart | Guest13890: source tarballs that contain binaries are a good reason to repack the source tarball | 08:13 |
| Guest13890 | so I can modify the content of the source tar ball as much as I want ? | 08:14 |
| siretart | Guest13890: in any case, make sure that you use 'dpkg-buildpackage -S <further options>' or some front-end such as debuild or 'bzr bd' to create a source package | 08:14 |
| siretart | Guest13890: of course. make sure that you give your repackaged source tarball a distinct name. we often use foo_1.0+dfsg1.orig.tar.gz for that to indicate that the tarball has been repackage to conform to the debian free software guidelines. | 08:15 |
| siretart | Guest13890: the drawback is that your users are no longer able to verify that the sources are "pristine", that is, taken unmodified from upstream | 08:16 |
| Guest13890 | siretart: okay. thank you very much. | 08:20 |
| siretart | you're welcome | 08:21 |
| Guest13890 | is a JAR file in a source package generally considered as a binary file ? | 08:38 |
| siretart | AFAIUI, JAR files are technically ZIP files that contain java bytecode, right? | 08:41 |
| siretart | which is hardly the prefered form of modification | 08:41 |
| Guest13890 | not generally. In my case the are resource files containing only PNG images. | 08:42 |
| Guest13890 | The program can load different JAR files containing different Icon sets at runtime. | 08:42 |
| siretart | are you the upstream author? | 08:44 |
| Guest13890 | No. | 08:45 |
| siretart | well, maybe you can suggest to him that providing the build scripts how to rebuild them would be a great idea, ideally by submitting a patch | 08:45 |
| siretart | I honestly do not know if the archive admins would reject a package that ships with such jar files, you could probably try. | 08:46 |
| Guest13890 | okay. but images (PNG) are allowed in source packages (even if they are binary files) yes ? | 08:47 |
| siretart | of course | 08:47 |
| siretart | a good test is "can I improve that file directly by editing it, or is there some real source behind it" | 08:48 |
| Guest13890 | ah ok. i got it :) | 08:50 |
| === yofel_ is now known as yofel | ||
| === Ursinhal is now known as Ursinha | ||
| sharms | for bug #1121951, I know what the problem is (the backlight step is in increments of 5, but the backlight interface for the X1 carbon will only take increments of 10) | 17:24 |
| ubottu | bug 1121951 in gnome-settings-daemon (Ubuntu) "Lenovo X1 Carbon: Backlight brightness keys don't work any more" [Undecided,Confirmed] https://launchpad.net/bugs/1121951 | 17:24 |
| sharms | does anyone have an idea of which part it should be fixed at? It seems that if a backlight step (the variable discrete under gnome-settings-daemon/plugins/power/gsd-power-plugin.c | 17:25 |
| sharms | is working for all other models and just not the X1 carbon, maybe it is a kernel issue with this specific driver? | 17:25 |
| sharms | the easiest fix is that I just hack a patch to use increments of 10, but that wouldn't be usable for everyone else | 17:26 |
| sharms | I also confirmed in upstream git gnome is using increments of 5 | 17:26 |
| === jcfp is now known as Guest76786 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!