[01:14] <Logan_> ScottK: Still around?
[02:03] <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:05] <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:19] <Logan_> ScottK: https://docs.google.com/file/d/0B77anyH872rJamJzRjBtZXpVck0/edit?usp=sharing
[03:07] <ScottK> Logan_: A link to the .dsc from your PPA would be fine.
[03:08] <Logan_> ScottK: https://launchpad.net/~logan/+archive/arm/+files/cdrdao_1.2.3-1ubuntu2.dsc
[03:09] <ScottK> Got it.
[05:00] <ScottK> Logan_: Problems with my arm stuff, so I can't check it.
[05:00] <Logan_> :/
[05:01] <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:09] <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.
[07:52] <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 ?
[08:01] <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:02] <siretart> Guest13890: also, make sure to not confuse the terms "binaries" vs "sources" and "binary package" vs. "source package".
 : 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] <siretart> Guest13890: source tarballs that contain binaries are a good reason to repack the source tarball
[08:14] <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:15] <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:16] <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:20] <Guest13890> siretart: okay. thank you very much.
[08:21] <siretart> you're welcome
[08:38] <Guest13890> is a JAR file in a source package generally considered as a binary file ?
[08:41] <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:42] <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:44] <siretart> are you the upstream author?
[08:45] <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:46] <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:47] <Guest13890> okay. but images (PNG) are allowed in source packages (even if they are binary files) yes ?
[08:47] <siretart> of course
[08:48] <siretart> a good test is "can I improve that file directly by editing it, or is there some real source behind it"
[08:50] <Guest13890> ah ok. i got it :)
[17:24] <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:25] <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:26] <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