Bug#503636: ITP: xfce4-power-manager -- power manager for Xfce desktop
Package: wnpp Severity: wishlist Owner: Debian Xfce Maintainers <[EMAIL PROTECTED]> * Package name: xfce4-power-manager Version : 0.6.0beta1 Upstream Author : Ali Abdallah <[EMAIL PROTECTED]> * URL : http://goodies.xfce.org/projects/applications/xfce4-power-manager * License : GPL Programming Lang: C Description : power manager for Xfce desktop Power manager for the Xfce desktop, laptop users can set up a power profile for two different modes “on battery power” and “on ac power”, desktop users still can change DPMS settings and CPU frequency using the settings dialog. It's able to put the laptop to sleep when requested or on certain events like LID close. . It's HAL and Dbus based and can replace daemons like gnome-power-manager, powersaved or pmud. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Sat, Oct 25, 2008 at 07:21, Manoj Srivastava <[EMAIL PROTECTED]> wrote: >Your argument boils down to: There is function that will never > be supported by free software. Annoying people by asking them to expose > their function by freeing the software just irritates them, so we > should just suck it up and accept it. I don't think I'm explaining this well, as it seems you are still not getting it: there isn't any source code to get. >Guess how we cater to people who need non-free software for > some functionality they must have? We put it into a place called the > non-free archive. Great; totally useless raw data the chips on the machine need so we can write free device drivers to talk to them. Excellent. So the plan is: "Debian is only for hardware manufacturers that embed the firmware in flash. If you hide your non-free stuff, that'd be great because then we could pretend it doesn't really exist. Please don't disrupt our perfect version of how the world works." >You do not have to be a "firmware engineer" to grok that. I guess I'll find out. I think this proposal is just trying to pretend that there isn't firmware in the machines now. How does it help the free software movement if we try to ignore the non-free firmware booting our machines now? Why are we trying to shuffle that under the rug? > ps: back in the day, before I became a quantum mechanic, I toyed around > with seeing if designing microprocessors was for me. I did design a 27 > instructions, 4 bit microprocessor with microcode, so I get what > firmware is. It depends, I'm talking about the synthesized image of the microprocessor (for the xlinux, altera, etc). I'm not talking about if you emulated it on solaris to check your processor (CS courses often do processor projects of that sort). I'm also not talking uboot/coreboot like firmware or psos-like things (also firmware but they _do_ have source code). If you did synthesize it, you might not have even "seen" it if you put it on a cpld. Then you might have just thought you were "programming" the chip. No; you were just writing it to flash. Thus bypassing the dilemma. If you build a product and don't want to pay to have the extra chip onboard (common on cheap low end parts) then you have to load it via software. Thus the firmware blob. And yes, for the 50th time: THERE IS NOT SOURCE CODE. There can not be source code, it didn't start as source code. You can't "compile" it because there isn't a compiler. It's not instructions for a microprocessor -- in your case -- it is the microprocessor itself. That's right, lets say that again, the firmware blob is your 4 bit microprocessor. So this whole free 4 bit microprocessor you just made, you can publish the source and everything (see also: openrisc & opensparc). But, to run it, you have to give people a firmware blob so they can run it. Perhaps you can't even make an installer for it because you can't initialize the chip in the installer because you can't put the fimware you need in the installer. So you can only support hardware where you can flash the firmware on the motherboard. Also not ideal because you might have a version out of sync with the kernel device driver you wrote. Great, thanks a lot freedom. So yes, I think most people aren't going to "get" the issue unless they may have been firmware engineers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503625: ITP: debirf -- Build a kernel and initrd to run Debian from RAM
Package: wnpp Severity: wishlist Owner: Jameson Graef Rollins <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: debirf Version : 0.18 Upstream Author : Jameson Graef Rollins <[EMAIL PROTECTED]> * URL : http://cmrg.fifthhorseman.net/wiki/debirf * License : GPLv3 Programming Lang: Bash Description : Build a kernel and initrd to run Debian from RAM debirf (DEBian on Initial Ram Filesystem) is a set of tools designed to create and prepare a kernel and initial ram filesystem that can run a full-blown Debian environment entirely from RAM. . The kernel and initramfs pair created by debirf can be used for a myriad of purposes, from quick-and-easy system repair to diskless thin clients. The kernel and initrd can be placed in your system boot partition, burnt to read-only media, or supplied by a netboot server. . The debirf tools use a module architecture which allows you to customize debirf for any possible purpose by specifying what components are included in the generated image. - -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: i386 (i686) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBAgAGBQJJBSkVAAoJEO00zqvie6q8W3cQAJGTKwRJxyUQgTToqkQHhRQz IjyctGwMtSaQC3b7mmxMe1yEVO7t0rA5opLaxDY/Vx4WYMQk2apBKXvmAhOWj98h DkH+th0Hs4Ewrh71qCgy65zmZjHAarsRYasBw8UHrnzaYHpa9EvTqHztUdtYdGw5 pL3UqvOtr8gK2CQkgL55zH+m5mKPATkLHPi4wNPVhgyVBfLV+6h0ZKR1EO9RXBYH TVrerlap7JWX5eoYdBB0lzt4KHG6DF81IKazW+s7Y76iaDJh7eDAUZShNPvDvytM /xXS9a3/6wuoF8dguHRBKFdJ1amk26DZTn3OlO7r3Q9wUox4+au1tmWh2nk83sEV L015ivMOeKf/8LBnJdht6a4W9CCSETKycF/x5GZ4xwBEHJtbe4Oybem7byXumSMA acn4/o5h2s9/zCRaraYHGQBggGkTEyifGt99FW93wlhJHlL8zyRQGJPkh9rZ0zJ5 TSdUWlDdZ3sUosMIQjFf5oOAxyAFGNH9f5BzgCWfV+p+n7RIdxjzicJOQJDF17uM q4jSfImh+X1PzukAd9Z9uvIn3dS+Lh+NE7y14rBA2DbXPKXRfS1Kf6KpcYXWZ2PR sK52X99Wu3pCycKuJ3uao4qROL4GFiY6qBGw0WZcRQrq4dKTQfWq+zXfTZKdeBno Kg69LhC9U8UiMVaquBkG =VcJk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Sat, Oct 25, 2008 at 09:21, Frank Küster <[EMAIL PROTECTED]> wrote: > How can that be? (That is an ernest question) Because that's how the hardware works. If you are making a widget and you need a fpga or hybrid chip of any sort, then you generate a binary blob using the chip manufacturers tools. So, no matter how good you intend on being, how much you love free software, you don't have any choice. Again, this is ironic since things like the opencores project are the most free hardware of all and are not given credit for it in this thread.
NEW status as of right now
As there's been discussion about the state of the NEW queue lately, I'd like to announce that at this moment there are 45 packages in NEW, only one of those being >2 weeks old (excepting problematic packages, there are 12 of those currently). Mostly thanks to Joerg and Mark this is down from ~250 packages we had in NEW on Friday. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503308: taking over this RFP
Package: wnpp Followup-For: Bug #503308 Owner: Patrick Ringl <[EMAIL PROTECTED]> Hello, I am going to package this app asap! :-) regards, Patrick -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (650, 'testing') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503594: ITP: red5 -- flash streaming server (streaming audio/video, remoting with AMF...)
X-Debbugs-Cc: debian-devel@lists.debian.org Package: wnpp Severity: wishlist Owner: "Damien Raude-Morvan" <[EMAIL PROTECTED]> * Package name: red5 Version : 0.8.0RC1 Upstream Author : The Red5 Project <[EMAIL PROTECTED]> * URL : http://osflash.org/red5 * License : LGPL and Apache 2.0 Programming Lang: Java Description : flash streaming server (streaming audio/video, remoting with AMF...) Red5 is a Java implementation of a Flash Media Server based on reverse engineering of RTMP and AMF protocols. . It support streaming video/audio/data to a Flash client and recording audio/video broadcast from a Flash client. . Any flash client is supported, including Gnash flash client and Adobe Flash Player. A binary-only deb package is available from upstream [1] and can be used as a initial packaging work. [1] http://www.npj.com/red5/debian/ signature.asc Description: This is a digitally signed message part.
Re: Correct way to move /etc config files
Hi there! First of all, thank to both Steve and James for the help. Then, as this was cross-posted to the pkg-fso-maint mailing list, I'll be more detailed than necessary, please skip what you don't care about. On Fri, 24 Oct 2008 22:31:45 +0200, Steve Langasek wrote: > On Tue, Oct 21, 2008 at 11:13:18PM -0400, James Vega wrote: >> On Tue, Oct 21, 2008 at 07:32:48PM -0700, Steve Langasek wrote: >> > On Wed, Oct 22, 2008 at 01:00:34AM +0200, Luca Capello wrote: >> > > This mail originates from the discussion at [1]: simply, I need to move >> > > an /etc file (/etc/frameworkd.conf) from one package (fso-frameworkd) to >> > > another one (fso-config-gta02). [...] >> > Use Replaces:, just as for other files that move between packages. >> >> As I understand it, you should also remove the conffile[0] from the >> original package according. > > That's part of "just as for other files that move between packages", yes. :) > Replaces: is for /moving/ files between packages; I think I've now understood: I thought that the burden was for the new package now carrying the config files, but it's exactly the contrary. I implemented the solution proposed in the Debian wiki (thanks again to James) and it works [1]. Two questions remain: 1) would be a good idea to provide a debhelper script to manage config files, i.e. to automatically insert the shell functions at [0] at build time? Something like dh_conffile_[re]move. 2) am I correct if I say that the reason behind the .dpkg-bak suffix is because using the .dpkg-old is a "nonsense", since what we backup is not really an "old" version? > if the file is supposed to be in both packages, that needs to be a > Conflicts:. Only the fso-config-* packages will provide the conffile. Now that I think of it this means that they should Conflicts: each other, thus each of them will provide the fso-config virtual package (Policy §7.6.2 [2]): Conflicts: fso-config Replaces: fso-config Provides: fso-config This has been implemented in commit [3], but ATM we decide that fso-frameworkd should only Recommends: fso-config [4]. Thx, bye, Gismo / Luca Footnotes: >> [0] - http://wiki.debian.org/DpkgConffileHandling [1] http://git.debian.org/?p=pkg-fso/fso-frameworkd.git;a=commitdiff;h=59f313926b62a683230d4b4a4de5128248648918 [2] http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.2 [3] http://git.debian.org/?p=pkg-fso/openmoko-files.git;a=commitdiff;h=3237ac83fc91d8dccfad72471de312bcc1c809b4 [4] http://lists.alioth.debian.org/pipermail/pkg-fso-maint/2008-October/000145.html pgphVZoJqVhAX.pgp Description: PGP signature
Re: Bug#503096: ITP: alpaca -- GnuPG file handling for Emacs
Tatsuya Kinoshita <[EMAIL PROTECTED]> writes: > I think that the alpaca package isn't meaningless even if less > people use alpaca than EasyPG. Grr. It's FEWER! > > `alpaca' uses symmetric encryption with "--cipher-algo AES" for a > new *.gpg file by default, while I haven't found an easy way to > customizet EasyPG. > Anyway, the point of this post: gpg's default symmetric encryption algorithm is CAST5 [1]. Looking through the epg code, I agree that there isn't currently a way to customise this. However, a lot of the infrastructure to make this easy is available: in epg.el line 36 there is a constant, epg-cipher-algorithm-alist. Using that as a filter, it would be quite simple to add a selection mechanism for the output type. I don't intend to do this, since I'm not sure what the appropriate semantics would be: should the user be pestered? should it be available via some prefix arg? Certainly there should be a customisation option. However, I'm sure that the epg maintainers would be interested in patches and/or further discussion about this. Maybe you should take the topic to their mailing list? Rupert [1] See the gpg manpage, COMMANDS section, under -c. pgpzBePzElQB4.pgp Description: PGP signature
Bug#503482: ITP: ps3-kboot -- First stage bootloader for the PS3
Package: wnpp Severity: wishlist Owner: sean finney <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: ps3-kboot Version : depends on choice of upstream (see below) Upstream Author : (see below) * URL : (see below) * License : GPL Programming Lang: mixed (shell, c, etc) Description : First stage bootloader for the PS3 The ps3-kboot package provides a first-stage bootloader which can be used to boot a Sony Playstation 3 into Debian GNU/Linux. This package will provide a copy of the bootloader file which can be used by various installers and live-cd distributions, as well as support for updating the bootloader image using utilities from the ps3-utils package. a note about "upstream": ps3-kboot is a customized version of kboot, which comes from http://kboot.sourceforge.net/, and can be found at http://www.kernel.org/pub/linux/kernel/people/geoff/cell/. in ubuntu this has already been packaged, but it's not yet clear whether this is derived directly from the former or latter. there are also very clear QA problems with all three versions (the two "upstreams" and the ubuntu package) which as it stands now prevent the software from being acceptable in debian. this is IMHO, but it did also get a public "eww" from an ftp-master when i mentioned it on IRC. i go a little more into detail about this (problems, plans, etc) here: http://www.seanius.net/blog/2008/10/ps3-kboot-for-debian/ sean - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJBHMYynjLPm522B0RAiEuAJ9ZDMx+4IKvO+DBntXXsRcxDdwbEQCbBJD+ 77MM/G755ew4hKqS7OmXE0M= =Fdh4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503096: ITP: alpaca -- GnuPG file handling for Emacs
On October 26, 2008 at 11:11AM +0100, zack (at debian.org) wrote: > Indeed, the fact that EasyPG is now integrated in development version > of Emacs is my main reason for objecting this ITP. [...] > Hence the question goes as: considering that the next release of > Debian is most likely going to be released with Emacs (>= 23.1), which > is integrated properly with EasyPG, do we need alpaca in Debian? I > believe the answer is «no». [...] > > `alpaca' just provides a hook function for *.gpg file handling. > > Meanwhile EasyPG is a powerful tool which also provides keyring > > browser, dired integration, mail functions and so on. So, the > > source code of alpaca is more small and simple. > > Yes, but EasyPG is integrated with a package we already have, and the > complexity you are mentioning is not exposed to the random user of > *.gpg files. I think that the alpaca package isn't meaningless even if less people use alpaca than EasyPG. `alpaca' uses symmetric encryption with "--cipher-algo AES" for a new *.gpg file by default, while I haven't found an easy way to customizet EasyPG. To avoid the complexity of handling *.gpg files, I won't enable the alpaca feature if EasyPG is installed, and I'll suggest EasyPG and add more information in the alpaca package document. FYI: you may enable both alpaca and EasyPG's epa-file with setting alpaca-regex-suffix to "\\.gnupg$" (other than ".gpg"). Thanks, -- Tatsuya Kinoshita pgpE1NIyZhXes.pgp Description: PGP signature
Bug#503469: ITP: nmapsi4 -- interface to nmap, the Network scanner
Package: wnpp Severity: wishlist Owner: Giuseppe Iuculano <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: nmapsi4 Version : 0.1 Upstream Author : Francesco Cecconi <[EMAIL PROTECTED]> * URL : http://nmapsi4.netsons.org/web/ * License : GPL Programming Lang: C++ Description : interface to nmap, the Network scanner NmapSI4 s a complete Qt-based Gui with the design goals to provide a complete nmap interface for Users, in order to menagement all options of this power security net scanner. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkEWzYACgkQNxpp46476aoTpgCfdNxjcfS5oj75/6IDsUjIoplQ eXgAn1Ywhf7KZy/fVlMlW3wbSBlELx0N =NfXb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503096: ITP: alpaca -- GnuPG file handling for Emacs
On Thu, Oct 23, 2008 at 11:14:53PM +0900, Tatsuya Kinoshita wrote: > > I think that a package for one single file is too much. I agree with Luca here. FWIW I also formally object to this ITP. > Even so, the Debian package is helpful for users to install, > upgrade and use it. This is not an argument per se. Everything which should be installed on user machines can benefit to be managed as a package. Still, we have trade-offs to do about the maintainability of our package base. > `alpaca' is an old and simple way. > > The old version of alpaca (named gpg.el) was released in 2003 and > has been useful ever since. EasyPG, "yet another GnuPG interface > for Emacs", version 0.0.1 was released in 2006, and then merged the > development version of Emacs (will be 23.1 release) in 2008. Indeed, the fact that EasyPG is now integrated in development version of Emacs is my main reason for objecting this ITP. I'm using emacs-snapshot from [1] and without any configuration at all *.gpg files are handled properly. The level of integration is the same I used to have with gnupg.vim as shipped by vim-scripts. Hence the question goes as: considering that the next release of Debian is most likely going to be released with Emacs (>= 23.1), which is integrated properly with EasyPG, do we need alpaca in Debian? I believe the answer is «no». [1] http://emacs.orebokech.com/ > `alpaca' just provides a hook function for *.gpg file handling. > Meanwhile EasyPG is a powerful tool which also provides keyring > browser, dired integration, mail functions and so on. So, the > source code of alpaca is more small and simple. Yes, but EasyPG is integrated with a package we already have, and the complexity you are mentioning is not exposed to the random user of *.gpg files. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
