Bug#697835: ITP: mruby -- lightweight implementation of the Ruby language

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: mruby
  Version : 1.0.0
  Upstream Author : mruby developers
* URL : https://github.com/mruby/mruby
* License : MIT
  Programming Lang: C, Ruby
  Description : lightweight implementation of the Ruby language

mruby is the lightweight implementation of the Ruby language
complying to the ISO standard.
This can be linked and embedded within your application.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130110081452.4003.8479.reportbug@chimagu

Packages with incomplete .md5sum files

[Andreas Beckmann]

Hi,

the following packages from wheezy ship files that are excluded from 
the .md5sums file:

  gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/.gacl
  gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/gridsitefoot.txt
  gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/gridsitehead.txt
  libreoffice-common: FILE WITHOUT MD5SUM 
/var/lib/libreoffice/share/config/javasettingsunopkginstall.xml
  nfs-common: FILE WITHOUT MD5SUM /var/lib/nfs/state
  nfs-kernel-server: FILE WITHOUT MD5SUM /var/lib/nfs/etab
  nfs-kernel-server: FILE WITHOUT MD5SUM /var/lib/nfs/rmtab
  nfs-kernel-server: FILE WITHOUT MD5SUM /var/lib/nfs/xtab
  r-base-core-dbg: FILE WITHOUT MD5SUM /usr/lib/debug/usr/bin/Rscript
  r-base-core-dbg: FILE WITHOUT MD5SUM /usr/lib/debug/usr/lib/R/bin/Rscript
  r-base-core: FILE WITHOUT MD5SUM /usr/bin/R
  r-base-core: FILE WITHOUT MD5SUM /usr/bin/Rscript
  r-base-core: FILE WITHOUT MD5SUM /usr/lib/R/bin/Rscript
  r-base-core: FILE WITHOUT MD5SUM /usr/lib/R/etc/Renviron.ucf
  r-base-core: FILE WITHOUT MD5SUM /usr/share/R/doc/html/packages.html
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/backdoorports.dat
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/i18n/cn
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/i18n/de
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/i18n/en
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/i18n/zh
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/i18n/zh.utf8
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/mirrors.dat
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/programs_bad.dat
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/suspscan.dat

For sid there are additionally:

  pcp: FILE WITHOUT MD5SUM /var/lib/pcp/config/pmie/config.default
  pcp: FILE WITHOUT MD5SUM /var/lib/pcp/config/pmlogger/config.default
  pcp: FILE WITHOUT MD5SUM /var/lib/pcp/config/pmlogger/crontab

There are also several aspell and ispell dictionary hashes affected by 
this bug, see #690216 for a list of packages and files. What needs to 
happen there is quite clear, so I excluded them from this list.

Excluding shipped files from .md5sums looks seriously wrong for files 
in /usr and at least questionable in /var/lib.

Such excludes were probably added to work around "debsums reports a 
modified file in $pkg" bugs, but that is the wrong approach. If a state 
file (in /var/lib) is shipped by the package and actively modified by 
the package, it will be overwritten on every upgrade. Instead of 
shipping the file maintainer scripts (and maybe triggers) should be 
used to create/update them on package installation/upgrade and clean 
them up during remove/purge.

How should we proceed with these packages? Should I file bugs? With 
which severity?


Andreas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50ee7a12.1030...@abeckmann.de

Re: debian/* license of non-free packages

[Markus Koschany]

Hi Nick,

On Thu, 10. Jan 05:35 Nick Andrik  wrote:
[...] 
> My main question is what kind of license should I specify in
> debian/copyright for debian/* ?
> If we assume that the packagers who have worked on this package during
> its lifetime can agree to a license for the packaging part, what are
> the constraints?
 
I am facing the same problem with my package zangband at the moment. The
license is non-free and does not allow copying and distribution for
"profit purposes". I had to update the copyright because of bug 696916
and 696919 and decided to make it clear that the files for debian/* are
free. I had chosen GPL-3+ for these files. 

The package got rejected by the release team who argues that it "is very
likely to make the resulting code undistributable if the debian packaging
includes patches touching the upstream part". [1]

Therefore i have prepared another version and i use the GNU
All-Permissive license now. [2] I hope that this solves the issue but i
haven't got a reply yet. 

On a side note, unace-nonfree also contains patches and the whole
debian directory is made available under the GPL-2+ license.

Maybe a permissive license is better suited then a copyleft license for such
cases.

[1] http://bugs.debian.org/697140
[2] 
http://www.gnu.org/software/texinfo/manual/texinfo/html_node/All_002dpermissive-Copying-License.html


signature.asc
Description: Digital signature

Re: debian/* license of non-free packages

[Jakub Wilk]

* Markus Koschany , 2013-01-10, 11:11:
I am facing the same problem with my package zangband at the moment. 
The license is non-free and does not allow copying and distribution for 
"profit purposes". I had to update the copyright because of bug 696916 
and 696919 and decided to make it clear that the files for debian/* are 
free. I had chosen GPL-3+ for these files.


The package got rejected by the release team who argues that it "is 
very likely to make the resulting code undistributable if the debian 
packaging includes patches touching the upstream part". [1]


Therefore i have prepared another version and i use the GNU 
All-Permissive license now. [2] I hope that this solves the issue but i 
haven't got a reply yet.


On a side note, unace-nonfree also contains patches and the whole 
debian directory is made available under the GPL-2+ license.


Maybe a permissive license is better suited then a copyleft license for 
such cases.


s/Maybe/Sure enough/

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130110110857.ga1...@jwilk.net

Bug#697849: ITP: libtest-command-simple-perl - Perl module to test external commands

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist
Owner: Joost van Baal-Ilić 

* Package name: libtest-command-simple-perl
  Upstream Author : Darin McBride 
* URL : http://search.cpan.org/dist/Test-Command-Simple/
* License : Perl (GPL or Artistic)
  Programming Lang: Perl
  Description : Perl module to test external commands
 A test module intended to simplify testing of external commands.
 It does so by running the command under IPC::Open3, closing the stdin
 immediately, and reading everything from the command's stdout and stderr.
 It then makes the output available to be tested.
 .
 It is not (yet?) as feature-rich as Test::Cmd, however the
 interface to this is much simpler.  Tests also plug directly into the
 Test::Builder framework, which plays nice with Test::More.


Test::Command::Simple is needed for building (during "make test") the validns
package, that one is being worked on at e.g.
https://launchpad.net/~jelu/+archive/validns .

libtest-command-simple-perl will be maintained by myself and Casper Gielen (
capslock2000-guest @ alioth ).

Bye,

Joost




signature.asc
Description: Digital signature

Re: debian/* license of non-free packages

[intrigeri]

Hi,

Paul Wise wrote (10 Jan 2013 05:35:25 GMT) :
> On Thu, Jan 10, 2013 at 12:43 PM, Nick Andrik wrote:

>> The main reason I decided to deal with unrar is because of e-book
>> reader calibre needing the libunrar.so library [1] in order to read
>> CBR files.

> I see.

FWIW, the GNOME archive manager (file-roller) knows how to use unar
since 3.6, which is in experimental. The version in Wheezy does not
(but knows how to use at least the non-free unrar).

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/851udtqjmr@boum.org

Re: debian/* license of non-free packages

[Jonas Smedegaard]

Quoting Markus Koschany (2013-01-10 11:11:30)
> Hi Nick,
> 
> On Thu, 10. Jan 05:35 Nick Andrik  wrote:
> [...] 
> > My main question is what kind of license should I specify in
> > debian/copyright for debian/* ?
> > If we assume that the packagers who have worked on this package 
> > during its lifetime can agree to a license for the packaging part, 
> > what are the constraints?
>  
> I am facing the same problem with my package zangband at the moment. 
> The license is non-free and does not allow copying and distribution 
> for "profit purposes". I had to update the copyright because of bug 
> 696916 and 696919 and decided to make it clear that the files for 
> debian/* are free. I had chosen GPL-3+ for these files.
> 
> The package got rejected by the release team who argues that it "is 
> very likely to make the resulting code undistributable if the debian 
> packaging includes patches touching the upstream part". [1]
> 
> Therefore i have prepared another version and i use the GNU 
> All-Permissive license now. [2] I hope that this solves the issue but 
> i haven't got a reply yet.
> 
> On a side note, unace-nonfree also contains patches and the whole 
> debian directory is made available under the GPL-2+ license.
> 
> Maybe a permissive license is better suited then a copyleft license 
> for such cases.

I agree that patches need be compatible with the code the patches are 
applied onto, which for some non-free works cannot be a copyleft one.  
But you may not be copyright holder of said patches so cannot ahead 
choose a liberal license either.

To me it makes sense to always declare a "Files: debian/*" section 
explicitly (except for Debian-native packages), and if patches are 
differently licensed (either because others did the licensing or because 
you did and are forced to license in a certain way to match wher it is 
applied) then additionally add a "Files: debian/patches/*" section.

I always place debian sections as the last Files sections, like this:

Files: *
Copyright: [upstream]
License: [non-free]

...

Files: debian/*
Copyright: [our team]
License: [copyleft]

Files: debian/patches/*
Copyright: [our team or whoever actually holds copyright]
License: [permissive or whatever others actually issued]

(and then I place all License sections below that - I find that easiest 
to read, but that's outside of this discussion).


 - 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: signature

Bug#697854: general: Fail to display video

[Ralph Ronnquist]

Package: general
Severity: important

I just installed a fresh Debian 6.0, and got the problem that video doesn't
show, specifically in skype (neither preview nor call) and cheese (preview).

The webcam appears to work fine, since it shows up at the remote end on skype
call (but I see nothing here), and cheese captures pictures nicely.

Also, when I ssh from another host with ForwardX11, then skype (both preview
and call) and cheese preview show video on that host.

Thus, I'm guessing on something with X but don't know where or what.

The host is a Sony Vaio Z with:
00:02.0 VGA compatible controller: Intel Corporation Sandy Bridge Integrated
Graphics Controller (rev 09)



-- System Information:
Debian Release: 6.0.6
  APT prefers stable
  APT policy: (900, 'stable'), (400, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130110134403.6652.65911.reportbug@soffa

Bug#697854: marked as done (general: Fail to display video)

[Debian Bug Tracking System]

Your message dated Thu, 10 Jan 2013 15:04:03 +0100
with message-id <201301101504.03808.hol...@layer-acht.org>
and subject line Re: Bug#697854: general: Fail to display video
has caused the Debian Bug report #697854,
regarding general: Fail to display video
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.)


-- 
697854: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697854
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: important

I just installed a fresh Debian 6.0, and got the problem that video doesn't
show, specifically in skype (neither preview nor call) and cheese (preview).

The webcam appears to work fine, since it shows up at the remote end on skype
call (but I see nothing here), and cheese captures pictures nicely.

Also, when I ssh from another host with ForwardX11, then skype (both preview
and call) and cheese preview show video on that host.

Thus, I'm guessing on something with X but don't know where or what.

The host is a Sony Vaio Z with:
00:02.0 VGA compatible controller: Intel Corporation Sandy Bridge Integrated
Graphics Controller (rev 09)



-- System Information:
Debian Release: 6.0.6
  APT prefers stable
  APT policy: (900, 'stable'), (400, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Hi,

On Donnerstag, 10. Januar 2013, Ralph Ronnquist wrote:
> I just installed a fresh Debian 6.0, and got the problem that video doesn't
> show, specifically in skype (neither preview nor call) and cheese
> (preview).

thats neither a general bug in Debian, nor is skype in Debian at all, so 
closing.


cheers,
Holger--- End Message ---

Bug#697854: general: Fail to display video

[Abou Al Montacir]

On Fri, 2013-01-11 at 00:44 +1100, Ralph Ronnquist wrote:
> Package: general
> Severity: important
> 
> I just installed a fresh Debian 6.0, and got the problem that video doesn't
> show, specifically in skype (neither preview nor call) and cheese (preview).
> 
> The webcam appears to work fine, since it shows up at the remote end on skype
> call (but I see nothing here), and cheese captures pictures nicely.
> 
> Also, when I ssh from another host with ForwardX11, then skype (both preview
> and call) and cheese preview show video on that host.
> 
> Thus, I'm guessing on something with X but don't know where or what.
> 
> The host is a Sony Vaio Z with:
> 00:02.0 VGA compatible controller: Intel Corporation Sandy Bridge Integrated
> Graphics Controller (rev 09)

aptitude install libv4l-0:i386
cp skype.desktop /usr/share/applications/skype.desktop

This should fix your issue and probably all those googling for 
skype+debian+webcam

Cheers,


skype.desktop
Description: application/desktop


signature.asc
Description: This is a digitally signed message part

Bug#697854: general: Fail to display video

[Abou Al Montacir]

On Fri, 2013-01-11 at 00:44 +1100, Ralph Ronnquist wrote:
> Package: general
> Severity: important
> 
> I just installed a fresh Debian 6.0, and got the problem that video doesn't
> show, specifically in skype (neither preview nor call) and cheese (preview).
> 
> The webcam appears to work fine, since it shows up at the remote end on skype
> call (but I see nothing here), and cheese captures pictures nicely.
> 
> Also, when I ssh from another host with ForwardX11, then skype (both preview
> and call) and cheese preview show video on that host.
> 
> Thus, I'm guessing on something with X but don't know where or what.
> 
> The host is a Sony Vaio Z with:
> 00:02.0 VGA compatible controller: Intel Corporation Sandy Bridge Integrated
> Graphics Controller (rev 09)

Please install libv4l-0 and copy this launcher
# aptitude install libv4l-0
# cp skype.desktop /usr/share/applications/skype.desktop

This should fix your issue and probably all those googling for 
skype+debian+webcam

Cheers,


skype.desktop
Description: application/desktop


signature.asc
Description: This is a digitally signed message part

Bug#697854: closed by Holger Levsen (Re: Bug#697854: general: Fail to display video)

[Ralph Ronnquist]

Well, as far as I can see it's a problem with the X server software 
rather than anything else, or the particular collection of packages I 
got on that installation. It happens with both cheese and skype, which 
are the things I've tried, while guvcview fails to run completely, with 
the note "Fatal:g_thread NOT supported' (a different problem).


Perhaps you would you be able to direct me to a better place to lodge 
this, if this is the wrong place?


regards,

Ralph.

On 11/01/13 01:09, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the general package:

#697854: general: Fail to display video

It has been closed by Holger Levsen.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Holger 
Levsen  by
replying to this email.





--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50eed47a.6030...@gmail.com

Bug#697854: general: Fail to display video

[Ralph Ronnquist]

I'm afraid I have tried this; I have libv4l-0 installed, and tried the 
LD_PRELOAD variants as well. No luck :-(


The point is that it does work fine when displaying on another host via 
ssh with X11 forwarding (though skype needs LD_PRELOAD). (Possibly plain 
remote X11 as well, but I don't have that set up) This leads me to 
believe there's something with the X server subsystem.


In any case I need help to dig into it.

Ralph.

On 11/01/13 01:43, Abou Al Montacir wrote:

On Fri, 2013-01-11 at 00:44 +1100, Ralph Ronnquist wrote:

Package: general
Severity: important

I just installed a fresh Debian 6.0, and got the problem that video doesn't
show, specifically in skype (neither preview nor call) and cheese (preview).

The webcam appears to work fine, since it shows up at the remote end on skype
call (but I see nothing here), and cheese captures pictures nicely.

Also, when I ssh from another host with ForwardX11, then skype (both preview
and call) and cheese preview show video on that host.

Thus, I'm guessing on something with X but don't know where or what.

The host is a Sony Vaio Z with:
00:02.0 VGA compatible controller: Intel Corporation Sandy Bridge Integrated
Graphics Controller (rev 09)


Please install libv4l-0 and copy this launcher
# aptitude install libv4l-0
# cp skype.desktop /usr/share/applications/skype.desktop

This should fix your issue and probably all those googling for
skype+debian+webcam

Cheers,



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50eed824.9030...@gmail.com

Re: debian/* license of non-free packages

[Svante Signell]

On Thu, 2013-01-10 at 14:18 +0100, Jonas Smedegaard wrote:
> Quoting Markus Koschany (2013-01-10 11:11:30)
> > Hi Nick,
...
> > On a side note, unace-nonfree also contains patches and the whole 
> > debian directory is made available under the GPL-2+ license.
> > 
> > Maybe a permissive license is better suited then a copyleft license 
> > for such cases.
> 
> I agree that patches need be compatible with the code the patches are 
> applied onto, which for some non-free works cannot be a copyleft one.  
> But you may not be copyright holder of said patches so cannot ahead 
> choose a liberal license either.

This is a puzzling question for me: If you are the copyright holder of
patches (they can be substantial) which license should apply? I have not
seen this before, maybe I missed it. This question applies to free as
well as non-free packages.

1) As a Debian patch, not forwarded upstream
2) The Debian Maintainer forwards the patch upstream
3) The patch submitter forwards the patch upstream

The third case might be clear, what about the other two?

> Files: debian/patches/*
> Copyright: [our team or whoever actually holds copyright]
> License: [permissive or whatever others actually issued]




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1357838482.25587.217.ca...@s1499.it.kth.se

Re: debian/* license of non-free packages

[Russ Allbery]

Svante Signell  writes:

> This is a puzzling question for me: If you are the copyright holder of
> patches (they can be substantial) which license should apply?

Whatever license you want to put on it.  However, it's going to need to be
compatible with the upstream license or the resulting patched work will
probably not be redistributable.

> I have not seen this before, maybe I missed it. This question applies to
> free as well as non-free packages.

> 1) As a Debian patch, not forwarded upstream
> 2) The Debian Maintainer forwards the patch upstream
> 3) The patch submitter forwards the patch upstream

> The third case might be clear, what about the other two?

Actually, all of those cases are equivalent, and in all of those cases the
patch author has the option of what license they want to use.

It's conventional (although not entirely legally sound) in the free
software community to just assume that any patch submitted without any
explicit license statement is licensed under the same terms as the
upstream source.  But that's just an assumption, and if upstream is being
legally conservative in their license handling, they would require
explicit statements of license in any patch.  Similarly Debian for patches
that we apply at build time.  And some upstreams are that legally
conservative; ones that require either a copyright assignment or a
contributor agreement, for example, will usually have, somewhere in that
paperwork, an explicit statement concerning licensing that the contributor
agrees to.

But there is a grand tradition of not crossing this T in all cases, and
being more formally precise about it is probably not a good use of project
time.  I for one don't intend to start asking bug submitters about the
license on their included patch unless I have some reason to believe they
don't intend it to be covered by the upstream license; I think that would
be more annoying than helpful.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcb5oskc@windlord.stanford.edu

Re: debian/* license of non-free packages

[Bart Martens]

On Thu, Jan 10, 2013 at 08:43:27AM +0100, Andreas Tille wrote:
> On Thu, Jan 10, 2013 at 06:50:57AM +, Bart Martens wrote:
> > > For the packages I maintain, I now refrain from doing so when the 
> > > contents of
> > > the debian directory are trivial.
> > 
> > I guess you don't bother to claim copyright for trivial debian/* files.
> > 
> > When there is no copyright and license information for the debian/* files, 
> > then
> > this can mean different things.
> 
> From my perspective according to DEP5 it can only mean one thing: The
> license is the same as specified in "Files: *" and you blame the
> copyright holder mentioned in this stanca as copyright holder also for
> debian/*.

That would be a fair assumption, but as long as the author of the debian/*
files hasn't stated this, it's an assumption.

> The latter is no problem for simple debian/* dirs and using
> the same license as the code seems to be reasonable anyway.

Sure, for simplicity it's best to use the same license.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130110173635.ga28...@master.debian.org

Re: debian/* license of non-free packages

[Bart Martens]

On Thu, Jan 10, 2013 at 09:29:07AM -0800, Russ Allbery wrote:
> Actually, all of those cases are equivalent, and in all of those cases the
> patch author has the option of what license they want to use.
> 
> It's conventional (although not entirely legally sound) in the free
> software community to just assume that any patch submitted without any
> explicit license statement is licensed under the same terms as the
> upstream source.

I guess you meant : It's conventional (although not entirely legally sound) in
the free software community to just assume that the copyright of any patch
submitted without any explicit copyright and license statement is transferred
(given) to the copyright holders of the upstream software.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130110175428.gb28...@master.debian.org

Re: debian/* license of non-free packages

[Jeremy Stanley]

On 2013-01-10 17:54:28 + (+), Bart Martens wrote:
> I guess you meant : It's conventional (although not entirely
> legally sound) in the free software community to just assume that
> the copyright of any patch submitted without any explicit
> copyright and license statement is transferred (given) to the
> copyright holders of the upstream software.

And in many cases it's convention to expect the patch contributor to
patch the copyright statement of the corresponding files as part of
their contribution, if they feel it's necessary. Many of the
projects I work on expect contributors to do precisely this as a
routine part of nontrivial patch submissions.
-- 
{ WHOIS( STANL3-ARIN ); WWW( http://fungi.yuggoth.org/ );
PGP( 48F9961143495829 ); MUD( kin...@katarsis.mudpy.org:6669 );
FINGER( fu...@yuggoth.org ); IRC( fu...@irc.yuggoth.org#ccl ); }


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130110180117.gs6...@yuggoth.org

Bug#697869: ITP: librrd-simple-perl -- Simple interface to create and store data in RRD files

[Russ Allbery]

Package: wnpp
Severity: wishlist
Owner: Russ Allbery 

* Package name: librrd-simple-perl
  Version : 1.44
  Upstream Author : Nicola Worthington 
* URL : http://search.cpan.org/dist/RRD-Simple/
* License : Apache 2.0
  Programming Lang: Perl
  Description : Simple interface to create and store data in RRD files

RRD::Simple provides a simple interface to RRDTool's RRDs module that
supports creating RRD files and storing data.  It provides a simple
mechanism to create RRD files with a sensible set of default RRA (Round
Robin Archive) definitions, and can dynamically add new data source names
to an existing RRD file.  It is useful for quick storage of data in an
RRD file if you do not need to, nor want to, bother defining custom RRA
definitions.

RRD::Simple does not currently offer a fetch method to retrieve data; for
that, use the RRDs module directly.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130110175949.2984.38340.report...@windlord.stanford.edu

Re: debian/* license of non-free packages

[Stefano Zacchiroli]

On Thu, Jan 10, 2013 at 05:54:28PM +, Bart Martens wrote:
> I guess you meant : It's conventional (although not entirely legally sound) in
> the free software community to just assume that the copyright of any patch
> submitted without any explicit copyright and license statement is transferred
> (given) to the copyright holders of the upstream software.

Nope, that doesn't look conventional at all to me :-)

$usually it is assumed that the copyright belongs to the patch author
(assuming the patch is copyrightable in the first place…), whereas the
license, which is often not declared by the patch author, is assumed to
be the same of the code base you're contributing to.

Of course, your value of $usually might vary.

For those interested in this topic, an interesting debate of this
"convention" happened ~1.5 years ago, as part of the FOSS-wide
discussion on CAA/CLAs. Here are a couple of relevant contributions:

- http://opensource.com/law/11/7/trouble-harmony-part-1
- http://opensource.com/law/11/7/trouble-harmony-part-2

Look for "inbound=outbound" in them.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: debian/* license of non-free packages

[Russ Allbery]

Bart Martens  writes:
> On Thu, Jan 10, 2013 at 09:29:07AM -0800, Russ Allbery wrote:

>> Actually, all of those cases are equivalent, and in all of those cases
>> the patch author has the option of what license they want to use.

>> It's conventional (although not entirely legally sound) in the free
>> software community to just assume that any patch submitted without any
>> explicit license statement is licensed under the same terms as the
>> upstream source.

> I guess you meant : It's conventional (although not entirely legally
> sound) in the free software community to just assume that the copyright
> of any patch submitted without any explicit copyright and license
> statement is transferred (given) to the copyright holders of the
> upstream software.

No, definitely not.  The copyright stays with the original author,
copyright notices nonwithstanding.  (Copyright notices say nothing about
who actually owns the copyright.)  It's not possible to transfer copyright
without legal paperwork (if it's possible to do so at all).

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fw28q4vb@windlord.stanford.edu

hardening for binaries/libraries packages

[Nick Andrik]

I'm trying to work with a source package that builds packages that
includes both binaries and dynamic libraries.
My question is on how to enable hardening in both of them, but PIE
support only in the binary (since libraries use PIC anyway).

My solution so far is something like this:

export DEB_BUILD_MAINT_OPTIONS = hardening=+all
include /usr/share/dpkg/buildflags.mk

include /usr/share/cdbs/1/class/makefile.mk
include /usr/share/cdbs/1/rules/debhelper.mk

# Make sure the library is built without PIE support (it already uses PIC
# since it is shared library)
nopie = $(shell
DEB_BUILD_MAINT_OPTIONS=$(DEB_BUILD_MAINT_OPTIONS),-pie
dpkg-buildflags --get $(1))

build/libunrar0:: CXXFLAGS := -fPIC $(call nopie,CXXFLAGS)
build/libunrar0:: LDFLAGS  := -fPIC $(call nopie,LDFLAGS)
-Wl,-soname,libunrar.so.0
build/libunrar0::
$(DEB_MAKE_INVOKE) lib


This solution has the minor side-effect of requiring "dpkg-dev (>=
1.16.1~)" build-dep since it uses dpkg-builflags for the hardening
options.
Is there another more compact way to achieve this?


Thanks,
Nick

--
=Do-
N.AND


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cann5kotco_g6wv7vt_hds9nmaxw+34a9wubxm9e0+wrkbl-...@mail.gmail.com

Bug#697854: closed by Holger Levsen (Re: Bug#697854: general: Fail to display video)

[Holger Levsen]

reopen 697854
reassign 697854 cheese
thanks
# dear cheese maintainers,
# below is some context, please read the full bug log for full context ;)

Hi Ralph,

On Donnerstag, 10. Januar 2013, Ralph Ronnquist wrote:
> Well, as far as I can see it's a problem with the X server software
> rather than anything else, or the particular collection of packages I
> got on that installation. It happens with both cheese and skype, which
> are the things I've tried, while guvcview fails to run completely, with
> the note "Fatal:g_thread NOT supported' (a different problem).
> 
> Perhaps you would you be able to direct me to a better place to lodge
> this, if this is the wrong place?

as this bug also occurs with cheese, I've reopened and reassigned it there. 
Thanks for your help in tracking this error down!


cheers,
Holger


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201301101915.22595.hol...@layer-acht.org

Processed: Re: Bug#697854: closed by Holger Levsen (Re: Bug#697854: general: Fail to display video)

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reopen 697854
Bug #697854 {Done: Holger Levsen } [general] general: 
Fail to display video
Bug reopened
Ignoring request to alter fixed versions of bug #697854 to the same values 
previously set
> reassign 697854 cheese
Bug #697854 [general] general: Fail to display video
Bug reassigned from package 'general' to 'cheese'.
Ignoring request to alter found versions of bug #697854 to the same values 
previously set
Ignoring request to alter fixed versions of bug #697854 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
697854: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697854
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.135784280431332.transcr...@bugs.debian.org

Re: hardening for binaries/libraries packages

[Simon McVittie]

On 10/01/13 18:02, Nick Andrik wrote:
> I'm trying to work with a source package that builds packages that
> includes both binaries and dynamic libraries.
> My question is on how to enable hardening in both of them, but PIE
> support only in the binary (since libraries use PIC anyway).

Does your library use GNU libtool? If it does, you can just throw in all
of the "hardening" CFLAGS and LDFLAGS, including -fPIE, and it will Do
The Right Thing. libtool knows about the distinction between static
libraries, shared libraries and executables, and between -fPIE and
-fPIC, and will replace -fPIE with whatever is right for the object. See
 for some
examples from a real build log.

If it doesn't use libtool, you have discovered the sort of thing that
led to libtool being written in the first place :-) The easiest way
might be to set separate sets of variables for shared libraries, static
libraries (if you have them) and executables, and patch upstream's build
system to follow what it says in those; or upstream's build system might
well already have suitable variables that it uses to pass -shared, -fPIC
and so on, which you might be able to override on the make command line:
"${DEB_MAKE_INVOKE} libfoo_ldflags='-shared -fPIC $(call
nopie,LDFLAGS)'" or something.

If it doesn't use libtool and you don't want to patch upstream's build
system, you will have to do something like what you quoted. I would
recommend dh-style rules over cdbs for situations like this: it's just
as short, and much much clearer what's going on.

Or, if your package doesn't do anything particularly strange, you might
even be able to get away with setting CXX="libtool --mode=compile g++"
and "LD=libtool --mode=link g++" :-)

Note that if this change targets wheezy, you should not convert from
cdbs to dh7 - but this sort of change seems too intrusive at this stage
of the freeze anyway, and doubly so if you have to do something this
non-obvious.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50ef0ff6.7080...@debian.org

Re: Packages with incomplete .md5sum files

[Michael Gilbert]

On Thu, Jan 10, 2013 at 3:21 AM, Andreas Beckmann wrote:
> Excluding shipped files from .md5sums looks seriously wrong for files
> in /usr and at least questionable in /var/lib.

What is so "serious" about that?  Please no more rc mbf's.

Thanks,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MMB15OkDgtvprN=sjb_tsvynz5xom8vqodukycjvqn...@mail.gmail.com

Re: [cut-team] Time to merge back ubuntu improvements!

[Michael Gilbert]

On Sat, Jan 5, 2013 at 12:36 AM, Thomas Goirand wrote:
> On 01/05/2013 01:28 AM, alberto fuentes wrote:
>> The few people on the list seems happy with it. If this is working
>> well, it needs a little more love on debian.org and a  'testing-cut'
>> link in the repos pointing to latest cut, so it can be set on
>> sources.list and forgotten
>
> Yes, we need to advertize more about CUT. CC-ing debian-www@lists.d.o
> in the hope the www team can link to CUT install instructions from
> our home page.

I probably should have already sent a message a while ago on this, but
yes the monthly snapshots have been put on hiatus during the freeze.
The official d-i betas and release candidates are recommended now so
that they get sufficient testing and feedback before the release.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mp9xiry+t+7rcasfwvjskh8tvwsmey3qx9txj0au1n...@mail.gmail.com

Re: debian/* license of non-free packages

[Andreas Tille]

On Thu, Jan 10, 2013 at 05:36:35PM +, Bart Martens wrote:
> > From my perspective according to DEP5 it can only mean one thing: The
> > license is the same as specified in "Files: *" and you blame the
> > copyright holder mentioned in this stanca as copyright holder also for
> > debian/*.
> 
> That would be a fair assumption, but as long as the author of the debian/*
> files hasn't stated this, it's an assumption.

I would not suggest anybody to do it this way and I explicitely enforce
sponsees to add the "Files: debian/*" section even if they are upstream
just to make things very explicite and clear.  But if I have nothing
explicite I need to assume something and finally a definition

   Files: *

does also match

   Files: debian/*

so what else should it mean if somebody leaves out the latter?  Perhaps
we should state this explicitely at

   http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

to give people a warning about this?
 
Kind regards

   Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130110211412.ga8...@an3as.eu

Re: debian/* license of non-free packages

[Steve Langasek]

On Thu, Jan 10, 2013 at 05:54:28PM +, Bart Martens wrote:
> On Thu, Jan 10, 2013 at 09:29:07AM -0800, Russ Allbery wrote:
> > Actually, all of those cases are equivalent, and in all of those cases the
> > patch author has the option of what license they want to use.

> > It's conventional (although not entirely legally sound) in the free
> > software community to just assume that any patch submitted without any
> > explicit license statement is licensed under the same terms as the
> > upstream source.

> I guess you meant : It's conventional (although not entirely legally
> sound) in the free software community to just assume that the copyright of
> any patch submitted without any explicit copyright and license statement
> is transferred (given) to the copyright holders of the upstream software.

This is a far less common convention... precisely because it's far less
legally sound.  You can make a good faith assumption that someone who's
sending you a patch for inclusion means for it to be under the same license;
but copyright assignments need to be documented.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: debian/* license of non-free packages

[Bart Martens]

On Thu, Jan 10, 2013 at 01:46:52PM -0800, Steve Langasek wrote:
> On Thu, Jan 10, 2013 at 05:54:28PM +, Bart Martens wrote:
> > On Thu, Jan 10, 2013 at 09:29:07AM -0800, Russ Allbery wrote:
> > > Actually, all of those cases are equivalent, and in all of those cases the
> > > patch author has the option of what license they want to use.
> 
> > > It's conventional (although not entirely legally sound) in the free
> > > software community to just assume that any patch submitted without any
> > > explicit license statement is licensed under the same terms as the
> > > upstream source.
> 
> > I guess you meant : It's conventional (although not entirely legally
> > sound) in the free software community to just assume that the copyright of
> > any patch submitted without any explicit copyright and license statement
> > is transferred (given) to the copyright holders of the upstream software.
> 
> This is a far less common convention... precisely because it's far less
> legally sound.  You can make a good faith assumption that someone who's
> sending you a patch for inclusion means for it to be under the same license;
> but copyright assignments need to be documented.

It's what happens in practice when I submit a patch upstream and don't say
anything about my copyright.  Upstream integrates the patch in the upstream
source code and redistributes the result with upstream copyright and license.
I think that this happens quite a lot.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130110215610.gc28...@master.debian.org

Re: debian/* license of non-free packages

[Stefano Zacchiroli]

On Thu, Jan 10, 2013 at 09:56:10PM +, Bart Martens wrote:
> It's what happens in practice when I submit a patch upstream and don't say
> anything about my copyright.  Upstream integrates the patch in the upstream
> source code and redistributes the result with upstream copyright and license.
> I think that this happens quite a lot.

As mentioned already in this thread (by Russ, I think), the declared
copyright owner(s) and the actual, legally valid, copyright owner(s) of
a given contribution are not necessarily the same.

In fact, chasing who are the real copyright owner(s) is a significant
part of copyright litigations, including GPL enforcements. I know a
couple of DDs who have professionally worked on this kind of
activities. I can put you in touch with them if you want to know more
about how, in practice, one find outs who the real copyright owners
are. But the basics are what we can all imagine: inspecting VCS
histories, patch submission to public mailing lists and bug trackers,
etc.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: debian/* license of non-free packages

[Russ Allbery]

Bart Martens  writes:

> It's what happens in practice when I submit a patch upstream and don't
> say anything about my copyright.  Upstream integrates the patch in the
> upstream source code and redistributes the result with upstream
> copyright and license.  I think that this happens quite a lot.

The Berne Convention effectively says that the copyright notice on a file
is meaningless when it comes to determining the copyright holder or
holders for the file's contents.  That was one of the major
standardizations in the Berne Convention: you no longer have to declare or
register copyright in works.  It happens automatically when the work is
created.

I don't know the law in all legal environments, but at least in the United
States, the only legal purpose that the copyright notice serves is that it
makes it difficult or impossible for the defendant to claim inadvertant
violation and it makes additional legal damages possible in a lawsuit.  It
has no bearing on the actual copyright owners of a work and is completely
optional.

The primary reason why Debian cares about copyright notices is that most
of our licenses require their preservation and (as a distant second) it
can make it easier to research contributors if there's some sort of
dispute.  There's no actual legal need for them unless the license
requires them.

In at least US law, and I'm fairly certain EU law as well, unless you have
explicitly signed a legal contract to transfer your copyright interest to
some other party, you still hold the copyright on every creative work that
you've made, including any patches that you've written that qualify as
creative works.  Whether or not you added a copyright, whether or not the
modified files are marked as such, and even if someone else slapped their
copyright notice on it.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lic0liwl@windlord.stanford.edu

Re: debian/* license of non-free packages

[Russ Allbery]

Russ Allbery  writes:

> In at least US law, and I'm fairly certain EU law as well, unless you
> have explicitly signed a legal contract to transfer your copyright
> interest to some other party, you still hold the copyright on every
> creative work that you've made, including any patches that you've
> written that qualify as creative works.  Whether or not you added a
> copyright, whether or not the modified files are marked as such, and
> even if someone else slapped their copyright notice on it.

I should have said here: modulo work for hire.  (That can be seen as just
a particularly common form of legal contract, but at least in the US it's
phrased differently: the copyright isn't transferred, but rather is always
held by the employer in a work-for-hire scenario.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hamoliqe@windlord.stanford.edu

Work-needing packages report for Jan 11, 2013

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 519 (new: 0)
Total number of packages offered up for adoption: 142 (new: 1)
Total number of packages requested help for: 63 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



No new packages have been orphaned, but a total of 519 packages are
orphaned.  See http://www.debian.org/devel/wnpp/orphaned
for a complete list.



The following packages have been given up for adoption:

   nqc (#697553), offered 4 days ago
 Description: Not Quite C compiler for LEGO Mindstorms RCX
 Installations reported by Popcon: 28

141 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 1074 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Installations reported by Popcon: 59741

   asymptote (#517342), requested 1413 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 3862

   athcool (#278442), requested 2998 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 69

   balsa (#642906), requested 473 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 789

   bastille (#592137), requested 887 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 189

   cardstories (#624100), requested 626 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 9

   chromium-browser (#583826), requested 956 days ago
 Description: Chromium browser
 Installations reported by Popcon: 11583

   cloud-init (#693094), requested 59 days ago
 Description: configuration and customization of cloud instances
 Installations reported by Popcon: 8

   debtags (#567954), requested 1074 days ago
 Description: Enables support for package tags
 Installations reported by Popcon: 2462

   doc-central (#566364), requested 1083 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 209

   fbcat (#565156), requested 1093 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 150

   flightgear (#487388), requested 1664 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 809

   freeipmi (#628062), requested 595 days ago
 Description: GNU implementation of the IPMI protocol
 Installations reported by Popcon: 2073

   gnat-4.4 (#539633), requested 1731 days ago
 Description: backport bug fixes from trunk (GCC 4.5)
 Installations reported by Popcon: 2100

   gnat-gps (#496905), requested 1596 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 442

   gnokii (#677750), requested 208 days ago
 Description: Datasuite for mobile phone management
 Installations reported by Popcon: 2181

   gnupg (#660685), requested 325 days ago
 Description: GNU privacy guard - a free PGP replacement
 Installations reported by Popcon: 129264

   golang (#668870), requested 270 days ago
 Description: Go programming language compiler - metapackage
 Installations reported by Popcon: 452

   gpa (#663405), requested 306 days ago
 Description: GNU Privacy Assistant (GPA)
 Installations reported by Popcon: 512

   gradle (#683666), requested 161 days ago
 Description: Groovy based build system
 Installations reported by Popcon: 24

   grub2 (#248397), requested 3167 days ago
 Description: GRand Unified Bootloader
 Installations reported by Popcon: 120573

   hfsprogs (#557892), requested 1142 days ago
 Description: mkfs and fsck for HFS and HFS+ file systems
 Installations reported by Popcon: 1285

   horde4 (#686007), requested 136 days ago
 Description: web-based groupware and other applications

   hotkey-setup (#483107), requested 1689 days ago
 Description: auto-configures laptop hotkeys
 Installations reported by Popcon: 2944

   irssi-scripts (#663577), requested 304 days ago
 Description: collection of scripts for irssi
 Installations reported by Popcon: 1121

   isdnutils (#661110), requested 321 days ago
 Description: ISDN utilities
 Installations reported by Popcon: 7742

   jove (#470185), requested 1768 days ago
 Description: Jonathan's Own Version of Emacs - a compact, power

Bug#697897: RFP: xul-ext-stylish -- a user styles manager for the web

[Paul Wise]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Debian Mozilla Extension Maintainers 
, debian-devel@lists.debian.org

* Package name: xul-ext-stylish
  Version : 1.3.1
  Upstream Author : Jason Barnabe
* URL : http://userstyles.org/
  : https://addons.mozilla.org/en-US/firefox/addon/stylish/
* License : GPLv3
  Programming Lang: XUL & Javascript
  Description : a user styles manager for the web

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#697898: ITP: dtv-scan-tables -- Digital TV scan tables for the DVB-S, DVB-C, DVB-T, and ATSC standards

[Jonathan McCrohan]

Package: wnpp
Severity: wishlist
Owner: Jonathan McCrohan 

* Package name: dtv-scan-tables
  Version : 20130111
  Upstream Author : Manu Abraham 
* URL : http://git.linuxtv.org/dtv-scan-tables.git
* License : LGPL
  Programming Lang: None
  Description : Digital TV scan tables for the DVB-S, DVB-C, DVB-T,
and ATSC standards

Following discussions on linux-media [1], it was decided to split the
dvb-apps tree into one for actual DVB applications, and the other for
DVB and scan files. It is hoped that this will enable users to receive
more up-to-date DVB scan files, perhaps by providing updated versions of
this package via stable point releases.

This split will be coordinated with the current dvb-apps maintainers,
and I will also be maintaining this package as part of the Debian
pkg-vdr-dvb team too.

Jon

[1] 
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/59204


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130111012319.1962.65726.report...@lambda.dereenigne.org

multilib followup: caution about remnant shared library files

[Paul Johnson]

Here's a cautionary heads up on the transition from ordinary to multilib Debian.

I run Debian Wheezy amd64. Some 32 bit applications are installed, and
somehow I came to a point where ia32libs wanted to update and
transition me to a multilib setup. I'm still trying to figure out if
that happened because I accidentally had sid enabled, or not, but I
decided to go ahead and see what happens. The big block of 32bit
support libraries from ia32-libs is replaced by a lot fo i386
packages.

It has been a little interesting to rebuild some local packages, I
think most of that will work itself out.  There are good docs on
re-writing debian packaging for multilib.

But today I found about a serious problem I want to warn any/everybody
about.  The multilib packages will replace files from /usr/lib with
files that go into /usr/lib/x86_64-linux-gnu or
/usr/lib/i386-linux-gnu.  If all goes well, that's the end of it.

However, some packages don't remove their own files (or, at least,
they don't get it done for me).  In the packaging, there are multilib
instructions, to assure the removal of files from /usr/lib when the
new are installed in the new folders. However, some packages
malfunction, and so you are left with the old shared library files.  I
was having a devil of a time building some packages because the build
system was finding libraries that I thought had been removed in
/usr/lib.

I used a handy Debian tool "cruft" to survey the situation, and here
are some of the "abandoned" library files that were left in /usr/lib:

libanl-2.11.2.so
libanl.so.1
libBrokenLocale-2.11.2.so
libBrokenLocale.so.1
libcidn-2.11.2.so
libcidn.so.1
libcrypt-2.11.2.so
libcrypt.so.1
libgcc_s.so.1
libmemusage.so
libnss_compat-2.11.2.so
libnss_compat.so.2
libnss_dns-2.11.2.so
libnss_dns.so.2
libnss_files-2.11.2.so
libnss_files.so.2
libnss_hesiod-2.11.2.so
libnss_hesiod.so.2
libnss_nis-2.11.2.so
libnss_nisplus-2.11.2.so
libnss_nisplus.so.2
libnss_nis.so.2
libpcprofile.so
libresolv-2.11.2.so
libresolv.so.2
libSegFault.so
libthread_db-1.0.so
libthread_db.so.1

Here's what goes wrong when those files are found during the package
build process. The linker notices shared files in /lib or /usr/lib,
but it can't find shlib dependency information on those in /var/
hierarchy (because that hierarchy now shows they are in
/usr/lib/x86_64-linux-gnu.

If you try to compile a package, you will recognize the problem if the
error says

error: no dependency information found for /lib/libnsl.so.1

and it is pointing to a file that is in there, but

$ dpkg -S  /lib/libnsl.so.1

is not owned by a package, and then you notice that there is a newer
version of libnsl.so in /usr/lib/x86_64-linux-gnu.

I'm pretty sure this is right, but I can't rule out the possibility
that some other thing that happened in apt-get or synaptic caused
this.  I also found a big chunk of python numpy stuff was "orphaned"
by package updates.

As I mentioned, the cruft package from Debian was a big help in
finding the problem. All I did was install the package, then

$ cd /tmp
$ sudo /usr/sbin/cruft -d /lib -r report-lib

$ sudo /usr/sbin/cruft -d /usr/lib -r report-usrlib

that cranks out the reports that show whether files are missing or not
valid members of deb packages.
-- 
Paul E. Johnson
Professor, Political Science  Assoc. Director
1541 Lilac Lane, Room 504  Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org   http://quant.ku.edu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caerodj9su8ynsl7jibil9yblotudvty9w8xrzm6vo3tv68_...@mail.gmail.com