Re: i686 require SSE4.1-capable processor?
On Mon, Jul 15, 2024 at 2:04 PM Andreas Ronnquist wrote: > > Hi > > I'm maintaining a package (filezilla) which just got a bug report that > it simply crashes on program start - It gets a SIGILL - "Illegal > instruction". (#1076312 report [1]). > > After the reporter debugged it, it seems like it crashes on the > assembler instruction "pinsrd", which looks like it was added in > SSE4.1, while the reporter runs this on a > > Intel(R) Celeron(R) M CPU 420 @ 1.60GHz > > which only supports SSE2. (Full cpuinfo available in the report) - So, my > question is - is this a cpu that is too old for Debian to support, or > should we support it, and Debian gcc generates invalid code requiring SSE4.1 > while it still should support SSE2? (Or is the problem something else > completely?) You are building on i386 with an advanced gcc flag: `-msse4.1`. This is different from Debian i386 baseline. * https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.67.1-1&stamp=1720717439&raw=0 (not tested) simply removing this flag should fix the issue.
file path length in .deb package.
Hi there, After reading the documentation of 'man deb' I cannot see any reference to any arbitrary length for filename in a deb package. For instance I have filepath (including sub directories) that reach ~100 characters. the tar format completely support that, but I am having some weird issue on my debian etch amd64 box. I have created a package where all files with long filepaths simply don't get installed (while being accessible using ar xvf + tar xvfz data.tgz). Let me know if this is a known issue. Regards, -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: file path length in .deb package.
On Wed, Apr 2, 2008 at 6:35 PM, Bart Martens <[EMAIL PROTECTED]> wrote: > > > On Wed, 2008-04-02 at 17:46 +0200, Mathieu Malaterre wrote: > > Hi there, > > > > After reading the documentation of 'man deb' I cannot see any > > reference to any arbitrary length for filename in a deb package. For > > instance I have filepath (including sub directories) that reach ~100 > > characters. the tar format completely support that, but I am having > > some weird issue on my debian etch amd64 box. I have created a package > > where all files with long filepaths simply don't get installed (while > > being accessible using ar xvf + tar xvfz data.tgz). > > > > Let me know if this is a known issue. > > Please consult the "Debian bug tracking system". wow ! Thanks, may I ask what you did during the 1s you spare not copy/pasting the bug number. You're loosing everyone time: - mine (obviously) - yours in answering such a lame response - anyone else that will find my post after a google search Anyway I did search on google for a *while* before posting, and could not find anything. I did repeat the search again for the last 15min: long filename dpkg site:bugs.debian.org long apt site:bugs.debian.org long dpkg site:bugs.debian.org It returned only one bug, but that was solved in 2002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=128388 Could you *please* give me the bug number, Thanks -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: waste of time (Re: file path length in .deb package.)
Hi Bart, On Thu, Apr 3, 2008 at 8:13 AM, Bart Martens <[EMAIL PROTECTED]> wrote: > On Wed, 2008-04-02 at 20:43 +0200, Mathieu Malaterre wrote: > > On Wed, Apr 2, 2008 at 6:35 PM, Bart Martens <[EMAIL PROTECTED]> wrote: > > > > > > > > > On Wed, 2008-04-02 at 17:46 +0200, Mathieu Malaterre wrote: > > > > Hi there, > > > > > > > > After reading the documentation of 'man deb' I cannot see any > > > > reference to any arbitrary length for filename in a deb package. For > > > > instance I have filepath (including sub directories) that reach ~100 > > > > characters. the tar format completely support that, but I am having > > > > some weird issue on my debian etch amd64 box. I have created a package > > > > where all files with long filepaths simply don't get installed (while > > > > being accessible using ar xvf + tar xvfz data.tgz). > > > > > > > > Let me know if this is a known issue. > > > > > > Please consult the "Debian bug tracking system". > > > > wow ! Thanks, may I ask what you did during the 1s you spare not > > copy/pasting the bug number. > > I don't know any relevant bug number. > > > You're loosing everyone time: > > - mine (obviously) > > - yours in answering such a lame response > > - anyone else that will find my post after a google search > > Please don't blame me for any waste of time on debian-devel. My reply > to you was a private e-mail, meant to suggest you to consult the bts to > see whether your problem is a known issue. Please accept my apologies, I kindda got very upset when I realized this issue (real problem for me right now). I'll open a bug report. Meanwhile you can test this package, which contains two files: do_not_install_me.txt and install_me.txt. http://gdcm.sourceforge.net/thingies/debpackage-0.0.0-Linux-x86_64.deb See the differences: $ dpkg -c debpackage-0.0.0-Linux-x86_64.deb drwxr-xr-x mmalaterre/mmalaterre 0 2008-04-03 11:31 ./tmp/ drwxr-xr-x mmalaterre/mmalaterre 0 2008-04-03 11:31 ./tmp/very/ drwxr-xr-x mmalaterre/mmalaterre 0 2008-04-03 11:31 ./tmp/very/long/ drwxr-xr-x mmalaterre/mmalaterre 0 2008-04-03 11:31 ./tmp/very/long/pathname/ drwxr-xr-x mmalaterre/mmalaterre 0 2008-04-03 11:31 ./tmp/very/long/pathname/foobar/ drwxr-xr-x mmalaterre/mmalaterre 0 2008-04-03 11:31 ./tmp/very/long/pathname/foobar/hello_world/ drwxr-xr-x mmalaterre/mmalaterre 0 2008-04-03 11:31 ./tmp/very/long/pathname/foobar/hello_world/toreproduceabugindpkg/ drwxr-xr-x mmalaterre/mmalaterre 0 2008-04-03 11:31 ./tmp/very/long/pathname/foobar/hello_world/toreproduceabugindpkg/pleaseconsider/ drwxr-xr-x mmalaterre/mmalaterre 0 2008-04-03 11:31 ./tmp/very/long/pathname/foobar/hello_world/toreproduceabugindpkg/pleaseconsider/123/ -rw-r--r-- mmalaterre/mmalaterre 0 2008-04-03 11:28 ./tmp/very/long/pathname/foobar/hello_world/toreproduceabugindpkg/pleaseconsider/123/do_not_install_me.txt -rw-r--r-- mmalaterre/mmalaterre 0 2008-04-03 11:28 ./tmp/very/long/pathname/foobar/hello_world/toreproduceabugindpkg/pleaseconsider/123/install_me.txt $ sudo dpkg -i debpackage-0.0.0-Linux-x86_64.deb Selecting previously deselected package debpackage. (Reading database ... 147313 files and directories currently installed.) Unpacking debpackage (from .../debpackage-0.0.0-Linux-x86_64.deb) ... Setting up debpackage (0.0.0) ... $ find /tmp/very /tmp/very /tmp/very/long /tmp/very/long/pathname /tmp/very/long/pathname/foobar /tmp/very/long/pathname/foobar/hello_world /tmp/very/long/pathname/foobar/hello_world/toreproduceabugindpkg /tmp/very/long/pathname/foobar/hello_world/toreproduceabugindpkg/pleaseconsider /tmp/very/long/pathname/foobar/hello_world/toreproduceabugindpkg/pleaseconsider/123 /tmp/very/long/pathname/foobar/hello_world/toreproduceabugindpkg/pleaseconsider/123/install_me.txt Thanks, -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packaging a project using cmake
Hi there, I am working on cleaning up the packaging of my project (GDCM) using cmake so that the .deb produced is consistant with the debian package. I was wondering if anyone had done the work before ? I am currently struggling on how to do it properly when installing python module (what is the layout, how do you know the python target installation directory...) Thanks ! -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a project using cmake
On Sat, Jun 7, 2008 at 7:47 PM, Sune Vuorela <[EMAIL PROTECTED]> wrote: > On 2008-06-07, Mathieu Malaterre <[EMAIL PROTECTED]> wrote: >> Hi there, >> >> I am working on cleaning up the packaging of my project (GDCM) using >> cmake so that the .deb produced is consistant with the debian package. >> I was wondering if anyone had done the work before ? I am currently >> struggling on how to do it properly when installing python module >> (what is the layout, how do you know the python target installation >> directory...) > > Are you talking about using cmake to *build the deb* or just about > packaging a project using cmake? > > If you are talking about the former, please forget it. What do you mean ? Indeed I want the whole process from src to .deb handled by cmake. I made some prelimianary versions at: http://sourceforge.net/project/showfiles.php?group_id=137895&package_id=197047&release_id=603764 You need to use cmake 2.6.0 (none of the dpkg-* utils are needed in the process). But if you take the souce tarball, dpkg-buildpackage should work too. Ref: http://www.mail-archive.com/[EMAIL PROTECTED]/msg03663.html Thanks, -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a project using cmake
On Sat, Jun 7, 2008 at 8:07 PM, Sune Vuorela <[EMAIL PROTECTED]> wrote: > On 2008-06-07, Mathieu Malaterre <[EMAIL PROTECTED]> wrote: >> On Sat, Jun 7, 2008 at 7:47 PM, Sune Vuorela <[EMAIL PROTECTED]> wrote: >>> On 2008-06-07, Mathieu Malaterre <[EMAIL PROTECTED]> wrote: >>>> Hi there, >>>> >>>> I am working on cleaning up the packaging of my project (GDCM) using >>>> cmake so that the .deb produced is consistant with the debian package. >>>> I was wondering if anyone had done the work before ? I am currently >>>> struggling on how to do it properly when installing python module >>>> (what is the layout, how do you know the python target installation >>>> directory...) >>> >>> Are you talking about using cmake to *build the deb* or just about >>> packaging a project using cmake? >>> >>> If you are talking about the former, please forget it. >> >> What do you mean ? Indeed I want the whole process from src to .deb >> handled by cmake. > > Then please forget it. That doesn't make proper debs. because... >> I made some prelimianary versions at: >> >> http://sourceforge.net/project/showfiles.php?group_id=137895&package_id=197047&release_id=603764 > >> You need to use cmake 2.6.0 (none of the dpkg-* utils are needed in >> the process). > > And this is where the cmake folks are wrong (I once wrote them a long > email about it). link, please ? >> >> But if you take the souce tarball, dpkg-buildpackage should work too. Ref: >> >> http://www.mail-archive.com/[EMAIL PROTECTED]/msg03663.html > > I stopped looking when > * no builddepenencies except cmake and debhelper > * one package filled with development packages and stuff. Well thanks ! That was a good bug report, indeed I forgot to duplicate cmake stuff into the equivalent debian file. I'll fix ASAP. But it should read: SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6, libstdc++6 (>= 4.0.2-4), libuuid1, zlib1g (>= 1:1.2.1), libgcc1 (>= 1:4.0.2), libexpat1, swig") Everytime I look at a debian package, it seems that those values are somehow hardcoded. I would think that a human is actually checking those versions, correct ? Or is there a tool that would say: $ superdupertool libfoo.so => this lib requires libstdc++6 at least version 4.0.2 Thanks, -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a project using cmake
On Sat, Jun 7, 2008 at 8:28 PM, Sune Vuorela <[EMAIL PROTECTED]> wrote:
> On 2008-06-07, Mathieu Malaterre <[EMAIL PROTECTED]> wrote:
>>>> What do you mean ? Indeed I want the whole process from src to .deb
>>>> handled by cmake.
>>>
>>> Then please forget it. That doesn't make proper debs.
>>
>> because...
>
> Because they doesn't use
> - dpkg-shlibdeps
I cannot figure out how to get this thing working. It keeps on
complaining when fed with an exe that I just build :
dpkg-shlibdeps: failure: no dependency information found for
/tmp/local/lib/libgdcmjpeg12.so.62.1 (used by
/tmp/local/bin/gdcmdump).
> - python-support|python-central for python stuff
That's the thing I as asking for in the first place, will look into it, thanks.
> - running ldconfig in postinst
AFAIK that's not always required...
> - interacting with postinst/preinst in other ways
I can tell cmake to package my own postinst/preinst file, eg:
http://gdcm.svn.sourceforge.net/viewvc/gdcm/Sandbox/gdcmreadahead/
>>> And this is where the cmake folks are wrong (I once wrote them a long
>>> email about it).
>>
>> link, please ?
>
> To Alex Neundorff and Bill Hoffmann.
I originally wrote the deb plugin, Alex simply integrated in cmake. If
you've lost the email, I'll check with them.
>> Well thanks ! That was a good bug report, indeed I forgot to duplicate
>> cmake stuff into the equivalent debian file. I'll fix ASAP. But it
>> should read:
>>
>> SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6, libstdc++6 (>= 4.0.2-4),
>> libuuid1, zlib1g (>= 1:1.2.1), libgcc1 (>= 1:4.0.2), libexpat1, swig")
>
> you do this *manually* ?
I had to look at what packages I had installed on my machine. Using
ldd I just selected a couple of them (I might be missing some).
As I said I could not figure out what tool was used to dump that
particular line in the control file.
>> Everytime I look at a debian package, it seems that those values are
>> somehow hardcoded. I would think that a human is actually checking
>> those versions, correct ? Or is there a tool that would say:
>>
>> $ superdupertool libfoo.so
>>=> this lib requires libstdc++6 at least version 4.0.2
>
> dpkg-shlibdeps run during build does that and then dpkg-gencontrol
> replaces the ${shlibs:Depends} in control file
ok
All this is kindda new to me. When I was looking at debian package
that use cmake to be build, I assumed the value in the control files
where hardcoded.
So, I changed my mind, I am not looking into deb-packaging my project
directly, but instead have the minimum debian specific files that
start cmake and in the end produce a valid/consistant .deb file. I was
suggest libopensync, is this a good start ?
Thanks again,
--
Mathieu
Ps: I had the discussion with Alex whether or not we should rely on
the dpkg-* tool to build a .deb file, since it appeared to me as being
only simply a 'ar' file , I assumed we could bypass them. Anyway
dpkg-shlibdeps seems to be a much more complex tool than just objdump
or ldd on the lib, this will be difficult to avoid.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a project using cmake
On Sun, Jun 8, 2008 at 9:43 AM, Riku Voipio <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 07, 2008 at 09:25:23PM +0200, Mathieu Malaterre wrote:
>> >> $ superdupertool libfoo.so
>> >>=> this lib requires libstdc++6 at least version 4.0.2
>
>> > dpkg-shlibdeps run during build does that and then dpkg-gencontrol
>> > replaces the ${shlibs:Depends} in control file
>
>> All this is kindda new to me. When I was looking at debian package
>> that use cmake to be build, I assumed the value in the control files
>> where hardcoded.
>
> You should read the Debian Policy[1] and Best Packaging Practices
> from Delopers reference[2]. Else you will generate packages that
> look superfically correct, but, are in fact buggy. IE don't develop
> by guesswork.
Ok, but REing the file format allowed me to understand the difference
between ar-as-in-GNU vs ar-as-inBSD and finding the following nasty
bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474092
Anyway I'll check with Alex/Bill if this ok to not be backward
compatible and only build deb on debian machine.
Thanks everybody,
--
Mathieu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Generating debian package using cmake (take 2)
Hi there, Because of the recent feedback I got in building debian package using cmake, I decided to rewrite the current -broken- support. As far as I understand : 1. dpkg-buildpackage *has* to be the entry point (nothing else, not even 'cmake') 2. dpkg-buildpackage requires a 'debian' subdirectory to be present in the source directory directly (it cannot be outside of the project first level subdirectory). 3. I was suggested libopensync for cmake/debian package start. 3.1 where is the internal name 'libopensync1exp3' coming from ? what does the '1exp3' stand for ? 3.2 In opensync/debian/control file, where does the 'Build-Depends' comes from ? Is this computed by some tool or is this purely human-based ? 4. Let say my package is named 'foo', 4.1 the 'libfoo' package is assumed to provide the runtime libraries 4.2 the 'libfoo-dev' package is assumed to provide the shared lib symlinks + headers file 4.3 I could not find any naming convention consistant for 'utils' or 'tools', basically applications (main function) based on 'libfoo'. I am sure there will be tiny differences that will prevent cmake from generating complete 'control' files (for instance, Conflicts section cannot be generated by a machine), I am targetting at getting 95% of the job done and hopefully 100% for simple project. Which will means that installation will be (automatically) consistant in between a Linux-debian/MacOSX-darwin/Win32-windows machine. For references: * http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack and * http://gdcm.svn.sourceforge.net/viewvc/gdcm/branches/gdcm-2-0/debian/ Regards, -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Generating debian package using cmake (take 2)
On Mon, Jun 23, 2008 at 9:57 PM, Frank Küster <[EMAIL PROTECTED]> wrote: > "Mathieu Malaterre" <[EMAIL PROTECTED]> wrote: > >> 3. I was suggested libopensync for cmake/debian package start. >> 3.1 where is the internal name 'libopensync1exp3' coming from ? what >> does the '1exp3' stand for ? > > You shouldn't try to invent a new system for building packages if you > are not familiar enough with Debian Policy to know that yourself. > > Sorry, but that's how it is. Hi Frank, That's just rude. Even if you are a super star in the debian-world and a fantastic hacker, your comment can not possibly be coming from a grown up adult. You did NOT even try to make a tiniest effort to understand what I am doing here. I am NOT reinventing the wheel here. As I said in the very first line of my email, I understood my previous mistake in the early implementation of debian package. That's why I am doing it the 'right' way (as I have been suggested in the previous thread in this very same mailing list). The output of cmake will be a bunch of files: control, libfoo.install, so that you can run dpkg-buildpackage as any other debian package. Why am I doing that ? Because *this is reinventing the wheel* when you use cmake and duplicate code in *.install file instead of simply asking cmake to generate those file for you. If you had read the wiki page I send, all the information is in the cmakelists, just not available as regular debian package files. The other goal is to also export cmake dependencies (cmake is doing system inspection), so that one should not have to write the 'Build-Depends' line. cmake knows what is needs to compile, so indeed this line is purely machine generated. As I said, I understand that some info (Conflicts typically) will be human generated, but I am sure that 95% of writing control/*.install file can be automatically generated by the build system: cmake in my case. As far as I understand generating those debian files can be tedious and error prone, plus it duplicate the logic in cmake anyway. This should remove most of the boiler plate code, when a project is using cmake. -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Generating debian package using cmake (take 2)
On Mon, Jun 23, 2008 at 11:06 PM, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le lundi 23 juin 2008 à 22:11 +0200, Mathieu Malaterre a écrit : >> That's just rude. Even if you are a super star in the debian-world >> and a fantastic hacker, your comment can not possibly be coming from a >> grown up adult. > > Rude? Come on. You are trying to reinvent the wheel in the worst > possible way, without understanding what a wheel is for and without > obviously reading the documents that explain what are wheels and how to > make them (Debian Policy and New Maintainer's guide). Starting from > that, Frank could have been much more rude. Fine. >> You did NOT even try to make a tiniest effort to understand what I >> am doing here. I am NOT reinventing the wheel here. As I said in the >> very first line of my email, I understood my previous mistake in the >> early implementation of debian package. That's why I am doing it the >> 'right' way (as I have been suggested in the previous thread in this >> very same mailing list). >> The output of cmake will be a bunch of files: control, >> libfoo.install, so that you can run dpkg-buildpackage as any other >> debian package. > > Stop. Don't even try to go further. This is NOT the right way. Your > brand new wheels are going to drive you straight into a wall after way > too much effort. Please give such real world examples of failure (if they are documented anywhere). >> Why am I doing that ? Because *this is reinventing the wheel* when >> you use cmake and duplicate code in *.install file instead of simply >> asking cmake to generate those file for you. If you had read the wiki >> page I send, all the information is in the cmakelists, just not >> available as regular debian package files. > > The cmakelists will not tell you in which package the files have to go. I am the maintainer of this particular package. I made sure that 'cmake-components' actually match what I call a 'typical' debian package: runtime libraries, application and dev package. Typically cmake will also split installation into development type installation vs runtime installation. So yes, there is a way to specify in cmake what executable is part of which components (package in debian vocabulary AFAIK). > And if they all need to go in the same package, you don't need a > *.install file. what do you mean all ? In cmake you simply say: INSTALL(TARGETS tiffdump libtiff RUNTIME DESTINATION bin COMPONENT Runtime LIBRARY DESTINATION lib COMPONENT Runtime ) INSTALL(FILES tiff.h DESTINATION include COMPONENT Development ) Which mean tiffdump and libtiff are part of the 'runtime' package, while 'tiff.h' is part of the development package.(*) Thus if you : cmake -DCOMPONENT=Runtime -P cmake_install.cmake It will only install the 'Runtime' components. > Most of the stuff in debian/ is NOT duplicating anything. It is the > required information to build a package. That's what I call duplicate information: http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/gdcmutils.install?view=markup This file could have been generated from the info contained in the following cmakelists.txt http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/Applications/Cxx/CMakeLists.txt?view=markup while this file: http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/libgdcm20.install?view=markup could have been generated from the info contained in the following files (where * stand for Common, DataDict...): http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/Source/*/CMakeLists.txt?view=markup So the question is now: are the files debian/libgdcm20.install & debian/gdcmutils.install the right way of doing it (I was suggested the opensync package if that matter). Else how do you automatically generate them, so that they are always in sink with the dev team ? >> The other goal is to also export cmake dependencies (cmake is doing >> system inspection), so that one should not have to write the >> 'Build-Depends' line. cmake knows what is needs to compile, so indeed >> this line is purely machine generated. > > There is no metadata store to map a build system's requirements to > build-dependencies (unlike those we have for shared libraries). Some of > us have thrown some ideas to achieve that with pkg-config, but they > would be hacks. Achieving them with packages not using pkg-config (or a > similar system) does not even look possible in the current state of > affairs. I do not understand this either. For instance, my cmakelists.txt contains this particular line: FIND_PACKAGE(ZLIB REQUIRED) I thought I could just add an entry for the Build-Depends teli
Re: Generating debian package using cmake (take 2)
On Tue, Jun 24, 2008 at 12:54 AM, Neil Williams <[EMAIL PROTECTED]> wrote: > On Tue, 2008-06-24 at 00:20 +0200, Mathieu Malaterre wrote: >> > Stop. Don't even try to go further. This is NOT the right way. Your >> > brand new wheels are going to drive you straight into a wall after way >> > too much effort. >> >> Please give such real world examples of failure (if they are >> documented anywhere). > > Cross-purposes. > > Mathieu - you're coming from the viewpoint of a single package and > trying to make that apply to all packages that would use cmake. I do not believe I said cmake would take over the whole debian package system tomorrow, but I see your point. Indeed, I am only focusing in getting (in too little time) debian package for a particular set of limited package. > Josselin is working from the viewpoint of all packages in Debian and > trying to make you see that the *right way* is to modify the existing > build tools to work with cmake. > > I regularly have cause to review, modify, patch and mangle every build > system used in Debian (just about) and I have had to build a modified > build system around those systems that is able to support cross-building > via each one. The only way to do this is to supply modifications for > debhelper and CDBS, then make individual changes for individual packages > and get those changes filed as bugs in the BTS. > > (Yes, I know many here hate CDBS but I say again, CDBS is the easiest > one for me to handle in such a way.) I had to work the other way around. Install cmake-based project via official debian package, only to realize installation was broken. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486794 That's were I started to think of a better collaboration in between debian package system and cmake... > Over the years, Emdebian and others have tried many other ways of doing > things, including your (doomed) attempt to scale up from a single > package. The right way is to extend debhelper to explicitly understand > cmake and use existing debhelper routines in a cmake-way. THANK YOU ! So far I only had FUDs about: 'no this is impossible, 'this is not the right way'. Thanks for taking the time to answer in detail, this much more supportive. I finally understood the previous aggressive answers, I was simply looking at the problem from opposite direction. So the next question is: where do I get started :) >> I am the maintainer of this particular package. > > Then I respectfully submit that this is quite obviously the WRONG > package to select for this purpose. Yeah well, say that to upper management :) Sorry been under too much pressure, I'll give up on my half born project cmake-driven debian package generation and start looking into integrating cmake into debhelper. > Forget any specific package - work within debhelper alone and create a > system that works for all cmake projects using debhelper meta-data that > is entirely within the current scope of debhelper itself. By all means > test on a particular package (preferably many packages) but do *NOT* > base the entire thesis on a specific package - that way lies lunacy, > believe me. Been there, done that. ok. > If debhelper understands cmake, CDBS will understand cmake via debhelper > and virtually every other build system in Debian will be able to make > the adjustment. > > Do *NOT* stipulate that all cmake projects in Debian are expected to > generate their debian/ files using your scheme - reverse the logic and > make your scheme support all possible permutations of files in debian/ > and provide the support required to implement those for cmake. Ok. I'll need to learn debhelper terminology. > (If for no other reason than that people like me need to be able to > patch your debian/ files to make the package cross-build and comply with > Emdebian Policy without changes being overwritten by cmake.) > > cmake is the object here, not the controller. > > debhelper is the controller - cmake is the servant. Help the controller > understand how the servant works and get the servant to do things the > way that the controller stipulates. ok. >> I made sure that >> 'cmake-components' actually match what I call a 'typical' debian >> package: runtime libraries, application and dev package. Typically >> cmake will also split installation into development type installation >> vs runtime installation. So yes, there is a way to specify in cmake >> what executable is part of which components (package in debian >> vocabulary AFAIK). > > In which case the chances of the system matching any other package made > by a different upstream team approach zero. :) >> > There is no metadata stor
Generating debian package using cmake (take 3)
Hello there, long time ! [Take 2 of 'Generating debian package using cmake' has been rated PJ-13-crude language, so let's try to make a clean sequel] In take 1, I was generating debian using cmake internal implementation of debian package, which as most of you know, was doomed to failure In take 2, I was automagically generating *.install and control files using cmake components implementation, which as most of you know, was also doomed to failure, In take 3, I implemented entirely by hand all the proper debian files, as can be found here: http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/ [Ready] Well I was told that this is also a bad idea, and a maintainer should not include those debian specific file directly in the upstream source. [Aim] So my question is: is this correct ? [Fire] If this is correct, I have to exclude the 'debian' directory when creating a release tarball. If this is ok to leave the debian directory, should the packager maintain a diff to the upstream source debian files, or should he/she just pretend those file are not there ? After reading: http://www.debian.org/doc/debian-policy/ch-source.html It seems to me that the package is supposed to be empty of any debian specific file. Thanks, -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Generating debian package using cmake (take 3)
On Wed, Jun 25, 2008 at 8:28 AM, Raphael Hertzog <[EMAIL PROTECTED]> wrote: > On Tue, 24 Jun 2008, Steve Langasek wrote: >> Joey Hess has done some work to allow debhelper to handle the case of files >> under debian/ that should be ignored (since they can't be deleted as part of >> a diff); I'm afraid I don't know the current state of this work and haven't >> heard of it being much used in practice to date, so I don't know that it's >> very practical - I certainly think it's ugly to have to do things this way, >> even if it's /possible/ to work around upstream shipping debian/ in the >> tarball. > > BTW, the new source format "3.0 (quilt)" will always ignore any > pre-existing debian dir in the .orig tarball. It will completely remove > that directory (if it exists) before unpacking the debian tarball. > > So this is a problem that is approaching its end. ok then I should not worry too much about that. Thanks, -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Reporting bug on documentation
'lo Where should I report broken links from: http://www.debian.org/doc/developers-reference/new-maintainer There is a link to : http://www.debian.org/doc/developers-reference/new-maintainer.html#mentors which does not exist. Thanks, -- Mathieu signature.asc Description: OpenPGP digital signature
Bug#536363: ITP: vera++ -- Vera++ is a programmable tool for verification, analysis and transformation of C++ source code.
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: vera++ Version : 1.1.1 Upstream Author : Maciej Sobczak * URL : http://www.inspirel.com/vera/ * License : Boost Programming Lang: C++ Description : Vera++ - Programmable verification and analysis tool for C++ Vera++ is a programmable tool for verification, analysis and transformation of C++ source code. Vera++ is mainly an engine that parses C++ source files and presents the result of this parsing to scripts in the form of various collections - the scripts are actually performing the requested tasks. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#536477: ITP: cdash -- An open source, web-based software testing server.
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: cdash Version : 1.4.2 Upstream Author : Julien Jomier * URL : http://www.cdash.org/ * License : BSD Programming Lang: PHP, XSL Description : An open source, web-based software testing server. CDash aggregates, analyzes and displays the results of software testing processes submitted from clients located around the world. Developers depend on CDash to convey the state of a software system, and to continually improve its quality. CDash is a part of a larger software process that integrates Kitware's CMake, CTest, and CPack tools, as well as other external packages used to design, manage and maintain large-scale software systems. Good examples of a CDash are the CMake quality dashboard and the VTK quality dashboard. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Running a 32bits on debian amd64 system
'lo I am reading: http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id292205 But everytime I chroot into my 32bits system, part of my system still sees me as my user: $ sudo chroot ./Debian32Chroot # id uid=0(root) gid=0(root) groups=0(root) # echo $HOME /home/mathieu What should I do so that I either: 1. Completely be root or 2. Completely be user 'mathieu' Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
GC Warning: Couldn't read /proc/stat
Hi, I have setup a ia32 chroot on my amd64 system, but I cannot install default-jdk which is needed for my software: Ref: http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id292205 Full log is: $ sudo -H chroot ./Debian32Chroot # apt-get install default-jdk Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: antlr default-jre default-jre-headless ecj ecj-gcj gappletviewer-4.3 gcj gcj-4.3 gcj-jdk gcj-jre gcj-jre-headless gij gij-4.3 gjdoc java-gcj-compat java-gcj-compat-dev java-gcj-compat-headless libbcel-java libecj-java-gcj libgcj9-0-awt libgcj9-dev libgcj9-jar libgcj9-src liblog4j1.2-java liblog4j1.2-java-gcj libmx4j-java libregexp-java Suggested packages: ant libgcj9-dbg libbcel-java-doc libgcj-doc libgnumail-java libservlet2.4-java jython The following NEW packages will be installed: antlr default-jdk default-jre default-jre-headless ecj ecj-gcj gappletviewer-4.3 gcj gcj-4.3 gcj-jdk gcj-jre gcj-jre-headless gij gij-4.3 gjdoc java-gcj-compat java-gcj-compat-dev java-gcj-compat-headless libbcel-java libecj-java-gcj libgcj9-0-awt libgcj9-dev libgcj9-jar libgcj9-src liblog4j1.2-java liblog4j1.2-java-gcj libmx4j-java libregexp-java 0 upgraded, 28 newly installed, 0 to remove and 0 not upgraded. 2 not fully installed or removed. Need to get 33.3MB of archives. After this operation, 67.6MB of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://ftp.fr.debian.org sid/main gij-4.3 4.3.3-12 [49.7kB] Get:2 http://ftp.fr.debian.org sid/main gcj-jre-headless 4:4.3.3-9 [1410B] Get:3 http://ftp.fr.debian.org sid/main gij 4:4.3.3-9 [1030B] Get:4 http://ftp.fr.debian.org sid/main libgcj9-jar 4.3.3-12 [10.1MB] Get:5 http://ftp.fr.debian.org sid/main libgcj9-0-awt 4.3.3-12 [80.6kB] Get:6 http://ftp.fr.debian.org sid/main java-gcj-compat 1.0.80-5.1 [1016B] Get:7 http://ftp.fr.debian.org sid/main gcj-jre 4:4.3.3-9 [1022B] Get:8 http://ftp.fr.debian.org sid/main default-jre 1.5-32 [1038B] Get:9 http://ftp.fr.debian.org sid/main liblog4j1.2-java 1.2.15-4 [313kB] Get:10 http://ftp.fr.debian.org sid/main libregexp-java 1.4-5 [89.7kB] Get:11 http://ftp.fr.debian.org sid/main libbcel-java 5.2-3 [483kB] Get:12 http://ftp.fr.debian.org sid/main libmx4j-java 3.0.2-6 [905kB] Get:13 http://ftp.fr.debian.org sid/main java-gcj-compat-headless 1.0.80-5.1 [15.3kB] Get:14 http://ftp.fr.debian.org sid/main default-jre-headless 1.5-32 [5622B] Get:15 http://ftp.fr.debian.org sid/main antlr 2.7.7-11 [10.6kB] Get:16 http://ftp.fr.debian.org sid/main libgcj9-dev 4.3.3-12 [785kB] Get:17 http://ftp.fr.debian.org sid/main gcj-4.3 4.3.3-12 [3261kB] Get:18 http://ftp.fr.debian.org sid/main gcj-jdk 4:4.3.3-9 [1542B] Get:19 http://ftp.fr.debian.org sid/main gcj 4:4.3.3-9 [864B] Get:20 http://ftp.fr.debian.org sid/main ecj 3.4.2-4 [13.8kB] Get:21 http://ftp.fr.debian.org sid/main libecj-java-gcj 3.4.2-4 [1505kB] Get:22 http://ftp.fr.debian.org sid/main ecj-gcj 3.4.2-4 [1414kB] Get:23 http://ftp.fr.debian.org sid/main gjdoc 0.7.9-4 [1615kB] Get:24 http://ftp.fr.debian.org sid/main gappletviewer-4.3 4.3.3-12 [5772B] Get:25 http://ftp.fr.debian.org sid/main java-gcj-compat-dev 1.0.80-5.1 [2498B] Get:26 http://ftp.fr.debian.org sid/main default-jdk 1.5-32 [1030B] Get:27 http://ftp.fr.debian.org sid/main libgcj9-src 4.3.3-12 [12.4MB] Get:28 http://ftp.fr.debian.org sid/main liblog4j1.2-java-gcj 1.2.15-4 [301kB] Fetched 33.3MB in 3s (9551kB/s) Can not write log, openpty() failed (/dev/pts not mounted?) Selecting previously deselected package gij-4.3. (Reading database ... 33775 files and directories currently installed.) Unpacking gij-4.3 (from .../gij-4.3_4.3.3-12_i386.deb) ... Selecting previously deselected package gcj-jre-headless. Unpacking gcj-jre-headless (from .../gcj-jre-headless_4%3a4.3.3-9_i386.deb) ... Selecting previously deselected package gij. Unpacking gij (from .../gij_4%3a4.3.3-9_i386.deb) ... Selecting previously deselected package libgcj9-jar. Unpacking libgcj9-jar (from .../libgcj9-jar_4.3.3-12_all.deb) ... Selecting previously deselected package libgcj9-0-awt. Unpacking libgcj9-0-awt (from .../libgcj9-0-awt_4.3.3-12_i386.deb) ... Selecting previously deselected package java-gcj-compat. Unpacking java-gcj-compat (from .../java-gcj-compat_1.0.80-5.1_i386.deb) ... Selecting previously deselected package gcj-jre. Unpacking gcj-jre (from .../gcj-jre_4%3a4.3.3-9_i386.deb) ... Selecting previously deselected package default-jre. Unpacking default-jre (from .../default-jre_1.5-32_i386.deb) ... Selecting previously deselected package liblog4j1.2-java. Unpacking liblog4j1.2-java (from .../liblog4j1.2-java_1.2.15-4_all.deb) ... Selecting previously deselected package libregexp-java. Unpacking libregexp-java (from .../libregexp-java_1.4-5_all.deb) ... Selecting previously deselected package libbcel-java. Unpacking libbcel-java (from .../libbcel-java_5.2-3_all.deb) ... Selecting previously deselecte
Re: Running a 32bits on debian amd64 system
On Mon, Jul 13, 2009 at 5:20 PM, Goswin von Brederlow wrote: > apt-get install schroot > RTFM Did you *actually* read it yourself ? I'd suggest you reread it: http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id292437 There is no mention to chroot -H option whatsoever You do not need to be rude when I explicitly quote the actual doc I am reading, which obviously should not recommend the use of chroot -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Running a 32bits on debian amd64 system
On Mon, Jul 13, 2009 at 5:41 PM, Cyril Brulebois wrote: > Which obviously hadn't been updated in *years*. RT*appropriate*FM. 1. This is the #1 link on a google search, 2. this is listed as *Please either ask in IRC channel if unsure or refer to the The Debian GNU/Linux AMD64 HOW-TO for a more up-to-date manual.* From: http://wiki.debian.org/DebianAMD64Faq Would you be kind enough to actually quote the document (URL) which you call 'appropriate' Thank you. -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Running a 32bits on debian amd64 system
On Tue, Jul 14, 2009 at 5:04 PM, Johannes Wiedersich wrote: > Mathieu Malaterre wrote: >> You do not need to be rude when I explicitly quote the actual doc I am >> reading, which obviously should not recommend the use of chroot > > FWIW, this is the wrong mailing list for that kind of question. People > tend to be more helpful, if the correct form and forum/list is chosen > (debian-user or debian-amd64 in this case). Please also search the > list's archives. I see... Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537227: ITP: kwstyle -- style checker for source code
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: kwstyle Version : 1.0.0 Upstream Author : Julien Jomier * URL : http://public.kitware.com/KWStyle/ * License : BSD Programming Lang: C++ Description : style checker for source code KWStyle is integrated in the software process to ensure that the code written by several users is consistent and can be viewed/printed as it was written by one person. KWStyle is primarily checking C/C++ source code but can be easily extended to other languages. It assumes that the code is syntaxically correct, i.e it compiles on a standard compiler. Among the fearures provided by KWStyle: - Several Indentation checking - Copyright Header correctness - Maximum line length - Encapsulation preservation - Internal variable checking via regular expressions - New line at the end of file -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
boost 1.39 (was: Re: Return of unversioned boost -dev packages (boost-defaults))
Steve, On Mon, May 11, 2009 at 6:07 AM, Steve M. Robbins wrote: Hello, I'm pleased to announce the upload of boost-defaults, a new package that supplies unversioned -dev packages for Boost (libboost-dev, etc.) that simply depend on the current "default" Boost version (today, it is Boost 1.38.0). I am lost, why is the versionned boost1.39 back then ? How should one write control file using let say: libboost-math-dev ? Should I do libboost-math-dev | libboost-math1.39-dev ? Thanks, -- Mathieu signature.asc Description: OpenPGP digital signature
Bug#545502: ITP: srcml -- srcML: A document-oriented XML representation of source code
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: srcml Version : 20061109 Upstream Author : Dr. Michael Collard, Jonathan Maletic * URL : http://www.sdml.info/projects/srcml/ * License : GPL Programming Lang: C++ Description : srcML: A document-oriented XML representation of source code srcML is a combination of source code (text) and selective AST information (tags) in a single XML document. . The focus is to construct a document representation in XML instead of a more traditional data representation of the source code. The representation of source code as semi-structured text supports a programmer-centric rather than a compiler-centric view, providing full access to the source code at the lexical, documentary (e.g., comments, white space), structural (e.g., classes, functions), and syntactic (e.g., statement) levels. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
buildd : chroot / tty and nawk
Hi there, I am running into an issue, dicom3tools does not compile properly on the buildd machine. The error is: ... rm -rf transynu.h nawk -f ../../.././libsrc/support/transyn.awk \ role=extern outname=transynu <../../.././libsrc/standard/transyn.tpl >transynu.h rm -rf sopclu.h nawk -f ../../.././libsrc/support/sopcl.awk \ role=extern outname=sopclu <../../.././libsrc/standard/sopcl.tpl >sopclu.h rm -rf elmconst.h nawk -f ../../.././libsrc/support/elmdict.awk \ role=constant outname=elmconst <../../.././libsrc/standard/elmdict.tpl >elmconst.h rm -rf strvalc.h nawk -f ../../.././libsrc/support/strval.awk \ role=declare outname=strvalc <../../.././libsrc/standard/strval.tpl >strvalc.h nawk: cannot open "/dev/tty" for output (No such device or address) make[5]: *** [strvalc.h] Error 2 ... Does anyone understand what this means ? If yes, what is needed to get tty working (or tell nawk to not use it). Thanks, -- Mathieu Ref: https://buildd.debian.org/fetch.cgi?&pkg=dicom3tools&ver=1.0~20090716-1&arch=amd64&stamp=1251914363&file=log -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: buildd : chroot / tty and nawk
Nevermind, the basic idea is described here: http://www.gnu.org/manual/gawk/html_node/Special-FD.html Sorry for the noise, On Tue, Sep 8, 2009 at 3:31 PM, Mathieu Malaterre wrote: > Hi there, > > I am running into an issue, dicom3tools does not compile properly on > the buildd machine. The error is: > > ... > rm -rf transynu.h > nawk -f ../../.././libsrc/support/transyn.awk \ > role=extern outname=transynu > <../../.././libsrc/standard/transyn.tpl >>transynu.h > rm -rf sopclu.h > nawk -f ../../.././libsrc/support/sopcl.awk \ > role=extern outname=sopclu > <../../.././libsrc/standard/sopcl.tpl >sopclu.h > rm -rf elmconst.h > nawk -f ../../.././libsrc/support/elmdict.awk \ > role=constant outname=elmconst > <../../.././libsrc/standard/elmdict.tpl >elmconst.h > rm -rf strvalc.h > nawk -f ../../.././libsrc/support/strval.awk \ > role=declare outname=strvalc > <../../.././libsrc/standard/strval.tpl >strvalc.h > nawk: cannot open "/dev/tty" for output (No such device or address) > make[5]: *** [strvalc.h] Error 2 > ... > > > Does anyone understand what this means ? If yes, what is needed to > get tty working (or tell nawk to not use it). > > Thanks, > -- > Mathieu > > Ref: > https://buildd.debian.org/fetch.cgi?&pkg=dicom3tools&ver=1.0~20090716-1&arch=amd64&stamp=1251914363&file=log > -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Complete, sorted list of developers (600kB)
Just for fun today, I tried to see the complete list of debian dev: http://qa.debian.org/developer.php -> http://qa.debian.org/developer.php?all=1 List is empty for me... weird... -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546752: ITP: igraph -- A library for creating and manipulating graphs
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: igraph Version : 0.5.2 Upstream Author : Gabor Csardi, Tamas Nepusz * URL : http://igraph.sourceforge.net/ * License : GPL Programming Lang: C++ Description : A library for creating and manipulating graphs igraph is a library for creating and manipulating graphs. It is intended to be as powerful (ie. fast) as possible to enable the analysis of large graphs. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546936: ITP: r-cran-igraph -- GNU R package for igraph
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: r-cran-igraph Version : 0.5.2 Upstream Author : Gabor Csardi * URL : http://cran.r-project.org/web/packages/igraph/ * License : GPL Programming Lang: R Description : GNU R package for igraph Routines for simple graphs and network analysis. igraph can handle large graphs very well and provides functions for generating random and regular graphs, graph visualization, centrality indices and much more. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547184: ITP: pixelmed -- PixelMed Java DICOM Toolkit
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: pixelmed Version : 20090816 Upstream Author : David Clunie * URL : http://www.pixelmed.com/ * License : BSD Programming Lang: Java Description : PixelMed Java DICOM Toolkit This is a stand-alone DICOM toolkit that implements code for reading and creating DICOM data, DICOM network and file support, a database of DICOM objects, support for display of directories, images, reports and spectra, and DICOM object validation. The toolkit is a completely new implementation, which does not depend on any other DICOM tools, commercial or free. It does make use of other freely available pure Java tools for compression and XML and database support. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550496: ITP: wrapitk -- Automated dynamic language binding for Insight Toolkit (ITK)
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: wrapitk Version : 0.3.0 Upstream Author : gaetan.lehmann * URL : http://code.google.com/p/wrapitk/ * License : BSD Programming Lang: C++ Description : Automated dynamic language binding for Insight Toolkit (ITK) WrapITK is an effort to automate the language binding process of one of the largest highly template-oriented c++ libraries, the Insight Toolkit image processing library. Currently Python, Java and Tcl language bindings are implemented, but only Python is fully supported. For ITK .NET languages wrapper you may refer to ManagedITK. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551978: ITP: vtkedge -- Library of advanced visualization and data processing techniques
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: vtkedge Version : 0.1.0 Upstream Author : Kitware, Inc. * URL : http://www.vtkedge.org/ * License : GPL Programming Lang: C++ Description : Library of advanced visualization and data processing techniques VTKEdge is a library of advanced visualization and data processing techniques that complement the Visualization Toolkit (VTK), as well as custom modules to allow the use of these techniques within ParaView. VTKEdge does not replace VTK, but rather is built alongside VTK to provide additional functionality. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552618: ITP: utfcpp -- A simple, portable and lightweight generic library for handling UTF-8 encoded strings.
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: utfcpp Version : 2.2.3 Upstream Author : Nemanja Trifunovic * URL : https://sourceforge.net/projects/utfcpp/ * License : BSD Programming Lang: C++ Description : A simple, portable and lightweight generic library for handling UTF-8 encoded strings. Many C++ developers miss an easy and portable way of handling Unicode encoded strings. The original C++ Standard (known as C++98 or C++03) is Unicode agnostic, and while some work is being done to introduce Unicode to the next incarnation called C++0x, for the moment nothing of the sort is available. In the meantime, developers use third party libraries like ICU, OS specific capabilities, or simply roll out their own solutions. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
gcj-4.4: Internal error: Segmentation fault (program ecj1)
Hi there, I am starring at: https://buildd.debian.org/~luk/status/package.php?p=gdcm -> https://buildd.debian.org/fetch.cgi?pkg=gdcm&arch=hppa&ver=2.0.13-1&stamp=1256783874&file=log&as=raw Linking CXX shared library ../../bin/libvtkgdcmJava.so make[3]: Leaving directory `/build/buildd-gdcm_2.0.13-1-hppa-FpGr8O/gdcm-2.0.13/debian/build-python2.5' [ 88%] Built target vtkgdcmJava make[3]: Entering directory `/build/buildd-gdcm_2.0.13-1-hppa-FpGr8O/gdcm-2.0.13/debian/build-python2.5' Scanning dependencies of target VTKGDCMJavaJar make[3]: Leaving directory `/build/buildd-gdcm_2.0.13-1-hppa-FpGr8O/gdcm-2.0.13/debian/build-python2.5' make[3]: Entering directory `/build/buildd-gdcm_2.0.13-1-hppa-FpGr8O/gdcm-2.0.13/debian/build-python2.5' [ 88%] javac *.java -> jar; jar cvf -> vtkgdcm.jar gcj-4.4: Internal error: Segmentation fault (program ecj1) Please submit a full bug report. See for instructions. make[3]: *** [bin/vtkgdcm.jar] Error 1 make[2]: *** [Utilities/VTK/CMakeFiles/VTKGDCMJavaJar.dir/all] Error 2 make[1]: *** [all] Error 2 make: *** [debian/build-python2.5-stamp] Error 2 I tried reproducing it here on my amd64 box using gcj-4.4 (testing) and gcc-snapshot but I cannot reproduce it here. I am guessing this is a hppa only issue. How should I handle that ? Ref: $ apt-cache policy gcj-4.4-jdk gcc-snapshot gcj-4.4-jdk: Installed: 4.4.1-6 Candidate: 4.4.1-6 Version table: *** 4.4.1-6 0 200 http://ftp.fr.debian.org testing/main Packages 100 http://ftp.fr.debian.org unstable/main Packages 100 /var/lib/dpkg/status gcc-snapshot: Installed: 20090923-1 Candidate: 20090923-1 Version table: *** 20090923-1 0 100 http://ftp.fr.debian.org unstable/main Packages 100 /var/lib/dpkg/status Thanks -- Mathieu Ps: on a different note, the README.Bugs file lives with gcc subdir, not gcj subdir (IMHO): http://packages.debian.org/search?suite=sid&arch=any&mode=path&searchon=contents&keywords=README.Bugs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ridiculously large packages
On Fri, Nov 20, 2009 at 4:21 PM, Frans Pop wrote: > On Friday 20 November 2009, Steve McIntyre wrote: >> If you ever want this to be available on Debian CDs, you're going to >> have to do something about the size. For now, I'm going to blacklist >> this package altogether. > > Even though they do technically still fit on a CD, you may want to consider > excluding the following packages as well, as including them essentially > means having roughly 4 CD images dedicated to 9 packages. > > 53450 vtk-doc_5.2.1-11_all.deb Slightly off topic, but I have been login some recommendations to divide the size of this package by at least a factor of 2. Reference (will be updated whenever tracking system process my mail) : http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=vtk-doc Cheers -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
uscan weirdness
Hi there, Does anyone knows why uscan is not working as I would expect: There is directory: ftp://download.nvidia.com/XFree86/Linux-x86_64/195.22/ However latest version detected is 190.42.2 http://dehs.alioth.debian.org/report.php?package=nvidia-graphics-drivers Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: uscan weirdness
On Tue, Nov 24, 2009 at 8:59 PM, Raphael Geissert wrote: > Daniel Leidert wrote: > >> Am Dienstag, den 24.11.2009, 18:28 +0100 schrieb Mathieu Malaterre: >> >>> Does anyone knows why uscan is not working as I would expect: >>> >>> There is directory: >>> ftp://download.nvidia.com/XFree86/Linux-x86_64/195.22/ >>> >>> However latest version detected is 190.42.2 >>> http://dehs.alioth.debian.org/report.php?package=nvidia-graphics-drivers >> >> Latest version detected by uscan is 195.22.2. The DEHS information is >> simply not up-to-date. This service is not run every minute. What did >> you expect? >> > > As a matter of fact, that package should have been re-checked by now. > The latest changes made by ftpmaster to allow arch: all packages to stay > until the arch-dep binaries are built for all the architectures have broken > DEHS (and the sec tracker, at least). > > I will try to find some time to fix it, but I don't expect anything before > the weekend. Thanks ! -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
doxygen + dot => anti-aliased png (was Re: Ridiculously large packages)
Hi there, On Fri, Nov 20, 2009 at 5:39 PM, Mathieu Malaterre wrote: > On Fri, Nov 20, 2009 at 4:21 PM, Frans Pop wrote: >> On Friday 20 November 2009, Steve McIntyre wrote: >>> If you ever want this to be available on Debian CDs, you're going to >>> have to do something about the size. For now, I'm going to blacklist >>> this package altogether. >> >> Even though they do technically still fit on a CD, you may want to consider >> excluding the following packages as well, as including them essentially >> means having roughly 4 CD images dedicated to 9 packages. >> >> 53450 vtk-doc_5.2.1-11_all.deb > > Slightly off topic, but I have been login some recommendations to > divide the size of this package by at least a factor of 2. > > Reference (will be updated whenever tracking system process my mail) : > http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=vtk-doc Just for reference. Some package (such as vtk-doc) became very large due to a minor change in doxygen/dot. Now PNG files are generated using cairo which by default is doing antialiasing. Using : dot -Tpng:gd output.png input.dot force the use of libgd to create the png file. The file size was reduced by a factor of 10 on the small experiments I played with. There is currently no easy way to update doxygen script to use this trick (*). DD & DM have to resort hacking the DOT_PATH and have a fake DOT script calling dot with the proper parameter. I hope this help some debian maintainers, -- Mathieu (*) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Check if library has debug symbols
Hi there, I am trying to compile tulip (*) for debugging with: $ export DEB_BUILD_OPTIONS='noopt debug nostrip' $ apt-get source tulip $ cd tulip-3.1.2 $ dpkg-buildpackage After installation, here is what objdump reveals (**). Does this means: 1. I did not export DEB_BUILD_OPTIONS ? 2. There is an issue in debian/rule for tulip that does not properly generate debug symbols ? Thanks, -- Mathieu (*) http://packages.qa.debian.org/t/tulip.html (**) $ objdump -h /usr/lib/libtulip-3.1.so /usr/lib/libtulip-3.1.so: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .note.gnu.build-id 0024 0190 0190 0190 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .hash 5b10 01b8 01b8 01b8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .gnu.hash 681c 5cc8 5cc8 5cc8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynsym 000161b8 c4e8 c4e8 c4e8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .dynstr 000354b5 000226a0 000226a0 000226a0 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .gnu.version 1d7a 00057b56 00057b56 00057b56 2**1 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu.version_r 00a0 000598d0 000598d0 000598d0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .rela.dyn 00013ce0 00059970 00059970 00059970 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .rela.plt 7fc8 0006d650 0006d650 0006d650 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .init 0018 00075618 00075618 00075618 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 10 .plt 5540 00075630 00075630 00075630 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .text 00142b38 0007ab70 0007ab70 0007ab70 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 12 .fini 000e 001bd6a8 001bd6a8 001bd6a8 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 13 .rodata faa0 001bd6c0 001bd6c0 001bd6c0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 14 .eh_frame_hdr 59fc 001cd160 001cd160 001cd160 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 15 .eh_frame 0001afdc 001d2b60 001d2b60 001d2b60 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 16 .gcc_except_table df6a 001edb3c 001edb3c 001edb3c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 17 .ctors0228 003fc000 003fc000 001fc000 2**3 CONTENTS, ALLOC, LOAD, DATA 18 .dtors0010 003fc228 003fc228 001fc228 2**3 CONTENTS, ALLOC, LOAD, DATA 19 .jcr 0008 003fc238 003fc238 001fc238 2**3 CONTENTS, ALLOC, LOAD, DATA 20 .data.rel.ro 78c8 003fc240 003fc240 001fc240 2**5 CONTENTS, ALLOC, LOAD, DATA 21 .dynamic 01e0 00403b08 00403b08 00203b08 2**3 CONTENTS, ALLOC, LOAD, DATA 22 .got 0958 00403ce8 00403ce8 00203ce8 2**3 CONTENTS, ALLOC, LOAD, DATA 23 .got.plt 2ab0 00404640 00404640 00204640 2**3 CONTENTS, ALLOC, LOAD, DATA 24 .data 0018 004070f0 004070f0 002070f0 2**3 CONTENTS, ALLOC, LOAD, DATA 25 .bss 0500 00407120 00407120 00207108 2**5 ALLOC 26 .comment 001c 00207108 2**0 CONTENTS, READONLY -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Example package with swig csharp
hi there, I am looking for a package which would provide a csharp binding to a C/c++ library to serve as reference (wrapped using swig). Thanks, -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
LJPEG 62.1 release ! (was Re: [med-svn] r2712 - trunk/packages/gdcm/trunk/debian (jpeg))
On Thu, Nov 20, 2008 at 12:05 PM, Andreas Tille <[EMAIL PROTECTED]> wrote: > On Thu, 20 Nov 2008, Mathieu Malaterre wrote: > >> Well the size of the lib will change. I think the API is compatible, >> but I do not know about the ABI. I really do not feel comfortable with >> option 1. > > OK - I just trust you because I never dived into this. > >> I'll start anyway with option 2, in the end there need to be such a >> package. It is so completely different from the libjpeg62, that I am >> now convinced this is not a bug against libjpeg62. > > Fine. So we have sorted out the way to go: Build a separate libjpeg62+ > (or whatever name seems to be apropriate - I would not attach the name > gdcm to this one) which can be used to link gdcm against. > >> ijg 6b was release in 98. no one really complain about that. At one >> point, when I had much more free time on my hand I found out that >> imagemagick people are supporting both lib (the official lib and the >> patched one). and of course the only other people using it are the >> dcmtk people. > > Could anybody verify how the Debian packaged version of imagemagick > and dcmtk are dealing with this issue. Does it might be that these > both ship their own version of lossless JPEG compression algorithm - > which would make even more sense to create the additional package. > What about graphicsmagick? > >> Anyway this is a no-op to create such package (option #2). I even >> maintain the jpeg.sf.net for that particular point. I'll be away for a >> couple of days, do you have some sort of bug tracker to keep track of >> this sort of thing ? > > I'm afraid I do not understand this parapgraph. Above you seem to > agree that building a separate package and now you call it a no-op? > And what do you mean with a bug tracker. If you intent to create a > new package you can use the Debian BTS and file an ITP bug against > the WNPP pseudo package. Done. http://sourceforge.net/project/showfiles.php?group_id=143299&package_id=300399&release_id=642896 This package contains: * IJG 6b * Lossless patch (oceana) * cmakelists.txt * debian/* files For people starting from this thread, LJPEG is simply an integration of the lossless patch for IJG. It comes with cmakelists.txt as a default build system since the building of IJG to support 8 / 12 and 16 bits is not a runtime option but a compile time option. I feel much more comfortable writing that in cmake than with the previous build system. Let see if the community has any interest in this package. There are a couple of gray areas remaining: - should I keep the version number 62 (aka 6b) from IJG or will this confuse people ? - I have a couple of patch in the gdcm/jpeg that have not been applied. It concern broken JPEG implementation and have not been seen outside of the DICOM world. - if this package ever gets into debian, I think dcmtk package should use it instead. -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LJPEG 62.1 release ! (was Re: [med-svn] r2712 - trunk/packages/gdcm/trunk/debian (jpeg))
On Tue, Nov 25, 2008 at 5:24 PM, Mathieu Malaterre <[EMAIL PROTECTED]> wrote: > On Thu, Nov 20, 2008 at 12:05 PM, Andreas Tille <[EMAIL PROTECTED]> wrote: >> On Thu, 20 Nov 2008, Mathieu Malaterre wrote: >> >>> Well the size of the lib will change. I think the API is compatible, >>> but I do not know about the ABI. I really do not feel comfortable with >>> option 1. >> >> OK - I just trust you because I never dived into this. >> >>> I'll start anyway with option 2, in the end there need to be such a >>> package. It is so completely different from the libjpeg62, that I am >>> now convinced this is not a bug against libjpeg62. >> >> Fine. So we have sorted out the way to go: Build a separate libjpeg62+ >> (or whatever name seems to be apropriate - I would not attach the name >> gdcm to this one) which can be used to link gdcm against. >> >>> ijg 6b was release in 98. no one really complain about that. At one >>> point, when I had much more free time on my hand I found out that >>> imagemagick people are supporting both lib (the official lib and the >>> patched one). and of course the only other people using it are the >>> dcmtk people. >> >> Could anybody verify how the Debian packaged version of imagemagick >> and dcmtk are dealing with this issue. Does it might be that these >> both ship their own version of lossless JPEG compression algorithm - >> which would make even more sense to create the additional package. >> What about graphicsmagick? >> >>> Anyway this is a no-op to create such package (option #2). I even >>> maintain the jpeg.sf.net for that particular point. I'll be away for a >>> couple of days, do you have some sort of bug tracker to keep track of >>> this sort of thing ? >> >> I'm afraid I do not understand this parapgraph. Above you seem to >> agree that building a separate package and now you call it a no-op? >> And what do you mean with a bug tracker. If you intent to create a >> new package you can use the Debian BTS and file an ITP bug against >> the WNPP pseudo package. > > > Done. > > http://sourceforge.net/project/showfiles.php?group_id=143299&package_id=300399&release_id=642896 > > This package contains: > * IJG 6b > * Lossless patch (oceana) > * cmakelists.txt > * debian/* files > > For people starting from this thread, LJPEG is simply an integration > of the lossless patch for IJG. It comes with cmakelists.txt as a > default build system since the building of IJG to support 8 / 12 and > 16 bits is not a runtime option but a compile time option. I feel much > more comfortable writing that in cmake than with the previous build > system. > > Let see if the community has any interest in this package. There are a > couple of gray areas remaining: > > - should I keep the version number 62 (aka 6b) from IJG or will this > confuse people ? > - I have a couple of patch in the gdcm/jpeg that have not been > applied. It concern broken JPEG implementation and have not been seen > outside of the DICOM world. > - if this package ever gets into debian, I think dcmtk package should > use it instead. I forgot to mention, the debian/* files are not shipped with the tarball and can be found instead at: http://jpeg.svn.sf.net/viewvc/jpeg/ljpeg/debian/ Thanks -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LJPEG 62.1 release ! (was Re: [med-svn] r2712 - trunk/packages/gdcm/trunk/debian (jpeg))
Andreas, On Tue, Nov 25, 2008 at 10:14 PM, Andreas Tille <[EMAIL PROTECTED]> wrote: > On Tue, 25 Nov 2008, Mathieu Malaterre wrote: > >>> Let see if the community has any interest in this package. There are a >>> couple of gray areas remaining: >>> >>> - should I keep the version number 62 (aka 6b) from IJG or will this >>> confuse people ? > > The version number should be different from the other libjpeg inside > Debian. Just to double check you understand that I call the package "libljpeg" so that it does not conflict with "libjpeg". The reason I kep the 62 notation is so that people are aware the patch was applied against the official ijg release 62, and not the one from guido's 6c release. >>> - I have a couple of patch in the gdcm/jpeg that have not been >>> applied. It concern broken JPEG implementation and have not been seen >>> outside of the DICOM world. > > I have no idea in how far these patches make sense for general use outside > Debian - than they should be included into the tarball (under a new version, > because it is just a new upstream version). If they only are useful for > specific Debian package they should be applied using quilt or dpatch. So far the package is very minimalist and only contains : - ijg 6b - lossless patch - cmakelists it does not contains non of the gdcm's patch. I'll work on that; once I see positive response from a DD to handle the package. This duplicate my work from the gdcm package, so I'd prefer not waste my time for a doomed package. >> I forgot to mention, the debian/* files are not shipped with the >> tarball and can be found instead at: >> >> http://jpeg.svn.sf.net/viewvc/jpeg/ljpeg/debian/ > > This is really great. I think I just elaborated about debian files in > upstream tarball - thanks for this sane decision. > > Any volunteers to build an official Debian package from it to proceed > with the dicom issues? > > Kind regards and thanks for your fine work As a side note what does it takes to becomes a DD ? I guess there should be some info on the web, I'll check on that. Regards, -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#508901: ITP: dicom3tools -- Tools for handling DICOM files, with conversion from proprietary formats.
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: dicom3tools Version : 1.0.20081122 Upstream Author : David A. Clunie * URL : http://www.dclunie.com/dicom3tools/workinprogress/ * License : BSD Programming Lang: C, C++ Description : Tools for handling DICOM files, with conversion from proprietary formats. Unix, Mac and Windows (Cygwin) command line utilities for creating, modifying, dumping and validating files of DICOM attributes, and conversion of proprietary image formats to DICOM. Can handle older ACR/NEMA format data, and some proprietary versions of that such as SPI. - System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (50, 'testing'), (40, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#508901: ITP: dicom3tools -- Tools for handling DICOM files, with conversion from proprietary formats.
On Tue, Dec 16, 2008 at 2:06 PM, Yves-Alexis Perez wrote: > On mar, 2008-12-16 at 13:57 +0100, Mathieu Malaterre wrote: >> Description : Tools for handling DICOM files, with conversion >> from proprietary formats. >> >> Unix, Mac and Windows (Cygwin) command line utilities for creating, >> modifying, dumping and validating files of DICOM attributes, and >> conversion of proprietary image formats to DICOM. Can handle older >> ACR/NEMA format data, and some proprietary versions of that such as >> SPI. > What are DICOM, ACR, NEMA, SPI? =O Those are extremely well know file format in the medical imaging world. Next time you go get an MRI / CT, ask for your DICOM CD with your images (in most countries, you do not get films anymore). ACR-NEMA used to refer to the previous standard (before DICOM 1993). And SPI is a proprietary format (used by Siemens/Philips) in pre 1993 PACS system. -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#508901: ITP: dicom3tools -- Tools for handling DICOM files, with conversion from proprietary formats.
On Tue, Dec 16, 2008 at 7:06 PM, Agustin Martin wrote: > On Tue, Dec 16, 2008 at 02:14:29PM +0100, Michael Hanke wrote: >> >> On Tue, Dec 16, 2008 at 02:06:40PM +0100, Yves-Alexis Perez wrote: >> > On mar, 2008-12-16 at 13:57 +0100, Mathieu Malaterre wrote: >> > > Description : Tools for handling DICOM files, with conversion >> > > from proprietary formats. >> > > >> > > Unix, Mac and Windows (Cygwin) command line utilities for creating, >> > > modifying, dumping and validating files of DICOM attributes, and >> > > conversion of proprietary image formats to DICOM. Can handle older >> > > ACR/NEMA format data, and some proprietary versions of that such as >> > > SPI. >> > What are DICOM, ACR, NEMA, SPI? >> Medical image data formats. Given that the description should be >> appropriate for a potential user those names should be ok -- but Mac and >> Windows are surely not meaningful in this context. > > I also find of help having that info in the long description, and even part > in the short one, so people is aware if they are not potential users. > Something like > > Description: DICOM medical image files manipulation and conversion tools. > > Command line utilities for creating, modifying, dumping and validating > files of DICOM attributes. Support conversion of some proprietary medical > image formats to DICOM. Can handle older ACR/NEMA format data, and some > proprietary versions of that such as SPI. > Fixed. $ svn ci -m"as proposed by Agustin Martin" control Ref: http://debian-med.alioth.debian.org/ -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509021: ITP: gdcm -- DICOM library
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: gdcm Version : 2.0.10 Upstream Author : Mathieu Malaterre * URL : http://gdcm.sourceforge.net * License : BSD Programming Lang: C, C++, C#, Python, Java Description : DICOM library Grassroots DiCoM is a C++ library for DICOM medical files. It is automatically wrapped to python/C#/Java (using swig). It supports RAW,JPEG (lossy/lossless),J2K,JPEG-LS, RLE and deflated. It also comes with DICOM Part 3,6 & 7 of the standard as XML files. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (50, 'testing'), (40, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508992: ITP: pvrg -- JPEG implementation from Standford
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: pvrg Version : 1.2.1 Upstream Author : Andy C. Hung * URL : ftp://havefun.stanford.edu:pub/jpeg/JPEGv1.2.tar.Z. * License : PUBLIC DOMAIN LICENSE Programming Lang: C Description : JPEG implementation from Standford This public domain image encoder and decoder is based on the JPEG Committee Draft. It supports all of the baseline for encoding and decoding. The JPEG encoder is flexible in the variety of output possible. It also supports lossless coding, though not as speedy as we would like. The manual is approximately 50 pages long which describes its use. The display program for JFIF-style (YCbCr) files is described in section IV) below. The JFIF style is not a requirement for this codec - it can compress and decompress CMYK, RGB, RGBalpha, and other formats - this codec may be helpful if you wish to extract information from non-JFIF encoded JPEG files. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (50, 'testing'), (40, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#508992: ITP: pvrg -- JPEG implementation from Standford
On Wed, Dec 17, 2008 at 2:16 PM, Ron Johnson wrote: > On 12/17/08 03:57, Mathieu Malaterre wrote: >> >> Package: wnpp >> Severity: wishlist >> Owner: Mathieu Malaterre >> >> >> * Package name: pvrg >> Version : 1.2.1 >> Upstream Author : Andy C. Hung >> * URL : ftp://havefun.stanford.edu:pub/jpeg/JPEGv1.2.tar.Z. > > $ mtr havefun.stanford.edu > Couldn't get fd's flags: Bad file descriptor > Name or service not known: No such file or directory The ftp has been down for a while now. I wasn't sure if I had to indicate the original ftp site, or the copy I uploaded on sf.net: http://sf.net/projects/jpeg -> https://sourceforge.net/project/showfiles.php?group_id=143299&package_id=157390 -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#508990: ITP: dicomscope -- DICOMscope - DICOM Viewer
On Wed, Dec 17, 2008 at 2:10 PM, Ron Johnson wrote: > On 12/17/08 03:29, Mathieu Malaterre wrote: >> >> Package: wnpp >> Severity: wishlist >> Owner: Mathieu Malaterre >> >> >> * Package name: dicomscope >> Version : 3.5.1 >> Upstream Author : OFFIS DICOM Team >> * URL : http://dicom.offis.de/dscope.php.en >> * License : Copyright (C) 1994-2004, OFFIS >> Programming Lang: C, C++ >> Description : DICOMscope - DICOM Viewer >> > >> DICOMscope is a free DICOM viewer which can display uncompressed, >> monochrome DICOM images from all modalities and which supports >> monitor calibration according to DICOM part 14 as well as >> presentation states. DICOMscope offers a print client (DICOM >> Basic Grayscale Print Management) which also implements the >> optional Presentation LUT SOP Class. > > BEGIN questionable verbiage >> >> The development of this >> prototype was commissioned by the "Committee for the Advancement >> of DICOM" and demonstrated at the European Congress of Radiology >> ECR 1999. An enhanced version was developed for the "DICOM >> Display Consistency Demonstration" at RSNA InfoRAD 1999. The >> current release 3.5.1 has been demonstrated at ECR 2001 and >> contains numerous extensions, including a print server, support >> for encrypted DICOM communication, digital signatures and >> structured reporting. >> >> DICOMscope is not meant as a competition for commercial DICOM >> viewers. The application is rather a feasibility study for DICOM >> presentation states. The program is not appropriate to be used in >> a clinical environment, e.g. for reporting. > > END > > Does this really have to be in the long description, or should it be in the > README.Debian? Ok will do. Thanks for comments -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508990: ITP: dicomscope -- DICOMscope - DICOM Viewer
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: dicomscope Version : 3.5.1 Upstream Author : OFFIS DICOM Team * URL : http://dicom.offis.de/dscope.php.en * License : Copyright (C) 1994-2004, OFFIS Programming Lang: C, C++ Description : DICOMscope - DICOM Viewer DICOMscope is a free DICOM viewer which can display uncompressed, monochrome DICOM images from all modalities and which supports monitor calibration according to DICOM part 14 as well as presentation states. DICOMscope offers a print client (DICOM Basic Grayscale Print Management) which also implements the optional Presentation LUT SOP Class. The development of this prototype was commissioned by the "Committee for the Advancement of DICOM" and demonstrated at the European Congress of Radiology ECR 1999. An enhanced version was developed for the "DICOM Display Consistency Demonstration" at RSNA InfoRAD 1999. The current release 3.5.1 has been demonstrated at ECR 2001 and contains numerous extensions, including a print server, support for encrypted DICOM communication, digital signatures and structured reporting. DICOMscope is not meant as a competition for commercial DICOM viewers. The application is rather a feasibility study for DICOM presentation states. The program is not appropriate to be used in a clinical environment, e.g. for reporting. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (50, 'testing'), (40, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509110: ITP: devide -- Delft Visualization and Image processing Development Environment
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: devide Version : 8.5 Upstream Author : Charl P. Botha * URL : http://code.google.com/p/devide/ * License : BSD Programming Lang: Python Description : Delft Visualization and Image processing Development Environment DeVIDE, or the Delft Visualization and Image processing Development Environment, is a Python-based dataflow application builder that enables the rapid prototyping of medical visualization and image processing applications via visual programming. In other words, by visually connecting functional blocks (think Yahoo pipes), you can create cool visualizations. See the DeVIDE website at http://visualisation.tudelft.nl/Projects/DeVIDE -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (50, 'testing'), (40, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509113: ITP: opensourcepacs -- OpenSourcePACS is a free, open source image referral, archiving, routing and viewing system
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: opensourcepacs Version : 1.2.1 Upstream Author : UCLA Medical Imaging Informatics group * URL : http://www.mii.ucla.edu/opensourcepacs/ * License : LGPL Programming Lang: Java Description : OpenSourcePACS is a free, open source image referral, archiving, routing and viewing system It adds functionality beyond conventional PACS by integrating wet read functions, implemented through DICOM Presentation State and Structured Reporting standards. In its first release, OpenSourcePACS delivers a complete wet read system, enabling an imaging clinic or hospital to offer its services over the web to physicians within or outside the institution. In future releases, we hope to incorporate more RIS (dictation, transcription, and reporting) functionality. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (50, 'testing'), (40, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Fwd: dicomscope: open tasks
Hi there,
I am working on the dicomscope package, and I was told there is an
issue with my package:
...
> E: dicomscope: no-shlibs-control-file usr/lib/libjInterface.so
> N:
> N: Although the package includes a shared library, the package does
> not
> N: have a shlibs control file. If this is intentional, please override
> N: this error.
> N:
> N: Refer to Policy Manual, section 8.6 for details.
>
> -> Unfortunately I have not the slightest idea what might went wrong
>here. Perhaps we should ask on debian-{devel,mentors} for help ...
Could someone please let me know:
1. What this means ?
2. What am I supposed to do to fix that issue.
thanks !
--
Mathieu
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[CMake] Producing deb package with 'ar'
Hi, I am currently working on integrating debian packaging system in cpack (part of CMake, see cmake.org). Basically cpack used to have a simple tarball system for creating package on *NIX. I simply had to encapsulate this tarball within an 'ar'ball, with a control and a md5sums file (*) I am now wondering if I should also create some sort of debian 'source' package. As far as I understand there is no such thing, but instead your are distributing a copy of the original tarball of the package and a diff file. Is this correct ? If so I need to generate a diff file wich contains a minial 'debian/rules' file, correct ? thanks for comment, -- Mathieu (*) I have been searching quite a lot the web for creating binary debian package using 'ar'. Since CMake is a cross platform tool, I thought this would make sense to use the most common tool on *NIX: 'ar' instead of asking cmake user to install specific dpkg build tool. In an ideal world I should be able to cross compile using cmake under windows to generate debian package... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [CMake] Producing deb package with 'ar'
Hi Antti-Juhani On 8/6/07, Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote: > On Mon, Aug 06, 2007 at 12:34:40PM +0200, Mathieu Malaterre wrote: > > I am currently working on integrating debian packaging system in > > cpack (part of CMake, see cmake.org). Basically cpack used to have a > > simple tarball system for creating package on *NIX. I simply had to > > encapsulate this tarball within an 'ar'ball, with a control and a > > md5sums file (*) > > I recommend reading the deb(5) man page; there may be surprises. Hum... I don't see anything surprising (debian oldstable). I have been listing the file in the correct order: $ ar -r bla.deb debian-binary control.tar.gz data.tar.gz And the magic number seems to be ok (!) > > > I am now wondering if I should also create some sort of debian > > 'source' package. As far as I understand there is no such thing, but > > instead your are distributing a copy of the original tarball of the > > package and a diff file. Is this correct ? > > It's not. A Debian source package consists of two to three files. The > main file has the suffix .dsc; it specifies source package metadata and > what other files are needed. The other files are a tarball and an > optional diff. See > http://www.debian.org/doc/debian-policy/ap-pkg-sourcepkg.html#s-pkg-sourcearchives > . > sweet ! thanks for the link. So according to this page I might even be able to generate a single tarball: If there is no original source code - for example, if the package is specially prepared for Debian or the Debian maintainer is the same as the upstream maintainer - the format is slightly different: then there is no diff, and the tarfile is named package_version.tar.gz, and preferably contains a directory named package-version Thanks for the link. > Also note that packages intended for installation in a Debian system > should follow Debian policy. This may be nontrivial to achieve using an > automated system like (I assume) cmake. > See http://www.debian.org/doc/debian-policy/ > That's a completely separate issue. I believe that once a package has been approved, any minor modification will not impact this initial decision. So this will be up to the maintainer to follow the debian policy IMHO. My initial plan is simply to have the whole process of generating a debian package of cmake using cmake... Thanks -Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FOP: Objects for Formatting Objects ?
Hi there, I am reading: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526092#20 Could someone please let me know why exactly fop-hyph.jar cannot be included as a debian package ? LPPL is technically allowed in debian, right ? Ref: http://xmlgraphics.apache.org/fop/0.95/hyphenation.html#license-issues Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: FOP: Objects for Formatting Objects ?
On Mon, Jan 25, 2010 at 6:41 PM, Russ Allbery wrote: > Mathieu Malaterre writes: > >> I am reading: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526092#20 > >> Could someone please let me know why exactly fop-hyph.jar cannot be >> included as a debian package ? LPPL is technically allowed in debian, >> right ? > > That bug was closed, so I'm not quite sure what you're referencing. Maybe > that it only allowed one to configure a path to the JAR and the JAR isn't > included in the package directly? > > In general, there's nothing wrong with including a JAR in a Debian package > *if* we have source and the source is under a DFSG license. A JAR is > roughly the Java equivalent of a compiled library, though, so you can't > just drop a JAR file into a package without having the source, except in > some very strange situations (such as if the JAR were hand-crafted and is > the only source available). Also, as a library, it's generally best to > package JARs separately and then have everything that uses them depend on > that package rather than copying them into every package and having to > update every package if they change. Let me rephrase into: "If you do not manually install the fop-hyph.jar it renders the whole fop package unusable. It fails with error like: SEVERE: Couldn't find hyphenation pattern en" Therefore the only reason why someone would leave a debian package into an unusable form, is AFAIK because of a licensing issue. I could not find the usual ITP for OFFO where someone says: you cannot upload because of license. So I am asking here, if I am missing anything obvious before opening an ITP/RFP for OFFO... Thanks again, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
libqt3-mt-dev: Depends: libjpeg62-dev but it is not going to be installed
[Sorry for duplicate] Hi there, I am struggling to rebuild my package. I am thinking there is an issue with libvtk-java. So I tried in my pbuilder env the following: # apt-get build-dep vtk Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting libjpeg8-dev instead of libjpeg-dev Note, selecting libpng12-dev instead of libpng-dev Note, selecting libtiff4-dev instead of libtiff-dev The following packages have unmet dependencies: libqt3-mt-dev: Depends: libjpeg62-dev but it is not going to be installed libtiff4-dev: Depends: libjpeg62-dev but it is not going to be installed E: Build-dependencies for vtk could not be satisfied. Does it make sense that I report this issue to the above packages (libqt3-mt-dev and libtiff4-dev) ? They should Build-Dep on the virtual package libjpeg-dev right ? Thanks ! -- Mathieu -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#570932: ITP: xslthl -- XSLT syntax highlighting
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: xslthl Version : 2.0.1 Upstream Author : Michal Molhanec, Jirka Kosek, Michiel Hendriks * URL : http://xslthl.sf.net * License : zlib/libpng License Programming Lang: Java Description : XSLT syntax highlighting This is an implementation of syntax highlighting as an extension module for XSLT processors . Article about programming written in DocBook, code examples can be automatically syntax highlighted during the XSLT processing phase. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- 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/20100222105708.4686.22534.report...@gotlib.isc.ens-lyon.fr
Bug#571198: ITP: xsddiagram -- XML Schema Definition (XSD) diagram viewer
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: xsddiagram Version : 0.5 Upstream Author : Regis Cosnier * URL : http://regis.cosnier.free.fr/?page=XSDDiagram * License : GPL Programming Lang: C# Description : XML Schema Definition (XSD) diagram viewer XSD Diagram is a XML Schema Definition (XSD) diagram viewer - Display the elements, the groups and the attributes - Show the text/HTML documentation of element and attribute when available - Print the diagram - Export the diagram to emf - Zoom the diagram - Registration in the Windows Explorer contextual menu - Drag'n drop a file from explorer -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- 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/20100224094332.12479.59753.report...@gotlib.isc.ens-lyon.fr
Where to report bug for lintian HTML pages ?
Hi there, I am looking at the page: http://lintian.debian.org/tags/doc-base-unknown-section.html Clearly the line (and the href) is bogus: "Refer to Debian doc-base Manual section 2.3.3 (The section field) for details. " Where should I fill a bug for that ? Thanks, -- Mathieu -- 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/bf0c3b3f1002260513m45961b86s845eb7819e186...@mail.gmail.com
Re: Packaging Gzstream?
On Fri, May 21, 2010 at 9:00 AM, Charles Plessy wrote: > Dear all, > > I am interested in a set of programs, the ‘BEDtools’, whose source includes a > convenience copy of the gzstream library. > > http://bedtools.googlecode.com > http://www.cs.unc.edu/Research/compgeom/gzstream/ > > A quick apt-file search indicates that at least two other packages (CCed) may > be using the gzstream library, k3d and freecad. So it seems that it would > make sense to package the gzstream library separately. > > But I notice that this library has not been updated since 2003, and obviously, > if only two programs in Debian are using it, there may be a more suitable > alternative, that would be worth suggesting to the authors of BEDtools. > > Does anybody has a good recommendation to replace gzstream by something more > “mainstream” without too much work? If not, are there volunteers to > co-maintain > gzstream in Debian (it looks simple, but since I am not a C programmer, I am > not comfortable with library packaging). GDCM is using zipstream. http://www.codeproject.com/KB/stl/zipstream.aspx I do not remember why I gave up on gzstream (license issue ?). I cannot volunteer -at the moment-, but I can help with C programming issues. HTH -- Mathieu -- 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/aanlktikoblrz71jnxdcfudj3edcqpj48ikzmg_bps...@mail.gmail.com
Bug#587051: ITP: GoFigure2 -- Cross-platform for visualizing, processing and analysing of bioimages
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: GoFigure2 Version : 0.4.2 Upstream Author : gofigure2-developers at lists.sourceforge.net * URL : http://gofigure2.sf.net * License : BSD Programming Lang: C++ Description : Cross-platform for visualizing, processing and analysing of bioimages GoFigure2 is an open-source, cross-platform application for visualizing, processing and analyzing of multidimensional microscopy data. Users can visualize, segment and track cells through time, detect cell-division and ultimately generate lineages. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- 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/20100624200513.24148.52360.report...@dhcp-67-183.isc.ens-lyon.fr
default-jdk on mips
Dear Debian Developers, I would like to request a give back of GDCM on MIPS due to bug #591998. Even after looking at the latest java-common upload: http://packages.qa.debian.org/j/java-common/news/20100809T203343Z.html I still do not understand when the buildd machine will be updated so that gcj become the default-jdk. Is there a way for me to check when the mips machine are updated ? Thanks, -- Mathieu ref: https://buildd.debian.org/status/package.php?p=gdcm signature.asc Description: OpenPGP digital signature
Bug#611764: ITP: activiz.net -- Tool for generating C# wrappers around VTK
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: activiz.net Version : 5.6.1 Upstream Author : kitware * URL : http://www.kitware.com/products/avdownload.php * License : BSD Programming Lang: C++ Description : Tool for generating C# wrappers around VTK ActiViz provides a powerful interface to the Visualization Toolkit (VTK), an object-oriented software system encompassing thousands of algorithms that transform data into interactive 3D environments. ActiViz, which generates C# wrappers around VTK, enables developers to combine the power of VTK with the many .NET framework objects for web and database access. Available as source code or as a pre-built WinForms Control, ActiViz .NET includes examples, online documentation, and supports IntelliSense in the .NET Framework -- 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/20110201211248.695.65487.report...@hpdesk.malat.net
Bug#611789: ITP: mummy -- command line executable that generates C# wrappers from gccxml output
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: mummy Version : 1.0.2 Upstream Author : kitware * URL : http://www.kitware.com/products/avdownload.php * License : BSD Programming Lang: C++ Description : command line executable that generates C# wrappers from gccxml output mummy is a command line executable that generates C# wrappers from gccxml output. A C# class is generated to wrap the wrappable class named in the gccxml output. Settings to control the wrapping are given inline directly in the class header file or in the MummySettings.xml input file. -- 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/20110202085929.24317.30024.report...@hpdesk.malat.net
Fwd: paraview_3.8.1-2_amd64.changes REJECTED
Dear DDs, A user discover the wrong source for paraview 3.8.1 were pushed to debian repository. To fix this mistake, I asked for the removal of the paraview package to be able to quickly reupload it. This was very quickly executed by ftpteam. However even if paraview has been removed from testing, I can still not push it back. See the error message below. Is there anything I would be missing ? Thanks ! -- Forwarded message -- From: Debian FTP Masters Date: Thu, Feb 24, 2011 at 9:50 AM Subject: paraview_3.8.1-2_amd64.changes REJECTED To: Sylvestre Ledru , Debian Science Team Reject Reasons: paraview_3.8.1-2_amd64.changes file already known to dak md5sum and/or size mismatch on existing copy of paraview_3.8.1-2.diff.gz. md5sum and/or size mismatch on existing copy of paraview_3.8.1-2.dsc. paraview_3.8.1-2_amd64.deb: can not overwrite existing copy already in the archive. md5sum and/or size mismatch on existing copy of paraview_3.8.1-2_amd64.deb. md5sum for /srv/ftp-master.debian.org/ftp/pool/main/p/paraview/paraview_3.8.1.orig.tar.gz doesn't match paraview_3.8.1-2.dsc. size for /srv/ftp-master.debian.org/ftp/pool/main/p/paraview/paraview_3.8.1.orig.tar.gz doesn't match paraview_3.8.1-2.dsc. can not overwrite existing copy of 'paraview_3.8.1-2.diff.gz' already in the archive. 'dpkg-source -x' failed for paraview_3.8.1-2.dsc [return code: 9]. [dpkg-source output:] gpg: Signature made Tue Feb 22 18:26:05 2011 UTC using DSA key ID 0EA23F2B [dpkg-source output:] gpg: Can't check signature: public key not found [dpkg-source output:] dpkg-source: error: File ./paraview_3.8.1.orig.tar.gz has size 30794867 instead of expected 33123181 mathieu.malate...@gmail.com may not upload NEW file paraview_3.8.1-2.diff.gz mathieu.malate...@gmail.com may not upload NEW file paraview_3.8.1-2.dsc mathieu.malate...@gmail.com may not upload NEW file paraview_3.8.1-2_amd64.deb === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. -- debian-science-maintainers mailing list debian-science-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-science-maintainers -- Mathieu -- 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/AANLkTineK-Nq=4wovvs4osooxox95eo_b8rhi3bz_...@mail.gmail.com
Bug#616698: ITP: PythonQt -- Dynamic Python binding for the Qt framework
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: PythonQt Version : 2.0.1 Upstream Author : Florian Link * URL : http://pythonqt.sf.net * License : LGPL Programming Lang: C++ Description : Dynamic Python binding for the Qt framework PythonQt offers an easy way to embed the Python scripting language into a C++ Qt applications. It makes heavy use of the QMetaObject system and thus requires Qt 4.x. The focus of PythonQt is on embedding Python into an existing C++ application, not on writing the whole application completely in Python. If you want to write your whole application in Python, you should use PyQt or PySide instead. If you are looking for a simple way to embed Python objects into your C++/Qt Application and to script parts of your application via Python, PythonQt is the way to go! -- 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/20110306183627.11090.1505.report...@virtlap.malat.net
Bug#617335: ITP: Log4Qt -- C++ port of the Log4j package using the Trolltech Qt Framework
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: Log4Qt Version : 0.3 Upstream Author : Martin Heinrich * URL : http://log4qt.sf.net/ * License : Apache 2.0 Programming Lang: C++ Description : C++ port of the Log4j package using the Trolltech Qt Framework Log4Qt is a C++ port of the Apache Software Foundation Log4j package using the Trolltech Qt Framework. One of the distinctive features of log4qt is the notion of hierarchical loggers. Using loggers it is possible to selectively control which log statements are output at arbitrary granularity. -- 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/20110308081224.17064.84173.report...@virtlap.malat.net
dh_make and dep5
Hi, What is the status of dep5(*) copyright file in debian ? I am using dh_make for preparing packages, and I had report that the default generated copyright template should be replaced by a dep5 one. Should I fill a bug report ? Thanks, -- Mathieu (*) http://dep.debian.net/deps/dep5/ -- 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/AANLkTi=j6ry51frapolj6rhqp7q7lfpq-hxcjvm6x...@mail.gmail.com
[Is there a lawyer in the room?] JPEG-LS license issue
Hi there, I am trying to understand some license issue I am having. Could someone let me know if the following is compatible with a debian package: >From the [For License Of Certain Hewlett-Packard Patents Relating To Lossless and Near-Lossless Image Compression] page (*) The following statement should prevent having an implement of JPEG-LS in debian: ... III. OTHER TERMS 1. Licensee may not assign the license granted hereunder to any party at any time without the prior explicit written consent of HP, except to an acquirer of substantially all of Licensee's assets with written notice to HP. ... Is this correct ? What I do not understand is implementation such as CharLS, which declare: ... Legal The code in this project is available through a BSD style license, allowing use of the code in commercial closed source applications if you wish. All the code in this project is written from scratch, and not based on other JPEG-LS implementations. Be aware that Hewlett Packard claims to own patents that apply to JPEG-LS implementations, but they license it for free for conformant JPEG-LS implementations. Read more at http://www.hpl.hp.com/loco/ before you use this if you use this code for commercial purposes. Ref: http://charls.codeplex.com/ ... As a side note ffmpeg/libavcodec now ships an implementation of JPEG-LS: $ apt-get source -t testing libavcodec-dev $ find ffmpeg-debian-0.svn20090303 | grep jpegls ffmpeg-debian-0.svn20090303/libavcodec/jpegls.h ffmpeg-debian-0.svn20090303/libavcodec/jpeglsenc.c ffmpeg-debian-0.svn20090303/libavcodec/jpeglsdec.h ffmpeg-debian-0.svn20090303/libavcodec/jpeglsdec.c ffmpeg-debian-0.svn20090303/libavcodec/jpegls.c I have bcc : 1. The main author of CharLs, 2. The main persons behind the implementation of ffmpeg/jpegls codec, in case they have worked on the subject or would like to add something, thanks ! Regards, -- Mathieu (*) http://www.hpl.hp.com/loco/JPEGLSTerms.htm -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
E: libactiviz: ldconfig-symlink-referencing-wrong-file
Hello, I am trying to package a *binary* package. This is a commercial software but for ease of installation I am simply repackaging it. I am getting closer to my goal, one of the remaining issue is: E: libactiviz: ldconfig-symlink-referencing-wrong-file usr/lib/libvtktiff.so.5.4 -> ./libvtktiff.so.5.4.0 instead of libvtktiff.so.5.4.0 I have not been able to figure out how to regenerate those symlinks using ldconfig... Ref: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime Thanks for help, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: E: libactiviz: ldconfig-symlink-referencing-wrong-file
On Fri, May 15, 2009 at 5:38 PM, Mathieu Malaterre wrote: > Hello, > > I am trying to package a *binary* package. This is a commercial > software but for ease of installation I am simply repackaging it. > > I am getting closer to my goal, one of the remaining issue is: > > E: libactiviz: ldconfig-symlink-referencing-wrong-file > usr/lib/libvtktiff.so.5.4 -> ./libvtktiff.so.5.4.0 instead of > libvtktiff.so.5.4.0 > > I have not been able to figure out how to regenerate those symlinks > using ldconfig... > > Ref: > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime Symply redoing the 'ln -s' command myself solve the issue. I needed to do: ln -s libfoo.1.2.3 libfoo.1.2 while apparently something like that was done: ln -s libfoo.1.2.3 ./libfoo.1.2 Sorry for the noise, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Fwd: gdcm_2.0.10-2_amd64.changes REJECTED
Hello, I am a new debian maintainer, and for the first time I tried a debian package upload. It did not go that well as I received the following email (*). The package is gdcm, it is collab maintain at debian-med, the only suspicious thing I can think of is that there is a mismatch for my email adress. For some reason the email listed on http://ftp-master.debian.org/dm-uploaders.html is: ma...@users.sourceforge.net, while everything else was done using mathieu.malate...@gmail.com. Could someone please let me know what could have gone wrong for the upload ? Attached is the .changes files. (*) -- Forwarded message -- From: Debian Installer Date: Fri, May 22, 2009 at 1:17 AM Subject: gdcm_2.0.10-2_amd64.changes REJECTED To: Mathieu Malaterre , Debian-Med Packaging Team Rejected: ma...@users.sourceforge.net is not authorised to sponsor uploads === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. -- Mathieu gdcm_2.0.10-2_amd64.changes Description: Binary data
Using jetring / updating email address in debian-maintainers
Hi there, I am suffering from the following bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530384 which is basically the same as: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511709 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488770 All I am trying to do is replace the currently listed email address at: http://ftp-master.debian.org/dm-uploaders.html from ma...@users.sourceforge.net into mathieu.malate...@gmail.com As mentionned in the bug report jetring-gen does not work for this kind of action or at least I could not get it generate the modification. I would *really* appreciate if someone could show me an example on how to apply the proper changeset to debian-maintainers.gpg so that the primary gpg UID is being updated. I tried: $ sudo apt-get install -t unstable debian-maintainers $ cp /usr/share/keyrings/debian-maintainers.gpg . $ jetring-explode debian-maintainers.gpg out $ cp change-mathieu out $ jetring-review debian-maintainers.gpg out but again jetring-review does not see any difference. with: $ cat out/add-mathieu Action: edit-key Data: uid 1 primary All of the above while the ma...@users.sourceforge.net gpg uid has been completely removed from my keyring. Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
gdcm: The following packages have unmet dependencies
Hi, I am getting a bizarre dep problem on alpha (only), see: https://buildd.debian.org/fetch.cgi?pkg=gdcm;ver=2.0.10-1;arch=alpha;stamp=1242615584 ... The following packages have unmet dependencies: mono-devel: Depends: mono-runtime (>= 2.0) but it is not installable Depends: libmono-corlib1.0-cil (>= 2.0) but it is not going to be installed Depends: libmono-corlib2.0-cil (>= 2.0) but it is not going to be installed Depends: libmono-system1.0-cil (>= 2.0) but it is not going to be installed Depends: libmono-data-tds1.0-cil (>= 2.0) but it is not going to be installed Depends: libmono-data-tds2.0-cil (>= 2.0) but it is not going to be installed Depends: libmono-getoptions1.0-cil (>= 1.0) but it is not going to be installed Depends: libmono-relaxng1.0-cil (>= 1.9) but it is not going to be installed Depends: libmono-security1.0-cil (>= 2.0) but it is not going to be installed Depends: libmono-system-data1.0-cil (>= 1.2.6) but it is not going to be installed Depends: libmono-system-web1.0-cil (>= 2.0) but it is not going to be installed Depends: libmono-system-web2.0-cil (>= 2.0) but it is not going to be installed Depends: libmono-system-runtime1.0-cil (>= 2.0) but it is not going to be installed Depends: libmono1.0-cil (>= 2.0) but it is not going to be installed Depends: mono-2.0-devel (= 2.0.1-6) but it is not going to be installed Depends: mono-gac (= 2.0.1-6) but it is not going to be installed E: Broken packages ... It is working on amd64/i386/ia64 fine. Does anyone knows what could be wrong ? Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Naming convention for Java gluelib ?
Hi there, I could find the naming convention for C# binding: http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-gac-naming-versioning I am now looking for a similar page for a library that would be wrapped in Java. What would be the convention for a foo.jar requiring a gluelib lib.so ? Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hint library name (was Re: Naming convention for Java gluelib ?)
On Mon, Jun 8, 2009 at 9:15 PM, Matthew Johnson wrote: > On Mon Jun 08 18:12, Mathieu Malaterre wrote: >> Hi there, >> >> I could find the naming convention for C# binding: >> >> http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-gac-naming-versioning >> >> I am now looking for a similar page for a library that would be >> wrapped in Java. What would be the convention for a foo.jar requiring >> a gluelib lib.so ? > > Hi, this is one of the things I'd like to review at debconf this year > since I think this whole area needs reviewing. > http://www.debian.org/doc/packaging-manuals/java-policy/ exists, which > says: > > "If a Java library relies on native code, the dynamic libraries > containing this compiled native code should be installed into the > directory /usr/lib/jni. These dynamic libraries should be shipped in > a separate architecture-specific package named libXXX[version]-jni. > The package containing the Java bytecode (generally > libXXX[version]-java) should depend on this package." > > which doesn't say much about file naming. A quick sample of the archive > shows at least: > > libfoo-java.so, libjfoo.so, libfoojni-fullversion.so > > so, at the moment there's not really a standard. I've CC'd debian-java > in case anyone there isn't reading debian-devel. Excellent ! Quick question, in C# it is possible to hint the wrapped layer what is the gluelib name. Does such mechanism exist in Java ? For instance my jar file is called 'gdcm.jar' and the gluelib is (now): 'libgdcmjni.so' Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Restricting binary (sub)package from single source package
Hi, Could someone let me know what I should do when a binary package is restricting me to a subset of architecture ? For instance libvtkgdcm requires libvtk5-dev, but not libgdcm-tools. How can I express that in my single control file for gdcm ? Ref: http://packages.qa.debian.org/g/gdcm.html Thanks -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Configurable debian/control & debian/rules
hi, I am reposting a previous post under a different Subject line, hoping to get more (read: any) feedback. I am currently maintaining the gdcm package: http://packages.qa.debian.org/g/gdcm.html Is is written in -somewhat- portable C++ and should build with any decent C++ compiler. However because a Binary package of gdcm required vtk (apt-get install libvtk5-dev), I had to list this dependency in the Source/Build-Depends section. My question is simply: how do express that only one Binary package requires a particular Build-Depends package, but the other remaining Binary package should be fine ? I was thinking that maybe there was a way to configure debian/control and debian rules files... Thanks for help, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Configurable debian/control & debian/rules
On Mon, Jun 22, 2009 at 5:02 PM, Alexander Reichle-Schmehl wrote: > Hi! > > Mathieu Malaterre schrieb: > >> My question is simply: how do express that only one Binary package >> requires a particular Build-Depends package, but the other remaining >> Binary package should be fine ? > > You can't. You specify build-depends for _source_ packages, which in turn > build the binary packages. And since you can't specify to build a specific > binary package anywayą: Why would you need to specify that a build > depends is only needed for a single binary package? Let's consider one source package 'foo' which can be build using a --enable-super-duper-3rd-party-lib. My control file is then: Source: foo Build-Depends: super-duper-3rd-party-lib ... Package: libfoo ... Package: libfoo-super-duper-3rd-party-lib ... Clearly only 'libfoo-super-duper-3rd-party-lib' 'Build-Depends' on package 'libfoo-super-duper-3rd-party-lib', which make libfoo only available on the limited subset of Arch for libfoo-super-duper-3rd-party-lib... Clearly this is an issue with availability on Arch, but I do not see how to express: "Use libfoo-super-duper-3rd-party-lib only if available" (I would then need to tweak debian/rules but this should be easier). Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Configurable debian/control & debian/rules
On Mon, Jun 22, 2009 at 4:51 PM, Samuel Thibault wrote: > Mathieu Malaterre, le Mon 22 Jun 2009 16:13:58 +0200, a écrit : >> My question is simply: how do express that only one Binary package >> requires a particular Build-Depends package, but the other remaining >> Binary package should be fine ? > > Mmm, I guess that's more a question for debian-mentors? dh_shlibdeps > will precisely do this automatically for you. No, dh_shlibdeps operates on Depends, not on Build-Depends. Thanks anyway, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Configurable debian/control & debian/rules
On Mon, Jun 22, 2009 at 5:43 PM, Russ Allbery wrote: > Mathieu Malaterre writes: > >> Let's consider one source package 'foo' which can be build using a >> --enable-super-duper-3rd-party-lib. My control file is then: >> >> >> Source: foo >> Build-Depends: super-duper-3rd-party-lib >> ... >> >> Package: libfoo >> ... >> >> Package: libfoo-super-duper-3rd-party-lib >> ... >> >> >> Clearly only 'libfoo-super-duper-3rd-party-lib' 'Build-Depends' on >> package 'libfoo-super-duper-3rd-party-lib', which make libfoo only >> available on the limited subset of Arch for >> libfoo-super-duper-3rd-party-lib... >> >> Clearly this is an issue with availability on Arch, but I do not see >> how to express: "Use libfoo-super-duper-3rd-party-lib only if >> available" (I would then need to tweak debian/rules but this should be >> easier). > > You want an arch-specific build-dependency, like: > > super-duper-3rd-party-lib [i386 amd64] Indeed that was simple. And I guess I need to reflect that into the 'Package: libfoo-super-duper-3rd-party-lib'/Architecture: section Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
dupload fatal error: Can't upload libgdcm-cil_2.0.10-5_amd64.deb
Hello, I had a network issue and had to re-run dupload a second time. Now a partially *.changes files was updated, and I cannot do anything anymore: $ dupload --force gdcm_2.0.10-5_amd64.changes dupload note: no announcement will be sent. Checking signatures before upload..signatures are ok Uploading (ftp) to ftp.upload.debian.org:/pub/UploadQueue/ [ job gdcm_2.0.10-5_amd64 from gdcm_2.0.10-5_amd64.changes libgdcm-cil_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok gdcm_2.0.10-5.tar.gz, size ok, md5sum ok, sha1sum ok, sha256sum ok libvtkgdcm2-dev_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok libvtkgdcm2.0_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok libgdcm2-dev_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok libgdcm2.0-dbg_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok libvtkgdcm-tools_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok libgdcm-tools_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok libgdcm2.0_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok python-gdcm_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok python-vtkgdcm_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok gdcm_2.0.10-5.dsc, size ok, md5sum ok, sha1sum ok, sha256sum ok gdcm_2.0.10-5_amd64.changes ok ] Uploading (ftp) to anonymous-ftp-master (ftp.upload.debian.org) [ Uploading job gdcm_2.0.10-5_amd64 libgdcm-cil_2.0.10-5_amd64.deb 193.1 kBdupload fatal error: Can't upload libgdcm-cil_2.0.10-5_amd64.deb: Could not create file. at /usr/bin/dupload line 558 Thanks for suggestion, -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dupload fatal error: Can't upload libgdcm-cil_2.0.10-5_amd64.deb
On Mon, Jun 22, 2009 at 9:22 PM, Joerg Jaspert wrote: > On 11789 March 1977, Mathieu Malaterre wrote: > >> I had a network issue and had to re-run dupload a second time. Now a >> partially *.changes files was updated, and I cannot do anything >> anymore: > > Either wait for the files to time out - or read the README in the > directory you try to upload to, look for command files. Sorry this might be dumb, but I cannot get the *.commands to be signed as expected: $ cat gdcm.commands Uploader: Mathieu Malaterre Commands: rm gdcm_2.0.10-5.tar.gz rm libgdcm2-dev_2.0.10-5_amd64.deb rm libgdcm-cil_2.0.10-5_amd64.deb rm libgdcm2.0-dbg_2.0.10-5_amd64.deb rm libvtkgdcm2-dev_2.0.10-5_amd64.deb rm libvtkgdcm2.0_2.0.10-5_amd64.deb $ gpg --sign --armor gdcm.commands It creates a separate .gpg file instead of appending the signature to the actual *.commands file... Thanks for help ! -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian/watch problem
On Fri, Jun 13, 2014 at 12:50 PM, Eugene Zhukov wrote: > Hello, > > I'm struggling to get debian/watch working for the package jing-trang. > The problem is upstream says Google no longer allows publishing > tarballs under [0]. So they only have tag for the latest release [1]. > My question is, is it possible to write a d/watch file for that? > > [0] https://code.google.com/p/jing-trang/downloads/list > [1] https://code.google.com/p/jing-trang/source/browse/#svn%2Ftags%2FV20131210 > > Thanks, > Eugene > That should get you started: $ cat debian/watch version=3 https://code.google.com/p/jing-trang/source/browse/tags/ V(.*) You'll still need a repack script shell to create the tarball but at least you can scan for newever version automagically. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+7wUswWp3K05-vSOPq1Cc_w23MJ31=vpxpi+qnsglhwhb_...@mail.gmail.com
Re: How to build-depend on a C++11-capable compiler?
On Mon, Jul 21, 2014 at 12:48 PM, Thibaut Paumard wrote: > Hi, > > The new release of my package Gyoto should be built preferably with a > C++11-capable compiler. It can be built with a reduced feature-set > without, though. > > Is there a clever way to ensure that the default compiler is > C++11-capable, if available in the archive, or should I simply > Build-Depend on g++ (>=4:4.7)? (The goal behind this question is to make > life easier for backporters and persons trying alternate toolchains). Last time I asked: https://lists.debian.org/debian-devel/2013/09/msg00335.html It was prefered to provide a C++98 ABI compatible library for the time being. If you start providing a C++11 ABI library people will not be able to mix symbols from your lib and other part of debian system. As far as I understand the whole debian should transition to C++11 ABI at the same time. 2cts -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+7wUsyb3pEg==8egvofsfzjgtvebgxhjtfutqj5bg3smh1...@mail.gmail.com
same question for ftp-eu (Re: SSH upload queue stuck?)
Hi, Same question for ftp-eu [*], is there anything broken ? I am running wheezy with dput-ng from backports. A direct upload on ftp-master seems to be working just fine. Thanks. [*] $ dput ftp-eu /home/mathieu/debian/debian-med/trunk/packages/gdcm/build-area/gdcm_2.4.3-1_amd64.changes Uploading gdcm using ftp to ftp-eu (host: ftp.eu.upload.debian.org; directory: /pub/UploadQueue/) running allowed-distribution: check whether a local profile permits uploads to the target distribution running protected-distribution: warn before uploading to distributions where a special policy applies running checksum: verify checksums before uploading running suite-mismatch: check the target distribution for common errors running check-debs: makes sure the upload contains a binary package running gpg: check GnuPG signatures before the upload gpg: Signature made Wed 30 Jul 2014 08:58:51 AM CEST using RSA key ID 8AE09345 gpg: Good signature from "Mathieu Malaterre " gpg: aka "Mathieu Malaterre " gpg: aka "Mathieu Malaterre (sf.net) " gpg: aka "Mathieu Malaterre (LIRIS) " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 6933 67FF AECD 8EAA CD1F 063B 0171 E182 8AE0 9345 Uploading libgdcm2.4_2.4.3-1_amd64.deb Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. Uploading libgdcm-tools_2.4.3-1_amd64.deb Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. Uploading libgdcm2-dev_2.4.3-1_amd64.deb Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. Uploading libgdcm2.4-dbg_2.4.3-1_amd64.deb Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. Uploading libgdcm-cil_2.4.3-1_amd64.deb Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. Uploading php5-gdcm_2.4.3-1_amd64.deb Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. Uploading libgdcm-java_2.4.3-1_amd64.deb Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. Uploading python-gdcm_2.4.3-1_amd64.deb Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. Uploading libvtkgdcm2.4_2.4.3-1_amd64.deb Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. Uploading libvtkgdcm2-dev_2.4.3-1_amd64.deb Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. Uploading libvtkgdcm-cil_2.4.3-1_amd64.deb Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. Uploading php5-vtkgdcm_2.4.3-1_amd64.deb Upload permissions error You either don't ha
ppc64 not in any-powerpc ?
I could not find the answer anywhere. Why is arch:ppc64 not in the `any-powerpc` definition ? I would have guessed arch:ppc64 to be very close to arch:powerpc... Thanks, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+7wUsw2esmUxU=G2NajhFWENpYTKzCVhAO6BQvepvLP=_a...@mail.gmail.com
Re: ppc64 not in any-powerpc ?
On Fri, Sep 12, 2014 at 12:17 PM, Andrey Rahmatullin wrote: > On Fri, Sep 12, 2014 at 11:48:26AM +0200, Mathieu Malaterre wrote: >> I could not find the answer anywhere. Why is arch:ppc64 not in the >> `any-powerpc` definition ? I would have guessed arch:ppc64 to be very >> close to arch:powerpc... > any means "any OS", not "any arches for this hardware" > https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-wildcard-spec Thanks all. I got confused with `wine` package which was built on x32 and powerpcspe, I guess those were forced by the uploaders. -M -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+7wUsxC6t_HOAT3q88=xntty1+on33u2pgcrfnby7et7-h...@mail.gmail.com
Re: Can a leaf package require SSE2 on i386?
On Sun, Sep 14, 2014 at 8:47 AM, Sébastien Villemot wrote: > Hi, > > As the maintainer of julia (a technical computing language built on top > of LLVM), I am wondering whether I should continue supporting the i386 > architecture. > > The bottom line is that julia needs SSE2 (and porting it to the x87 FPU > requires changes that are beyond what I am willing/able to do, see [1] > for more details). And the presence of SSE2 is not guaranteed on the > i386 architecture. As per ld.so man page: HARDWARE CAPABILITIES Libraries might be compiled using hardware-specific instructions which do not exist on all CPU. Such libraries should be installed in directories whose name defines the hardware capabilities such as /usr/lib/sse2/. The dynamic linker checks these directories against the hardware of the machine and selects the best suitable ver‐ sion of a given library. Hardware capabilities directories could be cascaded to combine CPU features. Hardware capabilities depends on the CPU. The following names are currently recognized: [...] x86 (32-bit only) acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386, i486, i586, i686, mca, mmx, mtrr, pat, pbe, pge, pn, pse36, sep, ss, sse, sse2, tm HTH -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+7wUszjeCz0hVVAQb9=evysce2q-axdqn3xvxlewdx84as...@mail.gmail.com
Weak c++ symbols refresher needed
Hi, I am starring at bug #758572. Basically OP reports that `cmake` is underlinked, which is a serious issue as per policy. However when reading the details it appears that this is a c++ weak symbol (AFAIK no weak default definition is available). This weak symbol is generated by default by gcc when using part of the STL (See #758572#13). So I would be tempted to simply close the bug as invalid, since weak symbol without default definition should not be an issue. However OP reports that it makes `cmake` fails using a custom `libcurl`. Could someone please remind me in which case weak symbols (no weak default definition) can trigger an undefined behavior at runtime ? Thanks. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+7wUszr9uQ-Ab9O8_GHGFkYpf==7iubeugfwa10xpsquit...@mail.gmail.com
Re: building against Clang (was: Legitimate exercise of...)
On Wed, Oct 29, 2014 at 5:02 PM, Jonas Smedegaard wrote: > Quoting Russ Allbery (2014-10-28 17:20:02) at debian-vote@l.d.o >> For the compiler, all of Debian is built with GCC, but some teams do >> test builds with Clang and report bugs, which most maintainers merge >> and some don't. > > Speaking of which: Is it Policy or just habit to use GCC over Clang? > > I ask because doxygen (and a very few others) links against > libclang1-3.5 "where available" according to the changelog, pulling in > more than 100M on systems using doxygen. libllvm3.5 is also used for > another few, including mesa. AFAIK, doxygen is still build using GCC. But it is build with the clang option turned on: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721778 2cts -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+7wUsxg56h-GKwi-Q5oAB9a=H63y48Ytn=fly9rynjbsfq...@mail.gmail.com
Re: Time for a new kernel?
On Mon, Nov 3, 2014 at 3:51 PM, Jeremy wrote: [...] > Also, look at the success of the Raspberry Pi. [...] > Preferably open-source hardware. [...] [...] https://wiki.debian.org/FreedomBox/TargetedHardware#Unsuitable -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+7wUsxs4NMUR0kkLQHv7mSKurr84NRHaEo+beai73=ghxt...@mail.gmail.com
relative path in -dbg packages
While reading the wiki page for AutomaticDebugPackages, I was wondering if it is possible to post-processed object file to manipulate relatives path for debug info ? Typical use case is that after installing the -dbg package, you end up with a gdb backtrace saying: [...] brw_meta_fast_clear (brw=brw@entry=0x7fffd4097a08, fb=fb@entry=0x7fffd40fa900, buffers=buffers@entry=2, partial_clear=partial_clear@entry=false) at ../../../../../../../src/mesa/drivers/dri/i965/brw_meta_fast_clear.c:447 447 ../../../../../../../src/mesa/drivers/dri/i965/brw_meta_fast_clear.c: No such file or directory. [...] Unless you create a fake directory tree, it is tedious to get any sense of the above. Sometimes you even get a hardcoded "/buildd" toplevel path, which may be annoying to create just to get proper context (function name, instruction...) for reporting a bug. So my questions are: 1. Is it possible to post-processed those objects file and change relative path to full path 2. Is it possible to reserve a system path for debug information, eg all debug paths should start with "/usr/src/debug" Thanks for comments, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+7wUsxjQE66LmQAwm1by_wsvtjxsMeNY9Uyw1Si6=wpxqb...@mail.gmail.com
Bug#667923: ITP: jcm -- Java Components for Mathematics
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: jcm Version : 1.0 Upstream Author : David J. Eck * URL : http://math.hws.edu/javamath * License : Public Domain Programming Lang: Java Description : Java Components for Mathematics THE "Java Components For Mathematics" project represents an effort to develop a framework of configurable mathematical software components written in the Java programming language. Our Java components are meant to be used on instructional Web pages as interactive illustrations, special-purpose calculators, support for exercises, and so forth. The components in Version 1 are mostly useful for calculus and pre-calculus and for science courses that use some of the same material. They use Java 1.1, and so will not work in some older browsers that support only Java 1.0. -- 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/20120407144732.16996.69586.report...@hpdesk.malat.net
Bug#668603: ITP: pirl -- PIRL Java Packages
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: pirl Version : 2.3.4 Upstream Author : Bradford Castalia * URL : http://pirlwww.lpl.arizona.edu/software/PIRL_Java_Packages.shtml * License : GPL-2 Programming Lang: Java Description : PIRL Java Packages Conductor: An application to manage procedure pipelines with classes to resolve references to parameters (as are used in Configuration objects) and Database fields, asynchronous thread logging of streams, and utility applications to exercise the mathematical expression evaluator (JCM) and send email notification messages to a list of recipients. The Conductor application requires (as of Java 1.4) a patch to the Process class implementation. This is provided separately in the Process.patch tarball. A sample pipeline kit for processing MOC images with the ISIS software is in the moclevall-kit tarball. . Configuration: An extension of the PVL.Parameter class for convenient management of configuration parameters. . Database: A simplified interface for access to, and basic management of, relational SQL databases. An example database query tool is included. . Image_Tools: Classes for obtaining metadata information from JP2 files, plus an ImageInputStream implementation for access to files remotely via an HTTP server. . PVL: The PIRL Parameter Value Language package provides for the input, output and manipulation of generic parameters and their data values. A PVL_to_DB class is provided to map PVL Parameter Values into Database fields for update or insert operations. . Strings: Character string manipulation capabilities used by the other PIRL packages. . Utilities: Miscellaneous utilities classes that handle various helpful operations not easily classified into the classes of other packages. . Viewers: Classes for common capabilies associated with GUI viewers, plus GUI viewers associated with other PIRL packages. -- 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/20120413113540.14279.12651.report...@hpdesk.malat.net
