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 ---
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-20120605There 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. ---
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 ----- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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.-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html