Re: [Pkg-phototools-devel] [PATCH 0/5] Bits from the Hugin PPA Packagers
Hello Andreas On 27.07.2012 18:37, Andreas Metzler wrote: Hello Stefan, thanks for the heads-up, however I have got the strong feeling of duplicate work happening. We already have this in experimental (Includes your patches 1, 2): Sorry, I didn't intend to waste your time. Obviously, I used the unstable branch instead of the experimental branch as the base for my modifications. I will rebase and let you know whats left over from my patches. Patches 4 5 are in hugin HG and should be included in beta2. Yes, this was mentioned in the cover letter, too. We will need a equivalent of Patch 3 in experimental, though. I will have a look at this. Thank you for the review. With kind regards Stefan Peter -- In summary, I think you are trying to solve a problem that may not need to be solved, using a tool that is not meant to solve it, without understanding what is causing your problems and without knowing how the tool actually works in the first place :) Jeffrey J. Kosowsky on the backuppc mailing list ___ Pkg-phototools-devel mailing list Pkg-phototools-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-phototools-devel
Re: [Pkg-phototools-devel] Chromium keeps crashing with segfaults
We know this bug occurred when we upgrade libexif to 0.6.20-3. One of that security patch broke the package. Instead of downgrading libexif to 0.6.20-2, I made a package for 0.6.21. It includes security fixes and chromium crashes are gone. You can get it here and use it until libexif maintainers fix the package: http://i.onur.im/libexif/ And I believe, this bug must be grave. It simply makes chromium unusable. ___ Pkg-phototools-devel mailing list Pkg-phototools-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-phototools-devel
[Pkg-phototools-devel] Processing of hugin_2012.0.0~beta1+dfsg-2_i386.changes
hugin_2012.0.0~beta1+dfsg-2_i386.changes uploaded successfully to localhost along with the files: hugin_2012.0.0~beta1+dfsg-2.dsc hugin_2012.0.0~beta1+dfsg-2.debian.tar.gz hugin_2012.0.0~beta1+dfsg-2_i386.deb hugin-tools_2012.0.0~beta1+dfsg-2_i386.deb hugin-data_2012.0.0~beta1+dfsg-2_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ Pkg-phototools-devel mailing list Pkg-phototools-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-phototools-devel
[Pkg-phototools-devel] hugin_2012.0.0~beta1+dfsg-2_i386.changes ACCEPTED into experimental
Accepted: hugin-data_2012.0.0~beta1+dfsg-2_all.deb to main/h/hugin/hugin-data_2012.0.0~beta1+dfsg-2_all.deb hugin-tools_2012.0.0~beta1+dfsg-2_i386.deb to main/h/hugin/hugin-tools_2012.0.0~beta1+dfsg-2_i386.deb hugin_2012.0.0~beta1+dfsg-2.debian.tar.gz to main/h/hugin/hugin_2012.0.0~beta1+dfsg-2.debian.tar.gz hugin_2012.0.0~beta1+dfsg-2.dsc to main/h/hugin/hugin_2012.0.0~beta1+dfsg-2.dsc hugin_2012.0.0~beta1+dfsg-2_i386.deb to main/h/hugin/hugin_2012.0.0~beta1+dfsg-2_i386.deb Changes: hugin (2012.0.0~beta1+dfsg-2) experimental; urgency=low . * Update to head of upstream HG 2012.0 branch (30_dutch_translation.diff 31_danish_translation.diff 32_update_python_api_versions.diff 33_unified_api-max.diff 34_assistant_downscale.diff 35_copyrightyear_and_lensfunref.diff). Included python plugins should work again. Thanks, Stefan Peter. Override entries for your package: hugin-data_2012.0.0~beta1+dfsg-2_all.deb - optional graphics hugin-tools_2012.0.0~beta1+dfsg-2_i386.deb - optional graphics hugin_2012.0.0~beta1+dfsg-2.dsc - source graphics hugin_2012.0.0~beta1+dfsg-2_i386.deb - optional graphics Announcing to debian-experimental-chan...@lists.debian.org Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. ___ Pkg-phototools-devel mailing list Pkg-phototools-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-phototools-devel
Re: [Pkg-phototools-devel] [PATCH 0/5] Bits from the Hugin PPA Packagers
On 2012-07-28 Stefan Peter s_pe...@swissonline.ch wrote: On 27.07.2012 18:37, Andreas Metzler wrote: [...] We will need a equivalent of Patch 3 in experimental, though. I will have a look at this. Hello Stefan, I have just made a new hugin upload to experimental, updating the source to tip of upstream HG 2012.0 branch. (Which includes the necessary fix.) FYI You can receive automatic notification by e-mail on every hugin upload from Debian's package tracking system. on http://packages.qa.debian.org/h/hugin.html (Select source-upload under opts.) Is the hugin PPA packaging available in revision control somewhere? cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' ___ Pkg-phototools-devel mailing list Pkg-phototools-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-phototools-devel
[Pkg-phototools-devel] Bug#682980: darktable: should use system shared libraw
[switching to non-quiet flavor of bug address] On 12-07-28 at 12:09pm, Pascal de Bruijn wrote: On Sat, Jul 28, 2012 at 2:26 AM, Jonas Smedegaard d...@jones.dk wrote: On 12-07-28 at 12:42am, Pascal de Bruijn wrote: On Sat, Jul 28, 2012 at 12:28 AM, Jonas Smedegaard d...@jones.dk wrote: On 12-07-27 at 10:08pm, Pascal de Bruijn wrote: When Darktable is linked against an external Libraw (or for that matter RawSpeed) library, we likely would get lots of camera support bugs which aren't reproducible (assuming the Debian Libraw version is older), wasting our time. Or we aren't getting any valid camera support bugs reported (assuming the Debian Libraw version is newer). So both cases (newer and older) are detrimental to our project. Bugs from users of Debian should go to Debian for this exact reason: The Debian package maintainers should pass upstream to you the Darktable developers only bugs relevant for you. Yeah, but that's not reality. People will just come and ask on our mailing lists and irc channels, often not telling us they are running Debian (unless we specifically ask), wasting our time. I recognize that issue from users of Debian reporting bugs about packages derived from Debian but changed in various ways unknown to us. What I do with that is not try enforce one single use of the packages we provide, but a) tell our users that they are free to use Debian also in (to us) weird ways (that's one of the freedoms that DFSG-free licensing provides!), but b) they are strongly recommended to tell us very clearly up front when reporting bugs if their setup of Debian is unusual, to not waste our time e.g. chasing bugs inefficiently. I guess that's a similar issue. However, there is a difference with users personally modifying things. And distributions shipping non-standard versions. We'd like to make sure that users get a user experience that is representative of our intended Darktable user experience. Users of Debian are not only personal. One user of Debian is the distribution Ubuntu. So in my opinion Darktable should get a permanent exception to this Debian policy. PS: Please don't misunderstand, I generally agree with the policy in this regard, it's just that it makes very little sense for projects like Darktable. Sorry, but I fail to see how this issue is any different from e.g. consumers of libexiv and the resulting changes to richness of the EXIF Having an older libexiv2 will not prevent files from being read at all. Having an old libraw could result in images being green instead of properly white balanced in some cases. And in even fewer cases it could result in files not loading at all (where they should have just loaded just fine (and/or not being green) with unpatched darktable sources). data supported with various versions of that library: as long as the API is the same, newest version of the library most often is preferred. Yes, but that isn't what happens in reality. What happens in reality is that Debian is usually behind, really... If I misunderstood and there is really something more intimate going on specifically with Darktable and its libraries could you please try elaborate more on that? With regard to the patch, LibRaw does RAW reading _and_ processing, we only use the RAW reading bits (which is fairly atypical). But the LibRaw processing bits don't support float DNGs (which we use for HDR IIRC), so the LibRaw authors are blocking them from being read. So we need to patch that up for our particular use. Besides the above, there is nothing more intimate going on, except that I see lots of potential problems, with little or no gain at all in our particular case. Thanks for the details. It still sound to me like Darktable would make good sense to link against shared libraries for Debian. I don't see how you'd resolve the float issue. But even if that were to be resolved. What is the perceived benefit in this particular case? Same benefits as with other cases. This is nicely described in Debian Policy: http://www.debian.org/doc/debian-policy/footnotes.html#f30 Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Pkg-phototools-devel mailing list Pkg-phototools-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-phototools-devel
[Pkg-phototools-devel] Bug#682980: darktable: should use system shared libraw
On Sat, Jul 28, 2012 at 6:19 PM, Jonas Smedegaard d...@jones.dk wrote: [switching to non-quiet flavor of bug address] On 12-07-28 at 12:09pm, Pascal de Bruijn wrote: On Sat, Jul 28, 2012 at 2:26 AM, Jonas Smedegaard d...@jones.dk wrote: On 12-07-28 at 12:42am, Pascal de Bruijn wrote: On Sat, Jul 28, 2012 at 12:28 AM, Jonas Smedegaard d...@jones.dk wrote: On 12-07-27 at 10:08pm, Pascal de Bruijn wrote: When Darktable is linked against an external Libraw (or for that matter RawSpeed) library, we likely would get lots of camera support bugs which aren't reproducible (assuming the Debian Libraw version is older), wasting our time. Or we aren't getting any valid camera support bugs reported (assuming the Debian Libraw version is newer). So both cases (newer and older) are detrimental to our project. Bugs from users of Debian should go to Debian for this exact reason: The Debian package maintainers should pass upstream to you the Darktable developers only bugs relevant for you. Yeah, but that's not reality. People will just come and ask on our mailing lists and irc channels, often not telling us they are running Debian (unless we specifically ask), wasting our time. I recognize that issue from users of Debian reporting bugs about packages derived from Debian but changed in various ways unknown to us. What I do with that is not try enforce one single use of the packages we provide, but a) tell our users that they are free to use Debian also in (to us) weird ways (that's one of the freedoms that DFSG-free licensing provides!), but b) they are strongly recommended to tell us very clearly up front when reporting bugs if their setup of Debian is unusual, to not waste our time e.g. chasing bugs inefficiently. I guess that's a similar issue. However, there is a difference with users personally modifying things. And distributions shipping non-standard versions. We'd like to make sure that users get a user experience that is representative of our intended Darktable user experience. Users of Debian are not only personal. One user of Debian is the distribution Ubuntu. Yes, which multiplies the problem for us. But at least for Ubuntu I can point people to my Darktable PPAs. So in my opinion Darktable should get a permanent exception to this Debian policy. PS: Please don't misunderstand, I generally agree with the policy in this regard, it's just that it makes very little sense for projects like Darktable. Sorry, but I fail to see how this issue is any different from e.g. consumers of libexiv and the resulting changes to richness of the EXIF Having an older libexiv2 will not prevent files from being read at all. Having an old libraw could result in images being green instead of properly white balanced in some cases. And in even fewer cases it could result in files not loading at all (where they should have just loaded just fine (and/or not being green) with unpatched darktable sources). data supported with various versions of that library: as long as the API is the same, newest version of the library most often is preferred. Yes, but that isn't what happens in reality. What happens in reality is that Debian is usually behind, really... If I misunderstood and there is really something more intimate going on specifically with Darktable and its libraries could you please try elaborate more on that? With regard to the patch, LibRaw does RAW reading _and_ processing, we only use the RAW reading bits (which is fairly atypical). But the LibRaw processing bits don't support float DNGs (which we use for HDR IIRC), so the LibRaw authors are blocking them from being read. So we need to patch that up for our particular use. Besides the above, there is nothing more intimate going on, except that I see lots of potential problems, with little or no gain at all in our particular case. Thanks for the details. It still sound to me like Darktable would make good sense to link against shared libraries for Debian. I don't see how you'd resolve the float issue. But even if that were to be resolved. What is the perceived benefit in this particular case? Same benefits as with other cases. This is nicely described in Debian Policy: http://www.debian.org/doc/debian-policy/footnotes.html#f30 1. Having multiple copies of the same code in Debian is inefficient Ok. I get that. But it's hardly worth creating problems for. 2. often creates either static linking or shared library conflicts I'm not sure how that would happen. Including local libraries generally avoids that problem, instead of creating it. 3. and, most importantly, increases the difficulty of handling security vulnerabilities in the duplicated code. This is a good point, particularly for network/Internet facing program and libraries. Though for LibRaw it's a rather theoretical point.
[Pkg-phototools-devel] Bug#683110: gphoto2: gphoto fails on USB 3.0 port
Package: gphoto2
Version: 2.4.14-1
Severity: normal
Dear Maintainer,
I am running gphoto on my HP laptop with my Canon camera.
Running gphoto2 --get-all-files --filename %:
succeeds just fine, but the subsequent
gphoto2 --recurse --delete-all-files
fails with An error occurred in the io-library ('Unspecified error'): No error
description available
It works fine on the USB 2.0 port.
When I plug the camera in the 3.0 port, I get the following messages in the
kernel log:
Jul 28 15:42:10 laptop kernel: [ 71.203480] usb 2-2: new high-speed USB
device number 2 using xhci_hcd
Jul 28 15:42:10 laptop kernel: [ 71.222197] xhci_hcd :05:00.0: WARN:
short transfer on control ep
Jul 28 15:42:10 laptop kernel: [ 71.222694] xhci_hcd :05:00.0: WARN:
short transfer on control ep
Jul 28 15:42:10 laptop kernel: [ 71.223179] xhci_hcd :05:00.0: WARN:
short transfer on control ep
Jul 28 15:42:10 laptop kernel: [ 71.223968] xhci_hcd :05:00.0: WARN:
short transfer on control ep
Jul 28 15:42:10 laptop kernel: [ 71.224100] usb 2-2: New USB device found,
idVendor=04a9, idProduct=318d
Jul 28 15:42:10 laptop kernel: [ 71.224105] usb 2-2: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
Jul 28 15:42:10 laptop kernel: [ 71.224108] usb 2-2: Product: Canon Digital
Camera
Jul 28 15:42:10 laptop kernel: [ 71.224110] usb 2-2: Manufacturer: Canon Inc.
Jul 28 15:42:10 laptop kernel: [ 71.224113] usb 2-2: SerialNumber:
1EF8D70C03F5438E9ECF20AA171D4D6A
Jul 28 15:42:10 laptop kernel: [ 71.224225] usb 2-2: ep 0x81 - rounding
interval to 32768 microframes, ep desc says 0 microframes
Jul 28 15:42:10 laptop kernel: [ 71.224228] usb 2-2: ep 0x2 - rounding
interval to 32768 microframes, ep desc says 0 microframes
Jul 28 15:42:41 laptop kernel: [ 102.805200] usb 2-2: USB disconnect, device
number 2
Jul 28 15:44:56 laptop kernel: [ 237.353538] usb 4-1.2: USB disconnect, device
number 3
Jul 28 15:44:56 laptop acpid: input device has been disconnected, fd 9
I don't get the short transfer or rounding interval messages when I plug it
into the 2.0 port.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-2-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages gphoto2 depends on:
ii libc6 2.13-33
ii libcdk5 5.0.20060507-4
ii libexif12 0.6.20-3
ii libgphoto2-2 2.4.14-2
ii libgphoto2-port0 2.4.14-2
ii libncurses5 5.9-10
ii libpopt0 1.16-7
ii libreadline6 6.2-8
gphoto2 recommends no packages.
Versions of packages gphoto2 suggests:
pn gthumb none
pn gtkam none
-- no debconf information
___
Pkg-phototools-devel mailing list
Pkg-phototools-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-phototools-devel
[Pkg-phototools-devel] (no subject)
Do you need a loan? if yes, contact us for more info.___ Pkg-phototools-devel mailing list Pkg-phototools-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-phototools-devel
