RFS: cegui-mk2 (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.5.0-3 of my package "cegui-mk2". It builds these binary packages: libcegui-mk2-1 - Crazy Eddie's GUI (libraries) libcegui-mk2-1-dbg - Crazy Eddie's GUI (debugging libraries) libcegui-mk2-dev - Crazy Eddie's GUI (development files) libcegui-mk2-doc - Crazy Eddie's GUI (documentation) The package appears to be lintian clean. The upload would fix these bugs: 413896, 441685 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cegui-mk2 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cegui-mk2/cegui-mk2_0.5.0-3.dsc I would be glad if someone uploaded this package for me. Cheers, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammarelkhatib.net | http://www.teorex.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Doubt about a java version of a package
Hi *, I have a package (yacas [0]) which is providing a java-based version of itself on its latest upstream version. I have read the java-policy. I read that the file (in my case a .jar one) must be executable and installed in /usr/bin. What I am not sure it's how the application should be launched when it's installed in Debian. I'd like to know if any of you know about a package in Debian that installs a java application so I can do an apt-get source and see how to proceed. (I've tried downloading some packages making use of aptitude search but I haven't found the right one yet) I hope you can help me. Cheers, [0] http://yacas.sourceforge.net/ -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammarelkhatib.net | http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Doubt about a java version of a package
Hi Kumar, On 10/24/07, Kumar Appaiah <[EMAIL PROTECTED]> wrote: > > As far as I can tell, the JAR must be put in /usr/share/java, and the > executable must be a wrapper script which calls the java interpreter > with the right jar. For example, in case of JFTP: > > [EMAIL PROTECTED] ~] ls -l /usr/share/java/jftp* > -rw-r--r-- 1 root root 466158 2007-10-12 10:57 > /usr/share/java/jftp-1.51~pre3.jar > lrwxrwxrwx 1 root root 18 2007-10-25 08:29 /usr/share/java/jftp.jar -> > jftp-1.51~pre3.jar > > And /usr/bin/jftp has this: > #!/bin/sh > /usr/lib/jvm/java-6-sun/jre/bin/java -jar /usr/share/java/jftp.jar "$@" > > (Note that your package shouldn't explicitly use /usr/lib/jvm/ > unless you specifically require a JVM for it. You should use > /usr/bin/java, which defaults to the JVM alternative the user has set > in /etc/alternnatives/java.) > Thanks for answering quickly. Now, It's clear what I have to do. > > Well, you could see jftp, except that it's in contrib, but you may be > able to get it into main if you get it to build it with a free Java > compiler like gcj. Or, see the pkg-java list for a bigger list. > I had to use sun-java6-jdk to compile the application, so I'll have to try to build it using a free java compiler to get the java-based version into main, right? (I'm sorry for asking that but it's my first time facing a java packaging) > > I hope you can help me. > > Come to debian-java for more. :-) > I will. :) Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammarelkhatib.net | http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: cegui-mk2 (updated package)
Dear mentors, I am looking for a sponsor for the new version 1:0.5.0.dfsg-1 of my package "cegui-mk2". It builds these binary packages: libcegui-mk2-1 - Crazy Eddie's GUI (libraries) libcegui-mk2-1-dbg - Crazy Eddie's GUI (debugging libraries) libcegui-mk2-dev - Crazy Eddie's GUI (development files) libcegui-mk2-doc - Crazy Eddie's GUI (documentation) The package appears to be lintian clean. The upload would fix these bugs: 413896, 441685 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cegui-mk2 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cegui-mk2/cegui-mk2_0.5.0.dfsg-1.dsc I would be glad if someone uploaded this package for me. Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammarelkhatib.net | http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: yacas (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.2.2-1 of my package "yacas". It builds these binary packages: yacas - Computer Algebra System yacas-doc - Documentation for Yacas The package appears to be lintian clean. The upload would fix these bugs: 358401, 424878, 424889 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/y/yacas - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/y/yacas/yacas_1.2.2-1.dsc I would be glad if someone uploaded this package for me. Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammarelkhatib.net | http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: smc (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.2-1 of my package "smc". It builds these binary packages: smc- a Jump and Run game like Super Mario World written in C++ smc-data - levels and music for smc The package appears to be lintian clean. The upload would fix these bugs: 446562, 448558 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/smc - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/smc/smc_1.2-1.dsc I would be glad if someone uploaded this package for me. Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammarelkhatib.net | http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: makehuman
Dear mentors, I am looking for a sponsor for my package "makehuman". * Package name: makehuman Version : 0.9.1-rc1a-1 Upstream Author : Manuel Bastioni <[EMAIL PROTECTED]> * URL : http://www.dedalo-3d.com/ * License : GPL-3 Section : graphics It builds these binary packages: makehuman - 3D characters modeling software makehuman-data - Data files for makehuman The package appears to be lintian clean. The upload would fix these bugs: 456959 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/makehuman - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/makehuman/makehuman_0.9.1-rc1a-1.dsc I have to point out that there are two libraries that should be uploaded first for making possible that makehuman compiles: 1) Animorph: It builds these binary packages: libanimorph - C++ written library for MakeHuman libanimorph-dev - development files for libanimorph The package appears to be lintian clean. The upload would fix these bugs: 457397 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/animorph - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/animorph/animorph_0.3-1.dsc 2) MHGUI: It builds these binary packages: libmhgui - GUI widget library for MakeHuman libmhgui-dev - development files for libmhgui The package appears to be lintian clean. The upload would fix these bugs: 457396 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mhgui - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mhgui/mhgui_0.2-1.dsc I would be glad if someone uploaded those packages for me. Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammarelkhatib.net | http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tcltls & possible-gpl-code-linked-with-openssl
Hi *, I am maintaining tcltls, and now I have to upload a new version. When I ran lintian -iI I got this: W: tcltls: possible-gpl-code-linked-with-openssl N: N: This package appears to be covered by the GNU GPL but depends on the N: OpenSSL libssl package and does not mention a license exemption or N: exception for OpenSSL in its copyright file. The GPL (including N: version 3) is incompatible with some terms of the OpenSSL license, and N: therefore Debian does not allow GPL-licensed code linked with OpenSSL N: libraries unless there is a license exception explicitly permitting N: this. N: N: If only the Debian packaging, or some other part of the package not N: linked with OpenSSL, is covered by the GNU GPL, please add a lintian N: override for this tag. Lintian currently has no good way of N: distinguishing between that case and problematic packages. I am not sure how to handle this Lintian Warning. I'd be glad if someone could tell me what I have to do in this case. I added copyright terms of openssl, but Lintian still showing that warning. So in this case, how a license exemption for OpenSSL should be done? Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammarelkhatib.net | http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tcltls & possible-gpl-code-linked-with-openssl
Hi Vincent, Vincent Bernat wrote: > OoO Pendant le journal télévisé du samedi 19 avril 2008, vers 20:35, > > You cannot just add yourself the exception in debian/copyright. You > should ask upstream about this issue and tell him to add the exception > which allows to link OpenSSL to his program. This is an important issue > since your have a copyright problem with your package. > OK, so I am contacting upstream, soon. Because this package is a dependency of aMSN, package which I maintain, too. > Another solution is to use GNU TLS instead of OpenSSL. But this leads to > some invasive changes I think. > Yes, you are right. I was thinking about it, but some invasive changes should be done. Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammarelkhatib.net | http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tcltls & possible-gpl-code-linked-with-openssl
Hi Russ, Russ Allbery wrote: > > If you add the exception from upstream to the copyright file and it uses > one of the standard wordings that talks about an exception or exemption, > lintian will figure it out for itself without needing an override. > I will take care of it to avoid the use of overrides. Thanks for the advice. Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammarelkhatib.net | http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: cegui-mk2 (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.6.1-1 of my package "cegui-mk2". It builds these binary packages: libcegui-mk2-0c2a - Crazy Eddie's GUI (libraries) libcegui-mk2-0c2a-dbg - Crazy Eddie's GUI (debugging libraries) libcegui-mk2-dev - Crazy Eddie's GUI (development files) libcegui-mk2-doc - Crazy Eddie's GUI (documentation) The upload would fix these bugs: 491075, and indirectly 491590. The package can be found on: - dget http://muammar.me/~muammar/pool/cegui-mk2_0.6.1-1.dsc I would be glad if someone upload this package for me. Thanks for reading and regards, PS. I have the package in my own server because I have problems uploading packages to mentors.d.n. -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: cegui-mk2 (updated package)
Hi Barry, Barry deFreese wrote: > Muammar, > > There seems to be a few issues with lintian. Are you already aware of > these? > > [EMAIL PROTECTED]:~/debian/cegui-mk2$ lintian -I > /home/bdefreese/pbuild-unstable/result/cegui-mk2_0.6.1-1_i386.changes > W: cegui-mk2 source: patch-system-but-direct-changes-in-diff > cegui_mk2-source-0.6.1.tar.bz2.cdbs-config_list I was aware of that lintian warnig. I have tried lots of stuff, but I didn't success. Do you have any idea in how to fix this? > E: libcegui-mk2-1: > symbols-file-contains-current-version-with-debian-revision on symbol > [EMAIL PROTECTED] and 9031 > others > W: libcegui-mk2-1: symbols-file-contains-debian-revision on symbol > [EMAIL PROTECTED] and 9031 > others When I introduced libcegui-mk2-1.symbols file, I was able to make the package get rid of this error, but with the new lintian version now I see it wasn't successful. I have tried: 1) to postfix the version number like this 0.6.1-1~ and it didn't work. 2) then I tried 0.6.1 and 0.6.1~ and they didn't work either. Maybe I am doing something wrong (that's almost sure). Does anyone know what is bad about this? Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://teorex.org | http://taciturna.com ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dpkg-shlibdeps: warning: dependency on.... (they use none of its symbols)
01 (NEEDED) Shared library: [libsndfile.so.1] 0x0001 (NEEDED) Shared library: [libstdc++.so.6] 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x0001 (NEEDED) Shared library: [libpthread.so.0] Furthermore, I executed ldd which prints dependencies on Shared Libraries: $ ldd debian/quickplot/usr/bin/quickplot linux-gate.so.1 => (0xb7efe000) libgtkmm-2.4.so.1 => /usr/lib/libgtkmm-2.4.so.1 (0xb7baf000) libgiomm-2.4.so.1 => /usr/lib/libgiomm-2.4.so.1 (0xb7b4a000) libgdkmm-2.4.so.1 => /usr/lib/libgdkmm-2.4.so.1 (0xb7b01000) libatkmm-1.6.so.1 => /usr/lib/libatkmm-1.6.so.1 (0xb7abc000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb771d000) libpangomm-1.4.so.1 => /usr/lib/libpangomm-1.4.so.1 (0xb76ef000) libcairomm-1.0.so.1 => /usr/lib/libcairomm-1.0.so.1 (0xb76d5000) libglibmm-2.4.so.1 => /usr/lib/libglibmm-2.4.so.1 (0xb767d000) libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0xb7677000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb75ec000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb75d1000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb75a9000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb758f000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7585000) libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0xb7518000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb74a) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb745c000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb73e4000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb73b9000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb737c000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7378000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb72c2000) libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0xb725b000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb716d000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7147000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb713a000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6fd9000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb6fc) libz.so.1 => /usr/lib/libz.so.1 (0xb6faa000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb6e8c000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb6e89000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb6e86000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6e81000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb6e72000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6e69000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6e66000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb6e5d000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6e56000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6e4c000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6e48000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb6e19000) libselinux.so.1 => /lib/libselinux.so.1 (0xb6e0) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb6dbe000) libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0xb6d44000) libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0xb6d3b000) libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0xb6d24000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6d0) libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0xb6cfc000) libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb6cf4000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6cdb000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb6cb5000) libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0xb6c62000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb6b69000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb6b3f000) libogg.so.0 => /usr/lib/libogg.so.0 (0xb6b3a000) /lib/ld-linux.so.2 (0xb7eff000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb6b37000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6b32000) So, if I look into the output of those two commands the libraries that dpkg-shlibdeps warn me of, I can see that they seem to be used by the binary. Maybe this is a bug in the libraries and not in quickplot. I don't know if I am right in this, I have had to read lots of documents to think this. The solution should be to avoid linking quickplot to those libraries. I have researched how to do it, but I haven't found how can I do it. I thought to override the automatic detected sha
Re: dpkg-shlibdeps: warning: dependency on.... (they use none of its symbols)
Hi, Thank you so much to all of you for answering the mail and all of my doubts. I'll ignore the warnings in the meanwhile and contact Upstream and GTK+ maintainers later. I don't think that using --as-needed flag would be a good option, IMHO. I believe that If I passed this flag it would not work in all architectures, so it will make quickplot brake on some of them. The fact that makes me strong on this argument, It's that linking a binary correctly is something that does not only depends on how the binary is being linked at compilation time, it also depends on how its dependencies are linked, too. Another reason would be one that I read in one of the links that Paul sent: 1) "It's known not to work on FreeBSD and probably does not work on other non-Linux targets." 2) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502083 3) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320697 Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps: warning: dependency on.... (they use none of its symbols)
On Sun, Mar 22, 2009 at 1:18 PM, Chow Loong Jin wrote: >> >> 1) "It's known not to work on FreeBSD and probably does not work on other >> non-Linux targets." >> >> 2) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502083 >> >> 3) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320697 > But Debian is not BSD, it's a GNU/Linux distribution is it not? Also, No, Debian is not BSD. But we have this http://www.debian.org/ports/kfreebsd-gnu/: "Debian GNU/kFreeBSD is a port that consists of GNU userland using the GNU C library on top of FreeBSD's kernel, coupled with the regular Debian package set." Now, as you can see at #502083 and #320697 the use of the flag has gotten problems before. > I'm not too sure about the whole breaking-on-other-archs issue. I've got > some packages with the ltmain.sh as needed patch, and -Wl,--as-needed in > LDFLAGS, and they built on all the target architectures[1]. > Well, I am not sure either because it is the first time I face this problem. But, If I've read well in #502083 there says: "--as-needed is only used on arm and armel builds, while it should be exactly opposite :( Incidentally it also shows that --as-needed is ok for arm (but not for armel)." While in arm it was ok, in armel the use of --as-needed flag didn't work. So, the use of such a flag could be _problematic_. > [1] https://launchpad.net/ubuntu/jaunty/+source/geanyvc/0.4-0ubuntu1 Well, this package is not into Debian archive yet, there is only an ITP. I know that Debian supports 12 architectures (http://www.debian.org/releases/stable/) while Ubuntu only supports 6 https://help.ubuntu.com/8.10/installation-guide/i386/hardware-supported.html so I think your argument about geanyvc does not apply at all for Debian. Regards, -- Muammar El Khatib. Linux user: 403107. GPG Key = 127029F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps: warning: dependency on.... (they use none of its symbols)
On Sun, Mar 22, 2009 at 2:37 PM, Chow Loong Jin wrote: > > Ah, my bad. Thanks for clarifying. Either way isn't that bug marked as > fixed? Which would mean all the issues discussed in the bug are also > fixed? Sure, It was marked as fixed. But it doesn't assure anything to me. I mean, even if it was marked as fixed, I shouldn't expect that my case would be the same. I'd prefer to contact GTK+ maintainers (taking care about what is said in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456335) or wait a little bit, instead of setting a flag that could lead problems in other architectures just to avoid a dpkg-shlibdeps warning (knowing that the real reason of those warnings are related to the *.pc files of the gtk's libraries). Regards, -- Muammar El Khatib. Linux user: 403107. GPG Key = 127029F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
debian/watch question
Hi debian-mentors,
I have this URL for downloading a package:
http://www.mcs.anl.gov/research/projects/mpich2/downloads/index.php?s=downloads
When you click on the link for downloading the application it sends you to:
http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/1.1.1p1/mpich2-1.1.1p1.tar.gz
So I thought that If I was able to make uscan look into
http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/ I'd get the
last version of the package checked correctly. I have this in debian/watch:
# Compulsory line, this is a version 3 file
version=3
http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/(\d\.\d)/mpich2-(.*)\.tar\.gz
Which is wrong,because it gives me this as result:
muam...@obey:~/src/main/libs/mpich2/mpich2$ uscan --report
Processing watchfile line for package mpich2...
Newest version on remote site is 1.1, local version is 1.1+dfsg.1
mpich2: remote site does not even have current version
muam...@obey:~/src/main/libs/mpich2/mpich2$
So, as can be seen the version that uscan sees with my debian/watch file is
version 1.1 while the current one is 1.1.1p1. The other error I see is that the
local version the +dfsg.1 is taken in account. I know I can avoid this by
mangling that debian version part¹.
Reading the uscan's manual I saw this:
# The filename is found by taking the last component of the URL and
# removing everything after any '?'. If this would not make a usable
# filename, use filenamemangle. For example,
# http://foo.bar.org/download/?path=&download=foo-0.1.1.tar.gz";>
# could be handled as:
# opts=filenamemangle=s/.*=(.*)/$1/ \
# http://foo.bar.org/download/\?path=&download=foo-(.*)\.tar\.gz
#
# http://foo.bar.org/download/?path=&download_version=0.1.1";>
# could be handled as:
# opts=filenamemangle=s/.*=(.*)/foo-$1\.tar\.gz/ \
#http://foo.bar.org/download/\?path=&download_version=(.*)
# The option downloadurlmangle can be used to mangle the URL of the file
# to download. This can only be used with http:// URLs. This may be
# necessary if the link given on the webpage needs to be transformed in
# some way into one which will work automatically, for example:
# opts=downloadurlmangle=s/prdownload/download/ \
# http://developer.berlios.de/project/showfiles.php?group_id=2051 \
# http://prdownload.berlios.de/softdevice/vdr-softdevice-(.*).tgz
I made some tries with each of them, but I always got no matches :(. How can I
reach the correct version for this package? I still try it. If someone could
help me I'd appreciate it.
Thanks for reading,
1. Mangling debian version
# Similarly, the upstream part of the Debian version number can be
# mangled:
opts=dversionmangle=s/\.dfsg\.\d+$// \
--
Muammar El Khatib.
Linux user: 403107.
GPG Key = 127029F1
http://muammar.me | http://proyectociencia.org
,''`.
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian/watch question
Hi Bart, On Sun, Aug 23, 2009 at 11:25 AM, Bart Martens wrote: > On Sun, Aug 23, 2009 at 11:02:53AM -0430, Muammar El Khatib wrote: >> I made some tries with each of them, but I always got no matches :(. How can >> I >> reach the correct version for this package? I still try it. If someone could >> help me I'd appreciate it. > > version=3 > opts="dversionmangle=s/\+dfsg\.\d+$//" \ > http://www.mcs.anl.gov/research/projects/mpich2/downloads/index.php?s=downloads > \ > .*/mpich2-(.*)\.tar\.gz > Thank you. It worked. I was doing it badly :-/ Regards, -- Muammar El Khatib. Linux user: 403107. GPG Key = 127029F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Question about a library that is not creating its *.so* files
Hi, I maintain a package which is called CEGUI. In current SID version (0.6.2), when you compile it, the next files under usr/lib are created: libCEGUIBase.la libCEGUIBase.so libCEGUIBase.so.1 libCEGUIBase.so.1.2.0 libCEGUIDevILImageCodec.la libCEGUIDevILImageCodec.so libCEGUIDevILImageCodec.so.0 libCEGUIDevILImageCodec.so.0.0.0 libCEGUIdirectfbRenderer.la libCEGUIdirectfbRenderer.so libCEGUIdirectfbRenderer.so.0 libCEGUIdirectfbRenderer.so.0.0.0 libCEGUIExpatParser.la libCEGUIExpatParser.so libCEGUIExpatParser.so.0 libCEGUIExpatParser.so.0.0.0 libCEGUIFalagardWRBase.la libCEGUIFalagardWRBase.so libCEGUIFalagardWRBase.so.1 libCEGUIFalagardWRBase.so.1.2.0 libCEGUILibxmlParser.la libCEGUILibxmlParser.so libCEGUILibxmlParser.so.0 libCEGUILibxmlParser.so.0.0.0 libCEGUILuaScriptModule.la libCEGUILuaScriptModule.so libCEGUILuaScriptModule.so.1 libCEGUILuaScriptModule.so.1.2.0 libCEGUIOpenGLRenderer.la libCEGUIOpenGLRenderer.so libCEGUIOpenGLRenderer.so.0 libCEGUIOpenGLRenderer.so.0.1.0 libCEGUISampleHelper.la libCEGUISampleHelper.so libCEGUISampleHelper.so.1 libCEGUISampleHelper.so.1.2.0 libCEGUITGAImageCodec.la libCEGUITGAImageCodec.so libCEGUITGAImageCodec.so.0 libCEGUITGAImageCodec.so.0.0.0 libCEGUITinyXMLParser.la libCEGUITinyXMLParser.so libCEGUITinyXMLParser.so.0 libCEGUITinyXMLParser.so.0.0.0 libCEGUItoluapp.la libCEGUItoluapp.so libCEGUItoluapp.so.1 libCEGUItoluapp.so.1.2.0 libCEGUIXercesParser.la libCEGUIXercesParser.so libCEGUIXercesParser.so.0 libCEGUIXercesParser.so.0.0.0 pkgconfig In most recent upstream version, when you compile it you will get this instead: libCEGUIBase-0.7.0.so libCEGUIBase.la libCEGUIBase.so libCEGUIDevILImageCodec-0.7.0.so libCEGUIDevILImageCodec.la libCEGUIDevILImageCodec.so libCEGUIExpatParser-0.7.0.so libCEGUIExpatParser.la libCEGUIExpatParser.so libCEGUIFalagardWRBase-0.7.0.so libCEGUIFalagardWRBase.la libCEGUIFalagardWRBase.so libCEGUILibxmlParser-0.7.0.so libCEGUILibxmlParser.la libCEGUILibxmlParser.so libCEGUILuaScriptModule-0.7.0.so libCEGUILuaScriptModule.la libCEGUILuaScriptModule.so libCEGUIOpenGLRenderer-0.7.0.so libCEGUIOpenGLRenderer.la libCEGUIOpenGLRenderer.so libCEGUISampleHelper-0.7.0.so libCEGUISampleHelper.la libCEGUISampleHelper.so libCEGUITGAImageCodec-0.7.0.so libCEGUITGAImageCodec.la libCEGUITGAImageCodec.so libCEGUITinyXMLParser-0.7.0.so libCEGUITinyXMLParser.la libCEGUITinyXMLParser.so libCEGUItoluapp-0.7.0.so libCEGUItoluapp.la libCEGUItoluapp.so libCEGUIXercesParser-0.7.0.so libCEGUIXercesParser.la libCEGUIXercesParser.so pkgconfig As can be seen above, there is no usr/lib/libCEGUI*.so.* files.I have looked into the configure file and there is this option: --enable-shared[=PKGS] build shared libraries [default=yes] So I cannot understand, Why this kind of stuff happen if the shared libraries are supposed to be created by default? Maybe this kind of question in silly, but what I would like to know is why it happens. I will appreciate your comments. Regards, -- Muammar El Khatib. Linux user: 403107. GPG Key = 127029F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about a library that is not creating its *.so* files
Hi Mike and Samuel, On Wed, Oct 7, 2009 at 11:24 AM, Mike Hommey wrote: > On Wed, Oct 07, 2009 at 05:49:39PM +0200, Mike Hommey wrote: >> On Wed, Oct 07, 2009 at 11:01:05AM -0430, Muammar El Khatib wrote: >> > Hi, >> > >> > I maintain a package which is called CEGUI. In current SID version >> > (0.6.2), when you compile it, the next files under usr/lib are >> > created: >> > >> >> > >> > As can be seen above, there is no usr/lib/libCEGUI*.so.* files.I have >> > looked into the configure file and there is this option: >> > >> > --enable-shared[=PKGS] build shared libraries [default=yes] >> > >> > So I cannot understand, Why this kind of stuff happen if the shared >> > libraries are supposed to be created by default? Maybe this kind of >> > question in silly, but what I would like to know is why it happens. I >> > will appreciate your comments. >> >> libname-x.y.z.so is another valid for for libname.so.x.y.z. > I thought so. > That should read: libname-x.y.z.so is another valid form. > I'll also add it is (supposed to be) supported by packaging tools. So it is not necessary to create symlinks to have libname.so.x.y.z, isn't it? On Wed, Oct 7, 2009 at 11:22 AM, Peter Samuelson wrote: > > [Muammar El Khatib] >> In most recent upstream version, when you compile it you will get this >> instead: >> >> libCEGUIBase-0.7.0.so >> libCEGUIBase.la >> libCEGUIBase.so > > That looks fine. If you look closely you will probably see that > libCEGUIBase.so is a symlink to libCEGUIBase-0.7.0.so. > Yes, you are right. >> So I cannot understand, Why this kind of stuff happen if the shared >> libraries are supposed to be created by default? > > Run 'file' on those files, you'll see they are what they're supposed to be. > They are share object files: $ file libCEGUILuaScriptModule-0.7.0.so libCEGUILuaScriptModule-0.7.0.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped > Then, just to make sure you're getting what you should be getting, > check the SONAMEs, make sure they match the *-0.7.0.so filenames. > $ objdump -p libCEGUIDevILImageCodec-0.7.0.so | grep SONAME SONAME libCEGUIDevILImageCodec-0.7.0.so They match :) > And if indeed the SONAMEs have changed (as it appears they have), make > sure to update the binary package names and shlibs files accordingly. You made me recall http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423502 > And ask the debian-release list before uploading, since what you now > have on your hands is a library transition. > I will write them before uploading. > And see if it's possible to remove the .la files, as was discussed on > debian-devel awhile back. I'll look for the thread about removing .la files in debian-devel. Thank you very much, it was very helpful all the information that both of you have given to me. Regards, -- Muammar El Khatib. Linux user: 403107. GPG Key = 127029F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about a library that is not creating its *.so* files
On Wed, Oct 7, 2009 at 11:42 AM, Muammar El Khatib wrote: > Hi Mike and Samuel, I am sorry. I meant to Peter. Regards -- Muammar El Khatib. Linux user: 403107. GPG Key = 127029F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
libfoo.so.X symlink not created at build time
Hi *, I'm maintaining a library which new upstream version is creating at build time *.la, *.so (development symlink), and the library itself with the form libfoo-x.y.z.so but not their symlinks that match their SONAME (I was expecting something like libfoo.so.X). My question is if it'd be safe to just create those "missing" symlinks using a libfoo.links file in the debian packaging part, or should I look for a different solution. I'd appreciate if someone could help me to give a proper way of solving this doubt that I have. Best regads, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104155145.ga10...@prank.debian.org
Re: libfoo.so.X symlink not created at build time
Hi Bernhard, On Tue, Jan 04, 2011 at 05:36:37PM +0100, Bernhard R. Link wrote: > * Muammar El Khatib [110104 16:52]: > > I'm maintaining a library which new upstream version is creating at build > > time > > *.la, *.so (development symlink), and the library itself with the form > > libfoo-x.y.z.so but not their symlinks that match their SONAME (I was > > expecting something like libfoo.so.X). > > Please take a look what their actual SONAME is (using readelf -d). > Here I am pasting an example: $ readelf -d libCEGUIBase-0.7.5.so Dynamic section at offset 0x2e2898 contains 30 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [liblua5.1.so.0] 0x0001 (NEEDED) Shared library: [libfreetype.so.6] 0x0001 (NEEDED) Shared library: [libpcre.so.3] 0x0001 (NEEDED) Shared library: [libpthread.so.0] 0x0001 (NEEDED) Shared library: [libdl.so.2] 0x0001 (NEEDED) Shared library: [libstdc++.so.6] 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] 0x000e (SONAME) Library soname: [libCEGUIBase-0.7.5.so] 0x000c (INIT) 0xeb6c0 0x000d (FINI) 0x263af8 0x0004 (HASH) 0x1b8 0x6ef5 (GNU_HASH) 0xb2c0 0x0005 (STRTAB) 0x42750 0x0006 (SYMTAB) 0x18198 0x000a (STRSZ) 381724 (bytes) 0x000b (SYMENT) 24 (bytes) 0x0003 (PLTGOT) 0x4e5bb0 0x0002 (PLTRELSZ) 51288 (bytes) 0x0014 (PLTREL) RELA 0x0017 (JMPREL) 0xdee68 0x0007 (RELA) 0xa33d8 0x0008 (RELASZ) 244368 (bytes) 0x0009 (RELAENT)24 (bytes) 0x6ffe (VERNEED)0xa32e8 0x6fff (VERNEEDNUM) 6 0x6ff0 (VERSYM) 0x9fa6c 0x6ff9 (RELACOUNT) 177 0x (NULL) 0x0 > While the SONAME usually is something like libfoo.so.X, it might also be > anything else (and the dynamic linker will that look for that file at > runtime). If the SONAME is not libfoo.so.X there is no need to have a > symlink of that name. > I think I have understood you. So, in this case I am showing I don't need the symlinks of type libfoo.so.X because the SONAME is itself the libfoo-x.y.z.so. > If you have something like libfoo-X.so there, then this is not a > development symlink, but the SONAME symlink. (so if any doc says > .so.X they mean -X.so in that case and if they say .so they mean the > real .so file and not the -X.so). > Then, I should provide in the library package _only_ the lib*-x.y.z.so files, and obviously the *.la and *.so development symlinks into -dev package. Please, correct me if I am wrong. Now, packages which depends on this library to build are going to fail with this change. It can be said that a library transition has to be done. I'll rebuild packages gotten by executing apt-cache rdepends, and contact maintainers. Could it be said that a "safe" upload would be when at least all those dependent packages have a workaround (in case of failing to build)?. I am sorry for these questions as basic as they can seem. It's my first time facing a library transition, and for what I have read I am aware of the complexity of it. > As stupid as this is (especially the mixing of namespaces for > filenames), there are sadly enough libraries already doing it this way > and there is technically no problem with it. Thanks for the information and your help, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104214241.ga15...@prank.debian.org
Re: libfoo.so.X symlink not created at build time
On Wed, Jan 05, 2011 at 11:41:40AM +0100, Bernhard R. Link wrote: > > I think I have understood you. So, in this case I am showing I don't need > > the > > symlinks of type libfoo.so.X because the SONAME is itself the > > libfoo-x.y.z.so. > > yes. > Thanks for confirming this. > > > > > If you have something like libfoo-X.so there, then this is not a > > > development symlink, but the SONAME symlink. (so if any doc says > > > .so.X they mean -X.so in that case and if they say .so they mean the > > > real .so file and not the -X.so). > > > > > > > Then, I should provide in the library package _only_ the lib*-x.y.z.so > > files, > > and obviously the *.la and *.so development symlinks into -dev package. > > Please, > > correct me if I am wrong. > > yes. > > Also note that your soname now includes the whole 0.7.5 part, so that > this number should most likely be part of the library package *name*. > (as the -1 seem to have been before). > Yes. I had read that in the Library Packaging Guide. > > Now, packages which depends on this library to build are going to fail with > > this > > change. > > Things that build-depend on this package should most likely still be > build-able with the -dev package installed. (Unless that version changes > something else in comparison to packages already in the archive). > I hope that most of them be able of build with the -dev package installed. But I tried with one that I maintain and it failed. > > It can be said that a library transition has to be done. I'll rebuild > > packages gotten by executing apt-cache rdepends, and contact maintainers. > > If the API did not change, then those packages might only need an > binNMU. > OK. > Also note that as the version in the soname seems to be the whole version > of the library (at least I guess so, as it is as 0.7.5 seems quite > similar to the package upstream version of 0.6.2 in sid), > every future minor upstream release will most likely change the soname and > need a full library transition cycle (and perhaps waiting for NEW and so on). > That is pretty bad, the need of a full library transition cycle for every minor upstream release :( > In other words: Unless you have some LART big enough to get upstream > to switch back to stable ABIs, think twice if you want to keep > maintaining this library or if simply droping it from Debian might be > the better solution. I fear it might be everything but pleasent to deal with > this all the time. > I think I lean more for trying first to talk to upstream about this. Not sure if I will succeed in this, either. > If you keep maintaining it, I'd also suggest asking the release team for > advice (as they will have to deal with those transitions). Ideally after > squeeze release, though. > OK. Yes, I was thinking in uploading this after squeeze is released to not interfere with the process of releasing. Thank you very much for your help. -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110106115508.ga24...@prank.debian.org
Re: RFS: rgbpaint
Dear Mats, On Mon, Jan 10, 2011 at 07:33:06PM +0100, Mats Erik Andersson wrote: > Dear mentors, > > This is a reminder as no response has surfaced. I am still looking > for a sponsor of this package. > > Package name: rgbpaint > Version : 0.8.7-1 > Upstream Author : Mark Tyler > URL : http://mtpaint.sourceforge.net/rgbpaint.html > License : GPL-2 > Section : graphics > I have these observations: 1) debian/copyright 1.1) There is an error in the link provided in the Format-Specification field: http://sv.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 It should be: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 1.2) Furthermore, copyright file has to be encoded in UTF-8 but it is not: $ file debian/copyright debian/copyright: ASCII Pascal program text I took as an example altree: $ file debian/copyright debian/copyright: UTF-8 Unicode English text 1.3) It seems that License field is repeated in section Files: debian/* (Look at the complexe example in http://dep.debian.net/deps/dep5/#index7h1) 1.4) Not all copyright holders are represented in debian/copyright. See for example: rgbpaint-0.8.7/po/* files. 2. debian/README.debian please, remove line 31 because it is empty. If you agree in changing what I pointed above, I can upload it for you. Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110111234935.ga26...@prank.debian.org
Re: RFS: rgbpaint
On Wed, Jan 12, 2011 at 12:32:23AM +, The Fungi wrote: > On Wed, Jan 12, 2011 at 12:49:35AM +0100, Muammar El Khatib wrote: > [...] > > 1.1) There is an error in the link provided in the > > Format-Specification field: > > http://sv.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 > > > > It should be: > > http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 > [...] > > If you're going into that, I'd recommend checking out the DEP5 tread > from debian-devel earlier this week: > > http://lists.debian.org/debian-devel/2011/01/msg00230.html > I had already read it. I got confused with the version used (I was thinking in rev=153 while the one used in the packaging was rev=135. Last one it is rev=155). So, for 1.1 the correct link for Format-Specification field is: http://dep.debian.net/deps/dep5/ Thanks for pointing this out, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110112012904.ga17...@prank.debian.org
Re: RFS: rgbpaint
On Wed, Jan 12, 2011 at 10:36:26AM +0100, Mats Erik Andersson wrote: > onsdag den 12 januari 2011 klockan 00:49 skrev Muammar El Khatib detta: > > Dear Mats, > > > > On Mon, Jan 10, 2011 at 07:33:06PM +0100, Mats Erik Andersson wrote: > > 1) debian/copyright > > 1.1) There is an error in the link provided in the Format-Specification > > field: > > http://sv.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 > > > > It should be: > > http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 > > Updated to conform with http://dep.debian.net/deps/dep5/. > OK. > > 1.3) It seems that License field is repeated in section Files: debian/* > > (Look > > at the complexe example in http://dep.debian.net/deps/dep5/#index7h1) > > No action: This is the "Standalone License Paragraph" formatting. > I learned this from the Perl Team. > OK. I have checked the Standalone License Paragraph formatting. You are right, it is fine. > > > > 1.4) Not all copyright holders are represented in debian/copyright. See > > for > > example: rgbpaint-0.8.7/po/* files. > > Copyright stanza has been added for all explicit translators. > Uploaded. Thanks for your contribution to Debian. Best Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110112220345.ga9...@prank.debian.org
Re: RFS: rgbpaint
On Wed, Jan 12, 2011 at 02:47:28AM +0100, Jakub Wilk wrote: > * Muammar El Khatib , 2011-01-12, 00:49: > >$ file debian/copyright > >debian/copyright: ASCII Pascal program text > > Uhm, sorry, no, file cannot be used to determine encodings. Besides, > UTF-8 is a superset of ASCII, so everything is all right according > to file. What would you suggest to me for determining encodings? Something like enca can be useful in these cases? -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110112221741.gb9...@prank.debian.org
Re: RFS: gts (updated package)
Hi Ruben, On Sun, Feb 13, 2011 at 12:45:06AM -0500, Ruben Molina wrote: > Dear mentors, > > I am looking for a sponsor for the new version 0.7.6+darcs101112-1 > of my package "gts". > Please, update the Format-Specification field of debian/copyright. Your watch file is reporting a new version of the package. Do you have an specific reason for uploading this version instead of the newest one? More than that your package seems pretty good, and I'd be glad of uploading it for you after clarifying what I wrote above. Best Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110213154202.ga28...@prank.debian.org
Re: RFS: gts (updated package)
On Sun, Feb 13, 2011 at 12:13:50PM -0500, Ruben Molina wrote: > El dom, 13-02-2011 a las 16:42 +0100, Muammar El Khatib escribió: > > On Sun, Feb 13, 2011 at 12:45:06AM -0500, Ruben Molina wrote: > > > I am looking for a sponsor for the new version 0.7.6+darcs101112-1 > > > of my package "gts". > > Please, update the Format-Specification field of debian/copyright. Your > > watch > > file is reporting a new version of the package. Do you have an specific > > reason > > for uploading this version instead of the newest one? > > Hi Muammar, > Thanks for your review. > > I updated the format of debian/copyright to DEP-5 Rev. 166, and I also > packaged the latest upstream tarball. I hadn't noticed this new release, > but in fact is just including a patch we forwarded from Debian. > I see. So, it is OK. > The package can be found on mentors.debian.net: > - dget > http://mentors.debian.net/debian/pool/main/g/gts/gts_0.7.6+darcs110121-1.dsc Uploaded. Thanks for your contribution. Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110213223320.ga1...@prank.debian.org
Package being built with mruby version different from the one in the debian archive
Dear mentors, There is a package I maintain that was abandoned, but now it has been forked. I have decided to upload a new version renaming it, and following instructions in [1]. In this new project, and that is the doubt I have, the package is being built using a version of mruby[2] different from the one in the debian archive. In addition, new upstream authors are using 3rd-party mruby extensions[4]. I believe this represents a problem because in theory a debian package has to be able to compile with already distributed binaries/libs in the archive. As you may have noticed, this would be the first time I intend to upload a package that depends on ruby. Would it be fine to upload the package compiled with these upstream shipped versions of mruby/extensions? or does it has absolutely to be compiled with the versions present in the debian archive?. I ask it because those mruby parts are compiled statically. I would be glad if anyone could help me with this. Regards, [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#s5.9.3 [2] https://github.com/Secretchronicles/TSC/blob/v2.0.0-rc1/tsc/mruby_tsc_build_config.rb [3] https://github.com/Secretchronicles/TSC/tree/v2.0.0-rc1/mruby/mgems [4] https://github.com/Secretchronicles/TSC/tree/devel/mruby -- Muammar El Khatib. Linux user: 403107. GPG Key = 71246E4A. http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150802103906.ga2...@zarathustra.debian.org
Re: Package being built with mruby version different from the one in the debian archive
On Mon, Aug 03, 2015 at 11:31:35AM +0800, Paul Wise wrote: > On Sun, Aug 2, 2015 at 6:39 PM, Muammar El Khatib wrote: > > > Would it be fine to upload the package compiled with these upstream shipped > > versions of mruby/extensions? or does it has absolutely to be compiled with > > the > > versions present in the debian archive?. > > Debian policy is to not use embedded code copies. I would suggest > working with your upstream to get their mruby changes merged into > mruby upstream and then get your upstream to remove their mruby > embedded code copies. The extensions would need to be packaged for > Debian too. > > https://wiki.debian.org/EmbeddedCodeCopies > Thanks for your response. I imagined following a path like this. I will discuss again with upstream about it. > > I ask it because those mruby parts are compiled statically. I would be glad > > if > > anyone could help me with this. > > Dynamic linking is preferred to static linking so if you can get rid > of that it would be good too. > > https://wiki.debian.org/StaticLinking > Thanks for the link again. Regards, -- Muammar El Khatib. Linux user: 403107. GPG Key = 71246E4A. http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150805145941.ga3...@zarathustra.debian.org
Re: RFS: tucan (updated package)
Hi Julián, On Thu, Apr 07, 2011 at 07:07:13AM -0500, Julián Moreno Patiño wrote: > Dear mentors, > > I am looking for a sponsor for the new version 0.3.10-1 of my package "tucan". > > It builds these binary packages: > tucan - Download and upload manager for 1-Click Hosters > > The package appears to be lintian clean. > > The upload would fix these bugs: 573561, 595156, 608293 > Just two tiny remarks. The first one, erase the blank space at the end of the file debian/tucan.menu The other one is that you updated watch file for closing #573561, and I am getting 404 Not Found: $ uscan --report uscan warning: In watchfile debian/watch, reading webpage http://code.google.com/p/tucan/downloads/detail?name= failed: 404 Not Found Could you tell me if you get the same problem as well? More than that, it will be ok for me to upload the package. I'll be waiting for your response. Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110411101443.gb29...@prank.debian.org
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Tue, Jan 17, 2012 at 10:59:14PM +0100, Ansgar Burchardt wrote: > SUMMARY > === > > We plan to ask for the creation of a new pseudo-package > debian-mentors or mentors.debian.org [3] (contact: > debian-mentors@lists.debian.org) in Debian's bug tracking system (the > name is still subject to change). A workflow for handling sponsoring > requests is proposed below. It is based on an earlier discussion on the > debian-mentors list[1]. > This is a really smart, simple and good idea to use the BTS. I sometimes just keep the RFS packages which get no replies marked as unread in mutt for keeping a track on this and try to help people (not that much recently, duties in real life don't give that much time for me), but if this idea gets to be implemented I am sure we'll have a better panorama of the packages that need to be uploaded. On the other hand I found just great the REVIEWING packages section. This is a key for attracting more contributors, because the sponsoring process can be really frustrating sometimes. In addition, the confirmed tag is really nice because it allows others with no upload rights to start doing revisions and that will facilitate (in some cases of course) the work of the ones who have upload rights and will help themselves because they will learn more about the Debian Policy. I know my mail does not contribute in some sense to this proposal, but I just felt the *need* of writing how great I found it. On the other hand, I don't find as a hassle the fact that sponsors have to close the reports manually. > > DRIVERS > === > > Ansgar Burchardt > Jakub Wilk > Arno Töll > gregor herrmann Congratulations to the $DRIVERS :) Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119151507.ga32...@ihacku.debian.org
Bug#955322: RFS: pulseaudio-dlna -- stream audio to DLNA devices and Chromecasts
On Mon, Mar 30, 2020 at 6:22 AM Fabian Wolff wrote: > > Hi Adam and Muammar, > > thanks for your quick replies! Adam, thank you for looking over my changes and > sponsoring the upload. > > One more thing: As I said in my original email, I have a Git repository set up > for this package, but I don't have the necessary permissions to create a > repository in the "Debian" group on Salsa, so could one of you (or somebody > else) please create the repository and give me "Maintainer" access to it, so > that I can push to it? > > https://salsa.debian.org/debian/pulseaudio-dlna Does it seem you already got access? https://salsa.debian.org/debian/pulseaudio-dlna/-/commit/61d6ee13c13eb76cb6b70b6b50c2fb5efe04dc7f Best, -- Muammar El Khatib. GPG Key = 71246E4A. https://muammar.me ,''`. : :' : `. `' `-
