Bug#465402: O: directfb -- direct frame buffer graphics
Package: wnpp Severity: normal Now that the library transition is over, and all major bugs should be fixed, I've been able to finally orphan the directfb suite of packages. It might make sense for whoever takes over, to adopt the whole suite (directfb, dfb++ and fusionsound), they have been maintained in the pkg-directfb alioth project, which I can hand over to the new maintainer(s). All patches have been sent and merged upstream, except for one, which I'm taking care of. There's intructions in that patch header on how to proceed for next upstream release. The package description is: DirectFB is a graphics library which was designed with embedded systems in mind. It offers maximum hardware accelerated performance at a minimum of resource usage and overhead. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24.1-zulo (PREEMPT) Locale: LANG=C, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: toolchain issue makes qt3 drop symbols ?
On Mon, Feb 11, 2008 at 12:01:47PM +0100, Fathi Boudra wrote: > if we choose the binNMU needed packages way, > virtualbox-ose binNMU will become useless in case of a 1.5.4-dfsg-5 > upload is pending. Yes, I got confused by this email talking about a new version and binNMUs. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Processing of .changes files by dak
On 11293 March 1977, Thomas Viehmann wrote: > somewhere else etc. to map key fingerprints to Debian accounts. Add > @debian.org > and you get an email address (let's not care about people disabling > it). ANY "solution" *HAS* to care about this, there is no way you can sanely think that [EMAIL PROTECTED] wants to have the possibly high number of mail rejects thanks to people disabling their debian.org mail. And then - if you have any patches improving the mail handling, or dak in general, talk to me and I put them into a bzr repo, ready for a master to merge. Wouldnt be the first patch to merge in. :) (Or talk to a master directly...) -- bye Joerg * libpng2 no libpng3 no why ? because no yes no yes no yes bullshit no yes no yes no yes stop ? no when someday beep beep beep beep (Closes: #157011) -- Christian Marillat <[EMAIL PROTECTED]> Thu, 29 Aug 2002 16:41:58 +0200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootstrapping GT.M
Andreas Tille <[EMAIL PROTECTED]> writes: > [I'm forewarding this to debian-devel because this seems to be the > right list for this kind of issues.] > > Short intro for debian-devel: We are discussion about including GT.M, > a free MUMPS implementation available at > http://sourceforge.net/projects/fis-gtm > into Debian to be able to package VistA, which is an enterprise grade > health care information system developed by the U.S. Department of > Veterans Affairs (VA) and deployed at nearly 1,500 facilities worldwide. > http://sourceforge.net/projects/openvista > > The problem is that you need a running GT.M to build GT.M in a > bootstrap process. Please read the mail from one of the authors below. > > On Mon, 11 Feb 2008, K.S. Bhaskar wrote: > >> [KSB] On account of the bootstrapping. You have to have a running >> GT.M at some point, or you have to simulate a running GT.M by hand. >> Think about bootstrapping a C compiler that is itself written in C. >> At some point, you need to do something to compile the compiler, e.g., >> compile it by hand. Once you have an executable binary of the first >> compiler, you can use it compile the next compiler, and so on. For >> GT.M, you will need the *_ctl.c, merrors_ansi.h, and ttt.c files, >> which are generated by GT.M itself (they are all human readable ASCII >> files). So, what you can do is to use an existing version of GT.M to >> create those files, read them to confirm that they look reasonable, >> i.e., no hidden binary code, and then build the new GT.M and use the >> new GT.M to build itself and verify that the files are the same. If >> you can think of any other way out of the bootstrapping conundrum, >> please do let me know. > > Well, if you do not know I do not have an idea either - but lets see > whether somebody at this list comes up with some solution. > >>> I would like to build Debian packages to include GT.M into the Debian >>> GNU Linux distribution. ... >> >> I do understand the spirit of the Debian requirement, but I wonder how >> it is applied to gcc. You must have gcc to compile gcc. Strictly speaking you only need a reasonable C compiler. Then again you also need a make, shell, ld, as, ... It is impossible to make a totaly self contained source and a lot of wasted effort to get anywhere close. Debian has defined a set of core packages that one can assume will always be available for building a package (essential and build-essential packages). That include gcc so the gcc deb relies on gcc to be available. But even then gcc first builds a temporary compiler (xgcc) and then compiles itself with that. > Any idea how to solve this problem? Any volunteers to package GT.M? > > Kind regards > > Andreas. > > PS: There was also RFP bug #175968 filed a long time ago which was > closed because nothing happened in this direction. There are three things you can do: 1) Do nothing. Once you have packages GT.M Debian will have a GT.M and you can Build-Depend on it for future builds. Big problem with this approach is that if the GT.M package ever breaks (and it will) you have to bootstrap it manually on all archs to get back on tarck again. 2) Include prebuild sources and a bootstrap target Basically you generate the *_ctl.c, merrors_ansi.h, and ttt.c files and put them somewhere in the source package out of the way of the clean target. In the bootstrap target you use those prebuild sources to build your GT.M compiler. But normaly you would just Build-Depend on the old GT.M. This is little more than 1 but allows you to get other people to bootstrap GT.M for you easily if it ever breaks. 3) Include prebuild sources and bootstrap on every build This basically means you always build twice. First you build from prebuild sources and then you rebuild from scratch again. This has the advantage that you don't Build-Depend on the old GT.M. A broken GT.M upload won't break the chain. MfG Goswin PS: Look at the mono packages for comparison. I think they have the same problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pre-building NEW packages, when they only introduce new binary packages
On 11293 March 1977, Philippe Cloutier wrote: Lets jump in here, even if not all points address your mail only. > If by "disfavour" you imply that it's intentional that NEW packages > aren't built before being accepted, I think you're wrong. I think it > would require not completely trivial changes. It *is* intentional that NEW queue packages wont get build automagically. One of the reasons is that we arent allowed to transfer packages from NEW outside of the US, unless we accept them into the archive. (US export laws and stuff and lalala, details can be read in threads way in the past when crypto in main went live. The basic knowledge is: NEW has to be in the US and packages not exported unless they are accepted into the archive). Now, one might limit the packages to such ones that already got accepted in the past and "just" change binary package names. But thats IMO much more work than it will ever gain us, as you - need to sort out which packages are ok to get autobuild from NEW - need to make them accessible to the buildds in some way. And only them. - Have to let buildds and wanna-build look at yet another location for packages and build them - Have to sort them into the queue somehow. If you go and sort them "below everything in unstable" then you wont have *any* advantage from "autobuilding NEW", as only faster architectures will ever built them, as the slower ones wont get down that far in the queue. And last, but also most complicated: - Need a way for all the buildd admins to see when they can finally sign a build log for a NEW package (after it got accepted), or when they need to go and delete it, as it wont ever get accepted, thanks to a REJECT. While you can do the first automagical by, lets say, looking at incoming.debian.org or packages files, you can't do the latter in any good way. Packages might get rejected due to some issue in them, and then maintainers are free to upload them with the same version to NEW again.[1] The whole thing is just way less benefit compared to the work one needs to do for it. [1] Yes, for REJECTs you can re-use the version number. The archive only requires new versions when the package got visible for users. -- bye Joerg < vorlon> I realize the risk of portability problems is lower than with certain other desktop environments beginning with K that will go unnamed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intend to hijack rrdtool
El lunes, 11 de febrero de 2008, Bernd Zeimetz escribió: > Heya, > > after so many positive responses we've decided to upload rrdtool today, > also not to loose time as it has to go trough NEW. It is team-maintained > and living in a git repository now. > > Maintainer: Debian RRDtool Team <[EMAIL PROTECTED]> > Vcs-Browser: http://git.snow-crash.org/?p=pkg-rrdtool.git;a=summary > Vcs-Git: git://git.snow-crash.org/pkg-rrdtool.git/ There *is* a pkg-rrdtool team in alioth, and a public SVN (that you see was having commits as of two days ago). I had problems to access my @debian.org address and just saw your mails today. Ender. -- Network engineer Debian Developer signature.asc Description: This is a digitally signed message part.
Firewire support in lenny
On Sun, Feb 03, 2008 at 10:04:18AM +0100, Marc 'HE' Brockschmidt wrote: > Early March 2008 > Very soft freeze [...] > Mid of July 2008 > Full freeze I guess that means that lenny will be released with linux kernel 2.6.24.x. If that is so, then I kindly request that the debian kernel packages will be released with the stable Firewire stack modules compiled. The current kernel package mainainer(s) has (have) decided to disable the stable modules in favour of the new and experimental JuJu stack[0]. The new stack has the advantage that is more secure and has a cleaner code base, but the drawback that a lot of devices and features are not yet supported. To summarise what the JuJu developers themselves say about the current state of the new stack[1]: Compatibility and stability At the time of this writing (01/2008), there are still multiple problems with the new FireWire kernel driver stack (alias Juju) compared to the old stack: * Lacking userspace integration. * Lack of testing. Therefore compatibility issues with some controllers and external devices. * There are still problems with isochronous reception on some OHCI 1.0 variants of VIA VT6306/6307 based cards. Cameras and audio devices are unusable with the new drivers if you have such a chip. * Almost no support for IIDC cameras: Highly experimental support in libdc1394 v2 which works with some luck on only a few OHCI 1.1 controllers. * Stability issues of the storage device driver firewire-sbp2 on some hardware. * Missing IP over 1394 support. Regarding Linux 2.6.22...2.6.24, the best advice to Linux distributors (kernel packagers) as well as to regular users is: Build only the old IEEE 1394 drivers. There are security issues with the stable stack[2], so to protect our users it is better to load the modules for the JuJu stack by default. But for those people who need the stable stack to do work, the modules for the stable stack should be available. There is no reason not to build both stacks, they don't conflict with each other (except that only one works if you load both, of course). I hope the kernel package maintainer(s) will make sure kernel packages with the stable modules available, but blacklisted by default, will enter testing soon, so that users of testing get a chance to test it before lenny is released. [0] http://bugs.debian.org/436267 [1] http://wiki.linux1394.org/JujuMigration [2] http://en.wikipedia.org/wiki/FireWire#Security_issues -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re[2]: Proposition: 'NMU' upload of wxwidgets 2.8
On Tue, 12 Feb 2008 19:07:10 -0600 William Pitcock <[EMAIL PROTECTED]> wrote: WP> On Wed, 2008-02-13 at 00:55 +0100, Vadim Zeitlin wrote: WP> > And, seeing from your signature that you're both a Debian and Ubuntu WP> > developer, I'd like to notice that Ubuntu doesn't seem to find WP> > anything WP> > catastrophic with shipping wx2.8 which it does since quite some time. WP> WP> So Ubuntu ships wx2.8. It doesn't matter to us. The fact that Ubuntu WP> does __ is not generally considered a valid argument for WP> justifying that Debian does the same. Yes, I know this and it was never my intention to imply that this alone was sufficient. But it did, and still does, sound strange to me that Ubuntu people didn't find any of those apparently numerous and unavoidable fatal bugs which wx2.8 is so full of. WP> What you should be telling us is why we should be shipping wx2.8 over WP> wx2.6 which is considered by many to be more proven than wx2.8. Could we please bring any facts in this discussion? I replied to a message stating, without any supporting arguments, that wx2.8 was unsuitable to be used. You make a less strong but still fairly significant claim that wx2.6 is considered by many to be better than wx2.8. Could you please tell who those "many" are and why do "they" consider this? It's very difficult to prove that you're innocent when you don't know what do you stand accused of. WP> I am sure if you can come up with valid reasons to do so (especially WP> identifying critical apps which require wx2.8 features is useful here), WP> that we will be happy to provide wx2.8. I don't know how critical these apps are but several of them have been mentioned previously by different people. In particular, if you appreciate using Debian as a development platform, the fact that CodeBlocks can't be built on it is IMHO a pretty critical problem. And even if a program doesn't require wx2.8 it will still work better with it than with wx2.6. Moreover, wx2.6 is officially unmaintained since 1.5 years (and in practice for longer) and any future bug fixes will be done only in wx2.8. But more generally I thought that it was in the order of things for old versions of programs and libraries to be replaced with newer ones in newer Debian releases. I didn't realize there was a need to provide a special argument for the upgrade, I rather thought that the problem was that wx2.8 was (erroneously and, AFAICS, due to the efforts of one and single person) deemed to be too broken to be upgraded to in spite of numerous requests here and in the BTS to do it. If this is not the case I don't think I can provide an argument more compelling than the ones already expressed before. So, once again, I can only propose to help to bring wx2.8 to Debian. If this is deemed to be unnecessary -- so be it. I'd just appreciate if the decision not to include wx2.8 in Debian could be formulated as being due to lack of reasons to upgrade and not as being due to "wx2.8 being totally unsuitable for application development" which is completely slanderous but unfortunately carries a lot of weight when it comes from the official wx Debian maintainer. Thanks, VZ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposition: 'NMU' upload of wxwidgets 2.8
Hi, On Wed, 2008-02-13 at 00:55 +0100, Vadim Zeitlin wrote: > And, seeing from your signature that you're both a Debian and Ubuntu > developer, I'd like to notice that Ubuntu doesn't seem to find > anything > catastrophic with shipping wx2.8 which it does since quite some time. So Ubuntu ships wx2.8. It doesn't matter to us. The fact that Ubuntu does __ is not generally considered a valid argument for justifying that Debian does the same. Additionally, not all Ubuntu contributors agree with all decisions made in the Ubuntu development process. What you should be telling us is why we _should_ be shipping wx2.8 over wx2.6 which is considered by many to be more proven than wx2.8. I am sure if you can come up with valid reasons to do so (especially identifying critical apps which require wx2.8 features is useful here), that we will be happy to provide wx2.8. William signature.asc Description: This is a digitally signed message part
Bug#465545: ITP: libpoe-component-server-simplehttpd-perl -- simple HTTP server for POE
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" <[EMAIL PROTECTED]> * Package name: libpoe-component-server-simplehttpd-perl Version : 1.40 Upstream Author : Apocalypse <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/POE-Component-Server-SimpleHTTP/ * License : Perl (Artistic | GPL-1+) Programming Lang: Perl Description : simple HTTP server for POE POE::Component::Server::SimpleHTTP is Perl extension to easily serve HTTP requests within the POE framework. It supports SSL and pre-forking if libpoe-component-sslify-perl and libipc-shareable-perl, respectively, are installed. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23-1-686 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposition: 'NMU' upload of wxwidgets 2.8
Vadim Zeitlin <[EMAIL PROTECTED]> writes: > if you appreciate using Debian as a development platform, the fact > that CodeBlocks can't be built on it is IMHO a pretty critical > problem. Why? -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposition: 'NMU' upload of wxwidgets 2.8
[for some previous context please see the thread starting at http://lists.debian.org/debian-devel/2007/12/msg00520.html] On Sun, 3 Feb 2008 14:19:27 -0800 Steve Langasek wrote: > Currently, the packages that are asking for wx2.8 are almost all available > and releasable in earlier versions, built against wx2.6. Uploading wx2.8 to > unstable implies that it's suitable for apps to build against, which by all > accounts it is not. As a somewhat interested person, could I please enquire about the sources of these accounts? As far as we (wxWidgets developers) are concerned, wx2.8 is miles ahead of 2.6 and, while any non-trivial software package has bugs and wx2.8 is no exception, is certainly not more buggy than 2.6. Moreover the only claims to the contrary which I've ever seen came (indirectly) from Ron Lee and we believe that he is purposefully sabotaging the inclusion of wx in Debian as a kind of revenge for being excluded from wxWidgets development team. So, once again, if there are any real reasons preventing wx2.8 from being included in Debian I'd really appreciate if somebody could finally point them out to us -- and I can promise that we'll do our best to fix them. And, seeing from your signature that you're both a Debian and Ubuntu developer, I'd like to notice that Ubuntu doesn't seem to find anything catastrophic with shipping wx2.8 which it does since quite some time. Of course, maybe Ubuntu is wrong and Debian maintainer is correct and there are horrible bugs in wx2.8 -- except we've never heard about them, as much as we'd like to. So if you have any information about the details of the accounts you mentioned, could you please post it here, to wx-dev@ lists.wxwidgets.org or me privately, as you prefer? But saying that "by all accounts wx2.8 is unsuitable" without any supporting arguments is just not very helpful. Thanks in advance, VZ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Pierre Habouzit wrote:
>
> echo() { /bin/echo "$@" }
echo() { /bin/echo ${1+"$@"}; }
I believe you mean.
--
John H. Robinson, IV [EMAIL PROTECTED]
http
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type. spiders.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: pre-building NEW packages, when they only introduce new binary packages
Le February 12, 2008 03:19:47 am Joerg Jaspert, vous avez écrit : > On 11293 March 1977, Philippe Cloutier wrote: > > Lets jump in here, even if not all points address your mail only. > > > If by "disfavour" you imply that it's intentional that NEW packages > > aren't built before being accepted, I think you're wrong. I think it > > would require not completely trivial changes. > > It *is* intentional that NEW queue packages wont get build > automagically. [...] > > Now, one might limit the packages to such ones that already got accepted > in the past and "just" change binary package names. But thats IMO much more > work than it will ever gain us, as you [...] > - Have to sort them into the queue somehow. If you go and sort them >"below everything in unstable" then you wont have *any* advantage >from "autobuilding NEW", as only faster architectures will ever >built them, as the slower ones wont get down that far in the queue. You do get the advantage that builds for faster archs are ready right away. Also, slow archs don't necessarily always have a queue. They just need to have more buildds than fast archs. At the moment, "only" hppa and mips* have significant queues, so...at least arm would build sooner. [...] > > The whole thing is just way less benefit compared to the work one needs > to do for it. Thanks. Of course, it *is* intentional not to throw NEW packages to the buildd network in its current form, since it's not designed to support that. I was talking about whether it was intentional to autobuild *none* of NEW. Your mail clarifies that this is not intentional, we just don't have the infrastructure for it, but we agree that even if it's possible to autobuild at least parts, this would be low priority work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Openssl in experimental: please test.
Hi, I've uploaded openssl 0.9.8g-6 to experimental. It adds support for TLS extensions. This changes some structs in the public header files causing ABI changes. I believe those are harmless and shouldn't cause any problems. But I'd like some people to test it before I upload this to unstable. Please see bug #462596 for more info. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: toolchain issue makes qt3 drop symbols ?
On 2008-02-10, Sune Vuorela <[EMAIL PROTECTED]> wrote: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D465028 - libqt3-mt: Miss= > ing=20 > weak symbols for stat64 functions > > basically, in qt3 3:3.3.7-9 and earlier, libqt3-mt seems to provide some=20 > symbols: > > $ objdump -T libqt-mt.so.3 | grep stat64 > 004d2d9e w DF .text 0032 Basestat64 > 002f19de w DF .text 0032 Basefstat64 > 005dcba0 w DF .text 0032 Baselstat64 I have now tried different things: Etch chroot with the following packages pulled from unstable: binutils console-tools cpp-4.1 g++-4.1 gcc-4.1 gcc-4.1-base gcc-4.3-base libc6 libgcc1 libncurses5 libselinux1 libslang2 libstdc++6 libstdc++6-4.1-dev linux-libc-dev tzdata libc6-dev the stat64 symbols was missing Etch chroot with linux-libc-dev from unstable installed the stat64 symbols was around Etch chroot with backported unstable binutils: the stat64 symbols was around Etch chroot with backported binutils build with backported binutils: the stat64 symbols was around Etch chroot with backported binutils build with backported binutils and linux-libc-dev pulled in from unstable: the stat64 symbols was around Any advice on how to proceed is still more than welcome /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#436267: Firewire support in lenny
On Tue, Feb 12, 2008 at 02:38:13PM +0100, maximilian attems wrote: > > My IIDC cameras do not work correctly with a juju-enabled libdc1394 > > 2.0.1. Furthermore, apart from coriander there are no applications that > > have migrated from libdc1394 v1 to v2. > > even with 2.6.24-4 linux images? > please mention the uname of your tests I'll see if I can do the tests on a clean install with the latest linux images tomorrow. > if you are on amd64 2.6.25-rc1-git2 > -> http://photon.itp.tuwien.ac.at/~mattems/ > will build i686 during day (takes much longer) > > please if 2.6.24 has troubles feedback on that one. I'll try both in any case. [...] > you can't have both without blacklisting one otherwise udev loads > randomly from boot to boot other firewire stack. changing blacklist > files in /etc/modprobe.d is trivial. I agree. I'm just asking that the old stack will be blacklisted, but still available in the linux images. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#465402: O: directfb -- direct frame buffer graphics
Hi Guillem, Otavio Salvador, Luis Mondesi and me would like to adopt directfb and friends. cheers, Fathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#465369: ITP: golearn -- Debian educational browser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 clone 465369 -1 reassign -1 goplay retitle -1 goplay: Please avoid "Debian" in short description severity -1 minor thanks On Tue, Feb 12, 2008 at 07:01:58AM +0100, Christian Perrier wrote: >Quoting Jonas Smedegaard ([EMAIL PROTECTED]): >> Package: wnpp >> Severity: wishlist >> Owner: Jonas Smedegaard <[EMAIL PROTECTED]> >> >> * Package name: golearn >> Version : 0.2 >> Upstream Author : Enrico Zini <[EMAIL PROTECTED]> & Miriam Ruiz <[EMAIL >> PROTECTED]> >> * URL : http://packages.debian.org/goplay >> * License : GPL-2+ >> Programming Lang: C++ >> Description : Debian educational browser > > I'm not sure whether this is really descriptive of what the program >does. > >"educational packages search tool using debtags" would maybe better fit as the >software browses across the archive to search for packages >(right?). Of course it browses an archive (mroe precisely what's >listed in sources.list) of Debian packages but indeed not necessarily >*the* Debian archive. Thanks. That makes good sense to me (as most if not all postings I have ever read from you!). I am all in favor of promoting software reuse - even beyond Debian. >That will probably bring the debate about "branding" here (explicitely >mention Debian) but I would at least support moving the mention of >Debian to the long description. At least it probably applies to its origin package: GoPlay! I've now cloned this bugreport. What do you say, Enrico and Miriam? - Jonas - -- Jonas Smedegaard <[EMAIL PROTECTED]> http://www.jones.dk/~jonas/ IT-guide dr. Jones<[EMAIL PROTECTED]> http://dr.jones.dk/+45 40843136 Debian GNU/Linux<[EMAIL PROTECTED]> http://www.debian.org/ GnuPG(1024D/C02440B8): 9A98 C6EB C098 9ED0 3085 ECA9 9FB0 DB32 C024 40B8 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHsaM8n7DbMsAkQLgRAj+cAJ9cmyCl4iIIlaQfHCxHK6T7KEG/eQCgnyc9 UN27JLlLOEE+z+NY+EIz+EI= =EKkj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Openssl in experimental: please test.
On Tue, Feb 12, 2008 at 08:54:26PM +0100, Kurt Roeckx wrote: > I've uploaded openssl 0.9.8g-6 to experimental. It adds support for TLS > extensions. This changes some structs in the public header files > causing ABI changes. I believe those are harmless and shouldn't cause > any problems. But I'd like some people to test it before I upload this > to unstable. > Please see bug #462596 for more info. FWIW, I expect that this is a waste of time. Packages in experimental don't get any significant amount of testing, and if any packages are affected by the ABI change, it's going to be lesser-used packages which are doing relatively naughty things with OpenSSL structs. So I highly recommend uploading this to unstable ASAP, since the only thing that's likely to get you sensible feedback is a reasonable length of time spent in unstable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457263: dialog: Please build with -fPIC
On Mon, 11 Feb 2008, Josselin Mouette wrote: > Le mardi 05 février 2008 à 13:27 +0100, Santiago Vila a écrit : > > Hello. > > > > Policy says I should ask here before I add -fPIC to dialog. > > > > So: May I build libdialog using -fPIC? > > > > My idea is to do this now, document which packages use it in a README, > > and if athe number of packages using it grows, consider the shared library. > > It is highly recommended to use a shared library instead of a static > library for such usage. Yes, I already know that. It's in policy. > If this is really not possible, It is possible, but it'll take time. gnunet is broken in the meantime. > you should build a libdialog_pic.a with -fPIC and keep libdialog.a > as is. What's the rationale for that? Does -ldialog link with libdialog_pic.a automatically if available? I would like gnunet to require a simple rebuild whenever I provide the shared library (which will be soon). My current plan is to build with -fPIC, add Provides: libdialog-dev which should make gnunet not to be broken anymore (as far as it's rebuilt), and then provide a proper shared library in a few weeks. Any serious objection to that?
Re: Bug#436267: Firewire support in lenny
On Tue, Feb 12, 2008 at 11:27:29AM +0100, Guus Sliepen wrote: > On Sun, Feb 03, 2008 at 10:04:18AM +0100, Marc 'HE' Brockschmidt wrote: > > > Early March 2008 > > Very soft freeze > [...] > > Mid of July 2008 > > Full freeze > > I guess that means that lenny will be released with linux kernel > 2.6.24.x. If that is so, then I kindly request that the debian kernel > packages will be released with the stable Firewire stack modules > compiled. no certainly not, we haven't yet discussed the release kernel. options are 2.6.25 or 2.6.26. > The current kernel package mainainer(s) has (have) decided to disable > the stable modules in favour of the new and experimental JuJu stack[0]. > The new stack has the advantage that is more secure and has a cleaner > code base, but the drawback that a lot of devices and features are not > yet supported. To summarise what the JuJu developers themselves say > about the current state of the new stack[1]: [snipp http://wiki.linux1394.org/JujuMigration ] > Regarding Linux 2.6.22...2.6.24, the best advice to Linux distributors > (kernel packagers) as well as to regular users is: Build only the old > IEEE 1394 drivers. you omit the interesting next paragraph: "Building the new drivers is only for advanced users (who for example want the better speed of firewire-sbp2 relative to sbp2) - and for distributors who know what is required in userspace to make use of the new drivers and who can get bugfixes backported and rolled out quickly." on the kernel side we do backport firewire patches. for the userspace side i still see lack of action on libdc1394 "2008/01/05: The official version 2.0.0 has been released. 2008/01/05: A first set of fixes have been released (version 2.0.1)" why is that not even in unstable/experimental? > users it is better to load the modules for the JuJu stack by default. > But for those people who need the stable stack to do work, the modules > for the stable stack should be available. There is no reason not to > build both stacks, they don't conflict with each other (except that only > one works if you load both, of course). > > I hope the kernel package maintainer(s) will make sure kernel packages > with the stable modules available, but blacklisted by default, will > enter testing soon, so that users of testing get a chance to test it > before lenny is released. the progress of the juju stack is very nice, there are quite some fixes queued for 2.6.25, we will make those snapshots available soonest. if the regression list for 2.6.25 is still high we may reconsider there to build the old stack with blacklisted modules. that has always been our stated fallback position, currently in the development phase we encourage testing of the newer stack on latest linux-images. > [0] http://bugs.debian.org/436267 > [1] http://wiki.linux1394.org/JujuMigration > [2] http://en.wikipedia.org/wiki/FireWire#Security_issues best regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#436267: Firewire support in lenny
On Tue, Feb 12, 2008 at 11:49:22AM +0100, maximilian attems wrote: > > I guess that means that lenny will be released with linux kernel > > 2.6.24.x. If that is so, then I kindly request that the debian kernel > > packages will be released with the stable Firewire stack modules > > compiled. > > no certainly not, we haven't yet discussed the release kernel. > options are 2.6.25 or 2.6.26. Given the pace of kernel releases, I do not believe 2.6.26 is possible for lenny, but 2.6.25 is possible, although I think it will only be released a month or two before the final freeze. > > Regarding Linux 2.6.22...2.6.24, the best advice to Linux distributors > > (kernel packagers) as well as to regular users is: Build only the old > > IEEE 1394 drivers. > > you omit the interesting next paragraph: > "Building the new drivers is only for advanced users (who for example > want the better speed of firewire-sbp2 relative to sbp2) - and for > distributors who know what is required in userspace to make use of the > new drivers and who can get bugfixes backported and rolled out quickly." > > on the kernel side we do backport firewire patches. > for the userspace side i still see lack of action on libdc1394 > "2008/01/05: The official version 2.0.0 has been released. > 2008/01/05: A first set of fixes have been released (version 2.0.1)" > > why is that not even in unstable/experimental? libdc1394 2.0.1 is in unstable: http://packages.debian.org/libdc1394-22 My IIDC cameras do not work correctly with a juju-enabled libdc1394 2.0.1. Furthermore, apart from coriander there are no applications that have migrated from libdc1394 v1 to v2. > the progress of the juju stack is very nice, there are quite some > fixes queued for 2.6.25, we will make those snapshots available > soonest. That is good to hear. > if the regression list for 2.6.25 is still high we may reconsider > there to build the old stack with blacklisted modules. > that has always been our stated fallback position, currently in the > development phase we encourage testing of the newer stack > on latest linux-images. I do not see why making the old stack available again, but blacklisted by default, discourages testing of the newer stack. If you have both available, then yes, users can switch to the new stack more easily, but at least they will still be using Debian kernel packages, and they can switch back to the juju stack just as well. If you do not make this option available, those who have problems with the new stack will have to compile their own kernels, and then they will not track the Debian kernel packages anymore. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Is Christian Meder MIA?
Hi Walter, sorry for not answering last year. I'm not completely MIA just terribly slow and very very low profile. I still intend to update the Debian aegis package. Sorry again for being unresponsive, Christian On Thu, 2008-02-07 at 12:38 +0100, Walter Franzini wrote: > Hi, > > in the past months I've tryied to contact Christian Meder > ([EMAIL PROTECTED]) without success. He is the maintainer of > the aegis packages. > > His last upload for aegis is dated 2006-05-14 and in the meantime the > upstream team has done two stable updates and the release of the next > major version is imminent, so I'm a bit worried of state of the > aegis packages in Debian. > > thanks > -- > Walter Franzini > http://aegis.stepbuild.org/ > > PGP Public key ID: 1024D/CB3FEB43 > Key fingerprint : FA26 C33B CAFF 7848 EFEB 7327 96AA 2D57 CB3F EB43 > Key server : http://www.keyserver.net > !DSPAM:47aaeeb1136361810014612! -- Christian Meder, email: [EMAIL PROTECTED] The Way-Seeking Mind of a tenzo is actualized by rolling up your sleeves. (Eihei Dogen Zenji) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootstrapping GT.M
[Andreas Tille] > Any idea how to solve this problem? Any volunteers to package GT.M? What about providing the generated files in the initial upload? The files can them be used to bootstrap the system on the autobuilders. The initial upload can't build-depend on itself, but when it is built, the next upload can build-depend on the previous version of itself. Gcc compiles itself several times during bootstrapping, first a minimal version that can use almost any C compiler, then itself with the minimal version, and finally itself with the full version of itself. Perhaps something similar should be done with GT.M? I realize that the situation is different as there is no M compiler included by default in Debian. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457263: dialog: Please build with -fPIC
Santiago Vila wrote: > Any serious objection to that? no, fine by me. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#436267: Firewire support in lenny
[ stripping cc list to relevant bug report + devel for general info ] On Tue, Feb 12, 2008 at 12:31:43PM +0100, Guus Sliepen wrote: > On Tue, Feb 12, 2008 at 11:49:22AM +0100, maximilian attems wrote: > > Given the pace of kernel releases, I do not believe 2.6.26 is possible > for lenny, but 2.6.25 is possible, although I think it will only be > released a month or two before the final freeze. that discussion belongs to another thread, but don't be too pessimistic. [snipp] > libdc1394 2.0.1 is in unstable: http://packages.debian.org/libdc1394-22 cool. sorry rmadison wasn't showing it to me yet. > My IIDC cameras do not work correctly with a juju-enabled libdc1394 > 2.0.1. Furthermore, apart from coriander there are no applications that > have migrated from libdc1394 v1 to v2. even with 2.6.24-4 linux images? please mention the uname of your tests > > the progress of the juju stack is very nice, there are quite some > > fixes queued for 2.6.25, we will make those snapshots available > > soonest. > > That is good to hear. if you are on amd64 2.6.25-rc1-git2 -> http://photon.itp.tuwien.ac.at/~mattems/ will build i686 during day (takes much longer) please if 2.6.24 has troubles feedback on that one. > > if the regression list for 2.6.25 is still high we may reconsider > > there to build the old stack with blacklisted modules. > > that has always been our stated fallback position, currently in the > > development phase we encourage testing of the newer stack > > on latest linux-images. > > I do not see why making the old stack available again, but blacklisted > by default, discourages testing of the newer stack. If you have both > available, then yes, users can switch to the new stack more easily, but > at least they will still be using Debian kernel packages, and they can > switch back to the juju stack just as well. If you do not make this > option available, those who have problems with the new stack will have > to compile their own kernels, and then they will not track the Debian > kernel packages anymore. you can't have both without blacklisting one otherwise udev loads randomly from boot to boot other firewire stack. changing blacklist files in /etc/modprobe.d is trivial. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
