Proposal: cdrkit vs. cdrtools
Dear Colleagues, as I wrote on http://www.sourcecode.de/content/cdrkit-vs-cdrtools I really wonder what way we should go. Regarding the non-freeness of cdrtools, we should concentrate on getting the cdrkit binaries to the upstream projects. Most of the apps I found in debian/ubuntu, which are using mkisofs/cdrecord as exec calls, could be patched easily to use genisoimage/wodin. Having an option compatiblity between e.g. cdrecord and wodin, this should work out of the box. Do you think it's worth the efford? Regards, \sh PS: Discussion on u-d-d, Reply-To set please honour it. -- SysAdmin, OSS Developer GPG-Key ID: 0xC098EFA8 Fingerprint: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 http://www.sourcecode.de/ signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Proposal: cdrkit vs. cdrtools
Stephan Hermann wrote the following on 13.01.2008 15:17 Dear Colleagues, as I wrote on http://www.sourcecode.de/content/cdrkit-vs-cdrtools I really wonder what way we should go. Regarding the non-freeness of cdrtools, we should concentrate on getting the cdrkit binaries to the upstream projects. Most of the apps I found in debian/ubuntu, which are using mkisofs/cdrecord as exec calls, could be patched easily to use genisoimage/wodin. Having an option compatiblity between e.g. cdrecord and wodin, this should work out of the box. Do you think it's worth the efford? Regards, \sh PS: Discussion on u-d-d, Reply-To set please honour it. [quote] For Ubuntu, cdrtools is in multiverse... [/quote] according to packages.ubuntu.com cdrtools isn´t in the archive since edgy and even in edgy it is only a transitional package only iirc. [quote] The Gentoo Linux ebuild for cdrkit installs symlinks to provide compatibility with applications looking for old cdrtools binaries: /usr/bin/cdda2wav - /usr/bin/icedax /usr/bin/cdrecord - /usr/bin/wodim /usr/bin/mkisofs - /usr/bin/genisoimage /usr/bin/readcd - /usr/bin/readom + a few more (manpages, etc) Seems to work fine because, as you say, the cdrkit binaries take the same options, and using symlinks saves on patching all the other applications depending on cdrtools. [/quote] in the light of the above i think this is the easiest way. -- bye Thilo key: 0x4A411E09 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Patching
Am 13.01.2008 um 02:45 schrieb Bryan Quigley: I don't believe either is implemented yet: Torrents check files in pieces so if some of the pieces have not changed they won't need to be redownloaded. While this sounds good in theory, it rarely works in practice: Remove a byte from the first chunk and all other chunks will point to a different range of the remaining file, resulting in a different hash and re-download of all chunks. Am 12.01.2008 um 21:41 schrieb Evan: Cons: - The method I described can't handle updates to non-binary files (help files, icons, etc.) This would have to be integrated somehow. I can't follow you here as _any_ file can be handled as binary. Like Subversion does, for example. IMHO, a successful patch mechanism would store the complete package on both ends. Just for downloading, a server could offer a patch against an already downloaded, similar package to make the download faster/using less bandwidth. A good patching algorithm isn't trivial and could include extracting and re-assembling the package on the client side. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Proposal: cdrkit vs. cdrtools
Hi, On So, 2008-01-13 at 17:29 +0100, Thilo Six wrote: Stephan Hermann wrote the following on 13.01.2008 15:17 Dear Colleagues, as I wrote on http://www.sourcecode.de/content/cdrkit-vs-cdrtools I really wonder what way we should go. Regarding the non-freeness of cdrtools, we should concentrate on getting the cdrkit binaries to the upstream projects. Most of the apps I found in debian/ubuntu, which are using mkisofs/cdrecord as exec calls, could be patched easily to use genisoimage/wodin. Having an option compatiblity between e.g. cdrecord and wodin, this should work out of the box. Do you think it's worth the efford? Regards, \sh PS: Discussion on u-d-d, Reply-To set please honour it. [quote] For Ubuntu, cdrtools is in multiverse... [/quote] according to packages.ubuntu.com cdrtools isn´t in the archive since edgy and even in edgy it is only a transitional package only iirc. This is not correct...according to soyuz: https://edge.launchpad.net/ubuntu/+source/cdrtools/10:2.01.01a33-0ubuntu2 the last version was in gutsy...and the removal was requested on 2008-01-09. Therefore we have several packages not working anymore :) To sum up: Two ways are valid: 1. We add Provides to the cdrkit binary packages and install ln -s /usr/bin/cdrkit binary name /usr/bin/cdrtools binary name 2. We could provide patches for Debian/Ubuntu and Upstream to support both ways.. I generated a list of source packages to find out what packages are involved: Hopefully with the correct output :) Command: [EMAIL PROTECTED]:~$ for i in `grep-dctrl -F Depends,Suggests,Recommends $SEARCHTERM /var/lib/apt/lists/*binary*|grep Package|cut -d -f 2` ; do grep-dctrl -F Binary $i /var/lib/apt/lists/*Source* | grep Package ; done - $SEARCHTERM = mkisofs - Package: devede Package: mythplugins Package: aptoncd Package: backup-manager Package: backupninja Package: bootcd Package: nautilus-cd-burner Package: xfburn Package: burn Package: cpuburn Package: libburn Package: mp3burn Package: mybashburn Package: cdrbq Package: cdrw-taper Package: cedar-backup2 Package: debian-cd Package: dfsbuild Package: ebox Package: ebox-ca Package: ebox-firewall Package: ebox-network Package: ebox-ntp Package: ebox-objects Package: ebox-openvpn Package: jukebox-mercury Package: libebox Package: zeroc-ice Package: fai Package: fai Package: gtoaster Package: hubackup Package: ichthux-meta Package: kiso Package: live-helper Package: mindi Package: mindi-busybox Package: pybackpack Package: systemimager Package: videolink Package: xcdroast - $SEARCHTERM = cdrecord - Package: mythplugins Package: arson Package: backupninja Package: bootcd Package: nautilus-cd-burner Package: xfburn Package: burn Package: cpuburn Package: libburn Package: mp3burn Package: mybashburn Package: cdbackup Package: cdcontrol Package: cdrbq Package: cdrw-taper Package: cedar-backup2 Package: gtoaster Package: hubackup Package: ichthux-meta Package: lphoto Package: mondo Package: mp3roaster Package: dpkg-multicd Package: multicd Some of those packages do have support for cdrkit, but some of them don't. E.G. I patched qvamps to use wodim/genisoimage instead of cdrecord/mkisofs. This tool doesn't even have autodetection. So this could be a candidate for a professional cdrkit/cdrtools detection and not only a quickpatch ;) But which way we go, this should be discussed here ;) Regards, \sh -- SysAdmin, OSS Developer GPG-Key ID: 0xC098EFA8 Fingerprint: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 http://www.sourcecode.de/ signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Proposal: cdrkit vs. cdrtools
Stephan Hermann wrote the following on 13.01.2008 20:20 Hi Stephan according to packages.ubuntu.com cdrtools isn´t in the archive since edgy and even in edgy it is only a transitional package only iirc. This is not correct...according to soyuz: https://edge.launchpad.net/ubuntu/+source/cdrtools/10:2.01.01a33-0ubuntu2 the last version was in gutsy...and the removal was requested on 2008-01-09. Therefore we have several packages not working anymore :) jup you are right. I have searched the binary section only, not for source package names sorry for the noise. /snip Regards, \sh -- bye Thilo key: 0x4A411E09 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Making 32-bit .debs for 64-bit systems
I use an amd64 system, but some applications are only available for the i386 architecture. Some prominent examples are Adobe Flash, Google Earth, and zsnes (which is written in assembly language, so I don't reckon to see it ported EVER.) I can usually get these i386 programs to run, but they require 32-bit libraries. ia32-libs has a whole bunch of i386 libraries for amd64, but it's not a complete solution. I recently had to install a 32-bit libselinux and libsepol to get Flash to run; they weren't included in ia32-libs. I did this by downloading the i386 .deb from packages.ubuntu.com, extracting the package, and manually copying all the files from the package's /usr/lib to my /usr/lib32. zsnes requires a 32-bit libsdl, which I also have to manually install. Are there any guidelines for creating .deb packages to install i386 libraries on amd64 systems? Is it enough to simply map /usr/lib to /usr/lib32 or are there other complications I need to deal with? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
tracking down suspend/hibernate bugs?
hi, just upgraded to hardy and suspend-to-ram is broken again (as in feisty other releases) i'm trying to figure out, again, how to track down this bug but i'm not entirely sure what the current chain of events is in the suspend process. can someone point me to a location where the process is described? or suggest best practice for finding bugs of this nature (in which resume is impossible, so messages e.g. from dmesg or /var/log/messages don't get captured? thanks, matt -- Matt Price [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: tracking down suspend/hibernate bugs?
In gutsy I believe the chain is this: gnome-power-manager - hal (/usr/lib/hal/scripts/hal-system-power-suspend) - acpi-support (/etc/acpi/sleep.sh) most of the actual work occurs in acpi-support. hal may call a different tool than acpi-support if it is available though, see /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux for full details. Aren Olson On Jan 13, 2008 7:42 PM, Matt Price [EMAIL PROTECTED] wrote: hi, just upgraded to hardy and suspend-to-ram is broken again (as in feisty other releases) i'm trying to figure out, again, how to track down this bug but i'm not entirely sure what the current chain of events is in the suspend process. can someone point me to a location where the process is described? or suggest best practice for finding bugs of this nature (in which resume is impossible, so messages e.g. from dmesg or /var/log/messages don't get captured? thanks, matt -- Matt Price [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Whoever said sunshine brings happiness has never danced in the rain. - K. Jackson Ubuntu Linux - www.ubuntu.com -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
