[users] FYI: bug in git-1.7.1-1 package

[Steve Huff]

hello folks!

git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

i apologize for any disruption resulting from this bug. we'll push an updated package as soon as possible; for the meantime, please exclude git updates from your yum config.

thanks,
-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100623/7eaea4b5/attachment.bin

[Jeff Johnson]

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

Technically its a packaging error from lack of QA on dependencies assertions
contained in a package.

Clearly noone tried to install the built package or they
would have seen the problem instantly.

Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

*shrug*

73 de Jeff

[Nicolas Thierry-Mieg]

Post by Jeff Johnson

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

Technically its a packaging error from lack of QA on dependencies assertions
contained in a package.
Clearly noone tried to install the built package or they
would have seen the problem instantly.
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

what, lousy QA and lazy staff???
And they're informing^Wboasting about it on the ml too, instead of
quietly fixing it and hoping no-one notices?
I want a refund NOW!!!

[Jeff Johnson]

Post by Nicolas Thierry-Mieg
I want a refund NOW!!!

Send me a PayPal service fee and I will happily refund your freedom.

Alternatively, consider barter:
Patched cheerfully accepted.

73 de Jeff

[Jeff Johnson]

Post by Nicolas Thierry-Mieg
I want a refund NOW!!!

Send me a PayPal service fee and I will happily refund your freedom.

Alternatively, consider barter:
Patched cheerfully accepted.

73 de Jeff

[Jeff Johnson]

Post by Nicolas Thierry-Mieg
I want a refund NOW!!!

Send me a PayPal service fee and I will happily refund your freedom.

Alternatively, consider barter:
Patched cheerfully accepted.

73 de Jeff

[Jeff Johnson]

Post by Nicolas Thierry-Mieg
I want a refund NOW!!!

Send me a PayPal service fee and I will happily refund your freedom.

Alternatively, consider barter:
Patched cheerfully accepted.

73 de Jeff

[Jeff Johnson]

Post by Nicolas Thierry-Mieg
I want a refund NOW!!!

Send me a PayPal service fee and I will happily refund your freedom.

Alternatively, consider barter:
Patched cheerfully accepted.

73 de Jeff

[Steve Huff]

Post by Jeff Johnson
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

i'm sorry, Jeff - i did not mean to cast any aspersions upon RPM. i thought list readers might have some interest in finding out what part of the build infrastructure introduced the bug; i agree with your assessment that we should have caught the bug before deployment.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100623/9fb1dbae/attachment.bin

[Jeff Johnson]

Post by Steve Huff

Post by Jeff Johnson
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

i'm sorry, Jeff - i did not mean to cast any aspersions upon RPM. i thought list readers might have some interest in finding out what part of the build infrastructure introduced the bug; i agree with your assessment that we should have caught the bug before deployment.

NP, no apologies needed.

I'd _LOVE_ to get the perl dependency autoextraction in RPM fixed and reliable. Most
recent attempt was a discussion with some CPAN guy at FOSDEM 2010.

The approach to fixing perl deps in RPM _MUST_ be global however. Otherwise you end-up
flip-flopping amongst bug-fixes endlessly. You really need to look at _ALL_ cases.

Been waiting patiently since first implemented in 2001, only a few have helped ever.

73 de Jeff

[Steve Huff]

Post by Jeff Johnson
I'd _LOVE_ to get the perl dependency autoextraction in RPM fixed and reliable. Most
recent attempt was a discussion with some CPAN guy at FOSDEM 2010.
The approach to fixing perl deps in RPM _MUST_ be global however. Otherwise you end-up
flip-flopping amongst bug-fixes endlessly. You really need to look at _ALL_ cases.

yup; it's tough. Christoph has done some work towards parsing META.yaml to extract dependencies, but of course many modules don't have META.yaml, or have incorrect information.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100623/03504653/attachment.bin

[Steve Huff]

Post by Jeff Johnson
I'd _LOVE_ to get the perl dependency autoextraction in RPM fixed and reliable. Most
recent attempt was a discussion with some CPAN guy at FOSDEM 2010.
The approach to fixing perl deps in RPM _MUST_ be global however. Otherwise you end-up
flip-flopping amongst bug-fixes endlessly. You really need to look at _ALL_ cases.

yup; it's tough. Christoph has done some work towards parsing META.yaml to extract dependencies, but of course many modules don't have META.yaml, or have incorrect information.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100623/03504653/attachment-0001.bin

[Steve Huff]

Post by Jeff Johnson
I'd _LOVE_ to get the perl dependency autoextraction in RPM fixed and reliable. Most
recent attempt was a discussion with some CPAN guy at FOSDEM 2010.
The approach to fixing perl deps in RPM _MUST_ be global however. Otherwise you end-up
flip-flopping amongst bug-fixes endlessly. You really need to look at _ALL_ cases.

yup; it's tough. Christoph has done some work towards parsing META.yaml to extract dependencies, but of course many modules don't have META.yaml, or have incorrect information.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100623/03504653/attachment-0002.bin

[Steve Huff]

Post by Jeff Johnson
I'd _LOVE_ to get the perl dependency autoextraction in RPM fixed and reliable. Most
recent attempt was a discussion with some CPAN guy at FOSDEM 2010.
The approach to fixing perl deps in RPM _MUST_ be global however. Otherwise you end-up
flip-flopping amongst bug-fixes endlessly. You really need to look at _ALL_ cases.

yup; it's tough. Christoph has done some work towards parsing META.yaml to extract dependencies, but of course many modules don't have META.yaml, or have incorrect information.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100623/03504653/attachment-0003.bin

[Steve Huff]

Post by Jeff Johnson
I'd _LOVE_ to get the perl dependency autoextraction in RPM fixed and reliable. Most
recent attempt was a discussion with some CPAN guy at FOSDEM 2010.
The approach to fixing perl deps in RPM _MUST_ be global however. Otherwise you end-up
flip-flopping amongst bug-fixes endlessly. You really need to look at _ALL_ cases.

yup; it's tough. Christoph has done some work towards parsing META.yaml to extract dependencies, but of course many modules don't have META.yaml, or have incorrect information.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.repoforge.org/pipermail/users/attachments/20100623/03504653/attachment.sig>

[Jeff Johnson]

Post by Steve Huff

Post by Jeff Johnson
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

i'm sorry, Jeff - i did not mean to cast any aspersions upon RPM. i thought list readers might have some interest in finding out what part of the build infrastructure introduced the bug; i agree with your assessment that we should have caught the bug before deployment.

NP, no apologies needed.

I'd _LOVE_ to get the perl dependency autoextraction in RPM fixed and reliable. Most
recent attempt was a discussion with some CPAN guy at FOSDEM 2010.

The approach to fixing perl deps in RPM _MUST_ be global however. Otherwise you end-up
flip-flopping amongst bug-fixes endlessly. You really need to look at _ALL_ cases.

Been waiting patiently since first implemented in 2001, only a few have helped ever.

73 de Jeff

[Jeff Johnson]

Post by Steve Huff

Post by Jeff Johnson
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

i'm sorry, Jeff - i did not mean to cast any aspersions upon RPM. i thought list readers might have some interest in finding out what part of the build infrastructure introduced the bug; i agree with your assessment that we should have caught the bug before deployment.

NP, no apologies needed.

I'd _LOVE_ to get the perl dependency autoextraction in RPM fixed and reliable. Most
recent attempt was a discussion with some CPAN guy at FOSDEM 2010.

The approach to fixing perl deps in RPM _MUST_ be global however. Otherwise you end-up
flip-flopping amongst bug-fixes endlessly. You really need to look at _ALL_ cases.

Been waiting patiently since first implemented in 2001, only a few have helped ever.

73 de Jeff

[Jeff Johnson]

Post by Steve Huff

Post by Jeff Johnson
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

i'm sorry, Jeff - i did not mean to cast any aspersions upon RPM. i thought list readers might have some interest in finding out what part of the build infrastructure introduced the bug; i agree with your assessment that we should have caught the bug before deployment.

NP, no apologies needed.

I'd _LOVE_ to get the perl dependency autoextraction in RPM fixed and reliable. Most
recent attempt was a discussion with some CPAN guy at FOSDEM 2010.

The approach to fixing perl deps in RPM _MUST_ be global however. Otherwise you end-up
flip-flopping amongst bug-fixes endlessly. You really need to look at _ALL_ cases.

Been waiting patiently since first implemented in 2001, only a few have helped ever.

73 de Jeff

[Jeff Johnson]

Post by Steve Huff

Post by Jeff Johnson
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

i'm sorry, Jeff - i did not mean to cast any aspersions upon RPM. i thought list readers might have some interest in finding out what part of the build infrastructure introduced the bug; i agree with your assessment that we should have caught the bug before deployment.

NP, no apologies needed.

I'd _LOVE_ to get the perl dependency autoextraction in RPM fixed and reliable. Most
recent attempt was a discussion with some CPAN guy at FOSDEM 2010.

The approach to fixing perl deps in RPM _MUST_ be global however. Otherwise you end-up
flip-flopping amongst bug-fixes endlessly. You really need to look at _ALL_ cases.

Been waiting patiently since first implemented in 2001, only a few have helped ever.

73 de Jeff

[Nicolas Thierry-Mieg]

Post by Jeff Johnson

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

Technically its a packaging error from lack of QA on dependencies assertions
contained in a package.
Clearly noone tried to install the built package or they
would have seen the problem instantly.
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

what, lousy QA and lazy staff???
And they're informing^Wboasting about it on the ml too, instead of
quietly fixing it and hoping no-one notices?
I want a refund NOW!!!

[Steve Huff]

Post by Jeff Johnson
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

i'm sorry, Jeff - i did not mean to cast any aspersions upon RPM. i thought list readers might have some interest in finding out what part of the build infrastructure introduced the bug; i agree with your assessment that we should have caught the bug before deployment.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100623/9fb1dbae/attachment-0001.bin

[Nicolas Thierry-Mieg]

Post by Jeff Johnson

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

Technically its a packaging error from lack of QA on dependencies assertions
contained in a package.
Clearly noone tried to install the built package or they
would have seen the problem instantly.
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

what, lousy QA and lazy staff???
And they're informing^Wboasting about it on the ml too, instead of
quietly fixing it and hoping no-one notices?
I want a refund NOW!!!

[Steve Huff]

Post by Jeff Johnson
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

i'm sorry, Jeff - i did not mean to cast any aspersions upon RPM. i thought list readers might have some interest in finding out what part of the build infrastructure introduced the bug; i agree with your assessment that we should have caught the bug before deployment.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100623/9fb1dbae/attachment-0002.bin

[Nicolas Thierry-Mieg]

Post by Jeff Johnson

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

Technically its a packaging error from lack of QA on dependencies assertions
contained in a package.
Clearly noone tried to install the built package or they
would have seen the problem instantly.
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

what, lousy QA and lazy staff???
And they're informing^Wboasting about it on the ml too, instead of
quietly fixing it and hoping no-one notices?
I want a refund NOW!!!

[Steve Huff]

Post by Jeff Johnson
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

i'm sorry, Jeff - i did not mean to cast any aspersions upon RPM. i thought list readers might have some interest in finding out what part of the build infrastructure introduced the bug; i agree with your assessment that we should have caught the bug before deployment.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100623/9fb1dbae/attachment-0003.bin

[Nicolas Thierry-Mieg]

Post by Jeff Johnson

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

Technically its a packaging error from lack of QA on dependencies assertions
contained in a package.
Clearly noone tried to install the built package or they
would have seen the problem instantly.
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

what, lousy QA and lazy staff???
And they're informing^Wboasting about it on the ml too, instead of
quietly fixing it and hoping no-one notices?
I want a refund NOW!!!

[Steve Huff]

Post by Jeff Johnson
Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

i'm sorry, Jeff - i did not mean to cast any aspersions upon RPM. i thought list readers might have some interest in finding out what part of the build infrastructure introduced the bug; i agree with your assessment that we should have caught the bug before deployment.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.repoforge.org/pipermail/users/attachments/20100623/9fb1dbae/attachment.sig>

[Yury V. Zaytsev]

Hey, Steve!

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

What git 1.7.1-1 you are talking about?! Did you work on Tom's package
without telling anyone or what :-)

Nothing seems to have changed in the SVN since my last attempts to get
it into RPMForge.

[Yury V. Zaytsev]

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Another rebuild and of course uncommitted / no comments. Sigh.

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Another rebuild and of course uncommitted / no comments. Sigh.

Yury,

As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

And I don't see a good reason for reiterating over the same thing over and
over again. I am not perfect and I don't have the time to change how it is
implemented right now.

[David Hrbáč]

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change how
it is implemented right now.

Dag,
is there a way Yuri and I can help? Yuri is preparing Trac instance,
hope so. Can we focus on a new build system, repository building sytem?
DH

[Yury V. Zaytsev]

Post by David Hrbáč
Dag,
is there a way Yuri and I can help? Yuri is preparing Trac instance,
hope so. Can we focus on a new build system, repository building sytem?

I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

[Karanbir Singh]

Post by Yury V. Zaytsev
I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

Erm, you told me that you were offline for a few days! I have a note to
get your stuff in place for 29th June.

- KB

[Yury V. Zaytsev]

Hi!

Post by Karanbir Singh

Post by Yury V. Zaytsev
I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

Erm, you told me that you were offline for a few days! I have a note to
get your stuff in place for 29th June.

You right :-(, surprisingly it turned out that I have more free time
during the hack fest, than I would normally have back home.

Cool, thanks. After I get back and do my homework I am willing to have a
preliminary go at it towards the weekend if time permits.

[Yury V. Zaytsev]

Hi!

Post by Karanbir Singh

Post by Yury V. Zaytsev
I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

Erm, you told me that you were offline for a few days! I have a note to
get your stuff in place for 29th June.

You right :-(, surprisingly it turned out that I have more free time
during the hack fest, than I would normally have back home.

Cool, thanks. After I get back and do my homework I am willing to have a
preliminary go at it towards the weekend if time permits.

[Yury V. Zaytsev]

Hi!

Post by Karanbir Singh

Post by Yury V. Zaytsev
I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

Erm, you told me that you were offline for a few days! I have a note to
get your stuff in place for 29th June.

You right :-(, surprisingly it turned out that I have more free time
during the hack fest, than I would normally have back home.

Cool, thanks. After I get back and do my homework I am willing to have a
preliminary go at it towards the weekend if time permits.

[Yury V. Zaytsev]

Hi!

Post by Karanbir Singh

Post by Yury V. Zaytsev
I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

Erm, you told me that you were offline for a few days! I have a note to
get your stuff in place for 29th June.

You right :-(, surprisingly it turned out that I have more free time
during the hack fest, than I would normally have back home.

Cool, thanks. After I get back and do my homework I am willing to have a
preliminary go at it towards the weekend if time permits.

[Yury V. Zaytsev]

Hi!

Post by Karanbir Singh

Post by Yury V. Zaytsev
I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

Erm, you told me that you were offline for a few days! I have a note to
get your stuff in place for 29th June.

You right :-(, surprisingly it turned out that I have more free time
during the hack fest, than I would normally have back home.

Cool, thanks. After I get back and do my homework I am willing to have a
preliminary go at it towards the weekend if time permits.

[Karanbir Singh]

Post by Yury V. Zaytsev
I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

Erm, you told me that you were offline for a few days! I have a note to
get your stuff in place for 29th June.

- KB

[Karanbir Singh]

Post by Yury V. Zaytsev
I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

Erm, you told me that you were offline for a few days! I have a note to
get your stuff in place for 29th June.

- KB

[Karanbir Singh]

Post by Yury V. Zaytsev
I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

Erm, you told me that you were offline for a few days! I have a note to
get your stuff in place for 29th June.

- KB

[Karanbir Singh]

Post by Yury V. Zaytsev
I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

Erm, you told me that you were offline for a few days! I have a note to
get your stuff in place for 29th June.

- KB

[Yury V. Zaytsev]

Post by David Hrbáč
Dag,
is there a way Yuri and I can help? Yuri is preparing Trac instance,
hope so. Can we focus on a new build system, repository building sytem?

I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

[Yury V. Zaytsev]

Post by David Hrbáč
Dag,
is there a way Yuri and I can help? Yuri is preparing Trac instance,
hope so. Can we focus on a new build system, repository building sytem?

I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

[Yury V. Zaytsev]

Post by David Hrbáč
Dag,
is there a way Yuri and I can help? Yuri is preparing Trac instance,
hope so. Can we focus on a new build system, repository building sytem?

I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

[Yury V. Zaytsev]

Post by David Hrbáč
Dag,
is there a way Yuri and I can help? Yuri is preparing Trac instance,
hope so. Can we focus on a new build system, repository building sytem?

I didn't hear from KB as of yet. I will continue the discussion on git
as I have time.

[Yury V. Zaytsev]

Hi Dag!

Post by Dag Wieers
As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

I don't see what it has to do with the build system. You are right, we
have what we have (and I know what we have). But right now we are using
Subversion, a version control system, aren't we?

Why wouldn't you make it a rule to commit BEFORE you attempt build (make
a shell alias so that you CAN'T forget) instead of coming back and
committing a huge blob after you have rebuilt / tested a whole bunch of
things?

This is SVN. Nothing will get lost. Nothing will break. Nothing will be
triggered by your commit. What will happen is that a message will get
sent to the commit mailing list and hopefully I or other packagers will
read an review it. This is the worst case scenario.

If you have accidentally screwed the build, it's not a big deal. Just
commit the fixed SPEC again and that's it. This will completely exclude
the possibility of leaving uncommitted stuff in your working copy,
however.

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change
how it is implemented right now.

Did you get my e-mails recently? I haven't heard anything from you. Why
can't we start changing it slowly and then migrate they finished VMs
where you want to see them?

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Dag Wieers
As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

I don't see what it has to do with the build system. You are right, we
have what we have (and I know what we have). But right now we are using
Subversion, a version control system, aren't we?
Why wouldn't you make it a rule to commit BEFORE you attempt build (make
a shell alias so that you CAN'T forget) instead of coming back and
committing a huge blob after you have rebuilt / tested a whole bunch of
things?

Two reasons:

- my tree has a lot of unfinished business, so I cannot simply do svn ci

- I don't want to commit stuff that hasn't been built/tested

That is why currently if I am doing things like testing git-builds, and
for some reason I sign and push something else, the git build will be
pushed accidentally as well.

In this case, I knew the package had a problem and was pushed, and I had
already fixed it 30mins later and build the packages again. Unfortunately
the push (which is a staged process) was waiting for me to type the
passphrase and therefor wasn't replacing the package that were fixed.

The following morning I noticed, but it was too late to do anything about
it. So I was forced to bump the release and fix it again and wait for the
repository to be created the next day. (The current -1 release is also
fixed, but createrepo has a bug that requires me to bump releases anyway)

One thing I have considered is having a staging repository that is one day
ahead of the real repository. That way we can catch problems before they
impact other people. The only problem is that enough people need to use
the staging repository to make it work.

Post by Yury V. Zaytsev
This is SVN. Nothing will get lost. Nothing will break. Nothing will be
triggered by your commit. What will happen is that a message will get
sent to the commit mailing list and hopefully I or other packagers will
read an review it. This is the worst case scenario.
If you have accidentally screwed the build, it's not a big deal. Just
commit the fixed SPEC again and that's it. This will completely exclude
the possibility of leaving uncommitted stuff in your working copy,
however.

Well, imagine I would do that. When would I commit ? After every change
and failed built ? For example Fabian is building PPC packages from that
same subversion, so he might build something I didn't intend to release.
So I will have to bump the release after every (silly) commit.

I simply don't want to do that, in fact I prefer if everyone would only
commit something they have built and tested, because I could be fixing a
commit to make it work at the same time the original committer is fixing
it.

Post by Yury V. Zaytsev

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change
how it is implemented right now.

Did you get my e-mails recently? I haven't heard anything from you. Why
can't we start changing it slowly and then migrate they finished VMs
where you want to see them?

The problem is that I am getting more mail than I can handle at the
moment, did I mention buying a house, becoming dad, commuting for 2.5h
every day ? So every mail that takes me more than 30secs to answer has a
high probability to not getting answered.

This one obviously got lucky :-)

And there are some other things keeping me awake at night too.

I don't even have Internet at my current work (only a lousy mobile
connection that is slow and disconnects more often than I would like). So
everybody who has enough time to criticize RPMforge, feel lucky you have
the time and a stable Internet connection to do that...

PS the reason I updated git is not because I like breaking people's
repositories, it's because I need it to get one of my TODO items off the
list, which requires git. I am happy if someone wants to take over
maintainership so I don't have to care, but the current version was too
old and needed an update.

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Dag Wieers
As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

I don't see what it has to do with the build system. You are right, we
have what we have (and I know what we have). But right now we are using
Subversion, a version control system, aren't we?
Why wouldn't you make it a rule to commit BEFORE you attempt build (make
a shell alias so that you CAN'T forget) instead of coming back and
committing a huge blob after you have rebuilt / tested a whole bunch of
things?

Two reasons:

- my tree has a lot of unfinished business, so I cannot simply do svn ci

- I don't want to commit stuff that hasn't been built/tested

That is why currently if I am doing things like testing git-builds, and
for some reason I sign and push something else, the git build will be
pushed accidentally as well.

In this case, I knew the package had a problem and was pushed, and I had
already fixed it 30mins later and build the packages again. Unfortunately
the push (which is a staged process) was waiting for me to type the
passphrase and therefor wasn't replacing the package that were fixed.

The following morning I noticed, but it was too late to do anything about
it. So I was forced to bump the release and fix it again and wait for the
repository to be created the next day. (The current -1 release is also
fixed, but createrepo has a bug that requires me to bump releases anyway)

One thing I have considered is having a staging repository that is one day
ahead of the real repository. That way we can catch problems before they
impact other people. The only problem is that enough people need to use
the staging repository to make it work.

Post by Yury V. Zaytsev
This is SVN. Nothing will get lost. Nothing will break. Nothing will be
triggered by your commit. What will happen is that a message will get
sent to the commit mailing list and hopefully I or other packagers will
read an review it. This is the worst case scenario.
If you have accidentally screwed the build, it's not a big deal. Just
commit the fixed SPEC again and that's it. This will completely exclude
the possibility of leaving uncommitted stuff in your working copy,
however.

Well, imagine I would do that. When would I commit ? After every change
and failed built ? For example Fabian is building PPC packages from that
same subversion, so he might build something I didn't intend to release.
So I will have to bump the release after every (silly) commit.

I simply don't want to do that, in fact I prefer if everyone would only
commit something they have built and tested, because I could be fixing a
commit to make it work at the same time the original committer is fixing
it.

Post by Yury V. Zaytsev

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change
how it is implemented right now.

Did you get my e-mails recently? I haven't heard anything from you. Why
can't we start changing it slowly and then migrate they finished VMs
where you want to see them?

The problem is that I am getting more mail than I can handle at the
moment, did I mention buying a house, becoming dad, commuting for 2.5h
every day ? So every mail that takes me more than 30secs to answer has a
high probability to not getting answered.

This one obviously got lucky :-)

And there are some other things keeping me awake at night too.

I don't even have Internet at my current work (only a lousy mobile
connection that is slow and disconnects more often than I would like). So
everybody who has enough time to criticize RPMforge, feel lucky you have
the time and a stable Internet connection to do that...

PS the reason I updated git is not because I like breaking people's
repositories, it's because I need it to get one of my TODO items off the
list, which requires git. I am happy if someone wants to take over
maintainership so I don't have to care, but the current version was too
old and needed an update.

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Dag Wieers
As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

I don't see what it has to do with the build system. You are right, we
have what we have (and I know what we have). But right now we are using
Subversion, a version control system, aren't we?
Why wouldn't you make it a rule to commit BEFORE you attempt build (make
a shell alias so that you CAN'T forget) instead of coming back and
committing a huge blob after you have rebuilt / tested a whole bunch of
things?

Two reasons:

- my tree has a lot of unfinished business, so I cannot simply do svn ci

- I don't want to commit stuff that hasn't been built/tested

That is why currently if I am doing things like testing git-builds, and
for some reason I sign and push something else, the git build will be
pushed accidentally as well.

In this case, I knew the package had a problem and was pushed, and I had
already fixed it 30mins later and build the packages again. Unfortunately
the push (which is a staged process) was waiting for me to type the
passphrase and therefor wasn't replacing the package that were fixed.

The following morning I noticed, but it was too late to do anything about
it. So I was forced to bump the release and fix it again and wait for the
repository to be created the next day. (The current -1 release is also
fixed, but createrepo has a bug that requires me to bump releases anyway)

One thing I have considered is having a staging repository that is one day
ahead of the real repository. That way we can catch problems before they
impact other people. The only problem is that enough people need to use
the staging repository to make it work.

Post by Yury V. Zaytsev
This is SVN. Nothing will get lost. Nothing will break. Nothing will be
triggered by your commit. What will happen is that a message will get
sent to the commit mailing list and hopefully I or other packagers will
read an review it. This is the worst case scenario.
If you have accidentally screwed the build, it's not a big deal. Just
commit the fixed SPEC again and that's it. This will completely exclude
the possibility of leaving uncommitted stuff in your working copy,
however.

Well, imagine I would do that. When would I commit ? After every change
and failed built ? For example Fabian is building PPC packages from that
same subversion, so he might build something I didn't intend to release.
So I will have to bump the release after every (silly) commit.

I simply don't want to do that, in fact I prefer if everyone would only
commit something they have built and tested, because I could be fixing a
commit to make it work at the same time the original committer is fixing
it.

Post by Yury V. Zaytsev

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change
how it is implemented right now.

Did you get my e-mails recently? I haven't heard anything from you. Why
can't we start changing it slowly and then migrate they finished VMs
where you want to see them?

The problem is that I am getting more mail than I can handle at the
moment, did I mention buying a house, becoming dad, commuting for 2.5h
every day ? So every mail that takes me more than 30secs to answer has a
high probability to not getting answered.

This one obviously got lucky :-)

And there are some other things keeping me awake at night too.

I don't even have Internet at my current work (only a lousy mobile
connection that is slow and disconnects more often than I would like). So
everybody who has enough time to criticize RPMforge, feel lucky you have
the time and a stable Internet connection to do that...

PS the reason I updated git is not because I like breaking people's
repositories, it's because I need it to get one of my TODO items off the
list, which requires git. I am happy if someone wants to take over
maintainership so I don't have to care, but the current version was too
old and needed an update.

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Dag Wieers
As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

I don't see what it has to do with the build system. You are right, we
have what we have (and I know what we have). But right now we are using
Subversion, a version control system, aren't we?
Why wouldn't you make it a rule to commit BEFORE you attempt build (make
a shell alias so that you CAN'T forget) instead of coming back and
committing a huge blob after you have rebuilt / tested a whole bunch of
things?

Two reasons:

- my tree has a lot of unfinished business, so I cannot simply do svn ci

- I don't want to commit stuff that hasn't been built/tested

That is why currently if I am doing things like testing git-builds, and
for some reason I sign and push something else, the git build will be
pushed accidentally as well.

In this case, I knew the package had a problem and was pushed, and I had
already fixed it 30mins later and build the packages again. Unfortunately
the push (which is a staged process) was waiting for me to type the
passphrase and therefor wasn't replacing the package that were fixed.

The following morning I noticed, but it was too late to do anything about
it. So I was forced to bump the release and fix it again and wait for the
repository to be created the next day. (The current -1 release is also
fixed, but createrepo has a bug that requires me to bump releases anyway)

One thing I have considered is having a staging repository that is one day
ahead of the real repository. That way we can catch problems before they
impact other people. The only problem is that enough people need to use
the staging repository to make it work.

Post by Yury V. Zaytsev
This is SVN. Nothing will get lost. Nothing will break. Nothing will be
triggered by your commit. What will happen is that a message will get
sent to the commit mailing list and hopefully I or other packagers will
read an review it. This is the worst case scenario.
If you have accidentally screwed the build, it's not a big deal. Just
commit the fixed SPEC again and that's it. This will completely exclude
the possibility of leaving uncommitted stuff in your working copy,
however.

Well, imagine I would do that. When would I commit ? After every change
and failed built ? For example Fabian is building PPC packages from that
same subversion, so he might build something I didn't intend to release.
So I will have to bump the release after every (silly) commit.

I simply don't want to do that, in fact I prefer if everyone would only
commit something they have built and tested, because I could be fixing a
commit to make it work at the same time the original committer is fixing
it.

Post by Yury V. Zaytsev

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change
how it is implemented right now.

Did you get my e-mails recently? I haven't heard anything from you. Why
can't we start changing it slowly and then migrate they finished VMs
where you want to see them?

The problem is that I am getting more mail than I can handle at the
moment, did I mention buying a house, becoming dad, commuting for 2.5h
every day ? So every mail that takes me more than 30secs to answer has a
high probability to not getting answered.

This one obviously got lucky :-)

And there are some other things keeping me awake at night too.

I don't even have Internet at my current work (only a lousy mobile
connection that is slow and disconnects more often than I would like). So
everybody who has enough time to criticize RPMforge, feel lucky you have
the time and a stable Internet connection to do that...

PS the reason I updated git is not because I like breaking people's
repositories, it's because I need it to get one of my TODO items off the
list, which requires git. I am happy if someone wants to take over
maintainership so I don't have to care, but the current version was too
old and needed an update.

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Dag Wieers
As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

I don't see what it has to do with the build system. You are right, we
have what we have (and I know what we have). But right now we are using
Subversion, a version control system, aren't we?
Why wouldn't you make it a rule to commit BEFORE you attempt build (make
a shell alias so that you CAN'T forget) instead of coming back and
committing a huge blob after you have rebuilt / tested a whole bunch of
things?

Two reasons:

- my tree has a lot of unfinished business, so I cannot simply do svn ci

- I don't want to commit stuff that hasn't been built/tested

That is why currently if I am doing things like testing git-builds, and
for some reason I sign and push something else, the git build will be
pushed accidentally as well.

In this case, I knew the package had a problem and was pushed, and I had
already fixed it 30mins later and build the packages again. Unfortunately
the push (which is a staged process) was waiting for me to type the
passphrase and therefor wasn't replacing the package that were fixed.

The following morning I noticed, but it was too late to do anything about
it. So I was forced to bump the release and fix it again and wait for the
repository to be created the next day. (The current -1 release is also
fixed, but createrepo has a bug that requires me to bump releases anyway)

One thing I have considered is having a staging repository that is one day
ahead of the real repository. That way we can catch problems before they
impact other people. The only problem is that enough people need to use
the staging repository to make it work.

Post by Yury V. Zaytsev
This is SVN. Nothing will get lost. Nothing will break. Nothing will be
triggered by your commit. What will happen is that a message will get
sent to the commit mailing list and hopefully I or other packagers will
read an review it. This is the worst case scenario.
If you have accidentally screwed the build, it's not a big deal. Just
commit the fixed SPEC again and that's it. This will completely exclude
the possibility of leaving uncommitted stuff in your working copy,
however.

Well, imagine I would do that. When would I commit ? After every change
and failed built ? For example Fabian is building PPC packages from that
same subversion, so he might build something I didn't intend to release.
So I will have to bump the release after every (silly) commit.

I simply don't want to do that, in fact I prefer if everyone would only
commit something they have built and tested, because I could be fixing a
commit to make it work at the same time the original committer is fixing
it.

Post by Yury V. Zaytsev

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change
how it is implemented right now.

Did you get my e-mails recently? I haven't heard anything from you. Why
can't we start changing it slowly and then migrate they finished VMs
where you want to see them?

The problem is that I am getting more mail than I can handle at the
moment, did I mention buying a house, becoming dad, commuting for 2.5h
every day ? So every mail that takes me more than 30secs to answer has a
high probability to not getting answered.

This one obviously got lucky :-)

And there are some other things keeping me awake at night too.

I don't even have Internet at my current work (only a lousy mobile
connection that is slow and disconnects more often than I would like). So
everybody who has enough time to criticize RPMforge, feel lucky you have
the time and a stable Internet connection to do that...

PS the reason I updated git is not because I like breaking people's
repositories, it's because I need it to get one of my TODO items off the
list, which requires git. I am happy if someone wants to take over
maintainership so I don't have to care, but the current version was too
old and needed an update.

[David Hrbáč]

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change how
it is implemented right now.

Dag,
is there a way Yuri and I can help? Yuri is preparing Trac instance,
hope so. Can we focus on a new build system, repository building sytem?
DH

[Yury V. Zaytsev]

Hi Dag!

Post by Dag Wieers
As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

I don't see what it has to do with the build system. You are right, we
have what we have (and I know what we have). But right now we are using
Subversion, a version control system, aren't we?

Why wouldn't you make it a rule to commit BEFORE you attempt build (make
a shell alias so that you CAN'T forget) instead of coming back and
committing a huge blob after you have rebuilt / tested a whole bunch of
things?

This is SVN. Nothing will get lost. Nothing will break. Nothing will be
triggered by your commit. What will happen is that a message will get
sent to the commit mailing list and hopefully I or other packagers will
read an review it. This is the worst case scenario.

If you have accidentally screwed the build, it's not a big deal. Just
commit the fixed SPEC again and that's it. This will completely exclude
the possibility of leaving uncommitted stuff in your working copy,
however.

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change
how it is implemented right now.

Did you get my e-mails recently? I haven't heard anything from you. Why
can't we start changing it slowly and then migrate they finished VMs
where you want to see them?

[David Hrbáč]

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change how
it is implemented right now.

Dag,
is there a way Yuri and I can help? Yuri is preparing Trac instance,
hope so. Can we focus on a new build system, repository building sytem?
DH

[Yury V. Zaytsev]

Hi Dag!

Post by Dag Wieers
As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

I don't see what it has to do with the build system. You are right, we
have what we have (and I know what we have). But right now we are using
Subversion, a version control system, aren't we?

Why wouldn't you make it a rule to commit BEFORE you attempt build (make
a shell alias so that you CAN'T forget) instead of coming back and
committing a huge blob after you have rebuilt / tested a whole bunch of
things?

This is SVN. Nothing will get lost. Nothing will break. Nothing will be
triggered by your commit. What will happen is that a message will get
sent to the commit mailing list and hopefully I or other packagers will
read an review it. This is the worst case scenario.

If you have accidentally screwed the build, it's not a big deal. Just
commit the fixed SPEC again and that's it. This will completely exclude
the possibility of leaving uncommitted stuff in your working copy,
however.

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change
how it is implemented right now.

Did you get my e-mails recently? I haven't heard anything from you. Why
can't we start changing it slowly and then migrate they finished VMs
where you want to see them?

[David Hrbáč]

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change how
it is implemented right now.

Dag,
is there a way Yuri and I can help? Yuri is preparing Trac instance,
hope so. Can we focus on a new build system, repository building sytem?
DH

[Yury V. Zaytsev]

Hi Dag!

Post by Dag Wieers
As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

I don't see what it has to do with the build system. You are right, we
have what we have (and I know what we have). But right now we are using
Subversion, a version control system, aren't we?

Why wouldn't you make it a rule to commit BEFORE you attempt build (make
a shell alias so that you CAN'T forget) instead of coming back and
committing a huge blob after you have rebuilt / tested a whole bunch of
things?

This is SVN. Nothing will get lost. Nothing will break. Nothing will be
triggered by your commit. What will happen is that a message will get
sent to the commit mailing list and hopefully I or other packagers will
read an review it. This is the worst case scenario.

If you have accidentally screwed the build, it's not a big deal. Just
commit the fixed SPEC again and that's it. This will completely exclude
the possibility of leaving uncommitted stuff in your working copy,
however.

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change
how it is implemented right now.

Did you get my e-mails recently? I haven't heard anything from you. Why
can't we start changing it slowly and then migrate they finished VMs
where you want to see them?

[David Hrbáč]

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change how
it is implemented right now.

Dag,
is there a way Yuri and I can help? Yuri is preparing Trac instance,
hope so. Can we focus on a new build system, repository building sytem?
DH

[Yury V. Zaytsev]

Hi Dag!

Post by Dag Wieers
As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

I don't see what it has to do with the build system. You are right, we
have what we have (and I know what we have). But right now we are using
Subversion, a version control system, aren't we?

Why wouldn't you make it a rule to commit BEFORE you attempt build (make
a shell alias so that you CAN'T forget) instead of coming back and
committing a huge blob after you have rebuilt / tested a whole bunch of
things?

This is SVN. Nothing will get lost. Nothing will break. Nothing will be
triggered by your commit. What will happen is that a message will get
sent to the commit mailing list and hopefully I or other packagers will
read an review it. This is the worst case scenario.

If you have accidentally screwed the build, it's not a big deal. Just
commit the fixed SPEC again and that's it. This will completely exclude
the possibility of leaving uncommitted stuff in your working copy,
however.

Post by Dag Wieers
And I don't see a good reason for reiterating over the same thing over
and over again. I am not perfect and I don't have the time to change
how it is implemented right now.

Did you get my e-mails recently? I haven't heard anything from you. Why
can't we start changing it slowly and then migrate they finished VMs
where you want to see them?

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Another rebuild and of course uncommitted / no comments. Sigh.

Yury,

As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

And I don't see a good reason for reiterating over the same thing over and
over again. I am not perfect and I don't have the time to change how it is
implemented right now.

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Another rebuild and of course uncommitted / no comments. Sigh.

Yury,

As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

And I don't see a good reason for reiterating over the same thing over and
over again. I am not perfect and I don't have the time to change how it is
implemented right now.

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Another rebuild and of course uncommitted / no comments. Sigh.

Yury,

As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

And I don't see a good reason for reiterating over the same thing over and
over again. I am not perfect and I don't have the time to change how it is
implemented right now.

[Dag Wieers]

Post by Yury V. Zaytsev

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Another rebuild and of course uncommitted / no comments. Sigh.

Yury,

As long as we don't have a solution for a buildsystem, this will continue
to happen. I can give you the reasons why this happened, but you already
know the answers and _yes_ it's not how I would like it to be either.

And I don't see a good reason for reiterating over the same thing over and
over again. I am not perfect and I don't have the time to change how it is
implemented right now.

[Steve Huff]

hello folks!

git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

i apologize for any disruption resulting from this bug. we'll push an updated package as soon as possible; for the meantime, please exclude git updates from your yum config.

thanks,
-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100623/7eaea4b5/attachment-0001.bin

[Jeff Johnson]

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

Technically its a packaging error from lack of QA on dependencies assertions
contained in a package.

Clearly noone tried to install the built package or they
would have seen the problem instantly.

Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

*shrug*

73 de Jeff

[Yury V. Zaytsev]

Hey, Steve!

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

What git 1.7.1-1 you are talking about?! Did you work on Tom's package
without telling anyone or what :-)

Nothing seems to have changed in the SVN since my last attempts to get
it into RPMForge.

[Yury V. Zaytsev]

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Another rebuild and of course uncommitted / no comments. Sigh.

[Steve Huff]

hello folks!

git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

i apologize for any disruption resulting from this bug. we'll push an updated package as soon as possible; for the meantime, please exclude git updates from your yum config.

thanks,
-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100623/7eaea4b5/attachment-0002.bin

[Jeff Johnson]

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

Technically its a packaging error from lack of QA on dependencies assertions
contained in a package.

Clearly noone tried to install the built package or they
would have seen the problem instantly.

Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

*shrug*

73 de Jeff

[Yury V. Zaytsev]

Hey, Steve!

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

What git 1.7.1-1 you are talking about?! Did you work on Tom's package
without telling anyone or what :-)

Nothing seems to have changed in the SVN since my last attempts to get
it into RPMForge.

[Yury V. Zaytsev]

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Another rebuild and of course uncommitted / no comments. Sigh.

[Steve Huff]

hello folks!

git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

i apologize for any disruption resulting from this bug. we'll push an updated package as soon as possible; for the meantime, please exclude git updates from your yum config.

thanks,
-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20100623/7eaea4b5/attachment-0003.bin

[Jeff Johnson]

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

Technically its a packaging error from lack of QA on dependencies assertions
contained in a package.

Clearly noone tried to install the built package or they
would have seen the problem instantly.

Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

*shrug*

73 de Jeff

[Yury V. Zaytsev]

Hey, Steve!

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

What git 1.7.1-1 you are talking about?! Did you work on Tom's package
without telling anyone or what :-)

Nothing seems to have changed in the SVN since my last attempts to get
it into RPMForge.

[Yury V. Zaytsev]

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Another rebuild and of course uncommitted / no comments. Sigh.

[Steve Huff]

hello folks!

git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

i apologize for any disruption resulting from this bug. we'll push an updated package as soon as possible; for the meantime, please exclude git updates from your yum config.

thanks,
-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.repoforge.org/pipermail/users/attachments/20100623/7eaea4b5/attachment.sig>

[Jeff Johnson]

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.

Technically its a packaging error from lack of QA on dependencies assertions
contained in a package.

Clearly noone tried to install the built package or they
would have seen the problem instantly.

Anthropomorphising RPM behavior is just a flimsy excuse to be lazy.

*shrug*

73 de Jeff

[Yury V. Zaytsev]

Hey, Steve!

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

What git 1.7.1-1 you are talking about?! Did you work on Tom's package
without telling anyone or what :-)

Nothing seems to have changed in the SVN since my last attempts to get
it into RPMForge.

[Yury V. Zaytsev]

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Another rebuild and of course uncommitted / no comments. Sigh.

[Yury V. Zaytsev]

Hi!

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Well, git now (still) depends on git-cvs, which depends on cvsps, which
I thought I have ported from EPEL correctly (and I did a mock build
indeed), but I ignored the fact, that its makefile can't deal with
CFLAGS forced from the command line, so DAR build failed.

I patched it and send the patch upstream, but for the time beign please
rebuild, otherwise the upgrade from EPEL's git not gonna work :-(

[Yury V. Zaytsev]

Hi!

I am puzzled by the lack of git-http-backend in our git package. What
makes me even more confused is that the man page is actually present as
it should.
--
Sincerely yours,
Yury V. Zaytsev

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.
i apologize for any disruption resulting from this bug. we'll push an updated package as soon as possible; for the meantime, please exclude git updates from your yum config.
thanks,
-steve
--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es
_______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users

[Yury V. Zaytsev]

Hi!

No git-daemon in git-daemon package on EL4 either?!?!

[Yury V. Zaytsev]

Post by Yury V. Zaytsev
Hi!
No git-daemon in git-daemon package on EL4 either?!?!

OK, I've got it. They are not on path (stored in libexec for whatever
reason) and the location in the template present in the SPEC was wrong.

I've just committed a patch for this.

[Yury V. Zaytsev]

Post by Yury V. Zaytsev
Hi!
No git-daemon in git-daemon package on EL4 either?!?!

OK, I've got it. They are not on path (stored in libexec for whatever
reason) and the location in the template present in the SPEC was wrong.

I've just committed a patch for this.

[Yury V. Zaytsev]

Post by Yury V. Zaytsev
Hi!
No git-daemon in git-daemon package on EL4 either?!?!

OK, I've got it. They are not on path (stored in libexec for whatever
reason) and the location in the template present in the SPEC was wrong.

I've just committed a patch for this.

[Yury V. Zaytsev]

Post by Yury V. Zaytsev
Hi!
No git-daemon in git-daemon package on EL4 either?!?!

OK, I've got it. They are not on path (stored in libexec for whatever
reason) and the location in the template present in the SPEC was wrong.

I've just committed a patch for this.

[Yury V. Zaytsev]

Post by Yury V. Zaytsev
Hi!
No git-daemon in git-daemon package on EL4 either?!?!

OK, I've got it. They are not on path (stored in libexec for whatever
reason) and the location in the template present in the SPEC was wrong.

I've just committed a patch for this.

[Yury V. Zaytsev]

Hi!

No git-daemon in git-daemon package on EL4 either?!?!

[Yury V. Zaytsev]

Hi!

No git-daemon in git-daemon package on EL4 either?!?!

[Yury V. Zaytsev]

Hi!

No git-daemon in git-daemon package on EL4 either?!?!

[Yury V. Zaytsev]

Hi!

No git-daemon in git-daemon package on EL4 either?!?!

[Yury V. Zaytsev]

Hi!

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Well, git now (still) depends on git-cvs, which depends on cvsps, which
I thought I have ported from EPEL correctly (and I did a mock build
indeed), but I ignored the fact, that its makefile can't deal with
CFLAGS forced from the command line, so DAR build failed.

I patched it and send the patch upstream, but for the time beign please
rebuild, otherwise the upgrade from EPEL's git not gonna work :-(

[Yury V. Zaytsev]

Hi!

I am puzzled by the lack of git-http-backend in our git package. What
makes me even more confused is that the man page is actually present as
it should.
--
Sincerely yours,
Yury V. Zaytsev

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.
i apologize for any disruption resulting from this bug. we'll push an updated package as soon as possible; for the meantime, please exclude git updates from your yum config.
thanks,
-steve
--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es
_______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users

[Yury V. Zaytsev]

Hi!

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Well, git now (still) depends on git-cvs, which depends on cvsps, which
I thought I have ported from EPEL correctly (and I did a mock build
indeed), but I ignored the fact, that its makefile can't deal with
CFLAGS forced from the command line, so DAR build failed.

I patched it and send the patch upstream, but for the time beign please
rebuild, otherwise the upgrade from EPEL's git not gonna work :-(

[Yury V. Zaytsev]

Hi!

I am puzzled by the lack of git-http-backend in our git package. What
makes me even more confused is that the man page is actually present as
it should.
--
Sincerely yours,
Yury V. Zaytsev

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.
i apologize for any disruption resulting from this bug. we'll push an updated package as soon as possible; for the meantime, please exclude git updates from your yum config.
thanks,
-steve
--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es
_______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users

[Yury V. Zaytsev]

Hi!

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Well, git now (still) depends on git-cvs, which depends on cvsps, which
I thought I have ported from EPEL correctly (and I did a mock build
indeed), but I ignored the fact, that its makefile can't deal with
CFLAGS forced from the command line, so DAR build failed.

I patched it and send the patch upstream, but for the time beign please
rebuild, otherwise the upgrade from EPEL's git not gonna work :-(

[Yury V. Zaytsev]

Hi!

I am puzzled by the lack of git-http-backend in our git package. What
makes me even more confused is that the man page is actually present as
it should.
--
Sincerely yours,
Yury V. Zaytsev

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.
i apologize for any disruption resulting from this bug. we'll push an updated package as soon as possible; for the meantime, please exclude git updates from your yum config.
thanks,
-steve
--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es
_______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users

[Yury V. Zaytsev]

Hi!

Post by Steve Huff
git-1.7.1-1, currently in the repo, has an erroneous dependency on
'perl(packed-refs)', which cannot be met because there is no such
pragma or module as packed-refs. this bug stems from the
overzealousness of rpm's automatic dependency discovery.

Well, git now (still) depends on git-cvs, which depends on cvsps, which
I thought I have ported from EPEL correctly (and I did a mock build
indeed), but I ignored the fact, that its makefile can't deal with
CFLAGS forced from the command line, so DAR build failed.

I patched it and send the patch upstream, but for the time beign please
rebuild, otherwise the upgrade from EPEL's git not gonna work :-(

[Yury V. Zaytsev]

Hi!

I am puzzled by the lack of git-http-backend in our git package. What
makes me even more confused is that the man page is actually present as
it should.
--
Sincerely yours,
Yury V. Zaytsev

Post by Steve Huff
hello folks!
git-1.7.1-1, currently in the repo, has an erroneous dependency on 'perl(packed-refs)', which cannot be met because there is no such pragma or module as packed-refs. this bug stems from the overzealousness of rpm's automatic dependency discovery.
i apologize for any disruption resulting from this bug. we'll push an updated package as soon as possible; for the meantime, please exclude git updates from your yum config.
thanks,
-steve
--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es
_______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users