Re: Call to participate in FrOSCon 2011
Stefano Zacchiroli writes: > JFYI: FrOSCon is looking for Debian-related talks and speakers. If you > plan to be around Bonn, Germany by August 20th, your contributions are > more than welcome and it might be a good chance to present your pet > Debian project to an enthusiast public and spread the Debian verb. > > Thanks for the invitation, David! > > Cheers. What is the deadline? MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aaerg9is.fsf@frosties.localnet
Re: non-free Packages as build-dependency of contrib / non-free ones & autobuilding
Andreas Barth writes:
> Hi,
>
> currently our policy says that main packages must only (build-)depend
> on main packages, but contrib and non-free packages could use packages
> from contrib and non-free.
>
> In practice build-dependencies from non-free are not used by the
> buildds for two reasons:
>
> 1. (mostly historical) we need to make sure that the packages are not
> installed anymore while building packages from main - this can be
> ensured via the lvm-snapshot type chroots however
>
> 2. we don't know (on an automated basis) which packages in non-free
> can be used as build-dependency without violating copyright. For the
> source packages we use the marker "Autobuild: yes", but that won't do
> for binary packages where we only want to have some packages
> considered by apt/aptitude.
>
>
> Some obvious solutions come to my mind:
>
> 1. Split non-free into "non-free-but-useable", i.e. packages that can
> be autobuilt, and can be used as a build-dependency (and where main +
> contrib + non-free is self-contained, like main today already is), and
> "silly-non-free" (the remaining packages).
>
> 2. Make a sub-disttree from non-free of the acceptable packages, and
> put it somewhere only on ftp-master or a few hosts only (that's enough
> for installing build-dependencies on buildds already)
>
>
>
> Other ideas? Opinions?
Add "Autobuild: yes" to binary packages so the flag ends up in Packages
and then filter non-free for packages with the flag set. This can be
done in /etc/apt/apt.conf.d/ with
Apt::Update::Post-Invoke { "filter.sh" }
where filter.sh goes through /var/lib/apt/lists/*non-free*Packages and
removes anything without "Autobuild: yes".
Would it be save to carry the "Autobuild: yes" flag from the source
stanza into binary packages? That would involve a small change in dpkg
and then the next compile of each package would fix the debs for
autobuilding.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3xt5izc@frosties.localdomain
Re: Debian on Atom 330 Question
Rein Tendonsie writes: > Beste, > > > Momenteel heb ik een dedicated server genomen ergens en men > zegt er dat ze geen Debian willen instaleren omdat deze niet zou werken > omwillen van de processor. > > Klopt het dat Debian niet werkt onder: > Intel Atom Dual core 330 > > http://processorfinder.intel.com/details.aspx?sSpec=SLG9Y > > Graag bevestiging of het wel of niet werkt, > gezien het bedrijf hiervan bewijs wil. > > Dank > Rein Corselis I don't realy understand much more than the subject but: % cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 28 model name : Intel(R) Atom(TM) CPU 330 @ 1.60GHz stepping: 2 cpu MHz : 1600.234 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm lahf_lm bogomips: 3200.46 clflush size: 64 cache_alignment : 64 address sizes : 32 bits physical, 48 bits virtual power management: ^^^ 4 times for 2 cores and 2 hyper threads each. MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian redesign
Andreas Tille writes: > I do not think that we could risk as a small non-commercial > project (compared to the given examples) that our logo we advertised > for a "not so long" timespan becomes outdated and our users might > become unhappy about "outdated" T-Shirts etc. Gives one a good reason to buy new T-Shirts. I seriously doubt users overall will be unhappy about "outdated" T-Shirts. They will welcome the variety. Gives them something new to wear. > Makes no sense at all and I do not see the slightest advantage > for the project. One argument raised for the simplified swirl was that it would scale better. More recognisable as our logo in smaller sizes and easier to print. Not sure I agree with that but I have never printed swirl buttons or the like either. MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What is preventing Debian from being fully free at this moment?
Martin Wuertele writes: > * Fred [2009-07-29 06:12]: > >> I'd love to see Debian comply to real GNU/FSF freedom. When I visit the >> website it boasts about how it is free. >> >> However, it is far from free while it is offering proprietary software as >> well as having binary blobs in the kernel. > > The kernel part is known an constantly worked on, even upsteream.. If > you should find any proprietary software in main please feel free to > file an RC bug, I doubt tough that you will have success. To clarify: success of finding. And other than the known kernel exceptions that are being worked on. > Please mind that Debian itself only consists of main while contrib and > non-free are provided for user convenience (see sec 5 of the social > contract http://www.debian.org/social_contract) > > Yours > Martin MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
Sandro Tosi writes: > On Wed, Jul 29, 2009 at 08:59, Goswin von Brederlow wrote: >> No, we freeze on time, we release when ready. Big difference. > > and this means a shorter freeze period (as stated in the original > announce) because? >From what I understand because the long freeze period we had last time is making problems all around for users (of unstable/testing) and developers as well as the release itself. MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
Frans Pop writes: > On Wednesday 29 July 2009, Meike Reichle wrote: >> The Debian project has decided to adopt a new policy of time-based >> development freezes for future releases, on a two-year cycle. > > Disappointing to see such an announcement without any prior discussion on > d-project, d-devel or d-vote. Some explanation of how and by who this > decision was reached would be appreciated. It was discussed at debconf. Lots of explanation given there seems to have been left out of the announcement. > So from now on we release "when it's time" instead of "when it's ready"? > RC bugs are no longer relevant? > > Cheers, > FJP No, we freeze on time, we release when ready. Big difference. MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Bernd Zeimetz writes: > Goswin von Brederlow wrote: >> Bernd Zeimetz writes: >> >>> Goswin von Brederlow wrote: >>>>> and it has numerous RC bugs. >>>> Lets see: >>>> http://packages.qa.debian.org/i/ia32-libs-tools.html >>>> >>>> RC bugs: 1 >>> There were 6 bugs when I looked at the page before writing my mail, guess >>> you've >>> merged/downgraded/... the others.I should have added another one - breaking >>> apt >> >> Most importantly fixed in an upload or assigned to the package that >> did the actual breaking. I got a number of non-bugs caused by >> libc6-i386 changing lib32 from link to directory too: Like >> lib32nss-mdns being uninstallable because libc6-i386 conflicts with >> it. >> >>> completely while removing the ia32 packages is not nice. > > Remember, I asked you on irc? > It leaves empty files somewhere in /var/lib/apt which breaks apt pretty > much... Fixed in version 19: * Remove empty Packages files on remove so update fetches fresh ones. So another "fixed in an upload" one. :)) MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Bernd Zeimetz writes: > Goswin von Brederlow wrote: >>> and it has numerous RC bugs. >> >> Lets see: >> http://packages.qa.debian.org/i/ia32-libs-tools.html >> >> RC bugs: 1 > > There were 6 bugs when I looked at the page before writing my mail, guess > you've > merged/downgraded/... the others.I should have added another one - breaking > apt Most importantly fixed in an upload or assigned to the package that did the actual breaking. I got a number of non-bugs caused by libc6-i386 changing lib32 from link to directory too: Like lib32nss-mdns being uninstallable because libc6-i386 conflicts with it. > completely while removing the ia32 packages is not nice. Pray tell, what breaks? MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Steve Langasek writes: > On Sun, Jul 05, 2009 at 12:20:08PM +0200, Goswin von Brederlow wrote: >> The upgrade path to multiarch is for the multiarch i386 deb to >> Conflicts/Replaces: . Which >> means ia32-libs or ia32-libs-gtk for the old system or ia32- >> for the ia32-apt-get one. > > If this means ia32-apt-get is installing files to the multiarch paths, then > this is a problem. You're making more work for the implementers of > multiarch by requiring them to take into account this ia32-apt-get kludge. There are a lot more things in those packages than *.so files. That is what the Replaces is needed for. The Conflicts on the other hand is needed so only one version of the library is installed on the system. Otherwise you will get the wrong version and things randomly break as Depends/Breaks/Conflicts won't catch right. This already holds for the old ia32-libs and ia32-libs-gtk and has nothing to do with ia32-apt-get or installing to multiarch paths. MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Pierre Habouzit writes: > On Sat, Jul 04, 2009 at 11:30:12PM +0200, Goswin von Brederlow wrote: >> Yannick writes: >> >> > Goswin von Brederlow wrote: >> > >> >> And hey, the "good" reason was "diverting the package management tools >> >> is unacceptable". But, no, we have to do insults instead of arguing. >> > >> > Alas, despite the diversion of the package management tools, I find ia32- >> > apt-get pretty useful. >> > >> > For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 Debian >> > (64bit Firefox 3.5 does not have the new tracemonkey javascript engine). >> > With ia32-apt-get, I could install the 32bit version of my GTK theme >> > engine >> > so that Firefox can look good. >> > >> > Is there a design problem in converting 32bits libraries to ia32-* >> > packages >> > or the sole problem is the diversion of apt-get and co? >> >> There where 3 minor bug reports about an ia32-* package not working >> right. Out of an estimate of 160-200 packages people use. I think that >> is pretty good. All 3 bugs where fix in a subsequent upload and >> currently there are no reported missconversions. On the other hand ~45 >> bugs about missconversion or missing packages in the old ia32-libs >> where closed (and will have to be reopened now). So I don't believe >> there is a design problem there. That part works just fine. >> >> But the diversions had people totaly in outrage. So much so that I >> believe they didn't even look past that at all. > > You absolutely don't get it do you ? Your conversion system is an ugly > hack, something completely horrible, that is meant to break in horrible > ways, has no forward upgrate path to a multiarch work, and so on. The conversion system is an ugly hack. Sure. But it is the same ugly hack 32bit support has always done, for over 5 years. The only change is when the conversion is done, i.e. moved from the buildd to the users system. By moving it there only those things the user needs/wants need converting and all the user needs/wants can be converted. That is the big advantage of ia32-apt-get over ia32-libs. If you find the conversion unacceptable then the only option for you is to request 32bit support on amd64/ia64 is removed till multiarch. The upgrade path to multiarch is for the multiarch i386 deb to Conflicts/Replaces: . Which means ia32-libs or ia32-libs-gtk for the old system or ia32- for the ia32-apt-get one. And again with ia32-apt-get there is a huge advantage. As packages convert to multiarch they can be droped in ia32-apt-get on a case by case basis and replaced by the multiarch one. Meaning users don't have to wait for and update 200 packages in a single step. > If you really mean to provide something like ia32-apt-get, what you > ought to do is to: > - help the user create and maintain a proper 32bits chroot; Way to complex and fragile with the millions of possible configurations of users systems. > - let ia32-apt-get or whatever it's called be a forward to running > apt-get inside that chroot; > - find a way to let the user run commands from that chroot seamlessly. Impossible to make that work for everyone/everything. Any solution will be a special case solution and only support some configurations. > That would be totally acceptable, and probably an improvement over the > current situation. MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Yannick writes: > Goswin von Brederlow wrote: > >> And hey, the "good" reason was "diverting the package management tools >> is unacceptable". But, no, we have to do insults instead of arguing. > > Alas, despite the diversion of the package management tools, I find ia32- > apt-get pretty useful. > > For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 Debian > (64bit Firefox 3.5 does not have the new tracemonkey javascript engine). > With ia32-apt-get, I could install the 32bit version of my GTK theme engine > so that Firefox can look good. > > Is there a design problem in converting 32bits libraries to ia32-* packages > or the sole problem is the diversion of apt-get and co? There where 3 minor bug reports about an ia32-* package not working right. Out of an estimate of 160-200 packages people use. I think that is pretty good. All 3 bugs where fix in a subsequent upload and currently there are no reported missconversions. On the other hand ~45 bugs about missconversion or missing packages in the old ia32-libs where closed (and will have to be reopened now). So I don't believe there is a design problem there. That part works just fine. But the diversions had people totaly in outrage. So much so that I believe they didn't even look past that at all. > If there's no design flaw, wouldn't ia32-archive be the correct path? I mean > a system to install converted packages which is set apart the package > management system (until the actual package installation of course)? I thought so. But people will have to live with no 32bit support or the old ia32-libs monster when Mark uploads it again as the default. > Yannick MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Josselin Mouette writes: > Le vendredi 03 juillet 2009 à 14:59 +0200, Goswin von Brederlow a > écrit : >> > Do you *really* want to have more reasons? >> >> I would settle for one good one. :) > > OK, letâs try one that you can understand. Try picturing a bridge. > ia32-libs-tools is trying to cross the bridge, but there is Ganneff > standing on the bridge wearing full armor, saying âNone shall passâ. > > And ia32-libs-tools is not wearing Excalibur. More acruate there is this angry mob with torches and pitchforks that chaces ia32-libs-tools back after Ganneff did let it pass. And hey, the "good" reason was "diverting the package management tools is unacceptable". But, no, we have to do insults instead of arguing. MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Bernd Zeimetz writes: > Goswin von Brederlow wrote: > > Please do files bugs about issues you consider blockers for >> ia32-libs-tools and squeeze and please include if that applies even if >> there is the old ia32-libs in parallel to it (i.e. when it doesn't get >> pulled in on upgrades). > > The package is a mess, Specifics. Not just ranting please. > the idea is broken by the design Not in my opinion. Works perfectly here. > and it has numerous RC bugs. Lets see: http://packages.qa.debian.org/i/ia32-libs-tools.html RC bugs: 1 #535486 ia32-libs breaks multiarch buildd and adds useless dependency The fix for this is for fglrx to stop building fglrx-glx-ia32 and letting ia32-apt-get provide the 32bit fglrx-grl package from i386 instead. Purely a transitional issue. It doesn't even break the buildd. It just takes really long to install if you don't have a strong enough source for entropy. > Do you *really* want to have more reasons? I would settle for one good one. :) MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Bastian Blank writes: > On Fri, Jul 03, 2009 at 10:28:24AM +0200, Goswin von Brederlow wrote: >> Last I heart s390 planed to drop 31bit support and go fully 64bit. > > This was the plan. However I don't know if it is the best solution. The > fact is: only Debian and SuSE still supports a complete 31bit userland. > RHEL is released 64bit only with some 31bit libs and SuSE have both. > This also means that many of the commercial software is now released as > 64bit binaries. > > On s390 we have the advantage that we have a lot more operations in > 64bit aka zarch mode while using the same opcode format. This includes > things like 32bit immediate loads and, for z9 and newer only, unicode > conversion[1]. So this code can actually be smaller and faster then the > 31bit code. > > So if we are going to get multiarch support, I would vote for a two > stage plan: > - Do a full 31 and 64bit release for X. > - Reduce the 31bit port to minimal for X+1. > I hope that apt e.g. will be able to do such an upgrade. > > Bastian > > [1] https://bblank.thinkmo.de/blog/s390-assembler, > https://bblank.thinkmo.de/blog/smallest-utf32-to-utf8-converter > -- I guess that means introducing a full s390x architecture then and eventually making s390 the partial architecture. You can start on the first part for squeeze. :) MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Steve Langasek writes: > On Fri, Jul 03, 2009 at 01:18:14AM +0200, Goswin von Brederlow wrote: >> There is only one thing that DAK might want to adapt to. For most >> multiarch architectures there is a definite main architecture that >> most things should be in and then some corner cases where different >> architetcure might be prefered or required. Usualy because 32bit mode >> has smaller code and is faster than 64bit mode but sometimes the >> larger addresss space of 64bit mode is required. > >> So there might be a need to introduce partial architectures for ppc64, >> mips64, mips64el, sparc64 that only carry a small subset of >> Debian. The change would be in policy to allow architecture that are >> partial and maybe some code to reject unwanted packages from those >> architectures. > > + s390x > > I would encourage people interested in these architectures to work on > developing such a policy, building on top of the current multiarch spec. > This isn't critical-path for delivering an initial multiarch implementation > for squeeze, but I see no reason that it couldn't be worked on in parallel. Last I heart s390 planed to drop 31bit support and go fully 64bit. MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Joerg Jaspert writes:
> Hello world,
>
> (Please remember that we can only speak for ourselves and not the
> security/release/any other teams, individuals or other sentient beings.)
>
> During the recent discussion about about ia32-libs{,-gtk,-tools} there were
> various requests for removal / comments about ftpmaster requirements for the
> whole ia32-libs situation.
>
> Having looked at the situation both in lenny and in sid, we tend to agree that
> ia32-libs-tools in its current form is unacceptable. It was mentioned in the
Please do files bugs about issues you consider blockers for
ia32-libs-tools and squeeze and please include if that applies even if
there is the old ia32-libs in parallel to it (i.e. when it doesn't get
pulled in on upgrades).
> threads that comments had been received from ftpmaster that the lenny form of
> ia32-libs (the one where all the source is duplicated in two huge packages -
> ia32-libs and ia32-libs-gtk) was disliked. This remains the case but it is
> still preferable (both to us, and it seems to the majority of the rest of the
> project) than the ia32-libs-tools approach.
>
> Given that there are definitely use-cases for some form of ia32-libs, we
> suggest that a version of ia32-libs{-gtk} is re-uploaded to Debian, replacing
> the current ia32-libs-tools. This needs agreement with the release and
> security teams, as this most probably will have to be supported for squeeze in
> some form (even if that includes admitting that we have no security support
> for
> the binary ia32-libs packages).
Also an agreement from Bdale Garbee and/or Frederik
Schüler to remain its maintainer or another
volunteer.
> The recent discussions on doing multiarch properly look promising and, even
> better, there seems to be broad consensus that this is the right longer-term
> direction. The question is whether the first round could be ready for squeeze
> so that we don't have to ship ia32-libs again. This obviously depends on
> people wanting (and having time) to work on it; hopefully more will be known
> after the planned BoF at DebConf. Just to make it clear, there are no
> objections at all from ftpmaster to multiarch and we will make sure that any
> archive-side changes which may be necessary will be performed so that we don't
> block it (although looking at the current proposal from Steve Langasek et al,
> we can't really see anything which should need changing).
As per design. :)
There is only one thing that DAK might want to adapt to. For most
multiarch architectures there is a definite main architecture that
most things should be in and then some corner cases where different
architetcure might be prefered or required. Usualy because 32bit mode
has smaller code and is faster than 64bit mode but sometimes the
larger addresss space of 64bit mode is required.
So there might be a need to introduce partial architectures for ppc64,
mips64, mips64el, sparc64 that only carry a small subset of
Debian. The change would be in policy to allow architecture that are
partial and maybe some code to reject unwanted packages from those
architectures.
> This should drop the surprising effects users of the ia32-libs-tools packages
> experienced in the last few days and also allow us to continue supporting
> users
> of the 32 bit libraries.
I hope most surprises are addresses in the current version, at least
those that aren't as designed. Please do continue to file bugs when
you run into something so it can be addressed in the package and other
people are spared from the surprise in the future.
> This is, as ever, not a statement of the future, but suggestions and thoughts
> on the matter. It has mainly been written due to the fact that we have been
> asked by multiple people to remove ia32-libs-tools but don't want to do so
> until a consensus has been reached on what we're going to do to replace it.
>
> Thanks,
>
> --
> bye, Joerg
> Sesse: I doubt that many people will switch network
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New contact address for the wanna-build team, and other bits
Felipe Sateler writes: > Adeodato Simó wrote: > >> Regarding requests for give-backs, etc., this is the new state of >> things: >> >> * Packages-arch-specific: still bug against âbuildd.debian.orgâ >> >> * Bin-NMUs: still debian-rele...@lists.debian.org >> >> * Chroot problems, package priority issues: still @buildd.debian.org >> >> * Give-backs and dep-waits: debian-wb-t...@lists.debian.org >> (including requests for experimental, but please mark them as such) > > What is the difference between give backs and BinNMUs? A give back is a > request > to build again because the first failure was not the package's fault, but > rather the buildd? I can't seem to find anything on google. An explanation of > all this terminology (including dep-wait) would be appreciated (hopefully in a > document explaining why and when would any be needed and how to ask for them). A give back will reschedule a build. That might be needed because the buildd screwed up or a apckage got lost between building and installing in the archive or other things. Give back only works on packages that have not been installed in the archive. A dep-wait is when you need a certain other package to be available before a build should be tried (again). E.g. the old version of libfoo-dev is buggy and you want to wait for libfoo-dev (>= 1.2-3) to be available. A BinNMU is when a package should be rebuild with a new version and usualy across all archs. Usualy to facilitate some library transition the source Build-Depends on. This results in +bX to be added to the version. MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New contact address for the wanna-build team, and other bits
Adeodato Simó writes: > Hello, > > As previously mentioned, the wanna-build team has been looking into > moving to a public role address instead of a private alias. We now have > a list on lists.debian.org for this purpose: > > debian-wb-t...@lists.debian.org > > This address should be used in preference over the old alias for any > communication with us that doesnât require privacy (you can still use > wb-t...@buildd.debian.org in that case). Please create a new entry on http://www.debian.org/intro/organization for the debian-wb-team listing at least the major players. People looking for the email address will not find it here. MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian Membership
"Giacomo A. Catenazzi" writes: > Matthew Johnson wrote: >> My goals with changing the membership procedures are: >> >> - To turn NM into a more evolutionary process where some privileges and >>rights are granted earlier in the process and the qualifications for >> the >>later parts are based mainly on the work done with the reduced >> privileges >> >> - To make some of those reduced privileges legitimate goals for people >> to >>aspire to in their own right >> >> - To acknowledge more types of contribution >> >> - To retain at least some of the oversight and checks of the current NM >>process for all of the technical parts of the membership process >> >> - To decouple of technical and political positions in the membership >> >> Being part of the project, particularly with upload rights, is something I >> believe _should_ be difficult. This restriction on access to the archive is >> one >> of our strengths, it gives us a higher quality of packaging (yes, there are >> exceptions, but they should be the exception, not the rule) than would >> otherwise be possible. > > I'm confused about your intents, reading last quoted paragraph with the > "To turn NM into a more evolutionary process". > > I totally agree that the upload right should be difficult to gain. > But the frequent discussions about NEW queue give us a lot of informations: > - we want easier upload right (e.g. for NEW packages) > - we suck on upload quality (only on NEW queue ???) > - we must be anal/fundamentalist on license checks (not only on NEW queue). I think that plays nicely with his first point, reduced privileges. Debian already has some of that with the DM/DD split. There are different kinds of packages in debian that require different skills: - binary packages, data packages - simple library packages - mixed binary/library/data packages Also there is a big difference between the NEW packages and existing packages. Getting things right the first time is much more difficult than keeping a package current. So why not have a set of rights. Initially people only have right to maintain a package and all uploads must be sponsored. After some successfull uploads the maintainer could get rights to upload existing packages. After a few new binary debs (e.g. soname transitions of a library) he could gain rights to upload new binary debs for existing sources to NEW. And if someone shows an aptitude for creating new source package and judging license issues then he could gain that right. This could also be coupled with steps in the NM process. E.g. the Task&Skill section would be required before any upload rights. On the other hand I don't see why someone needs to maintain a package master packaging to get access to debian-private? Something a translator wouldn't need at all. > Thus: > - we (DD) must improve => I would like some QA on existing DDs on new > proposal It would be good if some existing bad apples loose their rights. Screw up a library transition -> loose binary upload rights to NEW. As for NEW source packages maybe everyone should loose that with the exception of a willing bunch of good DDs and then more can be added when they show they can do it. Call it the NEW team. They could vet packages before they take up ftp-master time. > - how can we trust to DMs, if they don't have technical review and license > review? By restricting them to what we've observed they can do and gradualy give rights as they demonstrate further skills. > The last point seems to contradict common interpretation of "to turn NM into a > more evolutionary process". > > In conclusion: > - a agree with more type of contributors, and more fine grained access control > (translators, bug checkers and patcher, QA, infrastructure ...) > - vote only on "makers" (uploader, translator, ...) (who makes something in > last years). > - upload should be difficult > - quality control on existing members (to force not to be to lazy) Becoming a member with minimal rights should be easy. That is where I think DM goes totaly wrong. It makes uploads easier and becoming a member harder. For example a maintainer should have rights to log into debian machines and track down bugs in their package before they have the right to upload on their own. Let them demonstrate they can fix bugs even on architectures other than their own. > ciao > cate MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian packages
Gabriel McCall writes: > Dear Debian Package Maintainers, > > Is there a definitive way to download packages for a machine that, > due to it's remote location, does not have an internet connection? > What I'm looking for is a complete file that would contain all the > packages that a specific application is dependant upon whether or > not a given operating system already included said packages in it's > makeup. This sounds like you want a partial mirror. There is apt-zip for package management with sneakernet (you carry an USB stick/disk around) but that will only list needed packages and skip already installed ones. If I had this problem I would use reprepro. Reprepro is an easy tool to create or mirror a debian archive for use with apt. It also alows filtering the package list to create partial mirrors. It is easy to mirror just a list of packages. The hard part and the part that is missing is to create the package list so that all depends/recommends[/suggests] are satisfied. Maybe you can borrow code from debian-cd for that. > If something like that is not available, would there be a way to > create files full of packages that would cover a large range of > basic packages in an index such as a "pool"? This would allow users > to download and burn a CD full of the latest packages for specific > uses such as Multimedia, games, development, or perhaps entire > desktops that could be added to existing operating systems. > > For example, I cannot install a second desktop environment such as > Xfce or Kde on a machine that has Gnome installed without using a > package manager and an internet connection. However, if I were able > to download a set of package files which came with thier > dependencies neatly bundled in an index that could be read by > something like synaptic; I could then install the alternate desktop > environment without the need for an internet connection. > > Simpler yet would be a multimedia bundle, or perhaps a networking > bundle. If I simply wanted a media player installed on my system > and could download a package bundle which contained everything > needed to install that specific media player it would be much easier > than trying to download each individual package and install them all > as individual binary packages. There are way too many kinds of bundles people might want for debian to provide them all and only providing a select few will always leave most people wanting. So I think that would be a bad idea. > Please help me understand why this is not something that is easliy found. > > Thank you for your time > > Gabriel (hellion_darkl...@inbox.com) MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Download AMD64
kosovar pirate <[EMAIL PROTECTED]> writes: > Hello everyone, > > I have tried to download the amd64 version of debain > from the website ftp.fr.debian with jigdo but it > always answers that there are 647 file left and it is > unable to download them. I don't know if this come > from the jigdo files which are not updated. Anyway can > you give me a way to finish my installation. > > Thank you and sorry for a so stupid question for > someone of your level ;-) > > Thank you. I'm just doing this for the Etch RC1 images and I also see a bunch of files missing from my partial mirror. I filter out some useless debs so that is expected. But jigdo-list downloads the missing files from e.g.: --06:15:14-- http://us.cdimage.debian.org/cdimage/snapshot/Debian/pool/main/k/kde-i18n/kde-i18n-nl_3.5.5-1_all.deb That should work for all jigdo files. Which ones are you trying to make? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please change the Maintainer: header when forking Debian
Roland Mas <[EMAIL PROTECTED]> writes: > Michael Banck, 2006-11-03 12:08:46 +0100 : > >> If you grab the .deb referenced from >> http://packages.ubuntu.com/edgy/graphics/kinoplus and look at the >> control inside, you will find: >> >> Package: kinoplus >> Version: 0.3.5-3build1 >> [...] >> Maintainer: Ubuntu MOTU Developers >> Original-Maintainer: Roland Mas <[EMAIL PROTECTED]> > > Ah, so it's in the .deb, okay. It's not in the .dsc, though. And I > don't think Ubuntu users are expected to extract the control files > from debs, or even to use aptitude and see package properties. All > the support I've found mentions Launchpad. Unless they add a patch I see no reason to change the dsc file in a forked distribution. Better to have the original file with matching md5sum. Easier to check for patches that way. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to best reach the users of a package?
Ian Jackson <[EMAIL PROTECTED]> writes:
> martin f krafft writes ("How to best reach the users of a package?"):
>> [stuff]
>
> Mail to root is sadly not really useful any more (and anyway, does
> someone with a cluster of 1000 machines really want 10 mails a
> week?). And I'm afraid I'm one of those old farts who thinks that
> everything-over-http/html is really quite lame.
You forward the root mail to the head-node of the cluster and only
activate the news service on the head-node. Only one mail of news for
the cluster. Where is the problem?
> How about mailing lists debian-{testing,unstable}-announce, with the
> following properties:
>
> * installing testing or unstable causes a debconf notification to
>ask the user to subscribe
> * the package name is at the start of the subject line
> * we provide a simple script which turns the installed packages
>into Exim, sieve and procmail filters, as part of some suitable
>package, and perhaps run it out of cron.
> * messages signed by DDs and every incoming message must have
>a Reply-To (usually either @packages.d.o or debian-devel
>or something).
>
> Ian.
Possible. But I would make that debian-{stable,testing}-announce.
Unstable users can read Debian.News from the package files for the
most part.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to best reach the users of a package?
Anthony Towns writes: > On Sun, Aug 06, 2006 at 03:57:22PM +0200, Henning Makholm wrote: >> Scripsit Roland Mas <[EMAIL PROTECTED]> >> > Yeah, I hadn't thought of that. But, ehm, since news bits can be >> > classified per source package, they could be generated once a day, fed >> > to dak and friends, in the pool and pushed to the mirrors. >> I wonder how much it would confuse apt and its friends if we simply >> piggybacked the information onto the Packages records by adding a new >> field (with the entire text or just an URL), but without bumping the >> version number. > > It wouldn't confuse apt at all -- we already do that for Task: overrides, > eg. I don't know if the code already exists for adding multi-line overrides > (like Description: as opposed to Section:), though I'm not sure that would be > a good idea (cf translations etc) either. > > It wouldn't be overly difficult to do this on a trial basis, if someone > wanted to maintain the information and work out some sort of way to > measure whether it's actually a good idea or not. > > Cheers, > aj I think it is a bad idea. News must be independent to the Packages file. The idea is to (among others) reach stable/testing users with important information. If that has to wait for britney or a full release cycle to reach them then it is useless. And asking them to download the unstable Packages files all the time just for news is a big waste of bandwith. Only unstable users would benefit from it and they have Debian.News and changelogs for that. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LSB 3.1 status for etch
Mats Wichmann <[EMAIL PROTECTED]> writes: > Goswin von Brederlow wrote: >> Sven Luther <[EMAIL PROTECTED]> writes: >> >> >>> On Sun, Aug 06, 2006 at 01:28:04PM +0200, Goswin von Brederlow wrote: >>> >>>> What does the LSB 3.1 say about amd64 and libdirs? Does it require lib >>>> to contain 32bit libs? >>>> >>> Does this same question apply to other 64bit arches, like sparc64 or >>> powerpc64 >>> for example ? >> >> Theoreticaly yes. But they have 32bit libs in lib and 64bit libs in >> lib64 anyway. >> >> Amd64 has 64bit libs in lib and lib64 (link to lib). 32bit libs are in >> /emul/ia32-linux/... and lib32 (link to emul) just like ia64 has. That >> is different from other linux distributions. >> >> >>> Friendly, >>> >>> Sven Luther >>> >> >> MfG >> Goswin >> >> >> > the LSB for any given archtiecture does not require support for any > others - they're independent. so the amd64 setup is fine via the > symlink, *until* someone decides they want to support ia32 and amd64 > on the same system, because in this case the ia32 libs are expected to > be in /lib (same issue for ia64 fwiw). LSB did have a proposal for > that written by Matt Taggart, but not implemented in the spec. The problem for Debian is that binutils still does not support this (/usr/lib/arch-os-gnu/) proposal and all the patches for multiarch are pending only on binutils now. I bet that if Debian had made the change then LSB would have given it more consideration. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LSB 3.1 status for etch
Sven Luther <[EMAIL PROTECTED]> writes: > On Sun, Aug 06, 2006 at 01:28:04PM +0200, Goswin von Brederlow wrote: >> What does the LSB 3.1 say about amd64 and libdirs? Does it require lib >> to contain 32bit libs? > > Does this same question apply to other 64bit arches, like sparc64 or powerpc64 > for example ? Theoreticaly yes. But they have 32bit libs in lib and 64bit libs in lib64 anyway. Amd64 has 64bit libs in lib and lib64 (link to lib). 32bit libs are in /emul/ia32-linux/... and lib32 (link to emul) just like ia64 has. That is different from other linux distributions. > Friendly, > > Sven Luther MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to best reach the users of a package?
Joseph Neal <[EMAIL PROTECTED]> writes: > Hi. > > User Here. > > RSS would be great, actually. It may not be the flashing red light you're > looking for, but a feed or two for each suite announcing critical updates > would be very much appreciated. Maybe you could ship Firefox (or all the > aggregators in the archive) with something like that preconfigured? > > thanks The problem with an RSS feed is that you have to constantly poll it or you miss items. Or the feed itself becomes so large that a lot of traffic is wasted for those that do regulary check. Imho a "get messages since XYZ" is essential for it to be efficient. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to best reach the users of a package?
Frans Pop <[EMAIL PROTECTED]> writes: > On Saturday 05 August 2006 21:20, martin f krafft wrote: >> I envision a tool (warning: braindump ahead) that we install *by >> default* on a standard system, which uses cron to wake up once a day > > I think that installing it by default is not really an option. As all > Debian services, it should be opt-in, not installed by default. > > Giving it the same status as popcon would IMO be an option. In effect that > means: we ask the user during installation of any new system if he would > like to use the service. If he/she declines, well, that's his/her choice. You can do both. Ask and default to yes. I think such a service is even more important than popcon. >> and check online for important announcements regarding all installed >> packages, and mails them to root if any are found. I was thinking >> first to use the BTS for that, but we don't want that. The PTS also >> does not provide what we need for this, so it'd be another service, >> possibly one actually using the mirrors for distribution. And we'd >> need a policy/moderation so as to prevent spamming the users. > > I like the basic idea of the service. Consider the comments below a > braindump as well. > > It should also support important upgrade announcements (probably both per > arch and per package or even arch/package combinations) before a new > release. > This means that the service also needs to support codename/suite. > > How will the service determine if a package related message is relevant > for a user? Single version, version ranges, codename/suite, all? > > The service should also support systems that do not have a permanent > internet connection. > > Maybe it should also support corporate installations where not each > individual system is "subscribed", but rather a sysadmin subscribes to > the architectures/suites that are relevant for his organization, maybe > with a blanket selection for any announcement relating to any base system > package + selected other packages. > > Cheers, > FJP Here is some more brain dump: How about using ldap for this? Or some other database service. Message infos are filed into the DB with a min/max codename/suite they apply to, a min/max version, the package(s) affected, a date, a type/priority and maybe some other values and an ID for the message item themself. Small enough that downloading does not overly strain the bandwith. Clients can then request all message infos (since date of last query) from the db, filter them according to installed packages, versions, codename/suite, user preferences and download the message items left after filtering. There should be a direct viewer for users that aren't always online and a mailer that can be run as daemon/cron job. I would also like it if every uploads add the changelog entry and Debian.News file to the service automaticaly. The type for a changelog should include the urgency of the upload as that should reflect how important the change is. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LSB 3.1 status for etch
What does the LSB 3.1 say about amd64 and libdirs? Does it require lib to contain 32bit libs? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux Magazin Germany, affecting Debian's image?!
Matthew Palmer <[EMAIL PROTECTED]> writes: > On Thu, Jul 20, 2006 at 12:24:20PM +0200, Goswin von Brederlow wrote: >> PS: Is it true that Ubuntu things about supplying a 3 year offer for >> source under 3b so derivates of ubuntu can go sourcelss? > > A nice idea, to be sure, but it doesn't seem particularly helpful, unless > the derivative isn't modifying anything GPL-covered (possible, I suppose, > but unlikely), since the moment you modify something you don't have a > written offer from someone for that source code, and can't use 3c any more. > > More likely, Ubuntu is going to let people who use the Soyuz (I think that's > the one) part of Launchpad to define their own custom distros provide the > source alongside the binaries, thus letting everyone go the 3a route (as > long as you sign your sanity away by agreeing to use Launchpad for > ever more). > > - Matt Most of the time you change 1% and keep the remaining 99% of the dvd as is (unless you rebuild every source package like ubuntu does). A derivative can then just include that 1% source and the written offer. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RE : Re: Linux Magazin Germany, affecting Debian's image?!
Matthias Julius <[EMAIL PROTECTED]> writes: > Goswin von Brederlow <[EMAIL PROTECTED]> writes: > >> It is not ok to distribute binary images and say: You want source? Ask >> Debian for it. That is what I ment with distributing only binary >> images. Debian does not give a written offer under 3b to be passed on >> by distributers under 3c. > > And if you buy the DVD in a month from now it might well be that the > source package for the version that is on the DVD is not available > anymore from Debian, especially for non-Sarge packages. > > Matthias Or even snapshot.d.n, like those packages lost when part of the raid died. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RE : Re: Linux Magazin Germany, affecting Debian's image?!
Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Tue, Jul 18, 2006 at 04:31:00PM +0200, Goswin von Brederlow wrote: >> On the other hand the GPL, and most packages will be GPLed, requires >> that source be available in one of three ways: >> >> 3a) include source >> 3b) accompany it with a written offer good for 3 years >> 3c) pass through an offer received from upstream >> >> Since Debian gives no written offer for their packages but does 3a the >> option 3c can not be used for anyone building their own debian dvds. > > Correct. > >> So if one does a custom dvd release of debian one must include source >> or make and keep it available for 3 years. By that reasoning anyone >> distributing only binary images is in breach of the GPL. > > Err, no. > > If you distribute binary images with a magazine and have something in > that magazine saying "if you want the source write to with a > photocopy of this specific text", everything is okay. Err, yes. That one sentence makes all the difference. It means you do distribute source (on request but still) and then you are stuck with it for 3 years. It is not ok to distribute binary images and say: You want source? Ask Debian for it. That is what I ment with distributing only binary images. Debian does not give a written offer under 3b to be passed on by distributers under 3c. MfG Goswin PS: Is it true that Ubuntu things about supplying a 3 year offer for source under 3b so derivates of ubuntu can go sourcelss? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RE : Re: Linux Magazin Germany, affecting Debian's image?!
Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Tue, Jul 18, 2006 at 03:38:32AM -0400, Radu-Cristian FOTESCU wrote: >> --- Wouter Verhelst <[EMAIL PROTECTED]> a écrit : >> > the claim that Debian can be downloaded is a simple statement >> > of fact which just happens to be true as a byproduct of the way >> > we create Debian, it is not a promise. >> >> If I can't trust what I can read on Debian.org, > > You can still download Debian for free from the Internet. The fact that > there is a certain specific DVD release of Debian that you cannot > download _in that specific form_ does not change this. Even if you can't > download the DVD as an ISO image, you can still download everything it > contains from ftp.debian.org and its mirrors. > > The website does not say "you can download every conceivable version of > Debian GNU/Linux for free from the Internet". It says "You can download > Debian GNU/Linux for free from the Internet", which should be read as > "There are versions of Debian GNU/Linux that can be downloaded for free > from the Internet". There is a major difference, and it makes your claim > (that everyone who makes a customized version of Debian must make it > available for download) false. On the other hand the GPL, and most packages will be GPLed, requires that source be available in one of three ways: 3a) include source 3b) accompany it with a written offer good for 3 years 3c) pass through an offer received from upstream Since Debian gives no written offer for their packages but does 3a the option 3c can not be used for anyone building their own debian dvds. So if one does a custom dvd release of debian one must include source or make and keep it available for 3 years. By that reasoning anyone distributing only binary images is in breach of the GPL. My recommendation is to ALWAYS have the option of a source image. If people don't download/order/pickup the source image along with the binary one they have only themself to blame. Option 3a of the GPL should be satisfied by that. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for a new DPL mediation ... This will be the only thread i will reply to in the next time about this issue.
Chris Waters <[EMAIL PROTECTED]> writes: > On Wed, Jun 21, 2006 at 12:14:42AM -0400, Benjamin Seidenberg wrote: > >> AIUI (please, correct me if I am wrong) the D-I repository is hosted on >> svn.d.o, a machine belonging to the debian project. > > Currently hosted perhaps (I really don't know), but alternate hosting > could probably be found if the d-i team felt it necessary. I'm fairly > certain that d-i meets all the necessary criteria for Sourceforge or > Savannah, for example. > > I want to make it clear that I don't think AJ or the project is trying > to force anyone onto anyone's team, or doing anything else wrong. I'm > simply saying that such an attempt to control the membership of a team > _would_ be futile if the team wasn't willing, so there's little point > in saying that AJ _should_ "just give Sven access". He really doesn't > have that power unless the d-i team is willing to cooperate! > > Neither AJ, nor the Tech Ctte., nor even the whole project through a > GR has the power to make Sven a member of the d-i team unless the d-i > team is willing to have Sven as a member. As long as the D-I team is a debian team the debian constitution holds. As such the DPL and a GR have certain powers. People keep saying that you can't force volunteers to do anything but that is wrong. You (as in GR, DPL or proper delegate) can always force them out, replace them with someone else or disband the team completly. Don't get me wrong. I'm NOT saying this should happen, would happen or anything. But if neccessary that option remains. Sven could be forced onto the D-I team, everyone else can quit or live with it. If membership of Sven would be considered more essential than the rest of the team (and that will never happen for any one person) that remains a possibility. How ever far fetched that is. MfG Goswin PS: I'M NOT SAYING THAT SHOULD HAPPEN. Mediation is about compromise and not about force anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for a new DPL mediation ... This will be the only thread i will reply to in the next time about this issue.
Thijs Kinkhorst <[EMAIL PROTECTED]> writes: > On Mon, 2006-06-19 at 23:32 -0500, Ean Schuessler wrote: >> Social politics creeping into Debian is one of the greater mortal >> dangers that we face. > > I surely hope not. Your mail suggests that someone who has severe social > problems but is technically competent is per definition fit as a > developer. The DAM has a different idea about this. You won't become a DD with social problems. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (Debian's Two Choices) The influx of women and the outflux of men. The end of debian as a distro and it's emergance as a women's rights pulpit.
Wouter Verhelst <[EMAIL PROTECTED]> writes: > Get a life. No, really. Get yourself a family, and start thinking about > the real important matters. > > Though I'll hope for your own sake that you're gay, because I don't > think you'll be able to find a girlfriend with an attitude like that. Are you insane? Starting a family? Advocating making many little copies of him all with the same attitude? Reproduction is the last he should do. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Donations
Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Fri, Jun 09, 2006 at 11:54:31PM +0300, Lars Wirzenius wrote: >> pe, 2006-06-09 kello 22:43 +0200, Florian Weimer kirjoitti: >> > * MJ Ray: >> > > any donations to debian must be given to SPI; or >> > >> > Why do you think this is so? >> >> Our Constitution, section 9.2: >> >> Since Debian has no authority to hold money or property, any >> donations for the Debian Project must be made to SPI, which >> manages such affairs. >> >> I think this is rather outdated; when it was written, the only >> organization that held money and property for Debian was the SPI. These >> days there's more. There is no point in forcing people to transfer money >> from, say, Finland to the US, just because of this clause in the >> Constitution. > > I agree, so perhaps we should change the Constitution to match. > > However, since SPI does more than just holding our money (it also is the > owner of the copyrights on our website and of (at least some of) our > servers), I don't think removing SPI from the constitution entirely is a > good idea. > > Perhaps a formulation like > > Since Debian has no authority to hold money or property, any > monetary donations for the Debian Project must be made to an > organization that has been vetted by the DPL to be allowed to > handle such things in name of the Debian project, where no more > than one such organization shall be vetted per country. > > Any property in hardware, trademarks, or in copyright will be > handled by SPI, which is our legal umbrella organization in the > U.S. > > might work. This would avoid having to update the constitution every > time someone wants to create a new organization. > > Cc sent to -vote, because if we're going to update the constitution, > this might be a good idea. This should refer to another text listing the vetted organizations. One outside the constitution so it can be changed as needed. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian women: please pass away
Debian Women Please Pass Away <[EMAIL PROTECTED]> writes: > Debian-women is an affront to all the men who make > debian the best linux distro out there. We do not need > a feminist organization attached to debian. > rant rant rant You are discriminating against a group of people while Debians philosophy clearly states that as a "DON'T". You are not worth being a Debian user. It is pigs like you that make Debian-woman a neccessity. Please go drown yourself, Goswin PS: Dear Debian-women, keep up the good work. PPS: You look so cute in Debian short-sleves. Especialy Alfi. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
Marco d'Itri <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > >>You can't wait for an hotplug/udev event to be done processing. That >>is always done asynchron without any feedback of completion. > This is not correct. Look at the while loop in the init script and and > the udevsettle source. s/wait/block/ You have to poll the queue as I understand it, right? >>will randomly fail or succeed depending on current scheduling. Any >>sequence of loading a module and using the expected device node has to >>utilize a sleep statement and prey udev runs fast enough to complete >>in the given time. > Wrong. Experince proofs me right and you wrong. Or everyone is doing it wrong. Maybe udevsettle addresses this problem, it is fairly new though, right? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
Martin Schulze <[EMAIL PROTECTED]> writes: > Goswin von Brederlow wrote: >> The most hideous problem of hotplug/udev is the following: >> >> You can't wait for an hotplug/udev event to be done processing. That >> is always done asynchron without any feedback of completion. >> >> >> Consequently any module loading has to randomly wait a while till >> devices show up before using it. A simple thing as >> >> modprobe my-harddisk-module >> mount /dev/my-hard-disk >> >> will randomly fail or succeed depending on current scheduling. Any >> sequence of loading a module and using the expected device node has to >> utilize a sleep statement and prey udev runs fast enough to complete >> in the given time. > > I guess that the mount should/may appear in a special udev rule? > > Regards, > > Joey Hmm, that is an idea. Instead of /etc/rcS.d/S24raid2, /etc/rcS.d/S30checkfs.sh or /etc/rcS.d/S35mountall.sh one could write udev rules that rerun the raid detection, fsck or mount whenever a relevant device gets added. There are quite a lot of rcS.d scripts that could be made into udev rules. S07hdparm is another one. .oO( Will we finaly obsolete rc scripts and replace them with udev? :) Does that work for an initramfs though? Since I have all my stuff compiled in I don't use initramfs so I don't know if it runs udev there or just the event capturer. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
Matt Zimmerman <[EMAIL PROTECTED]> writes: > On Sat, May 13, 2006 at 08:50:27AM -0700, Jim Bodkikns (Dakotacom) wrote: >> ALL of the servers chosen to be reinstalled with a debian distro have >> high performance raid controllers and fail installs due to UDEV issues. (I >> hate that redhat handles this - I"m not really a fan of redhat). I have >> been forced to abandon debian distros as a result. I'm not happy about that >> - I prefer debian - but find that it cannot be deployed and I have received >> zero interest from anyone from the hotplug group down to even acknowledge >> that this is a problem in general. So I am going to deploy FC bordeaux >> instead. >> >> I am only reporting this to let people know that this is an issue, sadly, >> that you might consider addressing. Thanks for a terrific distro otherwise >> though. > > I don't see it as a general issue either; if you have problems of this type, > you should report them to the bug tracking system so that they can be fixed. > Debian as an organization can't hope to test all of the hardware available > in the market, so we rely on feedback from folks such as yourself to let us > know when there is a problem. The most hideous problem of hotplug/udev is the following: You can't wait for an hotplug/udev event to be done processing. That is always done asynchron without any feedback of completion. Consequently any module loading has to randomly wait a while till devices show up before using it. A simple thing as modprobe my-harddisk-module mount /dev/my-hard-disk will randomly fail or succeed depending on current scheduling. Any sequence of loading a module and using the expected device node has to utilize a sleep statement and prey udev runs fast enough to complete in the given time. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Wed, Jan 18, 2006 at 08:57:51PM +0100, Goswin von Brederlow wrote: >> Matt Zimmerman <[EMAIL PROTECTED]> writes: >> > I don't agree. This isn't even the case within Debian. Binary-only NMUs >> > don't modify the source package, even though the binaries are recompiled. >> >> They obviously do. The version is bumped and a new changelog entry is >> added. > > Yes. And then the source used to build that binNMU is thrown away. It's > a *binary* NMU, you don't see a sourceful upload with that. Which means the Maintainer field in the binary package could easily be changed. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Mike Bird <[EMAIL PROTECTED]> writes: > On Tue, 2006-01-17 at 17:29, Thomas Bushnell BSG wrote: >> Matt Zimmerman <[EMAIL PROTECTED]> writes: >> > I don't agree. This isn't even the case within Debian. Binary-only NMUs >> > don't modify the source package, even though the binaries are recompiled. >> >> Actually, binary-only NMUs, after the first compilation, *do* get new >> version numbers. > > In Debian yes. Ubuntu recompiles the Debian source, in a > different environment and with different dependencies, then > uploads with exactly the same version as Debian. > > Having two different package files with the exactly the same > name and different content and dependencies drove me crazy > for a while until we made our migration scripts smarter. > > --Mike Bird Andreas Barth has some patches for the debian policy and packaging manual from me under review that also include this situation. In short it adds (explains the existing) an optional fourth (sub)part to the debian version: [epoch:]upstream_version[-debian_revision[+branch]] The debian_revision may contain an additional branch suffix denoting a "fork" in the debian version number. I suggest 4 types of branches [abcs]: - 1.2-3+a0.ubuntu.1 - recompile of a package without changes - 1.2-3+b1 - debian binary only recompile - 1.2-3+c0.ubuntu.1 - patched source based on the debian version - 1.2-3+s1.sarge.1 - debian security upload If that gets accepted into policy I suggest asking all debian based distributions to use the 'a' or 'c' branch to correctly flag recompiles and patching. Using the distribution name in the branch should give an unique enough version to avoid any confusion about the origin. An unbranched version should always mean the binary is unmodified (the md5sum matches debians). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Matt Zimmerman <[EMAIL PROTECTED]> writes: > On Tue, Jan 17, 2006 at 04:09:50PM -0800, Thomas Bushnell BSG wrote: >> Notice that what you say, in response to what has been asked over and >> over, is "my opinion is that changing the Maintainer field on >> otherwise-unmodified source packages is too costly for derivatives in >> general." >> >> But you say nothing about why. You already have suitable automated >> tools. > > I don't think you can speak to what tools we do or do not have. The fact > is, we import most Debian source packages unmodified, and do not have any > such tool for modifying them. Don't you run wanna-build, buildd and sbuild? It is easy enough to change the maintainer field with that. >> Since you are rebuilding the package, you *must* change the version number >> *anyway*. It is not correct to recompile, and leave the version number >> alone. > > I don't agree. This isn't even the case within Debian. Binary-only NMUs > don't modify the source package, even though the binaries are recompiled. They obviously do. The version is bumped and a new changelog entry is added. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SATA hard disks
Juan Carlos Munoz <[EMAIL PROTECTED]> writes: > I bought a Dell Dimension 8400 with a SATA 80 Gb drive. I > wish to know if the latest version of Debian (sarge) has > support for SATA disks. > > Thanks. > > Juan Carlos Muñoz This is the wrong list for this question and the wrong question. SATA disks are supported by the SATA controler. The question is: Is your SATA controler supported by Debian (sarge)? And the answere is: Maybe. Most controlers are supported but not all. Download the netboot / mini.iso (4MB), businesscard (~60MB) or netinst (~120MB) iso and try. If it works it works. If not then ask on debian-user or debian-boot about it providing the lspci output for reference. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#155998: Please close when appropriate
tag 155998 - woody reassign 155998 project,dak thanks Helge Kreutzmann <[EMAIL PROTECTED]> writes: > Hello, > there will be no more point release for woody and this bug is not > security-related. You have not even replied to this bug. So I think it > can be closed, correct? > > Greetings > > Helge This bug is still very much relevant. It affects woody (old-stable), sarge (stable), etch (testing) and even sid (unstable). The problem is that architecture independent packages are blindly included on all architectures. The example in the bug is: foobar-data (all) depends foobar (any), foobar is not available for this architecture. I believe uninstallable architecture independent packages can and should be filtered out in main for each architecture for all releases (or from testing down maybe as part of britney). MfG Goswin PS: Reassigning this also to dak as that is to blame. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Utnubu Team Founded - Merging Ubuntu changes to Debian
Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > [Goswin von Brederlow] >> If anyone is intrested in adapting this drop me a note. > > Please provide URL and repository for this source? Unfortunately it isn't anywhere public. Maybe we should put all the amd64.debian.net scriptlets and conffiles into a public cvs/svn/arch/whatever. The script rsyncs the Packages/Sources files from REMOTE_BASE and copies the local (amd64) ones from LOCAL_BASE and then generates the differences between the two in STATSDIR. *.current-*.txt are files that match name AND version *.missing-*.txt are files in REMOTE but not LOCAL *.removed-*.txt are files in LOCAL but no REMOTE Note that a version change shows up in both missing and removed. I plan to add black/white listing for non-free packages. You probably want the same to filter out all known Debian packages Ubuntu doesn't have. Anyway, here it comes: -- #!/bin/sh # # report differences in sources and arch:all packages # # Copyright (C) 2005 Goswin von Brederlow <[EMAIL PROTECTED]> # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License as # published by the Free Software Foundation; either version 2 of the # License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. set -e REMOTE_BASE=sinclair::debian LOCAL_BASE=/org/amd64.debian.net/ftp/debian/ REMOTE_ARCH="i386" # dummy arch as we only need arch:all LOCAL_ARCH="amd64" # dummy arch as we only need arch:all DISTS="testing testing-proposed-updates unstable experimental" SECTIONS="main contrib" STATSDIR="`pwd`/stats" TMPDIR="/tmp/report-source.$$" TMPDIR="`pwd`/work2" RSYNC="rsync -q" mkdir -p "$STATSDIR" mkdir -p "$TMPDIR" cd "$TMPDIR" for DIST in $DISTS; do echo $DIST: fetching meta files case "$DIST" in experimental) DIST_DIR="../project/experimental"; HAVE_DI="false";; *) DIST_DIR="$DIST"; HAVE_DI="true";; esac rm -f $DIST.Packages.new $DIST.Sources.new $DIST.Packages.old $DIST.Sources.old for SECTION in $SECTIONS; do $RSYNC "$REMOTE_BASE/dists/$DIST_DIR/$SECTION/binary-$REMOTE_ARCH/Packages.gz" "$TMPDIR/$DIST.$SECTION.Packages.gz" gunzip < "$TMPDIR/$DIST.$SECTION.Packages.gz" >> $DIST.Packages.new || exit 1 if [ "$HAVE_DI" = "true" -a "$SECTION" = "main" ]; then $RSYNC "$REMOTE_BASE/dists/$DIST_DIR/$SECTION/debian-installer/binary-$REMOTE_ARCH/Packages.gz" "$TMPDIR/$DIST.$SECTION.di.Packages.gz" gunzip < "$TMPDIR/$DIST.$SECTION.di.Packages.gz" >> $DIST.Packages.new || exit 1 fi $RSYNC "$REMOTE_BASE/dists/$DIST_DIR/$SECTION/source/Sources.gz" "$TMPDIR/$DIST.$SECTION.Sources.gz" gunzip < "$TMPDIR/$DIST.$SECTION.Sources.gz" >> $DIST.Sources.new || exit 1 gunzip < "$LOCAL_BASE/dists/$DIST_DIR/$SECTION/binary-$LOCAL_ARCH/Packages.gz" >> $DIST.Packages.old || exit 1 if [ "$HAVE_DI" = "true" -a "$SECTION" = "main" ]; then gunzip < "$LOCAL_BASE/dists/$DIST_DIR/$SECTION/debian-installer/binary-$LOCAL_ARCH/Packages.gz" >> $DIST.Packages.old || exit 1 fi gunzip < "$LOCAL_BASE/dists/$DIST_DIR/$SECTION/source/Sources.gz" >> $DIST.Sources.old || exit 1 done echo $DIST: diff sources grep-dctrl "" -s Package,Version -n < $DIST.Sources.new | paste -sd " \n" > $DIST.src-in.new grep-dctrl "" -s Package,Version -n < $DIST.Sources.old | paste -sd " \n" > $DIST.src-in.old cat $DIST.src-in.new $DIST.src-in.old $DIST.src-in.old | sort | uniq -c > $DIST.src-out.count grep "^ 1" $DIST.src-out.count | cut -b9- | grep -v "^$" > "$STATSDIR/$DIST.missing-sources.txt" grep "^ 2" $DIST.src-out.count | cut -b9- | grep -v "^$" > "$STATSDIR/$DIST.removed-sources.txt" grep "^ 3" $DIST.src-out.count | cut -b9- | grep -v "^$" > "$STATSDIR/$DIST.current-sources.txt" echo $DIST: diff packages grep-dctrl -XF Architecture all -s Package,Version -n < $DIST.
Re: Utnubu Team Founded - Merging Ubuntu changes to Debian
Andreas Tille <[EMAIL PROTECTED]> writes: > On Sat, 16 Jul 2005, Joachim Breitner wrote: > >> I invite everyone interested to join the Utnubu Team. Utnubu stands for > Great name for this! ;-) > >> doing what Ubuntu does, just the other way around: We want to take the >> things Ubuntu does and that are missing in Debian, and - where >> appliciable - put them in Debian. > I absolutely support the idea. I recently wondered whether we could > write some tool which compares package names + versions from both > repositories and then looking up the diff archive Scott is kindly > providing. For the first part we (debian-amd64) have a script to compare Sources and Packages files between two distributions (debian and debian-amd64 for us) and split them into package/version that are in one, the other and both efficiently. If anyone is intrested in adapting this drop me a note. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A new banner for Sarge
Florian Weimer <[EMAIL PROTECTED]> writes: > * René van Bevern: > >> The "apt-get into it" is hard to read because the space between each >> letter is almost as much as the space between each word. > > It's also a bit unfortunate because we recommend to use aptitude. Debian Sarge - with an aptitude. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Statistics about the project
Maykel Moya <[EMAIL PROTECTED]> writes: > On March 25, an Encounter of Free Software will take place at UCI, here > in Cuba. I'd like to give a talk about the Debian Project. > > Have been digging the net searching for use statistics about the > project. Up to know, I only have: > > - Percent of Debian based distros respect to the total. > - Amount of developers > - Countries of developers and its percent respect all countries. > - Amount of source packages Amount of debs available per arch (buildd.d.o / buildd.net), amount of popcon users per arch (popcon.d.o), most used packages (popcon). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian 64 bits
[EMAIL PROTECTED] writes: > Hello, > > When do you think a Debian AMD-64 will be released ( not Alioth ?). > We are a lot to expect it will be soon ... > > Thanx With etch in 2006-2010. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the ftpmasters
Joel Aelwyn <[EMAIL PROTECTED]> writes: > On Sun, Feb 20, 2005 at 09:06:36PM +0100, Goswin von Brederlow wrote: >> - uploads to NEW need an advocate in addition to the normal signature >>... > Hmmm. Seems like it could work, but might still have the issue that finding > two maintainers who think something is good is not vastly more difficult > than finding one; also, many packages are already co-maintained, would you > allow co-maints to both sign it? I believe it *is* possible to get multiple > signatures with GnuPG (the same way you can encrypt something to multiple > keys), but I'd have to go dig through the docs to figure out how to do it. When talking about a more automated NEW queue people said that ftp-master checks package names and splits for sensibility and rejects quite a few of those because they are silly. Having 2 people think about it should reduce that somewhat (not as much as a NEW team though). It's a simple 4 eyes see more than 2 solution. So co-maintained both signig should be ok, it's still 4 eyes, 2 brains, half an IQ :) >> - a NEW team >>... >... > 3) Doesn't (as far as I can see offhand) require access to sensitive > accounts, key signatures, or software. Thus, someone who processes NEW as > a "generate recommendations for ftpmaster" can do the job without needing > much, if any, in the way of privileged access (possibly some issues with > crypto, but those should be easily resolveable). You need access to the NEW queue. But if I'm not misinformed any DD can get to the mirror on merkel? If not, an inofficial NEW queue could be setup by someone, uploads to there could be judged and then put into the real queue with a recommendation mail. Whether or not ftp-master would find that usefull or not is another question (and they have to answere that). >... > > Not that I expect, given how this and past conversations have gone, that > they'd particularly want to deal with me, but if a NEW processing group is > considered worthwhile, consider me volunteered to put in the time. Maybe > the work is suitable revenge for having to read or delete so many of my > emails. Maybe you could make contact with ftp-master and ask their opinion. I doubt they would want a non DD running the show. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the ftpmasters
Matthew Palmer <[EMAIL PROTECTED]> writes: > NEW would still have to be processed by hand, though -- crypto notifications > still need to be sent, ... I still fail to see any reason why this has to be done _by_hand_. Isn't the mail send always the same format? Can't that be totaly automated into a "accept foobar" script? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the ftpmasters
Pierre Habouzit <[EMAIL PROTECTED]> writes: >> It's a little OT, but I think that the upload mechanisms should be >> enhanced a little to be able to *certify* that a package has been >> reviewed by many DD. the Uploaders field is not signed, and is not >> trustfully. I guess this should be a really interesting information >> (even not for OT) > enven not for NEW ... sorry Multiple signatures in the changes file? Does gpg allow that in a way the existing scripts would still cope with? Maybe it is as simple as that. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the ftpmasters
Joel Aelwyn <[EMAIL PROTECTED]> writes: > One of my 'real problems' is a completely stalled NEW queue; secondhand ... Hear hear. To the rest of the mail too. Many people would thank you for a solutiont to this. Hopefully you can get an answere faster then the 6 month it took to get third hand knowledge that the ftp-master problem with amd64 does not exist. > Now, if the reason is because everyone involved in ftp-master has more > crucial tasks to do with getting Sarge out the door, that would be one > thing; the answer would be "Wait" if we're expecting that to last a couple > of weeks at most, or "train an additional person" if we expect it to > persist (yes, I *know* training someone "costs", but it also pays off > fairly rapidly, thus the patience-if-it's-short). The NEW queue hasn't been the most expedient for some time now which would indicate this is a long term problem. Unless the reason for the delay is too many people fighting over the decision then more manpower can't hurt, right. Let me repeat two ideas I mentioned before: - uploads to NEW need an advocate in addition to the normal signature The advocates job would be to test the package, check for packaging mistakes, gross bugs, build failures, license, bad name choice when splitting a package. That sort of thing. This would be helpfull in filtering out more bad uploads to NEW. Is that a frequent thing? How much time is wasted on trivial rejections currently? - a NEW team The new team would be an appointed group (not just random DD as for the advocate) of DDs that do all the checking and testing of NEW packages and recommend to ftp-master to accept a package in the end. This would mean the ftp-master would loose some of their duties and only be the implementing tool (with a veto right?). Having a NM team has worked great to NM. Maybe that success could be repeated. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DAMs
Don Armstrong <[EMAIL PROTECTED]> writes: > On Mon, 14 Feb 2005, Gunnar Wolf wrote: >> Goswin von Brederlow dijo [Sat, Feb 12, 2005 at 01:55:43PM +0100]: >> > Do you realy think it is difficult to get a second signature onto >> > your gpg key? Go to one key-signing party and you get 10 even on a >> > small one. > It shouldn't pose much of a problem > to many applicants (at least those close to major metropolitan areas) > and those where it does will probably need an exemption to the > signature rule anyway. Thats what I ment just formulated much better. :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DAMs
Gunnar Wolf <[EMAIL PROTECTED]> writes: > Goswin von Brederlow dijo [Sat, Feb 12, 2005 at 01:55:43PM +0100]: >> Do you realy think it is difficult to get a second signature onto your >> gpg key? Go to one key-signing party and you get 10 even on a small >> one. > > There should be some kind of exemption to this clause, as what you say Obviously there can be as already mentioned depending on the circumstances. > does not always hold. Latin America has grown a lot in DD density, as > we now have DDs in mostly every country (although there are important > areas still missing)... But distances are huge. If a prospective DD The second signature does not need to be a DD. The density of people with a key inside the web of trust should be bigger than the DD density. > lives in Bolivia or Paraguay, he can decide travelling (by land) 3 > _days_ to central Argentina or 4 _days_ to central Chile (and, if Rudy > Godoy is approved soon, some 2 days to central Perú) - Air travel just > for a GPG signature is a joke, and most South Americans cannot afford > spending a minimum of about US$500 just for this. The situation in > Africa and Asia is similar or even worse. If you travel to some DD for your first signature I'm sure that DD knows someone else near himself that can also sign your key giving you two instant signatures. Think about it. The DD signature is the hard part. > This last year I travelled a lot in South America, signed a good deal > of keys, and hope to have contributed enlarging the web of > trust... However, we are still behind what is ideal. When my Colombian > friends Luis Fernando Bustamante and Andrés Roldán were accepted as > DDs, they were not connected to the Debian keyring except by a third > party who had gnu.org signatures, and when I started NM, I had only > their signatures. Not everybody can be expected to live or attend a > conference close to a DD. See, your second signature was no problem. The DD signature was. > We do need a path of trust, of course... But we are humans, and our > processes should have the subjective grain of salt to take these > points into view. You and they got it so the procedure obviously works. :) > Greetings, MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DAMs
=?iso-8859-15?q?J=E9r=F4me_Marant?= <[EMAIL PROTECTED]> writes: >> - We wont accept[5] applicants who have only one signature on their GPG-key >> if that signature is made by the advocate. If it has only a signature >> from the advocate at least another one from the web-of-trust is >> needed. Not neccessarly a DD to sign the key, any other well-connected >> key is sufficient. >> Applicants will be put on hold until this is fixed, but it shouldn't >> last too long. >> This is to avoid theoretical things against us/the applicants, that >> they are "faked" by the advocate, by providing one or more other >> signatures from different people. > > I don't get it. Do you have a concrete example that makes this necessary? > It seems more and more difficult to become member of Debian, which is > after all a volonteer-only project. Why trying to more and more discourage > people to contribute? Do you realy think it is difficult to get a second signature onto your gpg key? Go to one key-signing party and you get 10 even on a small one. It might be difficult to get a DD signature for geographical reasons but any signature is pretty simple. And, given how tight the web of trust is, a random signature is probably no more than 2-4 hops away from a DD. >> - Also not accepted are people without traceable actions for >> Debian. Examples of this include >>- having only one package in the archive, with only one upload, >>- packages with dead upstream and no visible changes in Debian either, >>- a poor or non-existent handling of their bugs for the package(s). > > What about translators? Isn't it time to give them a real status? > They definitely aren't second-class contributors. That should be a "traceable action" through the changelogs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Front Desk members
Florian Weimer <[EMAIL PROTECTED]> writes: > * Goswin von Brederlow: > >>> Or, at least, how many people in the project are willing to claim to >>> be women. :) >> >> Every NM sends in his passport [...] > > Not true, this is only a fallback mechanism if there's no other means > to identify them. Looks like the ID check has changed then since I applied last. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Front Desk members
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Chris Waters <[EMAIL PROTECTED]> writes: > >> On Mon, Jan 31, 2005 at 12:58:17PM +0100, Bartosz Fenski aka fEnIo wrote: >>> This way we could also simply check how many women is involved in >>> Debian project ;) >> >> Or, at least, how many people in the project are willing to claim to >> be women. :) > > Every NM sends in his passport and the sex is probably noted there in > every country. > > MfG > Goswin Or hers, sorry. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Front Desk members
Chris Waters <[EMAIL PROTECTED]> writes: > On Mon, Jan 31, 2005 at 12:58:17PM +0100, Bartosz Fenski aka fEnIo wrote: >> This way we could also simply check how many women is involved in >> Debian project ;) > > Or, at least, how many people in the project are willing to claim to > be women. :) Every NM sends in his passport and the sex is probably noted there in every country. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
