* New btrfs-progs integration branch
@ 2012-06-05 19:09 Hugo Mills
2012-06-06 11:48 ` Helmut Hullen
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Hugo Mills @ 2012-06-05 19:09 UTC (permalink / raw)
To: Btrfs mailing list
[-- Attachment #1: Type: text/plain, Size: 2688 bytes --]
I've just pushed out a new integration branch to my git repo. This
is purely bugfix patches -- there are no new features in this issue of
the integration branch. I've got a stack of about a dozen more patches
with new features in them still to go. I'll be working on those
tomorrow. As always, there's minimal testing involved here, but it
does at least compile on my system(*).
The branch is fetchable with git from:
http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20120605
And viewable in human-readable form at:
http://git.darksatanic.net/cgi/gitweb.cgi?p=btrfs-progs-unstable.git
Shortlog is below.
Hugo.
(*) "I don't care about works-on-my-machine. We are not shipping your
machine!"
----
Akira Fujita (1):
Btrfs-progs: Fix manual of btrfs command
Chris Samuel (1):
Fix "set-dafault" typo in cmds-subvolume.c
Csaba Tóth (1):
mkfs.btrfs on ARM
Goffredo Baroncelli (1):
scrub_fs_info( ) file handle leaking
Hubert Kario (2):
Fix segmentation fault when opening invalid file system
man: fix btrfs man page formatting
Jan Kara (1):
mkfs: Handle creation of filesystem larger than the first device
Jim Meyering (5):
btrfs_scan_one_dir: avoid use-after-free on error path
mkfs: use strdup in place of strlen,malloc,strcpy sequence
restore: don't corrupt stack for a zero-length command-line argument
avoid several strncpy-induced buffer overruns
mkfs: avoid heap-buffer-read-underrun for zero-length "size" arg
Josef Bacik (3):
Btrfs-progs: make btrfsck aware of free space inodes
Btrfs-progs: make btrfs filesystem show <uuid> actually work
btrfs-progs: enforce block count on all devices in mkfs
Miao Xie (3):
Btrfs-progs: fix btrfsck's snapshot wrong "unresolved refs"
Btrfs-progs, btrfs-corrupt-block: fix the wrong usage
Btrfs-progs, btrfs-map-logical: Fix typo in usage
Phillip Susi (2):
btrfs-progs: removed extraneous whitespace from mkfs man page
btrfs-progs: document --rootdir mkfs switch
Sergei Trofimovich (2):
Makefile: use $(CC) as a compilers instead of $(CC)/gcc
Makefile: use $(MAKE) instead of hardcoded 'make'
Shawn Bohrer (1):
btrfs-progs: Update resize documentation
Wang Sheng-Hui (1):
btrfs-progs: cleanup: remove the redundant BTRFS_CSUM_TYPE_CRC32 macro def
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Great oxymorons of the world, no. 5: Manifesto Promise ---
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-05 19:09 New btrfs-progs integration branch Hugo Mills
@ 2012-06-06 11:48 ` Helmut Hullen
2012-06-06 13:14 ` Hugo Mills
2012-06-07 1:08 ` Jérôme Poulin
2012-06-26 8:58 ` Alex Lyakas
2 siblings, 1 reply; 14+ messages in thread
From: Helmut Hullen @ 2012-06-06 11:48 UTC (permalink / raw)
To: linux-btrfs
Hallo, Hugo,
Du meintest am 05.06.12:
> The branch is fetchable with git from:
> http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
> integration-20120605
There seems to be a bug inside:
[...]
gcc -g -O0 -o btrfsck btrfsck.o ctree.o disk-io.o radix-tree.o extent-
tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o
inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o
utils.o btrfs-list.o btrfslabel.o repair.o -luuid
gcc -g -O0 -o btrfs-convert ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o btrfslabel.o repair.o convert.o -lext2fs -lcom_err -luuid
gcc convert.o -o convert
convert.o: In function `btrfs_item_key':
/tmp/btrfs-progs-unstable/ctree.h:1404: undefined reference to `read_extent_buffer'
convert.o: In function `btrfs_dir_item_key':
/tmp/btrfs-progs-unstable/ctree.h:1437: undefined reference to `read_extent_buffer'
convert.o: In function `btrfs_del_item':
[...]
Viele Gruesse!
Helmut
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-06 11:48 ` Helmut Hullen
@ 2012-06-06 13:14 ` Hugo Mills
2012-06-06 15:03 ` Helmut Hullen
2012-06-06 19:13 ` Helmut Hullen
0 siblings, 2 replies; 14+ messages in thread
From: Hugo Mills @ 2012-06-06 13:14 UTC (permalink / raw)
To: helmut; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]
On Wed, Jun 06, 2012 at 01:48:00PM +0200, Helmut Hullen wrote:
> Hallo, Hugo,
>
> Du meintest am 05.06.12:
>
> > The branch is fetchable with git from:
>
> > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
> > integration-20120605
>
> There seems to be a bug inside:
>
> [...]
>
> gcc -g -O0 -o btrfsck btrfsck.o ctree.o disk-io.o radix-tree.o extent-
> tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o
> inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o
> utils.o btrfs-list.o btrfslabel.o repair.o -luuid
>
> gcc -g -O0 -o btrfs-convert ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o btrfslabel.o repair.o convert.o -lext2fs -lcom_err -luuid
>
> gcc convert.o -o convert
> convert.o: In function `btrfs_item_key':
> /tmp/btrfs-progs-unstable/ctree.h:1404: undefined reference to `read_extent_buffer'
> convert.o: In function `btrfs_dir_item_key':
> /tmp/btrfs-progs-unstable/ctree.h:1437: undefined reference to `read_extent_buffer'
> convert.o: In function `btrfs_del_item':
Odd. I've just tried this on a clean clone of my repo, and it's
building fine. It's declared in extent_io.h, and defined in
extent_io.c.
However, it does look like there's a problem with the make process:
my Makefile says:
btrfs-convert: $(objects) convert.o
$(CC) $(CFLAGS) -o btrfs-convert $(objects) convert.o -lext2fs -lcom_err $(LDFLAGS) $(LIBS)
... which seems to be what the second line you quoted is doing.
However, the third line with the problem looks like something out of
date. Possibly a mis-merge?
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- I am but mad north-north-west: when the wind is southerly, I ---
know a hawk from a handsaw.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-06 13:14 ` Hugo Mills
@ 2012-06-06 15:03 ` Helmut Hullen
2012-06-06 15:40 ` Hugo Mills
2012-06-06 19:13 ` Helmut Hullen
1 sibling, 1 reply; 14+ messages in thread
From: Helmut Hullen @ 2012-06-06 15:03 UTC (permalink / raw)
To: linux-btrfs
Hallo, Hugo,
Du meintest am 06.06.12:
> However, the third line with the problem looks like something out of
> date. Possibly a mis-merge?
Where should I search?
Viele Gruesse!
Helmut
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-06 15:03 ` Helmut Hullen
@ 2012-06-06 15:40 ` Hugo Mills
2012-06-06 15:52 ` Helmut Hullen
0 siblings, 1 reply; 14+ messages in thread
From: Hugo Mills @ 2012-06-06 15:40 UTC (permalink / raw)
To: helmut; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]
On Wed, Jun 06, 2012 at 05:03:00PM +0200, Helmut Hullen wrote:
> Hallo, Hugo,
>
> Du meintest am 06.06.12:
>
> > However, the third line with the problem looks like something out of
> > date. Possibly a mis-merge?
>
> Where should I search?
Well, the first thing would be to try a completely new clone of the
repo, then git co integration-20120605, and run make again. If that's
OK, then take a look with gitk in the broken repo and see what kind of
history you've got in there -- it should be a single unbroken sequence
from "master" (1957076ab4fefa47b6efed3da541bc974c83eed7) to
"integration-20120605" (d4c539067d1cb2476c7fb6003625de26e84059af).
Also have a look in the Makefile of the broken repo -- all of the
commands (listed near the top, assigned to the "progs" variable)
should start with "btrfs", and there should be no rule for "convert"
in there. Again, if that's not the case, you've managed to mis-merge
or check out the wrong branch.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- We are all lying in the gutter, but some of us are looking ---
at the stars.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-06 15:40 ` Hugo Mills
@ 2012-06-06 15:52 ` Helmut Hullen
2012-06-06 16:04 ` Hugo Mills
0 siblings, 1 reply; 14+ messages in thread
From: Helmut Hullen @ 2012-06-06 15:52 UTC (permalink / raw)
To: linux-btrfs
Hallo, Hugo,
Du meintest am 06.06.12:
>>> However, the third line with the problem looks like something out
>>> of date. Possibly a mis-merge?
>>
>> Where should I search?
> Well, the first thing would be to try a completely new clone of
> the repo, then git co integration-20120605, and run make again.
I had a brand new git clone.
Produced with
[...]
git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git
cd btrfs-progs-unstable
git checkout integration-20120605
(and "btrfs-progs-unstable" had been empty before "checkout")
> If
> that's OK, then take a look with gitk in the broken repo and see what
> kind of history you've got in there -- it should be a single unbroken
> sequence from "master" (1957076ab4fefa47b6efed3da541bc974c83eed7) to
> "integration-20120605" (d4c539067d1cb2476c7fb6003625de26e84059af).
I don't know much about working with git ... but I suppose I'm not
working with such things as a (broken) repo.
It's the same way I had successfully compiled your version from 20111012
and from 20111030.
Is there any change compiling the new version?
Viele Gruesse!
Helmut
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-06 15:52 ` Helmut Hullen
@ 2012-06-06 16:04 ` Hugo Mills
2012-06-06 16:18 ` Helmut Hullen
0 siblings, 1 reply; 14+ messages in thread
From: Hugo Mills @ 2012-06-06 16:04 UTC (permalink / raw)
To: helmut; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]
On Wed, Jun 06, 2012 at 05:52:00PM +0200, Helmut Hullen wrote:
> Hallo, Hugo,
>
> Du meintest am 06.06.12:
>
> >>> However, the third line with the problem looks like something out
> >>> of date. Possibly a mis-merge?
> >>
> >> Where should I search?
>
> > Well, the first thing would be to try a completely new clone of
> > the repo, then git co integration-20120605, and run make again.
>
> I had a brand new git clone.
>
> Produced with
>
> [...]
> git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git
> cd btrfs-progs-unstable
> git checkout integration-20120605
>
> (and "btrfs-progs-unstable" had been empty before "checkout")
>
> > If
> > that's OK, then take a look with gitk in the broken repo and see what
> > kind of history you've got in there -- it should be a single unbroken
> > sequence from "master" (1957076ab4fefa47b6efed3da541bc974c83eed7) to
> > "integration-20120605" (d4c539067d1cb2476c7fb6003625de26e84059af).
>
> I don't know much about working with git ... but I suppose I'm not
> working with such things as a (broken) repo.
>
> It's the same way I had successfully compiled your version from 20111012
> and from 20111030.
>
> Is there any change compiling the new version?
No, just type make from the directory.
Can you compare your Makefile with the one at [1] -- in particular
the progs variable at line 21-23, the "all" target on line 37, and the
"btrfs-convert" target on line 97. There definitely should not be a
plain "convert" target in there, but that seems to be what your system
was failing on.
Hugo.
[1] http://git.darksatanic.net/cgi/gitweb.cgi?p=btrfs-progs-unstable.git;a=blob;f=Makefile;h=96944449366d506918db711245aa771d103698a7;hb=integration-20120605
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- We are all lying in the gutter, but some of us are looking ---
at the stars.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-06 16:04 ` Hugo Mills
@ 2012-06-06 16:18 ` Helmut Hullen
2012-06-06 16:26 ` Hugo Mills
0 siblings, 1 reply; 14+ messages in thread
From: Helmut Hullen @ 2012-06-06 16:18 UTC (permalink / raw)
To: linux-btrfs
Hallo, Hugo,
Du meintest am 06.06.12:
>> git checkout integration-20120605
[...]
> Can you compare your Makefile with the one at [1] -- in particular
> the progs variable at line 21-23, the "all" target on line 37, and
> the "btrfs-convert" target on line 97. There definitely should not be
> a plain "convert" target in there, but that seems to be what your
> system was failing on.
Makefile with 3888 Bytes.
"md5sum Makefile" shows
(my file)
deef961e3ecd560ad8710cf0b58f5570 Makefile
(the file from your link)
deef961e3ecd560ad8710cf0b58f5570 Makefile
The problem is somewhere on another place ...
Viele Gruesse!
Helmut
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-06 16:18 ` Helmut Hullen
@ 2012-06-06 16:26 ` Hugo Mills
0 siblings, 0 replies; 14+ messages in thread
From: Hugo Mills @ 2012-06-06 16:26 UTC (permalink / raw)
To: helmut; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
On Wed, Jun 06, 2012 at 06:18:00PM +0200, Helmut Hullen wrote:
> Hallo, Hugo,
>
> Du meintest am 06.06.12:
>
> >> git checkout integration-20120605
>
> [...]
> > Can you compare your Makefile with the one at [1] -- in particular
> > the progs variable at line 21-23, the "all" target on line 37, and
> > the "btrfs-convert" target on line 97. There definitely should not be
> > a plain "convert" target in there, but that seems to be what your
> > system was failing on.
>
> Makefile with 3888 Bytes.
>
> "md5sum Makefile" shows
>
> (my file)
> deef961e3ecd560ad8710cf0b58f5570 Makefile
>
> (the file from your link)
> deef961e3ecd560ad8710cf0b58f5570 Makefile
>
> The problem is somewhere on another place ...
OK, can you send through the complete output of:
$ make clean
$ gcc --version
$ make --version
$ make
$ for f in .*.d; do echo == $d; cat $d; done
My guess is that the dependency generation is going wrong somewhere.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- There's many a slip 'twixt wicket-keeper and gully. ---
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-06 13:14 ` Hugo Mills
2012-06-06 15:03 ` Helmut Hullen
@ 2012-06-06 19:13 ` Helmut Hullen
1 sibling, 0 replies; 14+ messages in thread
From: Helmut Hullen @ 2012-06-06 19:13 UTC (permalink / raw)
To: linux-btrfs
Hallo, Hugo,
Du meintest am 06.06.12:
>>> The branch is fetchable with git from:
>>
>>> http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
>>> integration-20120605
>> gcc convert.o -o convert
>> convert.o: In function `btrfs_item_key':
>> /tmp/btrfs-progs-unstable/ctree.h:1404: undefined reference to
>> `read_extent_buffer' convert.o:
[...]
Solved - thanks for your help!
You have changed the Makefile;
make convert
does not more work, it has changed to
make btrfs-convert
-------------------------------
You can find the slackware binary at
<http://helmut.hullen.de/filebox/Linux/slackware/ap/btrfs-progs-20120606-i486-1hln.txz>
Viele Gruesse!
Helmut
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-05 19:09 New btrfs-progs integration branch Hugo Mills
2012-06-06 11:48 ` Helmut Hullen
@ 2012-06-07 1:08 ` Jérôme Poulin
2012-06-26 8:58 ` Alex Lyakas
2 siblings, 0 replies; 14+ messages in thread
From: Jérôme Poulin @ 2012-06-07 1:08 UTC (permalink / raw)
To: Hugo Mills, Btrfs mailing list
On Tue, Jun 5, 2012 at 3:09 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
>
> I've just pushed out a new integration branch to my git repo. This
> is purely bugfix patches -- there are no new features in this issue of
> the integration branch. I've got a stack of about a dozen more patches
> with new features in them still to go.
I was wondering if in the new patches you had the ReiserFS converter in queue?
http://www.spinics.net/lists/linux-btrfs/msg04985.html
It seems out for a while, I did try it out without any issue on my
main partition 2 years ago. This is not my patch but would you need
more testing before getting it integrated?
-- Repost, forgot to disable HTML.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-05 19:09 New btrfs-progs integration branch Hugo Mills
2012-06-06 11:48 ` Helmut Hullen
2012-06-07 1:08 ` Jérôme Poulin
@ 2012-06-26 8:58 ` Alex Lyakas
2012-06-26 9:58 ` Hugo Mills
2 siblings, 1 reply; 14+ messages in thread
From: Alex Lyakas @ 2012-06-26 8:58 UTC (permalink / raw)
To: Hugo Mills, Btrfs mailing list
Hi Hugo,
forgive me, but I am somewhat confused.
What is the "main" repo of btrfs-progs, if there is such thing?
I see patches coming in, but no updates to
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git,
which I thought was the one.
Can you pls clarify where should I pull updates from for btrfs-progs?
Thanks,
Alex.
On Tue, Jun 5, 2012 at 10:09 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
> I've just pushed out a new integration branch to my git repo. This
> is purely bugfix patches -- there are no new features in this issue of
> the integration branch. I've got a stack of about a dozen more patches
> with new features in them still to go. I'll be working on those
> tomorrow. As always, there's minimal testing involved here, but it
> does at least compile on my system(*).
>
> The branch is fetchable with git from:
>
> http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20120605
>
> And viewable in human-readable form at:
>
> http://git.darksatanic.net/cgi/gitweb.cgi?p=btrfs-progs-unstable.git
>
> Shortlog is below.
>
> Hugo.
>
> (*) "I don't care about works-on-my-machine. We are not shipping your
> machine!"
>
> ----
>
> Akira Fujita (1):
> Btrfs-progs: Fix manual of btrfs command
>
> Chris Samuel (1):
> Fix "set-dafault" typo in cmds-subvolume.c
>
> Csaba Tóth (1):
> mkfs.btrfs on ARM
>
> Goffredo Baroncelli (1):
> scrub_fs_info( ) file handle leaking
>
> Hubert Kario (2):
> Fix segmentation fault when opening invalid file system
> man: fix btrfs man page formatting
>
> Jan Kara (1):
> mkfs: Handle creation of filesystem larger than the first device
>
> Jim Meyering (5):
> btrfs_scan_one_dir: avoid use-after-free on error path
> mkfs: use strdup in place of strlen,malloc,strcpy sequence
> restore: don't corrupt stack for a zero-length command-line argument
> avoid several strncpy-induced buffer overruns
> mkfs: avoid heap-buffer-read-underrun for zero-length "size" arg
>
> Josef Bacik (3):
> Btrfs-progs: make btrfsck aware of free space inodes
> Btrfs-progs: make btrfs filesystem show <uuid> actually work
> btrfs-progs: enforce block count on all devices in mkfs
>
> Miao Xie (3):
> Btrfs-progs: fix btrfsck's snapshot wrong "unresolved refs"
> Btrfs-progs, btrfs-corrupt-block: fix the wrong usage
> Btrfs-progs, btrfs-map-logical: Fix typo in usage
>
> Phillip Susi (2):
> btrfs-progs: removed extraneous whitespace from mkfs man page
> btrfs-progs: document --rootdir mkfs switch
>
> Sergei Trofimovich (2):
> Makefile: use $(CC) as a compilers instead of $(CC)/gcc
> Makefile: use $(MAKE) instead of hardcoded 'make'
>
> Shawn Bohrer (1):
> btrfs-progs: Update resize documentation
>
> Wang Sheng-Hui (1):
> btrfs-progs: cleanup: remove the redundant BTRFS_CSUM_TYPE_CRC32 macro def
>
> --
> === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
> PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
> --- Great oxymorons of the world, no. 5: Manifesto Promise ---
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-26 8:58 ` Alex Lyakas
@ 2012-06-26 9:58 ` Hugo Mills
2012-06-26 18:43 ` Alex Lyakas
0 siblings, 1 reply; 14+ messages in thread
From: Hugo Mills @ 2012-06-26 9:58 UTC (permalink / raw)
To: Alex Lyakas; +Cc: Btrfs mailing list
[-- Attachment #1: Type: text/plain, Size: 4166 bytes --]
On Tue, Jun 26, 2012 at 11:58:41AM +0300, Alex Lyakas wrote:
> Hi Hugo,
> forgive me, but I am somewhat confused.
> What is the "main" repo of btrfs-progs, if there is such thing?
> I see patches coming in, but no updates to
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git,
> which I thought was the one.
>
> Can you pls clarify where should I pull updates from for btrfs-progs?
The official source for btrfs-progs is Chris's one, at the URL
above. The integration repo is kind of a staging area where I pull in
as many patches as I can and get them a bit more visibility. We don't
really have a well-defined workflow here.
It depends on what you intend doing: if you want to make packages
for your distribution, use Chris's repo. If you want something
reasonably stable and tested, use Chris's repo. If there's some
experimental kernel feature you want to test out, use integration. If
you want to be helpful and test out new patches and report problems
with them, use integration.
Hugo.
> Thanks,
> Alex.
>
>
>
> On Tue, Jun 5, 2012 at 10:09 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
> > I've just pushed out a new integration branch to my git repo. This
> > is purely bugfix patches -- there are no new features in this issue of
> > the integration branch. I've got a stack of about a dozen more patches
> > with new features in them still to go. I'll be working on those
> > tomorrow. As always, there's minimal testing involved here, but it
> > does at least compile on my system(*).
> >
> > The branch is fetchable with git from:
> >
> > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20120605
> >
> > And viewable in human-readable form at:
> >
> > http://git.darksatanic.net/cgi/gitweb.cgi?p=btrfs-progs-unstable.git
> >
> > Shortlog is below.
> >
> > Hugo.
> >
> > (*) "I don't care about works-on-my-machine. We are not shipping your
> > machine!"
> >
> > ----
> >
> > Akira Fujita (1):
> > Btrfs-progs: Fix manual of btrfs command
> >
> > Chris Samuel (1):
> > Fix "set-dafault" typo in cmds-subvolume.c
> >
> > Csaba Tóth (1):
> > mkfs.btrfs on ARM
> >
> > Goffredo Baroncelli (1):
> > scrub_fs_info( ) file handle leaking
> >
> > Hubert Kario (2):
> > Fix segmentation fault when opening invalid file system
> > man: fix btrfs man page formatting
> >
> > Jan Kara (1):
> > mkfs: Handle creation of filesystem larger than the first device
> >
> > Jim Meyering (5):
> > btrfs_scan_one_dir: avoid use-after-free on error path
> > mkfs: use strdup in place of strlen,malloc,strcpy sequence
> > restore: don't corrupt stack for a zero-length command-line argument
> > avoid several strncpy-induced buffer overruns
> > mkfs: avoid heap-buffer-read-underrun for zero-length "size" arg
> >
> > Josef Bacik (3):
> > Btrfs-progs: make btrfsck aware of free space inodes
> > Btrfs-progs: make btrfs filesystem show <uuid> actually work
> > btrfs-progs: enforce block count on all devices in mkfs
> >
> > Miao Xie (3):
> > Btrfs-progs: fix btrfsck's snapshot wrong "unresolved refs"
> > Btrfs-progs, btrfs-corrupt-block: fix the wrong usage
> > Btrfs-progs, btrfs-map-logical: Fix typo in usage
> >
> > Phillip Susi (2):
> > btrfs-progs: removed extraneous whitespace from mkfs man page
> > btrfs-progs: document --rootdir mkfs switch
> >
> > Sergei Trofimovich (2):
> > Makefile: use $(CC) as a compilers instead of $(CC)/gcc
> > Makefile: use $(MAKE) instead of hardcoded 'make'
> >
> > Shawn Bohrer (1):
> > btrfs-progs: Update resize documentation
> >
> > Wang Sheng-Hui (1):
> > btrfs-progs: cleanup: remove the redundant BTRFS_CSUM_TYPE_CRC32 macro def
> >
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- ... one ping(1) to rule them all, and in the ---
darkness bind(2) them.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: New btrfs-progs integration branch
2012-06-26 9:58 ` Hugo Mills
@ 2012-06-26 18:43 ` Alex Lyakas
0 siblings, 0 replies; 14+ messages in thread
From: Alex Lyakas @ 2012-06-26 18:43 UTC (permalink / raw)
To: Hugo Mills, Alex Lyakas, Btrfs mailing list
Thanks, Hugo.
At this point I mostly want to learn and stay up-to-date with new
patches coming in.
Alex.
On Tue, Jun 26, 2012 at 12:58 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
> On Tue, Jun 26, 2012 at 11:58:41AM +0300, Alex Lyakas wrote:
>> Hi Hugo,
>> forgive me, but I am somewhat confused.
>> What is the "main" repo of btrfs-progs, if there is such thing?
>> I see patches coming in, but no updates to
>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git,
>> which I thought was the one.
>>
>> Can you pls clarify where should I pull updates from for btrfs-progs?
>
> The official source for btrfs-progs is Chris's one, at the URL
> above. The integration repo is kind of a staging area where I pull in
> as many patches as I can and get them a bit more visibility. We don't
> really have a well-defined workflow here.
>
> It depends on what you intend doing: if you want to make packages
> for your distribution, use Chris's repo. If you want something
> reasonably stable and tested, use Chris's repo. If there's some
> experimental kernel feature you want to test out, use integration. If
> you want to be helpful and test out new patches and report problems
> with them, use integration.
>
> Hugo.
>
>> Thanks,
>> Alex.
>>
>>
>>
>> On Tue, Jun 5, 2012 at 10:09 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
>> > I've just pushed out a new integration branch to my git repo. This
>> > is purely bugfix patches -- there are no new features in this issue of
>> > the integration branch. I've got a stack of about a dozen more patches
>> > with new features in them still to go. I'll be working on those
>> > tomorrow. As always, there's minimal testing involved here, but it
>> > does at least compile on my system(*).
>> >
>> > The branch is fetchable with git from:
>> >
>> > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20120605
>> >
>> > And viewable in human-readable form at:
>> >
>> > http://git.darksatanic.net/cgi/gitweb.cgi?p=btrfs-progs-unstable.git
>> >
>> > Shortlog is below.
>> >
>> > Hugo.
>> >
>> > (*) "I don't care about works-on-my-machine. We are not shipping your
>> > machine!"
>> >
>> > ----
>> >
>> > Akira Fujita (1):
>> > Btrfs-progs: Fix manual of btrfs command
>> >
>> > Chris Samuel (1):
>> > Fix "set-dafault" typo in cmds-subvolume.c
>> >
>> > Csaba Tóth (1):
>> > mkfs.btrfs on ARM
>> >
>> > Goffredo Baroncelli (1):
>> > scrub_fs_info( ) file handle leaking
>> >
>> > Hubert Kario (2):
>> > Fix segmentation fault when opening invalid file system
>> > man: fix btrfs man page formatting
>> >
>> > Jan Kara (1):
>> > mkfs: Handle creation of filesystem larger than the first device
>> >
>> > Jim Meyering (5):
>> > btrfs_scan_one_dir: avoid use-after-free on error path
>> > mkfs: use strdup in place of strlen,malloc,strcpy sequence
>> > restore: don't corrupt stack for a zero-length command-line argument
>> > avoid several strncpy-induced buffer overruns
>> > mkfs: avoid heap-buffer-read-underrun for zero-length "size" arg
>> >
>> > Josef Bacik (3):
>> > Btrfs-progs: make btrfsck aware of free space inodes
>> > Btrfs-progs: make btrfs filesystem show <uuid> actually work
>> > btrfs-progs: enforce block count on all devices in mkfs
>> >
>> > Miao Xie (3):
>> > Btrfs-progs: fix btrfsck's snapshot wrong "unresolved refs"
>> > Btrfs-progs, btrfs-corrupt-block: fix the wrong usage
>> > Btrfs-progs, btrfs-map-logical: Fix typo in usage
>> >
>> > Phillip Susi (2):
>> > btrfs-progs: removed extraneous whitespace from mkfs man page
>> > btrfs-progs: document --rootdir mkfs switch
>> >
>> > Sergei Trofimovich (2):
>> > Makefile: use $(CC) as a compilers instead of $(CC)/gcc
>> > Makefile: use $(MAKE) instead of hardcoded 'make'
>> >
>> > Shawn Bohrer (1):
>> > btrfs-progs: Update resize documentation
>> >
>> > Wang Sheng-Hui (1):
>> > btrfs-progs: cleanup: remove the redundant BTRFS_CSUM_TYPE_CRC32 macro def
>> >
>
> --
> === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
> PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
> --- ... one ping(1) to rule them all, and in the ---
> darkness bind(2) them.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-06-26 18:43 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-05 19:09 New btrfs-progs integration branch Hugo Mills
2012-06-06 11:48 ` Helmut Hullen
2012-06-06 13:14 ` Hugo Mills
2012-06-06 15:03 ` Helmut Hullen
2012-06-06 15:40 ` Hugo Mills
2012-06-06 15:52 ` Helmut Hullen
2012-06-06 16:04 ` Hugo Mills
2012-06-06 16:18 ` Helmut Hullen
2012-06-06 16:26 ` Hugo Mills
2012-06-06 19:13 ` Helmut Hullen
2012-06-07 1:08 ` Jérôme Poulin
2012-06-26 8:58 ` Alex Lyakas
2012-06-26 9:58 ` Hugo Mills
2012-06-26 18:43 ` Alex Lyakas
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.