[01:14] ScottK: Still around? [02:03] Logan_: Sort of [02:03] ScottK: https://launchpadlibrarian.net/134960037/buildlog_ubuntu-raring-armhf.cdrdao_1%3A1.2.3-1ubuntu2_UPLOADING.txt.gz [02:03] No mention of armv7l, still... [02:03] I think it's because the ARM builders for PPAs are virtual. [02:05] That shouldn't matter. [02:05] Point me to the source package though and I'll try to build it on real hardware. [02:19] ScottK: https://docs.google.com/file/d/0B77anyH872rJamJzRjBtZXpVck0/edit?usp=sharing === jtechidna is now known as JontheEchidna [03:07] Logan_: A link to the .dsc from your PPA would be fine. [03:08] ScottK: https://launchpad.net/~logan/+archive/arm/+files/cdrdao_1.2.3-1ubuntu2.dsc [03:09] Got it. [05:00] Logan_: Problems with my arm stuff, so I can't check it. [05:00] :/ [05:01] Should we assume that it'll build with the arm patch still in Ubuntu and apply the merge? [05:01] Worst case scenario, it's in raring-proposed, and arm users can still download the previous version [05:09] If you build with and without the patch and the build logs are the same, it's reasonable to assume it's not needed. === Altair is now known as Guest13890 [07:52] 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] What can I do ? [08:01] 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:02] Guest13890: also, make sure to not confuse the terms "binaries" vs "sources" and "binary package" vs. "source package". === Logan__ is now known as Logan_ [08:08] : 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:13] Guest13890: source tarballs that contain binaries are a good reason to repack the source tarball [08:14] so I can modify the content of the source tar ball as much as I want ? [08:14] Guest13890: in any case, make sure that you use 'dpkg-buildpackage -S ' or some front-end such as debuild or 'bzr bd' to create a source package [08:15] 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:16] 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:20] siretart: okay. thank you very much. [08:21] you're welcome [08:38] is a JAR file in a source package generally considered as a binary file ? [08:41] AFAIUI, JAR files are technically ZIP files that contain java bytecode, right? [08:41] which is hardly the prefered form of modification [08:42] not generally. In my case the are resource files containing only PNG images. [08:42] The program can load different JAR files containing different Icon sets at runtime. [08:44] are you the upstream author? [08:45] No. [08:45] 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:46] I honestly do not know if the archive admins would reject a package that ships with such jar files, you could probably try. [08:47] okay. but images (PNG) are allowed in source packages (even if they are binary files) yes ? [08:47] of course [08:48] a good test is "can I improve that file directly by editing it, or is there some real source behind it" [08:50] ah ok. i got it :) === yofel_ is now known as yofel === Ursinhal is now known as Ursinha [17:24] 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] 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:25] 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] is working for all other models and just not the X1 carbon, maybe it is a kernel issue with this specific driver? [17:26] 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] I also confirmed in upstream git gnome is using increments of 5 === jcfp is now known as Guest76786