Re: Proposal: convert all udebs to xz compression
On Sat, Nov 19, 2011 at 17:21, Philipp Kern wrote: > Otavio, > > am Sat, Nov 19, 2011 at 04:55:12PM -0200 hast du folgendes geschrieben: >> On Wed, Nov 2, 2011 at 23:14, Otavio Salvador >> wrote: >> > On Sun, Oct 23, 2011 at 13:26, Philipp Kern wrote: >> > ... >> >> So my proposal is to switch the udeb compression default in dpkg to xz >> >> for wheezy, when the busybox and udpkg changes have landed. Then most >> >> udebs will get a translation upload anyway, if not they can be binNMUed >> >> to pick up the right compression. >> > ... >> > From my side you have a "go ahead" but I'd like to hear from Colin and >> > Joey if they can think about any con about doing it. >> What is the current status of it? > > blocked on inconclusive feedback of the dpkg devs on using the extreme variant > of xz (see #647915). We could start with -z0 of course, which would be > supported by dpkg-dev and hence a trivial patch of debhelper would do. > But it doesn't gain that much. Dpkg people, can you comment on that? I've pinged people on IRC already about this bug earlier today. > In other news I didn't yet upload the udpkg change because I waited for a > busybox upload to incorporate the already committed unxz inclusion. This has already been done. Please go ahead with udpkg then :-) -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cap9odkr2m9qyvrapbsvsnzsl3zcz3wl0vw68_pscpjayqq8...@mail.gmail.com
Re: GNU ChangeLogs, commit logs and commits
Tollef Fog Heen writes: > ]] Guillem Jover > > | * Small logical unit commits (if it cannot be described fully in the > | short summary, then there's probably too many changes): > | - Others do not get put off by monster commits, or trying to mentally > | untangle the unrelated changes in their minds. > | - Makes it easier to verify for correctness, avoid regressions, etc. > | - Makes it easier to revert or cherry-pick if needed. > > As buxy pointed out: how do you think we should do this wrt larger > features? In the past, you've wanted a squashed commit, is this still > wanted? IMO for bigger features it makes more sense a complete commit; obviously if you're doing changes in previous code, that will be used later by the feature and doesn't "break" the code, it could be done in a small commit and the rest into another one. IMO an important thing to have in mind is to commit only compilable code, to allow the usage of bisect. My 2c -- O T A V I OS A L V A D O R - E-mail: ota...@debian.org UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Negotiation ?
Ian Jackson <[EMAIL PROTECTED]> writes: > If Raphael and Guillem are willing to compromise on anything I'd like > to hear about it. At the moment their position seems to be that they > are the official maintainers and therefore get to rule by decree. I'm sorry Ian. I do appreciate all your past work in Debian and all very useful projects you work/worked on. You need to be in personal problems since it's obvious to me that you're smart (I consider you a genius for some things) to understand that what Raphael, Guillem and all other people that disagree with you said the exactly same thing over and over again. Summary: If you are willing to cooperate: - you take your branch triggers branch - rebase, merge patches, put unrelated changes in other patches - make this "new" branch available for review - in few days it's checked and merged If you are not willing to cooperate: - you wait until someone have time/motivation/whatever to - take your triggers branch - rebase, merge patches, put unrelated changes in other patches (will take more time since that person will need to understand whole thing before doing it) - make this "new" branch available for review by other team members - in few days it's checked and merged I'm very sorry but who is not willing to help is _you_. I work with many teams and ofthen I do rebase, and all needed work to get my _proposed_ changes merged. I don't try to push different policies for the team to get my changes in; instead I cooperate with them to get those changes in. Cheers, -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Negotiation ?
Ian Jackson <[EMAIL PROTECTED]> writes:
> Anthony Towns writes ("Re: dpkg semi-hijack - an announcement (also,
> triggers)"):
>> Beyond that, any additional uploads of dpkg will be REJECTed until you
>> guys resolve this nonsense. Flamewars on -devel, ignoring functional
>> patches for months on end, package hijacks and requests for UNACCEPTs
>> aren't the way to maintain dpkg.
>
> Do we have any basis for negotiation ? Is there anything that you
> guys are willing to concede ?
Did you even think about _you_ concede?
--
O T A V I OS A L V A D O R
-
E-mail: [EMAIL PROTECTED] UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
you the whole house."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dependency based boot sequencing and triggers
Petter Reinholdtsen <[EMAIL PROTECTED]> writes: >> Otherwise the installer unnecessarily and repetitively globally >> recalculates initscript dependencies for each package installed. > > Actually, it happens every time a init.d script is added to the boot > and shutdown sequence, and I believe it have to do that, to make sure > each script insertion fail individually when a script with incorrect > dependency information is encountered. Yes. The trigger shouldn't be the best way to cupe with it. If a trigger is used then all pending scripts would be ignored due a specific one being buggy. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Mike Bird <[EMAIL PROTECTED]> writes: > On Wed March 5 2008 12:29:08 Raphael Hertzog wrote: >> I've been added to dpkg's Uploader a few weeks ago, I'm not dpkg's main >> coordinator. I have no veto power, I was mainly trying to give my view >> of the situation ... > > May I suggest then that if no dpkg maintainer objects here > within 48 hours that Ian should proceed with his update? Obviously NO. It's a team policy and noone outside of team should override it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Ian Jackson <[EMAIL PROTECTED]> writes:
> John Goerzen writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg
> maintenance)"):
>> On Friday 29 February 2008 6:16:59 am Otavio Salvador wrote:
>> > That's why you should avoid using the branch as basis to others until
>> > it's clean and also avoid to make it public (without a reason) too.
>>
>> Whatever happened to "release early, release often"?
>
> Quite so.
>
> Also, Otavio is quite wrong to suggest that I shouldn't have based my
> experimental flex branch on the triggers branch. To do otherwise
> would have made conflicts inevitable because the two overlap; I would
> have had to do my flex work based on the old code and then do parts of
> them again, with a merge trainwreck to sort out.
You can use them as basis but after they have been cleaned to useless
commits and made logical.
I do it all the time and it works fine. Also, doing that, is very
simple to rebase your other branches against a new one. You could use
git rebase --into.
--
O T A V I OS A L V A D O R
-
E-mail: [EMAIL PROTECTED] UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
you the whole house."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Colin Watson <[EMAIL PROTECTED]> writes: > On Fri, Feb 29, 2008 at 09:16:59AM -0300, Otavio Salvador wrote: >> Ian Jackson <[EMAIL PROTECTED]> writes: >> > What I am trying to achieve is to use git in the proper way: that is, >> > in a way which makes merging work properly. >> > >> > Insisting that I use git in a manner which makes merges break but >> > gives prettier logfiles is absurd. >> >> That's why you should avoid using the branch as basis to others until >> it's clean and also avoid to make it public (without a reason) too. > > This makes it more difficult to ask for review while the branch is in > progress, which is a valuable property. It is ridiculous to artificially > avoid making branches public; a branch is a useful means of > collaboration and we should take advantage of it as such. I'm not saying that it couldn't be made public for review however I suppose noone will ask for review if it's still at start of development process. It's rather easy to someone contrib to others branch and it could be done as soon as it looks more mature. In that case, rebase would stop to be done until the feature is finished. After that, a new run to cleanup the history would be done. >> Usually, I make branches public when my log looks sane. >> >> And it's not absurd, is to allow everyone to be kept sane when looking >> the log in 5 years forward. > > I have never once run into this problem with other revision control > systems in which branching and merging are common. Somehow it just never > seems to be a real issue. I contend that dpkg is not big enough for it > to become a real issue. The problem here is that it's not a requirement to use git, however it's the dpkg repository policy and I guess we all (even more ones outside of the team) need to respect it. I personally apply this same policy on repositories that I work and it usually makes much easier logs to read. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Ian Jackson <[EMAIL PROTECTED]> writes:
> Raphael Hertzog writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg
> maintenance)"):
>> As soon as you edit commits, they'll get a new id, and thus you'll disrupt
>> merging.
>
> As I thought.
>
> What I am trying to achieve is to use git in the proper way: that is,
> in a way which makes merging work properly.
>
> Insisting that I use git in a manner which makes merges break but
> gives prettier logfiles is absurd.
That's why you should avoid using the branch as basis to others until
it's clean and also avoid to make it public (without a reason) too.
Usually, I make branches public when my log looks sane.
And it's not absurd, is to allow everyone to be kept sane when looking
the log in 5 years forward.
--
O T A V I OS A L V A D O R
-
E-mail: [EMAIL PROTECTED] UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
you the whole house."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > Preserving history is part of it, but not the objective. Sometimes you just > have to plain clean up the mess, so as to be able to see anything of value > through it. As people ofthen do when using file based ChangeLog. People doesn't put: "Fix my 3rd syntax error today" on it. It's used to track useful changes and logical changes. Same for history. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
John Goerzen <[EMAIL PROTECTED]> writes: > "Dirty history" is not only tolerated, but the *only* sane option with, > lesse... rcs cvs svn darcs tla baz (bzr?) > > Only the git and hg people seem to care (and the git people a lot more than > hg people). After you get used to get branches with proper commits for review, you see the pros. It is much easier to everyone to handle it. It's clearer for someone looking when it has been done and he has a logical unit doing the change instead of 10 commits with messed log messages without visual relation but doing a single logical change. As I said before, I usually commit very ofthen. After the change is done I redo the branch splitting the change in logical units. Each change has a nice and well descripted comment that gives good information to everyone interested on it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Pierre Habouzit <[EMAIL PROTECTED]> writes: <...> > And AFAICT, the kernel works in the very same way. What gets rebased > though, are the bugfixes patches that come by 2 or 3, and that add no > value when added as a specific branch. Usually those in git.git are > applied on top of the 'maint' branch (aka the maintenance branch) and > then merged back into master, and then back into 'next' (where the devel > happens). > > IOW, it depends, and if you work on a new _feature_ it's really rarely > rebased. Right. Well said. This however doesn't changes the value of logical changes. I doubt git.git people would accept patches like: "Now it compiles again" "Ouch! Syntax error" "First try to get it done" ... It's much nicer to have something like: "Implements the basis for feature 'foo'" "Changes code to use new feature 'foo'" and avoid all the messy commits done in the way. Besides that, I guess that even when you rebase something against git.git or linus tree, you'll end up being out to date and a merging being done since the volume of commits is too high to allow fast-forward merging only. Personaly, when I'm working on any branch I try to keep it against current version (be it maint or next or whatever) rebased. When merging, I don't worry if it'll be a merging or a fast-forward one. It'll only depends on how long the branch took to get merged. >> I vote for clean history and a bissectable tree, and I think it is worth the >> effort. But I am no dpkg developer, this is a thing you guys have to find >> an agreement among yourselves. > > You vote for the mad route. Sorry, but it makes absolutely no sense to > me. Ian's work was done at some point, tested from that point, and it > makes sense to remember that fact. Actually it's insane to forget that > fact. And rebasing is just pretending that fact never existed. It's just > wrong. Please see my commit about the logs above. As I said, it's much more about commit logs (for me at least) then rebasing. If Ian is OK to make it in logical pieces, it would be ok for me to merge. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Robert Collins <[EMAIL PROTECTED]> writes: > On Sun, 2008-02-24 at 16:46 -0300, Henrique de Moraes Holschuh wrote: >> Yet, rebasing is still routinely performed in the Linux kernel >> development. > > What I find interesting and rather amusing here is Linus talking > negatively about rebase: in particular its propensity to turn tested > code (what you actually committed) into untested code (what you > committed + what someelse has done, in a version of a tree no human has > ever evaluated for correctness). If people doesn't test and review the patches after rebasing, it looks right but everyone is suppose to test the changes after a merging (as for rebasing). -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Ian Jackson <[EMAIL PROTECTED]> writes:
> Raphael Hertzog writes ("Re: triggers in dpkg, and dpkg maintenance"):
>> However you haven't made it easy to merge your code... you repository is a
>> mess to proof-read and the cleaning work that you don't want to do has
>> thus to be done by Guillem.
>
> This is precisely the git bikeshedding I was talking about.
> The `work' that needs to be done is simply `git pull'. [1]
>
> My changes are not that hard to review and in any case they have been
> ready for merge for SIX MONTHS and deployed in a widely-used released
> Linux distribution for four months.
>
> What more evidence is needed of their suitability ?
They're suitable to get in but commit logs and team repository
policies need to be respected.
I'm with Raphael here and IMHO (even being not a member of team) is
that it shouldn't be merge until you, or someone interested, make it
follow the policies.
>> FWIW, you do have access to the repository but I would request you to be
>> removed from the team if you made usage of it in a way that doesn't
>> conform to the rules of the team. This includes having meaningful commit
>> logs and using private rebased branches for most of the work except when
>> we have a public branch where multiple persons of the team cooperate (such
>> as what happens with the sourcev3 branch currently).
>> http://wiki.debian.org/Teams/Dpkg/GitUsage
>
> This development model has been imported from the Linux kernel. It
> may be appropriate when there are hundreds or thousands of people
> generating huge quantities of patches, all trying to get their changes
> committed, with no organisational connection to the handful of people
> picked by the original author who need to act as gatekeeper.
>
> It is not appropriate for a project which has about four people
> submitting any significant number of patches, all of whom are fully
> signed-up members of a shared governance infrastructure, and where the
> gatekeepers are just the people in that project whose hands the code
> has most recently fallen into.
Sorry but I disagree with you. Every project ought to have sane commit
logs and logical changes. It makes cherry-picking, bisect and others
much easier and improves the general programming experience of others
devels since they see logical commits instead of a bunch of commit
doing different changes all the time.
Bear on mind that the comment used on the commit ought to be used to
justify the commit itself. It's not only to give something to show at
git log.
--
O T A V I OS A L V A D O R
-
E-mail: [EMAIL PROTECTED] UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
you the whole house."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
Raphael Hertzog <[EMAIL PROTECTED]> writes: > 2/ Otavio was sort of acknowledging it as a good thing but a good thing > that should be delayed for an unknown amount of time waiting for a fix on > apt's side while the lack of fix didn't seem to create important problems > > Under those conditions, I tend to react negatively. :) I said that I like the idea to have it ordered however, currently, it does mess up with APT and that's why I asked you to revert it until someone (I, Michael or someone else) has time to work on APT and fix it there. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
"Sergei Golovan" <[EMAIL PROTECTED]> writes: > On 2/22/08, Otavio Salvador <[EMAIL PROTECTED]> wrote: >> >> As I said, for APT, the order has meaning _always_. >> >> apt-get install foo bar >> >> Is completely different of >> >> apt-get install bar foo > > Then having a unique, well-defined order of packages in Depends is a > good idea. If packages aren't sorted their order is undefined (not all > of the dependencies are added by hands, many of them come from > substitution variables). So, the order may change from build to build. > Since it is important for APT then this situation should be avoided. No. Just let's respect the control file order. If the maintainer has put it this way, and we follow it, we avoid this too. As I said, it's a know issue and we need to fix it however it would be nice to not get the problem worse changing the package dependencies ordering at build time, at least for now. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
Raphael Hertzog <[EMAIL PROTECTED]> writes: > On Fri, 22 Feb 2008, Otavio Salvador wrote: >> Please, revert this change. > > No. I don't see any good reason for that: > > 1/ I have yet to see a major breakage due to that, the worst has > been changed dependencies on a built package due to choices of other > alternatives in ORed dependencies of build-dependencies Until APT is fixed to really discover the minimal set of packages, ignoring order, this is a serious issue from my POV. APT doesn't work that well on this cases and you can end installing more packages then is really required. For my, this is a good reason to not to do that before. Besides that, would be nice to have contacted Deity team for this change since APT is the major "user" of APT and we would have avoided this. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
Raphael Hertzog <[EMAIL PROTECTED]> writes: > On Fri, 22 Feb 2008, Norbert Preining wrote: >> On Fr, 22 Feb 2008, Raphael Hertzog wrote: >> > I can understand it might change the list of packages pulled, but both set >> > are supposed to work since that what dependencies are expressing. If you >> >> I disagree. Sometimes alternatives are something we put in to help >> transition. We have >> ... texlive-foo | tetex-bar >> and if this gets reordered that would be actually a big disadvantage. >> People will suddently get HUGE amount of packages due to >> tetex-bar depends on several texlive-packages > > You're speaking of something that you have not understood. The order > of packages listed in an OR has not changed... I am (of course) aware > that the order has a meaning in that case. As I said, for APT, the order has meaning _always_. apt-get install foo bar Is completely different of apt-get install bar foo Yes, this is a bug on APT but isn't a easy one and I or Michael will need to try to solve it :( -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
"Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > In some cases, particularly when the Depends can be satisfied by > different sets of alternatives, this change could have the effect of > changing the packages actually pulled in by apt-get or aptitude. I will > be happy to post a couple such examples -- one hypothetical, one real -- > if requested. (They are a bit long so I'm not including them in this > email.) Please, revert this change. This is indeed a issue on APT. I'm willing to work on that on APT side but it will take some time. Packages order _is_ important for APT. It shouldn't be but currently it does matter. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
Joey Hess <[EMAIL PROTECTED]> writes: <...> > However, stashing away uncommitted changes and not including them in the > build violates least suprise. I'd except to see them either commited > automatically, or the current error forcing me to resolve them before > building. The advantage to auto-committing, of course, is that you don't > have to know how to use git (or debcommit) to build a package that uses it. Error out looks to be the most robust thing to do. Otherwise we can start to get people not properly commiting changes themselfs ofthenly. <...> >> 4) aj suggested in this thread to add a Source-Depends field which could >> be used to specify the dependencies needed to unpack the package. I >> guess that could prove useful, but I really would like to avoid that >> all packages need to specify it (even though that might be solvable with >> substvars defined by the plugin). OTOH if dpkg uses an internal >> mechanism to map format to dependencies it would be more difficult for >> other programs like apt to get to this information. Or is this all >> over-engineering and the plugin should check its pre-requisites itself >> and note the dependencies in the error message like the current code >> does. > > One appoach would be for dpkg to build a dpkg-dev-git package that > includes the git format (and depends on git-core), and so on, > then "Format: 3.0 (foo)" could be converted to dpkg-dev-foo. Couldn't dpkg adds the needed packages, automatically, as build-depends? This looks more logical to me. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg development cycle
Raphael Hertzog <[EMAIL PROTECTED]> writes: > On Mon, 14 Jan 2008, Otavio Salvador wrote: >> > There are two possible options for the workings of the "stable" branch >> > though >> > I want to point out: >> > 1) As you described commit everything to "master" and cherry pick the >> > changes to "stable" if wanted. (backports) >> > 2) Try to decide where to commit beforehand and commit small changes >> > directly to "stable" and then merge that to "master". (forwardports) >> > >> > The latter generates more merge commits but less "duplicated" commits. >> > An example project that uses this model is git itself. >> >> Yes. And it does work much better. We 1 on parted and we're planning >> to move to 2 after 1.9 gets released since it makes our merging, >> releasing and changelog much clearer > > Do you typically have entries in debian/changelog in your commits? No. I'm using git-dch for it. > Because that's going to generate conflicts whatever solution you use. Yes, indeed. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg development cycle
Frank Lichtenheld <[EMAIL PROTECTED]> writes:
> On Thu, Jan 03, 2008 at 05:05:24PM +0100, Raphael Hertzog wrote:
>> Thus I'm wondering if we shouldn't follow the linux development model.
>> Have a cycle of say one month, merge stuff aggressively during 10 days,
>> make an upload to experimental and run the new dpkg on our own computers
>> during 20 days more and then upload to unstable (once bugs have been
>> ironed out).
>>
>> In parallel, we should have the liberty of regularly uploading bugfixes
>> to unstable (with a version like 1.14.14.{1,2,3}) ... it would only
>> contain cherry-picked bugfixes from the master branch.
>
> I would support this proposal.
>
> There are two possible options for the workings of the "stable" branch though
> I want to point out:
> 1) As you described commit everything to "master" and cherry pick the
> changes to "stable" if wanted. (backports)
> 2) Try to decide where to commit beforehand and commit small changes
> directly to "stable" and then merge that to "master". (forwardports)
>
> The latter generates more merge commits but less "duplicated" commits.
> An example project that uses this model is git itself.
Yes. And it does work much better. We 1 on parted and we're planning
to move to 2 after 1.9 gets released since it makes our merging,
releasing and changelog much clearer
--
O T A V I OS A L V A D O R
-
E-mail: [EMAIL PROTECTED] UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
you the whole house."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Review of file exclusion branch requested
Tollef Fog Heen <[EMAIL PROTECTED]> writes: > Hi, > > I've finally gotten around to fixing up my support for excluding bits > of packages as they are unpacked. It can be gotten from > git://git.err.no/dpkg in the master branch (sorry about that, it > should probably have gone in a separate branch). What would be the usage scenario for it? Embedded devices? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg development cycle
Raphael Hertzog <[EMAIL PROTECTED]> writes: <...> > What do you think ? Even not being active on dpkg team I'd like to express my agreement with your proposal. dpkg is a very important part of Debian and it does deserve to be a nice place to work in. The merge window allows that more and excitent features go in faster. What worries me are the slots choosen. I personally think that 10 days for merge window could be reduced by the half and the stabilization work to be extended to 25 days. When someone wants to have a feature merged, having 5 or 10 days for it won't change since it'll need to be done before it anyway and it leave more time for testing and like. My 2c. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is it possible to make a deb package in non-debian system butonly dpkg installed?
"BRIAND, Michel M" <[EMAIL PROTECTED]> writes: ... > Compiling dpkg on Solaris was like creating the first chicken. Maybe if > we could create a debbootstrap for Solaris it would be the first egg ... For debootstrap, the best place to talk is debian-boot ml. What problem you had? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Next upload 2007-11-04 (dpkg 1.14.8)
Guillem Jover <[EMAIL PROTECTED]> writes: > So I'd like to clean up the dpkg-architecture mess, I've the changes > locally, they mostly need splitting and committing and a bit more > testing. And I'd like to commit a patch I've had around for some time > to start supporting udebs. What're the changes regarting udebs handling that you wanna include? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Raphael Hertzog <[EMAIL PROTECTED]> writes: > Each time I had a bugfix, I "squashed" the bugfix commit into the > corresponding "logical commit" (using git rebase -i origin/master). If the bugfix is unrelated, is nice to put it in a separate branch for merging too so it's easier to have a global view of real changes need and not a mix of them. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
Ian Jackson <[EMAIL PROTECTED]> writes:
> Anthony Towns writes ("Re: Triggers status?"):
>> On Mon, Oct 22, 2007 at 05:43:45PM +0100, Ian Jackson wrote:
>> > * The dpkg triggers code should be merged from
>> > http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers/
>>
>> ] $ git clone http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.triggers
>> ] Initialized empty Git repository in /home/aj/H/dpkg/dpkg.triggers/.git/
>> ] Cannot get remote repository information.
>> ] Perhaps git-update-server-info needs to be run there?
>>
>> git:// doesn't work either (Connection refused).
>
> What I did was rsync -a my local tree to my public-html directory on
> chiark. chiark is still running sarge so git isn't installed there.
>
> Is it not possible to provide a git branch in this way ? What should
> I have done instead ?
Put it on your public_git on alioth? Easier :-)
--
O T A V I OS A L V A D O R
-
E-mail: [EMAIL PROTECTED] UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
you the whole house."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For dpkg translators: new git instructions
Raphael Hertzog <[EMAIL PROTECTED]> writes: > But I think that this is not a sustainable workflow for translators. They > are not used to handle multiple branches and it's complicated enough > already. >> Peter Karlsson <[EMAIL PROTECTED]> writes: >> > Would doing the incremental updates on a branch and merging it with >> > "git merge --squash" achieve the same effect, or would that still >> > clutter the repository? Peter looks to use this workflow and on this case it works. I'm replying _his_ question. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For dpkg translators: new git instructions
Raphael Hertzog <[EMAIL PROTECTED]> writes: > On Wed, 10 Oct 2007, Peter Karlsson wrote: >> Raphael Hertzog: >> >> > Please understand that this is not useful historical information and >> > as such we'd like to avoid seeing it. We want a single "Update Polish >> > translations" instead of 10 similar commits. >> >> Would doing the incremental updates on a branch and merging it with >> "git merge --squash" achieve the same effect, or would that still >> clutter the repository? > > I'm not sure I understand correctly the documentation of that option, but > it appears to be something completely unrelated. > > This command seems to apply the changes corresponding to the merge but not > record the merge as a merge, thus losing information concerning the > changes. It looks like this has the potential to hurt... please don't use > it. :) Sorry but you missunderstood it. For example, say branches: master foo and I've been commiting on foo for a while. Once my change is done, I can go to master and run: git merge --squash foo. It'll basically do the merge but no commits. When you commit, it'll show all the commit log of previous commits and you can change it and use a nice commit message that will look like if everything has been done on a single commit. This is one way of using "topic branches" and is similar to the squash command on rebase -i. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For dpkg translators: new git instructions
Peter Karlsson <[EMAIL PROTECTED]> writes: > Raphael Hertzog: > >> Please understand that this is not useful historical information and >> as such we'd like to avoid seeing it. We want a single "Update Polish >> translations" instead of 10 similar commits. > > Would doing the incremental updates on a branch and merging it with > "git merge --squash" achieve the same effect, or would that still > clutter the repository? Yes, it does exacly the same thing. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
> On Mon, Oct 08, 2007 at 09:34:14PM -0300, Otavio Salvador wrote:
>> > On the other hand one could argue that dpkg-buildpackage should
>> > intentionally remain simple and that people are expected to write
>> > their own wrappers or replacements if they need.
>> >
>> > What do you think?
>>
>> I personally think it ought to be kept simple since is very easy to
>> write other more "feature-rich" wrappers around it.
>>
>> It needs to support all basic features of dpkg but no more then that.
>
> In principle I agree with that.
>
> However as a matter of fact nowadays is not that easy to switch from one
> dpkg-buildpackage wrapper to the another, due to the variety of needed
> configurations, different invocation APIs and such and such (here I'm
> thinking at the ones I've used so far in my DD experience:
> dpkg-buildpackage itself, debuild, pbuilder, cowbuilder,
> {svn,bzr,git,...}-buildpackage.
>
> *If* (I'm not sure it will) integrating some of their features directly
> in dpkg-buildpackage can ease the switching from one to the other I
> would say: go and implement them in dpkg-buildpackage.
Personally I think it's a different problem.
A week ago I was talking to Arnaud (squashfs Debian maintainer, on Cc)
and we were talking about this problem and we think the best way to
avoid this problem is to have a common place for configuration so all
those wrappers avoid duplicated settings.
It would be better to offer a way to set and get settings in a common
way and then make all those tools to use it. This would make the
switch much easier.
--
O T A V I OS A L V A D O R
-
E-mail: [EMAIL PROTECTED] UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
you the whole house."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
Frank Lichtenheld <[EMAIL PROTECTED]> writes: > On the other hand one could argue that dpkg-buildpackage should > intentionally remain simple and that people are expected to write > their own wrappers or replacements if they need. > > What do you think? I personally think it ought to be kept simple since is very easy to write other more "feature-rich" wrappers around it. It needs to support all basic features of dpkg but no more then that. That is my personal point of view. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
