Re: is it a DFSG breach or not?
On 08:50 Mon 26 Jan , Stefano Zacchiroli wrote: SZ> On Sat, Jan 24, 2009 at 10:23:33PM +0300, Dmitry E. Oboukhov wrote: >> However it seems that there's no source of this JS in public access, SZ> Why so? SZ> I think this is the key of the issue. sources are found. see http://lists.debian.org/debian-devel/2009/01/msg00589.html :) -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Test suites after build and Build-Depends.
On 26/01/09 at 08:44 +0100, Stefano Zacchiroli wrote: > On Fri, Jan 23, 2009 at 09:12:43PM -0800, Russ Allbery wrote: > > The upcoming wording doesn't add a way to distinguish between build > > dependencies required for the build and ones required for testing. > > I think that was already clear to Charles. What I think he meant is > that once 'notest' is widespread enough, its "natural evolution" would > be a way to distinguish dependencies which belong to tests. What is the real goal of adding Build-Depends-Test: ? This wouldn't help the buildds, as they will install the test build-deps anyway (running the test suite on obscure arches is a really good idea, and often allows to find bugs in dependencies). This wouldn't really help the maintainer either. The download time of build-depends can be easily reduced by using a caching proxy (approx is really easy to setup). The installation time of build-depends only used for tests could be a problem, sure, but you should change your process if you suffer from it. For example, I usually do most of the packaging work in an unclean chroot, and use a clean chroot only for the final build. So dependencies are only installed twice. The goals of "nocheck" are different, and more useful, are bypassing the test suite allows faster builds in all cases. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
On Mon, Jan 26, 2009 at 09:59:04AM +0100, Lucas Nussbaum wrote:
> What is the real goal of adding Build-Depends-Test: ?
[ Note that I'm not pushing for that, but still, for the sake of the
argument ... ]
> The goals of "nocheck" are different, and more useful, are bypassing
> the test suite allows faster builds in all cases.
The goals of Build-Depends-Test are the same of "nocheck": faster
overall build time if you don't care about the test suite. In a sense,
"nocheck" can be complete only with Build-Depends-Test.
Then you can ask in which scenario you might want to skip test suite
to build faster, ... and I don't think buildds match that scenario.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#513092: ITP: pct-support-scripts -- pct support scripts for irc chat, ssh and remote vnc support
Package: wnpp Severity: wishlist Owner: Jelle de Jong I would like to get this program into the debian repository, I will package it and upload it to debian mentors, I will be looking for a sponser and mentor. This package is part of a larger group of packages that will form the pct-desktop-environment that I have been working on. Package name: pct-support-scripts Version : 0.1.1 Upstream Author : Jelle de Jong URL : https://secure.powercraft.nl/svn/packages/trunk/deb/pct-support-scripts/ License : GPLv3+ Programming Lang: BASH Description : pct support scripts for irc chat, ssh and remote vnc support This is a collection of easy scripts developed to provide remote support for Ubuntu and Debian GNU/Linux users. The scripts defaults settings are to be used with the support systems of PowerCraft Technology, but it is easy to use the scripts options and configuration files to use other support systems. The scripts are designed to use ssh secure tunneling so aslong outside connections are allowed on port 22 the systems will work with a gateway server in between, this will make it possible to provide support to users behind nats and firewalls. The package is maintained by PowerCraft Technology. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (990, 'unstable'), (50, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
On Mon, 26 Jan 2009, Stefano Zacchiroli wrote: > On Mon, Jan 26, 2009 at 09:59:04AM +0100, Lucas Nussbaum wrote: > > The goals of "nocheck" are different, and more useful, are bypassing > > the test suite allows faster builds in all cases. > > The goals of Build-Depends-Test are the same of "nocheck": faster > overall build time if you don't care about the test suite. In a sense, > "nocheck" can be complete only with Build-Depends-Test. > > Then you can ask in which scenario you might want to skip test suite > to build faster, ... and I don't think buildds match that scenario. nocheck is not only to reduce build-time but also to allow easier cross-compilation where a cross-compiled test-suite can't run at all on the build machine. Thus I don't think that the argument presented holds. The creation of nocheck doesn't imply that we have to go further and create Build-Depends-Test for completing any initial goal. For me it's useless complexity at this point. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Why is su preserving the environment?
Le samedi 24 janvier 2009 à 15:39 +, Matthew Johnson a écrit : > > Clearly that’s not the case, since the original issue happens over > > D-Bus. In this case, not for authentication, but clearly the application > > launched as root can connect to the session bus. > > Well, clearly something else is going on because root can't connect to the > session bus here, this is on Lenny. I'm also part of DBus upstream and AFAIK > this part of the security policy has not changed: You are pretty damn right. I thought it was a general D-Bus issue since bonobo uses the session bus address, but it only uses it to define a lock file for ORBit. So the problem actually lies in libbonobo - which makes it much less important in scope. Thanks for your insight. (I still think we shouldn’t keep such environment variables in processes started with su, but given the other reactions I’m not willing to argue more on this.) Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Test suites after build and Build-Depends.
On Mon, 26 Jan 2009 08:44:01 +0100, Stefano Zacchiroli wrote:
> Personally, I'd add as a condition for this to be a reasonable
> request, the fact that there should be enough packages with enough
> test-only dependencies, which I'm not convinced it is the case.
Are around 1200 arch:any libfoo-perl packages enough? They usually
duplicate the run-time dependencies in B-D-I for the tests and often
add some extra libtest-foo-perl modules. For the build usually
perl{,-modules} would be enough.
(Note that I'm not conviced of the value of a new Build-Depends-Test
field, I just wanted to provide an additional data point.)
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Bob Dylan: Summer Days
signature.asc
Description: Digital signature
Re: Test suites after build and Build-Depends.
On Mon, Jan 26, 2009 at 06:52:00PM +0100, gregor herrmann wrote: > On Mon, 26 Jan 2009 08:44:01 +0100, Stefano Zacchiroli wrote: > > > Personally, I'd add as a condition for this to be a reasonable > > request, the fact that there should be enough packages with enough > > test-only dependencies, which I'm not convinced it is the case. > > Are around 1200 arch:any libfoo-perl packages enough? They usually > duplicate the run-time dependencies in B-D-I for the tests OT, but why do they need to *duplicate* these? Normaly, dependencies in B-D needn't appear in B-D-I. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
* Mike Hommey [Mon, 26 Jan 2009 19:13:10 +0100]: > On Mon, Jan 26, 2009 at 06:52:00PM +0100, gregor herrmann wrote: > > On Mon, 26 Jan 2009 08:44:01 +0100, Stefano Zacchiroli wrote: > > > Personally, I'd add as a condition for this to be a reasonable > > > request, the fact that there should be enough packages with enough > > > test-only dependencies, which I'm not convinced it is the case. > > Are around 1200 arch:any libfoo-perl packages enough? They usually > > duplicate the run-time dependencies in B-D-I for the tests > OT, but why do they need to *duplicate* these? Normaly, dependencies in > B-D needn't appear in B-D-I. They duplicate the "Depends" line into B-D-I. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
On Mon, Jan 26, 2009 at 19:13, Mike Hommey wrote: > On Mon, Jan 26, 2009 at 06:52:00PM +0100, gregor herrmann wrote: >> Are around 1200 arch:any libfoo-perl packages enough? They usually >> duplicate the run-time dependencies in B-D-I for the tests > > OT, but why do they need to *duplicate* these? Normaly, dependencies in > B-D needn't appear in B-D-I. Run-time dependencies, hence bin pkg Depends field, not B-D. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
On 26/01/09 at 19:15 +0100, Adeodato Simó wrote: > * Mike Hommey [Mon, 26 Jan 2009 19:13:10 +0100]: > > > On Mon, Jan 26, 2009 at 06:52:00PM +0100, gregor herrmann wrote: > > > On Mon, 26 Jan 2009 08:44:01 +0100, Stefano Zacchiroli wrote: > > > > > Personally, I'd add as a condition for this to be a reasonable > > > > request, the fact that there should be enough packages with enough > > > > test-only dependencies, which I'm not convinced it is the case. > > > > Are around 1200 arch:any libfoo-perl packages enough? They usually > > > duplicate the run-time dependencies in B-D-I for the tests > > > OT, but why do they need to *duplicate* these? Normaly, dependencies in > > B-D needn't appear in B-D-I. > > They duplicate the "Depends" line into B-D-I. OTOH, we can't just say "let's change policy so that both depends and build-depends are required to build the package". It's a chicken-and-egg problem: binary deps are not known until you build the binary package... -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
* Lucas Nussbaum [Mon, 26 Jan 2009 19:21:54 +0100]: > It's a chicken-and-egg problem: binary deps are not known until > you build the binary package... That is simply not true, and not the case with many of our interpreted languages. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513141: ITP: haskell-testpack -- Test Utililty Pack for HUnit and QuickCheck
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: haskell-testpack Version : 1.0.0 Upstream Author : John Goerzen * URL : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/testpack * License : LGPL Programming Lang: Haskell Description : Test Utililty Pack for HUnit and QuickCheck testpack provides utilities for both HUnit and QuickCheck. These include tools for running QuickCheck properties as HUnit test cases, allowing you to combine both approaches in a single program. It also includes tools for more helpful displays of running progress in both HUnit and QuickCheck, additional generators for other types for QuickCheck, and shortcuts for quickly defining new test cases. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (99, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513145: ITP: haskell-convertible -- Typeclasses and instances for converting between types
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: haskell-convertible Version : 1.0.0 Upstream Author : John Goerzen * URL : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/convertible * License : LGPL Programming Lang: Haskell Description : Typeclasses and instances for converting between types Description: convertible provides a typeclass with a single function that is designed to help convert between different types: numeric values, dates and times, and the like. The conversions perform bounds checking and return a pure Either value. This means that you need not remember which specific function performs the conversion you desire. . Also included in the package are optional instances that provide conversion for various numeric and time types, as well as utilities for writing your own instances. . Finally, there is a function that will raise an exception on bounds-checking violation, or return a bare value otherwise, implemented in terms of the safer function described above. . Convertible is also used by HDBC 2.0 for handling marshalling of data to/from databases. . Convertible is backed by an extensive test suite and passes tests on GHC and Hugs. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (99, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
On 26/01/09 at 19:26 +0100, Adeodato Simó wrote: > * Lucas Nussbaum [Mon, 26 Jan 2009 19:21:54 +0100]: > > > It's a chicken-and-egg problem: binary deps are not known until > > you build the binary package... > > That is simply not true, and not the case with many of our interpreted > languages. uh? please explain. The Depends: could be created/modified during the build (see packages using control.in for example). If you want to parse the binary stanzas in debian/control to determine the depends before building, then it's a fragile approach. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
* Lucas Nussbaum [Mon, 26 Jan 2009 22:51:24 +0100]: > On 26/01/09 at 19:26 +0100, Adeodato Simó wrote: > > * Lucas Nussbaum [Mon, 26 Jan 2009 19:21:54 +0100]: > > > It's a chicken-and-egg problem: binary deps are not known until > > > you build the binary package... > > That is simply not true, and not the case with many of our interpreted > > languages. > uh? please explain. Ok. You package libfoo-ruby. For version 1.0-1, you write in debian/control: Source: ruby-foo Build-Depends: debhelper, ruby Package: libfoo-ruby1.8 Depends: ruby (>= 1.8), libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 ... Now, version 1.5 comes along, and it adds a testsuite, which is run using the libtest-me-harder-ruby1.8 package. So you run the test suite from debian/rules and update debian/control for 1.5-1 like this: Source: ruby-foo Build-Depends: debhelper, ruby, libtest-me-harder-ruby1.8 Package: libfoo-ruby1.8 Depends: ruby (>= 1.8), libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 ... Except that it does not work, because of course the test suite wants to run the program, which in turns wants to require 'bar', 'moo', and 'quack'. So your debian/control ends ups like: Source: ruby-foo Build-Depends: debhelper, ruby, libtest-me-harder-ruby1.8, libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 Package: libfoo-ruby1.8 Depends: ruby (>= 1.8), libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 ... Which makes Charles Plessy unhappy, and which isn't really solvable without something akin to control.in, either from debian/rules or, futuristically, dpkg-dev toolchain. And then, Build-Depends-Test is something different altogether. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls. -- Matt Cartmill -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
On 26/01/09 at 23:08 +0100, Adeodato Simó wrote: > * Lucas Nussbaum [Mon, 26 Jan 2009 22:51:24 +0100]: > > > On 26/01/09 at 19:26 +0100, Adeodato Simó wrote: > > > * Lucas Nussbaum [Mon, 26 Jan 2009 19:21:54 +0100]: > > > > > It's a chicken-and-egg problem: binary deps are not known until > > > > you build the binary package... > > > > That is simply not true, and not the case with many of our interpreted > > > languages. > > > uh? please explain. > > Ok. You package libfoo-ruby. For version 1.0-1, you write in debian/control: > > Source: ruby-foo > Build-Depends: debhelper, ruby > > Package: libfoo-ruby1.8 > Depends: ruby (>= 1.8), libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 > > ... > > Now, version 1.5 comes along, and it adds a testsuite, which is run > using the libtest-me-harder-ruby1.8 package. > > So you run the test suite from debian/rules and update debian/control > for 1.5-1 like this: > > Source: ruby-foo > Build-Depends: debhelper, ruby, libtest-me-harder-ruby1.8 > > Package: libfoo-ruby1.8 > Depends: ruby (>= 1.8), libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 > > ... > > Except that it does not work, because of course the test suite wants to > run the program, which in turns wants to require 'bar', 'moo', and > 'quack'. > > So your debian/control ends ups like: > > Source: ruby-foo > Build-Depends: debhelper, ruby, libtest-me-harder-ruby1.8, > libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 > > Package: libfoo-ruby1.8 > Depends: ruby (>= 1.8), libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 > > ... OK. Your point is: In most cases, the binary stanzas in debian/control will contain the correct set of binary dependencies at the beginning of the build. With which I agree, of course. My point is: There's nothing mandatory about having the binary stanzas in debian/control contain correct information at the beginning of the build. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513170: ITP: audiopreview -- command-line tool to play previews of audio and video files
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: audiopreview Version: 0.1 Upstream Author: Arnaud Soyez URL: http://audiopreview.codealpha.net/ License: GPL v3 Description: command-line tool to play previews of audio and video files, and also internet streams, written in C and based on Gstreamer. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Misc developer news (#13)
On Sun, Jan 25, 2009 at 9:37 AM, Emilio Pozuelo Monfort wrote: > Ondrej Certik wrote: >> This whohas command is awesome, great job! > > Yes. And the openSUSE URLs suck! Please file a bug. I'm surprised you sent that mail instead of filing a bug. -- 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
gone - no logout
Currently if a user is logged in while logrotate renames the /var/log/wtmp file then the command "last -i -f /var/log/wtmp.1" will give a result such as the following: root pts/010.0.0.1 Fri Jan 16 13:17gone - no logout Also the command "last -i" will not display anything about the user in question (it will disregard the end entry). Would it hurt to have a duplicate start entry in a wtmp file? If not then is there any reason not to duplicate the entries from sessions in progress from the wtmp.1 file to the wtmp file so that "last" will display all sessions completely? -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Misc developer news (#13)
On Tue, Jan 27, 2009 at 01:04:51PM +1100, Paul Wise wrote: > On Sun, Jan 25, 2009 at 9:37 AM, Emilio Pozuelo Monfort > wrote: > > Ondrej Certik wrote: > >> This whohas command is awesome, great job! > > > > Yes. And the openSUSE URLs suck! > > Please file a bug. I'm surprised you sent that mail instead of filing a bug. In defence of the OP, it hardly looks like a Debian-fixable problem. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: gone - no logout
In article <200901271009.35031.russ...@coker.com.au> you wrote: > Would it hurt to have a duplicate start entry in a wtmp file? If not then is > there any reason not to duplicate the entries from sessions in progress from > the wtmp.1 file to the wtmp file so that "last" will display all sessions > completely? Another option would be to have at least a "rotated" entry (like the reboot entries). But its most likely easier to just not rotate the files in normal operation. Gruss Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ITP: libconvert-binary-c-perl -- preprocessor and parser for C type definitions
retitle 468951 'ITP: libconvert-binary-c-perl -- preprocessor and parser for C type definitions' thanks Hi all, libconvert-binary-c-perl is needed by [[!debpkg: bioperl]] 1.6, that is needed by libbio-graphics-perl, that is needed by GBrowse, that is needed to browse DNA sequence, in particular our own genomes when they will all be sequenced. I already injected the package in pkg-perl's repository. Description: Binary Data Conversion using C Types Convert::Binary::C is a preprocessor and parser for C type definitions. It is highly configurable and supports arbitrarily complex data structures. Its object-oriented interface has pack and unpack methods that act as replacements for Perl's pack and unpack and allow to use C types instead of a string representation of the data structure for conversion of binary data from and to Perl's complex data structures. . Actually, what Convert::Binary::C does is not very different from what a C compiler does, just that it doesn't compile the source code into an object file or executable, but only parses the code and allows Perl to use the enumerations, structs, unions and typedefs that have been defined within your C source for binary data conversion, similar to Perl's pack and unpack. The copyright file is quite long and was already posted [[!debbug: 468951]]. The package is mostly "same licence as Perl", but there are some extra GPLed files that were copied from the libc (they are not included in the binary package). Among them, some GPL-v2 with Bison exeptions, and the infamous Sun RPC file. Apart from this, there is also some 20-year old files with non-standard statements that are DFSG compliant. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Misc developer news (#13)
On Tue, Jan 27, 2009 at 01:04:51PM +1100, Paul Wise wrote: > On Sun, Jan 25, 2009 at 9:37 AM, Emilio Pozuelo Monfort > wrote: > > Ondrej Certik wrote: > >> This whohas command is awesome, great job! > > > > Yes. And the openSUSE URLs suck! > > Please file a bug. I'm surprised you sent that mail instead of filing a bug. There is already #510524 open, but it's too fundamental a problem for a patch IMO. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Processed: reassign 512921 to xserver-xorg-video-neomagic, forcibly merging 513184 512921
Processing commands for cont...@bugs.debian.org: > # Automatically generated email from bts, devscripts version 2.10.35lenny1 > reassign 512921 xserver-xorg-video-neomagic Bug#512921: general: pixel artifacts on window drag Bug reassigned from package `general' to `xserver-xorg-video-neomagic'. > forcemerge 513184 512921 Bug#513184: Package: xserver-xorg-video-neomagic: pixel artifacts on window drag Bug#512921: general: pixel artifacts on window drag Forcibly Merged 512921 513184. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Misc developer news (#13)
Paul Wise wrote: > On Sun, Jan 25, 2009 at 9:37 AM, Emilio Pozuelo Monfort > wrote: >> Ondrej Certik wrote: >>> This whohas command is awesome, great job! >> Yes. And the openSUSE URLs suck! > > Please file a bug. I'm surprised you sent that mail instead of filing a bug. Against the openSUSE package? I doubt the whohas maintainers/developers can change openSUSE URLs, and I doubt they will use tinyurl for this either. Emilio signature.asc Description: OpenPGP digital signature
