Package: wnpp
Followup-For: Bug #892412
Owner: Ritesh Raj Sarraf
As part of my work, I have dependence on rabbitvcs.
Hence, I intend to adopt and maintain the rabbitvcs package
Thanks,
Ritesh
Package: wnpp
Followup-For: Bug #572853
Owner: Ritesh Raj Sarraf
I intend to take up maintenance for this package.
My work currently depend on this and rabbitvcs package, which provides a
rabbitvcs-thunar plugin.
Since this bug has not had any activity for a long time, I am marking
myself as th
Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar
* Package name: screenruler
Version : screenruler-0.960+bzr41+deb10
Upstream Author : Siegfried-A. Gevatter
* URL : http://gnomecoder.wordpress.com/screenruler/
* License : GPL-2
Programming Lang: Rub
Hi Ian,
On Mon, Jul 01, 2019 at 12:49:05PM +0100, Ian Jackson wrote:
> Andreas Tille writes ("Re: Survey results: git packaging practices /
> repository format"):
> > I admit I did not joined the dgit discussion - may be that's the reason
> > I can not really match the branches that are used in P
Hi
I need some help regarding a security issue that surfaced yesterday that
affects buster.
Using the Calamares installer and full-disk encryption, sensitive
information is stored in the initramfs, which is world readable:
https://github.com/calamares/calamares/issues/1191
I just took a quick g
Hi Simon,
On Mon, Jul 01, 2019 at 11:09:27AM +0100, Simon McVittie wrote:
> On Mon, 01 Jul 2019 at 07:30:39 +0200, Andreas Tille wrote:
> > I admit I did not joined the dgit discussion - may be that's the reason
> > I can not really match the branches that are used in Perl team policy
> >
> >
Hi Ian,
On Mon, Jul 01, 2019 at 12:53:06PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Survey results: git packaging practices / repository
> format"):
> > What it doesn't say is how changes to the upstream files are
> > represented. Can you explain ?
>
> Also: I had hoped that the tab
On Wed, Jul 3, 2019 at 6:07 PM Jonathan Carter wrote:
>
> Hi
>
> I need some help regarding a security issue that surfaced yesterday that
> affects buster.
>
> Using the Calamares installer and full-disk encryption, sensitive
> information is stored in the initramfs, which is world readable:
>
> h
Andreas Tille writes ("Re: Survey results: git packaging practices / repository
format"):
> On Mon, Jul 01, 2019 at 11:09:27AM +0100, Simon McVittie wrote:
> > From https://perl-team.pages.debian.net/git.html#Patches it appears
> > the Perl team is using what the survey page has labelled as "unapp
Hi Roger
On 2019/07/03 12:10, Roger Shimizu wrote:
> According to latest LUKS for rootfs guide [1], you can append
> "UMASK=0077" to /etc/initramfs-tools/initramfs.conf
>
> [1] https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html
Ah great, having a "/etc/initramfs-tools/conf.d
Sorry about this, but I really wanted to reply to this because I think
it is a common misconception. I hope people who are tired of this
subject can tell their program to delete messages with `dgit advocacy'
in the subject...
Andreas Tille writes ("Re: Survey results: git packaging practices / re
Hi Jonathan,
On Wed, 03 Jul 2019 at 11:07:11 +0200, Jonathan Carter wrote:
> weasel has also pointed out to me that the open permissions may also be
> a problem for dropbear users who's initramfs host private key can easily
> be spoofed by anyone who can read the initramfs, so I do believe that
>
On Wed, Jul 03, 2019 at 11:30:46AM +0100, Ian Jackson wrote:
> > I admit under the circumstances you describe DEP-14 has advantages over
> > default gbp. I'm not sure how productive it would be for teams with
> > about 1000 packages to change the repository layout (posssibly its
> > scriptable) ju
Hi Ian,
On Wed, Jul 03, 2019 at 11:41:34AM +0100, Ian Jackson wrote:
> Sorry about this, but I really wanted to reply to this because I think
> it is a common misconception. I hope people who are tired of this
> subject can tell their program to delete messages with `dgit advocacy'
> in the subje
Andreas Tille writes ("Re: dgit advocacy again (Re: Survey results: git
packaging practices / repository format)"):
> On Wed, Jul 03, 2019 at 11:41:34AM +0100, Ian Jackson wrote:
> > People like you are precisely the intended users of "dgit push --gbp".
> >
> > I think if you used it you would he
As a matter of policy Debian tends to install things like binaries as
world readable. In general I don't think we should be copying sensitive
information to the initramfs without careful consideration. The
rationale is that on systems with full disk encryption the initramfs
probably isn't encrypt
On Wed, Jul 03, 2019 at 08:59:26AM -0400, Sam Hartman wrote:
> The rationale is that on systems with full disk encryption the initramfs
> probably isn't encrypted
>
> I personally think sticking your full disk encryption keys onto the
> initramfs doesn't have a lot of value.
These two things are
Hi Ian,
On Wed, Jul 03, 2019 at 01:49:13PM +0100, Ian Jackson wrote:
> ...
> dgit push-source is slightly more convenient than the dput based
> system and it catches slightly more errors and does slightly more
> automatically. But, it is a fairly minor benefit *to the maintainer*.
>
> As I say,
Andreas Tille writes ("Re: dgit advocacy again (Re: Survey results: git
packaging practices / repository format)"):
> On Wed, Jul 03, 2019 at 01:49:13PM +0100, Ian Jackson wrote:
> > Anyway, I'm very happy to talk to you (or anyone) about your own
> > situation in detail IRL, and also open to hear
On Jul 03 2019, Andreas Tille wrote:
>> > That's the case for me. I need to admit that I did not used dgit. The
>> > reason is that I'm working in teams who all have Git repositories on
>> > Salsa that more or less are following what was described in the Perl
>> > team policy. I live under the
On Wed, Jul 03, 2019 at 01:49:13PM +0100, Ian Jackson wrote:
> The main difficulty now with getting dgit push adopted is that
> maintainers don't see the benefit *to themselves* and it is always
> harder to get someone to see a benefit *to someone else*.
Ok, that describe me. I see benefits in an
Jonathan Carter wrote:
> Ah great, having a "/etc/initramfs-tools/conf.d/initramfs-permissions"
> that contains "UMASK=0077" and running "update-initramfs -u" does fix
> that for me locally, I think it should be reasonable to add that to the
> calamares-settings package for Debian.
>
> Does anyone
Hello,
On Wed 03 Jul 2019 at 05:58pm +0100, Nikolaus Rath wrote:
> At least for me, I was able to simply run 'dgit --gbp build-source &&
> dgit --gpm push' instead of 'sbuild && dput '. Mission
> accomplished.
Or `dgit --gbp push-source`! (just wanted to note this in case you
hadn't come acros
Ian Jackson writes:
> Please let us know if we have missed one. It is probably better if
> you ask us rather than just adding it, unless you're sure that what
> you are adding isn't the same as one of the existing ones. In
> particular it seems that "unapplied" is used by a large number of
> pe
Ben Finney writes:
> I don't recognise the repository structure that was raised by myself and
> some others: A VCS repository that contains only the Debian packaging
> files, which at build time is then exported to a non-VCS working tree
> and moerged with the upstream source.
> It may be “bare
Ian Jackson writes:
> I have said before that I think using "dgit push" (where possible) is
> an ethical imperative. (I should clarify that I *don't* mean that
> people who aren't using "dgit push" yet are bad people. Life is so
> full of ethical imperatives that no real human could meet them a
On Thu, Jul 4, 2019 at 11:37 AM Russ Allbery wrote:
> Ben Finney writes:
>
> > I don't recognise the repository structure that was raised by myself and
> > some others: A VCS repository that contains only the Debian packaging
> > files, which at build time is then exported to a non-VCS working tree
Paul Wise writes:
> On Thu, Jul 4, 2019 at 11:37 AM Russ Allbery wrote:
>> Ben Finney writes:
>>> I don't recognise the repository structure that was raised by myself
>>> and some others: A VCS repository that contains only the Debian
>>> packaging files, which at build time is then exported to a
28 matches
Mail list logo
