Alcohol Tester Supplier
Dear Sir or Madam, Shenzhen Plutus Electronics Co., Ltd is a professional Alcohol manufacturer and supplier. Hope Plutus can be your supplier.We specialized in developing, producing and marketing electronics products. Our main products are Alcohol Tester,Key Chain, Flashing Products. One of our Alcohol Tester, model number is PLT-AHT658V, it's main features as follows: ●Digital alcohol tester with 0.01 % BAC (0.1 g/l) increment for reading ●Detect range: 0.00~0.19 % BAC & 0.0~1.9 g/l ●Alert level calibrated ●Quick response and resume ●Auto power off ●Accurate degree：± 0.00%BAC at 0.05（ 0.08 ） %BAC or ± 0.0g/L at 0.5 （ 0.8 ） g/L ●Repetitiveness：± 0.00%BAC at 0.05 （ 0.08 ） %BAC or ± 0.0g/L at 0.5 （ 0.8 ） g/L ●Compatibility：± 0.00%BAC at 0.05 （ 0.08 ） %BAC or ± 0.0g/L at 0.5 （ 0.8 ） g/L ●Key chain ●Use 2 * AAA alkaline batteries (not included) ●Unit dimensions: 79.5 *32 *19 mm Our overseas market are Europe, America, Middle East Asia, Asia, South America etc. We are famous for high quality in domestic and overseas market, established long term, stable and good relationship with them. We are waiting for your enquiry. For further information please visit our website at http://www.szplutus.com or contact with me at [EMAIL PROTECTED] Thanks and best regards, Rosemary - 抢注雅虎免费邮箱-3.5G容量，20M附件！ <>
Re: Announcing LHCP - Linux Hardware Compatibility Project
At Mon, 29 Jan 2007 16:23:57 +0100, Phil Knirsch wrote: > We've recently started working on a project called Linux Hardware > Compatibility > Project or in short LHCP. Goals are: > > * Provide a list of working hardware for people wanting to buy a new > computer > * Provide an idea on what hardware our/your distribution in run on > * Provide a list of hardware we need to improve support for > * Provide an interface to all above that allows simple and complicated > queries > * Get the user a list of thing that should work and a way to test that > * Tell the user how good his hardware is supported > > There have been several Hardware Compatibility lists from vendors and > other projects in the past, but most of them were limited in one > aspect or another - so we start our own. Interesting. I have been hosting own simple HCL at http://kmuto.jp/debian/hcl/. > For development discussions a mailing list has been set up here: > https://www.redhat.com/mailman/listinfo/lhcp-devel Subscribed :) Thanks, -- Kenshi Muto [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted linux-modules-di-amd64-2.6 1.03 (source amd64)
Mike Hommey <[EMAIL PROTECTED]>, 2007-01-29 22:50 +0100: > On Tue, Jan 30, 2007 at 06:22:20AM +0900, Michael(tm) Smith <[EMAIL > PROTECTED]> wrote: > I wonder what you are talking about, seems like your mail is kind of > corrupted. Yeah, bizarre result of having two console windows open, with mutt instances for two different mail accounts, and text somehow inadvertently finding its way from one to other. But I wouldn't rule out simple pilot error -- it's 7:30 am here in Tokyo (well, actually Shonan Fujisawa) and I've been up all night... --Mike -- Michael(tm) Smith http://people.w3.org/mike/ smime.p7s Description: S/MIME cryptographic signature
source code "forensic" practices
Dear Debian People, I ITPed a package which unfortunately ended up not providing original sources (sources everybody gets were indentation removed). Unreasonable denial of providing original source forced me to question good intent of the author to provide useful and spam/crap-free software. Since I could not possibly to examine that code, I've decided to look at other software written by the same author, and which has original source code, which probably nobody else ever examined anyways. The question is: are there any helper tools for doing source code validation subject to possibly available snippets of code which might be for illegal activity (ie sending out private information, or serve as backdoors, etc)? May be some language specific tools (JS, Java, python) which could catch snippets intended for data transmission/receival? Sniffing of the traffic of running app is an effective utility but can't always apply (I could write a code which sends out information only once in a month on a random date/time, I doubt that anyone would monitor/analyze all the monthly traffic to catch me), especially if a particular application is an extension to the bigger application (like mozilla products' extensions). Especially it becomes a hard task in checking extensions to Internet appliances such as web-browsers, which can provide reach API for the purpose of data transmission/receipt, and packets from a specific extension would be buried in the rest of the traffic coming out from the application. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted linux-modules-di-amd64-2.6 1.03 (source amd64)
On Tue, Jan 30, 2007 at 06:22:20AM +0900, Michael(tm) Smith <[EMAIL PROTECTED]> wrote: > Hi Frans, > > /* my attempts at answering a few of your questions, based on my own */ > /* limited experience trying to figure out specs written in Japanese */ > > Files: > > 373d03c1c9c91fa5926da35b0580b36b 664 debian-installer optional > > linux-modules-di-amd64-2.6_1.03.dsc > > e35678f6eea8e123d9599059033be802 1538 debian-installer optional > > linux-modules-di-amd64-2.6_1.03.tar.gz > > 155e800ccbb38988969c1503e9598a27 51196 debian-installer extra > > loop-aes-modulesSupports 2.6.18-4 > > I don't know any specifics about the XHTMLsomething like, "-Print part, but m" > > iD8DBQFFvjlI guess agminformation / > > contained in the tRNS chunSupports k > > JtpRANMcP+M4rwhzWG3en1E= > > Size restriction as defined in section 5.5.2.4 I wonder what you are talking about, seems like your mail is kind of corrupted. > /* I think 〜参照 is used just like the way we use "See ~" or */ You're right. For example 前記参照 would be "See above". > Not as far as I can see. I think "〜対応する" is used in specs in > the same way we used "Supports ~" in English. So above seems to > say that it supports it, not that it bans it. 〜対応する means corresponding/equivalent. I don't have the full phrase so I can't tell you what corresponds to what, but that's the meaning of 〜対応する. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted linux-modules-di-amd64-2.6 1.03 (source amd64)
Hi Frans, /* my attempts at answering a few of your questions, based on my own */ /* limited experience trying to figure out specs written in Japanese */ > Files: > 373d03c1c9c91fa5926da35b0580b36b 664 debian-installer optional > linux-modules-di-amd64-2.6_1.03.dsc > e35678f6eea8e123d9599059033be802 1538 debian-installer optional > linux-modules-di-amd64-2.6_1.03.tar.gz > 155e800ccbb38988969c1503e9598a27 51196 debian-installer extra > loop-aes-modulesSupports 2.6.18-4 I don't know any specifics about the XHTMLsomething like, "-Print part, but m" > iD8DBQFFvjlI guess agminformation / > contained in the tRNS chunSupports k > JtpRANMcP+M4rwhzWG3en1E= Size restriction as defined in section 5.5.2.4 /* I think 〜参照 is used just like the way we use "See ~" or */ Not as far as I can see. I think "〜対応する" is used in specs in the same way we used "Supports ~" in English. So above seems to say that it supports it, not that it bans it. --Mike Handles color transmission -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: restricted sourceless ARM uploads
I know I'm late to the party, but one big win about qemu build servers is that they can be instantly cloned, replicated, and shared. We can't do that with real hardware. --rich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Music 2.0 forum at Mood (Wed Jan 31)
You and your guests are invited to a special industry party. Wednesday, January 31, 2007 Co-hosted by Music 2.0. Free event. Private Red Carpet Opening at 7:00pm. Doors open at 8:00pm until 2:00am. Dining until 11:00pm. Special Performances by Stoll Vaughn and Mighty Mo Rogers. Music Spun by Celebrity DJ "Crash" (www.djcrash.com) Jackets requested. Upscale Attire enforced. Dinner/ Table Service RSVP: Diana 714-267-7218 or [EMAIL PROTECTED] -- About Music 2.0: Music 2.0 brings together industry leaders to analyze trends and developments affecting the business of digital music, including musics growing portability, digital distribution, piracy, desktop music production, industry consolidation, online marketing, and the rapidly expanding number of services targeting music consumers. Who will be attending: Consumer electronics manufacturers, Music and entertainment marketing, Record labels, majors and indies, Artists, Retailers, Marketers and advertisers, Software developers, Songwriters, Business and legal affairs and general counsel, Investors and venture capitalists, Digital distribution services, Professional services including managers, agents, attorneys, Hardware makers and manufacturers, Digital asset management, Digital Rights Management, Digital Media technologies, Wireless and mobile companies, Studios, Music Publishers, Agents, Marketing and advertising. Companies Involved include: (Partial List) AOL Music, All Media Guide, Bango, Big Champagne, BMI, Capitol records, Control room, Coolfer.com, Digimarc, Digonex, eMusic, EMI, Entertainment Media Workd, GigaVox Media, GlobalCollect, Goldring Hertz Lichtenstein, Gracenote, Harry Fox Agency, HipHopWest, Hollywood records, Hollywood Reporter, Hum Music, Ioda, Ipsos, isuppli, Javien, John Mellencamp, lala.com, Lionsgate, Live Nation, Logitech, Mitchel Sillberberg Knupp, Mediaguide, Microsoft, Mix & Burn, MusicIP, Musicwave, Mystrands, Navio, Nettwerk Productions, Optimal Payments, Palm, Pandora, PassAlong, Payment One, Peermusic, Pipeline, Plan Nine, Podshow, Promptu, Radar research, Real Networks, SanDisk, Sirius Radio, SNOCAP, Sony Corporation, SpotDJ, TNC, All Access Group, Ticketmaster, Trans World Ent, UrbanWorld Wireless, Universal Music Enterprises, Virgin Entertainment Group, Virgin Mobile, Virtual Venues, VOY Music, Warner Music Group, Westwood One, Xingtone, Yahoo, YouTube -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Announcing LHCP - Linux Hardware Compatibility Project
Hello everyone.
We've recently started working on a project called Linux Hardware
Compatibility
Project or in short LHCP. Goals are:
* Provide a list of working hardware for people wanting to buy a new
computer
* Provide an idea on what hardware our/your distribution in run on
* Provide a list of hardware we need to improve support for
* Provide an interface to all above that allows simple and complicated
queries
* Get the user a list of thing that should work and a way to test that
* Tell the user how good his hardware is supported
There have been several Hardware Compatibility lists from vendors and
other projects in the past, but most of them were limited in one
aspect or another - so we start our own.
To achive this we are building a modular framework to generate, collect,
submit
and analyze information about all components of systems running Linux
and how well each component works.
The project is currently in it's infancy, but following the typical
pragmatic
approach of open source projects ("Release early, release often!") we've
decided to already officially announce it.
Current status is that the basic GUI application for testing is up and
running
with some test modules. We're now in the process of writing the first real
data collection and test modules and are currently starting to design the
server end of the side.
The home page of the project can be found here:
https://hosted.fedoraproject.org/projects/LHCP
If you want to take a look at the current source code you can checked it out
using Mercurial in read only mode like this:
hg clone http://hg.fedoraproject.org/hg/hosted/LHCP
For development discussions a mailing list has been set up here:
https://www.redhat.com/mailman/listinfo/lhcp-devel
Although the project is hosted under Fedora we're aiming it to be very
distribution independant, so supporting other distributions should be
easy to
do. We have some basic requirements on what is needed on the system for
it to
simply work, but a lot of things will be optional.
Happy hacking,
Read ya, Phil & Fabi
--
Philipp Knirsch | Tel.: +49-711-96437-470
Development | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <[EMAIL PROTECTED]>
Hauptstaetterstr. 58 | Web: http://www.redhat.de/
D-70178 Stuttgart
Motd: You're only jealous cos the little penguins are talking to me.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: http://rerun.lefant.net/checklib - stopped updating?
* Christian Aichinger <[EMAIL PROTECTED]> [2007-01-29 11:34]: > If you have any questions about setting up the beast, don't hasitate > to mail me, though. Perhaps I'll even find some time to revive > rerun.lefant.net/checklib And we will get one of the LH machines to run checklib again via cron. The current box is a bit slow... yours Martin -- http://martin.wuertele.net/ -- Debian -- OFTC -- SPI -- [EMAIL PROTECTED] "You're attempting to login to Windows and there's a significant delay between entering your credentials and the desktop appearing. What is your first concern?" - "Your network is down!" - "No, your first concern is who the hell's overwritten your Linux desktop install!" -- Simon Travaglia, BOFH: Putting a price on the Boss -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: update on binary upload restrictions
Tollef Fog Heen a écrit : > * Joey Hess > > | > (b) source only uploads are in my experience very often badly tested > | > if they're even tested at all. For a long time after Ubuntu > | > switched to source only uploads, it was really obvious that a > | > large number of them hadn't even been test built, never mind > | > installed or used.[3][4] > | > | Hmm, are you implying that it eventually got better? > > It seems to have gotten better now, yes. However, people are often > quite happy to just throw source at the buildds until it builds, at > least unless they're told not to. This is less of a problem for > Ubuntu than Debian because Ubuntu's slowest arch is quite fast, while > doing the same to the Debian ARM port would make the buildd (and the > buildd operator) very unhappy. > They are fast ARM machines, one other solution would be to have fast ARM build daemons. But then the problem would be for m68k. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: update on binary upload restrictions
Charles Plessy <[EMAIL PROTECTED]> writes: > Le Mon, Jan 29, 2007 at 10:42:25AM +0100, Goswin von Brederlow a écrit : >> Santiago Vila <[EMAIL PROTECTED]> writes: >> >> > On Sun, 28 Jan 2007, Benjamin Seidenberg wrote: >> > >> >> If we do go to source-only uploads, could this problem be avoided by >> >> having arm and other slow arches wait until at least one other arch >> >> successfully builds the package? >> > >> > I think that would be a good idea anyway, even if we do not go to >> > source-only uploads. There is no point in wasting expensive CPU cycles >> > to build a package if it FTBFS on every architecture. >> >> I would rather do the opposite. Stop building a package when it fails >> on other archs. Thing about the (unlikely) situation that arm is >> idle. Nothing to build. Now someone uploads foobar. Should we wait or >> just try? If it works we saved time. If it fails only idleing is lost. > > Or how about having the package rejected before being queued if it is > not buildable on a (p|cow)builder installed on a fast machine, for > instance? You could make the i386 buildds special (or whichever arch is the most complete) and have it build a newly uploaded package first. Only if that succeeds throw the package at the other arches. This would need overrides for packages that don't exist on i386. Matthias
Re: buildd stuff
On Mon, Jan 29, 2007 at 11:04:12AM +0100, Aurelien Jarno wrote: > Goswin von Brederlow a écrit : > > Aurelien Jarno <[EMAIL PROTECTED]> writes: > > > >> One first step would be to keep the current build daemons maintainers > >> (ie the person who signs the upload), and give and access to some > >> porters to the wanna-build database. This way they could reschedule > >> failed builds, add dep-wait, or do binNMU. If I am right Steve Langasek > >> already has access to the wanna-build database of all architectures, so > >> that should not be a technical problem. > > > > I think from a technical point every buildd admin has access to > > wanna-build for all architectures. It is just policy not to mess > > around in someone elses backyard. > > You think wrong. Using the public ldap database, you can find the > following details: Why is w-b access so sacred? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to maintain packaging files for multiple distributions in the same tree?
On Mon, Jan 29, 2007 at 10:20:23AM +0100, Goswin von Brederlow wrote: > In stable/testing/unstable you have releases with a fixed version that > can only split of from the main trunk. Any change to stable/testing > MUST be made special for the old version in stable/testing and forks > off the main developement on its own course. There is no developement > going on in stable/testing, just bugfixes. You often have to prepare > backports for patches from unstable to share fixes. > > In Ubuntu you have a parallel version. You split of from the main > trunk but you follow parallel to it at a small distance. For every new > main version you want a new ubuntu version. Ubuntu versions aren't a > branch but rather a filter on top of the main release. The main > release changes, the filter remains constant (hopefully). The meaning of your "filter" analogy above isn't clear to me. By "Ubuntu versions" do you mean "releases of Ubuntu" or "Ubuntu versions of packages derived from Debian"? > Branches don't work so well for ubuntu as you have to pull over the > changes from the main branch to the ubuntu branch on every > release. Which means (unneccessary) work. It is work, yes, but in many cases it is necessary, and we do quite a bit of it at present. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd stuff
On Mon, Jan 29, 2007 at 11:04:12AM +0100, Aurelien Jarno wrote: > wb-i386: ajt, rmurray, troup, vorlon > wb-mips: ajt, rmurray, vorlon > There is no wb-amd64 nor wb-mipsel. I don't know why. amd64 is included in wb-i386; mipsel is included in wb-mips. Cheers, aj signature.asc Description: Digital signature
Re: prospect of non-US?
On Jan 29, Josip Rodin <[EMAIL PROTECTED]> wrote: > What is the current prospect for the non-US archive? It has been dead for a long time and apparently there are no plans to resurrect it. -- ciao, Marco signature.asc Description: Digital signature
Re: update on binary upload restrictions
Le Mon, Jan 29, 2007 at 10:42:25AM +0100, Goswin von Brederlow a écrit : > Santiago Vila <[EMAIL PROTECTED]> writes: > > > On Sun, 28 Jan 2007, Benjamin Seidenberg wrote: > > > >> If we do go to source-only uploads, could this problem be avoided by > >> having arm and other slow arches wait until at least one other arch > >> successfully builds the package? > > > > I think that would be a good idea anyway, even if we do not go to > > source-only uploads. There is no point in wasting expensive CPU cycles > > to build a package if it FTBFS on every architecture. > > I would rather do the opposite. Stop building a package when it fails > on other archs. Thing about the (unlikely) situation that arm is > idle. Nothing to build. Now someone uploads foobar. Should we wait or > just try? If it works we saved time. If it fails only idleing is lost. Or how about having the package rejected before being queued if it is not buildable on a (p|cow)builder installed on a fast machine, for instance? Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
prospect of non-US?
Hi, What is the current prospect for the non-US archive? I'm leaning towards removing it from the mirror submission web page, it seems like clutter there. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd stuff
Goswin von Brederlow a écrit : > Aurelien Jarno <[EMAIL PROTECTED]> writes: > >> One first step would be to keep the current build daemons maintainers >> (ie the person who signs the upload), and give and access to some >> porters to the wanna-build database. This way they could reschedule >> failed builds, add dep-wait, or do binNMU. If I am right Steve Langasek >> already has access to the wanna-build database of all architectures, so >> that should not be a technical problem. > > I think from a technical point every buildd admin has access to > wanna-build for all architectures. It is just policy not to mess > around in someone elses backyard. You think wrong. Using the public ldap database, you can find the following details: wb-alpha: ajt, rmurray, troup, vorlon wb-arm: ajt, rmurray, troup, vorlon wb-hppa: ajt, bdale, rmurray, stephen, taggart, tausq, troup, vorlon, willy wb-hurd-i386: ajt, jbailey, rmurray wb-i386: ajt, rmurray, troup, vorlon wb-ia64: ajt, bdale, dsp, koala, rmurray, stephen, taggart, tausq, troup, vorlon, willy wb-m68k: adconrad, ajt, branden, cts, rmurray, roman, schmitz, smarenka, troup, vorlon, waldi, wouter, younie wb-mips: ajt, rmurray, vorlon wb-ppc: ajt, daenzer, dan, michaelw, rmurray, schmitz, smarenka, troup, vorlon wb-s390: ajt, cowboy, gt, jr, rmurray, sgybas, vorlon, waldi wb-sparc: ajt, bcollins, jbailey, rmurray, troup, vorlon There is no wb-amd64 nor wb-mipsel. I don't know why. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: update on binary upload restrictions
On Monday 29 January 2007 10:42:25 Goswin von Brederlow wrote: > Santiago Vila <[EMAIL PROTECTED]> writes: > > On Sun, 28 Jan 2007, Benjamin Seidenberg wrote: > >> If we do go to source-only uploads, could this problem be avoided by > >> having arm and other slow arches wait until at least one other arch > >> successfully builds the package? > > > > I think that would be a good idea anyway, even if we do not go to > > source-only uploads. There is no point in wasting expensive CPU cycles > > to build a package if it FTBFS on every architecture. > > I would rather do the opposite. Stop building a package when it fails > on other archs. Thing about the (unlikely) situation that arm is > idle. Nothing to build. Now someone uploads foobar. Should we wait or > just try? If it works we saved time. If it fails only idleing is lost. > > > Even better would be to take the number of architectures > failed/succeeded/needs-build into account when deciding on the > priority of a package. The more archs fail the lower a source drops in > needs-build, the more succeed the higher it rises. The more backlog a > port has the more successfull this priority would be, i.e. it works > best for the problematic archs that need it. We need to distinguish between the multiple reasons for potential failures, though. I do not know about the latest developments of the build daemon, so maybe my example is now outdated, but a failure because of missing build dependencies should not be punished since the package may be fine per se. Problems with available memory, disk space etc would fall under the same category. Steffen pgpiW23kxjjei.pgp Description: PGP signature
Re: How to maintain packaging files for multiple distributions in the same tree?
On Mon, Jan 29, 2007, Goswin von Brederlow wrote: > In Ubuntu you have a parallel version. You split of from the main > trunk but you follow parallel to it at a small distance. For every new > main version you want a new ubuntu version. Ubuntu versions aren't a > branch but rather a filter on top of the main release. The main > release changes, the filter remains constant (hopefully). > > Branches don't work so well for ubuntu as you have to pull over the > changes from the main branch to the ubuntu branch on every > release. Which means (unneccessary) work. Are you comparing in the general case of packages in Debian and in Ubuntu? I think it's possible to manage software with a trunk for development and regular "snapshots" of this trunk for either a Debian/unstable or an Ubuntu upload or both. (I agree on what you said for uploads to testing or stable.) -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: update on binary upload restrictions
Santiago Vila <[EMAIL PROTECTED]> writes: > On Sun, 28 Jan 2007, Benjamin Seidenberg wrote: > >> If we do go to source-only uploads, could this problem be avoided by >> having arm and other slow arches wait until at least one other arch >> successfully builds the package? > > I think that would be a good idea anyway, even if we do not go to > source-only uploads. There is no point in wasting expensive CPU cycles > to build a package if it FTBFS on every architecture. I would rather do the opposite. Stop building a package when it fails on other archs. Thing about the (unlikely) situation that arm is idle. Nothing to build. Now someone uploads foobar. Should we wait or just try? If it works we saved time. If it fails only idleing is lost. Even better would be to take the number of architectures failed/succeeded/needs-build into account when deciding on the priority of a package. The more archs fail the lower a source drops in needs-build, the more succeed the higher it rises. The more backlog a port has the more successfull this priority would be, i.e. it works best for the problematic archs that need it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: x86 buildd for experimental ?
On Mon, Jan 29, 2007, Goswin von Brederlow wrote: > I think that is a shortcomming of apt though. > apt-get install foo=1.2-3 > will fetch foo 1.2-3 from whatever repository that has that > version. But with > Package: foo > Version: 1.2-3 > Depends: bar (= 1.2-3) > apt-get will NOT fetch bar 1.2-3 unless it happens to have the highest > pin and highest version by chance. You mean a shortcoming of apt-get? I think aptitude manages this more naturally. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd stuff
Aurelien Jarno <[EMAIL PROTECTED]> writes: > One first step would be to keep the current build daemons maintainers > (ie the person who signs the upload), and give and access to some > porters to the wanna-build database. This way they could reschedule > failed builds, add dep-wait, or do binNMU. If I am right Steve Langasek > already has access to the wanna-build database of all architectures, so > that should not be a technical problem. I think from a technical point every buildd admin has access to wanna-build for all architectures. It is just policy not to mess around in someone elses backyard. Maybe the [EMAIL PROTECTED] mails could be CCed to a group of existing buildd admins to take care of general problems while specific problems (like a broken chroot) are left to the specific admins. Prospective buildd admins could then also start of by joining that group and getting an education there before being thrown into the deep end of maintaining a full buildd. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: x86 buildd for experimental ?
Loïc Minier <[EMAIL PROTECTED]> writes: > On Thu, Jan 25, 2007, Wouter Verhelst wrote: >> Actually, sbuild uses plain apt-get and apt-cache to handle build deps >> these days; so if apt can handle a dependency, then so can sbuild. >> >> The problem really is the fact that experimental has 'NoAuto: yes' (or >> what is it again) set in its Release file, so unless you explicitly >> specify that you want to download and install from experimental, that's >> not going to happen. > > It's not a problem of "NoAuto: yes": as you note yourself, there's no > way with plain APT to pull from a repository only when it's required. > > You could argue that APT lacks the feature, but I think we need some > higher level program to force APT into installing the correct versions > (just like pbuilder-satisfydepends-experimental does for example). > > -- > Loïc Minier <[EMAIL PROTECTED]> I think that is a shortcomming of apt though. apt-get install foo=1.2-3 will fetch foo 1.2-3 from whatever repository that has that version. But with Package: foo Version: 1.2-3 Depends: bar (= 1.2-3) apt-get will NOT fetch bar 1.2-3 unless it happens to have the highest pin and highest version by chance. I think 'apt-get install' should, at least optionally, override the pin/version restrictions to fullfill dependencies. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to maintain packaging files for multiple distributions in the same tree?
Loïc Minier <[EMAIL PROTECTED]> writes: > On Thu, Jan 25, 2007, Goswin von Brederlow wrote: >> Evil. Don't change control at build time. > > Well, all GNOME packages update their control in the clean target, and > I think this is ok. The GStreamer packages update their packages in > a special "maint" target which is manual; this works okish, but this > gets forgotten from time to time. > >> Beter to generate a debian/control.new from control.in and then fail >> (with a helpfull message) if that differs from debian/control. > > That's an idea if the above mechanisms displease ftpmasters. > > However, it goes against having two controls for Maemo and Debian. > >> I think the simplest thing is to branch. You might want to upload some >> ix to stable-proposed-updates, security or testing-proposed-updates in >> which case your changelog gets additional entries not present in the >> unstable changelog and so on. A branch fits there perfectly. > > I'm not convinced this will work. I can imagine this will either > result in a fork or in a large manual process such as Ubuntu's; in both > cases, the process doesn't encourage pushing the patches back to > Debian (IMO, and from what I've seen). > > -- > Loïc Minier <[EMAIL PROTECTED]> I see a big difference between multiple releases like stable/testing/unstable and a fork or parallel releases like Ubuntu. In stable/testing/unstable you have releases with a fixed version that can only split of from the main trunk. Any change to stable/testing MUST be made special for the old version in stable/testing and forks off the main developement on its own course. There is no developement going on in stable/testing, just bugfixes. You often have to prepare backports for patches from unstable to share fixes. In Ubuntu you have a parallel version. You split of from the main trunk but you follow parallel to it at a small distance. For every new main version you want a new ubuntu version. Ubuntu versions aren't a branch but rather a filter on top of the main release. The main release changes, the filter remains constant (hopefully). Branches don't work so well for ubuntu as you have to pull over the changes from the main branch to the ubuntu branch on every release. Which means (unneccessary) work. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
