Hi Gianfranco,
Here is a link to the latest version, which uses triggers instead of
postinst and postrm. I think it's ready to upload, but please double
check :-)
http://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.4.1-1.1.dsc
Cheers,
Nicholas
Hi Dimitri,
On 22 April 2016 at 19:20, Dimitri John Ledkov wrote:
> I haven't looked closely, but i have a lot dubious emails about btrfs package.
> (a) i do not maintain backports, anybody is free to do those
> (b) all of my packages are lowNMU, meaning I trust any/all DDs to do
> sensible thing
On 23 April 2016 at 00:06, Nicholas D Steeves wrote:
> On 21 April 2016 at 08:33, Christian Seiler wrote:
>> Hi Gianfranco,
>>
>> On 04/21/2016 09:48 AM, Gianfranco Costamagna wrote:
activate update-initramfs
>>> do you think it is worth adding to the current NMU or it is better to leave
>>
On 21 April 2016 at 03:53, Jakub Wilk wrote:
> Policy ยง10.4 says that /bin/sh script need to follow SUSv3 + some
> extensions. Both "hash" and "command -v" are optional in SUSv3 (but they are
> mandatory in SUSv4), so in theory you shouldn't use them. In practice,
> however, "command -v" is probab
On 21 April 2016 at 08:33, Christian Seiler wrote:
> Hi Gianfranco,
>
> On 04/21/2016 09:48 AM, Gianfranco Costamagna wrote:
>>> activate update-initramfs
>> do you think it is worth adding to the current NMU or it is better to leave
>> it for
>> a future upload?
>
> I'm not sure if you meant to
Hi Gianfranco,
On 04/21/2016 09:48 AM, Gianfranco Costamagna wrote:
>> activate update-initramfs
> do you think it is worth adding to the current NMU or it is better to leave
> it for
> a future upload?
I'm not sure if you meant to ask me, but just in case: I would suggest
you do so, but it's no
* Nicholas D Steeves , 2016-04-20, 19:41:
"if [ -x /usr/sbin/update-initramfs ] && [ -e /etc/initramfs-tools/initramfs.conf
]"
I don't think there's anything particularly wrong with that line.
The previous attempts at fixing this (using 'hash' and 'command -v')
are both bashisms so they shou
Hi Nicholas,
>Yes, I read this for my initial upload. When Gianfranco's requested
>fixing piupart's warning I inferred that the manual was out of date
>relative to the current/sid standard that piupart was checking for.
oops, I think there has been a misunderstanding here.
IIRC I asked to *
Hi Christian,
>activate update-initramfs
do you think it is worth adding to the current NMU or it is better to leave it
for
a future upload?
the change looks good, I think it has no side effects, but I would like to hear
another opinion :)
G.
On 04/21/2016 01:41 AM, Nicholas D Steeves wrote:
> On 20 April 2016 at 18:33, James Cowgill wrote:
>>> "if [ -x /usr/sbin/update-initramfs ] && [ -e
>>> /etc/initramfs-tools/initramfs.conf ]"
>>
>> I don't think there's anything particularly wrong with that line.
>>
>> The previous attempts at f
On 20 April 2016 at 18:33, James Cowgill wrote:
>> "if [ -x /usr/sbin/update-initramfs ] && [ -e
>> /etc/initramfs-tools/initramfs.conf ]"
>
> I don't think there's anything particularly wrong with that line.
>
> The previous attempts at fixing this (using 'hash' and 'command -v')
> are both bash
On Wed, 2016-04-20 at 21:24 +, Gianfranco Costamagna wrote:
> Hi,
> you missed the change on postrm, and BTW I think this is out of the
> NMU scope, can we please leave the change
> out?
> I'm not too confident about it, I would like to just rename the
> package and let xnox give his opinion on
Hi,
you missed the change on postrm, and BTW I think this is out of the NMU scope,
can we please leave the change
out?
I'm not too confident about it, I would like to just rename the package and let
xnox give his opinion on
the postinst and postrm scripts.
maybe somebody on -mentors can give an
On 15 April 2016 at 09:25, Gianfranco Costamagna
wrote:
> also some issues might be fixed in a later release
>
> http://debomatic-amd64.debian.net/distribution#unstable/btrfs-progs/4.4.1-1.1/lintian
>
> I: btrfs-progs source: duplicate-short-description btrfs-tools btrfs-tools-dbg
> I: btrfs-progs
also some issues might be fixed in a later release
http://debomatic-amd64.debian.net/distribution#unstable/btrfs-progs/4.4.1-1.1/lintian
I: btrfs-progs source: duplicate-short-description btrfs-tools btrfs-tools-dbg
I: btrfs-progs source: duplicate-long-description btrfs-tools btrfs-tools-dbg
W:
On 8 April 2016 at 17:43, Gianfranco Costamagna
wrote:
>>Given that both of these will be broken if this package isn't
>>uploaded, is now the time to upload it?
>
> I didn't understand this sentence.
It turns out debian-cd can list both btrfs-tools and btrfs-progs to
handle the transition, howeve
Hi,
>I've filed a bug and submitted a patch for debian-cd and have>contacted the
>maintainers of partman-btrfs links to the updated
>package on mentors and to a github repo, because jcristau on
>#debian-installer said he preferred pulling from a git repo. How long
>should I wait before filing a
Moreinfo removed, because Sledge on #debian-installer directed me to
what I needed to patch in debian-cd.
-- Nicholas
I've filed a bug and submitted a patch for debian-cd and have
contacted the maintainers of partman-btrfs links to the updated
package on mentors and to a github repo, because jcristau on
#debian-installer said he preferred pulling from a git repo. How long
should I wait before filing an RFS bug ag
On 5 April 2016 at 13:52, Gianfranco Costamagna
wrote:
> so, please remove the moreinfo tag once you have a feedback from -boot team.
Will do. 'hope they rsvp soon!
> also a reverse-dependency needs fixing here
> https://codesearch.debian.net/results/btrfs-tools-udeb/page_0
> partman-btrfs
Fix
control: tags -1 moreinfo
Hi, I like changes now, and also lintian/piuparts seems happy
http://debomatic-amd64.debian.net/distribution#experimental/btrfs-progs/4.4.1-1.1/buildlog
so, please remove the moreinfo tag once you have a feedback from -boot team
Fixed @ same URL. Lots of beginner mistakes, plus carelessness wrt to
Standards Version :-$ Whoops! Thank you for your patience.
On 5 April 2016 at 13:07, Gianfranco Costamagna
> BTW I'm not sure about the udeb package rename, there is no upgrade path
> there, maybe you can get in touch with
>
something more:
+Replaces: btrfs-tools-dbg (<< 4.4.1-1)
+Breaks: btrfs-tools (<< 4.4.1-1)
you missed a -dbg here
+Package: btrfs-tools-dbg
+Section: debug
+Priority: extra
+Architecture: linux-any
+Depends: btrfs-progs-dbg, btrfs-progs (= ${binary:Version}), ${misc:Depends}
+Description: trans
Hi
>I've addressed what you asked for, except for "[dropping] the dbg
>package, they are autobuilt now (you need to use the ddbg migration I
>think)", because I'm not sure if how that will affect a backport to
>Jessie. Jessie+backported LTS kernel+matching btrfs-progs is my
>primary target and w
On 4 April 2016 at 09:20, Gianfranco Costamagna
wrote:
> I did a preliminary review on pkg-multimedia mail list [1] (where Nicholas
> applied for the team join)
>
>
> please address the issues I raised, and remove the moreinfo tag once done,
> and I'll do another spin.
>
>
> [1]
> https://lists
control: owner -1 !
control: tags -1 moreinfo
Hi Dimitri, I see you already acked the change on 780081, so I would like to
sponsor this package (if I remember correctly you like also cosmetical changes
on NMUs, so I'll
ask to bump std-version and something more).
I did a preliminary review on
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for an upload of "btrfs-progs" to experimental. In
Bug#780081 the
package maintainer had planned to do this, and I posted a link to this package
to that bug
report over two weeks ago. Given how difficult
27 matches
Mail list logo