Re: About new source formats for packages without patches
On Thu, 25 Mar 2010 17:30:28 -0700 Russ Allbery r...@debian.org wrote: this at this point. I've changed the severity to wishlist instead, which I think more accurately reflects the current severity of this request. That's fair. N: missing-debian-source-format N: N: To allow for possible future changes in the default source format, N: explicitly selecting a source format by creating debian/source/format N: is recommended. N: N: If you don't have a reason to stay with the old format for this N: package, please consider switching to 3.0 (quilt) (for packages with N: a separate upstream tarball) or to 3.0 (native) (for Debian native N: packages). N: N: If you wish to keep using the old format, please create that file and N: put 1.0 in it to be explicit about the source package version. If N: you have problems with the 3.0 format, the dpkg maintainers are N: interested in hearing, at debian-d...@lists.debian.org, the N: (technical) reasons why the new formats do not suit you N: N: Refer to the dpkg-source(1) manual page and N: http://wiki.debian.org/Projects/DebSrc3.0 for details. N: N: Severity: wishlist, Certainty: certain I hope this is a reasonable compromise between the various stances on the new source format. None of this is set in stone, or has gone anywhere other than the Lintian Git repository, and we can definitely change it further based on additional feedback. Much improved, thank you. Now all I need is for dpkg to accept that the absence of debian/source/format is declarative of source format 1.0 and that packages don't need to be changed merely to state the obvious. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpEXpGniZJQZ.pgp Description: PGP signature
Re: About new source formats for packages without patches
On Thu, 25 Mar 2010, Steve Langasek wrote: If it's really so important to the dpkg maintainers that source format 1.0 is declared, why doesn't dpkg-source -b *generate* this content automatically as part of the .diff.gz so that maintainers aren't being asked to take a manual action to assert the status quo? My goal as dpkg maintainer is that Debian converts the maximum number of source packages to the new source formats in the shortest timeframe. (You might not share this goal but that's another matter) The initial plan to achieve this was to auto-convert the source packages (hence the archive rebuild, the numerous bugs filed, and the release goal). I've been convinced that this was not necessarily the right approach for Debian. But I still want to be able to modify dpkg-source to not build 1.0 by default at some point, because it would be weird to use by default a format that we (dpkg maintainers) would consider as deprecated (granted, it's in the long term). At the same time, I've been convinced to change dpkg-source to only try to use one source format instead of having a fallback list (1.0 has this automatic fallback on native packages and people agreed that we should not continue to follow this bad design). We have an opportunity to fix now because if you indicate 3.0 (quilt) you will never build native package by mistake (and if you indicate 3.0 (native) you won't build a non-native package). Of course dpkg-source could autogenerate debian/source/format to 1, but this would mean taking the decision (“I want to continue using the old format”) in place of the maintainer, and it's a bad idea given my goal, just like it was a bad idea to automatically convert source packages to 3.0 (quilt) without the maintainer explicit consent. Taking all those points into account, this lintian warning is the best approach that I found out that respects all points of views [1] and I believe it respects Debian's philosophy of letting the maintainer in total control of his package. Cheers, [1] My point of view as developer that want to see the new formats widely used and the point of view of the maintainers that want control over his package and a guaranty that it won't break in the future. Cf the explanation of Anthony Towns in http://lists.debian.org/87b3a4191003251152r4367118ej35c16abd7fbbf...@mail.gmail.com I really have the feeling to see this antagonism at play in this thread. -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100326081730.gb7...@rivendell
Re: About new source formats for packages without patches
On Fri, 26 Mar 2010, Neil Williams wrote: Now all I need is for dpkg to accept that the absence of debian/source/format is declarative of source format 1.0. That's the case _for now_. packages don't need to be changed merely to state the obvious. They need because the dpkg maintainers have decided that it might not be the case indefinitely. I don't see any significant difference in the wording, the major change is the priority which simply means that less people will see it/take it into account (those that use -I by default). Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100326082538.gc7...@rivendell
Re: About new source formats for packages without patches
Raphael Hertzog a écrit : Note that the lintian message specifically requests to contact us if you decide to stick with 1.0 for such a technical reason. That's done that way so that I can help resolve those problems. No later than this morning I contacted the launchpad guys to allow new source formats in karmic PPA because one DD continued to use 1.0 for this reason. Did they reply? AFAIC, the same applies to jaunty PPA and lenny-backports. 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/4bac70ea.6020...@glondu.net
Re: About new source formats for packages without patches
On Fri, 26 Mar 2010, Stéphane Glondu wrote: Raphael Hertzog a écrit : Note that the lintian message specifically requests to contact us if you decide to stick with 1.0 for such a technical reason. That's done that way so that I can help resolve those problems. No later than this morning I contacted the launchpad guys to allow new source formats in karmic PPA because one DD continued to use 1.0 for this reason. Did they reply? AFAIC, the same applies to jaunty PPA and lenny-backports. Yes, they are going to allow it for karmic PPA. I just asked for jaunty too. lenny-backports needs a dak upgrade and formorer doesn't want to do it, maybe someone else should offer him to manage it for him. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100326084407.ge7...@rivendell
Re: About new source formats for packages without patches
Raphael Hertzog hert...@debian.org writes: On Fri, 26 Mar 2010, Neil Williams wrote: Now all I need is for dpkg to accept that the absence of debian/source/format is declarative of source format 1.0. That's the case _for now_. You seem to imply that the meaning of the above situation is subject to change outside the power of the dpkg maintainers. If so, why would that be? If not, and the definition of those meanings is up to the dpkg maintainers, why would they ever want the above meaning to change? -- \“The greatest tragedy in mankind's entire history may be the | `\ hijacking of morality by religion.” —Arthur C. Clarke, 1991 | _o__) | Ben Finney -- 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/8739znpiwd@benfinney.id.au
Re: About new source formats for packages without patches
On Fri, 26 Mar 2010 09:17:30 +0100, Raphael Hertzog hert...@debian.org wrote: My goal as dpkg maintainer is that Debian converts the maximum number of source packages to the new source formats in the shortest timeframe. (You might not share this goal but that's another matter) Do you really need a tech ctte decision to step back from that idea at this point of our release process? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- 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/e1nv5zg-0007t0...@swivel.zugschlus.de
Re: About new source formats for packages without patches
On Fri Mar 26 10:11, Marc Haber wrote: On Fri, 26 Mar 2010 09:17:30 +0100, Raphael Hertzog hert...@debian.org wrote: My goal as dpkg maintainer is that Debian converts the maximum number of source packages to the new source formats in the shortest timeframe. (You might not share this goal but that's another matter) Do you really need a tech ctte decision to step back from that idea at this point of our release process? I think that's a little harsh, I think that's a perfectly reasonable view. He didn't say 'ignoring the release' or 'by squeeze'. The expected time using the debhelper approach of 'build it and they will come' might be expected to take 5 years and Raphael is trying to actively work towards it so that it happens in 3. There surely must be some extra effort that people can put in to get their system adopted faster than just putting it out there and see what happens. Matt -- Matthew Johnson signature.asc Description: Digital signature
Serializing transitions
[ Bcc debian-release for info, discussion welcome on -devel ] Hello, one of our biggest problems is dealing with transitions because they tend to get interdependant and it's thus very difficult to move packages from sid to testing. Also many transitions are badly managed by the maintainers who are responsible for them, some even tend to consider that once they have uploaded the package to unstable, the rest will be done automatically. It would be nice to solve those problems. I have a proposal and in order to not make it needlessly complicated I leave out many of the details, they will have to be fleshed out later if we agree that it's something that might be doable and should be tried (at that point starting a DEP would make sense to get approvals from all concerned teams because it requires far-reaching changes as you will see). To resolve the problems I suggest to serialize transitions in sid. First the archive should block package uploads to sid that would be starting a new transition (defining this in more details is left for later). Instead transitions should be managed in dedicated repositories that are overlays over sid. We would have tools (command-line, web interface, etc.) to manage the transition in that repository. We could tell which packages need to be rebuilt (bin-NMU, sourceful upload) and the system would automatically rebuild the package (and it would also be automatically rebuilt every time that the package is updated in sid). Some web interface would display the status of the transition, displaying which package/arch have been built or not, and which one failed to build from source. Build-dependencies for the package rebuilds are fetched in sid and in the corresponding transition repository, that way parallel transitions are not mixed. Once all packages are rebuilt on all arches in the transition repository, the whole repository can be integrated in sid instantly (note that other pending transitions at this point will probably suffer a small setback since the underlying sid distribution has changed and many packages will have to be rebuilt and some may fail to build). Multiple transitions will still end up mixed in sid if you push them before packages have migrated to testing but they are all already completed and you only have to deal with RC bugs and delays to ensure package can migrate to testing. The release team has less responsibilities in making transitions happen but should instead carefully pick the order in which transitions will be pushed to sid. Dealing with transitions that way make it clear that the maintainer has to take the responsibility to prepare/complete the transition if he wants to see his package in sid and in the next release. Transitions can be started at any time, it's just that they will not be pushed to sid until they are completed. Nowadays we ask people to not start transitions because others are already going on, it's counterproductive. Preparing the transition in experimental is not always done and takes much more energy than such a system would take. How does that sound to you? There are numerous problems to solve to implement this of course, but do you believe that this approach could lead to better transition management, quicker testing transition and less frustration? Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100326095142.gg7...@rivendell
Re: Serializing transitions
[ Not quite sure why you sent it to debian-release when I tried to have the discussion on -devel only, anyway ] On Fri, 26 Mar 2010, Philipp Kern wrote: [ Just a few quick thoughts. ] On 2010-03-26, Raphael Hertzog hert...@debian.org wrote: Multiple transitions will still end up mixed in sid if you push them before packages have migrated to testing but they are all already completed and you only have to deal with RC bugs and delays to ensure package can migrate to testing. The release team has less responsibilities in making transitions happen but should instead carefully pick the order in which transitions will be pushed to sid. This also means that you need to restart aging when pushing stuff into sid, so that people can actually test the result, which just won't happen if it's done outside of sid. So for a perfect transition you are moving the testing to the end and increase the time for the transition. ;-) I think restarting aging is certainly wanted (I also discarded the idea of having those transition repositories be built on top of testing precisely because we want testing before going into testing). That said I think those transition repositories are going to be more used (and thus tested) than experimental because they are targeted. Users who want to test the latest KDE or Gnome will happily add such a repository if its sole purpose is to contain updated packages for this software (and they should be able to report bugs already). And there are those transitions which were not noticed by people beforehand, like ABI breaks without package renames, but I guess if your scenario would be in place, people would just be forced to revert those in unstable instead of pushing an uncoordinated transition through sid. I guess so. And the checks at upload time could try to catch those mistakes too. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100326101631.gi7...@rivendell
Re: About new source formats for packages without patches
On Thu, Mar 25, 2010 at 05:19:41PM +0100, Benjamin Drung wrote: Why is there no dak and wanna-build package? Are there plans to create such packages? There used to be a dak package but it ended up lagging very badly behind the actual dak code because it needed some database schema upgrades as time went on and these are very difficult to manage in a robust fashion in a package. Nobody ever had the time to do the updates and the package was so bitrotted that it was felt safer to remove it rather than mislead people into doing new installations with it. -- 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/20100326102549.ga27...@sirena.org.uk
Re: About new source formats for packages without patches
On Thu, Mar 25, 2010 at 11:13:01AM -0700, Russ Allbery wrote: The long tag description probably could be improved to make it clearer that the intention isn't to be a cudgel. Unfortunately pretty much any lintian warning ends up being a cudgel if it's enabled by default since zero lintian warnings is such a common goal. -- 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/20100326103221.gb27...@sirena.org.uk
Re: Serializing transitions
Raphael Hertzog hert...@debian.org writes: To resolve the problems I suggest to serialize transitions in sid. This was already discussed a few times. First the archive should block package uploads to sid that would be starting a new transition (defining this in more details is left for later). No, this can't be defined later. It's a central part. Would any new binary lead to a dedicated overlay? How do you determine when this is needed and when not? Instead transitions should be managed in dedicated repositories that are overlays over sid. We would have tools (command-line, web interface, etc.) to manage the transition in that repository. What would these tools do? Why don't they exist currently? We could tell which packages need to be rebuilt (bin-NMU, sourceful upload) and the system would automatically rebuild the package (and it would also be automatically rebuilt every time that the package is updated in sid). How do you determine the set of packages that need to be transitioned? Are these provided by the uploader? Can they be computed? Some web interface would display the status of the transition, displaying which package/arch have been built or not, and which one failed to build from source. You mean like the existing pages on buildd.debian.org? You just need to feed them the list of affected packages to get that. Multiple transitions will still end up mixed in sid if you push them before packages have migrated to testing but they are all already completed and you only have to deal with RC bugs and delays to ensure package can migrate to testing. Only deal with RC bugs? This touches an interesting point you didn't cover at all: How are bugs reported? How can these bugs be tracked if the same source version is fine in sid, but breaks in an overlay - or, worse, breaks in one overlay, but not in another? Dealing with transitions that way make it clear that the maintainer has to take the responsibility to prepare/complete the transition if he wants to see his package in sid and in the next release. I assumed that this was already the case. I also don't see how enforcing such a technical system would solve this problem? Preparing the transition in experimental is not always done and takes much more energy than such a system would take. Why, actually? How does that sound to you? Trying to improve the handling of transitions is a good thing. I don't consider your mail to be a proposal, as it doesn't cover any of the actual technical problems. Another interesting question: Do you plan to implement this? Do you expect someone else to do it? Why weren't the tools you hinted at never implemented for transition handling in sid? And, seeing the not ending discussions about your handling of the new dpkg source formats: Do you think that such a change could be implemented without pissing off so many people? Marc pgpWl5FRQVoaq.pgp Description: PGP signature
Re: Serializing transitions
On 2010-03-26, Raphael Hertzog hert...@debian.org wrote: That said I think those transition repositories are going to be more used (and thus tested) than experimental because they are targeted. Users who want to test the latest KDE or Gnome will happily add such a repository if its sole purpose is to contain updated packages for this software (and they should be able to report bugs already). But the big issue is here: what if the latest KDE SC requires you to remove Gnome (or the other way around) when one of them kicks off a transition of a common library. (libxklavier, poppler, ... ) Should users then choose or can there be some way to also have merged repositories ? /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/slrnhqp3s6.nfa.nos...@sshway.ssh.pusling.com
Re: Serializing transitions
On 10:51 Fri 26 Mar , Raphael Hertzog wrote: To resolve the problems I suggest to serialize transitions in sid. First the archive should block package uploads to sid that would be starting a new transition (defining this in more details is left for later). Instead transitions should be managed in dedicated repositories that are overlays over sid. We would have tools (command-line, web interface, etc.) to manage the transition in that repository. We could tell which packages need to be rebuilt (bin-NMU, sourceful upload) and the system would automatically rebuild the package (and it would also be automatically rebuilt every time that the package is updated in sid). Some web interface would display the status of the transition, displaying which package/arch have been built or not, and which one failed to build from source. Build-dependencies for the package rebuilds are fetched in sid and in the corresponding transition repository, that way parallel transitions are not mixed. Once all packages are rebuilt on all arches in the transition repository, the whole repository can be integrated in sid instantly (note that other pending transitions at this point will probably suffer a small setback since the underlying sid distribution has changed and many packages will have to be rebuilt and some may fail to build). Multiple transitions will still end up mixed in sid if you push them before packages have migrated to testing but they are all already completed and you only have to deal with RC bugs and delays to ensure package can migrate to testing. The release team has less responsibilities in making transitions happen but should instead carefully pick the order in which transitions will be pushed to sid. After reading these 2 parts, it shows up that lot of cases have to be handled and this will need a huge amont of work. Before starting anything I think we should clearly define all the needed tools and a transition procedure if we will follow your ideas. Dealing with transitions that way make it clear that the maintainer has to take the responsibility to prepare/complete the transition if he wants to see his package in sid and in the next release. Agreed. How does that sound to you? There are numerous problems to solve to implement this of course, but do you believe that this approach could lead to better transition management, quicker testing transition and less frustration? I was thinking to such a proposal last few days after thinking of latest python and perl migration. But it seems that you have deeper studied this topic than me ;) IMHO the discussion starts in the right way. Thanks for raising it. I think it's important to raise and discuss these issues and find out a better way to handle this than it's actually done. Greetings, -- ,''`. Xavier Oswald (xosw...@debian.org) : :' : GNU/LINUX Debian Developer http://www.debian.org `. `' GPG Key: 1024D/88BBB51E `- 938D D715 6915 8860 9679 4A0C A430 C6AA 88BB B51E -- 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/20100326103217.ga21...@gmail.com
Re: About new source formats for packages without patches
On Thu, Mar 25, 2010 at 05:19:41PM +0100, Benjamin Drung wrote: Am Donnerstag, den 25.03.2010, 16:16 + schrieb Philipp Kern: On 2010-03-25, Josselin Mouette j...@debian.org wrote: I’d expect it to be much smoother for an organization that uses Debian tools and works with us to add missing functionality in them if needed, than for an organization that uses its own tools. You seriously don't want to force dak upon everyone. And there is not even a package. (And the same is true for wanna-build, sadly.) Why is there no dak and wanna-build package? Are there plans to create such packages? There is a wanna-build package. It's about a year out of sync with what's in use on the Debian buildds, and would be possible to merge (as was done for sbuild and then buildd). It just needs a large chunk of time to merge and test. I don't have time for it right now myself, so probably won't happen for Squeeze. If anyone is sufficiently motiviated to do this, they are welcome to do this (I'll be happy to review and merge changes as time allows). 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: About new source formats for packages without patches
On Fri, 26 Mar 2010 10:32:21 + Mark Brown broo...@sirena.org.uk wrote: On Thu, Mar 25, 2010 at 11:13:01AM -0700, Russ Allbery wrote: The long tag description probably could be improved to make it clearer that the intention isn't to be a cudgel. Unfortunately pretty much any lintian warning ends up being a cudgel if it's enabled by default since zero lintian warnings is such a common goal. Russ has suggested the new tag becoming wishlist and once a tag is wishlist, it won't show up for most people - only with lintian -I. ... I've changed the severity to wishlist instead, http://lists.debian.org/debian-devel/2010/03/msg00837.html From lintian (1) in sid: The default settings are equivalent to -L =important -L+=normal/possible -L +minor/certain). so Severity: wishlist won't appear unless you override those defaults with -I or other options. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpidTrDnq55Q.pgp Description: PGP signature
Bug#575500: ITP: libminisat2-ocaml -- Ocaml bindings for minisat2
Package: wnpp Severity: wishlist Owner: Pietro Abate pietro.ab...@pps.jussieu.fr Owner: Pietro Abate pietro.ab...@pps.jussieu.fr * Package name: libminisat2-ocaml Version : 0.3 Upstream Author : Pietro Abate pietro.ab...@pps.jussieu.fr * URL : http://github.com/abate/MiniSat-ocaml/tree/minisat2 * License : GPLv3 Programming Lang: Ocaml Description : Ocaml bindings for minisat2 MiniSat-ocaml is a set of OCaml bindings for the SAT solver MiniSat. Instead of reimplementing MiniSat itself in OCaml, this library makes the MiniSat interface available through OCaml. The usage of the OCaml interface is pretty straightforward and mimics the C++ interface. -- 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/20100326112608.17817.65609.report...@dev.localnet.xen
Re: Serializing transitions
On Fri, 26 Mar 2010 10:51:43 +0100 Raphael Hertzog hert...@debian.org wrote: one of our biggest problems is dealing with transitions because they tend to get interdependant and it's thus very difficult to move packages from sid to testing. Also many transitions are badly managed by the maintainers who are responsible for them, some even tend to consider that once they have uploaded the package to unstable, the rest will be done automatically. Wouldn't a simpler method be to identify uploads that inadvertently impair an ongoing transition and bump that one upload to experimental or simply tell the DD not to upload to unstable? i.e. instead of an unknown number of concurrent overlays, a finite number of diverted / blocked uploads. Maybe extending dput functionality to check a file on a central server that lists the ongoing transitions and blocking the upload in the first place? The query would only require a wget - providing the file doesn't get too long, that could work. The file could list the packages involved and dput could scan the debc output to check that none of the declared dependencies match any of the packages in the list if the upload is targeted at unstable. I did a form of that for Emdebian Crush (emrecent) which used edos-debcheck to see if the upload was going to break the repository prior to making the upload. I'll need to revise that fairly soon to cope with the current experiments with Crush. What process is used to obtain the list of packages is irrelevant - as long as a list can be accessed and dput learns how to parse that (possibly using other tools like dcmd, debc and similar). Once that version of dput is in unstable, the problem would be significantly reduced. It would be nice to solve those problems. I have a proposal and in order to not make it needlessly complicated I leave out many of the details, Can we try simpler approaches that can be explained in detail first? they will have to be fleshed out later if we agree that it's something that might be doable and should be tried (at that point starting a DEP would make sense to get approvals from all concerned teams because it requires far-reaching changes as you will see). I can't see that changes to dput would require that level of work. What would need discussion would be management of the list file but there is already a list file - what is missing is a parser that can step in PRIOR to the upload being made. i.e. on my box, not ftp-master. (Yes, I have ended up in a situation where such a helper could have been very useful with xf86-input-tslib during a change of maintainer.) -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpv5Or6Avr81.pgp Description: PGP signature
Re: Serializing transitions
Hi! Neil Williams schrieb: Wouldn't a simpler method be to identify uploads that inadvertently impair an ongoing transition and bump that one upload to experimental or simply tell the DD not to upload to unstable? [..] Maybe extending dput functionality to check a file on a central server that lists the ongoing transitions and blocking the upload in the first place? Maybe I'm wrong but I thought the release team already has the possibility to block uploads because of transitions? I assumed the problem was to identify the packages involved in a transition... Best regards, Alexander -- 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/4bac9c97.3050...@schmehl.info
Re: About new source formats for packages without patches
On 25/03/2010 20:12, Raphael Hertzog wrote: - I'm still undecided whether I will change the default format in dpkg-source but obviously once all packages provide debian/source/format, I will be able to make the change without much bad impact. What is the use case of a default format if all packages provide debian/source/format ? Can we avoid to put a debian/source/format in our package if we agree to change our format when default in dpkg change ? (we must ensure that our package works with both format in this case) If yes, then what is the meaning of the lintian check ? (if no, then I really would want a use case of the default format) Or can we use 'default' in debian/source/format ? (we would have to distinguish default(native) and default(non-native)...) - the adoption rate of the new format is pretty good but that's also because I promoted it a lot so that maintainers currently have it in their mind when updating their packages. Having lintian remind them for packages where they have not yet decided which format to use is a good thing to keep the steady rate. http://upsilon.cc/~zack/stuff/dpkg-v3/ I better agree on this argument. Regards, Vincent - the message in the lintian warning also asks for feedback because I want to know why people decide to not use the newer formats so that I can try fixing/improving whatever is needed. Cheers, -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bacaa96.1090...@free.fr
Re: About new source formats for packages without patches
Raphael Hertzog schrieb am Friday, den 26. March 2010: On Fri, 26 Mar 2010, Stéphane Glondu wrote: Raphael Hertzog a écrit : Note that the lintian message specifically requests to contact us if you decide to stick with 1.0 for such a technical reason. That's done that way so that I can help resolve those problems. No later than this morning I contacted the launchpad guys to allow new source formats in karmic PPA because one DD continued to use 1.0 for this reason. Did they reply? AFAIC, the same applies to jaunty PPA and lenny-backports. Yes, they are going to allow it for karmic PPA. I just asked for jaunty too. lenny-backports needs a dak upgrade and formorer doesn't want to do it, maybe someone else should offer him to manage it for him. Thats not true. What I said to you is that we won't upgrade dak before backports.debian.org as this would mean doubling the work. Alex -- 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/20100326131539.gi1...@hawking.credativ.lan
De quem sempre te amou.!
Não esqueça de mim... O amor deve ser como água, puro e cristalino, como a terra, forte e bonito, como o ar, livre e solto... O amor é como os teus olhos que me fascinam, como a tua boca, que faz delirar, como tudo que lhe pertence, pois esse tudo foi tocado por suas mãos delicadas e macias. O amor é em si resumido em uma só palavra; você. Eternamente você! Esssa mensagem é para vc...!! acesse o link abaixo http://moourl.com/qt9an -- 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/4bacb2c1f0dac_70927e60670...@winter25.tmail
Re: Serializing transitions
[ I find the tone of your mail needlessly aggressive, we're just discussing an idea at this point and seeing if it's worth investing more time into it ] On Fri, 26 Mar 2010, Marc 'HE' Brockschmidt wrote: No, this can't be defined later. It's a central part. Would any new binary lead to a dedicated overlay? How do you determine when this is needed and when not? We have several types of transitions and it will need different kind of checks. Let me give some examples. A direct upload to sid: - must not drop a binary package that has reverse dependencies (ex: drop libfoo4 when new source package provides libfoo5) - must not change the SONAME of a public library without changing the package name - must not increase the automatic dep via shlibs/symbols files (we first want to make sure that such an updated library is built/available on all arches before it hits unstable) - must not remove a Provides where it was the only package providing it (ex: perlapi-5.8.0, phpapi-*) if there are reverse dependencies on that provides I'm not sure we can catch all transitions, I have no suggestion for python-defaults or gcc-defaults transitions for example. But we are generally aware of those transitions and they rarely happen out of the blue. I did not want to go into details because I believe that this part is doable and it doesn't bring much to the initial goal of the discussion: determining if such a system could work to better manage the transitions. Instead transitions should be managed in dedicated repositories that are overlays over sid. We would have tools (command-line, web interface, etc.) to manage the transition in that repository. What would these tools do? Why don't they exist currently? See below. They would be used to tell the system which packages are affected and should be included in the transition. (And they do not exist becuse nobody wrote them yet, although some release people have scripts to identify set of packages concerned by transitions) We could tell which packages need to be rebuilt (bin-NMU, sourceful upload) and the system would automatically rebuild the package (and it would also be automatically rebuilt every time that the package is updated in sid). How do you determine the set of packages that need to be transitioned? Are these provided by the uploader? Can they be computed? A mix of both, the uploader should be able to provide a raw list and/or tell the system all source packages whose binaries are depending on libfoo4. The release team would verify that the set of packages includes all required packages but some edos-debcheck based tools could also help to try to ensure that automatically. Some web interface would display the status of the transition, displaying which package/arch have been built or not, and which one failed to build from source. You mean like the existing pages on buildd.debian.org? You just need to feed them the list of affected packages to get that. Good if it can be done with a simple link to buildd.debian.org! It would still be nice to be able to attach some information like bug numbers near FTBFS so that people managing the transitions know whether all failures have been reported. Multiple transitions will still end up mixed in sid if you push them before packages have migrated to testing but they are all already completed and you only have to deal with RC bugs and delays to ensure package can migrate to testing. Only deal with RC bugs? This touches an interesting point you didn't cover at all: How are bugs reported? How can these bugs be tracked if the same source version is fine in sid, but breaks in an overlay - or, worse, breaks in one overlay, but not in another? Bugs are reported like usual. However you are right that we need to extend our bin-nmus versioning scheme to avoid collisions in package versions between various overlays. And/or we need to extend our tools to be able to explicitly give the source version (in fact there's such a request already in the dpkg-dev BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440094) In sid: Package: bar Version: 1.0-1 Source: barsrc In python2.6 overlay: Package: bar Version: 1.0-1+python2.6+b1 Source: barsrc (1.0-1) In libfoo5 overlay: Package: bar Version: 1.0-1+libfoo5+b1 Source: barsrc (1.0-1) It might also mean some changes to the version-tracking code. Dealing with transitions that way make it clear that the maintainer has to take the responsibility to prepare/complete the transition if he wants to see his package in sid and in the next release. I assumed that this was already the case. I also don't see how enforcing such a technical system would solve this problem? Currently a maintainer uploading new version of the library and having given a list of packages to bin-nmu can disappear, the transition will complete a some point because otherwise it blocks you as release managers to deal with other transitions. So
backports.debian.org
On Fri, 26 Mar 2010, Alexander Wirt wrote: Raphael Hertzog schrieb am Friday, den 26. March 2010: lenny-backports needs a dak upgrade and formorer doesn't want to do it, maybe someone else should offer him to manage it for him. Thats not true. What I said to you is that we won't upgrade dak before backports.debian.org as this would mean doubling the work. Has it been decided that backports.debian.org would be a separate dak installation? Otherwise it might well be that the backports suite are going to be directly managed on ftp-master.debian.org. That way it's automatically mirrored, etc. Also I fail to see why the upgrade would have to be done twice. Either you do it now and you can copy the database and the files to backports.debian.org or you don't and you'll have to do it on the new installation anyway. What do I miss? Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100326143154.gd8...@rivendell
Bug#575523: ITP: hbase -- random, realtime read/write access to big data using hadoop
Package: wnpp Severity: wishlist Owner: Thomas Koch tho...@koch.ro Owner: Thomas Koch tho...@koch.ro * Package name: hbase Version : 0.20.3 Upstream Author : Apache Foundation * URL : http://hadoop.apache.org/hbase/ * License : Apache 2 Programming Lang: Java Description : random, realtime read/write access to big data using hadoop HBase is the Hadoop database. It hosts very large tables (think petabytes) -- billions of rows X millions of columns -- atop clusters of commodity hardware. It's modeled after Google's Bigtable. * Convenient base classes for backing Hadoop MapReduce jobs with HBase tables * Query predicate push down via server side scan and get filters * Optimizations for real time queries * A high performance Thrift gateway * A REST-ful Web service gateway that supports XML, Protobuf, and binary data encoding options * Cascading source and sink modules * Extensible jruby-based (JIRB) shell * Support for exporting metrics via the Hadoop metrics subsystem to files or Ganglia; or via JMX * No HBase single point of failure * Rolling restart for configuration changes and minor upgrades * Random access performance on par with open source relational databases such as MySQL -- 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/20100326143209.6596.79358.report...@localhost.localdomain
Re: About new source formats for packages without patches
On Fri, 26 Mar 2010, Vincent Danjean wrote: What is the use case of a default format if all packages provide debian/source/format ? The default source format is required for backwards compatibility. I can't simply make the build fail if debian/source/format doesn't exist! But you're right that changing the default format doesn't make much sense when we are in a situation where we have multiple source formats and that there's none that is acceptable to use in all cases. Instead, when we'll deprecate the 1.0 format, we should simply make dpkg-source -b fail if debian/source/format doesn't exist. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100326145253.ge8...@rivendell
Bug#575530: ITP: ibus-tegaki -- tegaki engine for IBus
Package: wnpp Severity: wishlist Owner: LI Daobing lidaob...@debian.org * Package name: ibus-tegaki Version : 0.3.1 Upstream Author : Mathieu Blondel * URL : http://www.tegaki.org/ * License : GPLv2 Programming Lang: Python Description : tegaki engine for IBus IBus is an Intelligent Input Bus. It is a new input framework for Linux OS. It provides full featured and user friendly input method user interface. It also may help developers to develop input method easily. . Tegaki is an ongoing project which aims to develop a free and open-source modern implementation of handwriting recognition software, that is suitable for both the desktop and mobile devices, and that is designed from the ground up to work well with Chinese and Japanese. . this package provide the tegaki engine for ibus. -- 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/20100326155635.27170.52669.report...@cas.localhost
Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled
Hi! Joerg Jaspert schrieb: just a short notice for everyone out there who wants to upload or waits for a package migration to testing: ries.debian.org, the host behind ftp-master.debian.org, has hardware trouble, a failed memory module keeps resetting the machine at random intervals. A small update: Thanks to our DSAs ries seems to be working again, but we noticed some other broken files in the archive. We are therefore comparing checksums over the entire archive, which might take same time (as it is ~500GB). Best regards, Alexander -- 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/4bacde46.5030...@debian.org
Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled
Hi, On Fri Mar 26, 2010 at 17:18:14 +0100, Alexander Reichle-Schmehl wrote: Hi! Joerg Jaspert schrieb: just a short notice for everyone out there who wants to upload or waits for a package migration to testing: ries.debian.org, the host behind ftp-master.debian.org, has hardware trouble, a failed memory module keeps resetting the machine at random intervals. A small update: Thanks to our DSAs ries seems to be working again, but *cough* well, 2 DIMMs are now taken out of the machine, which we hope have caused that problem, but we will see There will be a further downtime when the replacement DIMMs arrive. Greetings Martin -- Martin Zobel-Helas zo...@debian.org | Debian System Administrator Debian GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- 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/20100326162721.ga18...@ftbfs.de
Re: backports.debian.org
On 2010-03-26, Raphael Hertzog hert...@debian.org wrote: Otherwise it might well be that the backports suite are going to be directly managed on ftp-master.debian.org. That way it's automatically mirrored, etc. FWIW that's also the case for volatile. We're basically waiting for ftp-master to do the integration but nothing happened so far. (And yes, I know that ftp-master is short on people and time, but I certainly won't update that antique installation of dak which is still bzr-based, when it should be somewhere else instead.) 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/slrnhqpomi.ca2.tr...@kelgar.0x539.de
Testing upgrade Failures:
I just tried to do an upgrade on testing I,m getting several errors. First snip of output is regarding unknown types. I have no idea what this is but I seen it before. SNIP- Processing triggers for hicolor-icon-theme ... Processing triggers for gnome-menus ... Processing triggers for desktop-file-utils ... Processing triggers for shared-mime-info ... Unknown media type in type 'chemical/x-alchemy' Unknown media type in type 'chemical/x-cache' Unknown media type in type 'chemical/x-cactvs-ascii' Unknown media type in type 'chemical/x-cactvs-binary' Unknown media type in type 'chemical/x-cactvs-table' Unknown media type in type 'chemical/x-cdx' Unknown media type in type 'chemical/x-cdxml' Unknown media type in type 'chemical/x-chem3d' Unknown media type in type 'chemical/x-cif' Unknown media type in type 'chemical/x-cml' Unknown media type in type 'chemical/x-daylight-smiles' Unknown media type in type 'chemical/x-dmol' Unknown media type in type 'chemical/x-gamess-input' Unknown media type in type 'chemical/x-gamess-output' Unknown media type in type 'chemical/x-gaussian-input' Unknown media type in type 'chemical/x-gaussian-log' Unknown media type in type 'chemical/x-genbank' Unknown media type in type 'chemical/x-gulp' Unknown media type in type 'chemical/x-hin' Unknown media type in type 'chemical/x-inchi' Unknown media type in type 'chemical/x-inchi-xml' Unknown media type in type 'chemical/x-jcamp-dx' Unknown media type in type 'chemical/x-macromodel-input' Unknown media type in type 'chemical/x-mdl-molfile' Unknown media type in type 'chemical/x-mdl-rdfile' Unknown media type in type 'chemical/x-mdl-rxnfile' Unknown media type in type 'chemical/x-mdl-sdfile' Unknown media type in type 'chemical/x-mdl-tgf' Unknown media type in type 'chemical/x-mmcif' Unknown media type in type 'chemical/x-mol2' Unknown media type in type 'chemical/x-mopac-graph' Unknown media type in type 'chemical/x-mopac-input' Unknown media type in type 'chemical/x-mopac-out' Unknown media type in type 'chemical/x-msi-car' Unknown media type in type 'chemical/x-msi-hessian' Unknown media type in type 'chemical/x-msi-mdf' Unknown media type in type 'chemical/x-msi-msi' Unknown media type in type 'chemical/x-ncbi-asn1' Unknown media type in type 'chemical/x-ncbi-asn1-binary' Unknown media type in type 'chemical/x-ncbi-asn1-xml' Unknown media type in type 'chemical/x-pdb' Unknown media type in type 'chemical/x-shelx' Unknown media type in type 'chemical/x-vmd' Unknown media type in type 'chemical/x-xyz' Processing triggers for man-db ... Processing triggers for menu ... Processing triggers for install-info ... SNIP--- second issue is: SNIP--- Running depmod. Running update-initramfs. update-initramfs: Generating /boot/initrd.img-2.6.32-3-686 W: Possible missing firmware /lib/firmware/rtl8168d-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl8168d-1.fw for module r8169 initrd.img(/boot/initrd.img-2.6.32-3-686 ) points to /boot/initrd.img-2.6.32-3-686 (/boot/initrd.img-2.6.32-3-686) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.32-3-686.postinst line 400. vmlinuz(/boot/vmlinuz-2.6.32-3-686 ) points to /boot/vmlinuz-2.6.32-3-686 (/boot/vmlinuz-2.6.32-3-686) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.32-3-686.postinst line 400. SNIP--- I have all the firmware drivers installed at least every package the says it has anything to do with firmware. third issue is: SNIP--- Found initrd image: /boot/initrd.img-2.6.32-3-686 File descriptor 11 (pipe:[279156]) leaked on lvs invocation. Parent PID 32356: /bin/sh File descriptor 12 (pipe:[279156]) leaked on lvs invocation. Parent PID 32356: /bin/sh SNIP--- I have no idea what this is??? Leaks cant be good or OK can they?? Last issue is with kernel image upgrade; this has failed twice: SNIP--- Running update-grub. Generating grub.cfg ... Found background image: moreblue-orbit-grub.png Found linux image: /boot/vmlinuz-2.6.32-trunk-686 Found initrd image: /boot/initrd.img-2.6.32-trunk-686 Found linux image: /boot/vmlinuz-2.6.32-3-686 Found initrd image: /boot/initrd.img-2.6.32-3-686 File descriptor 11 (pipe:[279156]) leaked on lvs invocation. Parent PID 32356: /bin/sh File descriptor 12 (pipe:[279156]) leaked on lvs invocation. Parent PID 32356: /bin/sh Found Debian GNU/Linux (5.0.1) on /dev/hdb1 Found Debian GNU/Linux (4.0) on /dev/hdc1 done Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/extlinux 2.6.32-3-686 /boot/vmlinuz-2.6.32-3-686 run-parts: /etc/kernel/postinst.d/extlinux exited with return code 1 Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.32-3-686.postinst line 868. dpkg: error
Re: About new source formats for packages without patches
Raphael Hertzog hert...@debian.org writes: I don't see any significant difference in the wording, Excellent, then I succeeded. If the people who were upset think it's better and you don't see a difference, that's exactly the balance that I was trying to strike. the major change is the priority which simply means that less people will see it/take it into account (those that use -I by default). Yes, this is always the standard tradeoff. However, that's an overall Lintian design decision: it only shows minor/certain or normal and higher bugs by default, and you have to ask if you want to see uncertain minor or wishlist bugs. That's to encourage people who don't want to be bothered with what they consider trivia to still use Lintian to check for significant issues. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxxv6k1f@windlord.stanford.edu
Re: backports.debian.org
Raphael Hertzog schrieb am Friday, den 26. March 2010: On Fri, 26 Mar 2010, Alexander Wirt wrote: Raphael Hertzog schrieb am Friday, den 26. March 2010: lenny-backports needs a dak upgrade and formorer doesn't want to do it, maybe someone else should offer him to manage it for him. Thats not true. What I said to you is that we won't upgrade dak before backports.debian.org as this would mean doubling the work. Has it been decided that backports.debian.org would be a separate dak installation? Afaik the whole thing will be on a separate box. Otherwise it might well be that the backports suite are going to be directly managed on ftp-master.debian.org. That way it's automatically mirrored, etc. Regardless of the place I don't have root on the box and can't do anything for it. Its all up to ftpmaster. So please don't beg me anymore. thanks. Also I fail to see why the upgrade would have to be done twice. Either you do it now and you can copy the database and the files to backports.debian.org or you don't and you'll have to do it on the new installation anyway. What do I miss? Because you don't have a clue how things are going. Alex -- 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/20100326182152.ga27...@nelson.snow-crash.org
Bug#575544: ITP: libfm -- libraries for file management programming needs
Package: wnpp Severity: wishlist Owner: Andrew Lee (李健秋) ajq...@debian.org Owner: Andrew Lee (李健秋) ajq...@debian.org * Package name: libfm Version : 0.1.9 Upstream Author : 洪任諭 Hong Jen Yee (PCMan) pcman...@gmail.com * URL : http://pcmanfm.sourceforge.net/ * License : (GPL) Programming Lang: (C) Description : libraries for file management programming needs LibFM is a library packaging GLIB/GIO and provide higher level API and related window components as a library for file management programming needs, and make it easy to reuse for other programs. Features: * Independent to any platform/desktop environment * Use gio/gvfs as same as Nautilus to support remote storage, with faster experience to users. * Support GVFS and remote storage access (Windows SMB, FTP, SFTP, WebDav...) * Fast, low memory usage and low latency which is friendly to less powerful hardware such as netbook and thin client/server. * Trash can support (provided by gvfs). * Clipboard operations are compatible for both GTK+, Gnome and QT/KDE * Core function separated from GUI, be able reuse with UI toolkit other than GTK+, eg Qt4 or Enlightenment. * Supports Drag and drop handling and supports XDS (X Direct Save). * Provides some widgets for file management needs that are missing in GTK+ and glib. -- 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/20100326180641.5377.57641.report...@localhost.localdomain
Re: About new source formats for packages without patches
OoO En ce début de soirée du jeudi 25 mars 2010, vers 21:06, Neil Williams codeh...@debian.org disait : Removing the tag without fixing dpkg to not require debian/source/format for source format 1.0 packages. That bug does need to be fixed. I've only altered a few of my packages in SVN - none of those need an upload particularly soon - so if there's a realistic chance that dpkg will never assert format 3.0 in the absence of debian/source/format, I'll override the lintian warning until dpkg is fixed. (Already done that for a few packages.) No offense, but adding a file to override a lintian information about adding a simple file seems a bit odd. -- Don't stop at one bug. - The Elements of Programming Style (Kernighan Plauger) pgpzkSjWP595c.pgp Description: PGP signature
Re: Suggestion to developer tools
Quoting ceduardo on 2010-03-18 17:32:27: What Do you developer tools sugges? Not a piece of software proper, but I, too, am learning programming and have found the book The Art of Unix Programming by Eric S. Raymond to be quite invaluable. I don't have an ISBN, as I have the PDF version, but a google for 'taoup.pdf site:catb.org' should yield something. Unsure if it's been translated to Portugese though. Offtopic: I'm looking for a place where I can buy the paper copy using cash or money order. PD: I sorry but my english is very bad, I am learning too. Hey, it's better than that of some native English speakers I know :) -- _ Brian Ryans 8B2A 54C4 E275 8CFD 8A7D 5D0B 0AD0 B014 C112 13D0 . ( ) ICQ UIN: 43190205 | Mail/MSN/Jabber: brianlry...@gmail.com ..: X ASCII Ribbon Campaign Against HTML mail and v-cards: asciiribbon.org / \ Any technology distinguishable from magic is insufficiently advanced signature.asc Description: Digital signature
Re: Suggestion to developer tools
2010/3/25 Brian Ryans brian.l.ry...@gmail.com: Quoting ceduardo on 2010-03-18 17:32:27: What Do you developer tools sugges? Not a piece of software proper, but I, too, am learning programming and have found the book The Art of Unix Programming by Eric S. Raymond to be quite invaluable. I don't have an ISBN, as I have the PDF version, but a google for 'taoup.pdf site:catb.org' should yield something. Unsure if it's been translated to Portugese though. Thanks, this more information to my objetive. I am from Colombia, my native language is spanish. Offtopic: I'm looking for a place where I can buy the paper copy using cash or money order. PD: I sorry but my english is very bad, I am learning too. Hey, it's better than that of some native English speakers I know :) Wow thank you -- _ Brian Ryans 8B2A 54C4 E275 8CFD 8A7D 5D0B 0AD0 B014 C112 13D0 . ( ) ICQ UIN: 43190205 | Mail/MSN/Jabber: brianlry...@gmail.com ..: X ASCII Ribbon Campaign Against HTML mail and v-cards: asciiribbon.org / \ Any technology distinguishable from magic is insufficiently advanced -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkusFKsACgkQCtCwFMESE9Do2gCeNPRgAv1hGQD20YojG3kLIcmE 8gUAoIaxE4jdL4FsPfLg1w8jqyHEMpOT =4JFA -END PGP SIGNATURE- -- ceduardo -- 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/c068e3701003261504g66573289r6e3e726027ca3...@mail.gmail.com
Re: Suggestion to developer tools
You mistakenly replied to me instead of to the list. I'll fix that. Quoting ceduardo on 2010-03-26 17:04:08: Thanks, this more information to my objetive. I am from Colombia, my native language is spanish. I don't know why I said Portuguese instead of Spanish. Brain fart on my part, likely. I'm unsure about where to get a copy of TAOUP in Spanish. Maybe regulars of debian-devel-spanish would know where to get such, if it even exists? I searched Google and nothing came up for a Spanish copy. -- _ Brian Ryans 8B2A 54C4 E275 8CFD 8A7D 5D0B 0AD0 B014 C112 13D0 . ( ) ICQ UIN: 43190205 | Mail/MSN/Jabber: brianlry...@gmail.com ..: X ASCII Ribbon Campaign Against HTML mail and v-cards: asciiribbon.org / \ Any technology distinguishable from magic is insufficiently advanced signature.asc Description: Digital signature
Re: Serializing transitions
Raphael Hertzog a écrit : Preparing the transition in experimental is not always done and takes much more energy than such a system would take. Why, actually? I don't an exhaustive answer but here are some points: 1/ you can't request bin-nmus of reverse-dependencies in experimental (to verify that all packages build fine with the updated package, and that's one of the main task in preparing the transition) 2/ you have to manually reupload a new source package to unstable with all the delay it induces for getting the package built on all arches Besides, you might have to version build-dependencies so that they are taken from experimental. Worse, you might have to expand all transitive build-dependencies and version them so that they are taken from experimental (sbuild prefers to fail instead of installing from experimental unless the versioned build-dependency is explicit). This is too impractical with OCaml, for example: it is impossible to make a transition in experimental without an insane amount of work, whereas recompiling all involved packages takes only a few hours (on amd64). 3/ some maintainers are too confident that nothing is going to break And even if they do tests, they cannot do them on all architectures. 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/4bad3ec1.7020...@glondu.net
Re: Serializing transitions
Neil Williams a écrit : I did a form of that for Emdebian Crush (emrecent) which used edos-debcheck to see if the upload was going to break the repository prior to making the upload. [...] Hum... interesting. If an upload is going to break the repository, dak could indeed ask some kind of confirmation before actually installing the packages in the archive. Has this ever been considered for the main archive? -- 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/4bad4328.9020...@glondu.net
Bug#575563: ITP: libbusiness-onlinepayment-payflowpro-perl -- PayPal Payflow Pro backend for Business::OnlinePayment
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libbusiness-onlinepayment-payflowpro-perl Version : 1.01 Upstream Author : Phil Lobbes phil at perkpartners.com * URL : http://search.cpan.org/dist/Business-OnlinePayment-PayflowPro/ * License : Perl Programming Lang: Perl Description : PayPal Payflow Pro backend for Business::OnlinePayment This is Business::OnlinePayment::PayflowPro, an Business::OnlinePayment backend module for PayPal Payflow Pro. It is only useful if you have a merchant account with PayPal Payflow Pro: https://www.paypal.com/cgi-bin/webscr?cmd=_payflow-pro-overview-outside Business::OnlinePayment is a generic interface for processing payments through online credit card processors, online check acceptance houses, etc. (If you like buzzwords, call it an multiplatform ecommerce-enabling middleware solution). -- 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/20100327001224.17546.46336.report...@skydancer.freeside.biz
Bug#575565: ITP: libbusiness-onlinepayment-paymentech-perl -- Chase PaymenTech backend for Business::OnlinePayment
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libbusiness-onlinepayment-paymentech-perl Version : 2.03 Upstream Author : Mark Wells m...@freeside.biz * URL : http://search.cpan.org/dist/Business-OnlinePayment-PaymenTech/ * License : Perl Programming Lang: Perl Description : Chase PaymenTech backend for Business::OnlinePayment This is Business::OnlinePayment::PaymenTech, an Business::OnlinePayment backend module for Chase Paymentech. It is only useful if you have a merchant account with Chase Paymentech: http://www.chasepaymentech.com/ Business::OnlinePayment is a generic interface for processing payments through online credit card processors, online check acceptance houses, etc. (If you like buzzwords, call it an multiplatform ecommerce-enabling middleware solution). -- 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/20100327001835.17790.63677.report...@skydancer.freeside.biz
Bug#575567: ITP: libbusiness-onlinepayment-ippay-perl -- IPPay backend for Business::OnlinePayment
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libbusiness-onlinepayment-ippay-perl Version : 0.04 Upstream Author : Jeff Finucane ip...@weasellips.com * URL : http://search.cpan.org/dist/Business-OnlinePayment-IPPay * License : Perl Programming Lang: Perl Description : IPPay backend for Business::OnlinePayment This is Business::OnlinePayment::IPPay, an Business::OnlinePayment backend module for IPPay. It is only useful if you have a merchant account with IPPay: http://www.ippay.com/ Business::OnlinePayment is a generic interface for processing payments through online credit card processors, online check acceptance houses, etc. (If you like buzzwords, call it an multiplatform ecommerce-enabling middleware solution). -- 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/20100327002549.17915.38385.report...@skydancer.freeside.biz
Bug#575571: ITP: sushi -- IRC suite operating via D-Bus
Package: wnpp Severity: wishlist Owner: Luke Faraone l...@faraone.cc * Package name: sushi Version : 1.1.1 Upstream Author : Michael Kuhn sur...@ikkoku.de * URL : http://sushi.ikkoku.de/ * License : Two-clause BSD Programming Lang: C, Python Description : IRC suite operating via D-Bus The sushi IRC suite consists of a central daemon and several clients, which communicate via DBus. DBus methods and signals are provided by the daemon to abstract the IRC protocol. Clients can use these methods and signals to easily interact with IRC. The daemon – maki – provides DBus methods and signals that abstract the IRC protocol to make it more pleasant to use. Consequently, clients using this interface can focus on providing a good user experience instead of worrying about implementation details of the IRC protocol. For example, this interface could also be used to easily write IRC bots in any language that supports DBus. The suite currently provides a graphical client for GTK – tekka – as well as one for the terminal – nigiri. -- 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/20100327021527.8649.46781.report...@opus.home
