Re: New NM Front-desk Member
On Sun, Aug 30, 2009 at 10:49:29PM +0200, Bernd Zeimetz wrote:
> the New-Maintainer Front-desk is happy to announce that Enrico Zini
> followed our invitation to join the
> team. Welcome on board and many thanks for volunteering!
Yu-hu \o/
... and thanks to the (now enlarged) FD group for their sometime
thankless work.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#544399: ITP: rakudo -- implementation of Perl 6 for Parrot
Package: wnpp Owner: Ryan Niebur Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: rakudo Version : "2009-08" aka PDX (will probably use 0.1~2009-08-1 for the package version) Upstream Author : The Rakudo Team * URL : http://rakudo.org/ * License : Artistic License 2.0 Programming Lang: Parrot Description : implementation of Perl 6 for Parrot Rakudo Perl is an implementation of the Perl 6 specification that runs on the Parrot virtual machine. I won't be able to upload this for a while, because previous to the current git version the build system didn't work with system installed parrot. parrot and rakudo release go together (monthly), but the debian maintainer of parrot only uploads the "stable" releases. So I have to wait for the next stable version of parrot to be released and uploaded to debian, and then for the corresponding version of rakudo to be released. So it will probably be a few months... -- _ Ryan Niebur ryanrya...@gmail.com signature.asc Description: Digital signature
Bug#544402: ITP: r-cran-erm -- GNU R package for extended Rasch modelling
Package: wnpp Severity: wishlist Owner: Julian Gilbey Package name: r-cran-erm Version : 0.10-2 Upstream Author : Patrick Mair and Reinhold Hatzinger URL : http://r-forge.r-project.org/projects/erm/ License : GPL-2 Programming Lang: R and C Description : GNU R package for extended Rasch modelling eRm fits Rasch models (RM), linear logistic test models (LLTM), rating scale model (RSM), linear rating scale models (LRSM), partial credit models (PCM), and linear partial credit models (LPCM). Missing values are allowed in the data matrix. Additional features are the ML estimation of the person parameters, Andersen's LR-test, item-specific Wald test, itemfit and personfit statistics including infit and outfit measures, various ICC and related plots, automated stepwise item elimination, simulation module for various binary data matrices. An eRm platform is provided at R-forge (see URL). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544422: ITP: ibus-table-wu -- Wu input method based on table engine of ibus
Package: wnpp Severity: wishlist Owner: Asias He * Package name: ibus-table-wu Version : 1.2.0.20090831 Upstream Author : Caius "kaio" Chance * URL : http://code.google.com/p/ibus * License : GPLv2 Programming Lang: N/A Description : Wu input method based on table engine of ibus IBus-Table is the IM Engine framework for table-based input methods, such as WuBi, ErBi, Cangjie and so on. . This package provides one input method: Wu. . Wu is a Chinese input method. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544427: ITP: ibus-table-ziranma -- Ziranma input method based on table engine of ibus
Package: wnpp Severity: wishlist Owner: Asias He * Package name: ibus-table-ziranma Version : 1.2.0.20090831 Upstream Author : Caius "kaio" Chance * URL : http://code.google.com/p/ibus * License : GPLv2 Programming Lang: N/A Description : Ziranma input method based on table engine of ibus IBus-Table is the IM Engine framework for table-based input methods, such as WuBi, ErBi, Cangjie and so on. .. This package provides one input method: Ziranma. .. Ziranma is a Chinese input method. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544432: ITP: ibus-table-stroke5 -- Stroke5 input method based on table engine of ibus
Package: wnpp Severity: wishlist Owner: Asias He * Package name: ibus-table-stroke5 Version : 1.2.0.20090828 Upstream Author : Caius 'kaio' Chance < k AT kaio DOT me > * URL : http://code.google.com/p/ibus * License : GPLv2 Programming Lang: N/A Description : Stroke5 input method based on table engine of ibus IBus-Table is the IM Engine framework for table-based input methods, such as WuBi, ErBi, Cangjie and so on. . This package provides one input method: Stroke5. . Stroke5 is a Simplified Chinese input method. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Future of the s390 port
Hi folks The s390 port was released with Lenny. However it is not in the best condition. There are mainly two problems which needs attention, lack of manpower and a 64 bit userland. The first problem is the worst. Currently only Frans Pop and I do work on it. Frans only does the Debian-Installer part and I simply have not enough time to do the rest. The s390 architecture is quite different to anything else, so it needs several specialized packages to work[1] and they need lasting attention. So if anyone wants to help (especially Debian developers) for the continuity of this port please speak up. The second problem is not that critical. No other distribution still supports a complete 31 bit s390 userland and even Debian dropped the 31 bit kernel support in the meantime[2]. Strategies for an upgrade to a 64 bit userland was discussed lately[3]. I doubt that I would be able to push this port through another release in the current state. The consequence would by that the port dies completely and with it the only free and released distribution for this machines. Bastian [1]: Mainly the kernel, generic tools (s390-tools), hardware support (sysconfig-hardware) and a whole bunch of debian-installer packages. [2]: <20090524185816.ga21...@wavehammer.waldi.eu.org> [3]: <20090818204335.ga6...@droopy.oc.cox.net> -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3 signature.asc Description: Digital signature
Re: Future of the s390 port
On Aug 31, Bastian Blank wrote: > I doubt that I would be able to push this port through another release > in the current state. The consequence would by that the port dies > completely and with it the only free and released distribution for this > machines. Is this really an important problem? Does a significant number of people actually use Debian/s390 on production servers? And if they exist, why they are not helping? -- ciao, Marco signature.asc Description: Digital signature
Bug#544441: RFA: enemies-of-carlotta -- mailing list manager)
I forgot the X-Debbugs-Cc in my original e-mail, sorry. Package: wnpp Severity: normal I would like to find a new maintainer for the enemies-of-carlotta package. It is a mailing list manager, of which I am upstream. I will gladly fix any bugs that exist upstream, but I do not wish to maintain the package in Debian anymore. As upstream, I do not predict any great changes, indeed no other changes than bug fixes. If a new maintainer can't be found in two weeks, I'll ask for the package to be removed from Debian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
On Mon, Aug 31, 2009 at 12:46 PM, Marco d'Itri wrote: > On Aug 31, Bastian Blank wrote: > >> I doubt that I would be able to push this port through another release >> in the current state. The consequence would by that the port dies >> completely and with it the only free and released distribution for this >> machines. > Is this really an important problem? > Does a significant number of people actually use Debian/s390 on > production servers? And if they exist, why they are not helping? > I think a bigger question is where do you find hardware where you can get remote root on; I'm not very familiar with s390 or mainframes in general, but its not a piece of hardware one individual person would own. I'm aware of the Hercules emulator, but that doesn't seem like it would be useful for general development of a port. Michael > -- > ciao, > Marco > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkqb/koACgkQFGfw2OHuP7G4NACfSPn2hWvMsEU1DhfSCk0M9boh > vi0AnR2IzJJyChe76F4vORV79qdP/9hi > =QbZi > -END PGP SIGNATURE- > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
On Aug 31, 2009, at 12:01 PM, Michael Casadevall wrote: I think a bigger question is where do you find hardware where you can get remote root on; I'm not very familiar with s390 or mainframes in general, but its not a piece of hardware one individual person would own. I'm aware of the Hercules emulator, but that doesn't seem like it would be useful for general development of a port. The Debian project has access to a couple of machines hosted by OSDL, or at least it used to (I haven't actually checked the status recently). These are older machines (z800?) but still 64-bit. The death of Flex-ES and the lack of a P/390, Integrated Server, or even H50/H70 equivalent for zSeries has left a hole in the market for lower-end developers (not just in the Debian or even Linux space). Hercules is actually pretty useful except in that it doesn't emulate a lot of modern peripheral hardware, particularly the QDIO OSA interfaces and the Fibre Channel interfaces which are a fact of life on modern z boxes. Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
On Aug 31, 2009, at 11:28 AM, Bastian Blank wrote: The first problem is the worst. Currently only Frans Pop and I do work on it. Frans only does the Debian-Installer part and I simply have not enough time to do the rest. The s390 architecture is quite different to anything else, so it needs several specialized packages to work[1] and they need lasting attention. So if anyone wants to help (especially Debian developers) for the continuity of this port please speak up. I'd like to help; my time has become much more limited than during previous release cycles, though, and my access to modern zSeries hardware has also become more limited. I can test installation, but on nothing anywhere near a full complement of device types, and I can make recommendations and amendments to a fair number of the sysconfig shell scripts and the shell scripts in the d-i packages. And given the pressures of my day job I can't really guarantee that I will be able to respond to any specific item in a timely fashion. I wish I could do more. Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
Marco d'Itri wrote: > On Aug 31, Bastian Blank wrote: >> I doubt that I would be able to push this port through another release >> in the current state. The consequence would by that the port dies >> completely and with it the only free and released distribution for this >> machines. > > Is this really an important problem? > Does a significant number of people actually use Debian/s390 on > production servers? That's hard to say, but I've seen 4 or 5 separate reports from people who've wanted to install stable on s390 systems in the past 2 months [1]. That was more than I'd expected for s390. Cheers, FJP [1] We got the reports because the stable kernel for s390 was broken. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544454: ITP: libnet-bonjour-perl -- Perl module for DNS service discovery
Package: wnpp Severity: wishlist Owner: Christine Spang * Package name: libnet-bonjour-perl Version : 0.96 Upstream Author : George Chlipala * URL : http://search.cpan.org/dist/Net-Bonjour/ * License : Perl (Artistic | GPL-1+) Programming Lang: Perl Description : Perl module for DNS service discovery Net::Bonjour is a set of modules that allow Perl programs to discover local services via multicast DNS (mDNS) or enterprise services via traditional DNS. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544486: ITP: python-keyring -- Store and access your passwords safely
Package: wnpp Severity: wishlist Owner: Carl Chenet * Package name: python-keyring Version : 0.1 Upstream Author : Kang Zhang * URL : http://pypi.python.org/pypi/keyring * License : PSF Programming Lang: Python Description : Store and access your passwords safely The Python keyring library provides an easy way to access the system keyring service (e.g GnomeKeyring, KDEKWallet) from Python. It can be used in any application that needs safe password storage. The Python keyring library also provides build-in keyrings. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Compiling libbam.a from libbam-dev with -fPIC?
Le Mon, Aug 31, 2009 at 01:23:39AM +0100, Stephen Gran a écrit : > This one time, at band camp, Charles Plessy said: > > Le Sat, Aug 29, 2009 at 08:06:09PM -0700, Steve Langasek a écrit : > > > On Sun, Aug 30, 2009 at 11:56:58AM +0900, Charles Plessy wrote: > > > > as per Policy § 10.2, I would like to know if everybody agrees if I > > > > change the > > > > libbam-dev package to compile libbam.a with -fPIC. > > > > > What are the reasons for not shipping a shared library? That's always > > > preferred over use of -fPIC for static libs, so we should examine the > > > reasons for this first. > > > > I forgot to mention that the upstream sources do not build a shared library. > > Is there some reason you as a maintainer can't? If the library has no > API or ABI stability, that might be a good reason not to (although it's > a better reason to talk to upstream about why they have to do so), but > otherwise, why not just do it? I started to write a message about to ask upstream why they do not make a shared version of libbam, but I am blocked because I could not give good reason of why Debian can not make -fPIC version of libbam. To my knowledge, libbam is used by the samtools themselves, as well as the Bio::SamTools perl library. For Bio::SamTools, -fPIC is definitely not a problem because the upstream README mentions to use this option if necessary. For the samtools program, it will be easy to prepare a version that is built against a non-fPIC libbam.a, but I fail to understand why it is important since if upstream releases a shared version of libbam, it will have to be compiled with -fPIC anyway, which makes little difference between the situation we want to avoid and the situation we want to recommend. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544498: ITP: libterm-encoding-perl -- Perl module to detect encoding of the current terminal
Package: wnpp Severity: wishlist Owner: Christine Spang * Package name: libterm-encoding-perl Version : 0.02 Upstream Author : Tatsuhiko Miyagawa * URL : http://search.cpan.org/dist/Term-Encoding/ * License : Perl (Artistic | GPL-1+) Programming Lang: Perl Description : Perl module to detect encoding of the current terminal Term::Encoding is a simple module to detect an encoding the current terminal expects, in various ways. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
udev and /usr
On May 31, md wrote: > The issue was raised by the udev upstream maintainer along with the udev > package maintainers of the major distributions, who all agreed that this > configuration is not supported. FYI, udev 146 ships usb-id and pci-id programs which read /usr/share/misc/usb.ids and /usr/share/misc/pci.ids . udev itself does not care about the results of these programs but other programs which used to use HAL may do, leading to subtle breakage. There are no obvious workarounds and I have no plan to fight against this, if you need it to work on systems with a standalone /usr then feel free to persuade the relevant maintainers to move the files. I also opened #544503 because supporting a standalone /var looks like a worthwhile effort, while supporting updating usb.ids with a script instead of apt looks like a complete idiocy. -- ciao, Marco signature.asc Description: Digital signature
Re: udev and /usr
Marco d'Itri wrote: > On May 31, md wrote: > >> The issue was raised by the udev upstream maintainer along with the udev >> package maintainers of the major distributions, who all agreed that this >> configuration is not supported. > FYI, udev 146 ships usb-id and pci-id programs which read > /usr/share/misc/usb.ids and /usr/share/misc/pci.ids . Wouldn't make it sense then if udev had a recommends or at least suggests for usbutils and pciutils? > udev itself does not care about the results of these programs but other > programs which used to use HAL may do, leading to subtle breakage. How will usb-id and pci-id behave, if the ids files are not accessible? > There are no obvious workarounds and I have no plan to fight against > this, if you need it to work on systems with a standalone /usr then > feel free to persuade the relevant maintainers to move the files. > > I also opened #544503 because supporting a standalone /var looks like > a worthwhile effort, while supporting updating usb.ids with a script > instead of apt looks like a complete idiocy. I agree with you. Given that I had more than once bug reports against hal due to broken pci.ids or usb.ids files, I'd prefer if update-usbids and update-pciids would go away. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
