Bug#583863: ITP: python-gudev -- Python bindings for gudev
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: python-gudev Version : 147 Upstream Author : John Stowers * URL : http://github.com/nzjrs/python-gudev * License : GPL Programming Lang: C Description : Python bindings for gudev The gudev library makes it much simpler to use libudev from programs already using GObject. . This package provides a Python binding to gudev. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531081851.2848.40411.report...@quadrispro-laptop
Re: Archive area for clamz (Amazon MP3 downloader)
On 2010-05-30, brian m. carlson wrote: > The difference is that those tools provide a reasonable level of > functionality with free data. Weather information is in the public > domain because there's no originality to it. Most programs that display > lyrics or album covers are music players, and there is free music > (available in our archive, no less) that they can usefully play. Console emulators like zsnes are in main, I think because there used to be at least one free ROM it can be used with (be it useful or not). Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni06sht.e9f.tr...@kelgar.0x539.de
Re: Re: Bug#529974: RFP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol
There must be a good *reason* why Christian still maintains ffmpeg and mplayer in d-m.o even though same-named packages are also in Debian. Maybe he likes the extra work?? Maybe because he activates some 5 more built-in encoders in ffmpeg and links it against some 5 more libraries like libmp3lame and libx264, which we can't since they are not in Debian. And no, it turns out he does not set value on collaboration with the Debian pkg-multimedia team or even attempt to keep his libraries at least binary compatible to the ones in Debian. Please concern yourself with the multimedia patent and codec situation in Debian next time, before you post bullshit to debian-devel. - Fabian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c03718f.8030...@greffrath.com
Re: Anounce of a secure repo for debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Mo den 31. Mai 2010 um 5:42 schrieb Christian PERRIER: > > This repository holds secured packages of the insecure debian packages > > just without the insecure patch (or the insecurity patched). The full > > sources are available to build. At the moment the repository holds > > base-files, openssh and procmail. > > Is this repository signed by a key? Yes, my own key. But read below. > Where is that key available? On Keyservers and signed by many people. > By who is this key signed? Many people, including some DDs. > Are there people around to speak and guarantee that the repository > owner is not providing malicious packages through this "secured" > repository? Thats the point. Nobody can do that. Thats the reason I hold the changes as small as possible and upload the full sources to the repo too. The point is that I cannot live with the insecure debian packages at all. So I builded that packages for my own. The repository is to give the secured packages to people who need it too. There is no need to develop the wheel every time again. > Don't take be wrong. I do not. I was thinking about that too. But I decided to make it available anyway. > though I certainly do question the technical arguments you brought in > this thread and the way you did it (the umsak 'disaster'). Well, I think (and I am not alone with this opinion) that the umask changes are a security disaster. And I do not want to make secret of it. > Unless the packages you provide are inspected by the same web of trust > that lives around the official Debian repository, Well, the web of trust seems to fail in this case. > I think that potential users should definitely be warned that they're > using it at their own risk (the same stands for any private > repository, of course, including those I manage myself...:-)). Yes, its a good idea. At the moment the repository is just as it is and it holds the secured packages I use by my own. However, I will consider to add such a note. Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTAN+Lp+OKpjRpO3lAQoMwAf+JvdiNfa+rJT48Ey6ZTIst5IZcKqFHxbU h+/UwfW9jzNViVoV+lYgftM56lWDX3ka4+9eUzwtfvq1IA0ZswgjoqvO9oHhlnGR SE66/aNC/U2WOIR3kbfsnzY1DRCKxuho27+kVUGypGYUzDQVkz48L26rU77gS9c/ 9CtdzIxRUABUu44pCuLRCzHWad/0Tm6Qje4OEV4wWLrFfBFSBfYsVW65UlZLqO7G h4pP0sb7F9Wtpjts+SShqyxrKXeUZITyQsiunIEzwiBc72vbKn9Ac/ODPouDihuJ lynvhDCnJscnoo6HP5WUn9h2JvPcvrr3Rvg+bnlgt5K19tlkUpUSiA== =uObw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531091526.gb27...@ikki.ethgen.de
add my id for linkexchange
add my id for linkexchange m...@megrisoft.info -- Regards mark contact me at : m...@megrisoft.info
Re: Anounce of a secure repo for debian
On Mon, 31 May 2010 06:42:57 +0200 Christian PERRIER wrote: > Quoting Klaus Ethgen (kl...@ethgen.de): > > cause of the recent umask disaster I decided to start a repository for > > packages which are insecure in debian distribution. and which are hosted in an unverifiable repository. Hmmm. At the very least, the public key should be available on the server itself and it should preferably be in an archive-keyring package in Debian. e.g. emdebian-archive-keyring and http://www.emdebian.org/packages/keys.html > > You can find this repository at ftp://ftp.ethgen.de/pub/debian-security > > (deb ftp://ftp.ethgen.de/pub/debian-security sid unofficial-secured). > > This repository holds secured packages of the insecure debian packages > > just without the insecure patch (or the insecurity patched). The full > > sources are available to build. At the moment the repository holds > > base-files, openssh and procmail. > > Is this repository signed by a key? gpgv: Signature made Sun 30 May 2010 19:01:45 BST using RSA key ID D1A4EDE5 gpgv: Can't check signature: public key not found > Where is that key available? I assume it's this one: pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <(E-Mail Removed)> Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B I found a listing of it in the Google cache but keyserver.kjsl.com appeared to be down and subkeys.pgp.net didn't report having that key. (I since imported it from the ASCII and added it to subkeys.pgp.net but with the current unreliability of keyservers, that didn't appear to help much. keys.gnupg.net does have it.) > By who is this key signed? Found it on pgp.net.nz also: http://pgp.net.nz:11371/pks/lookup?op=vindex&search=0x9F8E2A98D1A4EDE5 There are some signatures there which I recognise, Peter Palfrader being the most obvious to me. > Are there people around to speak and guarantee that the repository > owner is not providing malicious packages through this "secured" > repository? > Don't take be wrong. I don't question your honesty even though I > certainly do question the technical arguments you brought in this > thread and the way you did it (the umsak 'disaster'). But calling a > private repository "secured" is certainly something that is very > highly debatable. > > Unless the packages you provide are inspected by the same web of trust > that lives around the official Debian repository, I think that > potential users should definitely be warned that they're using it at > their own risk (the same stands for any private repository, of course, > including those I manage myself...:-)). I would question the safety / reliability of using a repository that forces the creation of Packages and Sources and Release files by hand instead of using a reliable, reproducible tool like reprepro. The site even includes the Makefile that shows the hacks used to make the repository files. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp1iygFDJZ7E.pgp Description: PGP signature
Re: completeness of the upg tests
On Sat, May 29, 2010 at 12:34:38PM +0200, C. Gatzemeier wrote: > > Thank you Harald for scrutinizing. > > Am Fri, 28 May 2010 14:50:27 +0200 > schrieb Harald Braumann: > > If that externel system means to have UPGs, but does not support > propper ID allignment (like debian, at least in the last releases), one > will have to fix it or set a fixed umask, yes. ACK > Same can be true in cases where a custom site-wide UPG user database is > used. In this case, exactly as you wrote, manually setting a > default umask is an option, if the IDs are not alligned or the user is > explicitly added to his primary group. ACK > > > And in those > > cases where it fails, I'd expect it to fail only for specific cases > > that might go unnoticed for a long time and might be hard to analyse. > > It's probably better if these are cases where the umask hasn't been > relaxed, than cases where a fixed 002 umask is to permissive. This is a > case for the 022 default with "usergroups" relaxation. > Then if one has UPGs, but notices the umask is not 002 for some > users, one checks login.defs and is informed about the checks and given > a way to set a fixed umask. ACK > However in case the external System properly supports alligned IDs (RH, > etc.) I currently don't see where any rare cases of misbehaviour in > either way should come from. The tests should work equally well even > with "mixed usersgroups". Just like on the external system itself. ACK > If the external user database is non-UPG, this is the case where the > tests prove most useful and provide security over setting a system wide > 002 umask as a default. (Additionally it is a case where the admin can > choose to turn umask relaxation off for peace of mind.) ACK > To shield against any cases of username==groupname (say a "vip" user > and group, or any other case of matching initials) where only > coincidently UID==GUID match, I asked to check if "vip" is the primary > group of the "vip" user and "vip" user is not an explicit member of the > "vip" group. > > I believe this completes the checks (see below) I don't, and that is what I meant by wishful thinking. Nowhere is it guaranteed that it works this way. Even if there where guarantees by POSIX, which I'm not aware of, you could as well authenticate against an Active Directory or a Lotus Domino Directory exported as an LDAP tree or some directory that is managed by homegrown scripts. Does it work that way there? pam-umask's usergroups options does the right thing in many cases. But only the admin can know if the user database conforms to the necessary critera. And in that case, he can enable it and use it for automatic umask relaxation. But it shouldn't be the default if you can't guarantee that it works in all cases, and you can't. Yes, it is a slight inconvenience that you have to explicitely enable it for the many systems where it will work. But that is very often the case: that you trade convenience for security. It always depends on your priorities. If your priority is convenience, you will use auto-detection. If your priority is security, you will keep 022 as default umask and don't use auto-detection on default. Cheers, harry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531101754.gb4...@sbs288.lan
Re: test if primary group, with only implicit membership of the user?
On Sat, May 29, 2010 at 03:49:25PM +0200, Petter Reinholdtsen wrote: > > [Harald Braumann] > > Why would you create such a mixed system? I don't see a usecase for > > that. > > You should not really allow your lack of imagination to limit what > computer systems can handle. :) > > Here at the University of Oslo, the user database is probably 25 years > old, and some users have private groups as their primary group while > others have shared groups. Of course the system should be flexible enough to support such legacy systems and even systems I can't imagine. And it is, and that's a good thing. I just meant that Debian doesn't have to deliver ready-made solutions for all possible imaginable and unimaginable set-ups. Cheers, harry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531102754.gc4...@sbs288.lan
Re: Anounce of a secure repo for debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am Mo den 31. Mai 2010 um 10:49 schrieb Neil Williams: > At the very least, the public key should be available on the server > itself and it should preferably be in an archive-keyring package in > Debian. Sure. And I plan to do so. But for the moment there is just that packages I told about. > gpgv: Signature made Sun 30 May 2010 19:01:45 BST using RSA key ID > D1A4EDE5 Correct. > > Where is that key available? > > I assume it's this one: > pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <(E-Mail Removed)> > Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B See my signature, yes. > and subkeys.pgp.net didn't report having that key. Thats really strange. The key _is_ on this server so I do not know why you didn't find it. > I would question the safety / reliability of using a repository Thats always the case with additional repositories. And since APT do not show the source of a package in the default configuration makes this not better. > that forces the creation of Packages and Sources and Release files by > hand instead of using a reliable, reproducible tool like reprepro. Well, this method was grown since ages when reprepro was not available and I hadn't the time to migrate a working method to a /nice/ working method. > The site even includes the Makefile that shows the hacks used to make > the repository files. There is no reason to hide that, so, yes. Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTAOiSJ+OKpjRpO3lAQpRJgf9Hb7adxPjd+JqtPWxMNzL1DWXvyxTV+Lq iqGaQ50+LsVoJH6DJgdt/vxAc/J4vLujrhnBqsrjdKwcquV66kJx8reZDeIxawBl 0K0z01W19CYTlHCykE8j0QIJSahbhGAyw02k2cFr9ToXCbWUv337Ao2FmmE8UQO/ /T8SVqc7Xc3LkUT4PapiXDg8iN5qo8r5T6YFD4JQKu50bFPqQx8Azc3Ri7PxupU0 pTh00oWhg3zbrboYP/vn53KafZXvkayR3bPfyZZBIrGXSJ361GSaqWIdnCoGJu6D Bq/z6Qn4shM+j/TPFBRS9eJr7SY5zuxzK1iCGs+gLeqdjaTO78NbQg== =nJO2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531114928.ge27...@ikki.ethgen.de
Re: Archive area for clamz (Amazon MP3 downloader)
On Mon, May 31, 2010 at 5:24 AM, Philipp Kern wrote: > On 2010-05-30, brian m. carlson wrote: >> The difference is that those tools provide a reasonable level of >> functionality with free data. Weather information is in the public >> domain because there's no originality to it. Most programs that display >> lyrics or album covers are music players, and there is free music >> (available in our archive, no less) that they can usefully play. > > Console emulators like zsnes are in main, I think because there used to be > at least one free ROM it can be used with (be it useful or not). xmame-sdl is in contrib, though. I find it hard to draw the line between main and contrib unless there's non-free depends, it's all very subjective. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimraphv1jxbh4zkycsdx5wxjopohcv-oy7cp...@mail.gmail.com
Re: Bug#529974: RFP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol
On 05/31/2010 03:21 AM, Fabian Greffrath wrote: There must be a good *reason* why Christian still maintains ffmpeg and mplayer in d-m.o even though same-named packages are also in Debian. Maybe he likes the extra work?? Maybe because he activates some 5 more built-in encoders in ffmpeg and links it against some 5 more libraries like libmp3lame and libx264, which we can't since they are not in Debian. That's what I thought. Thanks for confirming it. And no, it turns out he does not set value on collaboration with the Debian pkg-multimedia team or even attempt to keep his libraries at least binary compatible to the ones in Debian. OK. Please concern yourself with the multimedia patent and codec situation in Debian next time, before you post bullshit to debian-devel. LOL Let me quote siret...@debian.org : http://lists.debian.org/debian-devel/2010/05/msg01131.html what licensing issues do you see in rtmpdump, ffmpeg or mplayer?! they are all (L)GPL which is perfectly DFSG compatible. Before you come up with FUD about patents, DMCA, etc. - pretty please don't. there is already enough FUD floating around. So, you say, "concern myself with patent issues", and Reinhard says, "ignore the patent issues". -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c03af18.2090...@cox.net
Re: Archive area for clamz (Amazon MP3 downloader)
Il giorno lun, 31/05/2010 alle 09.27 -0300, Fernando Lemos ha scritto: > xmame-sdl is in contrib, though. I find it hard to draw the line > between main and contrib unless there's non-free depends, it's all > very subjective. xmame-sdl is in non-free, IIRC. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1275309517.2404.13.ca...@zorn.fi.trl
Re: Archive area for clamz (Amazon MP3 downloader)
On 05/31/2010 12:54 AM, Yves-Alexis Perez wrote: On dim., 2010-05-30 at 21:18 -0500, Ron Johnson wrote: Clamz just moves some bits from Point A to Point B. I hope you don't use this as a definition of dfsg-free? Hardly. My (possibly flawed) thinking was originally raised here: http://lists.debian.org/debian-devel/2010/05/msg01136.html I just read http://www.debian.org/social_contract and it says nothing > about the kind of *data* that programs can touch; only software, > source code and the licensing of that source code is mentioned. Sean Finney seems to think the same way I do: http://lists.debian.org/debian-devel/2010/05/msg01168.html better yet, tell me which item in the DFSG says that a program can't be Free unless all the purpose or data handled by the software is also Free. hint: there isn't one. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c03b082.3040...@cox.net
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/30 Ludovic Brenta : > David Kalnischkies writes: >> 2010/5/29 Ludovic Brenta : >>> David Kalnischkies writes: No. Replaces is used to say to dpkg: It is okay that this package overrides files of the other package - otherwise dpkg would complain loudly for good reasons. It doesn't say something about the upgrade path. >>> >>> I disagree with this particular part of your analysis. What you say is >>> true of Conflicts, not of Replaces. IMHO, Replaces really, clearly >>> suggests an upgrade path. Why else would the package renaming procedure >>> require both Conflicts and Replaces? >> >> Consider a package A which moved from a bad example-config file to >> a full blown doc translated to 100 languages. The documentation is split >> out into a new package A-doc which will Replaces the old A version >> as it will override the "old" example-file. The A-doc package will end up as >> a Recommends or Suggests for A as it is not strictly needed to work with A. > > This example is wrong. (I thought of this one while writing it but want to be a bit more generic:) apt currently Replaces manpages-pl because it includes now the polish translation of its manpages itself. Is apt with this Replaces now a valid upgrade path for manpages-pl? Even (or especially) if only manpages-pl is installed on the user system? The Replaces says that if i upgrade apt i should at least try to upgrade manpages-pl before (if it is installed) to get right of the Replaces - it doesn't say that if i have manpages-pl installed i should install apt now as well as it doesn't say that i should install manpages-pl if i have apt installed. If i want that i need a Depends… > The consequence is that, despite the fact that these packages are broken > (without the need for a Breaks: in their successor packages, BTW), > aptitude prefers to leave them installed rather than remove them; this > in turn blocks upgrades. If aptitude hasn't changed its complete logic recently it will behave as apt and will never allow a user to move from a consistent into an inconsistent state, so either your words are misleading, i don't understand you or both. A package is not broken out of a sudden for a package manager. Either the install candidate of another package Breaks it, Conflicts with it or its dependencies in the candidate version are not satisfiable. A in this way "broken" package* is either kept (by not installing the other packages), upgraded (if dependencies allow it) or removed (if installing the other packages is considered more important than the install status of this package) These options are present and a package manager will chose one of those depending on how costly they are. If the remove of package A causes e.g. the remove of thousand other packages it is likely that A will be kept back instead. * It is only broken if the package manager would choose to upgrade regardless of the outcome. Its complete unrelated if the functionality of the package is broken. This can happen, and this need to be modeled with dependencies (Breaks and to a lesser extend Conflicts is what you want) as otherwise the package manager will not know about it. It (=the manager) can't follow rules it doesn't know… > and, of course, Depends: on the exact version of A, i.e. > > Package: A-doc > Depends: A (=2) I hope not as it would be broken for all binary non-maintainer uploads of A… And the Depends is at least questionable even without a version number (many *-doc packages don't depend on anything. And if they do the Depends is completely unrelated or extreme relaxed, only a small subset does it like you suggest it). Give it a try yourself: apt-cache show $(apt-cache search ^.*-doc$ --names-only | cut --delimiter=' ' -f 1 | sort -R | head -n 50) | grep -e 'Package: ' -e 'Depends: ' > Please read the Debian Policy for Ada, to which I provided a link (at > least section 3.2 "Ada Library Information files". I mean it. If you > don't then you cannot possibly understand the problem. I don't know anything about Ada and i don't have read the policy for it as i will not understand it because of that - but even if i would read it it doesn't change the dependencies written down - at least as long you haven't told all package managers like dpkg, apt and aptitude to read and understand your policy as well. Thats why i response here, i just want to help you understand what a package manager will do with your dependencies and that is independent from the content of the package. In the end you will need to write dependencies even a crappy piece of code can understand and at least for me it would be an indicator if even humanoid dependency solvers can't understand them… (Also, while a policy is free to declare that white is the new black it is a good idea to follow established rules and just say black.) Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Co
Re: Bug#529974: RFP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol
On Mo, Mai 31, 2010 at 14:44:08 (CEST), Ron Johnson wrote: >> what licensing issues do you see in rtmpdump, ffmpeg or mplayer?! they >> are all (L)GPL which is perfectly DFSG compatible. Before you come up >> with FUD about patents, DMCA, etc. - pretty please don't. there is >> already enough FUD floating around. > > So, you say, "concern myself with patent issues", and Reinhard says, > "ignore the patent issues". No, that's not what I'm saying. Read again. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6f0dx32@faui44a.informatik.uni-erlangen.de
Re: The story behind UPG and umask.
On Sun, 30 May 2010 15:02:41 +0100, Stephen Gran wrote: >This one time, at band camp, Marc Haber said: >> I am not a very good friend of just counting. I would try to somehow >> hash the user name into the UID since this will - at least on systems >> with only a handful of users - enhance the chance that the same user >> name will get the same UID on different systems. > >There are already well understood mechanisms for ensuring that uids are >the same across multiple systems. I don't think adduser is the place >for that. If you think Directory Services, I doubt that my customers would allow me to put all systems that I operate in their environment (seldomly more than a handful per customer) on a single directory service. But I really like the idea of having all "Debian-exim" accounts with the same UID on all systems as this incredibly eases moving things (such as configuration templates) from one box to the other. This might be old-fashioned and paranoid, but it really eases life. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oj52s-0001op...@swivel.zugschlus.de
Re: Parallellizing the boot in Debian Squeeze - ready for wider testing
On Sun, 2010-05-16 at 14:18:57 +, Clint Adams wrote: > On Sat, May 15, 2010 at 10:57:56PM +0200, Petter Reinholdtsen wrote: > > > Was this request ever actually made to the kfreebsd porters? I'm not sure > > > that it was, in which case it's rather unfair to say that they've had > > > enough > > > time when they were never informed this was a pressing issue. > > > > One request was done last summer, see > > http://lists.debian.org/debian-bsd/2009/07/msg00117.html >. > > If I were a kfreebsd porter I'd interpret that as "would anyone like > to help port upstart?" rather than "we're going to shove upstart down > your throat, comply or else." Actually, rather than just porting, given both upstart and systemd upstream stances, it seems to me it would imply becoming upstream for a fork for each or all non-Linux ports. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531132317.gb10...@gaara.hadrons.org
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
David Kalnischkies wrote:
> 2010/5/30 Ludovic Brenta :
>> The consequence is that, despite the fact that these packages are
broken
>> (without the need for a Breaks: in their successor packages, BTW),
>> aptitude prefers to leave them installed rather than remove them; this
>> in turn blocks upgrades.
>
> If aptitude hasn't changed its complete logic recently it will behave as
> apt and will never allow a user to move from a consistent into an
> inconsistent state, so either your words are misleading, i don't
> understand you or both.
I explained in my original post; please re-read it and then you will
understand. Hint: removal of gnat-4.3.
[...]
>> Package: A-doc
>> Depends: A (=2)
>
> I hope not as it would be broken for all binary non-maintainer uploads
of
> A…
You are correct; I really meant:
Package: A-doc
Depends: A (=${binary:Version})
> And the Depends is at least questionable even without a version number
> (many *-doc packages don't depend on anything. And if they do the
> Depends is completely unrelated or extreme relaxed, only a small subset
> does it like you suggest it).
The Depends is mandatory in the one specific case that I described, i.e.
the -doc packages contains a symlink to a directory provided by another
package. Of course this is a minority of -doc packages. But my point
was to disprove your theory that a -doc packages needs to Conflict and
Replaces with a non-doc packages. It doesn't. Now let's drop that
part of the discussion.
[...]
>> Please read the Debian Policy for Ada, to which I provided a link (at
>> least section 3.2 "Ada Library Information files". I mean it. If you
>> don't then you cannot possibly understand the problem.
>
> I don't know anything about Ada and i don't have read the policy for
> it as i will not understand it because of that
Yes, you will. If you are smart enough to understand dpkg, then you
are smart enough to understand this document. No knowledge of Ada is
necessary. Knowledge of dpkg is. If you refuse to read the document,
then take my word for it: the package name changes are necessary and
justified.
> - but even if i would read
> it it doesn't change the dependencies written down - at least as long
> you haven't told all package managers like dpkg, apt and aptitude to
> read and understand your policy as well.
I do not ask that apt understand "my" policy. I ask that when a package
A Replaces a package B, apt at least offer the option of installing A
to replace B (i.e. remove B and install A). Currently, it doesn't.
> Thats why i response here, i
> just want to help you understand what a package manager will do with
> your dependencies and that is independent from the content of the
package.
>
> In the end you will need to write dependencies even a crappy piece of
> code can understand and at least for me it would be an indicator if
> even humanoid dependency solvers can't understand them…
>
> (Also, while a policy is free to declare that white is the new black
> it is a good idea to follow established rules and just say black.)
If you refuse to read the document, how can you judge what it says?
I think I have narrowed down the crux of the problem to this simple
question that a dpkg expert like yourself ought to be able to explain
to me:
What is the difference between Conflicts: and Replaces:?
I thought, perhaps naively, that Conflicts was to indicate a conflict
(i.e. packages cannot be installed together) and that Replaces meant
that a package replaced another (i.e. that the upgrade path was to
remove the old package and to install the new one).
If that is not the case, then either these words are misleading, i don't
understand them or both.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/bf5e9602880444a6f3511ef863627...@localhost
Re: same UIDs across multiple systems
On Mon, 31 May 2010 07:58:45 +0200, Yves-Alexis Perez wrote: >On dim., 2010-05-30 at 20:46 +0200, C. Gatzemeier wrote: >> Not a 100% sync, since any conflicts will need to be resolved, but quite >> good for systems with sparse users. Also for reinstalling/replacing >> systems, because it makes the IDs independent from the order in which >> they were created. > >I'm sure you could do a wrapper around adduser to specify the UID has a >hash of the username (or something, so you would have the same uid on >all your boxes), though it might be hard to avoid collisions in the >short allowed range. That's what I've been doing even during the time when I was lead maintainer of adduser. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oj5fw-0002k4...@swivel.zugschlus.de
Re: same UIDs across multiple systems
On Sun, 30 May 2010 19:57:13 +0200, "C. Gatzemeier" wrote: >I found useradd (not adduser) is part of passwd (not base-passwd), >would that be that central tool to take care of debian requirements? useradd is a portable tool. We should not make any semantic changes to that. Adduser is the debian tool which has all the intelligence that makes using Debian so joyful. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oj5gd-0002ke...@swivel.zugschlus.de
Re: Anounce of a secure repo for debian
On Sun, 30 May 2010 19:12:49 +0100, Klaus Ethgen wrote: >You can find this repository at ftp://ftp.ethgen.de/pub/debian-security >(deb ftp://ftp.ethgen.de/pub/debian-security sid unofficial-secured). I would like to ask you to refrain from using the string "debian-security" in your pathnames. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oj5hp-0002lw...@swivel.zugschlus.de
Re: completeness of the upg tests
Am Mon, 31 May 2010 12:17:54 +0200 schrieb Harald Braumann: > > I believe this completes the checks (see below) > > I don't, and that is what I meant by wishful thinking. Nowhere is it > guaranteed that it works this way. Could you please be a little more specific and try to provide a counter example to the reasoning I included in that other message? So we can see what you mean. > pam-umask's usergroups options does the right thing in many cases. But > only the admin can know if the user database conforms to the necessary > critera. So do we know that pam_umask usergroups is perfectly safe with the debian default user database? Isn't what we are discussing here only whether (if an admin changes the debian default to another user database) a relaxation may occur unjustified or not? Umask relaxation should be 100% safe with the debian default user database and settings. So the conditional relaxation can stay enabled by default. (As it was from the beginning. The functionality is only now available again with pam_umask.) We all agree a fixed 002 umask is not good, and that change should just be reverted as soon as possible. But in cases where an admin changes the database to a non-default one, it is perfectly fine for him to also have to turn umask relaxation off to make things work, if the user database does not conform to the common criteria. No matter if that means setting a fixed "abc" or "aac" umask in the resulting system. IMHO umask relaxation can be enabled by default in debian, even if there is an example where the umask would get relaxed unjustified with some non-default non-debian or even rogue user data base. It's just that all the legitimate examples I could come up with, won't get an unjustified relaxed umask anyway with the completed tests. Cheers, Christian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531154435.43367925c.gatzeme...@tu-bs.de@tu-bs.de
Re: Anounce of a secure repo for debian
On Mon, 31 May 2010 10:15:26 +0100, Klaus Ethgen wrote: >The point is that I cannot live with the insecure debian packages at >all. Are you trying to actively harm Debian? If so, please choose other words. You are not a native speaker and obviously don't have a clue of what you're saying. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oj5io-0002td...@swivel.zugschlus.de
Re: Anounce of a secure repo for debian
On Mon, 31 May 2010 12:49:28 +0100, Klaus Ethgen wrote: >Well, this method was grown since ages when reprepro was not available >and I hadn't the time to migrate a working method to a /nice/ working >method. You should have taken that time before going public. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oj5k3-0002uv...@swivel.zugschlus.de
Re: lilo removal in squeeze (or, "please test grub2")
On Tue, May 25, 2010 at 11:08:21AM +0100, Chris Carr wrote: > On 25/05/2010 10:00, Harald Braumann wrote: >> On Sat, May 22, 2010 at 10:39:52PM -0500, William Pitcock wrote: >>> (4) Users need to test grub2 now. >> >> I've been using grub2 for quite some time now on several different >> systems with mixed success. > [snip] >> Because of this, coupled with the many open bugs and the lack of >> documentation, I'm not sure if grub2 is ready to be released to the >> unsuspecting public. > > Just to add my 2p, I have had significant, foreseeable, nonunique > problems with grub2 on several machines (#495433, #508405, #518835 are > merely the ones I reported). I would agree with Harald's assessment that > grub2 is not ready. > > It appears from this thread that the maintainer status of grub2 is > little better than that of lilo. It is therefore difficult to understand > an argument in favour of removing lilo on the basis of a lack of > maintainer(s), as that would also apply to grub2. If it wasn't obvious from the grub-pc bug list already, I have to echo this sentiment, sadly. So far, grub2 package has been pretty much all trouble on both non-trivial configurations I've tried - #548648, #557425. I've also tried converting a system where I have LILO booting / off an LVM volume of a very large device, but that simply wasn't supported at all, upstream. (Some googling just now leads me to believe that this might possibly be fixed nowadays, but that still doesn't make it release-quality software.) So all this "lilo needs to die now, everyone quickly get grub2" talk does look a fair bit premature. Cynics might say amateurish or worse, YMMV. grub2 won't magically get better if we just throw more users at it. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531135638.ga8...@orion.carnet.hr
hashing username => UID
Am Mon, 31 May 2010 15:28:20 +0200 schrieb Marc Haber: > I really like the idea of having all "Debian-exim" accounts with the > same UID on all systems as this incredibly eases moving things As Yves suggested, maybe start testing a username => [1000..2] hash algorithm and conflict resolution scheme in a wrapper script, possibly merging the algorithm into useradd or adduser later. IMHO that would be a nice feature. Cheers, Christian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531160026.2d0ee9e6c.gatzeme...@tu-bs.de@tu-bs.de
Re: Re: Bug#529974: RFP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol
So, you say, "concern myself with patent issues", and Reinhard says, "ignore the patent issues". No! If feel the need to quote us, please do it at least correctly! Reinhard did not say to "ignore the patent issue". He asked you to stop throwing oil on the fire, as the whole media patent story has already been chewed through several times on different lists without leading to any satisfying results yet (see #522373). Using the next best media library ITP to pick this topic up again won't help either. And I did not say you should "concern yourself with patent issues". I did say you should concern yourself with the current multimedia situation in Debian. I takes some 5 minutes of research to find out why specific packages are present in both Debian and d-m.o. And it takes some more 5 minutes to find out that we (i.e. the pkg-multimedia team in Debian) are very unpleased with this situation. - Fabian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c03bf57.1070...@greffrath.com
Re: mini-dinstall possibly leading to lots of 'Failed to fetch http://xyx/abd_1.2-3.deb Size mismatch'
Dirk Eddelbuettel writes: > On 25 May 2010 at 06:59, Goswin von Brederlow wrote: > | Dirk Eddelbuettel writes: > | > Every now and then mini-dinstall throws us a curve ball. Right now I am > | > seeing the errors below on my testing box (which is otherwise current). > | > > | > What can we do to fix the index file? I have removed Packages*, Release*, > [...] > | > | Maybe just avoid the problem by using reprepro. > > So to continue: I got two votes for reprepro and am looking into it. As with > so many things, not that hard once one sits down and fiddles with it. > > One think I could not answer was: can it do what mini-dinstalled called > > archive_style = flat > > so that we could cook-up an in-place substitution? The answer seems to be > "No" and pools have advantages, esp as we are at 2300+ packages and growing. > So maybe this is the time to have users switch their sources.list entries. > > -- > Regards, Dirk I'm afraid you can't. Given the number of packages a flat archive isn't a good idea anyway so it is a good idea to change. You can import your old repository into reprepro by using a file:///path/ url and reprepro will hardlink the packages if possible (same filesystem). That way it doesn't use up noticable space. But I'm afraid you will have to switch to the non-flat sources.list entry format. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hmkduet@frosties.localdomain
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/31 Ludovic Brenta :
> David Kalnischkies wrote:
>> 2010/5/30 Ludovic Brenta :
>>> The consequence is that, despite the fact that these packages are
> broken
>>> (without the need for a Breaks: in their successor packages, BTW),
>>> aptitude prefers to leave them installed rather than remove them; this
>>> in turn blocks upgrades.
>>
>> If aptitude hasn't changed its complete logic recently it will behave as
>> apt and will never allow a user to move from a consistent into an
>> inconsistent state, so either your words are misleading, i don't
>> understand you or both.
>
> I explained in my original post; please re-read it and then you will
> understand. Hint: removal of gnat-4.3.
The only thing i can see from this "hint" is that dependencies are
missing. Fine, i guess i have talked about nothing else so far.
Whatever causes the removal of gnat-4.3 can e.g. also "Breaks"
all the packages who missed proper dependencies before.
>>> Package: A-doc
>>> Depends: A (=2)
>>
>> I hope not as it would be broken for all binary non-maintainer uploads
> of
>> A…
>
> You are correct; I really meant:
>
> Package: A-doc
> Depends: A (=${binary:Version})
If A gets a binNMU 2+b1 this depends will be broken, as A-doc
will not be rebuilt in a binNMU - that was all i meant.
(Assuming that A-doc is a arch:all package and A arch:any)
> package. Of course this is a minority of -doc packages. But my point
> was to disprove your theory that a -doc packages needs to Conflict and
> Replaces with a non-doc packages. It doesn't. Now let's drop that
> part of the discussion.
I talked about "Replaces", not about "Conflict". The Replaces is enough
to suggest an upgrade of the replaced package if possible, but okay,
lets drop it as it is relatively unrelated.
>> Thats why i response here, i
>> just want to help you understand what a package manager will do with
>> your dependencies and that is independent from the content of the
> package.
>>
>> In the end you will need to write dependencies even a crappy piece of
>> code can understand and at least for me it would be an indicator if
>> even humanoid dependency solvers can't understand them…
>>
>> (Also, while a policy is free to declare that white is the new black
>> it is a good idea to follow established rules and just say black.)
>
> If you refuse to read the document, how can you judge what it says?
If it requires changes to all package managers to handle upgrades
in a nice way for this subcategory of packages as it was suggested here
i guess i can say that. I btw didn't say that i mean your/ada policy -
i said "a policy", so if ada policy doesn't change the sense of
dependencies (white to black) i can apply common rules (black)
and everything is fine. It just seems that i can't.
> I think I have narrowed down the crux of the problem to this simple
> question that a dpkg expert like yourself ought to be able to explain
> to me:
dpkg is not my cup of tee, APT is. Anyway:
> What is the difference between Conflicts: and Replaces:?
All dependencies relations are defined in the policy [0],
for Replaces see e.g. [1].
In short: A Replaces only indicates that a file in package B
will be overridden - nothing more (and nothing less).
Just because a package overtakes a >file< doesn't automatically
mean i should install it. (see apt vs manpages-pl).
It absolutely doesn't have the sense of indicating package B
replaces package A completely. This is identical to a package
rename and can be handled as such.
Best regards,
David Kalnischkies
[0] http://www.debian.org/doc/debian-policy/ch-relationships.html
[1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktikuolaxcm2kkxhjuhduqjjjoczfjbnystycb...@mail.gmail.com
Re: lilo removal in squeeze (or, "please test grub2")
On Mon, 31 May 2010 15:56:38 +0200, Josip Rodin wrote: >So all this "lilo needs to die now, everyone quickly get grub2" talk does >look a fair bit premature. Cynics might say amateurish or worse, YMMV. >grub2 won't magically get better if we just throw more users at it. I fully agree. The grub situation is as with KDE: Old version abandoned, new version not finished. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oj6rx-0006hs...@swivel.zugschlus.de
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
David Kalnischkies wrote: > The only thing i can see from this "hint" is that dependencies are > missing. Fine, i guess i have talked about nothing else so far. > Whatever causes the removal of gnat-4.3 can e.g. also "Breaks" > all the packages who missed proper dependencies before. (side note: I've been a Debian developer since before Breaks: even existed, so I was unaware of its presence until this thread. This may be what I was looking for all along.) OK. After reading Policy about Breaks, I'm still not entirely sure how to best apply it. Maybe you can enlighten me. I am thinking of two options; maybe there is a third one that eludes me ATM. Option 1: upload a new package "gnat" that Breaks: all -dev packages that were present in Lenny but are no longer present in Squeeze. This however does not really help apt, or the user, discover the new replacement packages. Option 2: change each new -dev package so that it Breaks: its predecessor. For example, let libgtkada2.14.2-dev Break: libgtkada2.8.1-dev. Question 1: which option do you think is best? (my guess is option 2). Question 2: if I add Breaks: to a -dev package, which ones of Conflicts: and Replaces: should I also specify? (currently, both are specified; the new packages replace almost all files of the old packages). The goal is, of course, to make unattended upgrades that delete the old -dev packages and install the new ones possible. Thanks for any help. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e10a64e9ed6898b22e8643d48aa49...@localhost
Re: Anounce of a secure repo for debian
On Mon May 31 2010 06:45:14 Marc Haber wrote: > On Mon, 31 May 2010 10:15:26 +0100, Klaus Ethgen > wrote: > >The point is that I cannot live with the insecure debian packages at > >all. > > Are you trying to actively harm Debian? If so, please choose other > words. You are not a native speaker and obviously don't have a clue of > what you're saying. I am a native English speaker. Klaus is perfectly correct. Marc is not. --Mike Bird -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005310920.43547.mgb-deb...@yosemite.net
Re: Anounce of a secure repo for debian
* Klaus Ethgen: > cause of the recent umask disaster I decided to start a repository for > packages which are insecure in debian distribution. > > You can find this repository at ftp://ftp.ethgen.de/pub/debian-security > (deb ftp://ftp.ethgen.de/pub/debian-security sid unofficial-secured). To avoid confusion, please call your repository "debian-security-ng". Cheers, -Hilko -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87typof55u@msgid.hilluzination.de
Automatically installing hardware specific packages
For a long time, I have wished the Debian installer would automatically install the right packages on the servers I have. If it detect a RAID controller using the cpqarray kernel module, the cpqarrayd package should be installed. If a RAID controller using the mptscsih kernel module is detected, the mpt-status package should be installed. If a i810 compatible video card is detected, the i810switch package should be installed. I wrote a draft implementation a few years ago using the discover v2 package, but never found time to integrate it into the installer. But, since a few days ago, I found time to do this integration. The daily d-i images install discover automatically and run the required commands as root to install hardware specific packages automatically during installation. The command is aptitude install discover; discover-pkginstall This will look up USB and PCI IDs found on the machine in the database provided by the discover-data package, and install any hardware specific packages detected (after presenting a debconf question which is hidden at the normal debconf priority). To get this working out of the box, the discover-data package need to be updated with mappings from PCI and USB IDs to Debian package names. I've added a few, but I am sure there are mappings missing. If you know of some package that should be installed automatically when some PCI or USB devices are detected, please report them to BTS and the discover-data package, to get the mappings into Debian before Squeeze is released. :) Are there better ways to do this? Anyone willing to work on it? Fedora 13 provides PackageKit to install hardware specific packages after installation. Perhaps we should extend the discover system to listen to DBus events and install hardware packages also after installation? Or port PackageKit to Debian and use it instead? Anyway, a draft system is in d-i at the moment, and I welcome help with updating the hardware mappings to get more packages installed automatically by d-i. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fly6f0ypze@login2.uio.no
Re: Anounce of a secure repo for debian
On Mon, May 31, 2010 at 05:43:25PM +0200, Hilko Bengen wrote: > > You can find this repository at ftp://ftp.ethgen.de/pub/debian-security > > (deb ftp://ftp.ethgen.de/pub/debian-security sid unofficial-secured). > > To avoid confusion, please call your repository "debian-security-ng". or perhaps "debian-security-imho" would be even better. sean signature.asc Description: Digital signature
Re: Archive area for clamz (Amazon MP3 downloader)
On Mon, May 31, 2010 at 07:03:16AM +0200, sean finney wrote: > On Sun, May 30, 2010 at 09:40:48PM +, brian m. carlson wrote: > > The difference is that those tools provide a reasonable level of > > functionality with free data. Weather information is in the public > > domain because there's no originality to it. Most programs that display > > lyrics or album covers are music players, and there is free music > > (available in our archive, no less) that they can usefully play. > > so should amavis and spamassassin go to contrib because there aren't > any documented DFSG-free virus and spam going through our mailservers? I'll bite. amavis and spamassassin handle emails, and there are in fact emails that are free. CVS commit emails for free software projects are a great example of this. > better yet, tell me which item in the DFSG says that a program can't be > Free unless all the purpose or data handled by the software is also Free. > hint: there isn't one. > > in fact, DFSG #6 (No discrimination against fields of endeavor) could even > be applied to the exact opposite argument. > > ftp-master has the final say in what goes into the archive, but this > really sounds like an over-zealous misinterpretation of the DFSG. > i'd hope that this were a miscommunication and/or not the position > of the entire team, because otherwise it would take a GR to overturn > their position. I'm not arguing the DFSG here. Packages in both main and contrib must comply with the DFSG, so any non-compliance with the DFSG makes the entire argument moot since the packages in question then must go to non-free. What I *am* arguing is Felix's response to Ben. What I said was basically clarifying what Ben said, with respect to Felix's response. My point was that Amarok in fact does not, under any interpretation, belong in contrib. It has useful extensions that involve non-free data, but it is functional without those. Therefore, Amarok belongs in main even under the strictest interpretations of the main/contrib divide. In retrospect, I probably could have used a better word than "difference". What I meant is that the package in question (clamz) is not in the same category as amarok. There can be legitimate debate on the issue for one, and no reasonable disagreement on the other. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Anounce of a secure repo for debian
> On Mon, 31 May 2010 12:49:28 +0100, Klaus Ethgen wrote: > >Well, this method was grown since ages when reprepro was not available > >and I hadn't the time to migrate a working method to a /nice/ working > >method. [Marc Haber] > You should have taken that time before going public. Seriously? I think Klaus's project is as silly as everyone else thinks, but dude, the best criticism you can think of is that he didn't use standard tools to generate the apt indexes? When you come to that point, you should realize that you're just arguing for the sake of arguing. I mean, how could his choice not to deploy reprepro possibly affect the users of his repository? Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531171753.gf18...@p12n.org
Re: Archive area for clamz (Amazon MP3 downloader)
On Mon, May 31, 2010 at 05:13:51PM +, brian m. carlson wrote: > On Mon, May 31, 2010 at 07:03:16AM +0200, sean finney wrote: > > On Sun, May 30, 2010 at 09:40:48PM +, brian m. carlson wrote: > > > The difference is that those tools provide a reasonable level of > > > functionality with free data. Weather information is in the public > > > domain because there's no originality to it. Most programs that display > > > lyrics or album covers are music players, and there is free music > > > (available in our archive, no less) that they can usefully play. > > > > so should amavis and spamassassin go to contrib because there aren't > > any documented DFSG-free virus and spam going through our mailservers? > > I'll bite. amavis and spamassassin handle emails, and there are in fact > emails that are free. CVS commit emails for free software projects are > a great example of this. What about http://creativecommons.org/tag/amazon ? Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531175533.gd21...@nighthawk.chemicalconnection.dyndns.org
Re: Archive area for clamz (Amazon MP3 downloader)
On 31.05.2010 19:55, Michael Banck wrote: > On Mon, May 31, 2010 at 05:13:51PM +, brian m. carlson wrote: > >> I'll bite. amavis and spamassassin handle emails, and there are in fact >> emails that are free. CVS commit emails for free software projects are >> a great example of this. >> > What about http://creativecommons.org/tag/amazon ? > Unfortunately that's a CC license that doesn't allow commercial use, so it's not dfsg-free. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c03fa34.2040...@fobos.de
Re: Anounce of a secure repo for debian
]] sean finney | On Mon, May 31, 2010 at 05:43:25PM +0200, Hilko Bengen wrote: | > > You can find this repository at ftp://ftp.ethgen.de/pub/debian-security | > > (deb ftp://ftp.ethgen.de/pub/debian-security sid unofficial-secured). | > | > To avoid confusion, please call your repository "debian-security-ng". | | or perhaps "debian-security-imho" would be even better. Or something not involving the Debian name at all. Calling it debian-* makes it look like an official Debian resource, something it is clearly not. (Also, why the author doesn't just go the route that people have taken with harden-* in the past is something I don't understand, but I'm not going to tell people how to best go about their business when it doesn't affect me.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5ksx7hw@qurzaw.linpro.no
Re: Archive area for clamz (Amazon MP3 downloader)
Michael Banck writes: > On Mon, May 31, 2010 at 05:13:51PM +, brian m. carlson wrote: >> On Mon, May 31, 2010 at 07:03:16AM +0200, sean finney wrote: >> > On Sun, May 30, 2010 at 09:40:48PM +, brian m. carlson wrote: >> > > The difference is that those tools provide a reasonable level of >> > > functionality with free data. Weather information is in the public >> > > domain because there's no originality to it. Most programs that display >> > > lyrics or album covers are music players, and there is free music >> > > (available in our archive, no less) that they can usefully play. >> > >> > so should amavis and spamassassin go to contrib because there aren't >> > any documented DFSG-free virus and spam going through our mailservers? >> >> I'll bite. amavis and spamassassin handle emails, and there are in fact >> emails that are free. CVS commit emails for free software projects are >> a great example of this. > > What about http://creativecommons.org/tag/amazon ? Looking at the NIN album, it is CC-BY-NC-SA, which is not DFSG-free. /Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87typohr8w@mocca.josefsson.org
Re: correctly using other packages in postrm
Hi Evgeni, On Thu, May 27, 2010 at 11:32:06AM +0200, Evgeni Golov wrote: > This means that we *try* to execute the postrm-hook of dbconfig-common > in our postrm, but only if it's there. Policy 7.2 says "The Depends > field should also be used if the postinst, prerm or postrm scripts > require the package to be present in order to run. Note, however, that > the postrm cannot rely on any non-essential packages to be present > during the purge phase.", which allows dbconfig-common to be gone > *before* our postrm is executed. If it is gone, the hook isn't called, > /etc/dbconfig-common/bley.conf isn't removed and piuparts warns about > it. > That's perfectly correct, we leave a stale config file here, so how to > fix it? > Trivial solution would be something like: > if [ -f /usr/share/dbconfig-common/dpkg/postrm ]; then > . /usr/share/dbconfig-common/dpkg/postrm > dbc_go bley $@ > else > rm -f /etc/dbconfig-common/bley.conf > if which ucf >/dev/null 2>&1; then > ucf --purge /etc/dbconfig-common/bley.conf > ucfr --purge bley /etc/dbconfig-common/bley.conf > fi > fi Does dbconfig-common know about all of these config files? I think it's the responsibility of dbconfig-common to track them, and remove them on purge. That way if your package is purged while dbconfig-common is installed, the config file is removed, and if dbconfig-common is removed before purge, a dpkg --purge dbconfig-common can still clean it up. This is similar to how ucf's cache is already handled, btw. > Alternatively, we could modify piuparts not to remove dbconfig-common > before the tested package isn't gone (or actually: not to try to remove > any deps before the tested package isn't gone) and thus ignore this > problem, defining it as "not usual usecase" (who tries to remove deps > before removing the package itself?). Piuparts should include purging dbconfig-common (i.e.: all dependencies that it installed) as part of this test. If it does, and the config file is left behind, this is a dbconfig-common bug, IMHO. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531192448.ga30...@dario.dodds.net
How to follow mailing lists the easy way
I find it easier to use a newsreader instead of certain e-mail clients for managing mailing lists (I use Pan, as it has worked very well for me). # Here is a QUICK GUIDE: 1. Install Pan 2. Add a news server "news.gmane.org 3. Add your e-mail address 4. Subscribe to a news group e.g. "gmane.linux.ubuntu.user" 5. When you post/follow up first time you will receive an e-mail asking you to reply to the mail (to verify that you are you), and when you have done that you are ON. # Here is a LONGER GUIDE: Install Pan using synaptic (in ubuntu). Add as news server: Pan - Edit - Edit News Servers - Add - "news.gmane.org" Add your e-mail address: Pan - Edit - Edit Posting Profiles - "your e-mail address" Then Search for e.g. "gmane.linux.ubuntu.user" as group name (use search box top left in Pan) and then right click on the found list and choose "subscribe". Please note, that there is thousands of other mailing list groups out there, and also a lot of other news servers. gmane.linux.ubuntu.user (is the group for ubuntu-users mailing list) Practical setup items: Pan - Edit - Edit Preferences - Behaviour - Groups - mark "Get new headers in subscribed groups on start up". Pan - Groups - Get headers - select Get all headers - Execute This item makes it very important, that ALL subject lines in all posts to be very DESCRIPTIVE. Then it will be possible to search very distinct for answers. That is if you have all headers of a newsgroup downloaded in Pan, you can more easily find your answers. Search in subject lines is done in top right search box in Pan. This item has to be done each time you want all groups (maybe a bug). Pan - View - Header Pane - Choose "Thread Headers" (to sort articles by threads (toggle on/of)). When you post/follow up first time you will receive an e-mail asking you to reply to the mail (to verify that you are you), and when you have done that you are up to use the mailing list group using Pan. This should be done for each new newsgroup you subscribe to. Using Pan for your mailing lists also give you a much better overview of your mailing lists I think. Sorry that I repeat the usefullness of Pan, but it took me several years to find out how much more easy it is for me to use Pan for your mailing lists - a very important "weapon" for getting help in the linux world I find. ### If anybody has problems with a certain thread/author and use Pan newsreader they can do: Select the article and then choose: Pan - Ignore - Thread or Pan - Ignore - Author Then they get rid of the culprit/s *humor* See also this link: http://kb.iu.edu/data/afhc.html ### Here is a few mailing list groups: gmane.linux.ubuntu.user (ubuntu-users) gmane.linux.ubuntu.user.kubuntu (kubuntu-users) gmane.linux.debian.user gmane.linux.debian.devel.general ### This is a standard template message! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hu13bt$tj...@dough.gmane.org
Re: Archive area for clamz (Amazon MP3 downloader)
On 30.05.2010 23:40, brian m. carlson wrote: >> A very similar software is already in Debian main: >> Amarok contains two plugins that are able to download/stream >> music from Magnatune and MP3tunes; both are music stores. >> > Amarok also plays music quite well without those. I never use Magnatune > or MP3tunes. Also, there are free Ogg Vorbis files in our archive that > can be played with Amarok. It is irrelevant that all *I* use it for is > playing music that I've bought on CD; there is a significant amount of > free material that can be used instead. > If Amarok decided to use the source code of clamz to implement an Amazon plugin, Amarok could still be in main? That's IMHO somewhat inconsistent. Anyway the Debian Policy should be much clearer on the distinction between main and contrib. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c0425d0.1000...@fobos.de
Processed: Re: Bug#583954: fstab doesn't mount external USB-drive, but mount -a does
Processing commands for cont...@bugs.debian.org: > reassign 583954 general Bug #583954 [fstab ??] fstab doesn't mount external USB-drive, but mount -a does Warning: Unknown package 'fstab' Bug reassigned from package 'fstab ??' to 'general'. > -- Stopping processing here. Please contact me if you need assistance. -- 583954: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583954 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.127534311614278.transcr...@bugs.debian.org
users not belonging to the "users" group
There is another issue related to getting user collaboration working out of the box: Users do not belong to the "users" group, thus creating say /home/group/users as a (sgid) group directory to provide a way for the users of a system to collaborate on something does not work. Either adduser would have to add all new (and existing) users explicitly to the users group and fill /etc/group with all user names, or pam_group can dynamically add users to the users group when they login. Following the pam_group line for /etc/security/group.conf: *; *; *; Al-2400; users Any preferences? Cheers, Christian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100601003237.3fdd1ea0c.gatzeme...@tu-bs.de@tu-bs.de
Bug#583954: fstab doesn't mount external USB-drive, but mount -a does
This is probably because of the fundametal problem with the current boot system in Debian, and the fact that the Linux kernel have become event based and it is not possible to know in advance when a device will be available during boot. It is basicly a race condition during boot because the kernel return from kernel module loadin before the bus handled by a kernel module is scanned. :) To solve it, I believe we need to move to a event based boot system. See http://lists.debian.org/debian-devel-announce/2009/09/msg3.html > for more information. I am sure you find similar bug reports against the initscripts package, even if it can't be solved by there without a structural change in the way we handle boots, fsck and mounts. :) Ubuntu uses upstart to get an event based boot system, and this is the reason your external USB disk is mounted correctly there. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531222618.gi25...@login2.uio.no
Re: correctly using other packages in postrm
hi, On Mon, May 31, 2010 at 12:24:48PM -0700, Steve Langasek wrote: > Does dbconfig-common know about all of these config files? > > I think it's the responsibility of dbconfig-common to track them, and remove > them on purge. That way if your package is purged while dbconfig-common is > installed, the config file is removed, and if dbconfig-common is removed > before purge, a dpkg --purge dbconfig-common can still clean it up. i think in hindsight that's the way it *should* have been, but the documentation has suggested the contrary for long enough that i'm hesitant to break things, at least this late into the release cycle. sean signature.asc Description: Digital signature
clamz accepted in main [Re: Archive area for clamz (Amazon MP3 downloader)]
> > In retrospect, I probably could have used a better word than > "difference". What I meant is that the package in question (clamz) is > not in the same category as amarok. There can be legitimate debate on > the issue for one, and no reasonable disagreement on the other. Dear all, for the record, clamz has been accepted this night in the main section of the Debian archive. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531235248.gb15...@kunpuu.plessy.org
Re: lilo removal in squeeze (or, "please test grub2")
On Mon, May 31, 2010 at 10:25 PM, Marc Haber wrote: > I fully agree. The grub situation is as with KDE: Old version > abandoned, new version not finished. Not exactly. I was testing KDE4 since 3.97 and it was quite interesting and amusing. Not many people like to test bootloader on themself, though. /* also grub2 works pretty well for me but nevertheless I've no idea why we need to remove good old stable lilo */ Alexey -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim3xsh7lcbbtvkkxlxmi5hfaw9cwz7l05-qv...@mail.gmail.com
Re: Archive area for clamz (Amazon MP3 downloader)
Philipp Kern wrote: > Console emulators like zsnes are in main, I think because there used to be > at least one free ROM it can be used with (be it useful or not). It would probably be more consistent with clamz having been accepted into main, to not require that emulators have a free rom in order to be in main. As it is, the line between clamz and a romless emulator is quite narrow and not well-defined. Emulators have entered main on the back of free roms that are barely usable and were probably slapped together in a day or so[1], and it's to some extent duplicitous to say "this emulator is free because it lets you play this not very good game, which is also free" -- when everyone using the "free" emulator will really be playing Sonic The Hedgehog. -- see shy jo [1] Meaning no disrespect to their authors; I couldn't do it! signature.asc Description: Digital signature
ITP: monitor-edid -- tool to retrieve monitor EDID information
Package: wnpp Severity: wishlist Owner: Mathieu Trudel-Lapierre * Package name: monitor-edid Version : svn269700 Upstream Author : Anssi Hannula * URL : http://wiki.mandriva.com/en/Tools/monitor-edid * License : GPL3+ Programming Lang: C++, Perl Description : tool to retrieve monitor EDID information This tool is used to retrieve EDID information from a monitor using instrumentation provided by SYSFS, usually through the drm drivers. EDID information is used to attempt to get a clear representation of a display's recommended resolution, physical size, form factor, as well as other useful tidbits of information. Mathieu Trudel mathieu...@gmail.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilajl_kco2mwamcn0dplohyg2kytnxuq9wko...@mail.gmail.com
Re: Archive area for clamz (Amazon MP3 downloader)
Felix Geyer dijo [Sat, May 29, 2010 at 09:14:56PM +0200]:
> clamz [1] has been rejected from Debian NEW [2] some time ago.
> The FTP assistent that processed the package was of the
> opinion that it belongs to contrib instead of main because it's
> only useful to download non-free content.
>
> The purpose of clamz is to download MP3 files after buying them
> from Amazon. You can download MP3s with every browser though
> and Debian even has many MP3 decoders in main.
> I don't see why this is a problem.
>
> There is another package in main that is similar in this
> respect: youtube-dl.
>
> So what is the reason that clamz can't be in main?
I know I am coming to this discussion after ftp-master agreed with
this package being included in main - but still: For many years, we
have had a dozen lastfm-related packages. And yes, some of them are
meant to report ("scribble") what we are listening to our LastFM
profile - But at least, lastfmproxy, shell-fm and lastfm itself work
purely with lastfm-generated music streams. And even if ocassionaly
LastFM streamed a free song (I don't use their service since they
became a for-pay service), it is not controllable/predictable, and the
stream itself is nonfree.
Greetings,
--
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100601030734.ga28...@gwolf.org
Re: correctly using other packages in postrm
On Tue, Jun 01, 2010 at 01:13:28AM +0200, sean finney wrote: > On Mon, May 31, 2010 at 12:24:48PM -0700, Steve Langasek wrote: > > Does dbconfig-common know about all of these config files? > > I think it's the responsibility of dbconfig-common to track them, and remove > > them on purge. That way if your package is purged while dbconfig-common is > > installed, the config file is removed, and if dbconfig-common is removed > > before purge, a dpkg --purge dbconfig-common can still clean it up. > i think in hindsight that's the way it *should* have been, but the > documentation has suggested the contrary for long enough that i'm hesitant > to break things, at least this late into the release cycle. Hmm, what's the risk of changing it? I guess if dependencies are allowed to be purged when a package depending on them is removed-but-not-purged, dbconfig-common could obliterate config files that the depending package expects to still have around. Is that the concern? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100601040250.ga9...@dario.dodds.net
Re: correctly using other packages in postrm
On Mon, May 31, 2010 at 09:02:50PM -0700, Steve Langasek wrote: > Hmm, what's the risk of changing it? I guess if dependencies are allowed to > be purged when a package depending on them is removed-but-not-purged, > dbconfig-common could obliterate config files that the depending package > expects to still have around. Is that the concern? one of them, yeah. if dbc were to guarantee that it left no cruft behind, it would have to purge all the files it registered in proxy for packages when it was purged as well (which also means this would need to be tracked, which it isn't atm), but i don't feel confident enough without looking to know whether that would cause a problem in the depending packages' maintainer scripts. likewise, if dbc started purging these files as part of the postrm hook for the depending package, i'd be concerned that if this code was duplicated in the postrm script that it would result in a failure if it were run a a second time (i.e. the maintainer script already dealt with the file or tried to deal with it after calling the hook). it could be that they're both non-issues (now that i check, ucf seems to be fine with puring a config file that isn't registered, for example), but i'd want to do some kind of audit and loose testing to know for sure before i instabug a large number of packages. sean signature.asc Description: Digital signature
