Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
> > ... gzip, for example, has "timestamp" field in header. > > Try this locally, without any [D]VCS: > > > > % mkdir test && echo "one" > test/one.txt && echo "two" > test/two.txt > > % tar czf test1.tar.gz test && sleep 5 && tar czf test2.tar.gz test > > % md5 test1.tar.gz test2.tar.gz > > MD5 (test1.tar.gz) = 7b7c763a9d1d4edca7b5b415ab297fec > > MD5 (test2.tar.gz) = 703ac5387b2bd1146434516f1d761ed9 > > % gzip -d test1.tar.gz test2.tar.gz > > % md5 test1.tar test2.tar > > MD5 (test1.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 > > MD5 (test2.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 > > That is arguably a bug in "tar czf" :) but it is easy enough to > work around; we just need a checksum method -- e.g. SHA256_UNGZ -- > that pipes the distfile through gunzip when computing its checksum. > The problem goes beyond that: different standard tar formats can include mutable data like major and minor device numbers, and the atimes, uids, and gids of files. See, for example, tar(5). We would have to continually monitor whether each site generates tarballs with invariant checksums from the "same" files, or check the integrity of archive members after extraction. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Lev Serebryakov wrote: > ... gzip, for example, has "timestamp" field in header. > Try this locally, without any [D]VCS: > > % mkdir test && echo "one" > test/one.txt && echo "two" > test/two.txt > % tar czf test1.tar.gz test && sleep 5 && tar czf test2.tar.gz test > % md5 test1.tar.gz test2.tar.gz > MD5 (test1.tar.gz) = 7b7c763a9d1d4edca7b5b415ab297fec > MD5 (test2.tar.gz) = 703ac5387b2bd1146434516f1d761ed9 > % gzip -d test1.tar.gz test2.tar.gz > % md5 test1.tar test2.tar > MD5 (test1.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 > MD5 (test2.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 That is arguably a bug in "tar czf" :) but it is easy enough to work around; we just need a checksum method -- e.g. SHA256_UNGZ -- that pipes the distfile through gunzip when computing its checksum. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On Sun, Sep 11, 2011 at 01:01:31PM +0400, Lev Serebryakov wrote: > Hello, Perryh. > You wrote 11 сентября 2011 г., 10:05:59: > > > I can't address the non-specific "etc", but I would claim that each > > of those 3 specific examples is a VCS bug. Creating a tarball of a > > particular content set _should_ be a deterministic process: > Once again: gzip, for example, has "timestamp" field in header. Try > this locally, without any [D]VCS: > > % mkdir test && echo "one" > test/one.txt && echo "two" > test/two.txt > % tar czf test1.tar.gz test && sleep 5 && tar czf test2.tar.gz test > % md5 test1.tar.gz test2.tar.gz > MD5 (test1.tar.gz) = 7b7c763a9d1d4edca7b5b415ab297fec > MD5 (test2.tar.gz) = 703ac5387b2bd1146434516f1d761ed9 > % gzip -d test1.tar.gz test2.tar.gz > % md5 test1.tar test2.tar > MD5 (test1.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 > MD5 (test2.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 > % Now try the same with the -n option :) (and yes, I realize that you are probably aware of this, but so should any author of a system that automatically creates compressed tarballs out of not-ridigly-structured data) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 No language can express every thought unambiguously, least of all this one. signature.asc Description: Digital signature
Re: [RFC] New ports idea: github / gitorious / bitbucket
On Sun, 2011-09-11 at 23:52 +0400, Ruslan Mahmatkhanov wrote: > Ruslan Mahmatkhanov wrote on 11.09.2011 23:50: > > > > We will see that anyway - when user will try to extract changed > > distfile, he will get warning about incorrect checksum, so this is not > > the case, i believe. > > s/warning/error/g > > this error will stops the build. > Of course. I am not worried about the user, but from a maintainer's point of view it is helpful to get informed about that. Unless you check all your port's distfile hashes all the time it takes some time to discover if you have a bad mirror (and all other mirrors being fine). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket
Ruslan Mahmatkhanov wrote on 11.09.2011 23:50: We will see that anyway - when user will try to extract changed distfile, he will get warning about incorrect checksum, so this is not the case, i believe. s/warning/error/g this error will stops the build. -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket
C-S wrote on 11.09.2011 17:23: Sure it worth. From my POV, maintainer should be avoided the pleasure to mess with selfhosted and selfpackaged tarballs as much as possible. Besides of inconvenience it also less reliable (both in availability and security aspects). I'm perfectly happy to mirror anything if needed, by the way. Chris Selfhosting can be very helpful. I once had many downloads of hiawatha from my server in my logs. So, I checked the hashes and discovered that the distfile from the original homepage was not the same anymore. The author of hiawatha had changed the file without any announcements... Carlo We will see that anyway - when user will try to extract changed distfile, he will get warning about incorrect checksum, so this is not the case, i believe. -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket
>Sure it worth. From my POV, maintainer should be avoided the pleasure to > mess with selfhosted and selfpackaged tarballs as much as possible. > Besides of inconvenience it also less reliable (both in availability and > security aspects). > > > I'm perfectly happy to mirror anything if needed, by the way. > > > > Chris > Selfhosting can be very helpful. I once had many downloads of hiawatha from my server in my logs. So, I checked the hashes and discovered that the distfile from the original homepage was not the same anymore. The author of hiawatha had changed the file without any announcements... Carlo ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Hello, Perryh. You wrote 11 сентября 2011 г., 10:05:59: > I can't address the non-specific "etc", but I would claim that each > of those 3 specific examples is a VCS bug. Creating a tarball of a > particular content set _should_ be a deterministic process: Once again: gzip, for example, has "timestamp" field in header. Try this locally, without any [D]VCS: % mkdir test && echo "one" > test/one.txt && echo "two" > test/two.txt % tar czf test1.tar.gz test && sleep 5 && tar czf test2.tar.gz test % md5 test1.tar.gz test2.tar.gz MD5 (test1.tar.gz) = 7b7c763a9d1d4edca7b5b415ab297fec MD5 (test2.tar.gz) = 703ac5387b2bd1146434516f1d761ed9 % gzip -d test1.tar.gz test2.tar.gz % md5 test1.tar test2.tar MD5 (test1.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 MD5 (test2.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 % -- // Black Lion AKA Lev Serebryakov ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
"Matthew D. Fuller" wrote: > On Sat, Sep 10, 2011 at 07:03:41AM -0700 I heard the voice of > per...@pluto.rain.com, and lo! it spake thus: > > > > If I am understanding correctly, you seem to be saying that two > > distfiles autogenerated from the _same_ tag etc. in the _same_ > > repository, and actually containing exactly the same code, can > > nevertheless generate different checksums!? Wouldn't that be a > > bug in the DVCS? > > There're all sorts of ways the same content could wind up with > different checksums. The compression may happen slightly differently, > higher, or lower. The files could wind up in the tarball in a > different order. Timestamps could differ. etc. I can't address the non-specific "etc", but I would claim that each of those 3 specific examples is a VCS bug. Creating a tarball of a particular content set _should_ be a deterministic process: * The compression method, and the ordering of the files, should be consistent. * Each file's timestamp in the tarball should be the selected version's timestamp as recorded in the repository, typically the time when the selected version of that file was committed to the VCS. Ditto for directories, provided the VCS maintains directory history. * If the VCS does _not_ maintain directory history (which is a deficiency, but not really a "bug"), each directory's timestamp in the tarball should match the most-recent file or subdirectory in that directory. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
> The change occurred sometime in the last few months. This might be > related: > > https://github.com/blog/900-nodeload2-downloads-reloaded Ah, I see. Thanks for the link. Klaus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Chris Rees wrote on 10.09.2011 21:58: On 10 September 2011 18:47, Ruslan Mahmatkhanov wrote: Chris Rees wrote on 10.09.2011 21:33: Counterexamples welcome! Chris When i worked on net/erlyvideo port there on github were tarballs for some old versions of it. When i asked author to create tarballs for new versions too, he just delete all the tarballs :) So i just create and host them by myself. Hm, plain spiteful. I like to think (or hope) that's not representative of most of our upstream friends ;) Yep, for the second (and last) example - mediacore guys also ignored my request. But they use tags on github and has tarballs on main website. The main question is, is it worth us writing code to handle a small minority of projects that refuse, or is it just easier to host this same minority ourselves? Sure it worth. From my POV, maintainer should be avoided the pleasure to mess with selfhosted and selfpackaged tarballs as much as possible. Besides of inconvenience it also less reliable (both in availability and security aspects). I'm perfectly happy to mirror anything if needed, by the way. Chris -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On 10 September 2011 18:47, Ruslan Mahmatkhanov wrote: > Chris Rees wrote on 10.09.2011 21:33: >> >> >> Counterexamples welcome! >> >> Chris > > When i worked on net/erlyvideo port there on github were tarballs for some > old versions of it. When i asked author to create tarballs for new versions > too, he just delete all the tarballs :) > So i just create and host them by myself. > Hm, plain spiteful. I like to think (or hope) that's not representative of most of our upstream friends ;) The main question is, is it worth us writing code to handle a small minority of projects that refuse, or is it just easier to host this same minority ourselves? I'm perfectly happy to mirror anything if needed, by the way. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Chris Rees wrote on 10.09.2011 21:33: > Counterexamples welcome! Chris When i worked on net/erlyvideo port there on github were tarballs for some old versions of it. When i asked author to create tarballs for new versions too, he just delete all the tarballs :) So i just create and host them by myself. -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On 9 September 2011 15:28, Baptiste Daroussin wrote: > On Fri, Sep 09, 2011 at 02:24:37PM +0100, Klaus T. Aehlig wrote: >> > The main problem with that is: we have no way to keep a valid sum of the >> > distfiles if it is autogenerated (in particular with github) and this sum >> > is >> > really important. >> With github this fortunately is a non-issue. Even though they autogenerate >> their >> tar balls, they keep enough information to make them reproduciable. Just try: >> >> /tmp>fetch https://github.com/Dieterbe/uzbl/tarball/2011.07.25 >> 2011.07.25 100% of 143 kB 177 kBps >> /tmp>sha256 2011.07.25 >> SHA256 (2011.07.25) = >> 2e61fa6c62e48d3f13e95a4ea7e7aead65345f6c88a688844ef921685dffe565 >> /tmp>cat /usr/ports/www/uzbl/distinfo >> SHA256 (uzbl-0.0.0.2011.07.25.tar.gz) = >> 2e61fa6c62e48d3f13e95a4ea7e7aead65345f6c88a688844ef921685dffe565 >> SIZE (uzbl-0.0.0.2011.07.25.tar.gz) = 146851 >> /tmp> >> >> There still remain some minor issuses, like >> >> * due to autogeneration, you're quite likely to get a http-redirect, >> * filenames like 2011.07.25 are not too suitable for a distfile. >> >> But they certainly can be fixed by an appropriate framework. The nice thing >> is, >> github does the autogeneration right. >> >> Best, >> Klaus >> > > This is new because I already poke them about this in the past (more than a > year > ago and they clearly stated that they can't change that and that github people > shouldn't use this for realease but should use the real download space of > github) > > The issue opened about this seems to have disapear from github, maybe they > change their mind > I agree 100% with Bapt here-- I had the same problem with security/gorilla (I think it was gorilla...) -- the tarball wasn't stable over time and I had many problems with distinfo. I solved the problem, as Bapt suggested by approaching the author and politely asking if he would host the tarball on github. He agreed to do this. Most of the time developers using github simply overlook the problems of autogenerated tarballs, and just don't think to host dedicated ones -- I've never had a negative response from upstream about providing a proper stable tarball. Counterexamples welcome! Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On Fri, Sep 09, 2011 at 04:39:14PM +0100, Klaus T. Aehlig wrote: > > > Until recently, github required two requests to get a tarball: one to > > initiate the tarball creation, the other to download it. > > Yes, that's what I remember. The URL you got after the first redirect > was then good for a couple of days -- till eventually it wasn't used > for long enough time and the initial request was necessary again to > initiate tarball creation once again. > > When did they change that? That's definitely good news. The change occurred sometime in the last few months. This might be related: https://github.com/blog/900-nodeload2-downloads-reloaded -- Shaun Amott // PGP: 0x6B387A9A "A foolish consistency is the hobgoblin of little minds." - Ralph Waldo Emerson pgpt31kI015Db.pgp Description: PGP signature
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Hello, Perryh. You wrote 10 сентября 2011 г., 18:03:41: > If I am understanding correctly, you seem to be saying that two > distfiles autogenerated from the _same_ tag etc. in the _same_ > repository, and actually containing exactly the same code, can > nevertheless generate different checksums!? Wouldn't that be a > bug in the DVCS? If archive contains timestamp of its creation in header, checksums of ARCHIVE will be different for sure. -- // Black Lion AKA Lev Serebryakov ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On Sat, Sep 10, 2011 at 07:03:41AM -0700 I heard the voice of per...@pluto.rain.com, and lo! it spake thus: > > If I am understanding correctly, you seem to be saying that two > distfiles autogenerated from the _same_ tag etc. in the _same_ > repository, and actually containing exactly the same code, can > nevertheless generate different checksums!? Wouldn't that be a bug > in the DVCS? There're all sorts of ways the same content could wind up with different checksums. The compression may happen slightly differently, higher, or lower. The files could wind up in the tarball in a different order. Timestamps could differ. etc. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Baptiste Daroussin wrote: > The main problem with that is: we have no way to keep a valid sum > of the distfiles if it is autogenerated (in particular with github) > and this sum is really important. No question about the importance of the checksum, to prevent trojans and other problems if the distfile were to change "silently". If I am understanding correctly, you seem to be saying that two distfiles autogenerated from the _same_ tag etc. in the _same_ repository, and actually containing exactly the same code, can nevertheless generate different checksums!? Wouldn't that be a bug in the DVCS? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On Fri, Sep 09, 2011 at 03:05:42PM +0100, Klaus T. Aehlig wrote: > > > * due to autogeneration, you're quite likely to get a http-redirect, > > Does fetch support redirects? > > Yes. But for good reasons, Mk/bsd.ports.mk contains the line > > FETCH_ARGS?=-AFpr > > Note the -A. Of course, it's no problem to make an exception for github, but > at least, one should be aware of this. The redirect is often avoidable if you can determine the final URL of the distfile. Github only uses a single hostname for tarball downloads, so there is no issue with maintaining a list of mirrors. Until recently, github required two requests to get a tarball: one to initiate the tarball creation, the other to download it. I was able to work around this in one of my ports, but the hack is no longer needed. -- Shaun Amott // PGP: 0x6B387A9A "A foolish consistency is the hobgoblin of little minds." - Ralph Waldo Emerson pgpRTUDcBWUnD.pgp Description: PGP signature
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
> Until recently, github required two requests to get a tarball: one to > initiate the tarball creation, the other to download it. Yes, that's what I remember. The URL you got after the first redirect was then good for a couple of days -- till eventually it wasn't used for long enough time and the initial request was necessary again to initiate tarball creation once again. When did they change that? That's definitely good news. Klaus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On Fri, Sep 09, 2011 at 02:24:37PM +0100, Klaus T. Aehlig wrote: > > > > The main problem with that is: we have no way to keep a valid sum of the > > distfiles if it is autogenerated (in particular with github) and this sum is > > really important. > > > With github this fortunately is a non-issue. Even though they autogenerate > their > tar balls, they keep enough information to make them reproduciable. Just try: > > /tmp>fetch https://github.com/Dieterbe/uzbl/tarball/2011.07.25 > 2011.07.25100% of 143 kB 177 kBps > /tmp>sha256 2011.07.25 > SHA256 (2011.07.25) = > 2e61fa6c62e48d3f13e95a4ea7e7aead65345f6c88a688844ef921685dffe565 > /tmp>cat /usr/ports/www/uzbl/distinfo > SHA256 (uzbl-0.0.0.2011.07.25.tar.gz) = > 2e61fa6c62e48d3f13e95a4ea7e7aead65345f6c88a688844ef921685dffe565 > SIZE (uzbl-0.0.0.2011.07.25.tar.gz) = 146851 > /tmp> > > There still remain some minor issuses, like > > * due to autogeneration, you're quite likely to get a http-redirect, > * filenames like 2011.07.25 are not too suitable for a distfile. > > But they certainly can be fixed by an appropriate framework. The nice thing > is, > github does the autogeneration right. > > Best, > Klaus > This is new because I already poke them about this in the past (more than a year ago and they clearly stated that they can't change that and that github people shouldn't use this for realease but should use the real download space of github) The issue opened about this seems to have disapear from github, maybe they change their mind regards, Bapt pgpzmDDTJ4Neb.pgp Description: PGP signature
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
> > * due to autogeneration, you're quite likely to get a http-redirect,
> Does fetch support redirects?
Yes. But for good reasons, Mk/bsd.ports.mk contains the line
FETCH_ARGS?=-AFpr
Note the -A. Of course, it's no problem to make an exception for github, but
at least, one should be aware of this.
> > * filenames like 2011.07.25 are not too suitable for a distfile.
> DIST_SUBIDR=${PORTNAME} is solution for this.
yes. And a github framework probably should set this by default...
Best,
Klaus
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Hello, Klaus.
You wrote 9 сентября 2011 г., 17:24:37:
> * due to autogeneration, you're quite likely to get a http-redirect,
Does fetch support redirects?
> * filenames like 2011.07.25 are not too suitable for a distfile.
DIST_SUBIDR=${PORTNAME} is solution for this.
--
// Black Lion AKA Lev Serebryakov
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
> I've thought about checksums, but my simple experiment shows, that > tag-related (not tip-related, of course) archives give same chsum > after re-downloading in short time. But I don't check it for long-term > stability. Well, let's do at least one check with a one and a half year old tar ball. [root@kta1c10 /tmp]# fetch https://github.com/Dieterbe/uzbl/tarball/2010.01.05 2010.01.05100% of 130 kB 320 kBps [root@kta1c10 /tmp]# sha256 2010.01.05 SHA256 (2010.01.05) = 0aae5c9994d968b4f4ec7f8f2ce935c25e25d19cabbce27e3ded0672756132c8 [root@kta1c10 /tmp]# cd /usr/ports/www/uzbl/ [root@kta1c10 /usr/ports/www/uzbl]# cvs diff -r1.1 distinfo Index: distinfo === RCS file: /usr/ctm/cvs-cur/ports/www/uzbl/distinfo,v retrieving revision 1.1 retrieving revision 1.11 diff -r1.1 -r1.11 1,3c1,2 < MD5 (uzbl-0.0.0.2010.01.05.tar.gz) = 2574fc68a7a7693297d371ca58a4edb4 < SHA256 (uzbl-0.0.0.2010.01.05.tar.gz) = 0aae5c9994d968b4f4ec7f8f2ce935c25e25d19cabbce27e3ded0672756132c8 < SIZE (uzbl-0.0.0.2010.01.05.tar.gz) = 133875 --- > SHA256 (uzbl-0.0.0.2011.07.25.tar.gz) = > 2e61fa6c62e48d3f13e95a4ea7e7aead65345f6c88a688844ef921685dffe565 > SIZE (uzbl-0.0.0.2011.07.25.tar.gz) = 146851 [root@kta1c10 /usr/ports/www/uzbl]# There it works as well... Best, Klaus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Hello, Baptiste. You wrote 9 сентября 2011 г., 17:04:58: > The main problem with that is: we have no way to keep a valid sum of the > distfiles if it is autogenerated (in particular with github) and this sum is > really important. I've thought about checksums, but my simple experiment shows, that tag-related (not tip-related, of course) archives give same chsum after re-downloading in short time. But I don't check it for long-term stability. Ok, other idea: check-out sources (require hg/git as BUILD dependency, but anyway user will need them to build software by hands) and check strong checksum of checked out revision (as both DVCS uses strong checksums as IDs internally). It is more complex feature, than adding additional MASTER_SITES, for sure. -- // Black Lion AKA Lev Serebryakov ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
> The main problem with that is: we have no way to keep a valid sum of the > distfiles if it is autogenerated (in particular with github) and this sum is > really important. With github this fortunately is a non-issue. Even though they autogenerate their tar balls, they keep enough information to make them reproduciable. Just try: /tmp>fetch https://github.com/Dieterbe/uzbl/tarball/2011.07.25 2011.07.25100% of 143 kB 177 kBps /tmp>sha256 2011.07.25 SHA256 (2011.07.25) = 2e61fa6c62e48d3f13e95a4ea7e7aead65345f6c88a688844ef921685dffe565 /tmp>cat /usr/ports/www/uzbl/distinfo SHA256 (uzbl-0.0.0.2011.07.25.tar.gz) = 2e61fa6c62e48d3f13e95a4ea7e7aead65345f6c88a688844ef921685dffe565 SIZE (uzbl-0.0.0.2011.07.25.tar.gz) = 146851 /tmp> There still remain some minor issuses, like * due to autogeneration, you're quite likely to get a http-redirect, * filenames like 2011.07.25 are not too suitable for a distfile. But they certainly can be fixed by an appropriate framework. The nice thing is, github does the autogeneration right. Best, Klaus ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On Fri, Sep 09, 2011 at 02:30:52PM +0400, Lev Serebryakov wrote: > Hello, Freebsd-ports. > > I notice, that many software projects are hosted on social DVCS > hostings nowadays. > > Other common "feature" among them is absence of "official" tarballs > for versions. I don't say, that ALL projects whith primary hosting on > these DVCS sites don't publish official tarballs. But many of them > don't. > > On other hand, all these DVCS sites provide way to download auto-generated > tarballs > for any tag or branch or revision. > > Maybe, we need support for this model to ports system directly? Like > we support SourceForge and other code hosting sites. > The main problem with that is: we have no way to keep a valid sum of the distfiles if it is autogenerated (in particular with github) and this sum is really important. regards, Bapt pgpmHhPdusTdh.pgp Description: PGP signature
[RFC] New ports idea: github / gitorious / bitbucket direct support.
Hello, Freebsd-ports. I notice, that many software projects are hosted on social DVCS hostings nowadays. Other common "feature" among them is absence of "official" tarballs for versions. I don't say, that ALL projects whith primary hosting on these DVCS sites don't publish official tarballs. But many of them don't. On other hand, all these DVCS sites provide way to download auto-generated tarballs for any tag or branch or revision. Maybe, we need support for this model to ports system directly? Like we support SourceForge and other code hosting sites. -- // Black Lion AKA Lev Serebryakov ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
