Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386
Am Thu, 22 Aug 2013 07:46:55 +0200 schrieb Reinhard Tartler : > That would then make mpg123 export the _64 variants in the library. Is > this the correct behavior, even on systems that do have a 64bit off_t > such as kfreebsd-i386? Your answer seems a bit inconclusive here to me. > > Wouldn't it make sense for mpg123 always export these symbols, even when > they are "only" simple aliases on those archs? Yes, as mpg123 does that successfully on platforms I worked on so far. There are usually 3 parts of the large-file-aware API: 1. without suffix for native setting (32 bit off_t on systems that need _FILE_OFFSET_BITS=64 for 64 bit), possibly wrappers to call the _64 functions 2. with _64 for enabled large-file support (actual function or an alias to native 64 bit) 3. with _32 for those who set _LARGE_FILE_BITS=32, alias to native without suffix You see, this is a royal mess and hopefully agree with me that defining off_t with varying sizes on the same platform as build-time choice is madness. That's why very few libraries even try to handle that correctly. Any of these function names can be an alias, wrapper or actual libmpg123 function. Well, this mess is for me to care for as maintainer. Users are only interested in the symbols with _32 and _64 being present. > > short-time fix for mplayer2 would be to drop _FILE_OFFSET_BITS (undef > > in ad_mpg123.c before loading mpg123.h) as this indeed does not seem to > > be needed on kfreebsd. > > I was considering doing that, but I wonder if that was fix, or a workaround? Well, depends on you considering that unconditional definition of _FILE_OFFSET_BITS in MPlayer builds the proper thing to do;-) Depending on the nature of debian/kfreebsd, making the mpg123 header ignore _FILE_OFFSET_BITS might be a better idea. > > Could someone who works on that one confirm that it always defaults to > > 64 bit off_t? > > I'm not sure if I understand the question, what does "it" refer to? > kfreebsd-i386, mplayer2 or mpg123? The platform kfreebsd-i386. My question is how the large file issue is handled there. The mpg123 build log suggests to me that large file support (64 bit off_t) is the one and only configuration (which would be a good thing, in itself). Is that correct? Since people use mpg123 on "actual" *BSD systems since quite some time now, I suppose that debian/kfreebsd differs from them in that respect, as it does with respect to Linux. The long-term fix would make the mpg123 build aware of that and trigger generation of _64 functions as direct api calls, without suffix as alias to those and _32 wrapper functions that map long int offsets to the 64 bit ones. I cannot promise a time scale to work on that myself, due to RL pressure. One needs to modify configure.ac to check the size of off_t in case of empty _FILE_OFFSET_BITS setting from AC_SYS_LARGEFILE and trigger generation of _64 functions (or, rather _(8*sizeof(off_t) functions) if sizeof(off_t) != sizeof(long). This should only cover modification of configure.ac src/libmpg123/lfs_wrap.c src/libmpg123/lfs_alias.c src/libmpg123/mpg123.h.in to handle an extra macro besides _FILE_OFFSET_BITS to decide for suffix for primary API. It would not be right to just force _FILE_OFFSET_BITS=64 in configure.ac for that case, as this will cause _32 functions mapping 32 bit long int arguments to off_t, which is always 64 bit. And actually, this is the exact problem you already have with the current configure.ac ... only without the benefit of having _64 functions. You need to separate two use cases of mpg123.h: Sorting out the symbols of the libmpg123 build and mapping to the right ones when building a client application. Yeah, I'm convinced now: The mpg123 build is broken right now on this platform, as long as any user decides to define _FILE_OFFSET_BITS. The result will either be unresolved symbols (=64) or undefined behaviour (=32 ... handing 32 bit values into 64 bit arguments). Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386
On Do, Aug 22, 2013 at 00:32:12 (CEST), Thomas Orgis wrote: > Well, those look fine to me: > > checking for size_t... yes > checking for uintptr_t... yes > checking for ssize_t... yes > checking for off_t... yes > checking for int32_t... yes > checking for uint32_t... yes > checking for int16_t... yes > checking for uint16_t... yes > checking size of size_t... 4 > checking size of ssize_t... 4 > checking size of off_t... 8 > checking size of int32_t... 4 > checking size of long... 4 > > The whole point of large file support is to have off_t with 64 bit on a > 32 bit platform. But the lines before these explain some confusion: > > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > > _FILE_OFFSET_BITS is not set for mpg123 build. The normal build should > use 64 bit offsets, but the macro code renaming things to _64 suffix is > not active during mpg123 build, as it depends on that variable. Now, > MPlayer, and also mplayer2 build does that > > > cc [...] -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE > [...] -c -o libmpcodecs/ad_mpg123.o libmpcodecs/ad_mpg123.c > > That is the reason why I added the LFS alias functions. This practice > of enforcing the offset bits also on a 64 bit box prompted the need to > always provide _64 functions even if this is the natic off_t without > large file support hackery. > > The issue at hand is that the AC_SYS_LARGEFILE macro mpg123 uses for > configuring figures that it does not need _FILE_OFFSET_BITS. To sum it > up, here is a quote from configure.ac: > > dnl Detect large file support, enable switches if needed. > AC_SYS_LARGEFILE > dnl If we do have a switch for large files, rename off_t-aware API calls. > dnl Using the file_offset_bits variable here is fine for linux (possibly > Solaris), > dnl Others... we'll have to see. > > I guess kfreebsd counts as "others". One could just use the diagnostic > of the size of off_t and whether it differs from long int ... That would then make mpg123 export the _64 variants in the library. Is this the correct behavior, even on systems that do have a 64bit off_t such as kfreebsd-i386? Your answer seems a bit inconclusive here to me. Wouldn't it make sense for mpg123 always export these symbols, even when they are "only" simple aliases on those archs? > short-time fix for mplayer2 would be to drop _FILE_OFFSET_BITS (undef > in ad_mpg123.c before loading mpg123.h) as this indeed does not seem to > be needed on kfreebsd. I was considering doing that, but I wonder if that was fix, or a workaround? > Could someone who works on that one confirm that it always defaults to > 64 bit off_t? I'm not sure if I understand the question, what does "it" refer to? kfreebsd-i386, mplayer2 or mpg123? Thank you for your very prompt response! Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
RE: DELIVERY OF YOUR DIPLOMTIC CONSIGNMENT BOX!!!
Hello Dear,On behalf of the board and management of Overseas Credit Commission(OCC). London UK, I Mr. Robert Green, the Operations Manager wishes to inform you that your consignment / fund tagged Diplomatic Luggage 122 with Ref: No1226/X42/206 which was deposited in our vault for safe keeping by a Diplomatic courier company(SEA&BIRD) is due for Immediate collection.Be informed that we have concluded all arrangements to deliver your consignment at your door step through diplomatic means. In line with the binding diplomatic consignment delivery policies, kindly furnish us with the following as set forth.A copy of your international passport or any other means of identification as the true consignee. The address where the above cargo/funds should be delivered to and your phone number.List the nearest international airport to your address location. Meanwhile, we urge you to treat the above requirement with utmost urgency to enable us dispense our duties and obligation accordingly thereby allowing us to serve you in a timely fashion. Upon satisfactory receipt of all the above mentioned, you Will be further acquainted with the detailed delivery including information of the diplomat who will accompany your consignment.As always, feel very free to contact us on this email: seaandbirdcour...@gmail.com , should you have any further question as our customer.We pledge our best service at all times.Yours Sincerely,Mr. Robert Green.Foreign Operations ManagerTel: +447035949325 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386
Well, those look fine to me: checking for size_t... yes checking for uintptr_t... yes checking for ssize_t... yes checking for off_t... yes checking for int32_t... yes checking for uint32_t... yes checking for int16_t... yes checking for uint16_t... yes checking size of size_t... 4 checking size of ssize_t... 4 checking size of off_t... 8 checking size of int32_t... 4 checking size of long... 4 The whole point of large file support is to have off_t with 64 bit on a 32 bit platform. But the lines before these explain some confusion: checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no _FILE_OFFSET_BITS is not set for mpg123 build. The normal build should use 64 bit offsets, but the macro code renaming things to _64 suffix is not active during mpg123 build, as it depends on that variable. Now, MPlayer, and also mplayer2 build does that cc [...] -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE [...] -c -o libmpcodecs/ad_mpg123.o libmpcodecs/ad_mpg123.c That is the reason why I added the LFS alias functions. This practice of enforcing the offset bits also on a 64 bit box prompted the need to always provide _64 functions even if this is the natic off_t without large file support hackery. The issue at hand is that the AC_SYS_LARGEFILE macro mpg123 uses for configuring figures that it does not need _FILE_OFFSET_BITS. To sum it up, here is a quote from configure.ac: dnl Detect large file support, enable switches if needed. AC_SYS_LARGEFILE dnl If we do have a switch for large files, rename off_t-aware API calls. dnl Using the file_offset_bits variable here is fine for linux (possibly Solaris), dnl Others... we'll have to see. I guess kfreebsd counts as "others". One could just use the diagnostic of the size of off_t and whether it differs from long int ... short-time fix for mplayer2 would be to drop _FILE_OFFSET_BITS (undef in ad_mpg123.c before loading mpg123.h) as this indeed does not seem to be needed on kfreebsd. Could someone who works on that one confirm that it always defaults to 64 bit off_t? Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#720440: mpg123: mpg123 does not build LFS wrappers on kfreebsd-i386
Package: mpg123 Version: 1.15.3-1 Severity: important Justification: Broken binaries on release architecture kfreebsd-i386 According to the build logs in https://buildd.debian.org/status/fetch.php?pkg=mpg123&arch=kfreebsd-i386&ver=1.15.3-1&stamp=1365806890, the configure script determines that off_t has the size 8, which seems unusual for a 32bit operating system: checking size of off_t... 8 This causes various compiation warnings later: lfs_alias.c: In function 'mpg123_decode_frame_32': lfs_alias.c:123:2: warning: passing argument 2 of 'mpg123_decode_frame' from incompatible pointer type [enabled by default] In file included from lfs_alias.c:49:0: mpg123.h:514:12: note: expected 'off_t *' but argument is of type 'long int *' lfs_alias.c: In function 'mpg123_framebyframe_decode_32': lfs_alias.c:131:2: warning: passing argument 2 of 'mpg123_framebyframe_decode' from incompatible pointer type [enabled by default] In file included from lfs_alias.c:49:0: mpg123.h:523:12: note: expected 'off_t *' but argument is of type 'long int *' lfs_alias.c: In function 'mpg123_feedseek_32': lfs_alias.c:179:2: warning: passing argument 4 of 'mpg123_feedseek' from incompatible pointer type [enabled by default] Also, it breaks the compilation of mplayer2, cf. https://buildd.debian.org/status/fetch.php?pkg=mplayer2&arch=kfreebsd-i386&ver=2.0-701-gd4c5b7f-2&stamp=1377018444 cc -o mplayer command.o [...] libmpcodecs/vd_xanim.o libmpcodecs/vd_xvid4.o -Wl,-z,noexecstack -Wl,-z,relro -L/usr/local/lib -ffast-math -lncurses -lsmbclient -lquvi -lvdpau -lpng -lz -lmng -lz -ljpeg -lungif -lpulse -ljack -lpthread -lrt -lbluray -L/usr/lib/i386-kfreebsd-gnu -ldvdread -ldvdread -lcdio_paranoia -lcdio_cdda -lcdio -lass -lenca -lz -lmad -lvorbis -logg -lspeex -ltheora -logg -lmpg123 -la52 -ldca -lfaad -lbs2b -llcms2 -lavutil -lavcodec -lavformat -lswscale -lpostproc -lavresample -ldv -lxvidcore -lm -lvstream-client -lpthread -ldl -rdynamic -L/usr/lib/i386-kfreebsd-gnu -ldvdnavmini -lpthread -lm -ldirectfb -lXext -lX11 -lpthread -lXss -lXv -lXinerama -lXxf86vm -L/usr/lib/i386-kfreebsd-gnu -lcaca -lSDL -lGL -ldl -llirc_client libmpcodecs/ad_mpg123.o: In function `decode_a_bit': /«PKGBUILDDIR»/libmpcodecs/ad_mpg123.c:278: undefined reference to `mpg123_decode_frame_64' collect2: error: ld returned 1 exit status make[2]: *** [mplayer] Error 1 AFAIU the configure script and the header mpg123.h, the _64 bit vaiants are expected to be present also on kfreebsd-i386. In case this assumption is wrong, then mpg123.h should not alias to the _64 variants on this arch. Thomas, can you comment on what is the right thing to do on kfreebsd-i386? Thanks & Cheers, Reinhard Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: Bug#719928: blender: stale files after upgrade
Processing commands for cont...@bugs.debian.org: > reopen 719928 Bug #719928 {Done: "Matteo F. Vescovi" } [blender] blender: stale files after upgrade Bug reopened Ignoring request to alter fixed versions of bug #719928 to the same values previously set > stop Stopping processing here. Please contact me if you need assistance. -- 719928: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719928 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#719928: blender: stale files after upgrade
reopen 719928 stop Hey Matteo Uhm... On Wed, 2013-08-21 at 09:46 +0200, Matteo F. Vescovi wrote: > > On upgrade one gets these errors: > > Unpacking replacement blender ... > > dpkg: warning: unable to delete old directory > > '/usr/lib/blender/scripts/presets/framerate': Directory not empty > > dpkg: warning: unable to delete old directory > > '/usr/lib/blender/scripts/presets': Directory not empty > The issue here is that those files are replaced by blender-data package > now installing stuff under /usr/share and probably the installation > process didn't know that. Well it's not that easy... 1) dpkg provides means for files being moved from one package to the other,... in which case these errors from above wouldn't appear. 2) Right now (I'm on sid) it doesn't seem the case as if blender-data would contain any /usr/lib/blender stuff. Actually no package seems to have files for that location registered anymore... and it doesn't even exist anymore on my system. So reopening for now :) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
gxtuner 2.1-1 MIGRATED to testing
FYI: The status of the gxtuner source package in Debian's testing distribution has changed. Previous version: 2.0-2 Current version: 2.1-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
klick 0.12.2-2 MIGRATED to testing
FYI: The status of the klick source package in Debian's testing distribution has changed. Previous version: 0.12.2-1 Current version: 0.12.2-2 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
zita-at1_0.2.3-4_sparc.changes ACCEPTED into unstable
Mapping sid to unstable. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 21 Aug 2013 14:57:12 +0200 Source: zita-at1 Binary: zita-at1 Architecture: sparc Version: 0.2.3-4 Distribution: sid Urgency: low Maintainer: Debian Multimedia Maintainers Changed-By: Jaromír Mikeš Description: zita-at1 - JACK autotuner Changes: zita-at1 (0.2.3-4) unstable; urgency=low . * Added icon. Checksums-Sha1: 79bfe5b194a8bca225c92bccfd9707ab42f19e90 55822 zita-at1_0.2.3-4_sparc.deb Checksums-Sha256: 616bd19eef1090528d8ee0d77407877cb493c190917c3f50a0fd9a62cfb8f9a9 55822 zita-at1_0.2.3-4_sparc.deb Files: 1677f83652cdd6e187410c5fc3972b1f 55822 sound optional zita-at1_0.2.3-4_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSFMH0AAoJENu2CT7+FNqbYawP/jb3SndKdVQXfDouEI8HhFnV 9ZJBYffcm9c2AvUisvdJwVvFW9ng8URs9iiHe1n/fVZpIdeGg95YLrzqU0ZCwCtN yWXRTbp7Q4u9DgmcAqZ1RgfRVoHQvZnwPqjtBS2L869p68bWPuRKbjvMe5wwRc2T ZUymLiRtOSUwtPb+frkuG//649h+dhCirHlTnTWapmOinmlt37/pbkzqBXuPwswx Pa8RfTCODIl9UAVsnILTJCD63pioWH6LJUmrHZIUqIvVlSoRCYDz26AwmXY4Z+c2 2mfwa7fGMe/kWBSZxTRh07XTPgZSXKTgB1R/iSZCNILmLMD8FlU43DKKyGzUACys pnmKjwXGP65OPoOfra45vMmeIT+yEAeC+/P9SuticQfqMY35pUNYJ6cucLBG7qjj rbakljM1ZkbIKNv+pRLmVsoWvvjwIQm9DK2INAvhjEkIGzPyVtJ/Yd3QKsrXJOxT sPftPhi+k99S6SkI+3kwI0PrlYHTK6vuhXQhYcAXZ9roiq9bDiroGdJPULzW9/EM HK4S2ytkQcQr5f4E2jpYLY8EXngDMjle9veWaAaoQxEHtdCHHRJF8UKRPcljXB6r /OCLVL/bafpYRqhsCTjoeB2FrZayiXf9QOm8bAOFTqH87PS0Db0F/yNpPZycBJum M5nh2IlHYI1V/9alOEpe =Ojqr -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of zita-at1_0.2.3-4_sparc.changes
zita-at1_0.2.3-4_sparc.changes uploaded successfully to localhost along with the files: zita-at1_0.2.3-4_sparc.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: CC-BY-ND license in debian
2013/8/21 Felyza Wishbringer > CC-BY-ND > > Let's take a short look at this. > > CC, cool, Creative Commons > > BY, You must attribute the work in the manner specified by the author or > licensor, which is fine in v3, and by proxy, 2.0 and 2.5 due to the 4b > clause > that allows redistribution of derivative works under later versions of > the license. > > but > ND, No Derivatives: You may not alter, transform, or build upon this work. > > DFSG states: > Derived Works: The license must allow modifications and derived works, and > must allow them to be distributed under the same terms as the license of > the > original software. > > Obviously that ND (rather than SA) excludes it from Deb, directly. > > If upstream decides to go with CC-BY-SA v3, then that is compatible. ND is > explicitly not. Hope that helps. > > IANAL > Thank you! It is clear now. best regards mira ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
zita-at1_0.2.3-4_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 21 Aug 2013 14:57:12 +0200 Source: zita-at1 Binary: zita-at1 Architecture: source amd64 Version: 0.2.3-4 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers Changed-By: Jaromír Mikeš Description: zita-at1 - JACK autotuner Changes: zita-at1 (0.2.3-4) unstable; urgency=low . * Added icon. Checksums-Sha1: eb414b29bcc9a9af932ee9bb71d09aa193736915 2182 zita-at1_0.2.3-4.dsc 978296bfb4158b00584d5c41e2eb9f4198ed1c03 5464 zita-at1_0.2.3-4.debian.tar.gz 84220c303f956608da53e5a137c17fa5df49603b 56640 zita-at1_0.2.3-4_amd64.deb Checksums-Sha256: 07844568b4724b68fd0d7abe63a1cde7fd788990bad6f1103fb888ab799a 2182 zita-at1_0.2.3-4.dsc 9ce8468989e74b549e94068326d5b7f03a32cc8a97040b036d6bf452a8c8dd5c 5464 zita-at1_0.2.3-4.debian.tar.gz 5db7172c1d1e70b4ad5c3ca06dfb99a1aaa8839a076fad44d8c30c7bce1dde75 56640 zita-at1_0.2.3-4_amd64.deb Files: d23871b5294ffa7068ea41e91a97e4a1 2182 sound optional zita-at1_0.2.3-4.dsc 09dffa0bd8578185a8d22903ad557872 5464 sound optional zita-at1_0.2.3-4.debian.tar.gz 03a285bf4bb4c950899b02c25ff406d4 56640 sound optional zita-at1_0.2.3-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJSFLwIAAoJEFsBlFXiuE+lRvwQALAnr3LCdSQdOdzuapREkZXV Lkw4eMK8+0jywp5OnNsnqJT8U3ruyNkuO4wOeyqOxeV7u+72w+DNCYNa0BoGtWvq YdzVvBlfvoFuHaLH7BBwqMUT49mpzNPCSnK457XjeFY8wDsGrMDBpd1uw2jIMiR3 BQ4J0eoPmJoQ1yEtzucjsMLHRdgJuMhvwSzE1Cx5M+fJfi7PVb8wP8uot4plpYtK 3YbgaixdzvDx4gpZJNG2gteVa9hq+Mus8ggGovPlI8GHOIqQpYfnEcnlK9+L0J0Y C311hlp7J9dSEvdCXIU+AogbhL6dapklVMubrDwLvHKzI2CFx5hmx5IWTuK0dog9 PBSMLB3bzj4T7e0pZ5evUpg/OfKlmBHe39olfsIWKkqqtWUdaV4h+eZZOm6QHm5x jO32zhE/JJENwOI5/4VDisjf90r+iWQLeggv62hU/3uYkPLOm+bibnIYR2ngUhze cfG1IpUEwVXV/4R4YyaS/1HLRO2CL8kjH5jGXNrrp5GGsV3mUgwb0I5nk1zqKHN5 a6Tderb3qWbYkJ/AC6QW9q1PFlQaDd46Oelqr6mudJYkfbBpEpWAXFfX1aRmJ0IO 3zGBufQbrkHiQL/PNXDljLBhkZ+voDmKZPB6/FtnboT0Clai6e3GFTizwAmYqrAh pTvsZ9uw134PjejE++SV =l1il -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of zita-at1_0.2.3-4_amd64.changes
zita-at1_0.2.3-4_amd64.changes uploaded successfully to localhost along with the files: zita-at1_0.2.3-4.dsc zita-at1_0.2.3-4.debian.tar.gz zita-at1_0.2.3-4_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: CC-BY-ND license in debian
On Wed, Aug 21, 2013 at 10:19 PM, Jaromír Mikeš wrote: > > > Hi, > > upstream thinking to release under CC-BY-ND > He would like to have control over derived work. > Is CC-BY-ND license debian friendly? I mean is fine for debian "main"? > Thank you for looking to make software available in Debian. I am not a lawyer, but my understanding is that strictly speaking, even packaging something under CC-BY-ND for Debian may be against the licence. Under the CC-BY-ND licence, it may be that Debian could be considered a "Collective Work", but this seems a little risky. The relevant parts of the Debian Free Software Guidelines[1] are items 3 and 4. I am fairly sure it could not go into main, and I think it is doubtful even for non-free (due to the restriction on derived works). If upstream is keen to have it in major distributions, then maybe a different licence is more appropriate[2]. Hope that helps, Joe [1] http://www.debian.org/social_contract#guidelines [2] https://wiki.debian.org/DFSGLicenses ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: CC-BY-ND license in debian
Hi, upstream thinking to release under CC-BY-ND He would like to have control over derived work. Is CC-BY-ND license debian friendly? I mean is fine for debian "main"? http://creativecommons.org/licenses/by-nd/2.0/ Pls CC me as I am not subscribed to ML. best regards mira ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: CC-BY-ND license in debian
On Wed, Aug 21, 2013 at 8:47 AM, Matteo F. Vescovi wrote: > Hi! > > On Wed, Aug 21, 2013 at 09:44:50AM +0200, Jaromír Mikeš wrote: >> upstream thinking to release under CC-BY-ND >> He would like to have control over derived work. >> Is CC-BY-ND license debian friendly? No, it isn't. The "No Derivative Works" clause makes the work suitable for non-free only. That's just my humble opinion though, please get in touch with debian-legal. Cheers, -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
How To Start Your Own Online Newsletter
Hi, Having an online newsletter could be a nice little way to build your subscribers and potentially sell products to them in the future. Online newsletters usually aren't difficult to start up, as there are very few aspects that need to be completed. With just a few steps, you can be gaining plenty of subscribers within days. How to start your own online newsletter. The first thing you'll need to do is sign up to an email marketing manager account to some of the best companies. There are companies like Aweber who can provide for you the service that you need for getting the perfect email marketing account. Through Aweber, you can get your very own subscription form script, and it's this script which you'll place on your site to get people to type their names and email addresses inside of. Before you place that script on your site, make sure that you create a really nice set of messages that you will automatically send out. So, you can create around 10, 20, and even 50 different messages that you'd like to send out over a period of weeks or even months. This makes list building quite the autopilot income. You can create some nice affiliate offers, and then suddenly make sales day in and day out little by little. To get the most amount of sales, try creating lots of affiliate offers after each email. This will give you the chance to promote on nearly any email that is send out. Newsletters are meant to mainly be helpful and informational, but there's nothing wrong with making one to build your list as an internet marketer. So, try joining Aweber to begin with, and then start adding more and more emails to potentially make more sales. Newsletters aren't easy to do, but it can be hard to do at first. Just stick with it, and you'll see your campaigns grow little by little. Much Success! Jenny PS. Want to get started online buy don't know where to start? Click here for free affiliate templates every month! http://d04260dlqz7mcx46qeicg5pc3o.hop.clickbank.net/ This message was sent by: Jenny Foster 189 Broadway St., New York, NY, 32400, United States. Click HERE to cancel or edit your subscription: http://ebizresponse.com/ar/ar/r.php?s=14057&a=56&k=e85d41afab73605fe3ca18d426320435 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#719928: marked as done (blender: stale files after upgrade)
Your message dated Wed, 21 Aug 2013 09:46:21 +0200 with message-id <20130821074621.GA22002@localhost> and subject line Re: Bug#719928: blender: stale files after upgrade has caused the Debian Bug report #719928, regarding blender: stale files after upgrade to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 719928: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719928 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: blender Version: 2.68a-3 Severity: normal Hi. On upgrade one gets these errors: Unpacking replacement blender ... dpkg: warning: unable to delete old directory '/usr/lib/blender/scripts/presets/framerate': Directory not empty dpkg: warning: unable to delete old directory '/usr/lib/blender/scripts/presets': Directory not empty And stale files/dirs are left over: $ l /usr/lib/blender/scripts/presets/framerate/__pycache__ total 21k drwxr-xr-x 2 root root 4,1k Aug 17 00:14 . drwxr-xr-x 3 root root 4,1k Aug 17 00:14 .. -rw-r--r-- 1 root root 279 Aug 9 00:01 23.cpython-33.pyc -rw-r--r-- 1 root root 279 Aug 9 00:01 29.cpython-33.pyc -rw-r--r-- 1 root root 279 Aug 9 00:01 59.cpython-33.pyc Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.10-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages blender depends on: ii blender-data 2.68a-3 ii fonts-droid 1:4.2.r1-2 ii libavcodec54 9:1.2.2-dmo2 ii libavdevice53 7:0.10.3-dmo1 ii libavformat54 9:1.2.2-dmo2 ii libavutil52 9:1.2.2-dmo2 ii libboost-date-time1.49.0 1.49.0-4 ii libboost-filesystem1.49.0 1.49.0-4 ii libboost-locale1.49.0 1.49.0-4 ii libboost-regex1.49.0 1.49.0-4 ii libboost-system1.49.0 1.49.0-4 ii libboost-thread1.49.0 1.49.0-4 ii libc6 2.17-92 ii libfftw3-double3 3.3.3-5 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.8.1-9 ii libgl1-mesa-glx [libgl1] 9.1.6-2 ii libglew1.71.7.0-3 ii libglu1-mesa [libglu1]9.0.0-1 ii libgomp1 4.8.1-9 ii libilmbase6 1.0.1-6 ii libjack-jackd2-0 [libjack-0.116] 1.9.9.5+20130622git7de15e7a-1 ii libjpeg8 8d-1 ii libjs-jquery 1.7.2+dfsg-3 ii libopenal11:1.14-4 ii libopenexr6 1.6.1-7 ii libopenimageio1.2 1.2.1~dfsg0-3 ii libopenjpeg2 1.3+dfsg-4.6 ii libpng12-01.2.49-4 ii libpython3.3 3.3.2-5 ii libsdl1.2debian 1.2.15-6 ii libsndfile1 1.0.25-7 ii libspnav0 0.2.2-1 ii libstdc++64.8.1-9 ii libswscale2 9:1.2.2-dmo2 ii libtiff4 3.9.7-1 ii libx11-6 2:1.6.1-1 ii libxi62:1.7.2-1 ii libxxf86vm1 1:1.1.3-1 ii python3 3.3.2-13 ii zlib1g1:1.2.8.dfsg-1 blender recommends no packages. Versions of packages blender suggests: pn yafaray-exporter -- no debconf information --- End Message --- --- Begin Message --- On Sat, Aug 17, 2013 at 12:29:04AM +0200, Christoph Anton Mitterer wrote: > Hi. > > On upgrade one gets these errors: > Unpacking replacement blender ... > dpkg: warning: unable to delete old directory > '/usr/lib/blender/scripts/presets/framerate': Directory not empty > dpkg: warning: unable to delete old directory > '/usr/lib/blender/scripts/presets': Directory not empty The issue here is that those files are replaced by blender-data package now installing stuff under /usr/share and probably the installation process didn't know that. Not a real problem, then. Remove those files. The problem won't face again in future upgrades since the installation procedure will keep this structure now. So, I'm closing this bug report. If you consider the issue above described as more important than it is, please feel free to re-open this report. Cheers. -- Matteo F. Vescovi Debian Maintainer GnuPG KeyID: 0x83B2CF7A--- End Message --- ___
Re: CC-BY-ND license in debian
Hi! On Wed, Aug 21, 2013 at 09:44:50AM +0200, Jaromír Mikeš wrote: > upstream thinking to release under CC-BY-ND > He would like to have control over derived work. > Is CC-BY-ND license debian friendly? > > http://creativecommons.org/licenses/by-nd/2.0/ https://wiki.debian.org/DFSGLicenses -- Matteo F. Vescovi Debian Maintainer GnuPG KeyID: 0x83B2CF7A ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
CC-BY-ND license in debian
Hi, upstream thinking to release under CC-BY-ND He would like to have control over derived work. Is CC-BY-ND license debian friendly? http://creativecommons.org/licenses/by-nd/2.0/ thanks mira ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers