Re: Bug#639535: ITP: libdebian-copyright-perl -- perl module to parse, merge and write Debian copyright files

[Nicholas Bamber]

CPAN bug: http://rt.cpan.org/Ticket/Display.html?id=70544

On 28/08/11 06:19, Charles Plessy wrote:
> Le Sat, Aug 27, 2011 at 10:08:55PM +0100, Nicholas Bamber a écrit :
>>
>> * Package name: libdebian-copyright-perl
>>   Version : 0.1
>>   Upstream Author : Nicholas Bamber 
>> * URL : http://search.cpan.org/dist/Debian-Copyright/
>> * License : GPL-2+
>>   Programming Lang: Perl
>>   Description : perl module to parse, merge and write Debian
>> copyright files
>>
>> Debian::Copyright can be used for the representation, manipulation and
>> merging of Debian copyright files in an object-oriented way. It provides
>> easy
>> reading and writing of the debian/copyright file found in Debian source
>> packages.
> 
> Dear Nicholas,
> 
> thanks for producing this parser.  Perhaps the description could include the
> keywords “machine-readable” and “DEP 5” to make it easier to find.
> 
> By the way, since the version of DEP 5 that is distributed in the 
> debian-policy
> package uses extensively the word “paragraph” instead of “stanza”, perhaps you
> could either update the terminology in your documentation or add a note that
> stanza and parargraph are synonymous. 
> 
> Have a nice day,
> 


-- 
Nicholas Bamber | http://www.periapt.co.uk/
PGP key 3BFFE73C from pgp.mit.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/4e5a02fe.4060...@periapt.co.uk

Re: getting permission denied with shmat() as non-root

[Bastian Blank]

On Sat, Aug 27, 2011 at 08:44:41PM -0400, Timothy Stotts wrote:
> /proc/config.gz reveals that SYSVIPC is indeed compiled into the Linux
> kernel of the Debian system.

The Debian kernels don't include support for /proc/config.gz.

> How can I diagnose the program on the Debian system?

strace. Also you may want to compile a minimal program that shows the
error.

> I read on the Internet that this may have something to do with Linux
> Capabilities settings?

Linux limits shared memory usage for non-root users. Not sure how
exactly.

Bastian

-- 
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3


-- 
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/20110828101049.ga22...@wavehammer.waldi.eu.org

Re: getting permission denied with shmat() as non-root

[Peter Miller]

On Sat, 2011-08-27 at 20:44 -0400, Timothy Stotts wrote:
> I am using ftok(), shmget(), shmat() to obtain a small quantity of
> shared memory for the application. As root, the shmat() function
> succeeds on the embedded system. However, on the Debian system the
> shmat() function returns -1 with an error code of EACCES, indicating
> permission denied.

This means that the shared memory exists, or you would get EINVAL.
The ipcs command may be used to list information about shared memory,
and other ipc facilities.  Try using ipcs(1) to see if there is a an
owner and/or permissions mismatch for the shmid you are using.


-- 
Peter Miller 


--
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/1314529860.2648.15.camel@hawk

Re: [dd-list] Please use Architecture: linux-any

[Wouter Verhelst]

On Sat, Aug 20, 2011 at 01:11:40AM +0200, Samuel Thibault wrote:
>ntfs-3g

I was under the impression that ntfs-3g was a FUSE implementation, which
should in theory work on kFreeBSD too. But don't take my word for it :-)

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20110828112738.gj14...@grep.be

Bug#639583: ITP: herbstluftwm -- manual tiling window manager for X11

[Christoph Egger]

Package: wnpp
Severity: wishlist
Owner: Christoph Egger 

* Package name: herbstluftwm
  Version : 0.0~git
  Upstream Author : Thosten Wißmann thorsten-wissmann.de>
* URL : http://wwwcip.cs.fau.de/~re06huxa/herbstluftwm/
* License : Simplified BSD
  Programming Lang: C, sh
  Description : manual tiling window manager for X11

 In herbstluftwm the layout is based on splitting frames into subframes
 which can be split again or can be filled with windows, Tags (or
 workspaces or virtual desktops or ...) can be added/removed at
 runtime. Each tag contains an own layout and exactly one tag is viewed
 on each monitor. The tags are monitor independent.
 .
 It is configured at runtime via ipc calls from herbstclient. So the
 configuration file is just a script which is run on startup.



-- 
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/20110828120031.13633.21748.report...@hepworth.siccegge.de

OS for Mobile phones.

[Suresh Ramanujam]

Hi,

I am looking to make OS for mobile phones on Linux platform. Can Debian be
of any use?

Regards,
Suresh.R

Re: OS for Mobile phones.

[Neil Williams]

On Sun, 28 Aug 2011 17:20:17 +0530
Suresh Ramanujam  wrote:

> Hi,
> 
> I am looking to make OS for mobile phones on Linux platform. Can Debian be
> of any use?

Don't see why not but it depends on the amount of storage available on
device and what functionality needs to be supported with software
outside Debian (e.g. non-free stuff).

If space is an issue, look at Emdebian Grip which is 40% smaller but
binary-compatible with Debian which simplifies debugging.

http://www.emdebian.org/grip/

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpz8rCSXJSQE.pgp
Description: PGP signature

Re: OS for Mobile phones.

[Paul Wise]

On Sun, Aug 28, 2011 at 12:50 PM, Suresh Ramanujam wrote:

> I am looking to make OS for mobile phones on Linux platform. Can Debian be
> of any use?

A Debian derivative (Maemo) has been shipped by Nokia on the N900
phone, the N950 phone (developer only) and will probably be shipped on
the N9 when it is released.

Debian itself runs on the OpenMoko FreeRunner phone with an external kernel.

People have put Debian chroots on various Android devices and even run
Linux with a Debian rootfs on devices like the iPhone.

It would be great if more folks were interested in and working on
getting Debian running on their smartphones, some ideas for how to go
about that are available here:

http://wiki.debian.org/Smartphone

If anyone has contacts at smartphone manufacturers it might be an
interesting idea to get hardware samples to interested and capable
developers.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6Evh66G9OLRfMZrn+p-Tznz-QYBSho7KmJk+Fai=qs...@mail.gmail.com

Re: getting permission denied with shmat() as non-root

[Adam Borowski]

On Sat, Aug 27, 2011 at 08:44:41PM -0400, Timothy Stotts wrote:
> on the Debian system the shmat() function returns -1 with an error code of
> EACCES, indicating permission denied.  The embedded system does not have
> shm_open(), otherwise I would use that.

Other folks in this thread provided better ways to solve this, but if
everything else fails, you can check the presence of shm_open() with
autoconf (if not defined) or at runtime (if ENOSYS) and use one or the
other in your program.

-- 
1KB // Yo momma uses IPv4!


-- 
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/20110828130142.ga17...@angband.pl

Re: combined dependencies?

[Carsten Hey]

* Michael Tautschnig [2011-08-24 14:31 +0200]:
> > Its not any header package: dkms needs the _appropriate_ header
> > package matching the installed kernel package. If
> > linux-image-2.6.39-1-amd64 is installed, then dkms needs
> > linux-headers-2.6.39-1-amd64.  If linux-image-3.0-1-amd64 is
> > installed in parallel, then dkms needs linux-headers-3.0-1-amd64,
> > too.
> >
> > Its just an example, anyway.
>
> Isn't all you want (with l-i-1 = linux-image-2.6.39-1-amd64, l-h-2 =
> linux-headers-3.0-1-amd64, etc.)
>
> Depends: (l-i-1, l-h-1) | (l-i-2, l-h-2) | ...

The above depends line does not ensure that "the _appropriate_ header
package" is installed since an old image and an old header would satisfy
the dependency.


Given that I have linux-image-3.14 and linux-image-3.20 installed, but
not dkms nor any header package, installing dkms would force me to
install in one of the above cases _any_ header package matching an
installed kernel and in the other one to install _all_ header packages
matching an installed kernel.

If linux-headers-3.14 wouldn't be available in Debian anymore, the
originally proposed combined dependencies would force me to remove
linux-image-3.14 if I install dkms.  Do we really want to force users to
remove old kernel images (which they would possibly like to keep as
fallback) if they install dkms the first time?

What you proposed does not lead to forced removals of old kernel images,
but, as already mentioned, it does not ensure the appropriate header
being installed.


Carsten


-- 
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/20110828132306.ga29...@furrball.stateful.de

Re: Bug#639420: ITP: xpra -- tool to detach/reattach running X programs

[Miguel Landaeta]

On Sat, Aug 27, 2011 at 3:28 PM, Timo Juhani Lindfors
 wrote:
> Miguel Landaeta  writes:
>> You could check at http://vasks.debian.org/~nomadium-guest/debian/unstable/,
>
> should I ask Antoine (from upstream) to link to these packages or is it
> too early?

They work for me between two workstations running sid.
I don't see a problem with linking to them, the more feedback received
the better.

I guess we can continue the conversation off-list, we are already off-topic
for debian-devel.

Cheers,

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche


-- 
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/caea1cyra6mdkmo670jwdox6e86x9xgmtafec5ofwrnvsra+...@mail.gmail.com

Re: autopkgtest-devel list (DEP8 etc.)

[Yaroslav Halchenko]

Thank you Ian,

could you make it world rX (so it would appear on http://git. and becomes
available through git://), and add me to the group just in case:

$> cd /git/autopkgtest/
-bash: cd: /git/autopkgtest/: Permission denied
total 20
4 0001-addressing-the-rename-of-matlab-into-matlab-support.patch  4 bin/  4 
incoming/  4 mrsetup  4 proj/

$> ls -ld /git/autopkgtest/
4 drwxrws--- 3 root scm_autopkgtest 4096 Jul 30 19:00 /git/autopkgtest/

Thanks in advance,

On Sat, 27 Aug 2011, Ian Jackson wrote:

> The new autopkgtest-devel list is now open for business at
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/autopkgtest-devel
> If you're interested in autopkgtest please subscribe to it.  
> I'm going to stop sending emails to these ad-hoc CC lists from now on.

> I've also just uploaded autopkgtest 2.0.1, which contains a number of
> fixes mostly from Timo Lindfors (thanks, Timo!)

> The new git tree on alioth is here:
>git+ssh://git.debian.org/git/autopkgtest/autopkgtest.git
> and I have pushed the latest version there.

> I've set the maintainer for the autopkgtest package to the devel list,
> with just myself in the uploaders for now.  Please feel free to NMU if
> you think it's appropriate, or let me know if you'd like to properly
> join the package team.

> Thanks for your attention and interest,
> Ian.
-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
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/20110828153218.gh5...@onerussian.com

Re: gclcvs: Should this package be orphaned (or removed)?

[Niels Thykier]

reassign 637058 wnpp
severity 637058 normal
retitle 637058 O: gclcvs -- GNU Common Lisp compiler, CVS snapshot
thanks

Hi,

Since the original maintainer has not argued against this and is not (to
my knowledge) on vacation, I am hereby orphaning gclcvs (and gclcvs-doc).

The full description of the package is:

"""
GNU Common Lisp compiler, CVS snapshot

GNU Common Lisp (GCL) is a Common Lisp compiler and interpreter
implemented in C, and complying mostly with the standard set forth in
the book "Common Lisp, the Language I". It attempts to strike a useful
middle ground in performance and portability from its design around C.

This package contains the Lisp system itself. Documentation is provided
in the gclcvs-doc package.
"""

If no one picks this package up soon (within 14 days give or take) I
will push for its removal on the grounds that it is unmaintained and RC
buggy.

~Niels


On 2011-08-08 09:43, Niels Thykier wrote:
> Package: gclcvs
> Severity: serious
> 
> Hi
> 
> I noticed this package have two RC bugs that appears to have gotten
> no attention since March and April (repsectively).  Furthermore it
> was removed from testing on the 3rd of July due to #618127.
> 
> If you still maintain this package and have issues with fixing the
> RC bugs, please tag them "help" or/and ask for help on
> debian-devel@lists.debian.org.
>   Alternatively, if you are semi-busy now, consider filing a RFH against
> wnpp to request a co-maintainer.
> 
> Please note that if you do reply within 14 days time, I will assume
> you have lost interest in the package and put it up for adoption.
> 
> ~Niels
> 
> 


-- 
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/4e5a7384.30...@thykier.net

Re: autopkgtest-devel list (DEP8 etc.)

[Stefano Zacchiroli]

On Sat, Aug 27, 2011 at 12:38:05PM +0100, Ian Jackson wrote:
> The new autopkgtest-devel list is now open for business at
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/autopkgtest-devel
> If you're interested in autopkgtest please subscribe to it.  
> I'm going to stop sending emails to these ad-hoc CC lists from now on.

That's great, I've just subscribed to it.

> I've set the maintainer for the autopkgtest package to the devel list,
> with just myself in the uploaders for now.  Please feel free to NMU if
> you think it's appropriate, or let me know if you'd like to properly
> join the package team.

A few extra notes for the random lurker interested in this topic. During
DebConf11 we've had a BoF covering various Debian-related testing topics
[1], including autopkgtest. But beside the talking, the big news is that
Ian has hacked quite a bit on autopkgtest itself and removed all the
bitrot accumulated over the years. It's now usable and people can play
with it. For the related specs, people can look at the package
documentation or at .

The next big enabler we now need to make people use it is a machine
periodically running tests of packages available in the archive. I've
hardware available for that, but I could use some help from an
interested devop to set it up.

Cheers.

[1] http://penta.debconf.org/dc11_schedule/events/764.en.html
-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: gclcvs: Should this package be orphaned (or removed)?

[Christoph Egger]

Hi!

Niels Thykier  writes:
> If no one picks this package up soon (within 14 days give or take) I
> will push for its removal on the grounds that it is unmaintained and RC
> buggy.

  Fortunately there's a good alternative here as this is a snapshotting
package for software actually maintained well inside debian (gcl) so the
only thing we'll miss is regularly updated snapshots.

Regards

Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer


-- 
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/87ipphqsfp@hepworth.siccegge.de

Re: dar-static build failure

[Brian May]

On 27 August 2011 06:38, Henrique de Moraes Holschuh  wrote:
> And I do think it is at least a serious bug for libgpg-error-dev to drop its
> static lib when there are rdepends that require it (dar).  But I am not sure
> about this one.

The documentation says "makes unrelated software on the system (or the
whole system) break" for critical. I don't think this is critical...

For serious, it says "is a severe violation of Debian policy (roughly,
it violates a must or required directive), or, in the package
maintainer's or release manager's opinion, makes the package
unsuitable for release" however I don't think this is a violation of
Debian policy so just sure I can justify serious either.

http://www.debian.org/Bugs/Developer#severities
-- 
Brian May 


--
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/caa0zo6dzrq4fiqvl43vird-lgskf+nj9mo9zvd2whwvdhnr...@mail.gmail.com

Re: dar-static build failure

[Henrique de Moraes Holschuh]

On Mon, 29 Aug 2011, Brian May wrote:
> On 27 August 2011 06:38, Henrique de Moraes Holschuh  wrote:
> > And I do think it is at least a serious bug for libgpg-error-dev to drop its
> > static lib when there are rdepends that require it (dar).  But I am not sure
> > about this one.
> 
> The documentation says "makes unrelated software on the system (or the
> whole system) break" for critical. I don't think this is critical...
> 
> For serious, it says "is a severe violation of Debian policy (roughly,
> it violates a must or required directive), or, in the package
> maintainer's or release manager's opinion, makes the package
> unsuitable for release" however I don't think this is a violation of
> Debian policy so just sure I can justify serious either.
> 
> http://www.debian.org/Bugs/Developer#severities

Well, it makes other related packages FTBFS.   That warrants either serious
or grave, as it breaks other packages in a way that is considered a serious
bug.  It *also* either makes it unsuitable for release, or make directly
related packages unsuitable for release.  Again, enough for a "serious" bug.

In any case, it is nasty enough that it justifies a delayed NMU restoring
the proper static library.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20110829002034.ga26...@khazad-dum.debian.net

Maintainers, porters, and burden of porting

[Lucas Nussbaum]

TL;DR: I think that we should have a discussion about the respective
roles & responsibilities of maintainers and porters with regard to
porting.

Release team, there's a question for you regarding ruby1.9.1 in the last
paragraph.



Hi,

First, I'd like to say that I'm very proud of the fact that Debian
supports so many architectures, and even non-linux ports like kfreebsd.
And that Debian infrastructure is used to support unofficial
architectures such as Debian GNU/Hurd.

However, I'm the maintainer of Ruby. It's kind of special, because:
(1) it uses threads intensively (Ruby threads are mapped to pthreads,
and are routinely used in Ruby programs)
(2) it has a rather huge test suite, that is run at build time
As a result, building ruby1.9.1 tends to detect bugs in the toolchain,
the libc or the kernel, especially on architectures such as hppa or
kfreebsd-* which are a bit "different". I spent my week-end
investigating ruby1.9.1 issues on kfreebsd, sparc, and ia64.

My problem is that I have the impression that some ports are a bit on
the 'experimental' side. For some ports, we use compiler defaults that
are not supported by upstream (sparc), or are the sole users+maintainers
of key packages (it was the case with hppa, which was not using NPTL
when all others architectures were using it, and it is the case for the
libc with Debian GNU/kFreeBSD).

While it's nice that Debian supports such experiments, and while it
generally helps making Debian better by detecting and fixing bugs that
could eventually affect key architectures, I think that we have a
problem when it gets in the way of progress on the architectures that
95%+ of our uses use.

I have the impression that in many cases, maintainers are totally fine
with ports as long as they don't interfere with their work. The
toolchain on ports is generally able to generate code, and when it fails
to do so (ICEs!), toolchain maintainers are usually quick to react.
However, for most of the packages, there's no proof that the generated
code (and the generated packages) actually work.

However, issues such as miscompilation or broken syscall or libc
semantics are largely undetected. To illustrate this, you can have a
look at #635126 (miscompilation on armel and sparc) and #639658
(forks+threads fun on kFreeBSD, derived from #593139).

With the push for more testing (think autopkgtest), it's likely that we
will run into more bugs. Once an architecture is accepted as an official
architecture in Debian, 'experimental' architectures start blocking
packages migration to testing, and it becomes a problem for the
maintainer. I sometimes have the impression that I'm 'taken as hostage'
by porting issues, because it seems that if I don't fix porting issues
myself, nobody will do, and my package won't migrate to testing.

I think that we should clarify roles and responsibilities. I
know that manpower is scarse for some ports, but if it's up to
maintainers to do the porting work on their own, maybe we should instead
find a way that allows Debian to support those ports, without putting
them in a position to block or slow down other development tasks.

I'd like to reinforce the fact that it's the porters' responsibility 
to investigate porters issues, and propose the following
responsibilities:
(1) It is the responsibility of porters to:
- track architecture-specific bugs (build failures, toolchain
  issues, etc)
- investigate and solve such bugs
(2) It is the responsibility of maintainers to help porters as much
as possible
(3) When porters are failing to do (1), we should investigate ways to
continue to support these ports without releasing them as stable
architectures.

Question for the release team:
We might chose to make ruby1.9.1 the default ruby implementation for
wheezy (instead of ruby1.8).  I still hope that all porting issues
affecting ruby1.9.1 will be resolved.
But if it's down to those four choices, what should I do in a couple of
weeks, when the new upstream release will be available?
(1) not upload the next ruby release to unstable until porting issues
are fixed
(2) disable the test suite on architectures where it fails, so that the
package can build and migrate to testing (but it will be completely
broken, which might annoy DSA, e.g because of puppet)
(3) request removal of ruby binaries on architectures where it fails to
build
(4) orphan ruby1.9.1 ;)

Thanks,

- Lucas


-- 
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/20110829065834.gb27...@xanadu.blop.info