Re: Sponsorship requirements and copyright files
ti, 2009-03-24 kello 17:50 -0500, Manoj Srivastava kirjoitti: I am expressing my opinion now, on a mailing list devoted to debian development. I have not been keeping up witht eh bureaucratic rigmarole that seems to be being wrapped around discussions, not after we got the notice that there was a topic to be discussed, but we should not discuss it since the red-tape software was broken. It's not very clearly written into DEP0, but it was always my intention, I and think Zack's and Dato's (that is, the people who came up with DEP in the first place), that the DEP process should introduce very low levels of bureucracy, and that _all_ the bureaucracy would be handled by the drivers. Indeed, as far as anyone else is concerned, the DEP might not even exist. Whoever is drafting the draft ought to be paying attention to the feedback being generated now, and create a better draft to start with. I fully concur. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
ke, 2009-03-25 kello 01:32 +, Noah Slater kirjoitti: On Wed, Mar 25, 2009 at 12:39:46AM +, Steve McIntyre wrote: I'm curious... What do you think *is* the Debian way of doing things like this ? Manoj's email strongly implied that a DEP was needless bureaucracy. I'm hardly likely to argue with you about what constitutes the Debian way, but considering we've let a proposal stew on a wiki for over a year, have taken some discussion over to the mailing list and are now working on a DEP, I find it very confusing that it should be considered that we are somehow abusing the process. Speaking as one of the drivers of DEP0, I think you are misunderstanding how DEPs should be driven. They should not be used to control the discussion. They are, very fundamentally, a way to record consensus and the state of the discussion. As a by-product, they hopefully produce a document that will be useful later. If the people participating in a discussion have to be aware that something is discussed as part of a DEP, and have to adjust their behavior accordingly, the drivers have failed. (Also, DEPs are hardly the established Debian way of doing things. There's only two accepted ones, and only six ones ever registered, counting DEP0 itself. I hope that DEPs will some day be accepted, but they won't be, if it's OK to use them as hitting implements.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Tue, Mar 24, 2009 at 11:44 PM, Kalle Valo kalle.v...@iki.fi wrote: Luis R. Rodriguez mcg...@gmail.com writes: As a lot of you know we have a new regulatory implementation for Linux wireless now [1]. We have kept the old regulatory implementation through a Kconfig option, CONFIG_WIRELESS_OLD_REGULATORY. Distributions are slowly converging to start setting this to N -- as of 2.6.28. Distributions are also now shipping wireless-regdb [2] and CRDA [3]. Just of curiosity, what's happening with crda in debian? I still don't see them in debian unstable. I just found iw version 0.9.9-nogit in unstable, though. So things are going forward. Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
On Tue, 24 Mar 2009, nescivi wrote: Given that there are several audio oriented distributions based on Debian (e.g. 64studio and pure:dyne) that would benefit from this, and I am sure their teams may be interested in helping to support it too. IMHO it makes perfectly sense to try to join forces with these Debian based distributions and try to comaintain a -rt kernel package together with these guys to ensure a solit maintenance inside Debian. A lot of linux audio users build their own patched kernels, because they can't get it from the distribution; So why don't these people try to go the right way (tm) and work on an official -rt kernel package? and not all of them enjoy doing it. (I've kept postponing it, but if I don't find one in a distro soon, I'll probably have to... the current Ubuntu rt kernel seems to have some other issues I believe... at least on 64bit...) One reason more to finally solve the problem in the source distribution to make sure that all derivers will profit from it. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
On Tue, Mar 24, 2009 at 09:20:59PM -0500, Steve M. Robbins wrote: Is the NEW queue going to get processed any time soon? There are 215 packages waiting [1] about half of which have been there 3 or more weeks. FWIW, my lastest NEWs (emerged in the last few days) took between four and six weeks each. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature What is the percieved DFSG/RSA conflict? I can't detect any based on that section of the page. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 12:39 AM, Paul Wise p...@debian.org wrote: On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature What is the percieved DFSG/RSA conflict? I can't detect any based on that section of the page. Thanks Paul, then its just a matter of packaging. There is an debian-example/ directory with a cdbs example of how to package for wireless-regdb and crda if anyone is up for it. Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 12:47 AM, Luis R. Rodriguez mcg...@gmail.com wrote: On Wed, Mar 25, 2009 at 12:39 AM, Paul Wise p...@debian.org wrote: On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature What is the percieved DFSG/RSA conflict? I can't detect any based on that section of the page. Thanks Paul, then its just a matter of packaging. There is an debian-example/ directory with a cdbs example of how to package for wireless-regdb and crda if anyone is up for it. And as its probably best to coordinate with Ubuntu, they have a wireless-crda package which combines both into one package. Its shipping for Jaunty. Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
Steve M. Robbins st...@sumost.ca writes: Is the NEW queue going to get processed any time soon? There are 215 packages waiting [1] about half of which have been there 3 or more weeks. NEW is being processed almost daily. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
On Wed, Mar 25, 2009 at 11:12:10AM +0300, Kalle Kivimaa wrote: Steve M. Robbins st...@sumost.ca writes: Is the NEW queue going to get processed any time soon? There are 215 packages waiting [1] about half of which have been there 3 or more weeks. NEW is being processed almost daily. But not sequentially. It causes confusions when some packages stay for just a few days, while others are kept for several months. IMHO, except package with just SONAME bump, packages in NEW queue are better processed in a FIFO manner. Just my two cents. Regards, Deng Xiyue signature.asc Description: Digital signature
Re: NEW processing
Deng Xiyue manphiz-gu...@users.alioth.debian.org writes: IMHO, except package with just SONAME bump, packages in NEW queue are better processed in a FIFO manner. Just my two cents. Most of the time this is the case. But, if you upload a large, complex package, that might get passed by for a while so that several small, easy packages might be processed in the same time. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
On Wed, Mar 25, 2009 at 12:02:18PM +0300, Kalle Kivimaa wrote: IMHO, except package with just SONAME bump, packages in NEW queue are better processed in a FIFO manner. Just my two cents. Most of the time this is the case. But, if you upload a large, complex package, that might get passed by for a while so that several small, easy packages might be processed in the same time. Obviously this is causing starvation. Maybe one ftpmaster should always work from the back of the queue, or they should make sure to always process one package from the back of the queue for every three from the front? -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Re: [dissenting]: Proposal: Enhance requirements for General resolutions
Le Wednesday 25 March 2009 04:57:39 Gunnar Wolf, vous avez écrit : I agree. I fail to see where the GR process was abused. Since that seems the main argument in favour of this change, I fail to see the motivation for it. This proposal does not come from an abuse to the GR process, but to generalized frustration about the way 2008_002 and specially 2008_003 were handled. Ok. I understand the furstration about them, but I don't think that the number of seconders was the reasons for the abuse. There was clearly a need for those GR, so raisong the number of seconders would just have the consequence to prevent us from voting on important topics. Furthermore, I don't think it is wise to propose an enhancement and not explain what was the abuse with *details* and *examples*, nor how the proposal would enhance it. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
2009-03-25 (수), 16:55 +0800, Deng Xiyue: IMHO, except package with just SONAME bump, packages in NEW queue are better processed in a FIFO manner. Just my two cents. OTH, do we really need a manual check for SONAME bump? Was there any upload rejection in the past on new binary package addition cases? -- Changwoo Ryu cw...@debian.org signature.asc Description: This is a digitally signed message part
Re: NEW processing
On Wed, Mar 25, 2009 at 10:11:03AM +0100, Guus Sliepen wrote: Obviously this is causing starvation. Maybe one ftpmaster should always work from the back of the queue, or they should make sure to always process one package from the back of the queue for every three from the front? That's not very fair on the maintainer who is unfortunate enough to upload their package just before ten others. I enquired previously about whether we might have some developers assist the ftpmasters by pre-assessing packages and reporting appropriately, which might ease the process. I don't know if this would actually help them or just duplicate work, since they need to be sure that it's been done properly in any case. (ftpmasters: your thoughts?) I'd happily help out in this area, but not being a DD I'd probably need considerable mentoring, at least to start with. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: NEW processing
Jonathan Wiltshire deb...@jwiltshire.org.uk writes: I enquired previously about whether we might have some developers assist the ftpmasters by pre-assessing packages and reporting appropriately, which might ease the process. I don't know if this would actually help them or just duplicate work, since they need to be sure that it's been done properly in any case. (ftpmasters: your thoughts?) Most of the REJECTs are very trivial, so any peer review helps to spot them. I'd say that 90% of the REJECTs are simple the package contains license X files but X isn't listed in debian/copyright. Spotting these before the package hits NEW speeds up the process a lot. To put this into context: I had one package rejected recently for trivial incompleteness in debian/copyright, and I should know better - but you become blind to your own work, so having another pair of eyes go through the source does help. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
On Wed, Mar 25, 2009 at 3:20 AM, Steve M. Robbins st...@sumost.ca wrote: Is the NEW queue going to get processed any time soon? There are 215 packages waiting [1] about half of which have been there 3 or more weeks. It might be worthwhile reflecting upon what purpose the queue has. In a simple model, if the inflow rate equals the outflow rate, the queue in between can be arbitrarily long without serving any purpose or function but causing a delay (which is bad!). But, in reality, at least a part of the queue has a buffering function (since the ftp masters cannot work exactly in sync with incoming packages). Another function is as storage place during active work on evaluating packages. I guess the former function, on average, requires most of the queue length. It is probably good to have some standard for what is a reasonable length for this buffering and define a threshold over which the outflow rate should be higher than the inflow rate. In order to get the outflow rate higher than the inflow rate it is important that the work on the queue is fun and motivating. If the queue is long, people get irritated which doesn't make the important work of the ftp masters more rewarding. So, this is a bad situation. I guess one of the conclusions to be drawn is that it is extremely important to have a sufficient number of ftp masters. The project should prioritize the work on finding more ftp masters. I also think it is questionable to have strict rules for the ordering of processing, since having some degree of flexibility both can adapt the work somewhat to the ftp masters, so that work becomes easier and more fun rather than the reverse, and, make it possible to prioritize in a way that benefits the project as a whole. If queue length can be kept down this shouldn't be a problem. We must remember that having a queue length over a certain threshold serves no purpose at all! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Mittwoch, 25. März 2009, Gunnar Wolf wrote: Munin ... does not support alerting It does. Directly or via nagios. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: NEW processing
On Wed, Mar 25, 2009 at 10:11:03AM +0100, Guus Sliepen wrote:
Most of the time this is the case. But, if you upload a large, complex
package, that might get passed by for a while so that several small,
easy packages might be processed in the same time.
Obviously this is causing starvation.
No, it is not (on the assumption that we have simultaneous people
processing NEW which, AFAIK, is the case).
Cheers.
--
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: Please Improve Debian for Multimedia Production
Andreas Tille wrote: After reading the documentation, I still don't know if a blend is useful for us. Blends seem to be some kind of cooler tasks, is that true? Well, the terminology was taken over from tasksel at some former point in time - but it is a little bit more. Could you elaborate a bit? From what I gather (after reading the docs and skipping through the pages you have referenced), all I see are tasks (enhanced with metapackages with Recommends), and a nice web frontend. I'm pretty sure I'm missing something here. For them to be really useful there should be clearly defined use cases that justify creating the metapackages and tasks, for which I'm afraid there aren't in the multimedia world. Other than ardour or audacity, every multimedia user will probably use a different set of tools for doing their work (ie, there are lots of alternative software synthesizers/effects processors/whatever). If there is no such clear set of tools, is there a point in creating a blend? I'm not sure whether your point of view is based on your large amount of knowledge you might have about this field. You definitely know what to use and where to look at. Assume a person who is installing Debian the first time. Which advise would you give if this person might ask you: What Multimedia software is inside Debian. What should I install for a start. Which applications should I try to find out which might fit my needs best? If a person asked me that giving me the freedom to choose OS, I would be at a loss. For example, if somebody asked me: What should I install to get started in sound synthesis? (A more concrete example, and which I know best) I would not know what to say. There are big graphical sequencer and synth, like lmms, or graphical synths like puredata, or text synths, like csound or supercollider. Which one would be best? Install all of them? IME, people learn a program/language and stick to it. It's like trying to create a Software Development blend... it's just too broad and defined by personal preference, with no clear better packages. I can not imagine that multimedia is that different from other Blends. Look at the Debian Med biology task: There are more than 60 Dependencies inside Debian and there is not a single user who is using them all. We sometimes consider to split this up to some extend but did not until now. The fact is if a biologists asks you: What biological software is inside Debian? You can simply answer: Lock here: http://debian-med.alioth.debian.org/tasks/bio.html What should I install to get ready for work quickly? apt-get install med-bio For sure this installs several applications which are not needed by every person - but this is no exception to any other method to install a group of software. Metapackages are builded that way that you can deinstall every application because it uses only Recommends. So the user can start, try and in case of get bored by something remove a package later. Blends are intending to give the flat package pool some user specific structure which regards the needs of a certain group of users. And you as the multimedia developers are the people who know these users and might be able to prepare the system as good as possible. I might imagine certain tasks (please be patient - it is a suggestion of a poor user regarding multimedia stuff, just correct me if I'm wrong about your purposes): sound-recording sound-playing video-recording video-playing image-editors image-viewers note-editors (for noteedit - no idea whether this is a reasonable category name) ... Although I wouldn't choose those tasks[1], but lets go over them to illustrate my point. What should we put into sound-recording? All of them? The X more popular according to popcon? The ones I use? Also, use cases overlap: I don't think there is a sound recorder that is not also a sound player. Probably syncing with existing DebTags (I did not checked these) should be a good advise. Probably more fine graining needs to be done. At least I would *really* love to have an overview about these categories in Debian. Technically you might also approach this by applying DebTags and my goal is to technically merge DebTags and Blends technique stronger in the future. But as far as I know there is no such thing like a tasks or a bugs overview based on DebTags. Moreover you are able to include packages into your focus which are maintained by maintainers who are not joining your Multimedia Team (for whatever reason). I hope I was able to give some reasons why a Blend makes sense. I agree that it makes sense, at least for some users. However, maintaining a Blend is (I assume) time consuming. What I'm wondering is if it is worth the effort. Is it going to ease our work as a team? Is it going to make it easier for 64studio to integrate with us? [1] Actually, the multimedia name
Re: #520646: binNMU oprofile
Hello, Looks like oprofile needs a rebuild . $ opreport opreport: error while loading shared libraries: libbfd-2.18.0.20080103.so: cannot open shared object file: No such file or directory $ dpkg -L binutils | grep libbfd- /usr/lib/libbfd-2.19.1.so I’m told libbfd.so is a private/internal library of binutils that should not be dynamically linked against. A static version exists (libbfd.a), and packages should be using that AFAIK. Cc'ing -devel in case there’s a reason it should not be that way. If, on the contrary, nobody objects, I’ll file a wishlist against lintian so that an error (warning?) is emitted for packages that DT_NEED that library (and libopcodes/libiberty as well?) Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
Le Wednesday 25 March 2009 11:08:28 Stefano Zacchiroli, vous avez écrit : On Wed, Mar 25, 2009 at 10:11:03AM +0100, Guus Sliepen wrote: Most of the time this is the case. But, if you upload a large, complex package, that might get passed by for a while so that several small, easy packages might be processed in the same time. Obviously this is causing starvation. No, it is not (on the assumption that we have simultaneous people processing NEW which, AFAIK, is the case). My personal experience is not consistent with this. I have several very small ocaml packages waiting in NEW for several weeks now. I am upstream on these packages, and, honnestly, it takes few minutes to check them (only 3 files of code in tarball). On the other hand, I have been trying to move to the new libgavl for some times. Although I did make mistake in the copyright file, each round through NEW took me almost 2 months, which means that the transition is on-going since almost october or november. I have refrained myself from complaining so far, since it is usually not constructive, but until last week, all my debian-related activities were stuck in NEW. (Un)fortunately, gmerlin was rejected last week since I missed some licence headers in the doc/ so I can now fix this and wait again for two months. I would strongly advertise a public collaborative license and copyright check. That is the kind of work that we could all do and report in the NEW queue. Of course, the work that ftp-masters do is very important, in particular for checking unsual licence, or checking archive consistency, so thay should have the last word. However, if like 3 DDs claim they have reviewed the package's license and that eveythying is like GPL, along with a subjective views on the complexity of the package's check, then the work should be much more faster afterward. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
Andreas Tille wrote: On Tue, 24 Mar 2009, nescivi wrote: Given that there are several audio oriented distributions based on Debian (e.g. 64studio and pure:dyne) that would benefit from this, and I am sure their teams may be interested in helping to support it too. IMHO it makes perfectly sense to try to join forces with these Debian based distributions and try to comaintain a -rt kernel package together with these guys to ensure a solit maintenance inside Debian. A lot of linux audio users build their own patched kernels, because they can't get it from the distribution; So why don't these people try to go the right way (tm) and work on an official -rt kernel package? and not all of them enjoy doing it. (I've kept postponing it, but if I don't find one in a distro soon, I'll probably have to... the current Ubuntu rt kernel seems to have some other issues I believe... at least on 64bit...) One reason more to finally solve the problem in the source distribution to make sure that all derivers will profit from it. A little sidestep: Also for a realtime kernel for music production it's important to have the right drivers in it, to support firewire devices for example. I read this on the Debian multimedia mailinglist: We're aiming to have this package in 64 Studio 3.0, we also need to change our 2.6.29-rc4 kernel to support the old firewire stack though. Why only in 64studio and not in plain Debian? What's good for Debian is good for us :-) but the Debian project may not want to tweak the kernel or the FireWire stack just for the benefit of FFADO users. In the 64 Studio project we have more flexibility to do things like that. Some background info here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/276463 What is true about this? Shouldn't plain Debian also support those Pro audio Firewire devices, the ones the FFADO team are making drivers for? Regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
why is Ardour pretty outdated in stable and not in testing? (was Re: Please Improve Debian for Multimedia Production)
Hi, Now we're talking about improving Debian for multimedia, realtime kernels and the like, I thought let's make some work on more things to overcome some dissadvantages of Debian for audio production compared to other distro's. Why is such a core app and also beautiful app as Ardour is, not even in Debian stable or testing? This is a big problem imo and it should be solved as soon as possible. I can't imagine that there is a real problem, cause I know the Ardour devs as people who respect GNU/GPL... I read this on the Debian multimedia mailinglist: EDR It's not a matter of debian developer laziness ... the ardour in sid EDR needs patches to _upstream_ libraries. If/when those upstream libraries EDR accept the patches the ardour devs need, then those libraries can get EDR into debian and ardour can use the debian packaged versions rather than EDR it's own forked versions. 100% agreed, ardour not in lenny is a Real Pity (TM). To recap happened: 0) the ardour package was built against some 3rd party libs shipped inside the upstream tarball, this raised an RC bug 1) that bug was around for a long time, there were no easy fix for that, but eventually all of the patches made it the 3rd party upstream projects, which in turned made it to si 2) I've fixed RC bug in ardour in version 2.7.1-2 http://packages.debian.org/changelogs/pool/main/a/ardour/ardour_2.7.1-2/changelog It was on Dec 18th, that means nearly 2 months before lenny got release. At this point ardour was RC-free BUT.. 3) It was depending on jackd 0.109.2, uploaded a few days before. Note that jack 0.109.2 was a very important release because it fixed important bugs in version 0.106, which had been around for almost one year. Unfortunately lenny was already freezed by that time, and although both of the above updates were really safe (IMO) and despite all the efforts I and especially Reinhard put into convincing the release managers, we are unable to convince them to accept the updates in lenny. I personally felt very disappointed by all this, especially considering that lenny got out *2* months later. ( http://www.mail-archive.com/debian-multime...@lists.debian.org/msg03163.html ) Please some reactions on this issue and I hope it can be solved! Would be great! :) Thanks in advance, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
Romain Beauxis to...@rastageeks.org writes: I have several very small ocaml packages waiting in NEW for several weeks now. I am upstream on these packages, and, honnestly, it takes few minutes to check them (only 3 files of code in tarball). There are currently 46 packages in NEW which have been there for more than one month, so your packages are still quite far in the queue. Fortunately, there is only one package which has been there for more than two months. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing? (was Re: Please Improve Debian for Multimedia Production)
On Wed, 2009-03-25 at 12:58 +0100, Grammostola Rosea wrote: Why is such a core app and also beautiful app as Ardour is, not even in Debian stable or testing? This is a big problem imo and it should be solved as soon as possible. I can't imagine that there is a real problem, cause I know the Ardour devs as people who respect GNU/GPL... Someone needs to make it build: https://buildd.debian.org/fetch.cgi?pkg=ardour;ver=1%3A2.7.1-2;arch=s390;stamp=1229659387 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
packages' config scripts creating files, chroots and buildds.
Hi, part of the debconf stuff in our packages is the config script. This script's purpose is to ask the sysadmin questions via debconf. The action should then happen in the postinst maintainer script. The way our buildds work right now is that the host apt and host dpkg are asked to install the packages in chroots, with appropriate flags that cause those programs to chroot[1]. Recently we changed all debian.org systems to have apt-utils installed. This package causes the apt/debconf/dpkg trinity to preconfigure packages, i.e. ask all those questions before the packages in question are actually starting to get installed. **This preconfiguring does not happen in the chroots, but in the host system.** So far we have identified at least two packages that do this: pbuilder and htdig. We found them by configuration being dumped on the / of several systems without DSA ever having those packages installed on those machines - the buildd installed them into a chroot. This raises some questions: - should config scripts be allowed to create/touch/modify files (I think the answer here is no) - it's probably broken to run the preconfiguring outside of the chroot, at least I see no way how it can possibly work with the config script updating the host's debconf database and the postinst reading from the chroot's debconf database. o Is the fact that the config script is run on the host a bug in apt-get, dpkg, debconf, or apt-utils? o Do the buildds just forgot a set of extra weird options? o Is this whole idea that you can cause apt-get and dpkg to act on a root other than / doomed to failure to begin with? - when will the buildds be changed to call the chroot tools? Cheers, weasel [mailfup2 d...@ldo] 1. e.g. Mar 24 16:33:59 peri sudo: buildd : TTY=unknown ; PWD=/home/buildd/build ; USER=root ; COMMAND=/usr/bin/apt-get --purge -o Dir::State::status=/home/buildd/build/chroot-unstable/var/lib/dpkg/status -o DPkg::Options::=--root=/home/buildd/build/chroot-unstable -o DPkg::Run-Directory=/home/buildd/build/chroot-unstable -o DPkg::Options::=--force-confold -q -y install cdbs quilt ffmpeg imagemagick kdelibs5-dev ladspa-sdk libavdevice-dev libavformat-dev libdv4-dev libgtk2.0-dev libjack-dev libquicktime-dev libsamplerate-dev libsdl1.2-dev libsox-dev libswscale-dev libvorbis-dev libxine-dev libxml2-dev -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: #520646: binNMU oprofile
On Wed, Mar 25, 2009 at 8:30 PM, Adeodato Simó wrote: I’m told libbfd.so is a private/internal library of binutils that should not be dynamically linked against. A static version exists (libbfd.a), and packages should be using that AFAIK. Cc'ing -devel in case there’s a reason it should not be that way. If, on the contrary, nobody objects, I’ll file a wishlist against lintian so that an error (warning?) is emitted for packages that DT_NEED that library (and libopcodes/libiberty as well?) Please ensure that the lintian warning says to get the package added to the Debian security team's embedded code copies documentation. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: #520646: binNMU oprofile
* Paul Wise [Wed, 25 Mar 2009 21:29:10 +0900]: On Wed, Mar 25, 2009 at 8:30 PM, Adeodato Simó wrote: I’m told libbfd.so is a private/internal library of binutils that should not be dynamically linked against. A static version exists (libbfd.a), and packages should be using that AFAIK. Cc'ing -devel in case there’s a reason it should not be that way. If, on the contrary, nobody objects, I’ll file a wishlist against lintian so that an error (warning?) is emitted for packages that DT_NEED that library (and libopcodes/libiberty as well?) Please ensure that the lintian warning says to get the package added to the Debian security team's embedded code copies documentation. A second idea came up in #debian-release; namely, making binutil’s shlibs file generate unsatisfiable dependencies, to signal that is not okay to dynamically link against those libraries. I’m putting the binutils maintainer on CC to see what he thinks about this idea. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
Grammostola Rosea rosea.grammost...@gmail.com writes: Shouldn't plain Debian also support those Pro audio Firewire devices, the ones the FFADO team are making drivers for? Debian as a whole probably not. However interested contributors are strongly encouraged to help the debian kernel maintainers to integrate that patchset to the kernel package. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
On Wed, 25 Mar 2009, Felipe Sateler wrote: Could you elaborate a bit? From what I gather (after reading the docs and skipping through the pages you have referenced), all I see are tasks (enhanced with metapackages with Recommends), and a nice web frontend. I'm pretty sure I'm missing something here. Perhaps some clarification is done below - if not, just ask again. If a person asked me that giving me the freedom to choose OS, I would be at a loss. For example, if somebody asked me: What should I install to get started in sound synthesis? (A more concrete example, and which I know best) I would not know what to say. There are big graphical sequencer and synth, like lmms, or graphical synths like puredata, or text synths, like csound or supercollider. Which one would be best? Install all of them? IME, people learn a program/language and stick to it. It's like trying to create a Software Development blend... it's just too broad and defined by personal preference, with no clear better packages. I think I understood your point. But to enable people developing their own taste they need to be informed what to choose from. It's like a restaurant where you choose from a menu. Currently we are lacking a complete multimedia menu in Debian. Well, sure the applications will be installed in the menu of your desktop if you if you installed the according package - but there is no central place to pick the packages which might be interesting. Just take me as a more or less multimedia ignorant person I would have a hard time to find out all the relevant packages for graphical sequencing so I'd be really glad if there would be a tasks page which assembles the short descriptions and links to the homepage of the projects to enable a quick overview. In how far it is different for instance to Debian Junior's puzzles page. There are a lot of nice puzzles in Debian and you will finally pick some favourites of them. So why not presenting a reasonable overview about what is there? sound-recording sound-playing video-recording video-playing image-editors image-viewers note-editors (for noteedit - no idea whether this is a reasonable category name) ... Although I wouldn't choose those tasks[1], Sure - I told you I'm uneducated about your work - one reason more for you to make the tasks better, right? but lets go over them to illustrate my point. What should we put into sound-recording? All of them? Yes. Why not? If there are bad ones which should not be Recommended or Suggested I wonder why they should hang around in Debian at all. The X more popular according to popcon? No. Adding popcon stats to the tasks files is in the upper quarter of my todo list. People can decide themselves whether they want to try a package with low or high popcon first. The ones I use? No. This contradicts your own arguing. Also, use cases overlap: I don't think there is a sound recorder that is not also a sound player. The overlap is no problem and I explained in detail for several Blends: We do not want to build an exclusive categorisation which might be hard to understand for our users. The important thing is to support our users. A specific user wants to solve a certain task (and thus installs a certain metapackage). The question whether some Dependencies are also mentioned in a different metapackage is completely useles for this task. So in fact we do *not* build a categorisation tree but build pools of useful software for certain tasks which can definitely have overlaps. To come back to your example: A user who is seeking for his optimal sound player is not served best if we hide an application from his view by including it into sound recorders exclusively. While chances might be good that a sound recorder is not as lightweight as a pure player the user will find out this quickly if he is looking for only a lightweight player - but perhaps he becomes happy later about the added value of his favourite player if it also is able to record sound. I think I have to include this into the Blends doc somewhere ... I agree that it makes sense, at least for some users. However, maintaining a Blend is (I assume) time consuming. It depends: Look for instance at the software page of the Debian Accessibility project[1]: This page existed for a long time (BTW, with Debian Med we started with something like that as well and learned that maintaining such static pages is really hard). They were a perfect preparation to enable me to generate the tasks files in 15 minutes and some further work was done by Samuel Thibault (who is actually member of the project) which all in all did not took him much more than the same time to add some new projects. The result can be seen here in the tasks[2] and bugs[3] pages. IMHO this time is quite well spend for the result that you gain the following advantages: 1. General overview over your work 2. Translations of the descriptions of the
Re: NEW processing
On Wed, 2009-03-25 at 12:32 +0100, Romain Beauxis wrote: My personal experience is not consistent with this. I have several very small ocaml packages waiting in NEW for several weeks now. I am upstream on these packages, and, honnestly, it takes few minutes to check them (only 3 files of code in tarball). On the other hand, I have been trying to move to the new libgavl for some times. Although I did make mistake in the copyright file, each round through NEW took me almost 2 months, which means that the transition is on-going since almost october or november. What would be stopping you from requesting a review from one or more of your peers of these packages before uploading them to NEW? These reviews would make it more likely that your packages had made it through NEW in one go, much reducing the time that you have to wait. In addition to that it would have reduced the number of packages the ftp-masters have to review, and so sped up the queue somewhat for everyone else. There seems to be an interest in reviewing things in NEW, but this is difficult due to NEW policies. Why not simply move the review to be before NEW? For example, post your packages that will have to go through NEW to debian-mentors@, requesting a NEW-like check, and upload when you are satisfied with the reviews that you have. This would achieve much the same effect, and not require changing the NEW policy, as the packages aren't being distributed on project machines. Yes, the extra few days would be a delay before getting in to NEW, but if you really care about that then upload to NEW at the same time as requesting the review, and then upload a fixed package if any problems are found. Thanks, James -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [dissenting]: Proposal: Enhance requirements for General resolutions
I was requested to forward the following mail by Sven Luther: - Forwarded message from Sven Luther s...@powerlinux.fr - From: Sven Luther s...@powerlinux.fr To: Gunnar Wolf gw...@gwolf.org, listmas...@debian.org Cc: Romain Beauxis to...@rastageeks.org, debian-devel@lists.debian.org, debian-v...@lists.debian.org Date: Wed, 25 Mar 2009 07:01:17 +0100 Subject: Re: [dissenting]: Proposal: Enhance requirements for General resolutions Message-ID: 20090325060117.ga19...@powerlinux.fr References: 87vdq3gcf6@vorlon.ganneff.de 2009035302.ga24...@yellowpig 200903240112.34470.to...@rastageeks.org 20090325035739.gf8...@cajita.gateway.2wire.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7-deb3 On Tue, Mar 24, 2009 at 09:57:39PM -0600, Gunnar Wolf wrote: Romain Beauxis dijo [Tue, Mar 24, 2009 at 01:12:34AM +0100]: Le Sunday 22 March 2009 23:53:02 Bill Allombert, vous avez écrit : Furthermore I am a Debian since 2001 and I see no evidence than the GR process was abused during that time. On the contrary, some GR were delayed to the point where it was inconvenient for the release process. I agree. I fail to see where the GR process was abused. Since that seems the main argument in favour of this change, I fail to see the motivation for it. This proposal does not come from an abuse to the GR process, but to generalized frustration about the way 2008_002 and specially 2008_003 were handled. But the reason for this are in no way related with the number of seconds, but rather in the way the debian project considers discussion consensus and such. It seems to me that most people see it more as a blood sport where everything is fine as long as his ideas win, than a process where there is respect for the ideas and convictions of others. In general, we should revisit the way we handle GRs, go away from the current process, where the first step of the vote is to make sure only ideas which have your support get on the ballot, instead of searching a ballot whose many options may give a chance of the voters to represent every possible opinion. I strongly believe that the amendment process is the one who is responsible for this issue. The current proposal is only a stop-gap way of trying to limit votes, and doesn't consider the real issue. Voluntarily not considering darker motives which come to mind when reading this proposal and seeing the position of the proposers. The proposers should keep in mind that this proposal can be interpreted in such a darker way given a certain degree of resentment of the project toward their high-handness, but that is another issue. In general, the GRs who turned the more disastrous (such as vorlon's solo firmware GR, bypassing the kernel team's reflexion on the subject) are often perceived as a way to force an opinion because one moves first, and is more vocal about it. Many of the votes are of the let's vote, and be done with it, we would much prefer to work on technical stuff category. We should modify the GR process to be something like : 1) Some DDs (5, 15, whatever) decide to have a vote about a topic. There is no actual text yet at this stage, just a topic, and the DDs have to give a motivation about why they want to have this topic voted on. 2) The main proposer of the vote is then made responsible of drafting a ballot, which will have enough orthogonal options to represent all the current of opinions in the project. To do this, he helds a discussion on -vote, whose objective is not to defend ones idea, but to make sure every current of ideas in debian is represented on the ballot. This step should be non confrontational, and not lead to wild debates. options should be added liberally, without the need of seconds, and are of the responsability of the proposer. The ballot options each should get a rationale and description as part of this process 3) Once the ballot is ready, the proposed ballot is posted on d-d-a or some other list reaching every developer, and a period of time (1 week ?) is set for people who missed step 2 to object to the ballot. During step 2 and 3, if the responsible of the vote proves stubborn, or refuses to add options, an appeal to the secretary, DPL or technical committee should be possible to avoid problems and couter-balance the power of the responsible of drafting the ballot. 4) if after the ballot scrutinization period, no objections where made, the ballot is put to vote. 5) a heated discussion period can be had to defend the different ballot opinions, but this heated discussion is not weaved with using amendmens to confuse the issue, or tentatives to subvert existing proposals by subtle modifications of the text by seemingly innocent amendmens quickly accepted by the original proposer. = This would allow us to : 1) have a trully representative ballot 2) limit the heated
Re: packages' config scripts creating files, chroots and buildds.
o Is the fact that the config script is run on the host a bug in
apt-get, dpkg, debconf, or apt-utils?
dpkg-preconfigure is part of the debconf package, and gets called using
the following configuration setting:
/etc/apt/apt.conf.d/70debconf:
DPkg::Pre-Install-Pkgs {/usr/sbin/dpkg-preconfigure --apt || true;};
This is called from apt (apt-pkg/deb/dpkgpm.cc), so it seems the failure
to run it in the chroot is there:
597: if (RunScriptsWithPkgs(DPkg::Pre-Install-Pkgs) == false)
RunScriptsWithPkgs (also in dpkgpm.cc) uses DPkg::Tools::Options::, so
maybe you can do something with that, although I doubt it as
dpkg-preconfigure itself does not have any options to make it run in a
different root.
o Is this whole idea that you can cause apt-get and dpkg to act on a
root other than / doomed to failure to begin with?
There may be some truth in that too :-)
At least, it sounds like this is not something that has been tested very
much and could have other issues.
HTH,
FJP
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Wed, Mar 25 2009, Lars Wirzenius wrote: ke, 2009-03-25 kello 01:32 +, Noah Slater kirjoitti: On Wed, Mar 25, 2009 at 12:39:46AM +, Steve McIntyre wrote: I'm curious... What do you think *is* the Debian way of doing things like this ? Manoj's email strongly implied that a DEP was needless bureaucracy. The recent memoranda about DEPs did lead me to believe that. However ... I'm hardly likely to argue with you about what constitutes the Debian way, but considering we've let a proposal stew on a wiki for over a year, have taken some discussion over to the mailing list and are now working on a DEP, I find it very confusing that it should be considered that we are somehow abusing the process. Speaking as one of the drivers of DEP0, I think you are misunderstanding how DEPs should be driven. They should not be used to control the discussion. They are, very fundamentally, a way to record consensus and the state of the discussion. As a by-product, they hopefully produce a document that will be useful later. If the people participating in a discussion have to be aware that something is discussed as part of a DEP, and have to adjust their behavior accordingly, the drivers have failed. This paragraph, and this one It's not very clearly written into DEP0, but it was always my intention, I and think Zack's and Dato's (that is, the people who came up with DEP in the first place), that the DEP process should introduce very low levels of bureucracy, and that _all_ the bureaucracy would be handled by the drivers. Indeed, as far as anyone else is concerned, the DEP might not even exist. make me view a DEP far more favourably. Using a process to track discussion, which does not impede said discussion, can only be positive. (Also, DEPs are hardly the established Debian way of doing things. There's only two accepted ones, and only six ones ever registered, counting DEP0 itself. I hope that DEPs will some day be accepted, but they won't be, if it's OK to use them as hitting implements.) +1 manoj -- The truth is rarely pure, and never simple. Oscar Wilde Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: packages' config scripts creating files, chroots and buildds.
On Wednesday 25 March 2009, Frans Pop wrote:
dpkg-preconfigure is part of the debconf package, and gets called using
the following configuration setting:
/etc/apt/apt.conf.d/70debconf:
DPkg::Pre-Install-Pkgs {/usr/sbin/dpkg-preconfigure --apt || true;};
You can probably just remove this though for your chroot installs.
The configuration will then be done during package installation, but I
guess that's noninteractive anyway.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [dissenting]: Proposal: Enhance requirements for General resolutions
Sven Luther dijo [Wed, Mar 25, 2009 at 07:01:17AM +0100]: This proposal does not come from an abuse to the GR process, but to generalized frustration about the way 2008_002 and specially 2008_003 were handled. But the reason for this are in no way related with the number of seconds, but rather in the way the debian project considers discussion consensus and such. It seems to me that most people see it more as a blood sport where everything is fine as long as his ideas win, than a process where there is respect for the ideas and convictions of others. I do believe we have moved quite a bit from this problem, which was way more real and bitter several years ago. Today, far more people are willing to tone down their discussion patterns, and the discussion quality is obviously thus improved. Sadly, I cannot but recognize the aggressive pattern as one in which you repeatedly incurred, and that led to your lamentable expulsion and this unique situation you call censorship. In general, we should revisit the way we handle GRs, go away from the current process, where the first step of the vote is to make sure only ideas which have your support get on the ballot, instead of searching a ballot whose many options may give a chance of the voters to represent every possible opinion. I strongly believe that the amendment process is the one who is responsible for this issue. (...) We should modify the GR process to be something like : 1) Some DDs (5, 15, whatever) decide to have a vote about a topic. There is no actual text yet at this stage, just a topic, and the DDs have to give a motivation about why they want to have this topic voted on. 2) The main proposer of the vote is then made responsible of drafting a ballot, which will have enough orthogonal options to represent all the current of opinions in the project. To do this, he helds a discussion on -vote, whose objective is not to defend ones idea, but to make sure every current of ideas in debian is represented on the ballot. This step should be non confrontational, and not lead to wild debates. options should be added liberally, without the need of seconds, and are of the responsability of the proposer. The ballot options each should get a rationale and description as part of this process 3) Once the ballot is ready, the proposed ballot is posted on d-d-a or some other list reaching every developer, and a period of time (1 week ?) is set for people who missed step 2 to object to the ballot. During step 2 and 3, if the responsible of the vote proves stubborn, or refuses to add options, an appeal to the secretary, DPL or technical committee should be possible to avoid problems and couter-balance the power of the responsible of drafting the ballot. (...) Umh... Although this somehow builds on the same premise than mine (separating the topic from the options/amendments), I do not believe it would lead to better results. The current process, where each amendment is proposed by different people, ensures all the ideas with enough backing will be represented in the ballot. If all options were submitted by a single person (even with the posterior review process you mention - There would be inertia against making subtle changes to an already submitted ballot), the options represented in it would come from a single person which holds a single opinion. Even if this is not a conscious process, and ahs the best intention from the submitter. Greetings, -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing? (was Re: Please Improve Debian for Multimedia Production)
Grammostola Rosea wrote: I read this on the Debian multimedia mailinglist: Unfortunately lenny was already freezed by that time, and although both of the above updates were really safe (IMO) and despite all the efforts I and especially Reinhard put into convincing the release managers, we are unable to convince them to accept the updates in lenny. I personally felt very disappointed by all this, especially considering that lenny got out *2* months later. Please some reactions on this issue and I hope it can be solved! Would be great! :) IMHO, the best thing to do in these cases is to prepare lenny backports of the packages... It is not as good as if the packages were in lenny, but it allows lenny users to easily install the packages without switching to testing or waiting for the next release. Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing? (was Re: Please Improve Debian for Multimedia Production)
2009/3/25 Julien Cristau jcris...@debian.org On Wed, 2009-03-25 at 12:58 +0100, Grammostola Rosea wrote: Why is such a core app and also beautiful app as Ardour is, not even in Debian stable or testing? This is a big problem imo and it should be solved as soon as possible. I can't imagine that there is a real problem, cause I know the Ardour devs as people who respect GNU/GPL... Someone needs to make it build: https://buildd.debian.org/fetch.cgi?pkg=ardour;ver=1%3A2.7.1-2;arch=s390;stamp=1229659387 Hi, new to the list and to the thread. I totally agree with Grammostola Rosea about the core app nature of ardour and everybody interested in multimedia production needs this pkg like a fish needs water to swim and, sooner or later, he will need a RT kernel. my dime r
Re: realtime kernel for Debian
On Wed, Mar 25, 2009 at 12:37:37PM +0100, Grammostola Rosea wrote: Why only in 64studio and not in plain Debian? What's good for Debian is good for us :-) but the Debian project may not want to tweak the kernel or the FireWire stack just for the benefit of FFADO users. In the 64 Studio project we have more flexibility to do things like that. Some background info here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/276463 What is true about this? Shouldn't plain Debian also support those Pro audio Firewire devices, the ones the FFADO team are making drivers for? It's easy: http://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Module_auto-loading Compile both modules and blacklist the new Juju modules. That's the current upstream recommendation. Even if the default will change around 2.6.30 (or later, I don't know the exact schedule), the FFADO users could still enable the old ieee1394 modules. We already have libraw1394-v2 in sid, but as outlined, FFADO currently only works with the old stack. This might also change in the future, especially if the Google Summer of Code project succeeds. (in-kernel alsa driver module for firewire audio) IOW: ship both stacks, decide for one and blacklist the other. FFADO users will then select the appropriate one. And of course, I'll continue looking into the FFADO-on-Juju issue. HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Alioth - Convert SVN repo to Git
On Tue, Mar 24, 2009 at 08:44:55PM +0100, sean finney wrote: On Tue, Mar 24, 2009 at 09:52:28AM -0700, Ryan Niebur wrote: find . -type f -name 'foo*.dsc' | sort (or similar tools, make sure they're sorted in a way as dpkg would sort the versions) | while read i; do git-import-dsc $i done git-import-dscs (note the extra s on the end) does exactly this. holy crap that's an awesome tool. i just tried this on a directory containing all the currently relevant php5 .dscs/.orig.tar.gzs/.diff.gzs and it did exactly what i would have hoped that it should do. i think that pkg-php will be switching to git much sooner than expected now :) For me, the main major blocker is the lack of upstream-master merges in the history. Given that we are importing all of the upstream, and all of the debian releases, merge conflicts have already been handled and so it should be possible to do this since we have all of the information to hand (see #506211). This means you can't commit a new upstream release to the upstream branch and this do a git merge upstream on the master branch until you do an initial merge of all the conflicts in the history to this point (which can be a huge amount of work). Given that both should have a common ancestor (the original upstream commit), if the initial import also does an upstream-master merge for each new upstream, prior to adding the debian changes, it would work wonderfully. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
Le Wed, Mar 25, 2009 at 12:39:12PM +0300, Kalle Kivimaa a écrit : Most of the REJECTs are very trivial, so any peer review helps to spot them. I'd say that 90% of the REJECTs are simple the package contains license X files but X isn't listed in debian/copyright. Spotting these before the package hits NEW speeds up the process a lot. Le Wed, Mar 25, 2009 at 12:32:23PM +0100, Romain Beauxis a écrit : I would strongly advertise a public collaborative license and copyright check. That is the kind of work that we could all do and report in the NEW queue. Le Wed, Mar 25, 2009 at 12:33:00PM +, James Westby a écrit : There seems to be an interest in reviewing things in NEW, but this is difficult due to NEW policies. Why not simply move the review to be before NEW? For example, post your packages that will have to go through NEW to debian-mentors@, requesting a NEW-like check, and upload when you are satisfied with the reviews that you have. Hi all, Here is a wiki page proposing two parallel workflows for pre- or post-upload peer review. http://wiki.debian.org/CopyrightReview Have a nice read :) -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521182: ITP: dans-gdal-scripts -- GINA contributed GDAL tools
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine fran...@debian.org * Package name: dans-gdal-scripts Version : 0.14 Upstream Author : Dan Stahlke * URL : http://www.gina.alaska.edu/projects/gina-tools * License : BSD Programming Lang: C++ Description : GINA contributed GDAL tools Dan Stahlke's GDAL contributed tools are a collection of useful tools to perform common geo raster operations. The included tools are: gdal_contrast_stretch, gdal_dem2rgb, gdal_get_projected_bounds, gdal_landsat_pansharpi, gdal_list_corners, gdal_merge_simple, gdal_merge_vrt gdal_raw2geotiff, gdal_trace_outline, gdal_wkt_to_mask. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Alioth - Convert SVN repo to Git
On Wed, Mar 25, 2009 at 02:13:42PM +, Roger Leigh rle...@codelibre.net wrote: On Tue, Mar 24, 2009 at 08:44:55PM +0100, sean finney wrote: On Tue, Mar 24, 2009 at 09:52:28AM -0700, Ryan Niebur wrote: find . -type f -name 'foo*.dsc' | sort (or similar tools, make sure they're sorted in a way as dpkg would sort the versions) | while read i; do git-import-dsc $i done git-import-dscs (note the extra s on the end) does exactly this. holy crap that's an awesome tool. i just tried this on a directory containing all the currently relevant php5 .dscs/.orig.tar.gzs/.diff.gzs and it did exactly what i would have hoped that it should do. i think that pkg-php will be switching to git much sooner than expected now :) For me, the main major blocker is the lack of upstream-master merges in the history. Given that we are importing all of the upstream, and all of the debian releases, merge conflicts have already been handled and so it should be possible to do this since we have all of the information to hand (see #506211). This means you can't commit a new upstream release to the upstream branch and this do a git merge upstream on the master branch until you do an initial merge of all the conflicts in the history to this point (which can be a huge amount of work). Given that both should have a common ancestor (the original upstream commit), if the initial import also does an upstream-master merge for each new upstream, prior to adding the debian changes, it would work wonderfully. You don't need to do that on initial import. You can use a grafts file to create the history you like from these 2 unrelated branches, and you can then use git filter-branch to rewrite the master branch to have the commits rewritten to use this grafted history (then you can remove the grafts file). Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: packages' config scripts creating files, chroots and buildds.
On Wed, Mar 25, 2009 at 01:18:20PM +0100, Peter Palfrader wrote: This raises some questions: It might also explain why someone found sbuild-createchroot was running apt-get upgrade on the host system. - should config scripts be allowed to create/touch/modify files (I think the answer here is no) - it's probably broken to run the preconfiguring outside of the chroot, at least I see no way how it can possibly work with the config script updating the host's debconf database and the postinst reading from the chroot's debconf database. This looks like the tools are not respecting the APT and/or dpkg options to use the alternate root (and configuration). They need fixing. o Is the fact that the config script is run on the host a bug in apt-get, dpkg, debconf, or apt-utils? I'm unsure. If it's invoked by dpkg, it should be run inside the chroot, surely? If it's not apt or dpkg, or a closely-related helper tool that is obeying the same environment or command-line options, then it shouldn't be being run on the host. o Is this whole idea that you can cause apt-get and dpkg to act on a root other than / doomed to failure to begin with? I don't think so. We have been using apt and dpkg in this way for years, with only the occasional hiccup. If this is brokenness in just one tool, we should IMO just fix it. - when will the buildds be changed to call the chroot tools? I don't know, but it's certainly possible to do so. This is a trivial change. Just set $chroot_split=0 in sbuild.conf, and everything happens inside. However, it does require working networking support inside the chroot, or else you can't fetch packages and sources; this has previously not been done for several reasons, including preventing autobuilt packages from downloading anything not in the original source packages. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Amendment] Reaffirm the GR process
Kurt Roeckx wrote: What about: General Resolution sponsorship requirements sounds like package sponsorship requirements to me. therefore i suggest to be extra clear and change it to 'Requirements for General Resolution Sponsorship'. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
On Wed, Mar 25, 2009 at 06:18:00PM +0900, Changwoo Ryu wrote: 2009-03-25 (???), 16:55 +0800, Deng Xiyue: IMHO, except package with just SONAME bump, packages in NEW queue are better processed in a FIFO manner. Just my two cents. OTH, do we really need a manual check for SONAME bump? Was there any upload rejection in the past on new binary package addition cases? Yes, there have definately been times when packages are rejected from NEW that only got there becuase of a package addition. I'd say its common, even. If a package passes through new, then the maintainer uploads without really paying attention to what they are uploading, upstream licensing may have changed, making the package no longer acceptable. Or the package might have passed NEW in the past when it really shoudln't have. stew signature.asc Description: Digital signature
Re: NEW processing
On Wed, Mar 25, 2009 at 12:32:23PM +0100, Romain Beauxis wrote: I have several very small ocaml packages waiting in NEW for several weeks now. I am upstream on these packages, and, honnestly, it takes few minutes to check them (only 3 files of code in tarball). Of course, keep in mind, we wouldn't know that the package only has 3 files until we check. On the other hand, I have been trying to move to the new libgavl for some times. Although I did make mistake in the copyright file, each round through NEW took me almost 2 months, which means that the transition is on-going since almost october or november. As a hint. When this happens, respond to the REJECT email you get when you re-upload so that we know that there is a package we have already checked, so that we know you are re-uploading and addressing our concerns. However, if like 3 DDs claim they have reviewed the package's license and that eveythying is like GPL, along with a subjective views on the complexity of the package's check, then the work should be much more faster afterward. Knowing that 3 other DDs have checked a package doesn't change our work at all, unless that reduces the number of uploads. If a package has been uploaded that 3 other DDs have signed off on, we are still going to do the same checking that we would on a package that didn't have such a review. This is not to say that I wouldn't welcome such a thing. I'd hope that many of the packages we see wouldn't be uploaded if more people were looking at them before they were uploaded. stew signature.asc Description: Digital signature
Re: NEW processing
Mike O'Connor s...@debian.org (25/03/2009): Yes, there have definately been times when packages are rejected from NEW that only got there becuase of a package addition. I'd say its common, even. If a package passes through new, then the maintainer uploads without really paying attention to what they are uploading, upstream licensing may have changed, making the package no longer acceptable. Or the package might have passed NEW in the past when it really shoudln't have. And while the new package is kept out, the package currently in the archive might not be suitable at all. In the case of a single binary addition, that would mean as many RC bugs as REJECTED packages, don't you think? I might have missed some, but I haven't followed -bugs-rc closely last weeks, I must confess. Mraw, KiBi. signature.asc Description: Digital signature
Re: NEW processing
Le Wednesday 25 March 2009 16:18:46 Mike O'Connor, vous avez écrit : I have several very small ocaml packages waiting in NEW for several weeks now. I am upstream on these packages, and, honnestly, it takes few minutes to check them (only 3 files of code in tarball). Of course, keep in mind, we wouldn't know that the package only has 3 files until we check. (...) However, if like 3 DDs claim they have reviewed the package's license and that eveythying is like GPL, along with a subjective views on the complexity of the package's check, then the work should be much more faster afterward. Knowing that 3 other DDs have checked a package doesn't change our work at all, unless that reduces the number of uploads. Well, for instance, you would know when a review is going to take time or not. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
On 2009-03-25, Mike O'Connor s...@debian.org wrote: As a hint. When this happens, respond to the REJECT email you get when you re-upload so that we know that there is a package we have already checked, so that we know you are re-uploading and addressing our concerns. If you want this, please be more public about it, for example in teh rejection email. I'm pretty sure that most people would love to help you this way. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
On Wed, Mar 25, 2009 at 04:24:59PM +0100, Cyril Brulebois wrote: Mike O'Connor s...@debian.org (25/03/2009): Yes, there have definately been times when packages are rejected from NEW that only got there becuase of a package addition. I'd say its common, even. If a package passes through new, then the maintainer uploads without really paying attention to what they are uploading, upstream licensing may have changed, making the package no longer acceptable. Or the package might have passed NEW in the past when it really shoudln't have. And while the new package is kept out, the package currently in the archive might not be suitable at all. In the case of a single binary addition, that would mean as many RC bugs as REJECTED packages, don't you think? yes, usually it should. It doesn't always. I have tried to file bugs when I find them in the archive. The citadel related packages are a recent example of this. Unfortunately they don't always get filed. In my mind it would be better if the maintainers were to do this, seeing as it is evendenced by threads like this, we are having trouble keeping up with the NEW queue wihtout doing all of the source checks of packages not in the queue as you seem to be suggesting we should possibly be doing. stew signature.asc Description: Digital signature
Re: [dissenting]: Proposal: Enhance requirements for General resolutions
Romain Beauxis to...@rastageeks.org writes: Le Wednesday 25 March 2009 04:57:39 Gunnar Wolf, vous avez écrit : This proposal does not come from an abuse to the GR process, but to generalized frustration about the way 2008_002 and specially 2008_003 were handled. I understand the furstration about them, but I don't think that the number of seconders was the reasons for the abuse. There was clearly a need for those GR, so raisong the number of seconders would just have the consequence to prevent us from voting on important topics. FWIW, it is not at all clear to me that there was any need for either of those GRs (particularly 2008_002, which did indeed strike me as a waste of the GR process). Note that the effective conclusion of both of those GRs was to do what was happening anyway and would have happened without the GRs, apart from the secondary effects of making the whole thing more confrontational. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: packages' config scripts creating files, chroots and buildds.
Peter Palfrader wea...@debian.org writes: This raises some questions: - should config scripts be allowed to create/touch/modify files (I think the answer here is no) debconf-devel(7): The config script should not need to modify the filesystem at all. It just examines the state of the system, and asks questions, and debconf stores the answers to be acted on later by the postinst script. Conversely, the postinst script should almost never use debconf to ask questions, but should instead act on the answers to questions asked by the config script. Personally, my first instinct would be to call that an RC bug, but I may be missing some case where config needs to modify the file system. However, if config is being called outside of the chroot, it's also updating the wrong debconf database, no? So the rest of the problem does also need to be fixed regardless of whether we fix the packages. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [dissenting]: Proposal: Enhance requirements for General resolutions
Le Wednesday 25 March 2009 16:45:59 Russ Allbery, vous avez écrit : There was clearly a need for those GR, so raisong the number of seconders would just have the consequence to prevent us from voting on important topics. FWIW, it is not at all clear to me that there was any need for either of those GRs (particularly 2008_002, which did indeed strike me as a waste of the GR process). Well, even if I would agree with you, apparently this GR had 21 supporters.. Far from the idea of some abuse from a small number of developpers. So clearly, this proposition would not even solve this issue. Note that the effective conclusion of both of those GRs was to do what was happening anyway and would have happened without the GRs, apart from the secondary effects of making the whole thing more confrontational. For 2008_002 in particular, there was a clear need of such a decision, since the previous announce had been made as if it was about to happen while there was apprently no consensus for it. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
On Wed, Mar 25, 2009 at 11:44:19AM -0400, Mike O'Connor wrote: yes, usually it should. It doesn't always. I have tried to file bugs when I find them in the archive. The citadel related packages are a recent example of this. Unfortunately they don't always get filed. In my mind it would be better if the maintainers were to do this, seeing as it is evendenced by threads like this, we are having trouble keeping up with the NEW queue wihtout doing all of the source checks of packages not in the queue as you seem to be suggesting we should possibly be doing. Can you comment on why citadel was not immediately removed from Debian if it merited a REJECT? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
2009-03-25 (수), 11:13 -0400, Mike O'Connor:
On Wed, Mar 25, 2009 at 06:18:00PM +0900, Changwoo Ryu wrote:
OTH, do we really need a manual check for SONAME bump? Was there any
upload rejection in the past on new binary package addition cases?
Yes, there have definately been times when packages are rejected from
NEW that only got there becuase of a package addition. I'd say its
common, even. If a package passes through new, then the maintainer
uploads without really paying attention to what they are uploading,
upstream licensing may have changed, making the package no longer
acceptable. Or the package might have passed NEW in the past when it
really shoudln't have.
Such mistakes can always happen, even by usual package upgrade with no
NEW check. But we are distributing those buggy updated packages and
fixing such bugs over time. I doubt new binary package (SONAME bumps,
-{doc,data} package splitting, etc) introduces such bugs more often than
usual upload.
--
Changwoo Ryu cw...@debian.org
signature.asc
Description: This is a digitally signed message part
Re: [dissenting]: Proposal: Enhance requirements for General resolutions
Romain Beauxis to...@rastageeks.org writes: Le Wednesday 25 March 2009 16:45:59 Russ Allbery, vous avez écrit : FWIW, it is not at all clear to me that there was any need for either of those GRs (particularly 2008_002, which did indeed strike me as a waste of the GR process). Well, even if I would agree with you, apparently this GR had 21 supporters.. Far from the idea of some abuse from a small number of developpers. So clearly, this proposition would not even solve this issue. Sure. Thus proving that this proposal isn't raising the seconding requirement too high. :) Note that the effective conclusion of both of those GRs was to do what was happening anyway and would have happened without the GRs, apart from the secondary effects of making the whole thing more confrontational. For 2008_002 in particular, there was a clear need of such a decision, since the previous announce had been made as if it was about to happen while there was apprently no consensus for it. There was a clear need for a clarification. Why we had to vote on the clarification after Ganneff made it clear that it wasn't his intent to implement prior to consensus is still highly perplexing to me. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
Mike O'Connor s...@debian.org (25/03/2009): [...] we are having trouble keeping up with the NEW queue wihtout doing all of the source checks of packages not in the queue as you seem to be suggesting we should possibly be doing. Actually, that's not what I meant to suggest. :) I've been wondering for a while whether to add a binary package (a debug one) to one of mine. A possible question is: will an RC bug be opened against the current package if the NEW one gets REJECTED for missing licenses? If that's the case, fine. We're going to fix those horrible licensing issues we have in the archive as soon as a binary package is added. But that can also mean one will refrain from adding binary packages because one is lazy/doesn't have time to check licenses etc. If that's not the case, one might be tempted to try and sneak a new binary package through NEW, without worrying about the consequences (a possible RC bug). And since I'm all for full disclosure, try the following and guess why there's no blender-dbg package yet: $ apt-get source blender ls -d blender-*/extern/*/ (To be discharge, I'm already fighthing against embedded code copies and with time, things are getting better, but I'm not done yet.) To sum up: that was a real question, I didn't mean to point fingers. Mraw, KiBi. signature.asc Description: Digital signature
Re: NEW processing
On Wed, Mar 25, 2009 at 04:24:59PM +0100, Cyril Brulebois wrote: Mike O'Connor s...@debian.org (25/03/2009): Yes, there have definately been times when packages are rejected from NEW that only got there becuase of a package addition. I'd say its ... And while the new package is kept out, the package currently in the archive might not be suitable at all. In the case of a single binary Or the package staying in the archive might even have a security problem. Yes, even that happened. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: packages' config scripts creating files, chroots and buildds.
On Wed, Mar 25, 2009 at 08:50:29AM -0700, Russ Allbery wrote: Personally, my first instinct would be to call that an RC bug, but I may be missing some case where config needs to modify the file system. Given that one of the original goals of all this was to allow the config to be done on a different system to the one the package is being installed on I'd expect not. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [dissenting]: Proposal: Enhance requirements for General resolutions
Lucas Nussbaum lu...@lucas-nussbaum.net writes: On 25/03/09 at 09:06 -0700, Russ Allbery wrote: There was a clear need for a clarification. Why we had to vote on the clarification after Ganneff made it clear that it wasn't his intent to implement prior to consensus is still highly perplexing to me. Joerg Jaspert never made it perfectly clear that he would not implement anything before consensus. I repeatedly asked him to publicly say that (saying that I would withdraw my amendments if he did), but he never answered. Hm. Well, that wasn't the impression I had at the time, but I have no particular grounds for thinking that you're mistaken and I'm right versus the other way around. I didn't really mean to re-open this (not that you could tell from my original message -- sorry about that) so much as to note that I think we vote a lot on things where it's unclear to me that a GR is the way to address the problem, versus talking about it more. The reason why this proposal is appealing to me is that I'd rather not see GRs be used as a stick with which to beat people, and if it's much harder to get one voted on, I think they may be less common as an early recourse in a discussion that isn't going one's way. I like MJ's proposal for making the change in the required number of seconds expire automatically if we end up having no GRs at all, though. It does seem likely that within a year (or maybe two; I'm not sure which timeframe makes the most sense) there will be *something* that warrants a vote. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [dissenting]: Proposal: Enhance requirements for General resolutions
On 25/03/09 at 09:06 -0700, Russ Allbery wrote: Romain Beauxis to...@rastageeks.org writes: For 2008_002 in particular, there was a clear need of such a decision, since the previous announce had been made as if it was about to happen while there was apprently no consensus for it. There was a clear need for a clarification. Why we had to vote on the clarification after Ganneff made it clear that it wasn't his intent to implement prior to consensus is still highly perplexing to me. Joerg Jaspert never made it perfectly clear that he would not implement anything before consensus. I repeatedly asked him to publicly say that (saying that I would withdraw my amendments if he did), but he never answered. -- | 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: Architecture usertags
On Wed, Mar 25, 2009 at 05:30:19PM +0100, Wouter Verhelst wrote: Hi, I thought I'd sent out this mail, but apparently I did that when I had just reinstalled my laptop and the mailsetup wasn't working yet. Sorry about that. Now almost a month ago, I asked Don Armstrong to create architecture tags in the BTS. I've always felt that such a thing would be useful, because often porters are unaware of architecture-specific bugs, simply because there's no way in the BTS to actually search for them. Having such an ability could make porters of a particular architecture aware of the issues that affect their architecture, and (where necessary) able to help out. Don suggested using usertags instead, since it is the policy of the maintainers of the BTS to not create new 'regular' tags anymore unless a usertag is in common use already. That's fine with me, but it has one tiny little problem: if people are unaware of the usertag, they cannot add it to their bugs, thereby defeating the purpose of this whole exercise (allowing porters to find architecture-specific bugs that they are unaware of). This mail is to remedy that one tiny little problem. I made a small proposal on the debian porters' mailinglists, which did not encounter any resistance (apart from the fact that some architectures already have a (set of) usertags that they use). It is as follows: - The user to an architecture usertag should be the porters' mailinglist for that particular architecture. That is, debian-powe...@lists.debian.org for powerpc-related bugs, debian-ar...@lists.debian.org for arm and armel-related bugs, and so on. - The usertag should be the name of the architecture: m68k for m68k, powerpc for powerpc, hurd-i386 for hurd-i386, and so on (that's not hard, is it? ;-) I made a short overview of this on the wiki, at http://wiki.debian.org/Teams/Debbugs/ArchchitectureTags Got an extra ch in there? (with permission from Don to write something in the /Teams/Debbugs namespace) Maintainers are hereby encouraged to use these usertags on any architecture-specific bugs they might have on their packages. -- dann frazier -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 10:37 AM, Kel Modderman k...@otaku42.de wrote: On Wednesday 25 March 2009 17:51:41 Luis R. Rodriguez wrote: On Wed, Mar 25, 2009 at 12:47 AM, Luis R. Rodriguez mcg...@gmail.com wrote: On Wed, Mar 25, 2009 at 12:39 AM, Paul Wise p...@debian.org wrote: On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature What is the percieved DFSG/RSA conflict? I can't detect any based on that section of the page. Thanks Paul, then its just a matter of packaging. There is an debian-example/ directory with a cdbs example of how to package for wireless-regdb and crda if anyone is up for it. The example packaging needs some love, I think. I don't see it as a great reference to the eventual packaging material that would enter Debian. And as its probably best to coordinate with Ubuntu, they have a wireless-crda package which combines both into one package. Its shipping for Jaunty. And that's the only way to sanely package it (by combining the two pieces upstream splits) as show by Fedora also choosing that route. Well I actually disagree. Luis why can't CRDA and regd simply be released in same tarball considering they have such a strong relationship with eachother due to the openssl stuff? Openssl stuff is optional and in fact not the lib chosen by default, libgcrypt is the default though. The point is that crda won't be updated regularly but the wireless-regdb will be. No point in updating a binary when only the file it reads is the one that changes. Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wednesday 25 March 2009 17:39:03 Paul Wise wrote: On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature What is the percieved DFSG/RSA conflict? I can't detect any based on that section of the page. Hi Paul, By default the upstream wireless-regdb tarball contains and installs a pre-built wireless regulatory information binary signed by John Linville's openssl snakeoil. It is my understanding that in Debian we would prefer to build the binary from its source code. That presents a problem because CRDA expects to see John Linville's openssl stuff. One way to work around this is to munge CRDA and regdb together, generate our own openssl stuff and build CRDA and wireless-redb at the same time. Another way to go is to do away with the openssl stuff during build altogether, but Luis doesn't like that, and the build system's need patching to support it last time I checked. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
Michael Meskes wrote: On Wed, Mar 25, 2009 at 04:24:59PM +0100, Cyril Brulebois wrote: Mike O'Connor s...@debian.org (25/03/2009): Yes, there have definately been times when packages are rejected from NEW that only got there becuase of a package addition. I'd say its ... And while the new package is kept out, the package currently in the archive might not be suitable at all. In the case of a single binary Or the package staying in the archive might even have a security problem. Yes, even that happened. Well, it's a bad sign that people are mixing the fixing of RC/security bugs with new (binary) packages unless the bugs cannot be fixed without them (which usually is *not* the case). Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wednesday 25 March 2009 17:51:41 Luis R. Rodriguez wrote: On Wed, Mar 25, 2009 at 12:47 AM, Luis R. Rodriguez mcg...@gmail.com wrote: On Wed, Mar 25, 2009 at 12:39 AM, Paul Wise p...@debian.org wrote: On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature What is the percieved DFSG/RSA conflict? I can't detect any based on that section of the page. Thanks Paul, then its just a matter of packaging. There is an debian-example/ directory with a cdbs example of how to package for wireless-regdb and crda if anyone is up for it. The example packaging needs some love, I think. I don't see it as a great reference to the eventual packaging material that would enter Debian. And as its probably best to coordinate with Ubuntu, they have a wireless-crda package which combines both into one package. Its shipping for Jaunty. And that's the only way to sanely package it (by combining the two pieces upstream splits) as show by Fedora also choosing that route. Luis why can't CRDA and regd simply be released in same tarball considering they have such a strong relationship with eachother due to the openssl stuff? Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Architecture usertags
Wouter Verhelst wrote: Hi, Hi I thought I'd sent out this mail, but apparently I did that when I had just reinstalled my laptop and the mailsetup wasn't working yet. Sorry about that. Now almost a month ago, I asked Don Armstrong to create architecture tags in the BTS. I've always felt that such a thing would be useful, because often porters are unaware of architecture-specific bugs, simply because there's no way in the BTS to actually search for them. Having such an ability could make porters of a particular architecture aware of the issues that affect their architecture, and (where necessary) able to help out. Note that porters can find many issues just by looking at the buildd.d.o [0] pages even for issues not (yet) known in the BTS for which they could file bugs. Cheers Luk [0] http://buildd.debian.org/~luk/status/architecture.php?suite=unstablea=alpha -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Thu, 2009-03-26 at 03:37 +1000, Kel Modderman wrote: And as its probably best to coordinate with Ubuntu, they have a wireless-crda package which combines both into one package. Its shipping for Jaunty. And that's the only way to sanely package it (by combining the two pieces upstream splits) as show by Fedora also choosing that route. Luis why can't CRDA and regd simply be released in same tarball considering they have such a strong relationship with eachother due to the openssl stuff? I thought regdb was supposed to be a candidate for volatile. johannes signature.asc Description: This is a digitally signed message part
Re: NEW processing
Luk Claes l...@debian.org (25/03/2009): Michael Meskes wrote: On Wed, Mar 25, 2009 at 04:24:59PM +0100, Cyril Brulebois wrote: And while the new package is kept out, the package currently in the archive might not be suitable at all. In the case of a single binary ^^^ Or the package staying in the archive might even have a security problem. Yes, even that happened. Well, it's a bad sign that people are mixing the fixing of RC/security bugs with new (binary) packages unless the bugs cannot be fixed without them (which usually is *not* the case). Just to clarify my initial thought, I was talking about RC-bugginess due to possible license/copyright issues, those which would warrant a REJECT. Mraw, KiBi. signature.asc Description: Digital signature
Re: NEW processing
On Wed, Mar 25, 2009 at 03:57:49PM +, Clint Adams wrote: On Wed, Mar 25, 2009 at 11:44:19AM -0400, Mike O'Connor wrote: yes, usually it should. It doesn't always. I have tried to file bugs when I find them in the archive. The citadel related packages are a recent example of this. Unfortunately they don't always get filed. In my mind it would be better if the maintainers were to do this, seeing as it is evendenced by threads like this, we are having trouble keeping up with the NEW queue wihtout doing all of the source checks of packages not in the queue as you seem to be suggesting we should possibly be doing. Can you comment on why citadel was not immediately removed from Debian if it merited a REJECT? I cannot. I can say that I opened RC bugs and made sure others from the FTP team and from Release and Stable Release were aware of exactly what was happening. The uploader was upstream, so upstream was being made aware as well. Would you recommend that we remove packages from stable when this happens? stew signature.asc Description: Digital signature
Re: Architecture usertags
Bastien ROUCARIES wrote: On Wed, Mar 25, 2009 at 7:03 PM, Luk Claes l...@debian.org wrote: Wouter Verhelst wrote: Hi, Hi I thought I'd sent out this mail, but apparently I did that when I had just reinstalled my laptop and the mailsetup wasn't working yet. Sorry about that. Now almost a month ago, I asked Don Armstrong to create architecture tags in the BTS. I've always felt that such a thing would be useful, because often porters are unaware of architecture-specific bugs, simply because there's no way in the BTS to actually search for them. Having such an ability could make porters of a particular architecture aware of the issues that affect their architecture, and (where necessary) able to help out. Note that porters can find many issues just by looking at the buildd.d.o [0] pages even for issues not (yet) known in the BTS for which they could file bugs. Sometimes bug are arch specific. For instance a recent bug in librsvg was due to a floatting point rounding. Under sparc the bug produce a divide by zero, whereas under i386 it work normally. So arch tags are useful. Sure, though expecting them to be up-to-date not unless there will be enough people going to look at the build pages and tagging bugs accordingly AFAICS. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Thursday 26 March 2009 03:41:30 Luis R. Rodriguez wrote: On Wed, Mar 25, 2009 at 10:37 AM, Kel Modderman k...@otaku42.de wrote: On Wednesday 25 March 2009 17:51:41 Luis R. Rodriguez wrote: On Wed, Mar 25, 2009 at 12:47 AM, Luis R. Rodriguez mcg...@gmail.com wrote: On Wed, Mar 25, 2009 at 12:39 AM, Paul Wise p...@debian.org wrote: On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature What is the percieved DFSG/RSA conflict? I can't detect any based on that section of the page. Thanks Paul, then its just a matter of packaging. There is an debian-example/ directory with a cdbs example of how to package for wireless-regdb and crda if anyone is up for it. The example packaging needs some love, I think. I don't see it as a great reference to the eventual packaging material that would enter Debian. And as its probably best to coordinate with Ubuntu, they have a wireless-crda package which combines both into one package. Its shipping for Jaunty. And that's the only way to sanely package it (by combining the two pieces upstream splits) as show by Fedora also choosing that route. Well I actually disagree. The DFSG seems to suggest that the source code to the regulatory database should be modifiable and the derived work distributed under the same license. For our possible, and resonsible, modifications to take effect we need to build the regulatory database from source, not install the prebuilt/presigned one. The building of Debian packages is mostly done in anonymous build chroot's without access to personal cryptography information. How can the CRDA and wireless-regdb binaries both be built from source separately and share the same cryptographic information with these restrictions? (only then would debian-volatile be an option for regdb afaiu) Maybe the debian-kernel team should be contacted more directly, as it is ultimately them who need to make a decision about CONFIG_WIRELESS_OLD_REGULATORY ? Thanks, Kel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Architecture usertags
On Wed, Mar 25, 2009 at 7:03 PM, Luk Claes l...@debian.org wrote: Wouter Verhelst wrote: Hi, Hi I thought I'd sent out this mail, but apparently I did that when I had just reinstalled my laptop and the mailsetup wasn't working yet. Sorry about that. Now almost a month ago, I asked Don Armstrong to create architecture tags in the BTS. I've always felt that such a thing would be useful, because often porters are unaware of architecture-specific bugs, simply because there's no way in the BTS to actually search for them. Having such an ability could make porters of a particular architecture aware of the issues that affect their architecture, and (where necessary) able to help out. Note that porters can find many issues just by looking at the buildd.d.o [0] pages even for issues not (yet) known in the BTS for which they could file bugs. Sometimes bug are arch specific. For instance a recent bug in librsvg was due to a floatting point rounding. Under sparc the bug produce a divide by zero, whereas under i386 it work normally. So arch tags are useful. Regards Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Thu, Mar 26, 2009 at 3:42 AM, Kel Modderman k...@otaku42.de wrote: The DFSG seems to suggest that the source code to the regulatory database should be modifiable and the derived work distributed under the same license. It is my understanding that: Debian probably won't need to build the regdb from source most of the time so we can just ship the upstream regulatory.bin file most of the time. When we do, just adding a second public key to the CRDA pubkeys dir and using the corresponding private key (from outside the package) during the build process of wireless-regdb would be just fine. This would mean the maintainer of crda would also have to be the wireless-regdb maintainer. I assume the wireless-regdb is architecture-independent so this would work because the buildds do not build such packages. It is possible for users to add more public keys to the CRDA pubkeys dir and build their own wireless-regdb using their own private key. debian-volatile isn't an appropriate place for this because many stable users don't use volatile and it is fairly important they are kept up to date with this, kinda like the timezone database. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
On Wed, Mar 25, 2009 at 02:32:19PM -0400, Mike O'Connor wrote: I cannot. I can say that I opened RC bugs and made sure others from the FTP team and from Release and Stable Release were aware of exactly what was happening. The uploader was upstream, so upstream was being made aware as well. Would you recommend that we remove packages from stable when this happens? Yes, I would say that if the problem is so severe that a package must be REJECTed, then logically it would follow that the packages in the archive are intolerable enough that they should be removed forthwith. I'm curious about how others reconcile not doing so. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Thu, Mar 26, 2009 at 03:45:30AM +1000, Kel Modderman wrote: On Wednesday 25 March 2009 17:39:03 Paul Wise wrote: On Wed, Mar 25, 2009 at 4:09 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Last time I poked them it seemed it was not easy to figure out how to deal with, if at all, the optional but recommended RSA signature stuff [1] with the DFSG. [1] http://wireless.kernel.org/en/developers/Regulatory#RSADigitalSignature What is the percieved DFSG/RSA conflict? I can't detect any based on that section of the page. Hi Paul, By default the upstream wireless-regdb tarball contains and installs a pre-built wireless regulatory information binary signed by John Linville's openssl snakeoil. It is my understanding that in Debian we would prefer to build the binary from its source code. That presents a problem because CRDA expects to see John Linville's openssl stuff. One way to work around this is to munge CRDA and regdb together, generate our own openssl stuff and build CRDA and wireless-redb at the same time. Another way to go is to do away with the openssl stuff during build altogether, but Luis doesn't like that, and the build system's need patching to support it last time I checked. You could also patch-in support for your own signing key, provided that would comply with whatever policies Debian has about signing keys. Hth... John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: packages' config scripts creating files, chroots and buildds.
Russ Allbery wrote: debconf-devel(7): The config script should not need to modify the filesystem at all. It just examines the state of the system, and asks questions, and debconf stores the answers to be acted on later by the postinst script. Conversely, the postinst script should almost never use debconf to ask questions, but should instead act on the answers to questions asked by the config script. I totally missed this aspect of the original mail. Personally, my first instinct would be to call that an RC bug, but I may be missing some case where config needs to modify the file system. It certainly looks as if it's at least not how the system is intended to be used. But I don't think it's worded strongly enough to warrant RC bugs. Of course dpkg-reconfigure will still need to be run in the chroot as it does need to be able to _read_ the existing config to determine current settings. After all, debconf is not a registry. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Thu, 26 Mar 2009, Paul Wise wrote: debian-volatile isn't an appropriate place for this because many stable users don't use volatile and it is fairly important they are kept up to date with this, kinda like the timezone database. AFAIK, volatile.d.o _is_ the proper way to keep the timezone database up-to-date. What we can do is checkpoint volatile (either all of it, or selected parts of it) into all minor stable releases, for those with setups that don't get updates from volatile. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing?
Vincent Danjean wrote: Grammostola Rosea wrote: I read this on the Debian multimedia mailinglist: Unfortunately lenny was already freezed by that time, and although both of the above updates were really safe (IMO) and despite all the efforts I and especially Reinhard put into convincing the release managers, we are unable to convince them to accept the updates in lenny. I personally felt very disappointed by all this, especially considering that lenny got out *2* months later. Please some reactions on this issue and I hope it can be solved! Would be great! :) IMHO, the best thing to do in these cases is to prepare lenny backports of the packages... It is not as good as if the packages were in lenny, but it allows lenny users to easily install the packages without switching to testing or waiting for the next release. Free (Debian Multimedia member), Could you comment on this? I think it's the best when Ardour will hit Lenny. Second option is as a Lenny backport. Btw. why doesn't Ardour from unstable hit testing? This is normal for packages in Sid after some time right? Now there is no Ardour in stable AND testing. Thanks in advance, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
taste they need to be informed what to choose from. It's like a restaurant where you choose from a menu. Currently we are lacking a complete multimedia menu in Debian. An menu entry for multimedia sounds good to me (Ubuntu has an menu entry for 'multimedia production: - music production - video production (or something close to that). This is good imo because audio apps are a lot small apps which clutter up in the menu now. Well, sure the applications will be installed in the menu of your desktop if you if you installed the according package - but there is no central place to pick the packages which might be interesting. Just take me as a more or less multimedia ignorant person I would have a hard time to find out all the relevant packages for graphical sequencing so I'd be really glad if there would be a tasks page which assembles the short descriptions and links to the homepage of the projects to enable a quick overview. In how far it is different for instance to Debian Junior's puzzles page. There are a lot of nice puzzles in Debian and you will finally pick some favourites of them. So why not presenting a reasonable overview about what is there? sound-recording sound-playing video-recording video-playing image-editors image-viewers note-editors (for noteedit - no idea whether this is a reasonable category name) ... Although I wouldn't choose those tasks[1], Sure - I told you I'm uneducated about your work - one reason more for you to make the tasks better, right? I think this should be possible: you just pick a few, frequently used apps (when you build an distro you also have to choose some). Just to gave an idea. The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production imo. Ubuntu Studio has also some metapackages for video, music and artwork, but they also have an realtime kernel and a tool to handle the configuration. \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing?
On Wed, 25 Mar 2009 20:43:51 +0100
Grammostola Rosea rosea.grammost...@gmail.com wrote:
Btw. why doesn't Ardour from unstable hit testing? This is normal for
packages in Sid after some time right? Now there is no Ardour in stable
AND testing.
All the information is available via the PTS for ardour:
Testing status
Excuses:
* 96 days old (needed 10 days)
* Ignoring high urgency setting for NEW package
* out of date on s390: ardour (from 1:2.5-3)
* ardour (source, i386, alpha, amd64, armel, hppa, ia64, mips,
mipsel, powerpc, s390, sparc) has new bugs!
* Updating ardour introduces new bugs: #458660
* Not considered
http://packages.qa.debian.org/a/ardour.html
The bug information looks out of date, so clicking on the ToDo item:
The package has not yet entered testing even though the 10-day delay
is over. Check why.
gives:
http://release.debian.org/migration/testing.pl?package=ardour
* ardour has no old version in testing (trying to add, not update)
* ardour is not yet built on s390: 1:2.5-3 vs 1:2.7.1-2 (missing 1
binary: ardour)
https://buildd.debian.org/build.cgi?pkg=ardour
s390Fri Dec 19 04:03:07 2008maybe-failed
Chmod(gtk2_ardour/ardour.sh, 0755)
Substituting vars from gtk2_ardour/ardour2_ui_dark.rc.in into
gtk2_ardour/ardour2_ui_dark.rc Substituting vars from
gtk2_ardour/ardour2_ui_light.rc.in into gtk2_ardour/ardour2_ui_light.rc
Substituting vars from gtk2_ardour/ardour2_ui_dark_sae.rc.in into
gtk2_ardour/ardour2_ui_dark_sae.rc Substituting vars from
gtk2_ardour/ardour2_ui_light_sae.rc.in into
gtk2_ardour/ardour2_ui_light_sae.rc os.chdir('gtk2_ardour') cpp -E -P
ardour.menus.in ardour.menus os.chdir('/build/buildd/ardour-2.7.1')
version_builder([gtk2_ardour/version.cc, gtk2_ardour/version.h],
[]) semop(1): encountered an error: Identifier removed make: ***
[debian/stamp-scons-build] Error 1 Build killed with signal 15 after
150 minutes of inactivity
https://buildd.debian.org/fetch.cgi?pkg=ardour;ver=1%3A2.7.1-2;arch=s390;stamp=1229659387
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpSwFyacXoSW.pgp
Description: PGP signature
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 12:03 PM, Paul Wise p...@debian.org wrote: On Thu, Mar 26, 2009 at 3:42 AM, Kel Modderman k...@otaku42.de wrote: The DFSG seems to suggest that the source code to the regulatory database should be modifiable and the derived work distributed under the same license. It is my understanding that: Debian probably won't need to build the regdb from source most of the time so we can just ship the upstream regulatory.bin file most of the time. Yes, that is the case. The user who would modify these rules for example would be people doing experiments, research, or maintaining their own db for some sort of custom hardware with specifically licensed regulatory information. When we do, just adding a second public key to the CRDA pubkeys dir and using the corresponding private key (from outside the package) during the build process of wireless-regdb would be just fine. Yes, this is the case. This would mean the maintainer of crda would also have to be the wireless-regdb maintainer. Actually technically it could be a different person. I maintain crda upstream and John maintains wireless-regdb upstream, for example. I just need John's pubkey file which is non-binary. CRDA just reads the regulatory.bin which wireless-regdb provides. I assume the wireless-regdb is architecture-independent so this would work because the buildds do not build such packages. This is correct. You do need a regulatory.bin installed first though so that if crda is built with the RSA digital signature check part of its build process is to ensure the signature checks out against the currently installed regulatory.bin file on your system. But that's just because a sanity check is part of the default target on the Makefile. It is possible for users to add more public keys to the CRDA pubkeys dir and build their own wireless-regdb using their own private key. Affirmative. Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [renamed] Debian crda?
On Wed, Mar 25, 2009 at 1:25 PM, Luis R. Rodriguez mcg...@gmail.com wrote: Actually technically it could be a different person. I maintain crda upstream and John maintains wireless-regdb upstream, for example. I just need John's pubkey file which is non-binary. CRDA just reads the regulatory.bin which wireless-regdb provides. Let me be a little bit more clear on this last sentence. By provides I mean that John generated his pubkey using it and then e-mailed it to me. I then just merged it as part of CRDA so that by default CRDA trusts the regulatory.bin files he puts out. Luis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
On Wed, 25 Mar 2009, Grammostola Rosea wrote: taste they need to be informed what to choose from. It's like a restaurant where you choose from a menu. Currently we are lacking a complete multimedia menu in Debian. An menu entry for multimedia sounds good to me (Ubuntu has an menu entry for 'multimedia production: - music production - video production (or something close to that). This is good imo because audio apps are a lot small apps which clutter up in the menu now. Nothing against this but I used the term menu in a different than this technical meaning. I hope this became clear in my mail. Although I wouldn't choose those tasks[1], Sure - I told you I'm uneducated about your work - one reason more for you to make the tasks better, right? I think this should be possible: you just pick a few, frequently used apps (when you build an distro you also have to choose some). Just to gave an idea. But we do not choose a distro - we just have a distro which is called Debian. And we want to handle the packages which are just inside Debian. The choice inside Debian was done based on the user interest and time of developers. The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production imo. Ubuntu Studio has also some metapackages for video, music and artwork, but they also have an realtime kernel and a tool to handle the configuration. Well, I think the problem with the RT kernel was understood and it is just a an issue of just *doing* the actual packaging - so why not just starting with this? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Architecture usertags
On Wed, Mar 25, 2009 at 10:59:25AM -0600, dann frazier wrote: On Wed, Mar 25, 2009 at 05:30:19PM +0100, Wouter Verhelst wrote: I made a short overview of this on the wiki, at http://wiki.debian.org/Teams/Debbugs/ArchchitectureTags Got an extra ch in there? That was pointed out on IRC, too. It's the correct URL, however (i.e., the typo was made when creating the webpage, and then I copy-pasted it into the mail). I'm not sure renaming-and-redirecting is possible on the wiki; if it is, someone please do so (and sorry for this mess). -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Architecture usertags
On Wed, Mar 25, 2009 at 07:03:26PM +0100, Luk Claes wrote: Wouter Verhelst wrote: Now almost a month ago, I asked Don Armstrong to create architecture tags in the BTS. I've always felt that such a thing would be useful, because often porters are unaware of architecture-specific bugs, simply because there's no way in the BTS to actually search for them. Having such an ability could make porters of a particular architecture aware of the issues that affect their architecture, and (where necessary) able to help out. Note that porters can find many issues just by looking at the buildd.d.o [0] pages even for issues not (yet) known in the BTS for which they could file bugs. I'm aware of that. But there's a major difference between FTBFS bugs and architecture-specific bugs. emacs segfaults on m68k when the user hits control-alt-meta-shift-a is an example of an architecture-specific bug that is unlikely to be found by an autobuilder, and is the kind of bugs this type of usertags is primarily useful for. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 signature.asc Description: Digital signature
Re: Please Improve Debian for Multimedia Production
Andreas Tille wrote: On Wed, 25 Mar 2009, Grammostola Rosea wrote: taste they need to be informed what to choose from. It's like a restaurant where you choose from a menu. Currently we are lacking a complete multimedia menu in Debian. An menu entry for multimedia sounds good to me (Ubuntu has an menu entry for 'multimedia production: - music production - video production (or something close to that). This is good imo because audio apps are a lot small apps which clutter up in the menu now. Nothing against this but I used the term menu in a different than this technical meaning. I hope this became clear in my mail. That was clear, but it bumped up a old idea I had in my head ;) Please take that idea serious... Although I wouldn't choose those tasks[1], Sure - I told you I'm uneducated about your work - one reason more for you to make the tasks better, right? I think this should be possible: you just pick a few, frequently used apps (when you build an distro you also have to choose some). Just to gave an idea. But we do not choose a distro - we just have a distro which is called Debian. And we want to handle the packages which are just inside Debian. The choice inside Debian was done based on the user interest and time of developers. Now you misunderstood what I said ;) Maybe I was not clear, but the discussion was about which apps you should choose for such a metapackage, and I said, just pick some common used apps, to give an idea what is possible. The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production imo. Ubuntu Studio has also some metapackages for video, music and artwork, but they also have an realtime kernel and a tool to handle the configuration. Well, I think the problem with the RT kernel was understood and it is just a an issue of just *doing* the actual packaging - so why not just starting with this? [bit offtopic, there is another thread about this] I really like the openness for an RT kernel in Debian. I didn't expect it, so I'm really happy with. I hope some guys will jump in ! I will do my best to tell it around and ask people to join [/bit offtopic, there is another thread about this] Kind regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing?
Reinhard Tartler wrote: Grammostola Rosea rosea.grammost...@gmail.com writes: Could you comment on this? I think it's the best when Ardour will hit Lenny. New packages are not in scope of the update policy of released debian versions. So this is not going to happen. Second option is as a Lenny backport. That's more likely. However only packages in testing are candidates for lenny-backports. Btw. why doesn't Ardour from unstable hit testing? This is normal for packages in Sid after some time right? Now there is no Ardour in stable AND testing. http://release.debian.org/migration/testing.pl?package=ardour So this should be fixed, wait till it hit testing and then make an backport? \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing?
Grammostola Rosea rosea.grammost...@gmail.com writes: Could you comment on this? I think it's the best when Ardour will hit Lenny. New packages are not in scope of the update policy of released debian versions. So this is not going to happen. Second option is as a Lenny backport. That's more likely. However only packages in testing are candidates for lenny-backports. Btw. why doesn't Ardour from unstable hit testing? This is normal for packages in Sid after some time right? Now there is no Ardour in stable AND testing. http://release.debian.org/migration/testing.pl?package=ardour -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521219: ITP: ttf-umeplus -- Japanese gothic font based on umefont and M+ fonts
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, pkg-fonts-de...@lists.alioth.debian.org Package name: ttf-umeplus Version: 20090209-1 Upstream Author: UTUMI Hirosi utuhir...@yahoo.co.jp URL: http://www.geocities.jp/ep3797/modified_fonts_01.html Description: Description: Japanese TrueType gothic fonts, based on Umefont and M+Font UmePlus is Japanese TrueType gothic font, mixed Umefont and M+Font. It consists of * UmePlus Gothic * UmePlus P Gothic . And also, Umeplus is the default Japanese font for Mandriva Linux. License: M+ FONTS These fonts are free softwares. Unlimited permission is granted to use, copy, and distribute it, with or without modification, either commercially and noncommercially. THESE FONTS ARE PROVIDED AS IS WITHOUT WARRANTY. http://mplus-fonts.sourceforge.jp/mplus-outline-fonts/ umefont Copyright (c) 1990-2003 Wada Laboratory, the University of Tokyo. All rights reserved. Copyright (c) 2003-2004 Electronic Font Open Laboratory (/efont/). All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the Wada Laboratory, the University of Tokyo nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY WADA LABORATORY, THE UNIVERSITY OF TOKYO AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE LABORATORY OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Now it's lintian clean (without section changes). You can get it from http://mentors.debian.net/debian/pool/main/t/ttf-umeplus/ttf-umeplus_20090209-1.dsc -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane pgpSSn22nnpHD.pgp Description: PGP signature
Re: Please Improve Debian for Multimedia Production
On Wed, 25 Mar 2009, Grammostola Rosea wrote: Nothing against this but I used the term menu in a different than this technical meaning. I hope this became clear in my mail. That was clear, but it bumped up a old idea I had in my head ;) Please take that idea serious... To whom do you targeting this request? To me? - Probably not, because I will not fiddle around with those menus. The best idea would be if *you* take your suggestion serious and file bug report against menu (including patch) or if you fix the *.desktop files of relevant applications. But if I'm not missleaded you have to foreward this proposal to freedesktop.org where the menu standard is defined. This is probably a lot of work - and proves you are taking the request serious... Now you misunderstood what I said ;) Maybe I was not clear, but the discussion was about which apps you should choose for such a metapackage, and I said, just pick some common used apps, to give an idea what is possible. Ah OK. But hey, my problem is that I do not know commonly used multimedia apps. So why not starting with my suggestion to do some brainstorming in the Wiki? Just find some categories and packages that fit into. [bit offtopic, there is another thread about this] I really like the openness for an RT kernel in Debian. I didn't expect it, so I'm really happy with. Well, finally it is Free Software (if not it would not be included), right. I hope some guys will jump in ! I learned that this strategy will not work. Pointing your finger on an open problem and then just wait if somebody else will solve it just will not work. Try to start solving the problem yourself - we will help you in case of trouble. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Architecture usertags
On Mittwoch, 25. März 2009, Wouter Verhelst wrote: http://wiki.debian.org/Teams/Debbugs/ArchchitectureTags I'm not sure renaming-and-redirecting is possible on the wiki; if it is, someone please do so (and sorry for this mess). done :-) signature.asc Description: This is a digitally signed message part.
Re: [Amendment] Reaffirm the GR process
* Kurt Roeckx [Tue, 24 Mar 2009 23:52:22 +0100]: On Tue, Mar 24, 2009 at 08:03:46PM +0100, Robert Millan wrote: I'd also like to complain about the title text of the initial GR. It is clearly manipulative, as it pretends to be merely describing the proposed changes when in fact it is asserting an opinion. I hope the Secretary will fix this. I think the title is also not the best one and just used Joerg's title. What about: General Resolution sponsorship requirements I’d suggest a minor variation: “Sponsorship requirements for General Resolutions”. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Keeping track of best practises / policy changes with tracking -devel
Hi, I'm finding that I can't keep up with devel but I would like to be able to see a summary of consensuses (consensii?) that result from the discussions, as well a final summaries of best practices (and changes to them. Also a neat changelog of policy changes I should be aware of. Basically I want to make sure I package well, but I don't want to track -devel, because it is way too busy. Anything that can help? Also, is there any codification of best practices anywhere? (and what's the deal with the new package/patch format?) I've read NM guide and Policy, but what I see on -devel is a bunch of other technical information and considerations that aren't codified anywhere I can find, but following the mailing list to keep track is taking so much time that in the past few days I've read mail and done no work on actual development. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org signature.asc Description: PGP signature
Re: Keeping track of best practises / policy changes with tracking -devel
(Sending a personal copy because you said that you weren't following debian-devel easily. Apologies if this was a mistake.) Daniel Dickinson csh...@brucetelecom.com writes: I'm finding that I can't keep up with devel but I would like to be able to see a summary of consensuses (consensii?) that result from the discussions, as well a final summaries of best practices (and changes to them. Also a neat changelog of policy changes I should be aware of. Basically I want to make sure I package well, but I don't want to track -devel, because it is way too busy. Anything that can help? Also, is there any codification of best practices anywhere? (and what's the deal with the new package/patch format?) All of this stuff *should* make it into Debian Policy, and from there into the announcements that are posted to debian-devel-announce each time a new version of Debian Policy is uploaded. The average Debian packager should not have to care about most of these discussions until they make it into Policy (or, for best practices, the Developer's Reference -- that I track by installing it and using apt-listchanges to show me changelogs). We're rather far from that ideal at the moment. I hope to get us closer. The more people who are willing to file Policy bugs and write patches, the better, although of even more help would be more people who had the time to do the hard work of steering Policy discussions through to completion and consensus on wording. If you install the debian-policy package, you'll get a changelog of Policy updates in /usr/share/doc/debian-policy/upgrading-checklist.txt.gz. In the meantime, most of the major initiatives that require the average packager to pay attention are announced to debian-devel-announce in some form, and anything that isn't should be. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
This topic died off; any resolution?
I kind of got lost in this discussion. Is there a summary and debian policy and debian reference patch so that those of us who are just looking to do what we're supposed to do know what we are supposed to do and how to do it? Thanks, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org signature.asc Description: PGP signature
New quilt source format
Is there any information on how the typical package is supposed to use this new format, or (I'm a little confused on this) is it even in place yet? If it's not in place how do we prepare for it? Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org signature.asc Description: PGP signature
Re: Keeping track of best practises / policy changes with tracking -devel
On Wed, 25 Mar 2009 18:18:51 -0400 Daniel Dickinson csh...@brucetelecom.com wrote: I'm finding that I can't keep up with devel but I would like to be able to see a summary of consensuses (consensii?) that result from the discussions, as well a final summaries of best practices (and changes to them. Also a neat changelog of policy changes I should be aware of. $ zless /usr/share/doc/debian-policy/upgrading-checklist.txt.gz but that only tracks Policy after it has changed. Basically I want to make sure I package well, but I don't want to track -devel, because it is way too busy. debian-mentors mailing list, lintian -iI or --pedantic as long as you remember that not every pedantic listing actually needs to be fixed in all packages that it may appear. Then there are things like planet.debian.org and various RSS feeds as well as more specialised (and quieter) mailing lists for other topics. I've read NM guide and Policy, but what I see on -devel is a bunch of other technical information and considerations that aren't codified anywhere I can find, but following the mailing list to keep track is taking so much time that in the past few days I've read mail and done no work on actual development. :-) -devel is all about discussing stuff before there is a consensus. There's http://dep.debian.net to track some of the ongoing discussions. It's always best to skim -devel and ignore entire threads that don't relate directly to your own work - otherwise you'll never get anything done. (He says, after spending more time on replying to -devel in the last week than usual and suffering from a lack of time for other stuff as a direct result.) -devel is if you want to have a say in the discussion before a consensus is reached, rather than just keeping up to date. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp2Dd7gpi9X1.pgp Description: PGP signature
