Bug#797411: ITP: rumpkernel -- Rump kernel libraries
Package: wnpp Severity: wishlist * Package name: rumpkernel * URL : http://rumpkernel.org/ * License : quite a few (mostly BSD-style) Description : Rump kernels provide free, portable, componentized, kernel quality drivers such as file systems, POSIX system call handlers, PCI device drivers, a SCSI protocol stack, virtio and a TCP/IP stack. These drivers may be integrated into existing systems, or run as standalone unikernels on cloud hypervisors and embedded systems. URL: http://rumpkernel.org/ This package includes librump0 / librump-dev library, which allows applications to run and use Rump components (device drivers, file systems...) entirely on user-space. A particular demonstration of this is rumposs, a small program which interceps calls to OSS audio API, translates/redirects them to Rump which ultimately drives the audio chip entirely on user-space: https://github.com/robertmillan/rumposs -- Robert Millan
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 02/03/2014 12:19, Turbo Fredriksson wrote: > Basically, their ruling is law. Your opinion is just that - your opinion and > bear no weight at this > moment. Ah, good. Finally you openly admit that you're requesting ftp-master support for your hostile takeover instead of trying to coordinate with existing maintainers. I won't waste one more minute of my time trying to talk sense into you. -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53134544.5040...@debian.org
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 01/03/2014 15:46, Turbo Fredriksson wrote: > Please give us/me a direct link to the Debian GNU/Linux policy point that > explain that this is not acceptable. I don't have that. I'm telling you that Debian infrastructure is not ready to handle cross-arch namespace collisions based on my experience hitting the exact same problem before. There's a reason we add a "freebsd-" prefix to functionally equivalent packages like: freebsd-smbfs - mount command for the SMB/CIFS filesystem freebsd-net-tools - FreeBSD networking tools freebsd-nfs-common - NFS support files common to client and server freebsd-nfs-server - FreeBSD server utilities needed for NFS on GNU/kFreeBSD freebsd-ppp - FreeBSD Point-to-Point Protocol (PPP) userland daemon Your repeated insistence on occupying the "zfsutils" namespace makes me think you have a self-serving reason for this. How do you plan to react when actual breakage happens? On 02/03/2014 05:56, Turbo Fredriksson wrote: > That is what OpenZFS.org is for - eventually (hopefully sooner than later), > you/we/I will be able to > do just that - one source base for all architectures (Linux, FreeBSD, Illumos > etc). But we (they) > aren't there yet. > > > As it stands today, there are two "upstream sources" for/in Debian GNU/Linux > - one for the Linux > kernel and one for the FreeBSD kernel. These share _a lot_ (I can't give you > an exact figure, but if > I had to give a "between thumb and index finger guess", I'd say 90%) of the > same code (they both > originated from the last open Solaris release before Oracle closed the source > again) and provide the > exact same functionality, in the exact same way with binary programs that > behave the exact same way > (same options and parameters etc). Unless I missed something, ZoL is not OpenZFS. And neither ZoL nor OpenZFS support the kernel of FreeBSD at the time of writing. You make it look like you're adding a portable package, when in fact it is a Linux-specific package. The idea that you're adding a portable package is very consistent with your pretension of occupying the namespace. I think it would serve that agenda to imply that ZoL is OpenZFS and the source you're adding is portable, but I don't think you even believe what you're implying. If you truly believe in the "unification path", why don't you try Dimitri's suggestion? I notice that you ignored it on your reply to him: On 02/03/2014 03:52, Dimitri John Ledkov wrote: > Also, if there is zfs-dkms module available, why existing zfsutils > packages just can't enable compilation on "linux-any"?! Which should > also reduce the scope of linux specific packages down to > -dkms/-initramfs, and maybe an arch specific patch-series. The packages are so similar, right? Maybe he has a point. Why don't you send patches for zfsutils to enable compilation on linux-any? I'll be happy to work with you. -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53131091.8060...@debian.org
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 28/02/2014 15:13, Turbo Fredriksson wrote: > On Feb 28, 2014, at 1:29 PM, Robert Millan wrote: > >> The proposed package is poorly integrated with existing ZFS packages (e.g. >> zfsutils for native >> kFreeBSD support). >> >> First and foremost, there's a namespace grab which is likely to result in >> trouble, as I explained >> last November (and got no answer) > > Why is this a problem? I already explained. Nobody listens... (sigh) I pointed to the explanation in my previous mail. Please have a look. I urge you to take care of this now. If you'd rather ignore this, be aware that I won't lift a finger when actual breakage happens and you realize that you're forced to rename. > Also, "eventually" _all_ open source ZFS implementations will be built from > the source base. That would be great, but for now it's just wishful thinking. -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5311dfe0.6030...@debian.org
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 28/02/2014 10:20, Dimitri John Ledkov wrote: > Hello, > > On 28 February 2014 09:30, Turbo Fredriksson wrote: >> I'm basically Ccing half the world in this (only half sorry about that :) >> and I don't know who half >> of you are :), but there have been very little information on what's >> happening with ZoL in Debian >> GNU/Linux. >> >> Aron (and in some part Carlos) seems to have gone a-wall and the list have >> been VERY quiet. It seems >> like it's only Aron and me that is actually Debian GNU/Linux Developers >> (unless other things have >> happened outside the list that I'm not aware of - Carlos was/is a maintainer >> if I don't >> misremembering and Darik is in the wait queue?). And no actually status >> information/reason from the >> FTP maintainers about why it have been stuck in incoming for so long >> (accepted into incoming Sun, 07 >> Jul 2013 16:00:06 - that's more than six months ago!). Have it been >> rejected? Is it held up for some >> reason? What can I/we do to help move it along? Hi, The proposed package is poorly integrated with existing ZFS packages (e.g. zfsutils for native kFreeBSD support). First and foremost, there's a namespace grab which is likely to result in trouble, as I explained last November (and got no answer): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686447#117 There are also a number of implementation-independant add-ons which would be good practice to coordinate in some way with the other ZFS maintainers. I explained this in November too, and again got no answer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686447#112 And annoyingly, there's also been complaints that ZoL developers broke partman-zfs by committing porting updates that break existing support on kFreeBSD: https://lists.debian.org/debian-bsd/2014/02/msg00037.html I'm happy to see partman-zfs support more platforms, and I don't mind myself if those platforms are not yet part of Debian when support is merged. But I would at least find it reasonable that porting changes include an effort to avoid breaking existing production environments. We do this all the time when porting to kFreeBSD. I think it should work both ways. That I know of, nobody has spent the time to fix this particular mess yet :-( -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53108145.8030...@debian.org
Bug#690591: ITP: kfreebsd-firmware-nonfree -- Nonfree firmware modules for kfreebsd kernel
Hi, On Mon, Oct 15, 2012 at 03:48:41PM -0700, Christoph Egger wrote: > Currently the only way freebsd really supports firmware loading is > through kernel modules. FYI, latest kfreebsd-11 supports loading blobs from /lib/firmware. -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140115110140.ga19...@master.debian.org
Bug#733743: ITP: libnih.la -- portable libnih implementation
Hi Dimitri, On 31/12/2013 15:46, Dimitri John Ledkov wrote: > I would like to package a temporary fork of libnih, which has been > ported to kFreeBSD/eglibc platform. My plan for this package is to > provide same packages as the src:libnih, but for non-Linux ports > only. At the moment I have a port to kFreeBSD/eglibc. > > This is separate source package as the supported set of APIs is not yet > fully same as of the Linux port of libnih. For example kqueue/kevent > technology is not yet used to provide, e.g. file level notification as > done with inotify in the linux port. > > Some of my patches have already been accepted upstream > (https://github.com/keybuk/libnih), others are under review and some are > not ready for submission yet. > > All libnih test-suite passes on kFreeBSD for those components that have > been ported. > > Together with this effort, I am staging patches for Upstart itself for > kFreeBSD/eglibc https://code.launchpad.net/~xnox/upstart/kfreebsd. It > compiles, but at the moment is still incomplete. The test-suite does not > pass yet and there are no kFreeBSD specific bridges yet (e.g. devd > events, instead of udev, etc.). I'm hoping to have a bootable > kFreeBSD/eglibc port soon, with full support ahead of Jessie freeze on > 5th of November 2014. I assume porting Upstart is the whole reason you've ported libnih? I haven't been following the discussion about Upstart vs Systemd vs OpenRC debate. Are you doing this because you expect that Upstart will be adopted? > The requirements for libnih/kfreebsd, at the moment are, eglibc 2.18 & > kFreeBSD kernels with fixed waitid/wait6 syscalls. These are all present > in Debian experimental. Note the waitid/wait6 fix is in unstable, too (since 10.0~svn258623-1). > Alternatively, if lower eglibc versions are > required I could easily use wait6 syscall directely, without eglibc > wrapper. In that case only requirements would be patched kFreeBSD > kernels for the kern/184002 > http://www.freebsd.org/cgi/query-pr.cgi?pr=184002&cat= bug which I > discovered in FreeBSD. If I had to choose, I think I'd rather break old libc than break old kernels. The former is readily fixed by proper use of Depends field, while the later breaks kfreebsd-downloader and all sort of chroot/jail environments. > It's fixed in current/11, and is on track to be > fixed in 9.2, 10 stable updates. Uhm doesn't seem so. Nobody MFCed it to stable/10 yet. I think we can take 10.1 support for granted. 10.0 is probably difficult (but I will try anyway). -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52c4800b.6040...@debian.org
Bug#729149: ITP: ctfutils -- FreeBSD CTF utilities
Package: wnpp Severity: wishlist Owner: Robert Millan * Package name: ctfutils * URL : http://www.freebsd.org/ * License : CDDL, with some BSD (2 clause) additions Description : FreeBSD CTF utilities This package contains utilities to create, merge and dump contents of CTF files. . CTF (Compact C Type) format encapsulates a reduced form of debugging information similar to DWARF. -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527e5cbf.9050...@debian.org
Bug#686447: conflicting package names
> One question that floats over my mind is related to the name of the packages > libzfs-dev libzfs1 and zfsutils. On Debian/kFreeBSD there are packages with > the same name. Is allowed to have different source packages building binary > packages with the same name when they are different architectures? Btw doing this *used to* break stuff. I think it was the BTS, testing migration scripts, or a combination of the two. In order to avoid this, I recommend that you rename: zfsutils - command-line tools to manage ZFS filesystems As for the other conflicting packages, there is little point in providing them as separate libraries, as they have no users other than those provided in zfsutils. I would suggest you merge them into whatever becomes of zfsutils: libnvpair1 - Solaris name-value library for Linux libuutil1 - Solaris userland utility library for Linux libzfs-dev - Native ZFS filesystem development files for Linux libzfs1- Native ZFS filesystem library for Linux libzpool1 - Native ZFS pool library for Linux -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527c010d.30...@debian.org
Bug#686447: common ZFS extras
Hi, There are a few goodies in zfsutils package which are useful to different ZFS implementations but not (yet?) shared in a common package. You might find them useful: debian/local/bash_completion.d/zfsutils (stolen from zfs-fuse) debian/zfsutils.cron.d (stolen from linux softraid) debian/zfsutils.cron.daily (ToH snapshot management script I wrote myself, very useful IMHO ;-)) If you think it's worth it, we could split them off zfsutils into a separate binary-all package. -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527bff79.60...@debian.org
Bug#473189: back to RFP
retitle 473189 RFP: elftoolchain -- compilation tools for the ELF object file format owner 473189 Y Giridhar Appaji Nag thanks Hi, I begun packaging this and then determined that it didn't meet my requirements. I'm adding my unfinished work here in case someone wants to reuse it. -- Robert Millan elftoolchain.diff Description: Binary data
Bug#613805: preliminar nfs-ganesha package (user mode NFS server)
I made some progress and finally got a succesful build. A preliminar nfs-ganesha package is available at: Vcs-Browser: http://anonscm.debian.org/loggerhead/collab-maint/nfs-ganesha/ Vcs-Bzr: https://alioth.debian.org/anonscm/bzr/collab-maint/nfs-ganesha/ This produces 3 binary packages: nfs-ganesha-common, nfs-ganesha-doc and nfs-ganesha-posix. However, it still needs some cleanup before it can be useful. In particular the default /etc/ configuration doesn't work, and it seems to require a MySQL backend, which the package doesn't configure automagically. -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caofdtxp_u24+css53h9n73t26tdb8whaduhkxtegruav7vs...@mail.gmail.com
Bug#636164: RFP: apt-clone -- ZFS integrated APT package handling utility
2011/8/3 Michael Vogt : > There is a apt-clone tool in debian already. I'm really sorry for the > confusion (its one of my packages). Maybe it could become > apt-zfs-clone or apt-clone-zfs as its really only useful with zfs (as > I understand it at least). Sure, I don't think that will be a problem. Since this is an RFP (rather than ITP), I leave it to whoever might want to package this to decide on a new name. -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOfDtXMy+O-56CgFDqneTgFeoCuNXM7dj_fVXEb5sG97=ca...@mail.gmail.com
Bug#636504: RFP: pcbsd-netmanager -- PC-BSD Network Manager
Package: wnpp Severity: wishlist * Package name: pcbsd-netmanager * URL : see below * License : 3-clause BSD (with some MIT/X11 parts) Programming Lang: C++ (Qt) Description : PC-BSD Network Manager Graphical (Qt) Network Configuration utility of the PC-BSD project. May be used to setup Ethernet, Wireless and 3G/PPP. Extended description and Screenshots: http://wiki.pcbsd.org/index.php/Network_Configuration Browse source code: http://trac.pcbsd.org/browser/pcbsd/current/src-qt4?order=name (note: LICENSE file is in this top-level directory; subdirs pc-netmanager and libpcbsd are also required). Subversion URL: svn://svn.pcbsd.org/pcbsd/current/src-qt4 Note: This package is only useful on Debian GNU/kFreeBSD flavor. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803154047.1011.43739.reportbug@dimoni
Bug#636164: RFP: apt-clone -- ZFS integrated APT package handling utility
2011/8/1 Arno Töll :
> wow, that's cool! I'd love having this in Debian. Please note, apt-clone
> - - as you linked it - depends on grub 1, not grub-pc. I noticed that
> while having a quick look into the code, e.g.:
I know. SUN used to be quite interested in GRUB 2. One of their
engineers has spent a lot of time in upstream ML, but he wasn't
allowed to tell about SUN's plans.
> to be honest, that's some ugly piece of code as well. I'm not (so) sure,
> whether we shall package that /right now/. I think Nexenta is still
> based on Hardy and did not see much visible activity recently, as
> OpenSolaris is pretty much dead, so I don't expect any major changes
> very soon, as Nexenta may have other problems than apt-clone right now.
>
> apt-clone does not look too portable either:
>
> if ($idx > 2 && grep { /Nexenta.*Core.*Platform.*Elatte/ } @$sect) {
> delete $h{$idx};
> }
> ...
>
> So I wonder whether it would be more useful to fork it and provide a
> native Debian package instead, since this script seems not be very
> useful outside Nexenta.
I agree it's not the brightest piece of code, but at least I think the
GRUB part could be merged back. They know they might need it someday
when GRUB is upgraded in Illumos (GRUB 2 should work on Solaris -or
almost, all the important bits are there-).
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOfDtXMtwvf20p0ODYZNd3DLPfp�ssjTDzkpAMTkd+jX=z...@mail.gmail.com
Bug#636164: RFP: apt-clone -- ZFS integrated APT package handling utility
Package: wnpp Severity: wishlist * Package name: apt-clone Version : 0.7.9nexenta28 * URL : see below * License : CDDL Programming Lang: Perl Description : ZFS integrated APT package handling utility apt-clone is the command-line tool for handling packages, and may be considered the user's "front-end" to the apt-get(8). It manages GRUB menu and ZFS 'syspool' filesystems. Two upgrade methods supported: 1) safe upgrades via cloning a currently active filesystem and later chrooting into it to perform actual upgrade operation; 2) in-place (live) upgrades by checkpointing a currently active filesystem prior to any upgrade modifications done by apt-get utility. The live upgrading, as the name implies, happens in-place on the running system, and without reboot. Unless the safe -s option is explicitly specified, the system will automatically detect whether the upgrade will require reboot, and if so, it will clone the active filesystem and safely perform the software upgrade within this ZFS clone. A user then has two options: reboot into the new (upgraded) system folder or continue working (and possibly activate the upgrade and reboot into it later). apt-clone may be obtained from Nexenta APT repository. It is shipped as part of the apt package: http://apt.nexenta.org/dists/hardy-unstable/main/source/admin/apt_0.7.9nexenta28.dsc -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110731223813.92811.76907.reportbug@dimoni
Bug#613300: preliminar fuse4bsd package available, PLEASE TEST
2011/6/7 Axel Beckert : > To help to fix all the bugs it blocks, it should at least provide > fuse-utils (or even make a dummy package as some packages depend on a > versioned fuse-utils like e.g. sshfs) and provide the same interface > (i.e. /usr/bin/fusermount and /sbin/mount.fuse). I suspect we'll > probably need wrapper scripts to provide these interfaces. We could have a fuse4bsd source package, then a fuse-utils binary with the userland utility (mount.fusefs), and another binary for the kfreebsd module. The latter will have to be versioned (e.g. fusefs-kmod-8.2-1-amd64) unless/until someone comes up with a better way (port dkms?). -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktinwj5uuwd1om3+buwdsamnb_nd...@mail.gmail.com
Bug#613300: preliminar fuse4bsd package available, PLEASE TEST
http://people.debian.org/~rmh/fuse/ -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktin-hdltm6hqdheehkkn5sgkkgf...@mail.gmail.com
Bug#613805: RFP: nfs-ganesha -- NFS server running in User Space
Package: wnpp Severity: wishlist * Package name: nfs-ganesha * URL : http://nfs-ganesha.sourceforge.net/ * License : LGPL Programming Lang: C Description : NFS server running in User Space NFS-GANESHA is a NFS server running in User Space. It is available under the LGPL license. It has been designed to meet two goals: * providing very large metadata and data caches (up to millions of records) * providing NFS exports to various files systems and namespaces (a set of data organized as trees, with a structure similar to a files system) NFS-GANESHA uses dedicated backend modules called FSAL (which stand for File System Abstraction Layer) that provided the product with a unique API (used internally) to access the underlying namespace. The FSAL module is basically the "glue" between the namespace and the other part of NFS-GANESHA Available FSALs are: * FSAL/XFS : provides NFS frontend to XFS filesystems * FSAL/ZFS : provides with a way to export ZFS's pool with NFS-GANESHA * FSAL/LUSTRE : provides NFS frontend to LUSTRE filesystems (Lustre 2 or higher is required for this FSAL) * FSAL/PROXY: the module is in fact a NFSv4 client. Used with NFS-GANESHA, it turns the NFS server into a NFS proxy server. This module is still in its alpha version * FSAL/FUSELIKE: many product use FUSE to have NFS export. Often they resided in the user space. NFS-GANESHA is in user space too, and via this module it allow user space product to have NFS export from user space, without explicit kernel communication. The module use the same interface as the classical fuse binding: if your application have a fuse binding module ready, you'll need nothing else to interface it with NFS-GANESHA. For this specific use, the NFS-GANESHA's engine is wrap in a library to be use and compile with your proprieritary application. * FSAL/SNMP: information available via SNMP are organized as trees, they constitute a namespace. This backend module provides with the capability to export SNMP information data via NFS and browse them in a "procfs-like" way. * FSAL/POSIX: this module is based on the well known POSIX API which is included in the LibC. It allows NFS export for anything accessible via the POSIX interface. POSIX API addresses files and directories by their names (which are volatile identifiers, they may change if object is renamed). FSAL API uses persistent, opaque, unique identifier called handles. Because a this, FSAL/POSIX use the service of a PostGresQL database to perform "reverse lookup" from handle to filename. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110217114730.25192.99432.reportbug@thorin
Bug#613300: RFP: fuse4bsd -- Filesystem in USErspace library (BSD version)
Package: wnpp Severity: wishlist * Package name: fuse4bsd * URL : http://fuse4bsd.creo.hu/ * License : BSD Description : Filesystem in USErspace library (BSD version) FUSE for BSD kernels. Useful to provide FUSE support on GNU/kFreeBSD. This library requires porting work. Axel Beckert has already made some progress: http://lists.debian.org/debian-bsd/2010/08/msg00035.html Additionally, FreeBSD ports collection contains a few patches (necessary to build fuse4bsd for recent kernels): http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/fusefs-kmod/files/ http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/fusefs-libs/files/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110213223119.16011.19522.reportbug@thorin
Bug#592047: RFP: linux-libre -- The fully free Linux kernel
2010/9/5, Fernando C. Estrada : > package wnpp > retitle 592047 RFP: linux-libre -- The fully free Linux kernel > thanks > > Maybe you're interested in the Robert Millan's work in this package [1], > and hopefully he wants to keep doing this work ;-) or at least provides > certain advices to the person who likes to mantain this package. See: http://www.fsfla.org/svn/fsfla/software/linux-libre/freed-ebian/ -- Robert Millan -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=xtoqly2cbg=3ftgvkc7rf2ndi5nhnsjybj...@mail.gmail.com
Bug#566907: ITP: mingw-w64 -- Minimalist GNU w64 (cross) runtime
Package: wnpp Severity: wishlist Owner: Robert Millan * Package name: mingw-w64 * URL : http://mingw-w64.sourceforge.net/ * License : GPL, LGPL, ZPL, etc... Programming Lang: C, amd64 asm Description : Minimalist GNU w64 (cross) runtime This package contains the target runtime files for a cross-compilable Windows/amd64 target. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#563315: ITP: dragonegg -- GCC plugin that uses LLVM for optimization and code generation
Package: wnpp Severity: wishlist Owner: Robert Millan * Package name: dragonegg Version : SVN snapshot Upstream Author : Duncan Sands * URL : http://dragonegg.llvm.org/ * License : GPL Programming Lang: C Description : GCC plugin that uses LLVM for optimization and code generation DragonEgg is a GCC plugin (dragonegg.so) that replaces GCC's optimizers and code generators with those from the LLVM project. . It is a reimplementation of llvm-gcc that works with gcc-4.5 or later. . DragonEgg is under heavy development and is not mature - it may crash or produce wrong code. It will be initially uploaded for experimental (I expect it'll stay there for a while, at the very least untill gcc-4.5 reaches sid). -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562484: ITP: multiboot -- The Multiboot specification
Package: wnpp Severity: wishlist Owner: Robert Millan * Package name: multiboot Version : 0.6.96 Upstream Author : GNU project * URL : http://alpha.gnu.org/gnu/grub/ * License : GPLv2+ Programming Lang: Texinfo for the manual C and i8086 / ia32 assembly for the example kernel Description : The Multiboot specification This specification, created in 1995, describes a method of loading various multiboot kernels using a single compliant boot loader (such as GNU GRUB) on i386-based computers. . It is used by a variety of kernel images, such as the Hurd, Xen, or NetBSD kernels. . An example implementation of a Multiboot kernel is provided. . For an example implementation of a Multiboot loader, check GRUB Legacy (grub-legacy package), or GRUB 2 (grub-pc package, and others). Note: a previous version of this manual is already in Debian, as part of GRUB Legacy package. However since GRUB Legacy is now obsolete, upstream provides new versions of Multiboot in a separate package. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559774: ITP: modem-cmd -- send arbitrary AT commands to your modem
On Mon, Dec 07, 2009 at 03:28:26PM +0100, Hendrik Sattler wrote: >> This doesn't work. The modem expects you to flush its output buffer >> before it will accept new commands. > > Ok. > > Note: a modem may be in the wrong mode (e.g., GSM modems may have more > than one, some not even for AT commands). > There are numerous errors why a modem may not do what you want ;) Well, needless to say, I took my own modem as reference so although my code in principle should support all modems I give no warranty (as if I were going to give it anyway). In any case, patches welcome. >> That aside, terminal capabilities need to be set via termios. > > which can be done once with stty? > I don't see baud rate or any other options in that example line. Baud rate is hardcoded to 115200. In general, my intent is to hide the complexity. In fact this program would be completely useless if it wasn't for this (i.e. one can just do things low-level, either through C/termios or similar shell/stty interfaces), but this is true for most programs ain't it? :-) >> And it's not obvious that you want '\r' instead of '\n'. In fact, I figured >> that out by stracing "cu". > > Usually, AT commands are sent with "\r\n" at the end (like in Windows > text files), and the responses also do have those at the end of each > line. Yeah, I know that now (and back when I didn't know, I knew how to figure this out), but most users don't. This is why I think this program is useful for people who just want to make their modem dial a number. Hey, it would have been pretty useful *for me*! I not just wasted my time writing a new program to do what I wanted, that was only after I figured out that "cu" or "minicom" wouldn't behave the way I needed (even after messing with cu source code). -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559774: ITP: modem-cmd -- send arbitrary AT commands to your modem
On Mon, Dec 07, 2009 at 08:10:12AM -0600, John Hasler wrote: > Why don't you just bring back dip? > > toncho/~ apt-cache show dip > Package: dip > Status: install ok installed > Priority: extra > Section: net > Installed-Size: 300 > Maintainer: Mark W. Eichin > Version: 3.3.7p-4 > Replaces: netstd (<= 2.14) > Depends: libc6 (>= 2.2.4-4), liblockdev1 > Conffiles: > /etc/diphosts 7cbf2c9d02415cd75fafac56a6c62dc8 > /etc/slip.dip 0907d6a1717749ea2827498f5bfa4ec5 > /etc/ppp.dip 4fbc6b28e998e7fa098d08e0ab1efae4 > Description: Tool for handling SLIP/PPP dialup IP connections > This program handles the connections needed for dialup IP links, like > SLIP or PPP. It can handle both incoming and outgoing connections, > using password security for incoming connections. I'm not familiar with it. Is it usable for this purpose? It seems to fall in the same cathegory as ppp/wvdial/etc (i.e. designed to do a lot more than just dial a number). -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559774: ITP: modem-cmd -- send arbitrary AT commands to your modem
On Mon, Dec 07, 2009 at 09:28:03AM +0100, Josselin Mouette wrote: > Le lundi 07 décembre 2009 à 01:43 +0100, Robert Millan a écrit : > > modem-cmd can be used to send arbitrary AT commands to a modem device > > over a serial line. > > . > > For example: > > . > > $ modem-cmd /dev/ttyUSB0 ATDT123456 > > I don’t really see the point in packaging a 10-line shell script. It's not a shell script... Anyhow, the point is very simple: users sometimes find themselves in need of a simple dialer program, just like I did, and they tend to get utterly confused (just like I got): http://www.mail-archive.com/debian-u...@lists.debian.org/msg85161.html For me, the simplest solution was to derive the interface expected by the modem by stracing cu, and writing a small C program that implements it. > OTOH packaging vmcp[1] could be more useful, since it can also send > files, e.g. to control voice modems. > > [1] http://www.unix.gr/gsm/voice/vmcp.c I'd appreciate if you do. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559774: ITP: modem-cmd -- send arbitrary AT commands to your modem
On Mon, Dec 07, 2009 at 02:14:52AM +, Ben Hutchings wrote: > On Mon, 2009-12-07 at 01:43 +0100, Robert Millan wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Robert Millan > > > > * Package name: modem-cmd > > Version : 0.0.1 > > Upstream Author : me > > * URL : none yet, debian-native > > Why should this be Debian-specific? I don't know. Should it? > > $ modem-cmd /dev/ttyUSB0 ATDT123456 > > Which I can trivially can do with stty and echo already, no? I looked at stty, and its interface doesn't seem any simpler than programming termios directly. See also my other reply on flushing buffers. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559774: ITP: modem-cmd -- send arbitrary AT commands to your modem
On Mon, Dec 07, 2009 at 12:59:02PM +0100, Hendrik Sattler wrote: > Zitat von Robert Millan : >> Package: wnpp >> Severity: wishlist >> Owner: Robert Millan >> >> * Package name: modem-cmd >> Version : 0.0.1 >> Upstream Author : me >> * URL : none yet, debian-native >> * License : GPL >> Programming Lang: C >> Description : send arbitrary AT commands to your modem >> >> modem-cmd can be used to send arbitrary AT commands to a modem device >> over a serial line. >> . >> For example: >> . >> $ modem-cmd /dev/ttyUSB0 ATDT123456 > > What's the practical difference to > echo "ATDT123456\r" > /dev/ttyUSB0 > ? This doesn't work. The modem expects you to flush its output buffer before it will accept new commands. Since there might be some junk in it already (e.g. if you interrupted an ATDT command), it needs to be flushed at startup too. This requires non-blocking I/O. That aside, terminal capabilities need to be set via termios. And it's not obvious that you want '\r' instead of '\n'. In fact, I figured that out by stracing "cu". -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559774: ITP: modem-cmd -- send arbitrary AT commands to your modem
Package: wnpp Severity: wishlist Owner: Robert Millan * Package name: modem-cmd Version : 0.0.1 Upstream Author : me * URL : none yet, debian-native * License : GPL Programming Lang: C Description : send arbitrary AT commands to your modem modem-cmd can be used to send arbitrary AT commands to a modem device over a serial line. . For example: . $ modem-cmd /dev/ttyUSB0 ATDT123456 -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552098: ITP: jclicmoodle -- JClic module for Moodle
Package: wnpp Owner: Robert Millan Severity: wishlist * Package name: jclicmoodle Version : 0.1.0.8 Upstream Author : Sara Arjona Téllez * URL : http://projectes.lafarga.cat/projects/jclicmoodle * License : GPL Programming Lang: PHP Description : JClic module for Moodle Activity module for Moodle that allows the use JClic applets as a new type of resource in courses. The module collects and shows the results of the activities done by the students. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537495: ITP: 1 -- C++ API for D-BUS
Package: wnpp Severity: wishlist Owner: Robert Millan * Package name: dbus-c++ Version : GIT snapshot * URL : http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B * License : LGPL 2.1 Programming Lang: C++ Description : C++ API for D-BUS This package provides a C++ API for the D-Bus message system. Note: This library will be used by future versions of Gnote. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529525: ITP: vsag -- Very Simple Archive Generator
On Wed, May 20, 2009 at 03:47:06PM +0200, Goswin von Brederlow wrote:
> >
> > Not at all! dpkg-scanpackages works fine, in fact Vsag uses it to generate
> > Packages files. But it does also a few other things:
> >
> > - Generates compressed Packages.{gz,bz2}.
> >
> > - Generates Release indexes.
> >
> > - Automated gpg signatures.
> >
> > - DAK-like dists/ directory structure (with per-architecture separation)
> >
> > - etc
>
> Why not use reprepro ich is real simple to configure and does all this
> and more.
Hi Goswin,
I think reprepro serves a different purpose. It actively manages your
packages and keeps an internal database of their metadata. Vsag is designed
to be stateless, and to avoid managing the directory containing packages
themselves (one might wish to manage it by hand, using custom scripts,
whatsoever).
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529525: ITP: vsag -- Very Simple Archive Generator
On Wed, May 20, 2009 at 03:44:38AM +0200, Guillem Jover wrote:
> Hi!
>
> On Tue, 2009-05-19 at 22:18:51 +0200, Robert Millan wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Robert Millan
> >
> > * Package name: vsag
> > Version : 0.0.1
> > Upstream Author : Robert Millan
> > * URL : not yet released
> > * License : GPL
> > Programming Lang: bash, make
> > Description : Very Simple Archive Generator
> >
> > Vsag is a very simple program aimed at generating Debian archives out of
> > a directory filled with packages.
> > .
> > It doesn't track state or manage the directory itself in any way. Its
> > purpose is to provide a very simple method to generate the files normally
> > provided by a Debian archive so that it can be used by programs like apt
> > or debootstrap.
>
> Why not improve dpkg-scanpackages instead? What is there missing that
> you'd need?
Not at all! dpkg-scanpackages works fine, in fact Vsag uses it to generate
Packages files. But it does also a few other things:
- Generates compressed Packages.{gz,bz2}.
- Generates Release indexes.
- Automated gpg signatures.
- DAK-like dists/ directory structure (with per-architecture separation)
- etc
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529525: ITP: vsag -- Very Simple Archive Generator
Package: wnpp Severity: wishlist Owner: Robert Millan * Package name: vsag Version : 0.0.1 Upstream Author : Robert Millan * URL : not yet released * License : GPL Programming Lang: bash, make Description : Very Simple Archive Generator Vsag is a very simple program aimed at generating Debian archives out of a directory filled with packages. . It doesn't track state or manage the directory itself in any way. Its purpose is to provide a very simple method to generate the files normally provided by a Debian archive so that it can be used by programs like apt or debootstrap. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529183: ITP: gcc-mingw32 -- The GNU C compiler (cross compiler for MingW32)
On Mon, May 18, 2009 at 12:39:12AM +0200, Samuel Thibault wrote: > > > - Should not be confused with the MingW32 compiler, which is a > > > derivative of GCC 4.2 (I think the descriptions of both packages > > > are clear enough, but suggestions welcome). > > Will it be useful to keep that one? Well, that's not my call. I can think of a few reasons why it's desireable to have a build of GCC for compiling with MingW32 runtime/binutils, but as long as there's some use for the old MingW32 compiler, and there's someone willing to maintain it, I don't see why it'd be a problem to keep it. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529183: ITP: gcc-mingw32 -- The GNU C compiler (cross compiler for MingW32)
On Mon, May 18, 2009 at 12:39:12AM +0200, Samuel Thibault wrote: > > > - Build will be made by reliing on the gcc-source package, which > > > removes the need to add a separate .orig.tar.gz to the archive. > > > > If we have a method for one, why not use it for all? What is different > > with ming? > > Not being targeted at a debian system. Notice we have a few examples of cross-compilers for non-debian arches being built this way: gcc-avr - The GNU C compiler (cross compiler for avr) gcc-h8300-hms - The GNU C compiler (cross compiler for h8300-hitachi-coff) gcc-m68hc1x - GNU C compiler for the Motorola 68HC11/12 processors -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529183: ITP: gcc-mingw32 -- The GNU C compiler (cross compiler for MingW32)
Package: wnpp Severity: wishlist Owner: Robert Millan * Package name: gcc-mingw32 Version : 4.4 * URL : http://gcc.gnu.org/ * License : GPL Programming Lang: C Description : The GNU C compiler (cross compiler for MingW32) Build of GCC for MingW32. This package includes support for C for cross-compiling to a win32 using the MingW32 runtime. Notes: - Should not be confused with the MingW32 compiler, which is a derivative of GCC 4.2 (I think the descriptions of both packages are clear enough, but suggestions welcome). - Build will be made by reliing on the gcc-source package, which removes the need to add a separate .orig.tar.gz to the archive. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#248397: GRUB 2 RFH
retitle 248397 grub2 -- GRand Unified Bootloader thanks 20:43 right, hello robert 20:43 still need help with grub ? 20:43 not yet replaced by grub2... 20:43 i'm not sure how I can help besides commenting on the bug report 20:44 or can I do the next upload, to include the good patches ? [...] 20:49 the report is for grub2 now, basically 20:49 grub legacy is a dead branch, don't waste your time on it 20:49 hmm 20:50 if you want to help, you could subscribe to pkg-grub-devel (debian) and grub-devel (upstream) and see if you can comment on bug reports 20:50 shouldn't then grub be orphaned/removed and grub2 take its place in queeze now ? 20:50 that is, squeeze, obviously :) 20:50 yes 20:50 but it's a slow process 20:51 http://wiki.debian.org/GrubTransition documents what's missing in order to transition 20:51 this should be worked on in coordination with upstream 20:51 please comment that on the RFH 20:51 mind if I just copy-paste this conversation? 20:52 ok go ahead -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523093: [Bug 364931] Re: [needs-packaging] gnote in karmic
On Sat, May 02, 2009 at 08:08:39AM +0200, Savvas Radevic wrote: > - 0.3.0 is out :) I just updated the package in http://people.debian.org/~rmh/gnote/ > - You should have a debian/watch file - I didn't make one since I'm > based on git. Here's a suggestion: Added, thanks. > - I have split the package into 3 different ones: gnote (binary), > gnote-data (data without compilation), gnote-addins (binary) This might make sense, but I'm not sure it's a good idea to decide about package split just yet. > - I am using boost 1.37 or boost 1.35 or boost - I don't know if > that's good, but at least it gives more testing control over various > boost libraries: > libboost1.37-dev | libboost1.35-dev | libboost-dev, > libboost-filesystem1.37-dev | libboost-filesystem1.35-dev | > libboost-filesystem-dev, > libboost-regex1.37-dev | libboost-regex1.35-dev | libboost-regex-dev, > libboost-iostreams1.37-dev | libboost-iostreams1.35-dev | > libboost-iostreams-dev, > libboost-test1.37-dev | libboost-test1.35-dev | libboost-test-dev, I'll talk to upstream to see which version of boost is preferred. > - I've also set versioned dependencies, based on autoconf and ./configure: > automake (>= 1.9), > autoconf (>= 2.53), > pkg-config (>= 0.14.0), > libgtk2.0-dev (>= 2.14), > [...] > intltool (>= 0.35), > gnome-doc-utils (>= 0.4.2), Added, thanks. Except for automake (not needed) and gtk (>= 2.12 is enough now). > - For some reason, during document compilation/creation, it requires > rarian-compat package. I don't know if that's required for Debian, but > on ubuntu it was spitting errors (maybe the situation changed with > newer releases). No idea. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523093: undetermined copyright/license violation
On Wed, Apr 15, 2009 at 08:41:08AM +0200, Giacomo Catenazzi wrote: > Maybe taking derived code (e.g. including new code), one could write only > the license of aggregate work (thus one "later" license), I think so. I agree it could be better to list them explicitly, but upstream doesn't want that. Then again, see what I said in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523093#38 > but I think: > 1- the old code is still "2 or later" It is. Though, it is impractical to split it off the file that contains mixed licenses. But there's no need to either, people wanting the old code can take it from Tomboy (assuming patent liability is not a problem for them). > 2- it is better not to mix licenses in one file, so it is better >to add new code or with the same license or in an extra file >(no problem removing part of old file) > 3- Debian should allow the more liberal license as possible, >thus maintaining the option to use the "old" license terms. We already discussed about whether it's "good" or not to upgrade licenses or to mix different GPL versions in the same file, in a separate thread in -legal. I gave my personal opinion there. Btw the license change comes from upstream, not Debian. It's obvious Hubert has his own reasons for doing it, but whichever they are they're off-topic here. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523093: undetermined copyright/license violation
On Sat, Apr 11, 2009 at 12:46:23PM +0200, Robert Millan wrote: > > I arranged debian/copyright to make it clear authorship & copyright are > shared with the original authors. [...] Ah, btw, it seems there's a bug in some script. The file http://ftp-master.debian.org/new/gnote_0.1.1-1.html presents as "copyright" is actually "copyright.tomboy", a verbatim copy of tomboy's debian/copyright file. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523093: undetermined copyright/license violation
Hi Frank, On Sat, Apr 11, 2009 at 12:08:30AM +0200, Frank Lichtenheld wrote: > On Fri, Apr 10, 2009 at 11:40:02PM +0200, Robert Millan wrote: > > On Fri, Apr 10, 2009 at 10:19:38PM +0200, Robert Millan wrote: > > > I'm > > > going to upload the package in its current state: > > > > > > - When old file has no copyright/license information, only the new > > > copyright/license header added by Hubert is present. > > After having a look at the issue I saw that those file actually have > a reference to the AUTHORS file, which seems to be the place in TomBoy > where the copyright for all those files is declared. This was added recently, see: http://gitorious.org/projects/gnote/repos/mainline/commits/3a41801b8672333b199ffb14c12367be952745e9 didn't make it to the package I uploaded, though. > I personally would > guess probably fulfills the letter of law and license (but it is really only > a guess at this point). I'm a bit unsure though why it was chosen to > refer to the AUTHORS file instead of just including the copyright statement > in the file right next to the new one, which would probably have avoided > this whole discussion. I think this is because for each given file, not every person listed in AUTHORS has participated in it, so one can only guess (or track down each contribution for each file). Asserting copyright for more people than actually wrote code is somewhat dangerous, so this looks like a way to "err on the safe side". > So pending a thorough review and without having seen the debian/copyright > file, I currently see no reason not to allow this in Debian. I don't think > that it contains any blatant lies about the copyright status of the work, > even though I have the feeling it tries to avoid giving credit to > the original authors any more than necessary. But that is a social issue > and not a legal one. I arranged debian/copyright to make it clear authorship & copyright are shared with the original authors. If you consider it necessary that this clarification extends to upstream code, just let me know. Although it can be a PITA because upstream doesn't want to be bothered about this. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523093: undetermined copyright/license violation
On Fri, Apr 10, 2009 at 10:19:38PM +0200, Robert Millan wrote: > I'm > going to upload the package in its current state: > > - When old file has no copyright/license information, only the new > copyright/license header added by Hubert is present. > > - When old file has copyright/license information, the copyright line is > preserved, and merged with Hubert's copyright line and license terms. > Old license terms (LGPLv2.1) are discarded since they're compatible > with GPLv3. Actually, the latter situation doesn't exist. Upstream clarified: 23:23 none of the original files that where translated to C++ had copyright notice, but a few. these few, the (c) has been transfered 23:24 including the MIT license 23:24 in the new file Some old files *do* have LGPL license information, these are libtomboy/eggtrayicon.[ch] which are copied VERBATIM, and Tomboy/panelapplet/PanelAppletFactory.cs which hasn't been used at all. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523093: undetermined copyright/license violation
On Fri, Apr 10, 2009 at 04:00:26PM +0200, Robert Millan wrote: > > So what we need it to keep the old license header around, whenever there > was one. I'll make sure this applies before the package is uploaded. It appears that upstream rejects this idea. Since I don't believe it's such a strong requirement (I'm pretty sure I could find many counter-examples), I'm going to upload the package in its current state: - When old file has no copyright/license information, only the new copyright/license header added by Hubert is present. - When old file has copyright/license information, the copyright line is preserved, and merged with Hubert's copyright line and license terms. Old license terms (LGPLv2.1) are discarded since they're compatible with GPLv3. and let the FTP team decide on that. If they rule that this needs to be fixed, I'll add the missing license headers from original code myself, diverging from upstream tree if necessary. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523093: undetermined copyright/license violation
On Fri, Apr 10, 2009 at 09:37:22AM +0100, Anthony W. Youngman wrote: > I think you're wrong here! The GPL does NOT give you the right to change > the terms on which the original author granted use of the code! > > What it does give you (if the author uses the "or later" wording) is the > right to use a later licence to cover what YOU do. Let us say that I > licence something under "Version 2 or later". I have NOT given you the > right to relicence my code! What you *can* do is say "I prefer the terms > of version 3, the licence grant gives me the right to claim version 3 as > my permission to use this code, therefore I will modify/distribute/etc > under version 3". It DOES NOT allow you to take away my grant of version > 2. > > If you then distribute modified code and say "modifications are v3 only" > the resulting file becomes distributable under v3 only. It still hasn't > taken away my grant of version 2 to my code. Alright then. Thanks for the correction. So what we need it to keep the old license header around, whenever there was one. I'll make sure this applies before the package is uploaded. Thanks -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523093: undetermined copyright/license violation
On Thu, Apr 09, 2009 at 10:27:19PM -0500, Adam Majer wrote: > > License and copyright are one and the same. > > GPL license relies on copyright law, just like almost any other open > source license there is, be it BSD, Artistic or LGPL. Without copyright, > the license is meaningless. Without license, you have no right to the > source code. Thanks for the explanation; but I think what you mean is they're dependant on each other. This doesn't imply they're the same thing though. I think we all agree the "Copyright" lines, whenever they were present, need to be preserved. The license bits in general too, but what happens when the license terms explicitly give you permission to relicense? I gave this example in another mail (sorry if I sound redundant); my understanding is that in "2 or later" terms in a GPLv2+ header the license version can be updated by recipients of the code, and that keeping the old license blob around is not a must; is this correct? Does section 12 of LGPL 2.1 work the same way? If not, where's the difference? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523093: preliminar gnote packages
I've put preliminar packages here: http://people.debian.org/~rmh/gnote -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523093: undetermined copyright/license violation
On Wed, Apr 08, 2009 at 08:30:30PM +0100, Jo Shields wrote: > > > > If there's a problem, we'll get it sorted out, but I need more specific > > info on your findings; the example you pasted shows a file with nor > > copyright statement neither license information (from tomboy) and one > > with both of them (in gnote). Please tell me which of these (in your > > judgement) apply: > > > > - The new file seems to be asserting copyright for the code as > > a whole, and it's not implicitly understood that it only applies > > to the originality added to it by rewriting in C++. > > > > (this is somewhat contentious, since there are examples of other > > programs doing the same, but it can be fixed by adding a clarification > > to each file) > > > > - The new license (GPL v3) is incompatible with LGPL v2.1 > > > > (it's not; see section 13 of the LGPL v2.1) > > > > - There are copyright/license statements being replaced, elsewhere in > > the code. > > > > (if this is so, please give some example) > > > > - Something else. > > > > (be my guest) > > [...] > the copyright header in the > file is clearly asserting that the file is 100% copyrighted by Hubert > Figuiere when it's not. > > [...] > > And so on. "* Copyright (C) 2009 Hubert Figuiere" is simply false, Alright. So, I understand you mean option 1 (see my paragraph starting with "The new file seems to be asserting..." above). Unless there's a clear consensus in -legal that this is not a problem, I will assume it is. I'm fine with extra clarification, for the sake of correctness, it just means a bit more work. I'll speak with the gnote author about it. > and a > clear violation of Tomboy's license. Notice license and copyright statements are two separate issues. AFAIK LGPL doesn't explicitly require that a license notice is preserved mixing code with other licenses like the BSD license does, but I could be mistaken. Any advice on this from -legal? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523093: undetermined copyright/license violation
Hi Jo, Nice to see your newly found interest in C++ packages (though, not completely unexpected) :-) On Wed, Apr 08, 2009 at 06:26:18PM +0100, Jo Shields wrote: > Please note that this project in its current form contains swathes of > major copyright violations and cannot be uploaded to Debian - almost all > source files contain Tomboy source, with Copyright unilaterally changed. > > Compare, for an example, > http://gitorious.org/projects/gnote/repos/mainline/blobs/master/src/preferencesdialog.cpp > to > http://svn.gnome.org/viewvc/tomboy/trunk/Tomboy/PreferencesDialog.cs?revision=2349&view=markup > > This kind of rewrite is completely permitted under Tomboy's license - > changing the copyright without the author's permission is not. If there's a problem, we'll get it sorted out, but I need more specific info on your findings; the example you pasted shows a file with nor copyright statement neither license information (from tomboy) and one with both of them (in gnote). Please tell me which of these (in your judgement) apply: - The new file seems to be asserting copyright for the code as a whole, and it's not implicitly understood that it only applies to the originality added to it by rewriting in C++. (this is somewhat contentious, since there are examples of other programs doing the same, but it can be fixed by adding a clarification to each file) - The new license (GPL v3) is incompatible with LGPL v2.1 (it's not; see section 13 of the LGPL v2.1) - There are copyright/license statements being replaced, elsewhere in the code. (if this is so, please give some example) - Something else. (be my guest) > Tomboy's upstream have been alerted, and are trying to contact the GNote > author to resolve the issue Good to know. I'll speak with the gnote author too, but first you'll have to give some more information, or at least point me to it :-) Is there some description/summary of the problem elsewhere I can check? > - until then, GNote cannot be considered > suitable for Debian. Sure. Btw, I'm adding debian-legal to CC, perhaps they can provide some insight (as you know, when there are doubts about legal stuff it is considered good practice to discuss things in that list). Cheers -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523093: ITP: gnote -- port of Tomboy to C++
Package: wnpp Severity: wishlist * Package name: gnote Version : 0.1.1 Upstream Author : Hubert Figuiere * URL : http://live.gnome.org/Gnote http://www.figuiere.net/hub/blog/?2009/04/01/656-porting-to-cplusplus * License : GPL Programming Lang: C++ Description : port of Tomboy to C++ Gnote is a fork of Tomboy that has been ported to C++. Aside from speed, a clear advantage of this approach is that it can be installed without dragging in the patent-encumbered .NET stack. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]
Would you folks please calm down? On Fri, Feb 20, 2009 at 07:23:39AM +0100, gurkan wrote: > > HELLO > > DO NOT WORRY. ROBERTS MAIL STILL WORKS. > > THERE'S NO NORMAL TIME. IT CAN TAKE ONE DAY, BUT IT CAN ALSO TAKE ONE YEAR. > JUST WAIT... > > YOURS. > > PEOPLE WITHOUT PATIENCE CAN USE HTTP://SID.ETHZ.CH/DEBIAN/LIVES/NYU/ > > GUERKAN > > > IT APPEARS YOU ARE NOT RESPONDING > > > > WILL KEEP RESENDING THEN. > > > > > > ANNOYED ? > > > > YES. > > > > > > > > - > > > > > > > > > > > > > > OK. How long does approval normally take ? > > > > > > Also, you should have checked the file list with me first. Libraries > like: > > > > ./usr/lib/lives/plugins/playback/video/lives2lives_stream.a > > > > ./usr/lib/lives/plugins/playback/video/SDL.a > > > > ./usr/lib/lives/plugins/effects/realtime/weed/*.a > > > > > > are redundant, because these are all dynamically linked at runtime, so > > only the .so and .la versions are used. > > > > You may want to bear this in mind for the next release. > > > > > > Regards, > > Gabriel. > > > > > > > > > > > > On Sat, February 7, 2009 00:40, Robert Millan wrote: > >> On Sat, Feb 07, 2009 at 12:00:38AM +0100, salsa...@xs4all.nl wrote: > >>> > >>> LiVES 0.9.9.6 has been released today. This version should be suitable > >>> for > >>> inclusion in debian. All requested changes have been made. > >>> > >>> See http://lives.sourceforge.net/index.php?do=downloads for full > >>> details. > >>> > >>> > >>> Please keep me updated with any progress. > >> > >> Hi Gabriel, > >> > >> Please excuse me for not having notified you, we uploaded a snapshot and > > is currently in ftp-master queue pending approval: > >> > >> http://ftp-master.debian.org/new/lives_0.9.9.5+20090126+debian-1.html > >> > >> -- > >> Robert Millan > >> > >> The DRM opt-in fallacy: "Your data belongs to us. We will decide when > >> (and > >> how) you may access your data; but nobody's threatening your freedom: > > we still allow you to remove your data and not access it at all." > >> > -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]
On Thu, Feb 19, 2009 at 11:15:34PM +0100, salsa...@xs4all.nl wrote: > Robert, > it appears that your email is no longer functioning. Please update me with > your new email address. Hi, Server just upgraded to Lenny and got into some mess. It should be fine now. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505224: RFP: freecad -- An extensible CAx program (alpha)
On Wed, Feb 18, 2009 at 05:18:45PM +0100, Teemu Ikonen wrote: > On Tue, Feb 17, 2009 at 9:18 PM, Denis Barbier wrote: > > On 2009/2/10, Adam C Powell IV wrote: > > [...] > >> Robert, I owe you an answer on why the OCTPL is GPL-incompatible. > >> IANAL, TINLA, TINASOTODP, etc. but here goes: > >> * 4. para 4: "If you distribute or sublicense the Software (as > >>modified by You or on Your behalf as the case may be), You cause > >>such Software to be licensed as a whole, at no charge, to all > >>third parties..." The GPL does not require "at no charge", and > >>even expressly allows charging for software, so this is an > >>additional restriction beyond the GPL. > > > > GPL 2, section 2.b) > >You must cause any work that you distribute or publish, that in > >whole or in part contains or is derived from the Program or any > >part thereof, to be licensed as a whole at no charge to all third > >parties under the terms of this License. > > > >> * 4. para 5: "You document all Your Modifications, indicate the > >>date of each such Modifications, designate the version of the > >>Software You used..." None of this is required by the GPL, so > >>all of these are additional restrictions. > > > > GPL 2, section 2.a) > >You must cause the modified files to carry prominent notices > >stating that you changed the files and the date of any change. > > > > To me, OCTPL 6.3 (as found in OpenCascade sources, not the one > > at the website, which is outdated IIRC) is identical to LGPL 2.1, they > > paraphrased it, and I believe that OCTPL 6.3 is compatible with GPL. > > Interesting. I assume this would mean that works combining GPL and > OCTPL code (such as FreeCAD) would be acceptable to Debian main? > > Would it make sense to send a note about the GPL compatibility of > OCTPL and its similarity to LGPL to the FTP-master? Maybe this would > get OpenCascade out of the NEW queue, it's been sitting there 4 months > already. I have two questions: - Why not discuss it in debian-legal? - If they're effectively the same, why did they bother writing a new license? Perhaps their interpretation is not the same. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]
On Sat, Feb 07, 2009 at 12:00:38AM +0100, salsa...@xs4all.nl wrote: > > LiVES 0.9.9.6 has been released today. This version should be suitable for > inclusion in debian. All requested changes have been made. > > See http://lives.sourceforge.net/index.php?do=downloads for full details. > > > Please keep me updated with any progress. Hi Gabriel, Please excuse me for not having notified you, we uploaded a snapshot and is currently in ftp-master queue pending approval: http://ftp-master.debian.org/new/lives_0.9.9.5+20090126+debian-1.html -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505224: RFP: freecad -- An extensible CAx program (alpha)
On Tue, Feb 03, 2009 at 11:42:07AM +, Chris Walker wrote: > Robert Millan writes: > > > Package: wnpp > > Severity: wishlist > > Owner: Robert Millan > > > > * Package name: freecad > > > I've added this package to the the engineering metapackage in > debian-science. It should appear at > http://cdd.alioth.debian.org/science/tasks/engineering.html when the > cron job next runs. > > As you have prepared a preliminary package, I've treated this as an > ITP and put you down as responsible for the package. I can easily > remove you if you wish. > > For those reading on Debian-science, more details of the package below. Hi, There are long-standing license issues, which are being worked on by Adam Powell and others at the moment. Also, the package is maintained outside of the debian archives by Teemu Ikonen. My preliminar work only served to incorporate some improvements in Teemu's tree. Please leave this as RFP. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#481858: RFP: svn-bisect -- Determine which version of a subversion repository contains a change, by bisection
Not strictly related to this RFP, but you might be interested to know that starting with version 1.5.5dfsg1-1 (currently in experimental) of subversion-tools a "svn-bisect" script is provided. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]
On Wed, Jan 07, 2009 at 01:12:59PM +0100, salsa...@xs4all.nl wrote: > > OK, all of the fixes asked for have now been checked in to CVS. Thanks Gabriel! On Wed, Jan 07, 2009 at 01:19:41PM +0100, Gürkan Sengün wrote: > > > >Can I now, *finally*, expect a debian package of LiVES !?!?!?! > > there are such packages, just not officially in debian. could you make > a tarball release of all this stuff of CVS? Or maybe it would be fine to start with a CVS snapshot? It isn't going to make it to Lenny, so waiting for a stable upstream release is no problem IMO -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]
On Fri, Dec 19, 2008 at 08:00:20PM +0100, salsa...@xs4all.nl wrote: > > I hope so. Somebody mentioned the icons also last time - I can't believe > anybody would complain, they are 16 x 16 pixel (8 in total) bitmaps used > for play/rewind/stop/pause etc buttons. But I have added the thanks in to > the debian/copyright file now. This sounds like copyright-significant, but I don't think it's a problem; if the author doesn't want to license them, we have plenty of generic icons for play/etc already (I bet both GNOME and KDE have a few of them). > As was mentioned initially, indeed LiVES offers great ogg/theora support > both for encoding and decoding (instant decode is now a feature). Great. Btw, is mencoder needed for input? Note that although mplayer is in Debian, mencoder isn't yet. > In > future I plan to offer enhanced support for other free codecs, for example > the dirac codec which has been developed by the BBC. LiVES already > includes experimental encoding support for this format. How does Dirac compare to Theora? I heard both are patent-free. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]
On Thu, Dec 18, 2008 at 01:14:49AM +0100, salsa...@xs4all.nl wrote: > > > > Additionally your debian/copyright file is incomplete and misses > > (C)holders/license data. You have to include all such differences. > > Like all of libOSC/*, some of the icons. > > > > There was some code in colourspace.c which was by another author, it was > basically minimal code (setting some conversion values in tables). All of > this has now been rewritten from scratch. As far as I know the copyright > file is up to date. If anybody finds something missing, let me know and I > can add it in. Great! Sounds like that would be solved now. > > And next, it includes a mixture of GPL/LGPL v2/v2.1 and v3. > > Now you need to check if all v2/v2.1 ones are "or any later". If not it > > is undistributable. > > > > > > All of the LiVES code is licensed under the GPL v3 or LGPL v3. In fact, I > made the change on the day that the GPL v3 was released, and am proud of > that fact. Hey, you beat me (win32-loader) by just one day! ;-) > During the transition there may have been one or two files > which were mistakenly left as GPL v2 or higher. I believe all such files > have now been updated. If you find any files marked GPL2 or higher, please > let me know and I will update them. GPL v2 or higher files can be combined with GPL v3 code, so this is not a problem as far as Debian is concerned. It's only a problem if they're v2 only without "or later". Would that be the case for any of your files? > >> RFX.spec is a documentation file which documents a standard. I am happy > >> to > >> change the license for this to whatever you recommend (what does debian > >> recommend for standards ?). > > > > GPL or LGPL would be fine. > > OK, I still need to make this one change, I will check it into CVS now. Sorry, I was not particularly bright that day. GPL or LGPL is indeed fine for Debian, in that it makes the document free (modifiable, etc), but I didn't understand what you meant about a license "for standards". When people write a standard, it's logical they don't want modified versions to be also considered the same standard unless they previously sanction them. But sometimes standard drafters (like the RFC) take this too far and forbid moficication completely, making the document non-free. If you wanted to allow modification only in case they give the standard another name, you could draft a license specifically for this. That's what the Apache folks did, but it's really a bad idea. It breaks GPL compatibility and it abuses copyright to do something that really belongs to trademarks. For version 2 of their license, it seems they realized this, and simply said: This License does not grant permission to use the [...] trademarks GPLv3 has a provision for something similar: Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms: [...] c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or [...] e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or which you might find useful. Hope that helps! -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#247337: [Fwd: Re: [Fwd: lives_0.9.8.10-1_powerpc.changes REJECTED]]
On Tue, Apr 29, 2008 at 04:01:59PM +0200, Gürkan Sengün wrote: > On Tue, April 29, 2008 09:29, Gürkan Sengün wrote: > >Dear Salsaman, > > > >Could you relicense all of your software parts of lives into > >GNU GPL v3, or 2, or 2.1, whatever you like best? > > > >That'll make inclusion of lives into Debian (and Ubuntu) a lot > >easier. > > > >Thank you, > >Gürkan > > Hi, > all of the LiVES software is licensed under the GPL v3 or later. The only > exception is weed.h, weed.c, weed-utils.c which will become a library > under the LGPL v3 or later. If you find any source files which are > incorrectly licensed, please let me know and I will correct this. > > [...] > > I will take a look at the debian/copyright file and update it as necessary. Hi, Any progress on this? I'd really like to see an OGG-capable editor in Debian, and Lives looks like a good option. If you need more details, this was the response from FTP team (as posted in the bug log): Additionally your debian/copyright file is incomplete and misses (C)holders/license data. You have to include all such differences. Like all of libOSC/*, some of the icons. And next, it includes a mixture of GPL/LGPL v2/v2.1 and v3. Now you need to check if all v2/v2.1 ones are "or any later". If not it is undistributable. > RFX.spec is a documentation file which documents a standard. I am happy to > change the license for this to whatever you recommend (what does debian > recommend for standards ?). GPL or LGPL would be fine. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505224: RFP: freecad -- An extensible CAx program (alpha)
On Tue, Nov 11, 2008 at 04:25:01PM +0100, Robert Millan wrote:
>
> I'll check your package, compare it with mine, and see if anything I wrote
> is worthy of being merged with your tree.
Here, please consider the following changes:
- Some improvements in debian/control (control.diff)
- 01_disable_pivy.diff (see
https://sourceforge.net/tracker/index.php?func=detail&aid=2256647&group_id=49159&atid=455298)
- 02_fix_make_deps.diff (see
https://sourceforge.net/tracker/index.php?func=detail&aid=2256700&group_id=49159&atid=455300)
Also, you might want to re-use my debian/rules. It makes the package
much simpler IMHO, but this is just a matter of preference..
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
diff --git a/debian/control b/debian/control
index 5263dc2..aea3b7a 100644
--- a/debian/control
+++ b/debian/control
@@ -1,13 +1,12 @@
Source: freecad
-Section: x11
-Priority: optional
+Priority: extra
Maintainer: Debian Science Maintainers <[EMAIL PROTECTED]>
Uploaders: Teemu Ikonen <[EMAIL PROTECTED]>
Vcs-Browser: http://git.debian.org/?p=debian-science/packages/freecad.git
Vcs-Git: http://git.debian.org/git/debian-science/packages/freecad.git
-Homepage: http://sourceforge.net/projects/free-cad
-Build-Depends: debhelper (>= 7), autotools-dev, libc6-dev (>= 2.1.3),
- libstdc++6, libboost-dev, libboost-date-time-dev, libboost-filesystem-dev,
+Homepage: http://juergen-riegel.net/FreeCAD/Docu/index.php?title=Main_Page
+Build-Depends: debhelper (>= 7), autotools-dev,
+ libboost-dev, libboost-date-time-dev, libboost-filesystem-dev,
libboost-graph-dev, libboost-iostreams-dev, libboost-program-options-dev,
libboost-regex-dev, libboost-serialization-dev, libboost-signals-dev,
python2.5-dev, libqt4-dev, zlib1g-dev, libxerces27-dev, libxt-dev,
@@ -20,7 +19,7 @@ XS-Python-Version: current
Package: freecad
Architecture: any
Section: science
-Depends: ${shlibs:Depends}, ${python:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
XB-Python-Version: ${python:Versions}
Conflicts: freecad (<= 0.6.472-1)
Suggests: gnochm | kchmviewer | kchmviewer-nokde | xchm, python-opencv
@@ -30,7 +29,7 @@ Description: An extensible Open Source CAx program (alpha)
to run as a server and dynamically loadable application extensions and
it is designed to be platform independent.
.
- Currently, FreeCAD can import and display CAD models in IGES, STEP, and
+ Currently, FreeCAD can import and display CAD models in IGES, STEP, and
BRep formats and meshes in STL, BMS, AST and Wavefront OBJ formats.
Editing and modeling features are currently somewhat limited.
$ wc -l coin_wrap.cpp
335644 coin_wrap.cpp
This beast eats more than 2 GiB of memory to compile...
--- FreeCAD_0.7.1672/src/3rdParty/Makefile.am~ 2008-10-24 23:27:58.0 +0200
+++ FreeCAD_0.7.1672/src/3rdParty/Makefile.am 2008-11-10 16:34:00.0 +0100
@@ -1,4 +1,4 @@
-SUBDIRS=Pivy
+#SUBDIRS=Pivy
EXTRA_DIST = \
atlas/cblas.h \
--- src/Mod/Part/App/Makefile.am~ 2008-10-24 23:23:28.0 +0200
+++ src/Mod/Part/App/Makefile.am 2008-11-10 17:11:26.0 +0100
@@ -194,6 +194,8 @@
$(libPart_la_LIBADD) \
-lPart
+Part_la_DEPENDENCIES = libPart.la
+
#--
# set the include path found by configure
--- src/Mod/Raytracing/App/Makefile.am~ 2008-10-24 23:23:02.0 +0200
+++ src/Mod/Raytracing/App/Makefile.am 2008-11-10 17:20:10.0 +0100
@@ -71,6 +71,8 @@
$(libRaytracing_la_LIBADD) \
-lRaytracing
+Raytracing_la_DEPENDENCIES = libRaytracing.la
+
#--
# set the include path found by configure
--- src/Mod/Complete/Gui/Makefile.am~ 2008-10-24 23:23:54.0 +0200
+++ src/Mod/Complete/Gui/Makefile.am 2008-11-10 17:42:45.0 +0100
@@ -38,6 +38,8 @@
Resources/libResources.la \
-lCompleteGui
+CompleteGui_la_DEPENDENCIES = libCompleteGui.la
+
#--
# rule for Qt MetaObject Compiler:
--- src/Tools/_TEMPLATE_/App/Makefile.am~ 2008-10-24 23:24:40.0 +0200
+++ src/Tools/_TEMPLATE_/App/Makefile.am 2008-11-10 17:44:04.0 +0100
@@ -31,6 +31,8 @@
$(lib_TEMPLATE__la_LIBADD) \
-l_TEMPLATE_
+_TEMPLATE__la_DEPENDENCIES = lib_TEMPLATE_.la
+
#--
# set the include path found by configure
--- src/Mod/Points/App/Makefile.am~ 2008-10-25 01:24:06.0 +0200
+++ src/Mod/Points/App/Makefile.am 2008-11-10 19:01:06.0 +0100
@@ -52,6 +52,8 @@
Bug#505224: RFP: freecad -- An extensible CAx program (alpha)
On Tue, Nov 11, 2008 at 02:09:17AM +0100, Teemu Ikonen wrote: > On Mon, Nov 10, 2008 at 11:46 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Robert Millan <[EMAIL PROTECTED]> > > > > * Package name: freecad > [...] > > A preliminary package is available at: > > > > http://people.debian.org/~rmh/freecad/ > > Hi, > > I've also worked on FreeCAD packaging for a while, and a preliminary > package is at > http://git.debian.org/?p=debian-science/packages/freecad.git > Unfortunately I forgot to file an ITP. > > You're welcome to join the effort in the Debian Science repository or > if you like, take over the maintenance completely. There are still > some copyright / license problems present in the source, and some of > the stuff in the source package should really be a separate package, > which is why I haven't tried to upload this to ftp-master yet. I > actually just made some cleanups in the copyright file just today, but > did not push my changes to git.debian.org yet. I'll do it tomorrow > though. Hi Teemu, I was unaware of your preliminar work. I knew you intended to work on it, though [1]. Needless to say, I'd be glad if we can work together. I marked the bug as RFP because I wouldn't have time to maintain freecad all on my own. I'll check your package, compare it with mine, and see if anything I wrote is worthy of being merged with your tree. [1] Leo put me on CC on a ping mail sent a while ago, but I received no reply. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#505224: RFP: freecad -- An extensible CAx program (alpha)
Package: wnpp Severity: wishlist Owner: Robert Millan <[EMAIL PROTECTED]> * Package name: freecad Version : 0.7.1672 * URL : http://juergen-riegel.net/FreeCAD/Docu/index.php?title=Main_Page * License : LGPLv2.1+ Programming Lang: C++, Python Description : An extensible CAx program (alpha) FreeCAD is a CAx RAD based on OpenCasCade, Qt and Python. It features some key concepts like macro recording, workbenches, ability to run as a server and dynamically loadable application extensions and it is designed to be platform independent. . Currently, FreeCAD can import and display CAD models in IGES, STEP, and BRep formats and meshes in STL, BMS, AST and Wavefront OBJ formats. Editing and modeling features are currently somewhat limited. A preliminary package is available at: http://people.debian.org/~rmh/freecad/ -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501190: Reworded control
Btw, please keep in mind that the description issues I pointed out are
relatively unimportant compared to legal risk (and I haven't seen that
being discussed in debian-legal yet).
On Thu, Oct 09, 2008 at 03:32:48PM +0200, Robert Millan wrote:
> On Wed, Oct 08, 2008 at 12:38:41AM +0100, Jo Shields wrote:
> > Package: moonlight-plugin-core
> > Architecture: any
> > Depends: ${shlibs:Depends}
> > Conflicts: moonlight
> > Description: open source clone of Microsoft Silverlight - core plugin
> > Moonlight is a free Silverlight clone, allowing Free Software systems to
> > run embedded web-browser objects or standalone code targetting Microsoft
> > Silverlight.
>
> Not true. Code targetting Microsoft Silverlight may as well depend on
> functionality not present in this package. And in fact the only notable
> example I remember (the Chinese Olympics videostreams) did.
>
> Again, I'm pointing to wine as an example, since the situation is the same.
> wine has this in its description:
>
> "This is still a work in progress and many applications may still not work."
>
> Would you please make that clear? We don't want to deceive our users into
> thinking Silverlight is cross-platform, do we?
>
> > WARNING: This is an implementation of public API documentation published
> > on
> > MSDN,
>
> Not true. Take it from de Icaza himself:
>
> "Microsoft will give us access to the Silverlight specifications: details
> that might be necessary to implement 1.0, beyond what is currently published
> on the web; [...]"
> http://tirania.org/blog/archive/2007/Sep-05.html
>
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501190: Reworded control
On Wed, Oct 08, 2008 at 12:38:41AM +0100, Jo Shields wrote:
> Package: moonlight-plugin-core
> Architecture: any
> Depends: ${shlibs:Depends}
> Conflicts: moonlight
> Description: open source clone of Microsoft Silverlight - core plugin
> Moonlight is a free Silverlight clone, allowing Free Software systems to
> run embedded web-browser objects or standalone code targetting Microsoft
> Silverlight.
Not true. Code targetting Microsoft Silverlight may as well depend on
functionality not present in this package. And in fact the only notable
example I remember (the Chinese Olympics videostreams) did.
Again, I'm pointing to wine as an example, since the situation is the same.
wine has this in its description:
"This is still a work in progress and many applications may still not work."
Would you please make that clear? We don't want to deceive our users into
thinking Silverlight is cross-platform, do we?
> WARNING: This is an implementation of public API documentation published on
> MSDN,
Not true. Take it from de Icaza himself:
"Microsoft will give us access to the Silverlight specifications: details
that might be necessary to implement 1.0, beyond what is currently published
on the web; [...]"
http://tirania.org/blog/archive/2007/Sep-05.html
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight
On Mon, Oct 06, 2008 at 11:08:38PM +0100, Jo Shields wrote: > > You're absolutely right, it's a clone, albeit one officially endorsed by > those being cloned. My package description is sourced from a > debian-multimedia package, I'll post a replacement to the ITP shortly. Thanks. > However, one > observation - official Silverlight *does* run on multiple platforms > (Windows or Mac), just not on Linux or other *nixes. Moonlight is > officially endorsed & help given to Moonlight developers to help get > more platforms supported. Right, and Moonlight is not Silverlight, and since Silverlight is a moving target it won't be fully compatible with it anytime soon. Being endorsed hasn't changed that so far. > > - If you want to use ffmpeg, please clarify the legal situation wrt > > license > > incompatibility mentioned by Moonlight's authors in: > > > > http://tirania.org/blog/archive/2007/Sep-05.html > > > > which appears to have prevented them from using ffmpeg, and forced them > > into licensing blobs from Microsoft. Unfortunately they aren't very > > explicit about what the problem is, but it is certain there is one, so > > please find that out, and have it discussed in debian-legal. > > Novell don't want to distribute a Moonlight linked against FFmpeg, and > make themselves targets for patent trolls like the MPEG-LA. That's fair > enough really It is (IMO). But their statement doesn't seem to speak about patents: "We are unable to redistribute this code commercially due to licensing conflicts." Though, this ITP is not the best place to discuss legal issues. I'm just pointing out possible sources of trouble. Please, bring this up in debian-legal, and have the discussion referred to from here. > > [1] In > > http://groups.google.com/group/tiraniaorg-blog-comments/browse_thread/thread/2a07b8b50038d8c8/d582162af2d63d57 > > de Icaza states that you need to "get/download Moonlight from Novell > > which will include patent coverage" > > [2] http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx > > I don't see how possible but unclaimed patents would make moonlight in > Debian more dangerous than any software such as wine, linux, samba, OOo, > ntfs-3g, etc. Unclaimed patents are precisely the reason we don't have any MPEG encoders in Debian (see http://techliberation.com/2006/05/11/mpeg-patent-thicket/). Besides, I don't recall OOo authors saying you must download OOo from Sun or otherwise you will be endangered, like de Icaza asserted [1]. And I don't recall Microsoft having a web page where it regulates what you can and can't do explicitly with OOo. To summarize: - $author claims you should download the software from them in order to enjoy "protection" from patents owned by $this_troll. - $this_troll has a web page explicitly dictating what you can and can't do with $this_software. - You want Debian to dismiss all claims because you believe they're not "more dangerous" than those in wine, linux, samba, OOo or ntfs-3g. It doesn't sound convincing to me. And apparently it didn't sound convincing to others either (e.g. http://fedoraproject.org/wiki/ForbiddenItems#Moonlight). Would you please bring this up in debian-legal so a proper discussion can be held? [1] http://groups.google.com/group/tiraniaorg-blog-comments/browse_thread/thread/2a07b8b50038d8c8/d582162af2d63d57 > Upstream are also aware of any concerns we have, and > are trying to clear things up where possible. (offtopic) If I may make a suggestion, tell them to use GPLv3. It was purposely designed to solve this kind of problem. > ** Note, apologies to debian-devel@ for the offtopic nature of these > messages, my reply is aimed at debian-devel only for mailing list > archive purposes ** It is standard practice to CC debian-devel in new ITPs. Though, as I said for legal discussions please use debian-legal, and afterwards link to the discussion from here. You can start a discussion there by pointing to this ITP. Thanks -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight
On Mon, Oct 06, 2008 at 03:33:48PM +0200, Robert Millan wrote: > [2] http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx Btw, an independent analisys of that covenant is available: http://www.groklaw.net/article.php?story=20080528133529454 -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight
On Mon, Oct 06, 2008 at 03:24:26PM +0200, Robert Millan wrote: > > Description : open source implementation of Microsoft Silverlight > > > > [...] > > Hi, > > The description is misleading. This is (AFAICT) not an implementation of a > standard but a clone product, like wine, and much like wine it lags behind to > the real one. Please make that clear in the description to avoid leading > users > (and specially web developers) to believe Silverlight is cross-platform. For > example, the wine description reads: > > "This is still a work in progress and many applications may still not work." Moreover, the word "implementation of Silverlight" doesn't seem accurate when referring to a product instead of a standard. You probably meant to say this is a "clone of Silverlight". -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight
According to the authors of Moonlight [1], this software is covered by patents owned by Microsoft, which has rules specificaly forbidding re-distribution to parties that are "Downstream recipients" [2]. This seems to indicate it would be illegal for Debian developers in the US to: - Use Moonlight in their browsers (thereby becoming "downstream recipients"). - Upload new versions of the package. at the same time (though apparently they can do either of these activities as long as they don't do both at the same time). Please have this discussed/clarified in debian-legal as well. [1] In http://groups.google.com/group/tiraniaorg-blog-comments/browse_thread/thread/2a07b8b50038d8c8/d582162af2d63d57 de Icaza states that you need to "get/download Moonlight from Novell which will include patent coverage" [2] http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight
On Sun, Oct 05, 2008 at 01:07:16PM +0100, Jo Shields wrote: > Package: wnpp > Severity: wishlist > Owner: Jo Shields <[EMAIL PROTECTED]> > > > * Package name: moon > Version : 0.8.1 > Upstream Author : Everaldo Canuto <[EMAIL PROTECTED]> and others > * URL : http://www.mono-project.com/Moonlight > * License : LGPL-2, Ms-PL, Expat > Programming Lang: C, C# > Description : open source implementation of Microsoft Silverlight > > [...] Hi, The description is misleading. This is (AFAICT) not an implementation of a standard but a clone product, like wine, and much like wine it lags behind to the real one. Please make that clear in the description to avoid leading users (and specially web developers) to believe Silverlight is cross-platform. For example, the wine description reads: "This is still a work in progress and many applications may still not work." Also, this program depends heavily on codecs, and you didn't specify which ones you plan to use: - If those are the binary codecs from Microsoft, make it clear you plan to upload to contrib (not Debian). - If you want to use ffmpeg, please clarify the legal situation wrt license incompatibility mentioned by Moonlight's authors in: http://tirania.org/blog/archive/2007/Sep-05.html which appears to have prevented them from using ffmpeg, and forced them into licensing blobs from Microsoft. Unfortunately they aren't very explicit about what the problem is, but it is certain there is one, so please find that out, and have it discussed in debian-legal. Thanks -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381727: linuxbios ITP
reopen 381727 retitle 381727 coreboot -- Free Software BIOS replacement thanks Hi Uwe, I made a package of Coreboot today. Provides coreboot-qemu (with no payload) and coreboot-lar: http://people.debian.org/~rmh/coreboot/ How do we go about this? Are you still interested in maintaining Coreboot? If you like, we could team maintain it. I think that'd be the best since this package has the potential to become a lot of work to deal with. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492935: ITP: seabios -- Legacy BIOS implementation
Package: wnpp Severity: wishlist Owner: Robert Millan <[EMAIL PROTECTED]> * Package name: seabios Version : 0.2.3 Upstream Author : Kevin O'Connor <[EMAIL PROTECTED]> * URL : http://linuxtogo.org/~kevin/legacybios/ * License : GPL Programming Lang: C, i8088 asm Description : Legacy BIOS implementation SeaBIOS is a legacy BIOS implementation, aimed at supporting not only emulated hosts such as QEMU, but also real hardware. . Note, however, that SeaBIOS does not handle early initialization of core chipsets, so don't even think of flashing it to your board (look at Coreboot for that). . This package provides a build of SeaBIOS that can be loaded from GRUB 2. It's primarily targetted at systems that run non-BIOS flavours of GRUB (such as grub-coreboot, grub-efi or grub-ieee1275), to give them the capability of booting BIOS-based operating systems. Preliminary packages are available at: http://people.debian.org/~rmh/seabios/ -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480478: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sun, Jun 22, 2008 at 01:08:30PM -0500, Adam Majer wrote: > > Certainly, the backports.org keyring is useful to some people, *but* it is, > > 1. not free software I don't think there's a legal basis to claim copyright on a blob of random bytes generated by a program. Who's the copyright holder? gpg? The authors of gpg? The person who typed gpg in command-line? The entropy source? -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480478: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Mon, Jun 23, 2008 at 11:39:36AM +1000, Brian May wrote: > Luk Claes wrote: > >apt-get install debian-backports-keyring > > > >or > > > >gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C > >gpg --export | apt-key add - > > > This involves 3 separate commands, and modifies files under > /root/.gnupg/ at the same time. Seems overly complicated, especially for > non-technical people. Would it be possible to simplify this? The problem is not simplifiing the process, but finding one that is not flawed and actually provides security. This ITP is not about making it simpler. -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480478: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sun, Jun 22, 2008 at 10:34:15PM +0200, Luk Claes wrote:
> Robert Millan wrote:
> > On Sat, Jun 21, 2008 at 03:52:12PM +0200, Alexander Wirt wrote:
> >> I'm still not that sure if its a good idea to add a non-offical debian repo
> >> keyring into the archive... But I let the decision to the ftp-masters..
> >
> > Well, currently a problem is the only way to get a trusted path to the bpo
> > repository is by fetching debian-backports-keyring from it, checking your
> > signature in its .dsc, etc. So this is what I'm trying to solve.
>
> Hmm, are there not 2 other ways documented on backports.org as you can
> see below?
> --
> If you are using etch and you want apt to verify the downloaded
> backports you can import backports.org archive’s key into apt:
>
> apt-get install debian-backports-keyring
>
> or
>
> gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C
> gpg --export | apt-key add -
>
> or
>
> wget -O - http://backports.org/debian/archive.key | apt-key add -
> --
These examples just add the key to apt's keyring, but they don't provide any
trusted path to it. One has to blindly believe that the key being downloaded
by apt-get, gpg [1] or wget belongs to its owner.
[1] In the gpg example, you could happen to have a trusted key in your database
that provides a trusted path to bpo's key, but for the average user this is
IMHO not an acceptable solution.
--
Robert Millan
I know my rights; I want my phone call!
What good is a phone call… if you are unable to speak?
(as seen on /.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480478: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sat, Jun 21, 2008 at 03:52:12PM +0200, Alexander Wirt wrote: > I'm still not that sure if its a good idea to add a non-offical debian repo > keyring into the archive... But I let the decision to the ftp-masters.. Well, currently a problem is the only way to get a trusted path to the bpo repository is by fetching debian-backports-keyring from it, checking your signature in its .dsc, etc. So this is what I'm trying to solve. As for being non-official, I can try to make it clear in the package description that this key isn't officially endorsed by Debian, etc; does this sound fine to you? -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485553: ITP: charybdis -- fast, scalable irc server
On Tue, Jun 10, 2008 at 11:50:47AM +0200, Miriam Ruiz wrote: > 2008/6/10 Guus Sliepen <[EMAIL PROTECTED]>: > > On Mon, Jun 09, 2008 at 11:43:53PM -0500, William Pitcock wrote: > > > >> * URL : http://www.ircd-charybdis.net > >> * License : GPL > >> > >> Like oftc-hybrid, I intend to link this to OpenSSL. Since nobody > >> seems to care about that, I'm going to assume that it's OK. > > > > People DO care, and it is not OK. Linking with OpenSSL is only allowed > > if there is an exemption to the license of charybdis that explicitly > > allows linking to the OpenSSL. See for example this page which gives a > > nice summary and links to some related debian-legal emails: > > > > http://www.gnome.org/~markmc/openssl-and-the-gpl.html > > I don't know if it's possible, but you might want to try to link it to > GNUTLS [1] instead. GNUTLS has an OpenSSL portability layer, but it is not complete. It would require some porting work. Btw, the build system in ircd-charybdis considers OpenSSL an optional dependency. If it's an optional feature, why not just disable it untill a better solution is found? -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459902: Any progress with taking over nstx?
On Fri, May 23, 2008 at 01:32:45PM +0200, Franz Pletz wrote: > On Fri, 23 May 2008 08:59:27 +0200 Robert Millan wrote: > > On Sat, Mar 08, 2008 at 02:40:47PM +0100, Petter Reinholdtsen wrote: > > > > > > Hi. Looking at http://bugs.debian.org/459902 >, I suspect but > > > are not sure if you are still planning to take over nstx. The > > > change of ownership make me unsure. Are you still planning to take > > > over nstx? > > > > No reply. I guess this means not. > > Sorry for not responding earlier. It's okay for me you takeing over > maintenance. No problem. If you have more time later on, consider joining in. > However, please be aware that I had problems getting nstx > to run on amd64. Which problems? It works for me on amd64 client with i386 server. Do you run amd64 on both client and server, or some other combination? Though, if you need to ellaborate perhaps it's best if you file a bug report. -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459902: Any progress with taking over nstx?
retitle 459902 O: nstx -- Tunnel IP over DNS owner 459902 ! retitle 459902 ITA: nstx -- Tunnel IP over DNS thanks On Sat, Mar 08, 2008 at 02:40:47PM +0100, Petter Reinholdtsen wrote: > > Hi. Looking at http://bugs.debian.org/459902 >, I suspect but > are not sure if you are still planning to take over nstx. The change > of ownership make me unsure. Are you still planning to take over > nstx? No reply. I guess this means not. -- Robert Millan I know my rights; I want my phone call! What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439965: ITP: grubutil-win32 -- GRUB win32 utilities
Package: wnpp Severity: wishlist Owner: Robert Millan <[EMAIL PROTECTED]> * Package name: grubutil-win32 Version : 1.1-18 * URL : http://download.gna.org/grubutil/ * License : GPL (v2 or later) Programming Lang: C, 386 asm Description : GRUB win32 utilities This package provides GRUB boot record images that can be used by the native bootloaders of various win32 platforms in order to load a full instance of GNU GRUB. . It is built using the grub-pc package dynamicaly to generate a GRUB kernel, and then embedding that kernel with the necessary glue code to accomplish its task. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381727: linuxbios ITP
On Mon, Jul 23, 2007 at 01:06:29PM +0200, Uwe Hermann wrote: > Yep, good point. I'll see to have a package ready in a few days. Good. Let me know if you can use some help. > I definately want to ship a QEMU target, sure. > > The hardware targets could also make sense in LinuxBIOSv3, as there is a > tool which allows you to "inject" any payload into an otherwise "empty" > LinuxBIOS image. Which payload did you plan to put in the qemu target? I'm prospectively looking at the GRUB port (there's a SoC project) to build a LinuxBIOS image based on that. If you think that's good enough, we can go for it. Or otherwise we could use this "inject" feature to make the LinuxBIOS package payload-agnostic, and let payloads be handled separately. > Also, there will be a linuxbios-source package which > you can install and build your own images from scratch, too. Are you sure users will prefer this over upstream svn? Since proper operation of the code is so critical, I'd expect them to look for svn revisions that have been labeled as "good" for their hardware, which differs from user to user. That (and the fact that providing QA can become tedious) is why I was only thinking about qemu builds (at least for now). -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381727: linuxbios ITP
Hi Uwe, This ITP looks quite old. Are you still working on this? I would like a linuxbios package with an image that can be used with qemu. I'm not sure if you're targetting qemu (and bochs/etc) only or real hardware builds (is the latter feasible for debian?). But in either case, we can work together. I'll be glad to help at least in the qemu part. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#283005: ispCP debian package
On Mon, Jun 18, 2007 at 03:41:20PM -0500, Raphael wrote: > > I'm not sure about this, but I think DD's won't like upgrade stuff > from a package that never existed in the Debian rep to a new coming > one. That sounds perfectly reasonable to me. Specially if there has been a debian package around, even if not part of Debian. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383934: VHCS debian package
On Thu, May 31, 2007 at 12:41:51PM -0300, Dererk wrote: > > Thanks for answering so soon, Hendrik! > > I agree 100% with you, there's no sense in risking everyone with a no > longer maintained soft, I didn't even known this fork existed. > > Fortunately it's in heavy development, and, as you mentioned, It's > indeed released on 1.0 RC2. > > I'm giving it a try, and I'm proposing it being packaged. Volunteers? :-) > > > Therefore, I think there's not sense in keeping this two bugs open. I'm > closing this. Why not retitling/reusing instead? You could retitle one to be used for ispcp, and the other to be left as a record of why it's not worthy to package vhcs (since it's likely that someone will look at it later and be benefitted from this information). -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409593: trusted?
When you say trusted, do you really mean trusted, or treacherous? If this package has nothing to do with Treacherous Computing, please say it clearly to avoid confusion. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409591: trusted?
When you say trusted, do you really mean trusted, or treacherous? If this package has nothing to do with Treacherous Computing, please say it clearly to avoid confusion. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425038: ITP: win32-loader -- Debian-Installer loader for win32
On Fri, May 18, 2007 at 02:08:38PM -0400, Joey Hess wrote: > Robert Millan wrote: > > Then there are three components that will be included in the source package > > and > > not automaticaly built from source. All them will be eventualy sorted out, > > but > > for now it means the package will be in contrib. I summarise them here: > > Hmm, I'm unsure if binary software will be let in contrib. Since it does > have source code, just FTBFS, this is something of a grey area. I think it fits in Policy 2.2.2: "Examples of packages which would be included in contrib are: * free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution, and [...]" MSVC is one of these packages which "are not in our archive at all". > > It's a deb now, but I can switch it if that's more convenient. I'm not > > familiar with BYHAND, isn't it a nuissance for ftp-masters? Also, can you > > give an example of BYHAND package so that I can have a look and see how it > > works? > > debian-installer is currently one of (the only?) byhand package. See the > dpkg-distaddfile call in its rules file. Will have a look. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425038: ITP: win32-loader -- Debian-Installer loader for win32
On Fri, May 18, 2007 at 01:27:57PM -0400, Joey Hess wrote: > Robert Millan wrote: > > * License : GPL > > Have all the non-free bits been done away with now? There have never been any non-free bits :-) There was an issue with some NSIS code whose copyright wasn't clarified, that got resolved (there was a mail from you in debian-boot about this, can't find it now). Then there are three components that will be included in the source package and not automaticaly built from source. All them will be eventualy sorted out, but for now it means the package will be in contrib. I summarise them here: - System.dll (from NSIS) can't be built without using propietary software (see bug #31). My package takes the binary from official NSIS .zip. - wget.exe can't be built from unmodified wget sources, and given that it's only needed temporarily untill we solve #412285, I didn't want to bother its maintainer about adding cruft to build it. - grub4dos is not in debian. Since I grub4dos is based on GRUB Legacy, which is deprecated, I don't want to add a new package for something that ought to disappear anyway. I expect that GRUB 2 will meet the requisites so that the unmodified upstream version can be used instead. > Do you plan to package it as a deb, or as a BYHAND tarball? The latter > would be most useful, so that the exe file is available unpacked on the > mirrors. It's a deb now, but I can switch it if that's more convenient. I'm not familiar with BYHAND, isn't it a nuissance for ftp-masters? Also, can you give an example of BYHAND package so that I can have a look and see how it works? -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425038: ITP: win32-loader -- Debian-Installer loader for win32
On Fri, May 18, 2007 at 06:47:37PM +0200, Nico Golde wrote: > * Robert Millan <[EMAIL PROTECTED]> [2007-05-18 18:38]: > > Package: wnpp > > Severity: wishlist > > Owner: Robert Millan <[EMAIL PROTECTED]> > > > > * Package name: win32-loader > > * URL : http://goodbye-microsoft.com/ > > * License : GPL > > Programming Lang: NSIS, C, Bash. > > Description : Debian-Installer loader for win32 > > > > This package provides a win32 program that can be used as a loader for > > Debian Installer, acting as a more user-friendly boot mechanism than > > traditional BIOS-based boot. > [...] > While I think this is a pretty cool program, why should we > ship win32 programs in Debian packages? I mean if I install > it I can't do anything with it on my Debian box. Because d-i can build-depend on it to generate win32-boot capable CDs, similarly to how it's done with syslinux. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425038: ITP: win32-loader -- Debian-Installer loader for win32
Package: wnpp Severity: wishlist Owner: Robert Millan <[EMAIL PROTECTED]> * Package name: win32-loader * URL : http://goodbye-microsoft.com/ * License : GPL Programming Lang: NSIS, C, Bash. Description : Debian-Installer loader for win32 This package provides a win32 program that can be used as a loader for Debian Installer, acting as a more user-friendly boot mechanism than traditional BIOS-based boot. It can act as a standalone netboot loader (for a practical example, see http://goodbye-microsoft.com/), or as a cdrom/usb-disk add-on that starts a media-based install. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#415955: Bug#417030: please support GRUB Invaders in 'update-grub'
On Sun, Apr 01, 2007 at 09:49:42PM -0300, Otavio Salvador wrote: > Fabian Greffrath <[EMAIL PROTECTED]> writes: > > > Please add support for the GRUB Invaders game to the 'update-grub' > > script. GRUB Invaders is a very small (~4kB) multiboot compliant Space > > Invaders clone which runs directly on a computer (i386), without an > > operating system. It is meant to be started with the GRUB bootloader for > > PCs [0,1]. > > Hello Fabian, > > We intend to replace GRUB with GRUB2 as soon as possible and we're > planing to push the new update-grub script there too. I would like to > ask you if you could wait a cuple of weeks while we do that and then > you'll be able to provide the module for update-grub in your package. > > Robert, do you agree with me? Yes. And adding support for a game in GRUB is no justification for getting a new GRUB into etch at this time. When I have some time, I'll finish my work on update-grub2 and integrate it upstream. The current update-grub in GRUB2 package is NOT update-grub2. Please don't submit patches against it either, it'll completely be replaced. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410061: please move to contrib
On Tue, Mar 27, 2007 at 11:46:00AM +0100, Rob Andrews wrote: > On 24-Mar-2007 23:44.02 (GMT), Robert Millan wrote: > > > Never the less, if it's decided that nspluginwrapper should go into > contrib, > > > then into contrib it should go. > > I suppose that we're deciding that as we speak :-) > > I neglected to mention, I updated the package found at > http://choralone.org/debian/n/nspluginwrapper/ last night, and it sets its > section as "contrib/utils". Ah, that is good. Thank you. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410061: please move to contrib
On Sat, Mar 24, 2007 at 10:01:09PM +, Rob Andrews wrote: > On 24-Mar-2007 21:06.39 (GMT), Robert Millan wrote: > > > This also allows the usage of free plugins as well. > > > Feasibly, ia32-libs' only purpose is to allow the execution of software > that > > > cannot be recompiled natively. By example, that should also be in > contrib. > > How many free plugins are out there that don't work on amd64 ? > > Few, but feasibly someone could choose to use an i386 binary of a GPLed > project with nspluginwrapper. How feasable is that? Can you give an example? Also note that if GPLed plugins that have 64-bit issues, it's more productive to fix those issues than running them through a wrapper that presumably has other problems (reportedly, crash conditions). In the context of a pure DFSG environment, I see a loss in that rather than a gain (in the sense that it misleads users into addressing the wrong problems). (of course, without the context of a pure DFSG env this may no longer apply, but then we're in contrib land already ;-)). > What users choose to do with the software is > not a reflection on the software itself. We don't consider unfeasible uses of software to stablish main/contrib separation. Think of the implications: one could argue that flashplugin-nonfree belongs in main, because you can copy the script to /dev/random to fill your entropy pool :-) I don't claim that nspluginwrapper use in a pure DFSG env is unfeasible, but I haven't seen anything supporting that, and to me it seems unlikely. > The area of what software it could run is dependant on how the user chooses > to use it. As I mentioned, ia32-libs' primary purpose is to run software > that cannot be recompiled for amd64/ia64. However, it can feasibly both run > free and non-free software. But it goes into main. ia32-libs can be useful if you want to run apache in 32-bit mode because this gives you higher memory efficiency in a performance-critical environment. > Never the less, if it's decided that nspluginwrapper should go into contrib, > then into contrib it should go. I suppose that we're deciding that as we speak :-) -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410061: please move to contrib
On Sat, Mar 24, 2007 at 09:15:18PM +, Rob Andrews wrote: > On 23-Mar-2007 23:07.11 (GMT), Robert Millan wrote: > > I hope you didn't upload to main like the preliminar version at > > http://choralone.org/debian/n/nspluginwrapper/ suggests. This program is > > a helper for running non-free software, hence contrib stuff. > > This also allows the usage of free plugins as well. > > Feasibly, ia32-libs' only purpose is to allow the execution of software that > cannot be recompiled natively. By example, that should also be in contrib. How many free plugins are out there that don't work on amd64 ? -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410061: please move to contrib
I hope you didn't upload to main like the preliminar version at http://choralone.org/debian/n/nspluginwrapper/ suggests. This program is a helper for running non-free software, hence contrib stuff. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388701: beryl in xorg.conf
FYI: #412069 This Works For Me [tm], but I thought you might want to drop some commments. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344417: closed by David Moreno Garza <[EMAIL PROTECTED]> (WNPP bug closing)
reopen 344417 thanks Please don't close this ITP. It's being maintained outside of Debian, and I suppose it'll be uploaded to unstable eventualy. The SVN tree is available at: http://svn.debian.org/wsvn/glibc-bsd/trunk/freebsd6-buildutils Could you add an override in your script to exclude this ITP? -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#203211: Software patents and Debian
On Wed, Aug 16, 2006 at 11:04:44AM +0200, Bas Wijnen wrote: > Hello, > > When looking for some video-editing software, I found avidemux. According to > the wnpp bug, there is a problem with license issues regarding the MPEG2/MPEG4 > codec. There is a software patent on this codec, and a paid license is needed > in order to use it, appearantly. > > My question is how Debian handles software patents. I thought we didn't care > about them except if they were actively enforced, because it's completely > impossible to avoid all patented software, considering the junk that gets > patented. If that is the case, would any of you know if the MPEG[24] codec > patents are actively enforced? In other words, can this be in Debian? > > Thanks, > Bas Wijnen > > Ps: Please keep me CCd, I'm not on the list. Why not just removing the offending code and leaving avidemux only with support for patent-free codecs like theora? -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#283005: VHCS debian package
It seems there's a package available already: http://vhcs.puuhis.net/wiki/index.php/Getting_started http://apt.scunc.it/pool/sarge/main/v/vhcs/ Very complete, with debconfiscated setup, etc. Hendrik, do you have plans for getting this into the official archive? -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
