FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 11-28-2007, 07:25 AM
"Aaron Griffin"
 
Default Missing packages?

The following appear to be missing for i686:
firefox 2.0.0.10-2
pidgin 2.3.0-1
ddrescue 1.6-1

I *think* these missing packages might actually be causing a DB issue
brought up on the pacman-dev list.

If you look at the extra db entries, firefox has a filename pointing
at the 2.0.0.10-1 version, which is still on the ftp, but the version
is listed as 2.0.0.10-2

I don't know if the other two are affected

_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public
 
Old 11-28-2007, 12:15 PM
"Dan McGee"
 
Default Missing packages?

On Nov 28, 2007 2:25 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
> The following appear to be missing for i686:
> firefox 2.0.0.10-2
> pidgin 2.3.0-1
> ddrescue 1.6-1

Simo- I know you built pidgin for me, what hapened here?

-Dan

_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public
 
Old 11-28-2007, 12:41 PM
Paul Mattal
 
Default Missing packages?

Dan McGee wrote:
> On Nov 28, 2007 2:25 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
>> The following appear to be missing for i686:
>> firefox 2.0.0.10-2
>> pidgin 2.3.0-1
>> ddrescue 1.6-1

Interesting. I haven't actually run the db update script to put
ddrescue 1.6-1 in the repo yet. Why, then, would it report it
missing? It appears 1.5-1 is still in the db file.

This seems like erroneous erroring on the part of the db update
script; it should not consider packages missing until *that* dev
runs the update script, not any dev.

- P

_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public
 
Old 11-28-2007, 12:52 PM
Alexander Baldeck
 
Default Missing packages?

Paul Mattal wrote:
> Dan McGee wrote:
>> On Nov 28, 2007 2:25 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
>>> The following appear to be missing for i686:
>>> firefox 2.0.0.10-2
>>> pidgin 2.3.0-1
>>> ddrescue 1.6-1
>
> Interesting. I haven't actually run the db update script to put
> ddrescue 1.6-1 in the repo yet. Why, then, would it report it
> missing? It appears 1.5-1 is still in the db file.
>
> This seems like erroneous erroring on the part of the db update
> script; it should not consider packages missing until *that* dev
> runs the update script, not any dev.
>
> - P

Hey all,

I did update firefox yesterday and since I always do a local pkgrel bump
for /usr I accidently checked that PKGBUILD in. While I was hecticly
removing thigs I caused a syntax error in build. Oh well, pidgin seemed
to be missing already when I ran db for the first time.

Cheers,

Alex

_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public
 
Old 11-28-2007, 01:08 PM
"Travis Willard"
 
Default Missing packages?

On Nov 28, 2007 8:41 AM, Paul Mattal <paul@mattal.com> wrote:

Dan McGee wrote:
> On Nov 28, 2007 2:25 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
>> The following appear to be missing for i686:

>> * * firefox 2.0.0.10-2
>> * * pidgin 2.3.0-1
>> * * ddrescue 1.6-1

Interesting. I haven't actually run the db update script to put
ddrescue 1.6-1 in the repo yet. Why, then, would it report it

missing? It appears 1.5-1 is still in the db file.
It's missing because that's the version of the PKGBUILD in cvs* marked CURRENT.*

The CURRENT tag is _supposed_ to mean "this is the version currently in the repo" - if you've tagged a package CURRENT and not added the package into the db, then you've made a mistake.

*
This seems like erroneous erroring on the part of the db update
script; it should not consider packages missing until *that* dev

runs the update script, not any dev.


_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public
 
Old 11-28-2007, 01:40 PM
Paul Mattal
 
Default Missing packages?

Travis Willard wrote:
> On Nov 28, 2007 8:41 AM, Paul Mattal <paul@mattal.com
> <mailtoaul@mattal.com>> wrote:
>
> Dan McGee wrote:
> > On Nov 28, 2007 2:25 AM, Aaron Griffin <aaronmgriffin@gmail.com
> <mailto:aaronmgriffin@gmail.com>> wrote:
> >> The following appear to be missing for i686:
> >> firefox 2.0.0.10-2
> >> pidgin 2.3.0-1
> >> ddrescue 1.6-1
>
> Interesting. I haven't actually run the db update script to put
> ddrescue 1.6-1 in the repo yet. Why, then, would it report it
> missing? It appears 1.5-1 is still in the db file.
>
>
> It's missing because that's the version of the PKGBUILD in cvs marked
> CURRENT.
>
> The CURRENT tag is _supposed_ to mean "this is the version currently in
> the repo" - if you've tagged a package CURRENT and not added the package
> into the db, then you've made a mistake.

I disagree. Often you need to build and upload a set of packages
(using devtools) and you want to upload them as you build them but
drop them in the repo at once because they need to be released together.

Furthermore, it seems silly to consider the package missing when the
database file and the package file for the old version are still in
the repo.

If we want the CURRENT flag to really mean what you say, we should
have the DB scripts do the tagging.

- P

_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public
 
Old 11-28-2007, 02:33 PM
"Travis Willard"
 
Default Missing packages?

On Nov 28, 2007 9:40 AM, Paul Mattal <paul@mattal.com> wrote:

Travis Willard wrote:
> On Nov 28, 2007 8:41 AM, Paul Mattal <paul@mattal.com
> <mailto:
paul@mattal.com>> wrote:
>
> * * Dan McGee wrote:
> * * *> On Nov 28, 2007 2:25 AM, Aaron Griffin <aaronmgriffin@gmail.com

> * * <mailto:aaronmgriffin@gmail.com>> wrote:
> * * *>> The following appear to be missing for i686:
> * * *>> * * firefox 2.0.0.10-2
> * * *>> * * pidgin
2.3.0-1
> * * *>> * * ddrescue 1.6-1
>
> * * Interesting. I haven't actually run the db update script to put
> * * ddrescue 1.6-1 in the repo yet. Why, then, would it report it
> * * missing? It appears
1.5-1 is still in the db file.
>
>
> It's missing because that's the version of the PKGBUILD in cvs *marked
> CURRENT.
>
> The CURRENT tag is _supposed_ to mean "this is the version currently in

> the repo" - if you've tagged a package CURRENT and not added the package
> into the db, then you've made a mistake.

I disagree. Often you need to build and upload a set of packages

(using devtools) and you want to upload them as you build them but
drop them in the repo at once because they need to be released together.
I agree that this is a common and useful thing to do, however with rxvt-unicode and firefox I don't think this was the case.


Besides, when you build and upload a set of packages, you do so with the intention of adding them to the repo after they're all uploaded.* There will be a little incongruence between the time the first package is uploaded and the last one is uploaded, but ideally you wouldn't start using 'extrapkg' or the like until you were ready to put them all into the repo at once.


I don't personally see the use case of 'build half tonight, extrapkg them, go to sleep, build the second half tomorrow, extrapkg them, then run /arch/db-extra" as a valid case - if that's the workflow, then extrapkg should be used only when you're ready to put stuff into the repos.

*
Furthermore, it seems silly to consider the package missing when the
database file and the package file for the old version are still in

the repo.
The package is considered missing because the CVS tag is telling the db scripts to expect that package.* In light of that meaning, it's not silly - it's basically telling you which packages are marked CURRENT but not in the repo itself.

*
If we want the CURRENT flag to really mean what you say, we should
have the DB scripts do the tagging.


I also agree that the ideal place to tag the repo is upon actual insertion into the DB.* The problem is that, at current, the DB scripts use the CURRENT tag to determine which version is supposed to be in the repo and update the database accordingly.* We'd have to include a distinct method of telling the DB scripts "Hey, this is the version we want" that doesn't rely on CURRENT.


I'm curious - what do you interpret the CURRENT flag to mean, if not "the version CURRENTly in the repo"?

_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public
 
Old 11-28-2007, 03:32 PM
"Aaron Griffin"
 
Default Missing packages?

On Nov 28, 2007 8:40 AM, Paul Mattal <paul@mattal.com> wrote:
> Travis Willard wrote:
> > On Nov 28, 2007 8:41 AM, Paul Mattal <paul@mattal.com
> > <mailtoaul@mattal.com>> wrote:
> >
> > Dan McGee wrote:
> > > On Nov 28, 2007 2:25 AM, Aaron Griffin <aaronmgriffin@gmail.com
> > <mailto:aaronmgriffin@gmail.com>> wrote:
> > >> The following appear to be missing for i686:
> > >> firefox 2.0.0.10-2
> > >> pidgin 2.3.0-1
> > >> ddrescue 1.6-1
> >
> > Interesting. I haven't actually run the db update script to put
> > ddrescue 1.6-1 in the repo yet. Why, then, would it report it
> > missing? It appears 1.5-1 is still in the db file.
> >
> >
> > It's missing because that's the version of the PKGBUILD in cvs marked
> > CURRENT.
> >
> > The CURRENT tag is _supposed_ to mean "this is the version currently in
> > the repo" - if you've tagged a package CURRENT and not added the package
> > into the db, then you've made a mistake.
>
> I disagree. Often you need to build and upload a set of packages
> (using devtools) and you want to upload them as you build them but
> drop them in the repo at once because they need to be released together.
>
> Furthermore, it seems silly to consider the package missing when the
> database file and the package file for the old version are still in
> the repo.
>
> If we want the CURRENT flag to really mean what you say, we should
> have the DB scripts do the tagging.

Travis is right here. Even if this is not what _you_ assume, it is
what the database scripts assume, and unless you want to fix them
(soon, as in today) to not work like that, then it'd be nice if you
simply moved the CURRENT tag

$ cvs tag -Fr 1.7 CURRENT system/ddrescue/PKGBUILD

Furthermore, you are actually always the person who says the DB
scripts *MUST* check our source control and *MUST* ensure version
matches. This statement appears to be the reverse of that. Or are you
saying that the PKGBUILD need not be tagged/marked latest, but just be
"one of the PKGBUILDs in source control"? How exactly would we ensure
the constraint you've always wanted without a tagging mechanism as is
currently in use

_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public
 
Old 11-28-2007, 04:33 PM
Paul Mattal
 
Default Missing packages?

Aaron Griffin wrote:
> On Nov 28, 2007 8:40 AM, Paul Mattal <paul@mattal.com> wrote:
>> Travis Willard wrote:
>>> On Nov 28, 2007 8:41 AM, Paul Mattal <paul@mattal.com
>>> <mailtoaul@mattal.com>> wrote:
>>>
>>> Dan McGee wrote:
>>> > On Nov 28, 2007 2:25 AM, Aaron Griffin <aaronmgriffin@gmail.com
>>> <mailto:aaronmgriffin@gmail.com>> wrote:
>>> >> The following appear to be missing for i686:
>>> >> firefox 2.0.0.10-2
>>> >> pidgin 2.3.0-1
>>> >> ddrescue 1.6-1
>>>
>>> Interesting. I haven't actually run the db update script to put
>>> ddrescue 1.6-1 in the repo yet. Why, then, would it report it
>>> missing? It appears 1.5-1 is still in the db file.
>>>
>>>
>>> It's missing because that's the version of the PKGBUILD in cvs marked
>>> CURRENT.
>>>
>>> The CURRENT tag is _supposed_ to mean "this is the version currently in
>>> the repo" - if you've tagged a package CURRENT and not added the package
>>> into the db, then you've made a mistake.
>> I disagree. Often you need to build and upload a set of packages
>> (using devtools) and you want to upload them as you build them but
>> drop them in the repo at once because they need to be released together.
>>
>> Furthermore, it seems silly to consider the package missing when the
>> database file and the package file for the old version are still in
>> the repo.
>>
>> If we want the CURRENT flag to really mean what you say, we should
>> have the DB scripts do the tagging.
>
> Travis is right here. Even if this is not what _you_ assume, it is
> what the database scripts assume, and unless you want to fix them
> (soon, as in today) to not work like that, then it'd be nice if you
> simply moved the CURRENT tag
>
> $ cvs tag -Fr 1.7 CURRENT system/ddrescue/PKGBUILD
>
> Furthermore, you are actually always the person who says the DB
> scripts *MUST* check our source control and *MUST* ensure version
> matches. This statement appears to be the reverse of that. Or are you
> saying that the PKGBUILD need not be tagged/marked latest, but just be
> "one of the PKGBUILDs in source control"? How exactly would we ensure
> the constraint you've always wanted without a tagging mechanism as is
> currently in use

Sorry to have apparently started quite a debate here.

My point was not about what the CURRENT flag *should* mean but about
what it does mean. Since it's possible to get the two out of sync
(fairly easily, in fact), I don't assume that CURRENT == exactly
what's in the repo.

That said, I think the best outcome for right now would be to add
some language to the failure indicating WHY the package is
"missing".. because it hasn't yet been put in the db vs. ones that
already have, because the second is a much more important
issue/problem than the first to those trying to use the package.

One day we'll solve the problems fully, and I didn't mean to upset
everyone over all this. I just wanted to point out that the repo
isn't necessarily in an inconsistent state when this particular
scenario occurs, and by throwing the *same* error when the actual
repo is hosed vs. when it is not tends to make people ignore the
messages altogether.

- P

_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public
 
Old 11-28-2007, 04:43 PM
"Aaron Griffin"
 
Default Missing packages?

On Nov 28, 2007 11:33 AM, Paul Mattal <paul@mattal.com> wrote:
> Sorry to have apparently started quite a debate here.
>
> My point was not about what the CURRENT flag *should* mean but about
> what it does mean. Since it's possible to get the two out of sync
> (fairly easily, in fact), I don't assume that CURRENT == exactly
> what's in the repo.

It's not a debate. I'm saying this:

Whatever you may believe, here is how the db scripts work. Please
either fix them, or simply retag your PKGBUILD with the command I
provided.
There's no debate. The scripts function this way regardless of how you
*think* they work. The CURRENT and CURRENT-64 tags must match whats in
the repos, or it yells.

This is not a fatal error, but it is still an error - it doesn't break
our DB but it breaks everyone's abs checkout by giving them a PKGBUILD
that we're not even using.

> That said, I think the best outcome for right now would be to add
> some language to the failure indicating WHY the package is
> "missing".. because it hasn't yet been put in the db vs. ones that
> already have, because the second is a much more important
> issue/problem than the first to those trying to use the package.

Sure, go ahead, the scripts are in CVS right now. I can update gerolde
with the new scripts that have your feature in it - just let me know
when it's in

> One day we'll solve the problems fully, and I didn't mean to upset
> everyone over all this. I just wanted to point out that the repo
> isn't necessarily in an inconsistent state when this particular
> scenario occurs, and by throwing the *same* error when the actual
> repo is hosed vs. when it is not tends to make people ignore the
> messages altogether.

As I said, the pacman DBs are not in an inconsistent state, but now ABS is.

_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public
 

Thread Tools




All times are GMT. The time now is 04:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org