Discussion:
[users] new rpm clamav 0.97.5
ml
2012-06-23 22:07:30 UTC
Permalink
hello folks and builder


you have an idea that should take the time to update rpmforge of deposit
for the new version of clamav rpm package

https://github.com/repoforge/rpms/commit/c9ea3f89205911cba0adf

even when this is over 2 days

sincerely
--
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC2626742
gpg --keyserver pgp.mit.edu --recv-key C2626742

http://urlshort.eu fakessh @
http://gplus.to/sshfake
http://gplus.to/sshswilting
http://gplus.to/john.swilting
https://lists.fakessh.eu/mailman/
This list is moderated by me, but all applications will be accepted
provided they receive a note of presentation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.repoforge.org/pipermail/users/attachments/20120624/36f8d5e0/attachment.bin
Christopher Meng
2012-06-24 00:18:15 UTC
Permalink
ok
Post by ml
hello folks and builder
you have an idea that should take the time to update rpmforge of deposit
for the new version of clamav rpm package
https://github.com/repoforge/rpms/commit/c9ea3f89205911cba0adf
even when this is over 2 days
sincerely
--
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC2626742
gpg --keyserver pgp.mit.edu --recv-key C2626742
http://gplus.to/sshfake
http://gplus.to/sshswilting
http://gplus.to/john.swilting
https://lists.fakessh.eu/mailman/
This list is moderated by me, but all applications will be accepted
provided they receive a note of presentation
--
Best Regards,
Christopher Meng------'Cicku'

Ambassador/Contributor of Fedora Project and Contributor of GNU.
Blog:http://cicku.me
Twitter:@cickumqt
Hope you can visit and leave some comments.
More Contact info see here:http://about.me/cicku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120624/da876d65/attachment.html
John R. Dennison
2012-06-24 00:35:26 UTC
Permalink
Post by ml
you have an idea that should take the time to update rpmforge of deposit
for the new version of clamav rpm package
https://github.com/repoforge/rpms/commit/c9ea3f89205911cba0adf
even when this is over 2 days
The problem is that the builds are not run and pushed to the mirrors in
a timely fashion. This is not a new issue, just a, sadly, recurring
one.

I'm not trying to speak ill of the repo or the contributors / Dag, but
there is a problem with process / workflow that has needed to be
addressed for quite some time.




John
--
I have lived with the prospect of an early death for the last 49 years.
I'm not afraid of death, but I'm in no hurry to die. I have so much I want
to do first. I regard the brain as a computer which will stop working when
its components fail. There is no heaven or afterlife for broken down
computers; that is a fairy story for people afraid of the dark.

-- Stephen Hawking (1942-), English theoretical physicist, in a Guardian
Newspaper interview, 15 May 2011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.repoforge.org/pipermail/users/attachments/20120623/56b434e0/attachment.bin
Christopher Meng
2012-06-24 01:11:28 UTC
Permalink
I agree.
Post by John R. Dennison
Post by ml
you have an idea that should take the time to update rpmforge of deposit
for the new version of clamav rpm package
https://github.com/repoforge/rpms/commit/c9ea3f89205911cba0adf
even when this is over 2 days
The problem is that the builds are not run and pushed to the mirrors in
a timely fashion. This is not a new issue, just a, sadly, recurring
one.
I'm not trying to speak ill of the repo or the contributors / Dag, but
there is a problem with process / workflow that has needed to be
addressed for quite some time.
John
--
I have lived with the prospect of an early death for the last 49 years.
I'm not afraid of death, but I'm in no hurry to die. I have so much I want
to do first. I regard the brain as a computer which will stop working when
its components fail. There is no heaven or afterlife for broken down
computers; that is a fairy story for people afraid of the dark.
-- Stephen Hawking (1942-), English theoretical physicist, in a Guardian
Newspaper interview, 15 May 2011
--
Best Regards,
Christopher Meng------'Cicku'

Ambassador/Contributor of Fedora Project and Contributor of GNU.
Blog:http://cicku.me
Twitter:@cickumqt
Hope you can visit and leave some comments.
More Contact info see here:http://about.me/cicku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120624/73b6cd48/attachment.html
Nico Kadel-Garcia
2012-06-24 01:45:49 UTC
Permalink
Post by John R. Dennison
Post by ml
you have an idea that should take the time to update rpmforge of deposit
for the new version of clamav rpm package
https://github.com/repoforge/rpms/commit/c9ea3f89205911cba0adf
even when this is over 2 days
The problem is that the builds are not run and pushed to the mirrors in
a timely fashion. ?This is not a new issue, just a, sadly, recurring
one.
I'm not trying to speak ill of the repo or the contributors / Dag, but
there is a problem with process / workflow that has needed to be
addressed for quite some time.
A better question, perhaps, is "how can we best help" ?
John R. Dennison
2012-06-24 02:44:28 UTC
Permalink
Post by Nico Kadel-Garcia
A better question, perhaps, is "how can we best help" ?
Not from my vantage point. It's been pretty clear that Dag will not
relinquish sole rights to kick off builds and push to the mirrors; at
least that has been his stance for a long time. And that's fine, it's
his repo after all. But it's not an ideal situation when things sit in
the pending queue for as long as they do.

The package in question, clam and it's subpackages, is arguably a
security update due to issues with the internal tar and chm components;
and while both can be considered to be corner-cases in the real world,
they are still cases nonetheless; the package should have been available
by this time. Out of fairness I will note that EPEL does not yet have
an update available either.






John
--
A man or woman is seldom happy unless he or she is sustaining him or herself
and making a contribution to others.

-- Hilary Hinton "Zig" Ziglar (1926-), American self-help author and speaker,
See You at the Top (2000)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.repoforge.org/pipermail/users/attachments/20120623/5f9c66a2/attachment.bin
Christopher Meng
2012-06-24 04:03:07 UTC
Permalink
yes.And that's why somebody hate this repo.
Post by John R. Dennison
Post by Nico Kadel-Garcia
A better question, perhaps, is "how can we best help" ?
Not from my vantage point. It's been pretty clear that Dag will not
relinquish sole rights to kick off builds and push to the mirrors; at
least that has been his stance for a long time. And that's fine, it's
his repo after all. But it's not an ideal situation when things sit in
the pending queue for as long as they do.
The package in question, clam and it's subpackages, is arguably a
security update due to issues with the internal tar and chm components;
and while both can be considered to be corner-cases in the real world,
they are still cases nonetheless; the package should have been available
by this time. Out of fairness I will note that EPEL does not yet have
an update available either.
John
--
A man or woman is seldom happy unless he or she is sustaining him or herself
and making a contribution to others.
-- Hilary Hinton "Zig" Ziglar (1926-), American self-help author and speaker,
See You at the Top (2000)
--
Best Regards,
Christopher Meng------'Cicku'

Ambassador/Contributor of Fedora Project and Contributor of GNU.
Blog:http://cicku.me
Twitter:@cickumqt
Hope you can visit and leave some comments.
More Contact info see here:http://about.me/cicku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120624/9f5c1c94/attachment.html
John R. Dennison
2012-06-24 05:43:15 UTC
Permalink
Post by Christopher Meng
yes.And that's why somebody hate this repo.
Hating this repo or EPEL or any other repo is pretty pointless. No one
is being forced at gunpoint to use any particular 3rd-party repo.

If one is unhappy with a specific repo they are free to use another one
that better fits their requirements or, as Nico alluded to, see if there
is some way that they can contribute and make the repo better for not
only themselves but for others as well - this may work well in some
cases and not so well in others.

People are also able to maintain and package their own components if
they feel that is the solution that works best for them. There is ample
documentation available to get someone started down this path, starting
with the Fedora packaging guidelines. I maintain quite a few of my own
packages for my own use and that of my clients (and I may end up doing
just that for clamav as well). There is a learning curve involved, but
when working with a package-based distribution it is, in my opinion,
time well spent.

I would also like to take a moment and publicly thank Dag and all the
contributors to rpmforge, and all the people that volunteer their time
and efforts for EPEL and all the other 3rd-party repos. All of your
efforts are greatly appreciated by us, the consumers of your work.





John
--
"Whenever two people meet, there are really six people present. There is each
man as he sees himself, each man as the other person sees him, and each man
as he really is."

-- William James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.repoforge.org/pipermail/users/attachments/20120624/177c2c63/attachment.bin
Christopher Meng
2012-06-24 06:29:32 UTC
Permalink
yeah, I agree. and thank you again.
--
Best Regards,
Christopher Meng------'Cicku'

Ambassador/Contributor of Fedora Project and Contributor of GNU.
Blog:http://cicku.me
Twitter:@cickumqt
Hope you can visit and leave some comments.
More Contact info see here:http://about.me/cicku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120624/036e04c9/attachment.html
Christopher Meng
2012-06-24 06:29:32 UTC
Permalink
yeah, I agree. and thank you again.
--
Best Regards,
Christopher Meng------'Cicku'

Ambassador/Contributor of Fedora Project and Contributor of GNU.
Blog:http://cicku.me
Twitter:@cickumqt
Hope you can visit and leave some comments.
More Contact info see here:http://about.me/cicku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120624/036e04c9/attachment-0002.html>
John R. Dennison
2012-06-24 05:43:15 UTC
Permalink
Post by Christopher Meng
yes.And that's why somebody hate this repo.
Hating this repo or EPEL or any other repo is pretty pointless. No one
is being forced at gunpoint to use any particular 3rd-party repo.

If one is unhappy with a specific repo they are free to use another one
that better fits their requirements or, as Nico alluded to, see if there
is some way that they can contribute and make the repo better for not
only themselves but for others as well - this may work well in some
cases and not so well in others.

People are also able to maintain and package their own components if
they feel that is the solution that works best for them. There is ample
documentation available to get someone started down this path, starting
with the Fedora packaging guidelines. I maintain quite a few of my own
packages for my own use and that of my clients (and I may end up doing
just that for clamav as well). There is a learning curve involved, but
when working with a package-based distribution it is, in my opinion,
time well spent.

I would also like to take a moment and publicly thank Dag and all the
contributors to rpmforge, and all the people that volunteer their time
and efforts for EPEL and all the other 3rd-party repos. All of your
efforts are greatly appreciated by us, the consumers of your work.





John
--
"Whenever two people meet, there are really six people present. There is each
man as he sees himself, each man as the other person sees him, and each man
as he really is."

-- William James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120624/177c2c63/attachment.sig>
Dag Wieers
2012-06-24 13:39:17 UTC
Permalink
Post by John R. Dennison
Post by Nico Kadel-Garcia
A better question, perhaps, is "how can we best help" ?
Not from my vantage point. It's been pretty clear that Dag will not
relinquish sole rights to kick off builds and push to the mirrors; at
least that has been his stance for a long time. And that's fine, it's
his repo after all. But it's not an ideal situation when things sit in
the pending queue for as long as they do.
Incorrect. I have stated many times that I would prefer a central
buildsystem and that I am no longer a single point of failure.
Post by John R. Dennison
The package in question, clam and it's subpackages, is arguably a
security update due to issues with the internal tar and chm components;
and while both can be considered to be corner-cases in the real world,
they are still cases nonetheless; the package should have been available
by this time. Out of fairness I will note that EPEL does not yet have
an update available either.
The problem in this case is not the fact that I didn't want to update it.
I have tried to build this the day it was released and two days later. The
problem is that upstream changed the tarball (no longer shipping a
database) and this has implications to our packages. If anyone care, the
logfiles were pushed in both cases showing the problem with the build. The
lack of time to dive into this and think about a solution is what is
causing the delay, if it was a mere update the packages would have been
online the same day as the release.

The fact that upstream only started to discuss this after the recent
release did not help a bit. It should have discussed before changing.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Yury V. Zaytsev
2012-06-24 16:51:40 UTC
Permalink
Post by John R. Dennison
Not from my vantage point. It's been pretty clear that Dag will not
relinquish sole rights to kick off builds and push to the mirrors; at
least that has been his stance for a long time. And that's fine, it's
his repo after all.
That's not really where we are standing now.

It's rather that he is unwilling to relinquish his signing key until
there is a process set up which he would be satisfied with that involves
a number of independent contributors and the result is not called "Dag's
private archive" any longer. Long-term transition to the "RepoForge"
brand is a part of this strategy...

I personally find this stance totally reasonable and would probably
request the same if I were him. Now the problem is that in order to get
there somebody needs to organize this whole thing and the manpower is
just not available at the moment.

In the past years I planned and performed migration to GitHub to remove
a part of the issue: reliance on Dag as a single PoF for accepting
contributions. We extensively discussed that on the lists and not only
he didn't oppose to that, but also helped with the migration.

Likewise, this year David heavily invested his time in mirroring
infrastructure and again his contribution was gratefully accepted. I
personally find his efforts to be of much value...

Unfortunately, I'm having *very* hard times these days and can't afford
contributing my time to creating an open building infrastructure in as
much as I recognize that this is an important, interesting and possibly
fun project for RepoForge.

I hope that in the future we will eventually tackle this last problem,
but at the moment there's a lack of resources rather than bad will that
prevents us from doing so...
--
Sincerely yours,
Yury V. Zaytsev
Christopher Meng
2012-06-24 23:10:58 UTC
Permalink
Can you describe the infrastructure 's meaning especially in repoforge?
Thanks.
--
Best Regards,
Christopher Meng------'Cicku'

Ambassador/Contributor of Fedora Project and Contributor of GNU.
Blog:http://cicku.me
Twitter:@cickumqt
Hope you can visit and leave some comments.
More Contact info see here:http://about.me/cicku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20120625/3f9372b4/attachment-0001.html
David Hrbáč
2012-06-25 09:19:06 UTC
Permalink
Post by Christopher Meng
Can you describe the infrastructure 's meaning especially in repoforge?
Thanks.
Chris,
Sorry, I don't understand the question.
DH
David Hrbáč
2012-06-25 09:19:06 UTC
Permalink
Post by Christopher Meng
Can you describe the infrastructure 's meaning especially in repoforge?
Thanks.
Chris,
Sorry, I don't understand the question.
DH
David Hrbáč
2012-06-25 09:05:33 UTC
Permalink
Post by Yury V. Zaytsev
I hope that in the future we will eventually tackle this last problem,
but at the moment there's a lack of resources rather than bad will that
prevents us from doing so...
I want to state this, just to make sure, we are REALLY aware of this
issue. We are not trying to go "take-it-or-don't-use-it" way. As to
resources, there's no lack of hw/sw resources. We are really short on
man-hours.

I'm going to start to work on a new distributed build infrastructure
soon, as it seems that I have the most resources available now.
Everybody's help will be appreciated. So, if you are familiar with Koji,
Bodhi, Mock et al., just drop me en email.
Regards,
David Hrb??
Yury V. Zaytsev
2012-06-25 09:19:33 UTC
Permalink
Post by David Hrbáč
I want to state this, just to make sure, we are REALLY aware of this
issue. We are not trying to go "take-it-or-don't-use-it" way. As to
resources, there's no lack of hw/sw resources. We are really short on
man-hours.
Right, sorry if I was unclear about that.
Post by David Hrbáč
I'm going to start to work on a new distributed build infrastructure
soon, as it seems that I have the most resources available now.
Everybody's help will be appreciated. So, if you are familiar with
Koji, Bodhi, Mock et al., just drop me en email.
You might wish to have a look at Goose / Ascendos people repos. There
was also some stuff left from Troy which might be of use...

I looked into setting up Koji on my hardware about a year ago, but it
looked pretty much hopeless to make such a system maintainable in the
long term unless you do it properly by packaging the whole stack and
writing puppet / chef classes to control it. As I didn't have time for
that, I simply gave up... :-(
--
Sincerely yours,
Yury V. Zaytsev
Yury V. Zaytsev
2012-06-25 09:19:33 UTC
Permalink
Post by David Hrbáč
I want to state this, just to make sure, we are REALLY aware of this
issue. We are not trying to go "take-it-or-don't-use-it" way. As to
resources, there's no lack of hw/sw resources. We are really short on
man-hours.
Right, sorry if I was unclear about that.
Post by David Hrbáč
I'm going to start to work on a new distributed build infrastructure
soon, as it seems that I have the most resources available now.
Everybody's help will be appreciated. So, if you are familiar with
Koji, Bodhi, Mock et al., just drop me en email.
You might wish to have a look at Goose / Ascendos people repos. There
was also some stuff left from Troy which might be of use...

I looked into setting up Koji on my hardware about a year ago, but it
looked pretty much hopeless to make such a system maintainable in the
long term unless you do it properly by packaging the whole stack and
writing puppet / chef classes to control it. As I didn't have time for
that, I simply gave up... :-(
--
Sincerely yours,
Yury V. Zaytsev
Christopher Meng
2012-06-24 23:10:58 UTC
Permalink
Can you describe the infrastructure 's meaning especially in repoforge?
Thanks.
--
Best Regards,
Christopher Meng------'Cicku'

Ambassador/Contributor of Fedora Project and Contributor of GNU.
Blog:http://cicku.me
Twitter:@cickumqt
Hope you can visit and leave some comments.
More Contact info see here:http://about.me/cicku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120625/3f9372b4/attachment-0002.html>
David Hrbáč
2012-06-25 09:05:33 UTC
Permalink
Post by Yury V. Zaytsev
I hope that in the future we will eventually tackle this last problem,
but at the moment there's a lack of resources rather than bad will that
prevents us from doing so...
I want to state this, just to make sure, we are REALLY aware of this
issue. We are not trying to go "take-it-or-don't-use-it" way. As to
resources, there's no lack of hw/sw resources. We are really short on
man-hours.

I'm going to start to work on a new distributed build infrastructure
soon, as it seems that I have the most resources available now.
Everybody's help will be appreciated. So, if you are familiar with Koji,
Bodhi, Mock et al., just drop me en email.
Regards,
David Hrb??
Christopher Meng
2012-06-24 04:03:07 UTC
Permalink
yes.And that's why somebody hate this repo.
Post by John R. Dennison
Post by Nico Kadel-Garcia
A better question, perhaps, is "how can we best help" ?
Not from my vantage point. It's been pretty clear that Dag will not
relinquish sole rights to kick off builds and push to the mirrors; at
least that has been his stance for a long time. And that's fine, it's
his repo after all. But it's not an ideal situation when things sit in
the pending queue for as long as they do.
The package in question, clam and it's subpackages, is arguably a
security update due to issues with the internal tar and chm components;
and while both can be considered to be corner-cases in the real world,
they are still cases nonetheless; the package should have been available
by this time. Out of fairness I will note that EPEL does not yet have
an update available either.
John
--
A man or woman is seldom happy unless he or she is sustaining him or herself
and making a contribution to others.
-- Hilary Hinton "Zig" Ziglar (1926-), American self-help author and speaker,
See You at the Top (2000)
--
Best Regards,
Christopher Meng------'Cicku'

Ambassador/Contributor of Fedora Project and Contributor of GNU.
Blog:http://cicku.me
Twitter:@cickumqt
Hope you can visit and leave some comments.
More Contact info see here:http://about.me/cicku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120624/9f5c1c94/attachment-0002.html>
Dag Wieers
2012-06-24 13:39:17 UTC
Permalink
Post by John R. Dennison
Post by Nico Kadel-Garcia
A better question, perhaps, is "how can we best help" ?
Not from my vantage point. It's been pretty clear that Dag will not
relinquish sole rights to kick off builds and push to the mirrors; at
least that has been his stance for a long time. And that's fine, it's
his repo after all. But it's not an ideal situation when things sit in
the pending queue for as long as they do.
Incorrect. I have stated many times that I would prefer a central
buildsystem and that I am no longer a single point of failure.
Post by John R. Dennison
The package in question, clam and it's subpackages, is arguably a
security update due to issues with the internal tar and chm components;
and while both can be considered to be corner-cases in the real world,
they are still cases nonetheless; the package should have been available
by this time. Out of fairness I will note that EPEL does not yet have
an update available either.
The problem in this case is not the fact that I didn't want to update it.
I have tried to build this the day it was released and two days later. The
problem is that upstream changed the tarball (no longer shipping a
database) and this has implications to our packages. If anyone care, the
logfiles were pushed in both cases showing the problem with the build. The
lack of time to dive into this and think about a solution is what is
causing the delay, if it was a mere update the packages would have been
online the same day as the release.

The fact that upstream only started to discuss this after the recent
release did not help a bit. It should have discussed before changing.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Yury V. Zaytsev
2012-06-24 16:51:40 UTC
Permalink
Post by John R. Dennison
Not from my vantage point. It's been pretty clear that Dag will not
relinquish sole rights to kick off builds and push to the mirrors; at
least that has been his stance for a long time. And that's fine, it's
his repo after all.
That's not really where we are standing now.

It's rather that he is unwilling to relinquish his signing key until
there is a process set up which he would be satisfied with that involves
a number of independent contributors and the result is not called "Dag's
private archive" any longer. Long-term transition to the "RepoForge"
brand is a part of this strategy...

I personally find this stance totally reasonable and would probably
request the same if I were him. Now the problem is that in order to get
there somebody needs to organize this whole thing and the manpower is
just not available at the moment.

In the past years I planned and performed migration to GitHub to remove
a part of the issue: reliance on Dag as a single PoF for accepting
contributions. We extensively discussed that on the lists and not only
he didn't oppose to that, but also helped with the migration.

Likewise, this year David heavily invested his time in mirroring
infrastructure and again his contribution was gratefully accepted. I
personally find his efforts to be of much value...

Unfortunately, I'm having *very* hard times these days and can't afford
contributing my time to creating an open building infrastructure in as
much as I recognize that this is an important, interesting and possibly
fun project for RepoForge.

I hope that in the future we will eventually tackle this last problem,
but at the moment there's a lack of resources rather than bad will that
prevents us from doing so...
--
Sincerely yours,
Yury V. Zaytsev
David Hrbáč
2012-06-24 07:37:50 UTC
Permalink
Post by Nico Kadel-Garcia
A better question, perhaps, is "how can we best help" ?
Nico's right. We know the issue and even the solution. We need to come
up with a new build infra and workflow to build, test, sign and push. We
can create something like "two or more sign-offs are ok" to sign and
push a new package in the wild.
DH
Dag Wieers
2012-06-24 13:50:16 UTC
Permalink
Post by David Hrbáč
Post by Nico Kadel-Garcia
A better question, perhaps, is "how can we best help" ?
Nico's right. We know the issue and even the solution. We need to come
up with a new build infra and workflow to build, test, sign and push. We
can create something like "two or more sign-offs are ok" to sign and
push a new package in the wild.
Indeed. The aim is to have a new repository (repoforge) and signature that
is managed by more than one person so that existing users can make the
deliberate choice from 'trusting me' to 'trusting the project'.

But that raises more than one question:

- who is to be trusted
- what infrastructure to be used
- project governance
- who has the time to help with this

I know that I am responsible for the lack and delay of updates at times
(clamav is not a good example) but I am not the sole responsible of this
project not moving to a new and better infrastructure and into a better
governed project.

Another point to raise, all SPEC files and changes are available, so
anyone with the time and energy to improve any process is welcome to do
so. There is no special sauce or machinery keeping you from doing what
this project is doing. If this works well, we can switch to this new
infrastructure.

One of the things mentioned several times was a repoclosure job that would
send repoclosure problems to the packagers list to identify and fixes
dependency problems. Anyone can do that already and start fixing issues.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
R - elists
2012-06-25 04:52:04 UTC
Permalink
whomever did it, Thank You :-) for pushing out the new clamav 0.97.5 for us

there was an issue in our main.cld, or part of a file format change or
something

said it was corrupt or whatever

...and bombed the final parts of the "yum update"

so that was easily fixed by running freshclam a time or two

renamed the file main.cld.broken and eventually pulled everything from
clamav servers

then had to actually start clamd

dunno if that helps anyone in regards to packaging

- rh
Tilman Schmidt
2012-06-25 08:24:21 UTC
Permalink
Post by R - elists
there was an issue in our main.cld, or part of a file format change or
something
said it was corrupt or whatever
...and bombed the final parts of the "yum update"
I think the actual issue is that package clamav-db contains both
cld and cvd files. ClamAV doc says you should only have one of
the two. What's more, the cld files are empty. So it seems that
something went wrong in the build process.

Prior to the update my installation had main.cvd and daily.cld.
After the update it had two additional files, daily.cld.rpmnew
and main.cld.broken, both empty. So it seems the new clamav-db
package brought along two spurious empty files daily.cld and
main.cld.
Post by R - elists
renamed the file main.cld.broken and eventually pulled everything from
clamav servers
then had to actually start clamd
I just removed daily.cld.rpmnew and main.cld.broken and started
clamd. Freshclam had already taken care of the rest. But may be
because I always run freshclam as a daemon, not as a cron job.

HTH
Tilman
--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
R - elists
2012-06-25 14:37:23 UTC
Permalink
Post by Tilman Schmidt
I think the actual issue is that package clamav-db contains
both cld and cvd files. ClamAV doc says you should only have
one of the two. What's more, the cld files are empty. So it
seems that something went wrong in the build process.
Prior to the update my installation had main.cvd and daily.cld.
After the update it had two additional files,
daily.cld.rpmnew and main.cld.broken, both empty. So it seems
the new clamav-db package brought along two spurious empty
files daily.cld and main.cld.
Post by R - elists
renamed the file main.cld.broken and eventually pulled
everything from
Post by R - elists
clamav servers
then had to actually start clamd
I just removed daily.cld.rpmnew and main.cld.broken and
started clamd. Freshclam had already taken care of the rest.
But may be because I always run freshclam as a daemon, not as
a cron job.
HTH
Tilman
we run freshclam as a cron job

and you are right, there was a CVD error too...

so we have two .broken files so to speak

main.cld.broken

and

main.cvd.broken

so there was simple conflict of some sort. i tried to copy and paste the
errors yet forgot to save it

ill check if i can find in the logs

and of course, after two manual freshclam runs, we were good to go

then manual

service clamd start

and up

:-)

thanks again!

- rh
R - elists
2012-06-25 14:37:23 UTC
Permalink
Post by Tilman Schmidt
I think the actual issue is that package clamav-db contains
both cld and cvd files. ClamAV doc says you should only have
one of the two. What's more, the cld files are empty. So it
seems that something went wrong in the build process.
Prior to the update my installation had main.cvd and daily.cld.
After the update it had two additional files,
daily.cld.rpmnew and main.cld.broken, both empty. So it seems
the new clamav-db package brought along two spurious empty
files daily.cld and main.cld.
Post by R - elists
renamed the file main.cld.broken and eventually pulled
everything from
Post by R - elists
clamav servers
then had to actually start clamd
I just removed daily.cld.rpmnew and main.cld.broken and
started clamd. Freshclam had already taken care of the rest.
But may be because I always run freshclam as a daemon, not as
a cron job.
HTH
Tilman
we run freshclam as a cron job

and you are right, there was a CVD error too...

so we have two .broken files so to speak

main.cld.broken

and

main.cvd.broken

so there was simple conflict of some sort. i tried to copy and paste the
errors yet forgot to save it

ill check if i can find in the logs

and of course, after two manual freshclam runs, we were good to go

then manual

service clamd start

and up

:-)

thanks again!

- rh

David Hrbáč
2012-06-25 09:15:04 UTC
Permalink
Post by R - elists
whomever did it, Thank You :-) for pushing out the new clamav 0.97.5 for us
there was an issue in our main.cld, or part of a file format change or
something
said it was corrupt or whatever
...and bombed the final parts of the "yum update"
so that was easily fixed by running freshclam a time or two
renamed the file main.cld.broken and eventually pulled everything from
clamav servers
then had to actually start clamd
dunno if that helps anyone in regards to packaging
- rh
Well,
Thanks for bug report. I have created an issue:
https://github.com/repoforge/rpms/issues/183 I'm going to investigate.

I prefer not to use clamav-db package, it's going to be outdated a day
after the release. It's too big to distribute. Better way is to use
freshclam.
Regards,
DH
Tilman Schmidt
2012-06-25 08:24:21 UTC
Permalink
Post by R - elists
there was an issue in our main.cld, or part of a file format change or
something
said it was corrupt or whatever
...and bombed the final parts of the "yum update"
I think the actual issue is that package clamav-db contains both
cld and cvd files. ClamAV doc says you should only have one of
the two. What's more, the cld files are empty. So it seems that
something went wrong in the build process.

Prior to the update my installation had main.cvd and daily.cld.
After the update it had two additional files, daily.cld.rpmnew
and main.cld.broken, both empty. So it seems the new clamav-db
package brought along two spurious empty files daily.cld and
main.cld.
Post by R - elists
renamed the file main.cld.broken and eventually pulled everything from
clamav servers
then had to actually start clamd
I just removed daily.cld.rpmnew and main.cld.broken and started
clamd. Freshclam had already taken care of the rest. But may be
because I always run freshclam as a daemon, not as a cron job.

HTH
Tilman
--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
David Hrbáč
2012-06-25 09:15:04 UTC
Permalink
Post by R - elists
whomever did it, Thank You :-) for pushing out the new clamav 0.97.5 for us
there was an issue in our main.cld, or part of a file format change or
something
said it was corrupt or whatever
...and bombed the final parts of the "yum update"
so that was easily fixed by running freshclam a time or two
renamed the file main.cld.broken and eventually pulled everything from
clamav servers
then had to actually start clamd
dunno if that helps anyone in regards to packaging
- rh
Well,
Thanks for bug report. I have created an issue:
https://github.com/repoforge/rpms/issues/183 I'm going to investigate.

I prefer not to use clamav-db package, it's going to be outdated a day
after the release. It's too big to distribute. Better way is to use
freshclam.
Regards,
DH
Yury V. Zaytsev
2012-06-25 08:02:57 UTC
Permalink
Post by Dag Wieers
One of the things mentioned several times was a repoclosure job that
would send repoclosure problems to the packagers list to identify and
fixes dependency problems. Anyone can do that already and start fixing
issues.
I'm not gonna have an Internet connection @ home for at least a couple
of months, but I now have a Jenkins box available elsewhere, so any kind
of lightweight periodic jobs I can run.

What does it take to set up a useful repoclosure job? I can mirror
locally form Esslingen, but then does repoclosure need local file system
access or it would be happy with a repo served over HTTP? Is it just a
matter of yum install repoclosure?
--
Sincerely yours,
Yury V. Zaytsev
R - elists
2012-06-25 04:52:04 UTC
Permalink
whomever did it, Thank You :-) for pushing out the new clamav 0.97.5 for us

there was an issue in our main.cld, or part of a file format change or
something

said it was corrupt or whatever

...and bombed the final parts of the "yum update"

so that was easily fixed by running freshclam a time or two

renamed the file main.cld.broken and eventually pulled everything from
clamav servers

then had to actually start clamd

dunno if that helps anyone in regards to packaging

- rh
Yury V. Zaytsev
2012-06-25 08:02:57 UTC
Permalink
Post by Dag Wieers
One of the things mentioned several times was a repoclosure job that
would send repoclosure problems to the packagers list to identify and
fixes dependency problems. Anyone can do that already and start fixing
issues.
I'm not gonna have an Internet connection @ home for at least a couple
of months, but I now have a Jenkins box available elsewhere, so any kind
of lightweight periodic jobs I can run.

What does it take to set up a useful repoclosure job? I can mirror
locally form Esslingen, but then does repoclosure need local file system
access or it would be happy with a repo served over HTTP? Is it just a
matter of yum install repoclosure?
--
Sincerely yours,
Yury V. Zaytsev
Nico Kadel-Garcia
2012-06-24 13:54:33 UTC
Permalink
Post by David Hrbáč
Post by Nico Kadel-Garcia
A better question, perhaps, is "how can we best help" ?
Nico's right. We know the issue and even the solution. We need to come
up with a new build infra and workflow to build, test, sign and push. We
can create something like "two or more sign-offs are ok" to sign and
push a new package in the wild.
DH
Even without push approva for the active repository, I wonder if some
continuous build/regresstion test environments hosted offsite would be
useful. I find it *really useful* to be able to build components I
work with using "mock" and run basic regression tests on them. I'd
love to make my build and test environments resemble Dag's as closely
as possible, so my submitted packagtes are more likely to work well in
the official Repoforge build environments.

Is the build environment well defined anywhere so I can do that?

I'm afraid I don't currently have the spare hardwre and bandwidth to
run a dynamic mirror of the Repoforge build tree. Not at home, and
since I'm a contractor, my workplace wouldn't currently spring for it.
But I've got a bunch of Perl modules I'd like to RPM wrap and publish
soon, and I'd love to do that with a similar build environment.
Yury V. Zaytsev
2012-06-25 07:57:38 UTC
Permalink
Post by Nico Kadel-Garcia
Is the build environment well defined anywhere so I can do that?
You can have a look for dar or pydar in the git repos, I vaguely
remember that I converted it to git at some point.

Dag's system basically consists of static chroots that have all packages
installed, as it predated mock & friends and now requires a very
significant effort to upgrade.

I would recommend you sticking with mock + local and repoforge repos, if
packages fail to build in Dag's environment that build fine in your mock
root, then there's a 99% chance that it's a problem with the former...
--
Sincerely yours,
Yury V. Zaytsev
David Hrbáč
2012-06-25 09:25:41 UTC
Permalink
Post by Nico Kadel-Garcia
Even without push approva for the active repository, I wonder if some
continuous build/regresstion test environments hosted offsite would be
useful. I find it *really useful* to be able to build components I
work with using "mock" and run basic regression tests on them. I'd
love to make my build and test environments resemble Dag's as closely
as possible, so my submitted packagtes are more likely to work well in
the official Repoforge build environments.
Continuous build/regression test environment would be well welcomed. My
internal work-flow is based on:
time for i in {4-x86_64,4-i386,5-x86_64,5-i386,6-x86_64,6-i386}; do
mock -r centos-$i gitolite-2.3-1.el5.hrb.src.rpm
--resultdir=./gitolite/"%(dist)s"/"%(target_arch)s"/; done

If everything's ok, go ehead to push.
Post by Nico Kadel-Garcia
Is the build environment well defined anywhere so I can do that?
Depends only on centos (base, update) and repoforge/repoforge-extras
repositories.
DH
Yury V. Zaytsev
2012-06-25 07:57:38 UTC
Permalink
Post by Nico Kadel-Garcia
Is the build environment well defined anywhere so I can do that?
You can have a look for dar or pydar in the git repos, I vaguely
remember that I converted it to git at some point.

Dag's system basically consists of static chroots that have all packages
installed, as it predated mock & friends and now requires a very
significant effort to upgrade.

I would recommend you sticking with mock + local and repoforge repos, if
packages fail to build in Dag's environment that build fine in your mock
root, then there's a 99% chance that it's a problem with the former...
--
Sincerely yours,
Yury V. Zaytsev
David Hrbáč
2012-06-25 09:25:41 UTC
Permalink
Post by Nico Kadel-Garcia
Even without push approva for the active repository, I wonder if some
continuous build/regresstion test environments hosted offsite would be
useful. I find it *really useful* to be able to build components I
work with using "mock" and run basic regression tests on them. I'd
love to make my build and test environments resemble Dag's as closely
as possible, so my submitted packagtes are more likely to work well in
the official Repoforge build environments.
Continuous build/regression test environment would be well welcomed. My
internal work-flow is based on:
time for i in {4-x86_64,4-i386,5-x86_64,5-i386,6-x86_64,6-i386}; do
mock -r centos-$i gitolite-2.3-1.el5.hrb.src.rpm
--resultdir=./gitolite/"%(dist)s"/"%(target_arch)s"/; done

If everything's ok, go ehead to push.
Post by Nico Kadel-Garcia
Is the build environment well defined anywhere so I can do that?
Depends only on centos (base, update) and repoforge/repoforge-extras
repositories.
DH
Dag Wieers
2012-06-24 13:50:16 UTC
Permalink
Post by David Hrbáč
Post by Nico Kadel-Garcia
A better question, perhaps, is "how can we best help" ?
Nico's right. We know the issue and even the solution. We need to come
up with a new build infra and workflow to build, test, sign and push. We
can create something like "two or more sign-offs are ok" to sign and
push a new package in the wild.
Indeed. The aim is to have a new repository (repoforge) and signature that
is managed by more than one person so that existing users can make the
deliberate choice from 'trusting me' to 'trusting the project'.

But that raises more than one question:

- who is to be trusted
- what infrastructure to be used
- project governance
- who has the time to help with this

I know that I am responsible for the lack and delay of updates at times
(clamav is not a good example) but I am not the sole responsible of this
project not moving to a new and better infrastructure and into a better
governed project.

Another point to raise, all SPEC files and changes are available, so
anyone with the time and energy to improve any process is welcome to do
so. There is no special sauce or machinery keeping you from doing what
this project is doing. If this works well, we can switch to this new
infrastructure.

One of the things mentioned several times was a repoclosure job that would
send repoclosure problems to the packagers list to identify and fixes
dependency problems. Anyone can do that already and start fixing issues.
--
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
Nico Kadel-Garcia
2012-06-24 13:54:33 UTC
Permalink
Post by David Hrbáč
Post by Nico Kadel-Garcia
A better question, perhaps, is "how can we best help" ?
Nico's right. We know the issue and even the solution. We need to come
up with a new build infra and workflow to build, test, sign and push. We
can create something like "two or more sign-offs are ok" to sign and
push a new package in the wild.
DH
Even without push approva for the active repository, I wonder if some
continuous build/regresstion test environments hosted offsite would be
useful. I find it *really useful* to be able to build components I
work with using "mock" and run basic regression tests on them. I'd
love to make my build and test environments resemble Dag's as closely
as possible, so my submitted packagtes are more likely to work well in
the official Repoforge build environments.

Is the build environment well defined anywhere so I can do that?

I'm afraid I don't currently have the spare hardwre and bandwidth to
run a dynamic mirror of the Repoforge build tree. Not at home, and
since I'm a contractor, my workplace wouldn't currently spring for it.
But I've got a bunch of Perl modules I'd like to RPM wrap and publish
soon, and I'd love to do that with a similar build environment.
John R. Dennison
2012-06-24 02:44:28 UTC
Permalink
Post by Nico Kadel-Garcia
A better question, perhaps, is "how can we best help" ?
Not from my vantage point. It's been pretty clear that Dag will not
relinquish sole rights to kick off builds and push to the mirrors; at
least that has been his stance for a long time. And that's fine, it's
his repo after all. But it's not an ideal situation when things sit in
the pending queue for as long as they do.

The package in question, clam and it's subpackages, is arguably a
security update due to issues with the internal tar and chm components;
and while both can be considered to be corner-cases in the real world,
they are still cases nonetheless; the package should have been available
by this time. Out of fairness I will note that EPEL does not yet have
an update available either.






John
--
A man or woman is seldom happy unless he or she is sustaining him or herself
and making a contribution to others.

-- Hilary Hinton "Zig" Ziglar (1926-), American self-help author and speaker,
See You at the Top (2000)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120623/5f9c66a2/attachment.sig>
David Hrbáč
2012-06-24 07:37:50 UTC
Permalink
Post by Nico Kadel-Garcia
A better question, perhaps, is "how can we best help" ?
Nico's right. We know the issue and even the solution. We need to come
up with a new build infra and workflow to build, test, sign and push. We
can create something like "two or more sign-offs are ok" to sign and
push a new package in the wild.
DH
David Hrbáč
2012-06-24 07:32:05 UTC
Permalink
Post by John R. Dennison
The problem is that the builds are not run and pushed to the mirrors in
a timely fashion. This is not a new issue, just a, sadly, recurring
one.
I'm not trying to speak ill of the repo or the contributors / Dag, but
there is a problem with process / workflow that has needed to be
addressed for quite some time.
John,
We are aware of this issue. We are trying to open the repo and the
processes and not rely just on Dag. I can't speak for Dag, but I'm
pretty sure Dag knows where the problem is. He has handed over his
powers. The only thing we, as a community, are not able to do so is to
build, sign, and push to the repo. As I have said, we understand where
the problem is sufficiently. We are working to eliminate this issue. We
want this this repo to be considered as community repo called Repoforge.
This is not Dag's private repo any more. All I can add now is that we
(contributors) do this on a volunteer basis and within our spare time.
That's why it all takes a lot of time and the progress is quite slow.
Thanks,
David Hrb??
Christopher Meng
2012-06-24 01:11:28 UTC
Permalink
I agree.
Post by John R. Dennison
Post by ml
you have an idea that should take the time to update rpmforge of deposit
for the new version of clamav rpm package
https://github.com/repoforge/rpms/commit/c9ea3f89205911cba0adf
even when this is over 2 days
The problem is that the builds are not run and pushed to the mirrors in
a timely fashion. This is not a new issue, just a, sadly, recurring
one.
I'm not trying to speak ill of the repo or the contributors / Dag, but
there is a problem with process / workflow that has needed to be
addressed for quite some time.
John
--
I have lived with the prospect of an early death for the last 49 years.
I'm not afraid of death, but I'm in no hurry to die. I have so much I want
to do first. I regard the brain as a computer which will stop working when
its components fail. There is no heaven or afterlife for broken down
computers; that is a fairy story for people afraid of the dark.
-- Stephen Hawking (1942-), English theoretical physicist, in a Guardian
Newspaper interview, 15 May 2011
--
Best Regards,
Christopher Meng------'Cicku'

Ambassador/Contributor of Fedora Project and Contributor of GNU.
Blog:http://cicku.me
Twitter:@cickumqt
Hope you can visit and leave some comments.
More Contact info see here:http://about.me/cicku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120624/73b6cd48/attachment-0002.html>
Nico Kadel-Garcia
2012-06-24 01:45:49 UTC
Permalink
Post by John R. Dennison
Post by ml
you have an idea that should take the time to update rpmforge of deposit
for the new version of clamav rpm package
https://github.com/repoforge/rpms/commit/c9ea3f89205911cba0adf
even when this is over 2 days
The problem is that the builds are not run and pushed to the mirrors in
a timely fashion. ?This is not a new issue, just a, sadly, recurring
one.
I'm not trying to speak ill of the repo or the contributors / Dag, but
there is a problem with process / workflow that has needed to be
addressed for quite some time.
A better question, perhaps, is "how can we best help" ?
David Hrbáč
2012-06-24 07:32:05 UTC
Permalink
Post by John R. Dennison
The problem is that the builds are not run and pushed to the mirrors in
a timely fashion. This is not a new issue, just a, sadly, recurring
one.
I'm not trying to speak ill of the repo or the contributors / Dag, but
there is a problem with process / workflow that has needed to be
addressed for quite some time.
John,
We are aware of this issue. We are trying to open the repo and the
processes and not rely just on Dag. I can't speak for Dag, but I'm
pretty sure Dag knows where the problem is. He has handed over his
powers. The only thing we, as a community, are not able to do so is to
build, sign, and push to the repo. As I have said, we understand where
the problem is sufficiently. We are working to eliminate this issue. We
want this this repo to be considered as community repo called Repoforge.
This is not Dag's private repo any more. All I can add now is that we
(contributors) do this on a volunteer basis and within our spare time.
That's why it all takes a lot of time and the progress is quite slow.
Thanks,
David Hrb??
ml
2012-06-23 22:07:30 UTC
Permalink
hello folks and builder


you have an idea that should take the time to update rpmforge of deposit
for the new version of clamav rpm package

https://github.com/repoforge/rpms/commit/c9ea3f89205911cba0adf

even when this is over 2 days

sincerely
--
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC2626742
gpg --keyserver pgp.mit.edu --recv-key C2626742

http://urlshort.eu fakessh @
http://gplus.to/sshfake
http://gplus.to/sshswilting
http://gplus.to/john.swilting
https://lists.fakessh.eu/mailman/
This list is moderated by me, but all applications will be accepted
provided they receive a note of presentation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120624/36f8d5e0/attachment.sig>
Christopher Meng
2012-06-24 00:18:15 UTC
Permalink
ok
Post by ml
hello folks and builder
you have an idea that should take the time to update rpmforge of deposit
for the new version of clamav rpm package
https://github.com/repoforge/rpms/commit/c9ea3f89205911cba0adf
even when this is over 2 days
sincerely
--
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC2626742
gpg --keyserver pgp.mit.edu --recv-key C2626742
http://gplus.to/sshfake
http://gplus.to/sshswilting
http://gplus.to/john.swilting
https://lists.fakessh.eu/mailman/
This list is moderated by me, but all applications will be accepted
provided they receive a note of presentation
--
Best Regards,
Christopher Meng------'Cicku'

Ambassador/Contributor of Fedora Project and Contributor of GNU.
Blog:http://cicku.me
Twitter:@cickumqt
Hope you can visit and leave some comments.
More Contact info see here:http://about.me/cicku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120624/da876d65/attachment-0002.html>
John R. Dennison
2012-06-24 00:35:26 UTC
Permalink
Post by ml
you have an idea that should take the time to update rpmforge of deposit
for the new version of clamav rpm package
https://github.com/repoforge/rpms/commit/c9ea3f89205911cba0adf
even when this is over 2 days
The problem is that the builds are not run and pushed to the mirrors in
a timely fashion. This is not a new issue, just a, sadly, recurring
one.

I'm not trying to speak ill of the repo or the contributors / Dag, but
there is a problem with process / workflow that has needed to be
addressed for quite some time.




John
--
I have lived with the prospect of an early death for the last 49 years.
I'm not afraid of death, but I'm in no hurry to die. I have so much I want
to do first. I regard the brain as a computer which will stop working when
its components fail. There is no heaven or afterlife for broken down
computers; that is a fairy story for people afraid of the dark.

-- Stephen Hawking (1942-), English theoretical physicist, in a Guardian
Newspaper interview, 15 May 2011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20120623/56b434e0/attachment.sig>
Loading...