Re: cdn.debian.net as a project service?
On Fri, Mar 11, 2011 at 3:55 AM, Michael Vogt wrote: > There is a "mirror" method in apt since some time that is a bit of a > combined cdn/README.mirrors approach. Its not much used and probably > has some rough edges but should be a good starting point. > > The idea is that you have a sources.list entry like: > deb mirrors://mirrors.debian.org/mirror sid main > > and the server returns a list of "good" mirrors (based on something > like geoip) for your location as a simple text list. This is done on > apt-get update. After that it uses a selected miror of that list to do > the actual update and for getting the packages. The list is stored > locally in /var/lib/apt/mirrors so that a re-query is not needed for > each download request. It supports fallback to the next mirror if > there are problems and also reporting back issues (via a external > helper). > > One missing feature is that it needs to send along info about the > release/arch its looking for or the returned list needs to be extended > to include this info. But otherwise it should be good and working. Looks like the main thing missing for this to work is an implementation of the server? What is the protocol? Maybe this would be a good gsoc project? -- 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 Archive: http://lists.debian.org/AANLkTi=kiybjhxg6+8tbjkzfjdbarnxsxz8d6wuqe...@mail.gmail.com
Re: cdn.debian.net as a project service?
On Fri, Mar 11, 2011 at 11:04 AM, Paul Wise wrote: > Not nessecarily, it really depends. For example in Australia local > mirrors are much faster than US mirrors. And your ISPs mirrors are usually faster than other ISPs mirrors. Some ISPs give free access to their mirror; the mirror traffic doesn't count towards your traffic quota. -- 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 Archive: http://lists.debian.org/AANLkTi=0+duoc7mwugv2zf-17xdt+tnfatqjxojn9...@mail.gmail.com
Re: cdn.debian.net as a project service?
On Fri, Mar 11, 2011 at 7:11 AM, Adam Borowski wrote: > Another strange thing about apt-spy is that it picks a subset of mirrors > without an apparent rule. It claims it uses > http://http.us.debian.org/debian/README.mirrors.txt yet it ignores most (but > not all!) of non-country-primary ones. Thats a bug in the parsing (#457049). > Right, with bottlenecks usually being at the last mile, all good mirrors > will have nearly the same speed. Picking any from the general area should > be fine. Not nessecarily, it really depends. For example in Australia local mirrors are much faster than US mirrors. -- 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 Archive: http://lists.debian.org/AANLkTi=qqrkxfb_sqx-rz-qtor-gvgqwyymo7ilii...@mail.gmail.com
Processed: reassign 617694 to src:linux-2.6
Processing commands for cont...@bugs.debian.org: > reassign 617694 src:linux-2.6 2.6.32-30 Bug #617694 [general] general: rt2860sta reconnect fails wpa2 enterprise peap Bug reassigned from package 'general' to 'src:linux-2.6'. Bug #617694 [src:linux-2.6] general: rt2860sta reconnect fails wpa2 enterprise peap Bug Marked as found in versions linux-2.6/2.6.32-30. > thanks Stopping processing here. Please contact me if you need assistance. -- 617694: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617694 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129981112429995.transcr...@bugs.debian.org
Bug#617744: ITP: libnet-frame-perl -- framework for crafting raw frames
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libnet-frame-perl Version : 1.07 Upstream Author : Patrice Auffret * URL : http://search.cpan.org/dist/Net-Frame/ * License : Artistic Programming Lang: Perl Description : framework for crafting raw frames Net::Frame is a Perl framework for crafting raw frames (Layers 2 through 7). Out of the box, it can be used to produce ARP, Ethernet, IPv4, PPP, TCP and UDP frames. It has an extensible design for new frame implementations. This module only creates frames; Net::Write (see libnet-write-perl) can be used to write frames directly to wire. NOTE: this package replaces a now-defunct RFP for libnet-packet-perl (Net::Frame is an upstream fork of Net::Packet, and Net::Packet is deprecated upstream) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikbgmgtx-jtfhwjqfpaxpgavp+onry1usyq5...@mail.gmail.com
Re: cdn.debian.net as a project service?
On Fri, 2011-03-11 at 00:11 +0100, Adam Borowski wrote: > On Thu, Mar 10, 2011 at 05:12:08PM +, Lars Wirzenius wrote: > > I like the idea of having apt choose the mirror, rather than the admins > > of cdn.debian.net. It lessens the centralization. Also, it would require > > fewer changes from mirror admins to participate. > > What do you propose apt to do? > > * runtime tests: costly and bogus (see below) > * geolocation: you'd need an external service to tell your routable IP, and > after that additional step you're no better off than what cdn can do [...] Yes, you are better off. If we rely on GeoIP at the DNS level and a user's recursive DNS server is far away from them then we may pick the wrong mirror. But if we do it through a redirection or indirection at the HTTP level, then we will pick the right one. If they are using an HTTP proxy far away from them, they will surely be using the same proxy to fetch the files they wanted, so a mirror close to the proxy is the right answer. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: cdn.debian.net as a project service?
On Fri, 11 Mar 2011 00:11:40 +0100, Adam Borowski wrote: > > On the other hand, we don't necessarily have to be able to pick the > > optimal mirror. It's probably good enough to pick a good one. > Right, with bottlenecks usually being at the last mile, all good mirrors > will have nearly the same speed. Picking any from the general area should > be fine. For a rather broad value of "general area"; random anecdote: After DebConf10 I forgot to set the mirror on my laptop back to a regional one; and I only realized it days later because the mirror at Columbia University works just fine in Central Europe :) The only times I switch mirrors when being at home are when either the server has a problem (like being outdated) or my network connection (like the IPv6 tunnel being down). - And both is not really about geography or "network in general". Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Zueriwest: Harry Klein signature.asc Description: Digital signature
Re: new scripts and patches for devscripts
* Stefano Zacchiroli [2011-03-11 00:18 +0100]: > First of all, I'm not sure anymore that I see the point of discussing > the *language issue* in a circle larger than the devscripts > maintainers. ... The language issue should probably be a decision > within the devscripts team, together with the script proposers. Wise words. > Nevertheless, I think the argument you're proposing above is potentially > dangerous. You seem to assume that just because some new scripts get > into devscripts then it will be up to the most active maintainer of the > package to maintain them. ... Debian is a do-ocracy and every DD governs his or her small country ;) I was talking about who should decide such things (not how specific teams work internally) and described a way to avoid working together on one package if there is no agreement. > IMHO, part of the value of devscripts is that it offers a bunch of > useful maintenance script by default. It's already quite big and very > few maintainers know all of them. Splitting the package even more will > further reduce the possibility that maintainers will find them. There is a similar argument for changing the current state: having generally useful scripts in ubuntu-dev-tools "reduce(s) the possibility that maintainers will find them" since the Ubuntu specific ones and those that assume Ubuntu typical configurations cause a lot of noise. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110311003034.gn31...@furrball.stateful.de
Re: new scripts and patches for devscripts
On Thu, Mar 10, 2011 at 02:34:51PM -0500, James Vega wrote:
> I completely agree that rewriting the tools isn't a useful effort. I
> was more concerned that there had been significant development done on
> scripts that were intended to be proposed to devscripts and yet were
> intentionally being written in a language that I had previously
> expressed to Benjamin wasn't used in devscripts.
>
> I'm not categorically opposed to having Python scripts in devscripts,
> as I do grok Python. My resistance was more due to the process around
> the proposed contributions and posing the barrier to acceptance as
> purely an added dependency.
I can understand that, sorry I haven't grokked it before. If you feel
previous agreements have been "betrayed" (ok, that's a strong word ...),
than this is a whole different matter, a one of trust, which is up to
devscripts maintainers to judge.
> Also, while Benjamin and Stefano have offered to support the potential
> new scripts, how does that help with the existing scripts which Benjamin
> stated concern about? Last we spoke, he wasn't comfortable with Perl,
> so while they may support their scripts within devscripts, how much does
> it really buy for the devscripts package as a whole? Is it worth moving
> them or easier to just keep them in ubuntu-dev-tools?
Having a script rather than in u-d-t will most likely mean that a lot
more people, not only in Debian but also in other derivatives, will have
higher chances to discover it. If the tool in question increases
maintainer productivity (and/or diminish tedious work), there lies some
value in moving script.
I agree that if Stefano and Benjamin have only expressed interest in
those scripts there is no added values for other scripts, but I'm
unconvinced that's bad per se.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
python packaging example with debhelper, dh_pysupport and dh_python2
Hi, i tried to understand the correct way to package a python module with debhelper, dh_pysupport and dh_python2. I created a python-helloworld example package ( get it from https://code.launchpad.net/~toabctl/+junk/python-helloworld ) and want to know if i used the correct way to package a simple python module. questions are: - are the package dependencies correct or do i need some more substvars? - what exactly should do dh_python2 and do i need both, dh_pysupport _and_ dh_python2? i just found the manpage and [1] as dh_python2 documentation and don't exactly understand why i need dh_python2. - How should i install the python module if i don't have a setup.py . i use the debian/install file and just copy all files to /usr/share/pyshared/helloworld . is this correct? [1] http://people.debian.org/~piotr/dc10_slides.pdf Cheers, Tom signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
On Thu, Mar 10, 2011 at 08:15:22PM +0100, Carsten Hey wrote:
> James Vega seems to be the most active devscripts maintainer these days,
> and he does this (as far as I know) in his spare time. If he does not
> want to have python scripts in it, I see no justification to force him
> to do so. I also see no reason to try hard to convince him after he
> clearly stated his point of view.
First of all, I'm not sure anymore that I see the point of discussing
the *language issue* in a circle larger than the devscripts maintainers.
(Disclaimer: although I'm still listed as devscripts uploader, I
consider myself in violation of that rule as wall: it's been quite a
while since my last significant contribution to the package.) The
language issue should probably be a decision within the devscripts team,
together with the script proposers.
Nevertheless, I think the argument you're proposing above is potentially
dangerous. You seem to assume that just because some new scripts get
into devscripts then it will be up to the most active maintainer of the
package to maintain them. That is not my experience with devscripts
maintenance. I got in initially because of one single script, but later
on I also ended up fixing issues here and there and doing general clean
up work (for a very little while). I don't think that the fact I got in
due to a single script has increases the maintenance burden on other
maintainers. If it were the case, you might have been right, but I see
no evidence of that.
> If including other languages in the new package would be planned, naming
> it devscripts-extra or similar instead could be helpful. An alternative
> to the above is to rename devscripts to devscripts-base or -core, name
> the new binary package devscripts and let it depend on devscripts-base.
IMHO, part of the value of devscripts is that it offers a bunch of
useful maintenance script by default. It's already quite big and very
few maintainers know all of them. Splitting the package even more will
further reduce the possibility that maintainers will find them.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: cdn.debian.net as a project service?
On Thu, Mar 10, 2011 at 05:12:08PM +, Lars Wirzenius wrote: > I like the idea of having apt choose the mirror, rather than the admins > of cdn.debian.net. It lessens the centralization. Also, it would require > fewer changes from mirror admins to participate. What do you propose apt to do? * runtime tests: costly and bogus (see below) * geolocation: you'd need an external service to tell your routable IP, and after that additional step you're no better off than what cdn can do * asking the user: sure, but it'd be nice to not have to do that > > > Package: netselect-apt > > > Description: speed tester for choosing a fast Debian mirror Does it actually work for anyone? I just tried it from machines at four different locations on 3½ ISPs; two with IPv6+IPv4, two IPv4 only; two with no NAT; all with full UDP/ICMP connectivity -- getting an empty result every single time (#23, #582976). netselect-apt somehow requires root, I got none on a machine outside of northern Poland so I can't test if it's something caused by a specific mirror. > > apt-spy is another one. It downloads Packages files from all the > > mirrors in a region or country and reports the fastest. Its download test has way too randomness to be of much use. I get results from all around half of Europe, in no test out of three ftp.pl.debian.org won and it's just next to a router early on the path to the rest. With bottleneck being the last mile, it's not that surprising. Another strange thing about apt-spy is that it picks a subset of mirrors without an apparent rule. It claims it uses http://http.us.debian.org/debian/README.mirrors.txt yet it ignores most (but not all!) of non-country-primary ones. > Packages files are pretty big, and having to download several of them is > quite a stumbling block. If I'm on a metered connection, I don't want to > have to download several unnecessary megabytes just to see which mirror > is fastest. As apt-spy shows, you'd have to download far more than just a 6MB file to beat the variance. At least, it approximates network distance worse than geolocation. > Ping times, of course, are not a particularly good way to pick a mirror, > either. Yeah, they seem to be more reliable than a short download test though, even if for a wrong reason. > On the other hand, we don't necessarily have to be able to pick the > optimal mirror. It's probably good enough to pick a good one. Right, with bottlenecks usually being at the last mile, all good mirrors will have nearly the same speed. Picking any from the general area should be fine. > Also, picking the mirror should be just one function (or class or module > or whatever) in apt, so everything else could be implemented independent > of the choice of heuristic to choose a mirror. > > Would someone be willing to mentor a GSoC project for this? Or do it > themselves? The current state is: * manual selection, or * geolocation (cdn.debian.net) None of alternatives proposed is any better than these two -- and with apt-spy, significantly worse. Thus, I'd say there are so many better uses for GSoC folks. Blessing cdn.debian.net as the default choice seems to be the best solution to me. Geographical proximity is not the same as network proximity but approximates it well enough. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310231140.ga27...@angband.pl
Re: Removal of wanna-build from sbuild
On Thu, Mar 10, 2011 at 07:57:44PM +, Philipp Kern wrote: > On 2011-03-10, Bernd Zeimetz wrote: > > On 03/10/2011 06:56 PM, Philipp Kern wrote: > >> On 2011-03-10, Hector Oron wrote: > >>> I was planning to start using a wanna-build instance, but i was not > >>> sure which one to use. > >>> As I have not yet started to use any of them I have no real objection > >>> for its removal, on the other hand I would not mind to try to merge > >>> current wb used on buildd with the one shipped in sbuild. Just let me > >>> know your preferences. > >> The two codebases don't have much in common, given that the sbuild one was > >> heavily refactored. > > So why the hell are these two branches not merged and developed by a team? > > Volunteer time is limited and the focus of the wanna-build team is a different > one than providing packages, at least at the moment. (Especially as it's > hard to produce something that works equally well as a package and as a > central installation that's updated differently.) There's also no benefit > in moving the central wanna-build to a refactored code base that has less > features and fixes. Exactly. I was planning to merge the wanna-build.git changes into sbuild.git for a *long* time. I just haven't had time to do it, and no one else has seemed especially interested. Certainly not sufficiently interested to volunteer their time to do it. > buildd in unstable was severely broken for ages, because the packages > weren't at all tested after heavy refactorings (and still aren't > because the maintainer doesn't have a test setup). wanna-build will > have suffered the same fate. The main sticking point for me being able to properly test buildd is that is requires a functional wanna-build setup to do so. And setting one up is decidedly non-trivial. wanna-build.git is unusable without all the extra support scripts on grieg, and the schema files are broken. I was not able to set up a working wanna-build environment. What I'm thinking of doing here is writing a "fake" wanna-build that can emulate the real one. To the extent that e.g. --list=needs-build can return a list of packages to build. This would allow buildd testing in the absence of a full wanna-build setup. Again, it needs time to do. Any help here would be appreciated. wanna-build was a little different from buildd. It was /never/ truly functional from the start, either before or after any refactoring, and with zero users, there just hasn't been the demand to work on it above sbuild or buildd. > For buildd-0.61.0 the situation seems to be a bit better, I only needed > some few hours instead of days to get it working again. buildd *is* living > in the same repository as sbuild, though. It's just wanna-build that's > separate. That's good to know. Adding the testsuite has reduced the chance of regressions somewhat. Getting buildd in the testsuite as well would be even better. > That said, if you want to step up in maintaining a hellish Perl codebase, > feel free to send patches. Help is always appreciated. It's not the nicest codebase in the world, but I think we've improved it significantly in recent years. sbuild at least is now usable by mortals, though it could still be easier to set up; documentation is the main lacking here. 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. signature.asc Description: Digital signature
Re: new scripts and patches for devscripts
On 03/10/2011 10:32 PM, Steve Langasek wrote: > On Thu, Mar 10, 2011 at 09:50:57PM +0100, gregor herrmann wrote: >> On Thu, 10 Mar 2011 10:51:50 -0800, Steve Langasek wrote: > > get-build-deps Is this an alias for "apt-get build-dep $1"? >>> No, it's a tool that's been long missing from a Debian as a standard >>> interface - "install the build-dependencies for the package in my current >>> directory". > >> Sounds similar to 'mk-build-deps -i debian/control'. > Note that you don't have to say "debian/control" there. It's the default. I wonder why "-i" and "-r" aren't activated by default though. >> That's not a vote for "get-build-deps is useless" but an >> encouragement for merging similar efforts and combining forces. > > Certainly, I agree that efforts should be merged. In a sense, that's what > this request to take u-d-t scripts into devscripts is about. :) > > FWIW, mk-build-deps is close, but not exactly what I'm looking for > personally. I really want a command that, without needing to specify any > extra options, does 'mk-build-deps -i -r debian/control', because I think > this is the common case. I also think we're missing as a standard interface > a tool that *tells* us what build-dependencies need to be installed (and > what build-conflicts need to be removed), in a form that's automatically > consumable by other tools including, but not limited to, apt-get. > dpkg-checkbuilddeps fails this because it only tells which b-d's are > unsatisfied, in a form that has to be further processed. > I hope that this poney^W two-lines script won't use "sudo" (again). Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d7949d6.6090...@dogguy.org
Re: new scripts and patches for devscripts
On Thu, Mar 10, 2011 at 09:50:57PM +0100, gregor herrmann wrote: > On Thu, 10 Mar 2011 10:51:50 -0800, Steve Langasek wrote: > > > >get-build-deps > > > Is this an alias for "apt-get build-dep $1"? > > No, it's a tool that's been long missing from a Debian as a standard > > interface - "install the build-dependencies for the package in my current > > directory". > Sounds similar to 'mk-build-deps -i debian/control'. > That's not a vote for "get-build-deps is useless" but an > encouragement for merging similar efforts and combining forces. Certainly, I agree that efforts should be merged. In a sense, that's what this request to take u-d-t scripts into devscripts is about. :) FWIW, mk-build-deps is close, but not exactly what I'm looking for personally. I really want a command that, without needing to specify any extra options, does 'mk-build-deps -i -r debian/control', because I think this is the common case. I also think we're missing as a standard interface a tool that *tells* us what build-dependencies need to be installed (and what build-conflicts need to be removed), in a form that's automatically consumable by other tools including, but not limited to, apt-get. dpkg-checkbuilddeps fails this because it only tells which b-d's are unsatisfied, in a form that has to be further processed. I think a standard tool to handle this "what do I need to install and remove to satisfy the build-depends for the current package" question would be useful at a lower level than devscripts, fwiw. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#617718: ITP: libgraphite2-2.0.0 -- a "smart font" rendering engine -- library
Package: wnpp Severity: wishlist Owner: Rene Engelhard * Package name: libgraphite2-2.0.0 Version : 0.9.3 Upstream Author : SIL International * URL : http://sf.net/projects/silgraphite * License : LGPL Programming Lang: C++ Description : a "smart font" rendering engine -- library Graphite is a system that can be used to create and use "smart fonts" capable of displaying writing systems with various complex behaviors, such as: contextual shaping, ligatures, reordering, split glyphs, bidirectionality, stacking diacritics and complex positioning. . This library was designed and developed by the NRSI (Non-Roman Script Initiative) within SIL International (www.sil.org) to act as a complement to other smart font rendering technologies with limited practical local extensability. Its purpose is to help meet the needs of a very large number of "minority language" communities for local extensibility of complex script behaviors. . The behavior of the rendering engine for a given writing system is specified through extra tables added to a TrueType font. These tables are generated by compiling a GDL (Graphite Description Language) source file into a font using grcompiler. . This package contains the shared library. This seems to be the successor of silgraphite2.0(sic!) which is libgraphite3 and LibreOffice is going to switch to graphite2. Daniel, would you want to (co-)maintain it? I have a package (on upstreams Debian packaging fixed up) here already :-) Grüße/Regards, Rene -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310211447.ga29...@rene-engelhard.de
Bug#617716: ITP: biogenesis -- artificial life program that simulates evolution of organisms
Package: wnpp Severity: wishlist Owner: Miriam Ruiz * Package name: biogenesis Version : 0.8 Upstream Author : Joan Queralt * URL : http://biogenesis.sourceforge.net/ * License : GPL-2+ Programming Lang: Java Description : artificial life program that simulates evolution of organisms Biogenesis is an artificial life program that simulates the processes involved in the evolution of organisms. It shows colored segment based organisms that mutate and evolve in a 2D environment. Biogenesis is based on Primordial Life. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310210226.27034.47213.report...@alioth.debian.org
Re: cdn.debian.net as a project service?
On Thu, 10 Mar 2011 10:22:29 +0100, Peter Palfrader wrote: > I'd really like to see support for sane mirror selection in apt itself, > possibly with archive support (i.e. list of mirrors somewhere on > ftp.d.o). That would allow apt to for instance retry on a different > server if the first one it tried does not work for some reason, and > maybe even report the problem to a central mirror. Being able to specify a "fallback" mirror would be nice. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Arlo Guthrie: Washington County signature.asc Description: Digital signature
Re: new scripts and patches for devscripts
On Thu, 10 Mar 2011 18:48:21 +0100, Stefano Zacchiroli wrote: > To conclude with an obvious argument, rewriting useful tools which are > known to work and which are currently maintained by a derived distro, > when they are already written in a popular language, doesn't seem to be > the smartest thing to do to me. Agreed. And in general, I welcome the effort to combine the efforts spent in the two packages. They are both valuable, and IMO both suffer a bit from unintuitive names and partly overlapping tools, while both provide a great help for developers. (And since both operate on .deb packages I see no real value in separating them between Debian and Ubuntu.) Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Tom Waits: Step Right Up signature.asc Description: Digital signature
Re: new scripts and patches for devscripts
Hi James (2011.03.10_21:34:51_+0200) > I completely agree that rewriting the tools isn't a useful effort. I > was more concerned that there had been significant development done on > scripts that were intended to be proposed to devscripts and yet were > intentionally being written in a language that I had previously > expressed to Benjamin wasn't used in devscripts. I've done development on them while they were in u-d-t, because they had issues that needed fixing, or new features I/other people wanted, and I don't care *that* much which package they live in. Yes, some of the scripts have always intended to be proposed for devscripts, but that was no reason not to work on them. Especially when getting them into devscripts was going to run into this language barrier... I've even rewritten some u-d-t Perl scripts in Python, so they could take advantage of Python libraries we'd already implemented, rather than have to implement the same things in multiple languages. (Also, my Perl is pretty poor, I'm much more productive in Python). > Last we spoke, he wasn't comfortable with Perl, so while they may > support their scripts within devscripts, how much does it really buy > for the devscripts package as a whole? It's a fair point. My perl isn't great, and I can't suddenly see myself suddenly getting deeply involved in devscripts. Of course the future is hard to predict, but I'm not planning on sharpening my perl skills. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310205005.gr24...@bach.rivera.co.za
Re: new scripts and patches for devscripts
On Thu, 10 Mar 2011 10:51:50 -0800, Steve Langasek wrote: > > >get-build-deps > > Is this an alias for "apt-get build-dep $1"? > No, it's a tool that's been long missing from a Debian as a standard > interface - "install the build-dependencies for the package in my current > directory". Sounds similar to 'mk-build-deps -i debian/control'. That's not a vote for "get-build-deps is useless" but an encouragement for merging similar efforts and combining forces. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Beatles signature.asc Description: Digital signature
Re: cdn.debian.net as a project service?
On Thu, Mar 10, 2011 at 10:22:29AM +0100, Peter Palfrader wrote: > On Thu, 10 Mar 2011, Lars Wirzenius wrote: > > What would it take to get cdn.debian.net become a service provided by > > the project? In other words, cdn.debian.org, instead of cdn.debian.net. [..] > I'd really like to see support for sane mirror selection in apt itself, > possibly with archive support (i.e. list of mirrors somewhere on > ftp.d.o). That would allow apt to for instance retry on a different > server if the first one it tried does not work for some reason, and > maybe even report the problem to a central mirror. There is a "mirror" method in apt since some time that is a bit of a combined cdn/README.mirrors approach. Its not much used and probably has some rough edges but should be a good starting point. The idea is that you have a sources.list entry like: deb mirrors://mirrors.debian.org/mirror sid main and the server returns a list of "good" mirrors (based on something like geoip) for your location as a simple text list. This is done on apt-get update. After that it uses a selected miror of that list to do the actual update and for getting the packages. The list is stored locally in /var/lib/apt/mirrors so that a re-query is not needed for each download request. It supports fallback to the next mirror if there are problems and also reporting back issues (via a external helper). One missing feature is that it needs to send along info about the release/arch its looking for or the returned list needs to be extended to include this info. But otherwise it should be good and working. Cheers, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310195547.GA24278@localhost
Re: Removal of wanna-build from sbuild
On Thu, Mar 10, 2011 at 05:24:25PM +, Hector Oron wrote: > Hello Roger, > > 2011/3/10 Roger Leigh : > > > This mail is really just to find out: is anyone actually using the > > wanna-build package in the archive? popcon indicates that a few > > people have it installed, and < 10 have ever used it. Would > > migrating to wanna-build.git be realistic for these users? > > I was planning to start using a wanna-build instance, but i was not > sure which one to use. > As I have not yet started to use any of them I have no real objection > for its removal, on the other hand I would not mind to try to merge > current wb used on buildd with the one shipped in sbuild. Just let me > know your preferences. I think using the version in use on the Debian buildd infrastructure is the better choice. It's better tested, actively maintained and in active use. The sbuild version was superficially OK, but when I checked as phil suggested, it's really not in good shape; as a result, I've removed it now. But neither are particularly ideal. They originated as flat-file Perl MLDBM databases which were later upgraded to use PostgreSQL, but due to the interface imposed upon them by the historic design are really not that well suited to the task. Due to the limitations in the design, there are a number of scripts running on the Debian machines to wrap wanna-build to make it do more complex stuff, but AFAICS these are not in wanna-build.git. But all these layers of wrappers are really just working around deficiencies in the core design and interface provided by wanna-build. I don't think it's worth spending the time fixing it in sbuild.git; I was working on a more complete modern database schema with dato, which may be found in sbuild.git, and I'll be looking at making this into a functional replacement for wanna-build, but without its legacy baggage. But for now, wanna-build.git is where the working implementation lives. 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. signature.asc Description: Digital signature
Re: Removal of wanna-build from sbuild
On 2011-03-10, Bernd Zeimetz wrote: > On 03/10/2011 06:56 PM, Philipp Kern wrote: >> On 2011-03-10, Hector Oron wrote: >>> I was planning to start using a wanna-build instance, but i was not >>> sure which one to use. >>> As I have not yet started to use any of them I have no real objection >>> for its removal, on the other hand I would not mind to try to merge >>> current wb used on buildd with the one shipped in sbuild. Just let me >>> know your preferences. >> The two codebases don't have much in common, given that the sbuild one was >> heavily refactored. > So why the hell are these two branches not merged and developed by a team? Volunteer time is limited and the focus of the wanna-build team is a different one than providing packages, at least at the moment. (Especially as it's hard to produce something that works equally well as a package and as a central installation that's updated differently.) There's also no benefit in moving the central wanna-build to a refactored code base that has less features and fixes. buildd in unstable was severely broken for ages, because the packages weren't at all tested after heavy refactorings (and still aren't because the maintainer doesn't have a test setup). wanna-build will have suffered the same fate. For buildd-0.61.0 the situation seems to be a bit better, I only needed some few hours instead of days to get it working again. buildd *is* living in the same repository as sbuild, though. It's just wanna-build that's separate. That said, if you want to step up in maintaining a hellish Perl codebase, feel free to send patches. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrninib9o.4cb.tr...@kelgar.0x539.de
Re: Removal of wanna-build from sbuild
On 03/10/2011 06:56 PM, Philipp Kern wrote: > On 2011-03-10, Hector Oron wrote: >> I was planning to start using a wanna-build instance, but i was not >> sure which one to use. >> As I have not yet started to use any of them I have no real objection >> for its removal, on the other hand I would not mind to try to merge >> current wb used on buildd with the one shipped in sbuild. Just let me >> know your preferences. > > The two codebases don't have much in common, given that the sbuild one was > heavily refactored. So why the hell are these two branches not merged and developed by a team? -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d792b1c.7030...@bzed.de
Re: new scripts and patches for devscripts
On 2011-03-10, Carsten Hey wrote: > One way to have both, all members of the devscripts team keep their > current vim in maintaining it, and not wasting the potential developer > resources of these two DDs, could be the following: > > Package: devscripts > Maintainer: Devscripts Devel Team > Recommends: devscripts-python > > Package: devscripts-python > Maintainer: Devscripts Python Devel Team > Recommends: devscripts That's salomonic. I hope people notice that. Splitting it at arbitrary language boundaries instead of sharing a common repository and getting their act together... and to arrange for two languages in use... would make little baby Jesus cry. Especially as you admit that it's temporary until someone comes along with Python knowledge and happens to maintain devscripts. Isn't debian-goodies similar? Do we need a -python and -perl there, too? There's no technical reason for it. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrninia01.49h.tr...@kelgar.0x539.de
Re: new scripts and patches for devscripts
On Thu, Mar 10, 2011 at 12:48 PM, Stefano Zacchiroli wrote: > Also, considering we are talking about Python and not, say, my beloved > OCaml, I wouldn't be surprised to discover that among active Debian > developers we have nowadays more Python knowledge than Perl knowledge > (but I'm already regretting starting this potential troll ...). Back to > numbers, according to [1] already in Debian 4.0 the number of SLOC in > the archive of Python vs Perl was very close (2.5% vs 2.8%) with a > strong growing trend for Python. > > To conclude with an obvious argument, rewriting useful tools which are > known to work and which are currently maintained by a derived distro, > when they are already written in a popular language, doesn't seem to be > the smartest thing to do to me. I completely agree that rewriting the tools isn't a useful effort. I was more concerned that there had been significant development done on scripts that were intended to be proposed to devscripts and yet were intentionally being written in a language that I had previously expressed to Benjamin wasn't used in devscripts. I'm not categorically opposed to having Python scripts in devscripts, as I do grok Python. My resistance was more due to the process around the proposed contributions and posing the barrier to acceptance as purely an added dependency. Also, while Benjamin and Stefano have offered to support the potential new scripts, how does that help with the existing scripts which Benjamin stated concern about? Last we spoke, he wasn't comfortable with Perl, so while they may support their scripts within devscripts, how much does it really buy for the devscripts package as a whole? Is it worth moving them or easier to just keep them in ubuntu-dev-tools? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinJC2AHouG=prenzbpod0ls4dxzmygvbmrwo...@mail.gmail.com
Bug#617707: ITP: libfile-listing-perl -- module to parse directory listings
Package: wnpp Owner: Nicholas Bamber Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libfile-listing-perl Version : 6.00 Upstream Author : Gisle Aas * URL : http://search.cpan.org/dist/File-Listing/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to parse directory listings File::Listing exports a single function called parse_dir(), which can be used to parse directory listings. The first parameter to parse_dir() is the directory listing to parse. It can be a scalar, a reference to an array of directory lines or a glob representing a filehandle to read the directory listing from. The second parameter is the time zone to use when parsing time stamps in the listing. If this value is undefined, then the local time zone is assumed. The third parameter is the type of listing to assume. Currently supported formats are 'unix', 'apache' and 'dosftp'. The default value 'unix'. Ideally, the listing type should be determined automatically. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d792590.1020...@periapt.co.uk
Re: new scripts and patches for devscripts
* Stefano Zacchiroli [2011-03-10 18:48 +0100]: > The argument of maintenance burden is in general a valid one, but IME > maintenance burden in devscripts is more limited by the amount of > people who are interested in maintaining a specific (dev)script than > by the needed language knowledge. ... > > To conclude with an obvious argument, rewriting useful tools which are > known to work and which are currently maintained by a derived distro, > when they are already written in a popular language, doesn't seem to > be the smartest thing to do to me. I agree with above arguments, but my conclusion is a different one than what you seem to imply in yours. James Vega seems to be the most active devscripts maintainer these days, and he does this (as far as I know) in his spare time. If he does not want to have python scripts in it, I see no justification to force him to do so. I also see no reason to try hard to convince him after he clearly stated his point of view. One way to have both, all members of the devscripts team keep their current vim in maintaining it, and not wasting the potential developer resources of these two DDs, could be the following: Package: devscripts Maintainer: Devscripts Devel Team Recommends: devscripts-python Package: devscripts-python Maintainer: Devscripts Python Devel Team Recommends: devscripts If including other languages in the new package would be planned, naming it devscripts-extra or similar instead could be helpful. An alternative to the above is to rename devscripts to devscripts-base or -core, name the new binary package devscripts and let it depend on devscripts-base. If the devscripts maintainers would change their mind in future, these packages could be merged. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310191522.ga10...@furrball.stateful.de
Re: new scripts and patches for devscripts
On Thu, Mar 10, 2011 at 06:32:28PM +0100, Mehdi Dogguy wrote: > >get-build-deps > Is this an alias for "apt-get build-dep $1"? No, it's a tool that's been long missing from a Debian as a standard interface - "install the build-dependencies for the package in my current directory". This may not be the best implementation/name/semantics, but there's definitely a gap to be closed there, as 'dpkg-checkbuilddeps' provides no easy way to feed the missing package list to apt, and 'apt-get build-deps' can't look at the local directory. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Removal of wanna-build from sbuild
On 2011-03-10, Hector Oron wrote: > I was planning to start using a wanna-build instance, but i was not > sure which one to use. > As I have not yet started to use any of them I have no real objection > for its removal, on the other hand I would not mind to try to merge > current wb used on buildd with the one shipped in sbuild. Just let me > know your preferences. The two codebases don't have much in common, given that the sbuild one was heavily refactored. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnini46m.3vh.tr...@kelgar.0x539.de
Bug#617700: ITP: xul-ext-custom-tab-width -- Iceweasel/Firefox extension for setting a custom tab width
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor * Package name: xul-ext-custom-tab-width Version : 1.0.1 Upstream Author : Dão Gottwald * URL : http://en.design-noir.de/mozilla/tab-width/ * License : MPL 1.1 Programming Lang: Javascript/XUL Description : Iceweasel/Firefox extension for setting a custom tab width Lets users of Iceweasel, Firefox, and other compatible browsers customize the minimum and maximum tab width. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310175128.4217.43133.reportbug@localhost.localdomain
Re: new scripts and patches for devscripts
On Thu, Mar 10, 2011 at 04:46:01PM +, Lars Wirzenius wrote:
> I suspect most people who want to add something to devscripts don't
> start off by deciding that they want to do that. Instead they have an
> itch they want to scratch, they write something quick to get fix that,
> and then realize that it might be useful for others, and submit it to
> devscripts.
>
> That's certainly what happened to dd-list.
Exactly the same thing happened to me with debcheckout, which I
initially wrote as a fire and forget ack and then lured me into
co-maintaining devscripts with others.
The argument of maintenance burden is in general a valid one, but IME
maintenance burden in devscripts is more limited by the amount of people
who are interested in maintaining a specific (dev)script than by the
needed language knowledge. Given that two DDs have already stepped up to
maintain the Python scripts at hand, the maintenance burden argument
seems moot here.
Also, considering we are talking about Python and not, say, my beloved
OCaml, I wouldn't be surprised to discover that among active Debian
developers we have nowadays more Python knowledge than Perl knowledge
(but I'm already regretting starting this potential troll ...). Back to
numbers, according to [1] already in Debian 4.0 the number of SLOC in
the archive of Python vs Perl was very close (2.5% vs 2.8%) with a
strong growing trend for Python.
To conclude with an obvious argument, rewriting useful tools which are
known to work and which are currently maintained by a derived distro,
when they are already written in a popular language, doesn't seem to be
the smartest thing to do to me.
Cheers.
[1] http://www.springerlink.com/content/c516h8t6l16251l5/
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: new scripts and patches for devscripts
On 08/03/2011 23:01, Benjamin Drung wrote: check-symbols I always hated programs that do "sudo" (and even more those doing it *twice*). And, isn't just unpacking the .deb and checking for ".so" there enough? You could have undefined symbols… but that may not be an issue most of the time, IMO. (when diffing like in this case). pbuilder-dist cowbuilder-dist mk-sbuild Those could be integrated in pbuilder/cowbuilder/sbuild as examples, IMHO. get-build-deps Is this an alias for "apt-get build-dep $1"? pull-debian-source (?) apt-get source $src ? reverse-build-depends This is "build-rdeps", already in devscripts, afaik. suspicious-source what-patch I thought that the reason for this script to exist is to be used by other scripts (like edit-patch, or add-patch) but it seems like it's not. I'm not even sure that it helps beginners since it hides some very basic information that every new maintainer should learn. Am I wrong here? Encouraging people to document how they patch their package could be a better initiative, IMHO. Most of the script are written in Python. Rewriting them to get them included in devscripts is too much work without benefit. devscripts would depend on python then. I suspect that the number of scripts to be moved is quite low. Moreover, most of them are very simple and can be rewritten very easily. Is rewriting them not an option? Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d790b2c.2000...@dogguy.org
Re: Removal of wanna-build from sbuild
Hello Roger, 2011/3/10 Roger Leigh : > This mail is really just to find out: is anyone actually using the > wanna-build package in the archive? popcon indicates that a few > people have it installed, and < 10 have ever used it. Would > migrating to wanna-build.git be realistic for these users? I was planning to start using a wanna-build instance, but i was not sure which one to use. As I have not yet started to use any of them I have no real objection for its removal, on the other hand I would not mind to try to merge current wb used on buildd with the one shipped in sbuild. Just let me know your preferences. Cheers, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikuna7woxzqn-faa7ql0uo0zvffs61w3qd1c...@mail.gmail.com
Re: cdn.debian.net as a project service?
I like the idea of having apt choose the mirror, rather than the admins of cdn.debian.net. It lessens the centralization. Also, it would require fewer changes from mirror admins to participate. On to, 2011-03-10 at 21:55 +0800, Paul Wise wrote: > On Thu, Mar 10, 2011 at 9:46 PM, The Fungi wrote: > > On Thu, Mar 10, 2011 at 01:06:03PM +, Lars Wirzenius wrote: > >> If one has or downloads a list of mirrors, what's a good way to > >> choose the best one? Ping time? > > > > Package: netselect-apt > > Description: speed tester for choosing a fast Debian mirror > > apt-spy is another one. It downloads Packages files from all the > mirrors in a region or country and reports the fastest. Packages files are pretty big, and having to download several of them is quite a stumbling block. If I'm on a metered connection, I don't want to have to download several unnecessary megabytes just to see which mirror is fastest. Ping times, of course, are not a particularly good way to pick a mirror, either. On the other hand, we don't necessarily have to be able to pick the optimal mirror. It's probably good enough to pick a good one. Also, picking the mirror should be just one function (or class or module or whatever) in apt, so everything else could be implemented independent of the choice of heuristic to choose a mirror. Would someone be willing to mentor a GSoC project for this? Or do it themselves? -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299777128.3524.28.ca...@havelock.lan
Re: Removal of wanna-build from sbuild
On 2011-03-10, Roger Leigh wrote: > This mail is really just to find out: is anyone actually using the > wanna-build package in the archive? Given that I know bits of the sbuild.git codebase: Try to run it. If it doesn't immediately explode there might be users. If it does and there are no reports of it, well, then there aren't any. buildd packages regularly just explode with variables being unknown and similar. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnini11o.3s8.tr...@kelgar.0x539.de
Bug#617694: general: rt2860sta reconnect fails wpa2 enterprise peap
Package: general Severity: normal hi, When reconnect to a wpa2 enterprise peap wireless network the network-manager doesn't get connection. The solution I have tested is: right click in network-manager, disable wireless, modprobe -r rt2860sta, load the module again, and enable wireless in network-manager, then it works does it happen to anyone? Greetings -- System Information: Debian Release: 6.0 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310164622.5397.13661.reportbug@eeepc
Re: new scripts and patches for devscripts
On to, 2011-03-10 at 11:28 -0500, James Vega wrote: > I also think that going off and writing scripts in Python when one knows > that devscripts is a Perl and shell project is the wrong way to try to > contribute. One generally tries to work with a project, not write a lot > of code in a language the project isn't using and then come back later > to try and push that code into the project. I suspect most people who want to add something to devscripts don't start off by deciding that they want to do that. Instead they have an itch they want to scratch, they write something quick to get fix that, and then realize that it might be useful for others, and submit it to devscripts. That's certainly what happened to dd-list. devscripts is by nature a collection of tools that are only slightly related. This makes it quite different from the usual kind of package or project. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299775561.3524.16.ca...@havelock.lan
Re: new scripts and patches for devscripts
On Thu, 2011-03-10 at 11:28 -0500, James Vega wrote: > On Thu, Mar 10, 2011 at 11:18 AM, Bernd Zeimetz wrote: > > On 03/09/2011 01:05 AM, Roger Leigh wrote: > >>> Most of the script are written in Python. Rewriting them to get them > >>> included in devscripts is too much work without benefit. devscripts > >>> would depend on python then. > >> > >> Most of the scripts are short. Rewriting would be fairly simple, and > >> may be beneficial in removing the Ubuntu-specific bits. > > > > Python si very common these days, I think allowing Python scripts to go > > into devscripts would bring some more contributors and useful scripts to > > devscripts. I think there is no need to waste a developer's time to > > rewrite working stuff in a different language. > > I also think that going off and writing scripts in Python when one knows > that devscripts is a Perl and shell project [...] devscripts is a project? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: cdn.debian.net as a project service?
The Fungi wrote: > On Thu, Mar 10, 2011 at 01:06:03PM +, Lars Wirzenius wrote: > > If one has or downloads a list of mirrors, what's a good way to > > choose the best one? Ping time? > > Package: netselect-apt > Description: speed tester for choosing a fast Debian mirror > This package provides a utility that can choose the best Debian > mirror by downloading the full mirror list and using netselect to > find the fastest/closest one. Where "fastest" == "least latency", which is a nearly useless metric to use when chosing a mirror. -- see shy jo signature.asc Description: Digital signature
Re: new scripts and patches for devscripts
On Thu, Mar 10, 2011 at 11:18 AM, Bernd Zeimetz wrote: > On 03/09/2011 01:05 AM, Roger Leigh wrote: >>> Most of the script are written in Python. Rewriting them to get them >>> included in devscripts is too much work without benefit. devscripts >>> would depend on python then. >> >> Most of the scripts are short. Rewriting would be fairly simple, and >> may be beneficial in removing the Ubuntu-specific bits. > > Python si very common these days, I think allowing Python scripts to go > into devscripts would bring some more contributors and useful scripts to > devscripts. I think there is no need to waste a developer's time to > rewrite working stuff in a different language. I also think that going off and writing scripts in Python when one knows that devscripts is a Perl and shell project is the wrong way to try to contribute. One generally tries to work with a project, not write a lot of code in a language the project isn't using and then come back later to try and push that code into the project. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTim0xW4m2f2mBGyF=cmdn4hmbixbgy3--hxfe...@mail.gmail.com
Re: new scripts and patches for devscripts
On 03/09/2011 01:05 AM, Roger Leigh wrote: >> Most of the script are written in Python. Rewriting them to get them >> included in devscripts is too much work without benefit. devscripts >> would depend on python then. > > Most of the scripts are short. Rewriting would be fairly simple, and > may be beneficial in removing the Ubuntu-specific bits. Python si very common these days, I think allowing Python scripts to go into devscripts would bring some more contributors and useful scripts to devscripts. I think there is no need to waste a developer's time to rewrite working stuff in a different language. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d78f9de.3010...@bzed.de
Removal of wanna-build from sbuild
sbuild (sbuild.git) builds packages for sbuild, wanna-build and buildd. Of these, only sbuild and buildd are actively maintained. The wanna-build instance used on the buildds is maintained independently in a separate wanna-build.git repository. Given that wanna-build in sbuild.git is not maintained, and is not really usable without all the support scripts in use on the Debian machines which use it, I intend to remove it unless there are any major objections. This mail is really just to find out: is anyone actually using the wanna-build package in the archive? popcon indicates that a few people have it installed, and < 10 have ever used it. Would migrating to wanna-build.git be realistic for these users? Thanks, 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. signature.asc Description: Digital signature
Re: new scripts and patches for devscripts
Benjamin Drung writes ("Re: new scripts and patches for devscripts"):
> Am Mittwoch, den 09.03.2011, 22:28 + schrieb Ian Jackson:
> > udt-* for all applicable *, where "udt" stands for "ubuntu-dev-tools".
>
> Why? These scripts are not ubuntu specific.
To distinguish them from any other scripts for adding, editing and
identifying patches, checking symbols, merging changelogs, etc.
"udt-*" is simply a way to refer to the origin of the scripts.
> Would you rename all scripts in devscripts for "dv-*", where "dv"
> stands for devscripts?
Most of the scripts in devscripts have reasonable names. "debthis"
and "debthat".
However, I think the following are misnamed:
annotate-output
chdist
chdist
cowpoke
dch
dcmd
dcontrol
dget
diff2patches perhaps
getbuildlog
grep-excuses
licensecheck
list-unreleased
manpage-alert
mass-bug
mergechanges
namecheck
rc-alert
svnpath perhaps
tagpending
transition-check
uscan
uupdate
who-uploads
whodepends
I think these could plausibly be provided by some other program which
is unrelated to Debian packaging.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/19832.62307.160258.365...@chiark.greenend.org.uk
Re: binNMU for Arch: all packages.
Le 15/01/2011 18:22, Steve Langasek a écrit :
[...] and require us to use a hackish (>= ), (<< )
construction for all arch:any -> arch:all dependencies just as we already
have to do for arch:all -> arch:any dependencies.
This is as "wrong" as adding artificial versioned build-dependencies, as
is often the case when you are "simulating" a binNMU with a sourceful
upload in the middle of a transition.
Building "manually" the binNMUed arch:all package at the right time, and
uploading it would achieve a better result, IMHO. And then, all the
arch:any packages (if any) can be binNMUed on the buildds as usual, with
explicit dep-waits, without touching the source package.
One way to handle the substvar issue (which would be more correct to me)
is to add the possibility to specify a version constraint modulo binNMU.
So that Julien's example of [1] would look like:
Package: foo
Architecture: all
Package: bar
Architecture: any
Depends: foo (~= ${source:Version})
(if we choose ~= to denote version equality modulo binNMU). In terms of
implementation, it is conceptually similar to depending on a virtual
package that is provided by the corresponding binary with the same
source version.
[1] http://lists.debian.org/debian-devel/2011/01/msg00480.html
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d78f2f5.1000...@debian.org
Re: ${python:Breaks}
Le jeudi 10 mars 2011 à 09:00 -0500, Scott Kitterman a écrit : > The upstream Python position is (I'll paraphrase), "There will not be > a Python 2.8. If there is a new feature release of Python 2 it will be > because someone forked it - it's Free software, so we can't prevent > that". > > There are a lot of things we need to worry about in the Debian Python > world, but I don't think python2.8 is one of them. Now consider that many applications do not support Python micro versions being > 9. This means that if Python 2.7.9 ever needs to be updated, it will be to 2.8.0. Of course, upstream will answer that Python 2.x should be dead at that time. Considering the time (8 years) it took to phase out a package (gtk1.2) with a similar (or actually lower) number of reverse dependencies, I wouldn’t bet on that. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299769921.1147.22.camel@meh
Re: cdn.debian.net as a project service?
On Jo, 10 mar 11, 21:55:57, Paul Wise wrote: > > > > Package: netselect-apt > > Description: speed tester for choosing a fast Debian mirror > > apt-spy is another one. It downloads Packages files from all the > mirrors in a region or country and reports the fastest. In my experience you have to use a combination of both to get a good mirror. netselect is good at finding close mirrors, while apt-spy the ones with good bandwidth. Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: ${python:Breaks}
On Thursday, March 10, 2011 06:15:01 am Raphael Hertzog wrote: > On Thu, 10 Mar 2011, Piotr Ożarowski wrote: > > seriously, THERE WILL BE NO NEW PYTHON 2.X VERSION RELEASED UPSTREAM¹, > > we don't have to worry about 2.X transitions when 2.7 will become the > > only supported one. If you don't like Breaks, I will remove it, it > > really doesn't matter - that's why at the beginning I wasn't generating > > either of these dependencies (in Depends and in Breaks). > > Well, if upstream changes their plans it will to late to fix the > dependencies... The upstream Python position is (I'll paraphrase), "There will not be a Python 2.8. If there is a new feature release of Python 2 it will be because someone forked it - it's Free software, so we can't prevent that". There are a lot of things we need to worry about in the Debian Python world, but I don't think python2.8 is one of them. Scott K signature.asc Description: This is a digitally signed message part.
Re: cdn.debian.net as a project service?
On Thu, Mar 10, 2011 at 9:46 PM, The Fungi wrote: > On Thu, Mar 10, 2011 at 01:06:03PM +, Lars Wirzenius wrote: >> If one has or downloads a list of mirrors, what's a good way to >> choose the best one? Ping time? > > Package: netselect-apt > Description: speed tester for choosing a fast Debian mirror apt-spy is another one. It downloads Packages files from all the mirrors in a region or country and reports the fastest. -- 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 Archive: http://lists.debian.org/AANLkTi=b44b3VkXkpBfh7JfVMpqyrtdbgm=ohojpk...@mail.gmail.com
Re: cdn.debian.net as a project service?
On Thu, Mar 10, 2011 at 01:06:03PM +, Lars Wirzenius wrote:
> If one has or downloads a list of mirrors, what's a good way to
> choose the best one? Ping time?
Package: netselect-apt
Description: speed tester for choosing a fast Debian mirror
This package provides a utility that can choose the best Debian
mirror by downloading the full mirror list and using netselect to
find the fastest/closest one.
It can output a sources.list(5) file that can be used with package
management tools such as apt or aptitude.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110310134634.gw1...@yuggoth.org
Re: Ruby changes for Wheezy
On Thu, 10 Mar 2011, Lucas Nussbaum wrote:
> What is the correct way to override what dpkg-shlibdeps detects?
Either you replace the dependency associated to the interpreters' libraries
by providing debian/shlibs.local (or any other file that you indicate with
-L) or you tell dpkg-shlibdeps to put the dependencies for the .so files
of interest in another variable like ${shlibs:Suggest} (mixing -d and -e
options as appropriate on the command line).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110310134227.ga2...@rivendell.home.ouaza.com
Re: cdn.debian.net as a project service?
On to, 2011-03-10 at 10:22 +0100, Peter Palfrader wrote: > I'd really like to see support for sane mirror selection in apt itself, > possibly with archive support (i.e. list of mirrors somewhere on > ftp.d.o). That would allow apt to for instance retry on a different > server if the first one it tried does not work for some reason, and > maybe even report the problem to a central mirror. If one has or downloads a list of mirrors, what's a good way to choose the best one? Ping time? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299762363.22610.1.camel@tacticus
Re: cdn.debian.net as a project service?
Hi, On Thu Mar 10, 2011 at 12:09:32 +, Philipp Kern wrote: > On 2011-03-10, Mike Hommey wrote: > > On Thu, Mar 10, 2011 at 08:58:55AM +, Lars Wirzenius wrote: > >> What would it take to get cdn.debian.net become a service provided by > >> the project? In other words, cdn.debian.org, instead of cdn.debian.net. > >> If we had cdn.debian.org, we could make it into a default mirror (which > >> could potentially skip one question in the installer), debmirror, > >> pbuilder, piuparts, and other tools that need to have a mirror > >> specified, making it easier to use the tools. It would also be a boon > >> for those who travel a lot. > > Isn't ftp.debian.org resolving to different addresses depending on your > > geolocalization nowadays ? > > security is, ftp.debian.org isn't. It's even special as it's a mirror > that's synced pretty early. our automatism though check if ftp.d.o is to be shutdown for reboot and itself points ftp.d.o to another host in the mirror network. So yes, from time to time ftp.d.o does not point to kassia. Cheers, Martin -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster GPG key http://go.debian.net/B11B627B | GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310125612.gi18...@ftbfs.de
Re: Ruby changes for Wheezy
On 10/03/11 at 12:00 +, Sune Vuorela wrote:
> On 2011-03-10, Lucas Nussbaum wrote:
> > On 09/03/11 at 22:27 +, Ian Jackson wrote:
> >> Lucas Nussbaum writes ("Ruby changes for Wheezy"):
> >> > We are planning a rather large set of changes in Ruby packaging for
> >> > Debian wheezy, and would appreciate some external feedback on our
> >> > proposals.
> >> >
> >> > Our plans are described on
> >> > http://wiki.debian.org/Teams/Ruby/RubyInWheezy
> >> > Don't hesitate to ask for details if needed.
> >>
> >> I think your families of packages
> >> ruby1.8-foo
> >> ruby1.9.1-foo
> >> ruby-foo-common
> >> etc. are overcomplicated. Can you not find a way to make only one
> >> package for each extension, each containing an appropriate collection
> >> of .so files etc. ?
> >
> > what we could do, indeed, is ship all the .so files in the same binary
> > package, and then hack the Depends field to have:
> > ruby1.8 | ruby-interpreter
> >
> > What is the correct way to override what dpkg-shlibdeps detects?
>
> you can override what dpkg-shlibdeps detect, but it sounds like you want
> to write your own shlibs/symbol files that tells
> ruby1.8 | ruby-interpreter for all involved libraries ?
>
> The last part of shlibs files is a free text file that is passed
> verbatim into the depends file.
yes, but I also need to remove the part that says:
libruby1.8, libruby1.9.1, librubinius, libjruby
- Lucas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110310121516.ga19...@xanadu.blop.info
Re: cdn.debian.net as a project service?
On 2011-03-10, Mike Hommey wrote: > On Thu, Mar 10, 2011 at 08:58:55AM +, Lars Wirzenius wrote: >> What would it take to get cdn.debian.net become a service provided by >> the project? In other words, cdn.debian.org, instead of cdn.debian.net. >> If we had cdn.debian.org, we could make it into a default mirror (which >> could potentially skip one question in the installer), debmirror, >> pbuilder, piuparts, and other tools that need to have a mirror >> specified, making it easier to use the tools. It would also be a boon >> for those who travel a lot. > Isn't ftp.debian.org resolving to different addresses depending on your > geolocalization nowadays ? security is, ftp.debian.org isn't. It's even special as it's a mirror that's synced pretty early. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrninhfrs.3b6.tr...@kelgar.0x539.de
Re: Ruby changes for Wheezy
On 2011-03-10, Lucas Nussbaum wrote:
> On 09/03/11 at 22:27 +, Ian Jackson wrote:
>> Lucas Nussbaum writes ("Ruby changes for Wheezy"):
>> > We are planning a rather large set of changes in Ruby packaging for
>> > Debian wheezy, and would appreciate some external feedback on our
>> > proposals.
>> >
>> > Our plans are described on
>> > http://wiki.debian.org/Teams/Ruby/RubyInWheezy
>> > Don't hesitate to ask for details if needed.
>>
>> I think your families of packages
>> ruby1.8-foo
>> ruby1.9.1-foo
>> ruby-foo-common
>> etc. are overcomplicated. Can you not find a way to make only one
>> package for each extension, each containing an appropriate collection
>> of .so files etc. ?
>
> what we could do, indeed, is ship all the .so files in the same binary
> package, and then hack the Depends field to have:
> ruby1.8 | ruby-interpreter
>
> What is the correct way to override what dpkg-shlibdeps detects?
you can override what dpkg-shlibdeps detect, but it sounds like you want
to write your own shlibs/symbol files that tells
ruby1.8 | ruby-interpreter for all involved libraries ?
The last part of shlibs files is a free text file that is passed
verbatim into the depends file.
/Sune
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrninhfb1.rvp.nos...@sshway.ssh.pusling.com
Re: ${python:Breaks}
On Thu, 10 Mar 2011, Piotr Ożarowski wrote: > seriously, THERE WILL BE NO NEW PYTHON 2.X VERSION RELEASED UPSTREAM¹, > we don't have to worry about 2.X transitions when 2.7 will become the > only supported one. If you don't like Breaks, I will remove it, it > really doesn't matter - that's why at the beginning I wasn't generating > either of these dependencies (in Depends and in Breaks). Well, if upstream changes their plans it will to late to fix the dependencies... > What do you want me to do? Can I drop both of them or do you want me to > drop Breaks only? So I would suggest to continue as usual and generate only the versioned Depends. Better safe than sorry. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310111501.gc31...@rivendell.home.ouaza.com
Re: dh_make and dep5
On Thu, Mar 10, 2011 at 09:54:19AM +, Alessio Treglia wrote: > > Should I fill a bug report ? > By reading the changelog [1], it seems the maintainer has already > accomplished that. > > [1] http://goo.gl/oomj3 Yes, see /usr/share/debhelper/dh_make/licenses/ -- WBR, wRAR signature.asc Description: Digital signature
Re: Ruby changes for Wheezy
On 09/03/11 at 22:27 +, Ian Jackson wrote:
> Lucas Nussbaum writes ("Ruby changes for Wheezy"):
> > We are planning a rather large set of changes in Ruby packaging for
> > Debian wheezy, and would appreciate some external feedback on our
> > proposals.
> >
> > Our plans are described on
> > http://wiki.debian.org/Teams/Ruby/RubyInWheezy
> > Don't hesitate to ask for details if needed.
>
> I think your families of packages
> ruby1.8-foo
> ruby1.9.1-foo
> ruby-foo-common
> etc. are overcomplicated. Can you not find a way to make only one
> package for each extension, each containing an appropriate collection
> of .so files etc. ?
what we could do, indeed, is ship all the .so files in the same binary
package, and then hack the Depends field to have:
ruby1.8 | ruby-interpreter
What is the correct way to override what dpkg-shlibdeps detects?
- Lucas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110310104747.ga16...@xanadu.blop.info
Re: new scripts and patches for devscripts
Ian Jackson writes: > udt-* for all applicable *, where "udt" stands for "ubuntu-dev-tools". > [...] > udt-mk-sbuild This command creates a schroot with a named debian or ubuntu release, and adds a useful section to schroot.conf. Adding "udt-" does not make it any less misnamed. :) -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7xvczrz2bt@fsck.linpro.no
Re: cdn.debian.net as a project service?
Hi, On Thu Mar 10, 2011 at 10:22:29 +0100, Peter Palfrader wrote: > On Thu, 10 Mar 2011, Lars Wirzenius wrote: > I'd really like to see support for sane mirror selection in apt itself, > possibly with archive support (i.e. list of mirrors somewhere on > ftp.d.o). That would allow apt to for instance retry on a different > server if the first one it tried does not work for some reason, and > maybe even report the problem to a central mirror. some information about this might be outdated by now, but the idea still stands: http://wiki.debian.org/RedirectProposal Maybe make this a GSoC2011 project? Cheers, Martin -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster GPG key http://go.debian.net/B11B627B | GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310103637.gh18...@ftbfs.de
Re: dh_make and dep5
On to, 2011-03-10 at 10:42 +0100, Mathieu Malaterre wrote: > What is the status of dep5(*) copyright file in debian ? I am using > dh_make for preparing packages, and I had report that the default > generated copyright template should be replaced by a dep5 one. > Should I fill a bug report ? Except for minor tweaks, I consider DEP5 ready, unless someone finds a bug that needs fixing (there's a wording change pending). The final step is inclusion into the debian-policy package. That said, DEP5 is optional, you can use it or not, as you wish. If you don't want to use it, feel free to mark any bugs you get about it as wontfix. If you do want to use it, now's as good a time as any to start, but beware that the Format: field's URL will change once the spec gets included into the debian-policy package. That said, it would be awesome if dh-make would generate DEP5-compliant debian/copyright templates, either by default or optionally. If there isn't a bug about yet, please do file a wishlist one. Thanks. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299751175.23447.22.camel@tacticus
Re: dh_make and dep5
On Thu, Mar 10, 2011 at 9:42 AM, Mathieu Malaterre wrote: > Should I fill a bug report ? By reading the changelog [1], it seems the maintainer has already accomplished that. [1] http://goo.gl/oomj3 -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=VdRwNbx9FmBj9=u1ckacmhjg+_a+2q6f4b...@mail.gmail.com
Re: cdn.debian.net as a project service?
On Thu, Mar 10, 2011 at 5:30 PM, Peter Palfrader wrote: > On Thu, 10 Mar 2011, Paul Wise wrote: > >> On Thu, Mar 10, 2011 at 5:22 PM, Peter Palfrader wrote: >> >> > (i.e. list of mirrors somewhere on ftp.d.o). >> >> We have had the mirrors list on each mirror for a long time: >> ftp://ftp.debian.org/debian/README.mirrors.txt > > That's not exactly machine readable tho. apt-spy consumes it OK, usually. You are right though; it could definitely be made into a better format, .822 or YAML or JSON or any standard format. -- 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 Archive: http://lists.debian.org/AANLkTinPA9tKPssN+VS=K8UFKr-dtxBwZ=gkaetpx...@mail.gmail.com
dh_make and dep5
Hi, What is the status of dep5(*) copyright file in debian ? I am using dh_make for preparing packages, and I had report that the default generated copyright template should be replaced by a dep5 one. Should I fill a bug report ? Thanks, -- Mathieu (*) http://dep.debian.net/deps/dep5/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=j6ry51frapolj6rhqp7q7lfpq-hxcjvm6x...@mail.gmail.com
Re: cdn.debian.net as a project service?
On Thu, 10 Mar 2011, Paul Wise wrote: > On Thu, Mar 10, 2011 at 5:22 PM, Peter Palfrader wrote: > > > (i.e. list of mirrors somewhere on ftp.d.o). > > We have had the mirrors list on each mirror for a long time: > ftp://ftp.debian.org/debian/README.mirrors.txt That's not exactly machine readable tho. -- | .''`. ** Debian ** 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 Archive: http://lists.debian.org/20110310093037.gb7...@anguilla.noreply.org
Re: cdn.debian.net as a project service?
On Thu, Mar 10, 2011 at 5:22 PM, Peter Palfrader wrote: > (i.e. list of mirrors somewhere on ftp.d.o). We have had the mirrors list on each mirror for a long time: ftp://ftp.debian.org/debian/README.mirrors.txt ftp://ftp.iinet.net.au/debian/debian/README.mirrors.txt ftp://ftp.au.debian.org/debian/README.mirrors.txt -- 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 Archive: http://lists.debian.org/AANLkTi=1xhxde9keqh+8iqlzvgy5pbc5lttyh6abv...@mail.gmail.com
Re: cdn.debian.net as a project service?
On Thu, Mar 10, 2011 at 08:58:55AM +, Lars Wirzenius wrote: > What would it take to get cdn.debian.net become a service provided by > the project? In other words, cdn.debian.org, instead of cdn.debian.net. > > If we had cdn.debian.org, we could make it into a default mirror (which > could potentially skip one question in the installer), debmirror, > pbuilder, piuparts, and other tools that need to have a mirror > specified, making it easier to use the tools. It would also be a boon > for those who travel a lot. Isn't ftp.debian.org resolving to different addresses depending on your geolocalization nowadays ? Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310092648.ga13...@glandium.org
Re: cdn.debian.net as a project service?
On Thu, 10 Mar 2011, Lars Wirzenius wrote: > What would it take to get cdn.debian.net become a service provided by > the project? In other words, cdn.debian.org, instead of cdn.debian.net. I think DNS hacks are the wrong approach in the long run. The recursors people use are no longer always close to themselves. Even if they were, geodns does not always give the right answer - we are seing this problem now already with security, and that's very coarse having only per-continent resolution. The addition of the new south american mirror made stuff worse for some parts of Uruguay because their net to north america is way better than their link to Brazil. Playing well with dnssec is another concern. I'd really like to see support for sane mirror selection in apt itself, possibly with archive support (i.e. list of mirrors somewhere on ftp.d.o). That would allow apt to for instance retry on a different server if the first one it tried does not work for some reason, and maybe even report the problem to a central mirror. Cheers, weasel -- | .''`. ** Debian ** 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 Archive: http://lists.debian.org/20110310092229.ga7...@anguilla.noreply.org
Re: cdn.debian.net as a project service?
Lars, This is ARAKI (a...@debian.org), maintainer of cdn.debian.net. Thanks for using cdn.debian.net and your good suggestion. I think we need more resource to modify some points as follows, - IPv6 support - More mirror list maintainer - Using GeoCityLite - DNS servers on other countries. # We all DNS server of cdn.debian.org are located in Japan. - Integration/Corporation related service Any help, suggest welcome. ARAKI On Thu, Mar 10, 2011 at 5:58 PM, Lars Wirzenius wrote: > What would it take to get cdn.debian.net become a service provided by > the project? In other words, cdn.debian.org, instead of cdn.debian.net. > > If we had cdn.debian.org, we could make it into a default mirror (which > could potentially skip one question in the installer), debmirror, > pbuilder, piuparts, and other tools that need to have a mirror > specified, making it easier to use the tools. It would also be a boon > for those who travel a lot. > > -- > Blog/wiki/website hosting with ikiwiki (free for free software): > http://www.branchable.com/ > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/1299747535.3524.12.ca...@havelock.lan > > -- ARAKI Yasuhiro a...@debian.org http://debiancdn.appspot.com/managesurrogate cdn.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=9x7nzqq7urlxq0m1torpskre67qtytc_zy...@mail.gmail.com
${python:Breaks}
[Raphael Hertzog, 2011-03-09]
> On Wed, 09 Mar 2011, Piotr Ożarowski wrote:
> > [Josselin Mouette, 2011-03-06]
> > > You might “like” Breaks, but this:
> > > Depends: python
> > > Breaks: python (>= 2.8), python (<< 2.5)
> > > has the same semantics as:
> > > Depends: python (>= 2.5), python (<< 2.8)
> >
> > Yes it does; if you will not add ${python:Breaks} in debian/control,
> > that's what dh_python2 will generate actually.
>
> Having a different behaviour depending on whether a variable is listed in
> a dependency or not does not look like good design to me.
>
> > Packages with public modules do not really care about default Python
> > version usually so why should they depend on python package¹?
> >
> > [¹] if package ships .py files, there's a dependency on python package
> > due to pycompile/pyclean scripts, but if package is providing .so files
> > only, there's no need for "python" in Depends
>
> This might be true but it smells like a useless optimization at the cost
> of abusing the Breaks field. First of because you use it like "IsBrokenBy"
> and then because Breaks is usually used to force the upgrade of the broken
> package to a non-broken version. But you're not using it that way and I'm
> not sure how well APT will cope with this.
>
> > > What is the point of doing that?
> >
> > Breaks will warn user if an upgrade of python can break some scripts with
> > /usr/bin/python in shebang, but python-foo packages can still be usable so
> > I prefer Breaks (because it's easier to override).
>
> I really don't understand your point. If the default python is not
> supported by python-foo, then it won't be coinstallable whether you're
> using Depends or Breaks...
seriously, THERE WILL BE NO NEW PYTHON 2.X VERSION RELEASED UPSTREAM¹,
we don't have to worry about 2.X transitions when 2.7 will become the
only supported one. If you don't like Breaks, I will remove it, it
really doesn't matter - that's why at the beginning I wasn't generating
either of these dependencies (in Depends and in Breaks).
What do you want me to do? Can I drop both of them or do you want me to
drop Breaks only?
[¹] I guess I have to repeat it in my every mail, people still see
problems that will not exist in few months
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110310091056.gg30...@piotro.eu
Bug#617646: ITP: liblwp-mediatypes-perl -- module to guess media type for a file or a URL
Package: wnpp Owner: Nicholas Bamber Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: liblwp-mediatypes-perl Version : 6.01 Upstream Author : Gisle Aas * URL : http://search.cpan.org/dist/LWP-MediaTypes/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to guess media type for a file or a URL LWP::MediaTypes provides functions for handling media (also known as MIME) types and encodings. The mapping from file extensions to media types is defined by the media.types file. If the ~/.media.types file exists it is used instead. For backwards compatibility it will also look for ~/.mime.types. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d78945c.3040...@periapt.co.uk
cdn.debian.net as a project service?
What would it take to get cdn.debian.net become a service provided by the project? In other words, cdn.debian.org, instead of cdn.debian.net. If we had cdn.debian.org, we could make it into a default mirror (which could potentially skip one question in the installer), debmirror, pbuilder, piuparts, and other tools that need to have a mirror specified, making it easier to use the tools. It would also be a boon for those who travel a lot. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299747535.3524.12.ca...@havelock.lan
