Re: RFC round 3: DEP-3: Patch Tagging Guidelines
On Mon, Jun 29, 2009 at 10:53:53PM +0200, Raphael Hertzog wrote:
> === Next step? ===
>
> After this round, if we don't have any important changes, I'll
> probably announce the format to debian-devel-announce. Should I use
> this opportunity to ask for more review or simply suggest people to
> start using the format?
It would be more appropriate to write a proof of concept
implementation before posting to d-d-a, IMO. That way your proposal
will be sounder and, for instance, Ubuntu or other distro people can
more easily start to converge with us. The implementation can be as
simple as a patch "validator" which parses all fields and complains if
some of the mandatory fields are missing.
Just my 0.02€,
thanks for the initiative!
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: multiarch and maintainer scripts
On Thu, Jul 02, 2009 at 09:36:23PM +0200, Goswin von Brederlow wrote: > what can be done if the maintainer scripts of a package must behave > differently when unpacking the i386 deb on i386 or the i386 deb on > amd64? > For example 32bit fglrx-glx needs to divert /usr/lib/libGL.so.1.2 on > i386 but /usr/lib32/libGL.so.1.2 on amd64. This example would seem to be obsolete once mesa was converted to multiarch paths. We could simply guarantee that /usr/lib32/libGL.so.1.2 didn't exist on any affected system (using versioned conflicts if appropriate), and then there's no need to distinguish. > Other examples would be packages that scan for plugins in their > postinst to generate a list of them. Pango and gtk used to do > that. Even if they are changed the multiarch library dirs they should > probably continue to scan the old plugin dirs for backward > compatibility. "used to do" - are there real-world examples of this? I don't think we should engineer solutions that are only relevant for *hypothetical* backwards compatibility. > So would it make sense to allow architecture specific maintainer > scripts? Back to the fglrx-glx example the control.tar.gz could > contain: > preinst-amd64 - use when configuring on amd64 > preinst - use otherwise > I choose '-' so it doesn't collide with debhelpers preinst.amd64 > source files. I think this is a horribly inelegant solution. And I'm unconvinced that there's any real reason at all for a properly implemented multiarch package to try to distinguish between different host architectures. -- 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
Re: Re-activating an emeritus account
On 03/07/09 at 13:12 +0800, Paul Wise wrote: > On Fri, Jul 3, 2009 at 12:02 PM, John Ferlito wrote: > > > I've been trying to become a Debian Developer again for a while. I am > > currently in emeritus status. The correct process for this according > > to [1] is to email da-mana...@d.o which I have done twice in the last > > year with no response. > > Try prodding the DAMs (Ganneff & Myon) or FD (bzed, Yoe, Myon, man-di) > on IRC on #debian-devel or #debian-newmaint. It is possible that the > mails went missing or unnoticed somehow. Maybe it would help to use RT to track questions to da-mana...@d.o instead of pure email? -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
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, the idea is broken by the design and it has numerous RC bugs. Do you *really* want to have more reasons? -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-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-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: CDPATH and shell scripts
Mike Hommey writes: > On Thu, Jul 02, 2009 at 02:26:21PM -0700, Russ Allbery wrote: >> Jonathan Yu writes: >> >> > How to fix them? Write Perl scripts, and turn on taint checking -- >> > that fixes the four issues above, because it makes the script exit if >> > any of them look dangerous. Env::Sanctify::Auto is a Perl module that >> > automatically cleans up the paths. >> > >> > My advice: >> > 1. Write scripts that might be run as root (or setuid root) using Perl >> > 2. Turn on taint checking >> > 3. Consider using Env::Sanctify::Auto (shameless plug) >> >> I would really prefer that people not start writing maintainer scripts >> in Perl as a matter of course. Perl is harder to analyze for programs >> like lintian than shell scripts (which are already hard enough). > > I wonder, do dpkg unset these variables when running maintainer scripts? > That could be a good idea if it doesn't already. > > Mike It does not, at least not specifically. Nor do nearly all shell scripts in /usr/bin. And think of what fun that would be to debug for a debconf using package. Suddenly debconf gets told some paths and errors out. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
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 -- But Captain -- the engines can't take this much longer! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
connection problem between BlueZ and BT module via UART port.
Hi! I am currently working on Debian with the latest version of kernel 2.6 of linux. I have bought a bluetooth module of the CSR company ( BTM-330, running with the BC4_roam type microprocessor) I have tried to link it with öy computer via the HCI protocol already existing on the one hand on Linux ( thanks to the installation of the blueZ package) and on the other hand also there on my BT module. However when I try to connect it with the hciattach commad on the UART type port (ttyS0) I get the following message:"Initialization timed out". Here is the tye of commad I have entered: hciattach /dev/ttyS0/csr Regarding the BT card, we can observe that the message is indeed received by the card because the light gets ON, but on the whole the connection between blueZ and te BTmodule is not realized. Then when I enter the hciconfig commad to see if the öodule has been detecte on the PORT, there is indeed nothing displayed. I have made internet searches on my own and from what I have read, it seems that it is due to the fact that the hciattach command needs to define the BT card at a baud rate of 230400 whereas on linus 2.6 ther is a "bug" that doesn't allow the UART to be programed at baud rates higher than 115200. So I would like to hve your point of view on this justification of the non detection of the bt module. Has anyone an idea of the localisation of the problem, and who eventually knows how to correct it? Thanks! Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: piuparts output wishlist?
> Lars Wirzenius writes: > > How would _you_ like to see piuparts report results, and produce other > > output? Go wild, the sky is bright blue. > > > > The obvious things to fix are: > > > > - make it really easy to see what the result of each test is > > Almost as obvious is to easily identify which test is being run. > I think a good way to show both of these would be to have a different > channel of output, beside the logging output, that shows explicitly a > test identifier at the start, and then the result of that test at the > end, with a visually similar presentation for both. “Test identifier” > can simply be a command line, for example:: > > N: Running command: ‘dpkg --info > /var/cache/pbuilder/result/burn_0.4.4-1_all.deb’ > … > I: Command OK: ‘dpkg --info > /var/cache/pbuilder/result/burn_0.4.4-1_all.deb’ > N: Running command: ‘chroot /tmp/tmpQm3zr8 dpkg -i > tmp/burn_0.4.4-1_all.deb’ > … > E: Command FAILED: ‘chroot /tmp/tmpQm3zr8 dpkg -i > tmp/burn_0.4.4-1_all.deb’ What about emitting this as TAP, the Test Anything Protocol [1]? The general format is 1..N ok 1 Description # Directive not ok 42 Description # Diagnostic It does not support severities, but these could be put in a Diagnostic line. [1] http://search.cpan.org/~petdance/TAP-1.00/TAP.pm Regards, Peter Pöschl -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: piuparts output wishlist?
Peter Pöschl writes: > What about emitting this as TAP, the Test Anything Protocol [1]? +0 from me. Investigating TAP is on my to-do list, so I don't have an opinion on that yet; but in principle it seems fine, and there is goodness in widely-used output formats. -- \ “Anyone who believes exponential growth can go on forever in a | `\finite world is either a madman or an economist.” —Kenneth | _o__) Boulding | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Dueling Banjoes
On Thu, Jul 02, 2009 at 12:48:16PM -0500, Gunnar Wolf wrote: >Andrea Bolognani dijo [Thu, Jul 02, 2009 at 05:03:37PM +0200]: >>We haven't got multiarch yet, and you ask for multibanjos support already? >> >>That's pretty rude if you ask me. > >But bibanjo can perfectly solve the needs at hand, with the hardware >at hand. http://www.theage.com.au/national/prehistoric-billabong-yields-three-new-aussie-dinosaurs-20090703-d78d.html Are you guys sure you're not talking about banjo, the new aussi dinosaur which is one of three recently dicovered in Australia? -- To UNSUBSCRIBE, email to debian-devel-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-devel-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-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
Hello, I really welcome the stuff in DEP 3. I've just scanned over the existing threads and haven't seen the following points made, but please excuse me if I missed a discussion already. One thing I would like to see patch metadata help facilitate is patch review. At the moment the "Reviewed-by" header proposed would allow a tool to ensure at least two sets of eyeballs had seen a patch; however, patches can go stale. I think some chronological information is needed alongside the review. I propose a "Last-Reviewed" header to capture this information. I decided on a separate header for this for two reasons * adding the date info to the Reviewed-by header will make it quite a lot longer * generally you only need to know the date of the last review, not the date of last review per reviewer. Secondly, why not use RFC 2822 for the date field used in Last-Update (and my proposed Last-Reviewed)? It has a better granularity including timezone support, is output by GNU date(1) easily with the -R argument and is already in use for email Date: headers and Debian .changes files amongst others. -- Jon Dowland Index: dep3.mdwn === --- dep3.mdwn (revision 69) +++ dep3.mdwn (working copy) @@ -145,11 +145,20 @@ field can be used mutiple times if several persons reviewed the patch. + * `Last-Reviewed` (optional) + +This field can be used to indicate when the patch was last reviewed. It +should list the email address of the reviewer (surrounded by +angle-brackets) and date when the patch was reviewed. The email address +should correspond to one used in a `Reviewed-By` header. The date should +be in RFC 2822 format. Example: +`Last-Reviewed: Fri, 03 Jul 2009 13:10:35 +0100 by ` + * `Last-Update` (optional) - This field can be used to record the date when the meta-information -have been last updated. It should use the ISO date format -`-MM-DD`. +have been last updated. It should use be in RFC 2822 format, such as +generated by GNU `date(1)` with the `-R` switch. Example: +`Fri, 03 Jul 2009 13:10:35 +0100` Related links signature.asc Description: Digital signature
5 sexy Date Ideas Wpiith Your Woman
5 sexy Dafte Ideas Wiith Your Woman www. gen44. net. Bacteria infesting grocerry cart heandles -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535607: ITP: libmoosex-has-sugar-perl -- Sugar Syntax for moose 'has' fields
Package: wnpp Severity: wishlist Owner: Jonathan Yu * Package name: libmoosex-has-sugar-perl Version : 0.0403 Upstream Author : Kent Fredric * URL : CPAN * License : Perl (Artistic + GPL) Programming Lang: Perl Description : Sugar Syntax for moose 'has' fields Reduced Typing in has declarations. The constant need to type => and '' is fine for one-off cases, but the instant you have more than about 4 attributes it starts to get annoying. More compact declarations. Reduces much of the redundant typing in most cases, which makes your life easier, and makes it take up less visual space, which makes it faster to read. No String Worries Strings are often problematic, due to whitespace etc. Noted that if you do happen to mess them up, Moose should at least warn you that you've done something daft. Using this alleviates that worry. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535610: ITP: libelf-extract-sections-perl -- Extract Raw Chunks of data from identifiable ELF Sections
Package: wnpp Severity: wishlist Owner: Jonathan Yu * Package name: libelf-extract-sections-perl Version : 0.0102 Upstream Author : Kent Fredric * URL : CPAN * License : Perl (Artistic + GPL) Programming Lang: Perl Description : Extract Raw Chunks of data from identifiable ELF Sections -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
This one time, at band camp, Goswin von Brederlow said: > Faidon Liambotis writes: > > > Goswin von Brederlow wrote: > >> ia32-wine is only available when ia32-apt-get is installed. > > WTF? Are you listening to yourself? > > > > Do you actually believe that it's okay to mess in such horrendous > > ways with the packaging system? > > If you don't want it then don't use it. That is your choice. You understand we're building a distribution here, right? This isn't just about whatever random thing you feel like doing. If a huge number of DDs are telling you you're wrong, you likely are. If you can't listen to your peers, I'm guesing this abortion needs to go the TC, but I would prefer if you could listen to what people are telling you. -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#535617: ITP: kupfer -- fast and lightweigh desktop summoner/launcher
Package: wnpp Owner: Luca Falavigna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: kupfer Version : c1 Upstream Author : Ulrik Sverdrup * URL : http://kaizer.se/wiki/kupfer/ * License : GPLv3 Programming Lang: Python Description : fast and lightweigh desktop summoner/launcher Kupfer is a summoner/launcher in the style of Quıcĸsılvεʀ or Gnome Do. It can search and browse your files, launch desired applications and objects you need. Kupfer is written in Python and has a flexible architecture based on plugins to extend its features. signature.asc Description: PGP signature
Bug#535615: ITP: libtopology -- Hierarchical view of the machine
Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: libtopology Version : 0.9 Upstream Author : libtopology team * URL : http://libtopology.gforge.inria.fr/ * License : CeCILL-B Programming Lang: C Description : Hierarchical view of the machine libtopology provides a portable abstraction (across OS, versions, architectures, ...) of the hierarchical topology of modern architectures. It primarily aims at helping high-performance computing applications with gathering information about the hardware so as to exploit it accordingly and efficiently. libtopology provides a hierarchical view of the machine, NUMA memory nodes, sockets, shared caches, cores and simultaneous multithreading. It also gathers various attributes such as cache and memory information. libtopology supports old kernels not having sysfs topology information, with knowledge of cpusets, offline cpus, and Kerrighed support -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535619: ITP: python-keybinder -- register global key bindings for gtk-based apps
Package: wnpp Owner: Luca Falavigna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: python-keybinder Version : 0.0.2 Upstream Authors: Ulrik Sverdrup Nigel Tao Raphaël Slinckx Sebastian Pölsterl Alex Graveley * URL : http://kaizer.se/wiki/python-keybinder/ * License : GPLv2 Programming Lang: C Description : register global key bindings for gtk-based apps Python extension to allow applications to register a key binding to be later executed when a combination of keys is pressed. signature.asc Description: PGP signature
Bug#535620: ITP: libfind-lib-perl -- Helper to smartly find libs to use in the filesystem tree
Package: wnpp Severity: wishlist Owner: Jonathan Yu * Package name: libfind-lib-perl Version : 0.06 Upstream Author : Yann Kerhervé * URL : CPAN * License : Perl (GPL + Artistic) Programming Lang: Perl Description : Helper to smartly find libs to use in the filesystem tree -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Progress on reprepro frontend
On Sunday 21 June 2009 03:33:33 Goswin von Brederlow wrote: > > Overall, I think that reprepro does a good job of maintaining a local > > repository, and we shouldn't reimplement what it does. Reprepro also > > seems flexible enough to implement most of the backend with simple > > commands and options. I've never tried to implement a new apt-method > > before, so I think that would take a bit more research from me. > > I totally agree that reprepro as the cache/storage backend would be > great use of existing software. > > The problem I have with it being an apt method is that the apt method > runs on a different host than the reprepro. That would require ssh > logins from all participating clients or something to alter the > reprepro filter. > > MfG > Goswin I've started on writing the reprepro frontend part of the program. The frontend isn't really complete, but I think it's a pretty good start. I decided to make a system user "repserve" that will control reprepro. This makes it easier to generate and use a gpg key with an unencrypted private key. Since the key should only be readable by the repserve user, and since the application is designed to make personal, partial mirrors, I think that this strategy should be sufficient for how it will be mainly used. The repserve user's home is at /var/lib/repserve Running "repserve intialize" should create the gpg key, export the key to /var/www/repserve/archive.gpg, and create the initial repserve.conf file. I don't know what to do about gathering entropy so that the key can be made more automatically. Instead of directly configuring reprepro, I've put the main configuration in a python config file (read by ConfigParser). I've made code that parses this config file (~/repserve.conf), and generates the reprepro configuration from this. This should make it easier to generate some of the more commonly used configurations for reprepro. I've made it so that the configuration can be filled from the contents of a sources.list file. Every 'deb' line uses dpkg --print-architecture to determine the arch to use. The deb-src lines use the "source" arch in reprepro. There is an --arch option that will let you specify the arch to use for the 'deb' entries, so it can be used like so: repserve addsources /etc/apt/sources.list repserve --arch=i386 addsources /etc/apt/sources.list Sources can also be fed from stdin: cat /etc/apt/sources.list | repserve --arch=c64 addsources or cat /etc/apt/sources.list | ssh repse...@mirror repserve addsources I have made a simple function that tries to guess the name of the repository from the method. So a method like http://security.debian.org/ gets the name "security", etc. This function doesn't work all that well yet, at it doesn't try to look at the names of the official mirrors to figure out if it's a debian mirror, and use the name "debian" for those. If a name isn't guessed, it tries to use "repos1", "repos2", etc. Adding additional sources will use the same repository name for each method already contained in the config file, so once you set a name, it should stay set. Changing the upstream mirror in the sources.list may cause an extra repository to be made if the mirror isn't identified in the guessing function. For each source in the sources.list, the Release file is retrieved and parsed. From the Release file the extra options such as Origin, Version, etc. are used. This make a better reprepro configuration without having to manually fill out all those fields. The release files are currently being retrieved using urllib2, but should be using python-apt. I haven't had time to mess with this yet, as I wanted to get other parts working first. The reprepro configuration isn't created automatically after adding sources, in case some of those repository names need to be changed. The reprepro configuration is created by: repserve reconfigure Each unique url in the sources list defines a separate repository. Each section in the repserve.conf file corresponds to a repository and the dist (codename). Each repository is split between the basedir and outdir, which makes it easier to use the outdirs in apache, or maybe ftpd (the default outdir parent is /var/www/repserve). The basedirs are located in /var/lib/repserve/repos-db/ . I have started making the bare minimum code to help manage filterlists. Since it hasn't really been decided how those lists are to be generated, and which repository is going to use which filterlist, I'm somewhat stuck here. I've tried to keep things flexible, so once something is decided, it should be relatively easy to implement. Reprepro isn't really being used yet. Only the configuration is being managed so far, which has been the most difficult part. There is some code that handles running reprepro, but it hasn't really been used yet. Only update and export are handled now, but it shouldn't be too difficult get this p
Re: [Debconf-discuss] GPG keysigning?
On Thu, Jun 25, 2009 at 11:24:29AM -0700, Russ Allbery wrote: > Giacomo Catenazzi writes: > > A naive question: why does not FSF check identity of contributors? > > They must sign a copyright assignment (or disclaimer), send this > > document to FSF, but I see no identity check on FSF side. > > > > They do this for legal reasons! > > > > For FSF copyright assignment is more important than identity check. > > For us seems the contrary, but AFAIK FSF work closely with lawyer then > > us! > > This may appear counterintuitive, but I believe the FSF is at > significant less legal risk for the sorts of problems we're discussing > than Debian is. This is because the FSF doesn't distribute binaries and > doesn't provide automated updates to systems. Even if this were true (which I doubt), I'm quite certain that whether or not you use your real name on a piece of software has any relevance whatsoever as to whether you're accountable and/or can be sued for what you did with said software. There is no reason other than "it's good form" why we would require a real name from contributors. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
Raphael Hertzog wrote: > Hello, > > it looks like we quickly converged on something relatively well accepted. > Current version: http://dep.debian.net/deps/dep3/ Thanks for working on this Raphael, I am glad to see it moving. I have a few comments, but overall I like the current proposal. It is also fine to replace the current Ubuntu guidelines for this in my opinion (there's no issues with "deriving from" the information that I can see). > Structure This certainly makes it easier to implement parsers, but I'm wary of it being too strict. To my reading it is not clear whether this is valid: #!/usr/bin/dpatch-run # # Description: ... and I think it should be. Also, can you use "#" comments if it isn't a dpatch file? I can imagine that some would write it like that for other patch formats. > This obligatory field contains at least a short description on the first line. > Supplementary lines can be used to provide a longer explanation of the patch > and its history. Is it worth advising that lines be < 80 characters (including "Description: ")? > one should simply indicate the URL where the patch got grabbed "one should simply indicate the URL where the patch was taken from" is less colloquial English. > Bug- or Bug (optional) I think your reasoning behind this is good, however, without a list of vendors is there going to be a problem with consistency in the Vendors? Is it Bug-Debian or Bug-debian? Should we just specify that parsers should compare the vendors in a case-insensitive manner when they do so, and assume that there aren't two names for a distribution? > Author (optional) Can be given multiple times I assume? That should be explicit as the way to handle multiple authors. > This field can be used mutiple times if several persons reviewed the patch. "several people" is more usual English, and the correct spelling is "multiple". > This field can be used to record the date when the meta-information > have been last updated. "was last updated" is more usual English. What do you see as the use for this? Is it just informational? > Josselin Mouette wanted to allow bug numbers instead of URLs in the Bug-*/Bug > fields. Several people expressed their preference for a simple URL field. > Sub-thread: http://lists.debian.org/debian-devel/2009/06/msg00543.html I don't like this suggestion at all. Copying and pasting a URL in is generally convenient, and while many of us will have quick ways of going from a bug number to the bug page, new contributors and those outside the project won't, and so it will be harder for them to get the information. Yes, typing the bugs.debian.org part when you have the bug number is tedious, but it's easy, and it's possibly a case of write-one read-many. > Guido Günther suggested to reuse field names used by git-format-patch and/or > allow them together with existing fields. > Message: http://lists.debian.org/debian-devel/2009/06/msg00551.html I can see the attraction here, but I see potential for difficulty around the extra fields that aren't in git-format-patch output. > After this round, if we don't have any important changes, I'll probably > announce the format to debian-devel-announce. Should I use this opportunity to > ask for more review or simply suggest people to start using the format? I think the suggestion of an implementation of a parser is a good one, though I'm not sure you should block on it. I would be interested in helping to write a tool to parse the fields and do something useful with them, if we had some idea of what would work well for lintian and other tools that would want to consume the output. Thanks, James -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
here's a nice big group-reply with an assortment of comments :) overall i think this looks pretty good, though i do have some concerns that will kind of repeat themselves below about there being too much emphasis on something machine friendly instead of human friendly... On Sun, Jun 21, 2009 at 12:07:42PM -0500, Raphael Geissert wrote: > Raphael Hertzog wrote: > > > Origin (required) > Making this field mandatory doesn't sound like a good idea to me, as it ACK On Mon, Jun 29, 2009 at 10:03:24PM +0200, Raphael Hertzog wrote: > On Sun, 21 Jun 2009, Raphael Geissert wrote: > > > Description (required) > > Why not simply consider all the free-form text the description? that would > > make all the current patches with a comment insta DEP3-compliant. > > Done, but that's a recommendatino for the parser. Note that it's not > DEP3-compliant since the Origin field is required. i really don't see why the origin field should be required, at least as is. personally i'd find the idea a bit cumbersome, as the same "keyword" information has probably been documented elsewhere (the changelog) and possibly duplicated (in the patch description), maybe even multiple times (the version control system), and possibly incorrect (a cherry-picked patch is updated locally due to other conflicting patches, but the header still implies otherwise because the maintainer forgot to update it). i'm also not sure i see the benefit in being able to know in an automated and machine readable way whether a patch was "cherry-picked" or "backported" or "cross-ported" or from an arbitrary "vendor" or "other". so... why not just let it be a URL or textual description? > > > Origin (required) > > Making this field mandatory doesn't sound like a good idea to me, as it > > already clashes a bit with the forwarded and author fields. If the Origin > > is upstream, then it doesn't need to be forwarded; and it doesn't cope very > > well with the idea of patches by some John Doe user. > > I believe it's important to be able to know where the patch came from. I do think that knowing where the patch came from is very important, and one of the main driving rationales behind this proposal. but more than a URL or a revision/commit id, and something that might need to be kept up-to-date? what's the benefit of having it be in such a strict and machine readable format? what benefit will a parser provide us being able to figure this out over us just reading it ourselves? (i'm not trying to be rhetorical i'm actually interested in hearing the justification) > > > Bug- or Bug (optional) > > Like Paul Wise already said: it would be better to have a single field where > > the urls to the bug trackers can be specified. It doesn't only make it > > easier to find the final url, but it also requires zero extra > > maintenance/updates on the parsing tools just to know about another bug > > tracker. > > Paul did not say that, he simply told that he preferred URLs instead of > bug numbers. also, it should be kept in mind that some upstreams do not have bug tracking systems at all, so the URL could very well be referencing a mailing list post or news update or similar. > Are you saying that you don't want Bug- but only Bug without > any requirement to indicate the vendor ? > > I think it would be bad because it would not allow to differentiate the > upstream bug url from the others. is there a benefit to differentiating in a machine readable way? if a human reads that, they should by context be able to tell which references the upstream (i.e. bugs.project.net), vs. debian (i.e. bugs.debian.org) vs some other vendor just by reading it. if there's a rationale, i think it should be included in the DEP to clarify why this is important. for example, is it so that the patch can be traded between distros with minimal fuss to the headers? On Tue, Jun 30, 2009 at 08:49:21AM +0200, Raphael Hertzog wrote: > > * “Origin (required): This field should document the origin of the patch. It > > starts with a single keyword that can have the following standard values” > > > > I think that the rules are too hard to follow strictly. What if the patch is > > not from upstream but for backporting, for instance? > > That case is covered: « “backport” (in the case of an upstream patch that > had to be modified to apply on the current version) » (see above question about benefit of strict Origin syntax) > The rules are not hard and if you don't know you should default to > "other". We could make that explicit if really needed. at the very least, could "other" be implied with the lack of this field? i.e., it seems much more natural to say Origin: http://blah/foo.html and allow the keywords like "upstream" to be used as optional sugar to add further information. and what about Origin: Some User okay, maybe that should be Author, but then why have an additional and duplicate field "Origin: other, submitted by..." requirement? later on, On Wed, Jul 01, 2009 at 0
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
Jon Dowland writes: > One thing I would like to see patch metadata help facilitate is patch > review. At the moment the "Reviewed-by" header proposed would allow a > tool to ensure at least two sets of eyeballs had seen a patch; > however, patches can go stale. I think some chronological information > is needed alongside the review. I propose a "Last-Reviewed" header to > capture this information. (Psst: the patch has exactly one header, structured into multiple fields. Just like an RFC2822 email message or an HTTP response.) -- \ “I bought some powdered water, but I don't know what to add.” | `\—Steven Wright | _o__) | Ben Finney pgpN2caXn95r3.pgp Description: PGP signature
ia32-apt-get: Striking my colors
Hi, I'm striking my colors. By popular demand I'm orphaning the ia32-libs and ia32-libs-gtk transitional packages. As said before the prerequisite for that was that someone else steps up as new maintainer for the old ia32-libs and ia32-libs-gtk monsters and Mark Hymers has agreed to do so. I don't know if Bdale Garbee and Frederik Schüler will remain co-maintainer that is up to them. I've have prepared a new version (22) of ia32-lib-tools http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=ia32-libs-tools http://mentors.debian.net/debian/pool/main/i/ia32-libs-tools/ - drops ia32-libs and ia32-libs-gtk packages so Mark can take them over - removes all diversions to the package management - adds a conflict with ia32-libs and ia32-libs-gtk to all packages - adds a Provides: ia32-abi - introduces new ia32-apt-get/ia32-aptitude/ia32-dpkg/ia32-dpkg-deb wrapper scripts that preserve the old functionality Now why should anyone sponsor that? Simple. The ia32-apt-get/ia32-aptitute will allow users that have already installed ia32-apt-get to update their ia32-lib* packages to ones that "Provide: ia32-abi". Then when Mark later uploads ia32-libs and ia32-libs-gtk he can "Conflicts: ia32-abi", "Replaces: ia32-abi" to get a smooth transition. Without this ia32-libs and ia32-libs-gtk would have to Conflicts/Replaces on over 160 packages which would be a real pain. So this is a call to all ia32-apt-get haters to sponsor the upload so Mark can replace it later on. MfG Goswin PS: Thanks to Mark Hymers for being not just talk like many other. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
On Fri, 03 Jul 2009 14:36:48 -0400, James Westby wrote: > Raphael Hertzog wrote: > > Josselin Mouette wanted to allow bug numbers instead of URLs in the > > Bug-*/Bug > > fields. Several people expressed their preference for a simple URL field. > > Sub-thread: http://lists.debian.org/debian-devel/2009/06/msg00543.html > I don't like this suggestion at all. Copying and pasting a URL in is > generally convenient, and while many of us will have quick ways of going > from a bug number to the bug page, new contributors and those outside > the project won't, and so it will be harder for them to get the > information. > Yes, typing the bugs.debian.org part when you have the bug number is > tedious, but it's easy, and it's possibly a case of write-one read-many. I respectfully disagree on that issue. In my experience bugs in Debian (in whatever context but also/including current patches) are referred to by their number; the same is true IMO for upstream bugs in certain fields (e.g. CPAN RT). I agree that that's not completely obvious/intuitive for "newcomers" but consumers of the patch format (command line tools, web interfaces, ...) are free to expand them to URLs, and those interfaces are probably more used than the raw source packages by the people who are not intimate with the semantics of the used bug trackers. Maybe I'm too lazy but I'd rather use Bug: #123456 Bug_CPAN: #12345 than having to construct URLs for these cases ... Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/ `-NP: REM: Shiny Happy People signature.asc Description: Digital signature
Re: [Debconf-discuss] GPG keysigning?
On Fri, Jul 03, 2009 at 08:52:14PM +0200, Wouter Verhelst wrote: > Even if this were true (which I doubt), I'm quite certain that whether > or not you use your real name on a piece of software has any relevance > whatsoever as to whether you're accountable and/or can be sued for what > you did with said software. It's not about whether you're accountable, it's about whether you can be *found* in order to be *held* accountable. -- 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
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
Hi: I think gregor makes a good point, and that there can be a reasonable compromise between the two worlds of "hey, let's just use URLs in the Bug: field" and "no, I'm too lazy, we should just use a nubmer and refer to the Debian BTS" On Fri, Jul 3, 2009 at 8:58 PM, gregor herrmann wrote: > On Fri, 03 Jul 2009 14:36:48 -0400, James Westby wrote: > >> Raphael Hertzog wrote: >> > Josselin Mouette wanted to allow bug numbers instead of URLs in the >> > Bug-*/Bug >> > fields. Several people expressed their preference for a simple URL field. >> > Sub-thread: http://lists.debian.org/debian-devel/2009/06/msg00543.html >> I don't like this suggestion at all. Copying and pasting a URL in is >> generally convenient, and while many of us will have quick ways of going >> from a bug number to the bug page, new contributors and those outside >> the project won't, and so it will be harder for them to get the >> information. >> Yes, typing the bugs.debian.org part when you have the bug number is >> tedious, but it's easy, and it's possibly a case of write-one read-many. > > I respectfully disagree on that issue. > > In my experience bugs in Debian (in whatever context but > also/including current patches) are referred to by their number; the > same is true IMO for upstream bugs in certain fields (e.g. CPAN RT). > > I agree that that's not completely obvious/intuitive for "newcomers" > but consumers of the patch format (command line tools, web > interfaces, ...) are free to expand them to URLs, and those > interfaces are probably more used than the raw source packages by the > people who are not intimate with the semantics of the used bug > trackers. > > Maybe I'm too lazy but I'd rather use > Bug: #123456 > Bug_CPAN: #12345 Maybe an idea is to have a format like: Bug: #123456 (assumes Debian BTS) Bug: BTS#123456 (same as above, but explicit) Bug: RT#123456 (to point to the CPAN Request Tracker) Bug: http://blahblah So you can use any of the above formats, either the short forms where you have: SYSTEM#NUMBER or the full URL. Of course, that makes it more complex to handle parsing slightly, but I think it's tolerable. And given previous fields I think Bug-CPAN is more appropriate than Bug_CPAN (underscores are not used in Control fields from what I can tell, like with Vcs-Browser for example) I think in general there are some common bug tracking systems and we should honour those, to make it easier for developers to write quickly, but in a way that is not ambiguous -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
On Fri, 03 Jul 2009 21:03:28 -0400, Jonathan Yu wrote: > I think gregor makes a good point, and that there can be a reasonable > compromise between the two worlds of "hey, let's just use URLs in the > Bug: field" and "no, I'm too lazy, we should just use a nubmer and > refer to the Debian BTS" Thanks for honouring my laziness :) > > Maybe I'm too lazy but I'd rather use > > Bug: #123456 > > Bug_CPAN: #12345 > Maybe an idea is to have a format like: > Bug: #123456 (assumes Debian BTS) > Bug: BTS#123456 (same as above, but explicit) > Bug: RT#123456 (to point to the CPAN Request Tracker) > Bug: http://blahblah Ack, and/but the original proposal has Bug- which seems reasonable to me, therefore I'd rather stick to Bug:, Bug-CPAN:, Bug-Gnome, ... > So you can use any of the above formats, either the short forms where > you have: SYSTEM#NUMBER or the full URL. Ack on either #number or URL. > And given previous fields I think Bug-CPAN is more appropriate than > Bug_CPAN (underscores are not used in Control fields from what I can > tell, like with Vcs-Browser for example) Sorry, that was a typo on my side. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/ `-NP: Queen: Heaven For Everyone signature.asc Description: Digital signature
Re: RFC round 3: DEP-3: Patch Tagging Guidelines
gregor herrmann wrote: > I agree that that's not completely obvious/intuitive for "newcomers" > but consumers of the patch format (command line tools, web > interfaces, ...) are free to expand them to URLs, and those > interfaces are probably more used than the raw source packages by the > people who are not intimate with the semantics of the used bug > trackers. Yes, but this is a format for sharing between distributions as well. It may be that they have now idea what "LP" means, and where to expand it to. Also, some suggestions have used RT and BTS, RT is a system, not an instance, and BTS is a generic term, so what do you use for instances? Also, in order for tools to expand these, they need a complete list of every bug tracker everywhere, do you really want to try and maintain that? It may be that we have slightly different workflows, but I tend to have a bug open in my browser when working on it, so it's trivial to grab the URL. In addition the Debian BTS doesn't inject URLs in to the messages, so they are not to hand if you are just going on an email from a bug. Thanks, James -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debconf-discuss] GPG keysigning?
On Fri, Jul 03, 2009 at 06:00:11PM -0700, Steve Langasek wrote: > On Fri, Jul 03, 2009 at 08:52:14PM +0200, Wouter Verhelst wrote: > > Even if this were true (which I doubt), I'm quite certain that whether > > or not you use your real name on a piece of software has any relevance > > whatsoever as to whether you're accountable and/or can be sued for what > > you did with said software. > > It's not about whether you're accountable, it's about whether you can be > *found* in order to be *held* accountable. I'm not convinced it is significantly easier to find someone by use of just their name and email address than it is to find them by use of just an alias and an email address. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
