On Wed, 2024-01-31 at 10:49 -0500, Scott Talbert wrote:
>
> Note: I don't discourage usage of debbugs. It's just that I'm unlikely to
> notice bugs immediately due to the way debbugs notifications work.
You should be able to use tracker.debian.org to subscribe to teams or
individual packages wh
On Sun, 2023-08-13 at 22:59 +0200, Timo Röhling wrote:
> There's talk on #d-python if pybuild could/should deal with it; I'd
> give it a few days and see if that pans out.
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/46
seems to be the one to watch.
Ian.
On Sat, 2021-02-27 at 17:30 -0500, Sergio Durigan Junior wrote:
> I don't know if I understand the pushback I'm seeing
> against using a debconf question for this.
FWIW I don't think I've read any actual pushback on that in this thread
although I can see how it might appear that way to another rea
On Sat, 2021-02-27 at 11:21 -0500, Sergio Durigan Junior wrote:
> On Saturday, February 27 2021, Ian Campbell wrote:
> >
> > FWIW that would be my personal preference too (probably with some sort
> > of cache, maybe once per library or executable or some granularity like
On Sat, 2021-02-27 at 11:47 +0100, Kurt Roeckx wrote:
On Thu, Feb 25, 2021 at 03:55:17PM -0500, Sergio Durigan Junior wrote:
> As I said in the announcement message, I have proposed a Merge
> Request
> against elfutils in order to enable the automatic usage of our
> debuginfod server. I know that
Thank you both for your replies.
Frank Ch. Eigler wrote:
> Do these considerations overcome the concerns, so as to provide a
> comfortable out-of-the-box experience for most users?
I'm not totally convinced about silently enabling it by default, but...
On Thu, 2021-02-25 at 15:55 -0500, Sergio D
Frank's original reply didn't make it to the list for some reason and
has also gone missing on his end so resending on his request.
On Wed, 2021-02-24 at 15:23 -0500, Frank Ch. Eigler wrote:
---
Hi, Ian -
ijc wrote:
> [...]
> What are the security implications for users/clients of using this
On Wed, 2021-02-24 at 16:58 +, Ian Campbell wrote:
Ugh, sorry, the quoting seems to have gone quite wrong there, let me
try again...
> On Tue, 2021-02-23 at 22:53 -0500, Sergio Durigan Junior wrote:
> Hello there,
>
> I would like to announce a new service that I have just conf
On Tue, 2021-02-23 at 22:53 -0500, Sergio Durigan Junior wrote:
Hello there,
I would like to announce a new service that I have just configured for
Debian: https://debuginfod.debian.net.
debuginfod is a new-ish project whose purpose is to serve
ELF/DWARF/source-code information over HTTP. It is
Package: wnpp
Severity: wishlist
Owner: Ian Campbell
* Package name: cmake-format
Version : 0.6.10
Upstream Author : Josh Bialkowski
* URL : https://github.com/cheshirekow/cmake_format
* License : GPL-3
Programming Lang: Python
Description : source
On Sat, 2020-02-22 at 22:40 +0100, Mattia Rizzolo wrote:
> Honestly though, I don't think going and clicking "subscribe" in a "few
> dozens" package pages is too much.
It looks like we have a pts-subscribe command in devscripts these days,
so it can also be scripted. (I've never used it, just spot
On Thu, 2019-05-09 at 12:51 +, Holger Levsen wrote:
> On Thu, May 09, 2019 at 01:46:19PM +0100, Ian Jackson wrote:
> > debcheckout *certainly* doesn't do this. It just gives you the
> > current master which may not have been uploaded anywhere.
>
> nope:
>
> $ debcheckout munin
> declared git
On Thu, 2019-05-09 at 11:19 +1000, Ben Finney wrote:
> What I remain unconvinced of is the worth of abandoning the clean
> separation between an upstream source repository (whether Git repository
> or not) and a VCS repository for Debian packaging (typically in Git).
I think there's a common misco
On Tue, 2019-05-07 at 11:01 -0400, Sam Hartman wrote:
> That said, I think Ansgar has some really valid points. I think that
> dgit (or git-dpm) are the hardest work flows to teach.
I think perhaps you meant `git-debrebase` rather than `dgit` throughout
the remainder of your mail, since comparing
On Tue, 2019-04-30 at 12:05 +0100, Ian Jackson wrote:
> Sean Whitton writes ("Re: Preferred git branch structure when upstream moves
> from tarballs to git"):
> > On Mon 29 Apr 2019 at 02:12PM +01, Ian Campbell wrote:
> > >
> > > I think (but don'
On Mon, 2019-04-29 at 13:50 -0700, Sean Whitton wrote:
>
> dgit-maint-merge -> dgit-maint-debrebase would indeed be the
> convert-from-dgit-view subcommand. If I were dealing with this, for
> simplicity, I would start from the point of just having made an upload.
> That way you know your HEAD is
On Mon, 2019-04-29 at 13:25 +0100, Ian Jackson wrote:
> Look at the intro to each of these and see which one you think might
> be best:
> https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html
>
> https://manpages.debian.org/stretch-backports/dgit/dgit-maint-debrebase.7.en
On Tue, 2019-03-12 at 08:10 +, Ian Campbell wrote:
> > I have no idea where the line terminators difference in one single
> > branch in one single file that is never used in Debian builds comes
> > from. I don't think it's the pristine-tar data, when I remove the
&
> I have no idea where the line terminators difference in one single
> branch in one single file that is never used in Debian builds comes
> from. I don't think it's the pristine-tar data, when I remove the
> generated orig.tar.xz and have it regenerated with --git-no-pristine-tar
> it has a differ
On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> The hardware that supports GLES also supports OpenGL because GLES is
> a subset of OpenGL.
I'm confused by this inference. If GLES is a subset of OpenGL then
surely hardware which claims to implement GLES is at liberty to only
implement that
On Sat, 2018-11-10 at 11:25 +0100, Jonas Smedegaard wrote:
> Quoting Mattia Rizzolo (2018-11-09 21:29:30)
> [a range of fine details snipped]
> > Good bye, and thank you for your contributions you made back then!
>
> Thank you, Mattia. I found above to be a decent and polite post when I
> read i
On Tue, 2018-10-16 at 09:48 +0100, Jonathan Dowland wrote:
> On Tue, Oct 16, 2018 at 08:59:16AM +0200, Narcis Garcia wrote:
> > I'm using this express-made address because personal addresses
> > aren't
> > masked enough at this mail public archive. Public archive
> > administrator
> > should fix th
On Mon, 2018-10-15 at 22:31 -0700, Alessio Treglia wrote:
> On Mon, Oct 15, 2018 at 9:51 PM Enzo Nicosia
> wrote:
> > Please, just tell us who we should contact (current/last
> > maintainer?) to start working on that.
>
> That's easy [1].
It is, but the link you gave is a rather cryptic way of p
On Mon, 2018-09-03 at 10:17 +0200, Jakub Wilk wrote:
> http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap01.html#tag_23_01_07
TIL: there is a (slightly, but not insanely so) roundabout rationale
for having a non-builtin `cd`... thanks!
Ian.
On Thu, 2018-07-12 at 19:03 +0500, Andrey Rahmatullin wrote:
> On Thu, Jul 12, 2018 at 02:16:01PM +0100, Ian Campbell wrote:
> > > > (3) CUDA Deep Neural Network library (cuDNN)[4] is NVIDIA's
> > > > **PROPRIETARY**,
> > > > stacked
On Thu, 2018-07-12 at 13:09 +, Holger Levsen wrote:
> On Thu, Jul 12, 2018 at 12:35:24PM +, Lumin wrote:
> > (3) CUDA Deep Neural Network library (cuDNN)[4] is NVIDIA's
> > **PROPRIETARY**,
> > stacked on CUDA, and requires NVIDIA GPU exclusively.
>
> so what? Debian runs on non-free
On Fri, 2018-06-01 at 11:31 -0400, Alexandre Viau wrote:
> On 2018-05-31 12:33 PM, Chris Lamb wrote:
> > [11] https://wiki.debian.org/MemberBenefits
>
> Oh, this reminds me of something.
>
> Has anyone gotten replies to their requests sent to
> debian-st...@collabora.com for the Steam subscripti
On Tue, 2018-05-29 at 15:00 +0200, Vincent Lefevre wrote:
> On 2018-05-22 15:19:50 +0500, Andrey Rahmatullin wrote:
> > On Tue, May 22, 2018 at 11:43:31AM +0200, Heinz Repp wrote:
> > > Just stumbled over some removals:
> > >
> > > GnuCash removed from testing in August 2017
> > > FreeCad removed
On Mon, 2018-04-16 at 09:00 -0700, Russ Allbery wrote:
> Fixing the package when it was removed from testing with RC bugs seems
> entirely reasonable. What bothers me is just adding onself as
> comaintainer without any discussion, and thus making that upload not an
> NMU.
>
> By all means NMU to
On Wed, 2018-04-11 at 07:08 +, Lumin wrote:
> [2] https://ftp-master.debian.org/stat/new-5years.png
Does this graph show the length of the NEW queue over time or the
numbers of packages passing through NEW over time?
Ian.
On Thu, 2018-03-29 at 14:02 +0100, Ian Jackson wrote:
> Don Armstrong writes ("Re: interpretation of wontfix"):
> > 2) wontfix+help: this bug requires too much effort to fix, so I won't be
> >working on it, but patches will be accepted.
>
> I dislike the use of "help" in this context. If the
On Wed, 2018-03-07 at 08:05 -0600, Steve Robbins wrote:
> I think the suggestion of randomized spot checking is meant to
> replace - not add - to the present system of checking that penalizes
> uploads of existing source but new binaries. So human resources
> should not be the issue.
Yes, that's
On Tue, 2018-03-06 at 19:18 +0100, Mattia Rizzolo wrote:
> On Tue, Mar 06, 2018 at 06:34:28PM +0100, Adam Borowski wrote:
> > What might be reasonable is making the separation between binNEW and srcNEW
> > more obvious, especially for us on the other side. This would also
> > encourage the ftpmast
On Fri, 2018-03-02 at 08:29 +0100, Ralf Treinen wrote:
> On Fri, Mar 02, 2018 at 04:15:18AM +0300, kact...@gnu.org wrote:
>
> > Is it true? When invoked as /bin/sh, GNU Bash works in Posix-emulation
> > mode, and it is not that bad:
>
> Indeed, Bash manual section 6.11. Thanks for pointing this o
On Thu, 2018-03-01 at 13:40 +0800, Paul Wise wrote:
> On Wed, Feb 28, 2018 at 11:23 PM, Alberto Luaces wrote:
>
> > Great! After passing those keys trough `ssh-keygen -lf`, I get the
> > confirmation I was looking for.
>
> Why do you need ssh-keygen when you can just add the ssh key to your
> kn
On Wed, 2018-02-14 at 12:53 +0100, Wouter Verhelst wrote:
> But nobody
> should be afraid of using an epoch when the upstream version number
> changes incompatibly, because *that's what they're for*.
Much of the discussion in this thread (and the recommendations not to
use them) seem to be for cas
On Thu, 2018-02-08 at 11:50 +0100, Raphael Hertzog wrote:
> On Thu, 08 Feb 2018, Ian Campbell wrote:
> > Is it also the case that today we implicitly require that all
> versions
> > used in a source package name's history are unique even once the
> epochs
> >
On Wed, 2018-02-07 at 13:51 +, Ian Jackson wrote:
> I suggest something like this wording to replace the following
> paragraphs about the epoch:
>
>Epochs exist to cope with changes to the upstream version numbering
>scheme, and some other difficult cases. The epoch is a powerful
>
On Tue, 2018-01-23 at 18:20 +0530, Kumar Appaiah wrote:
> On Tue, Jan 23, 2018 at 10:27:06AM -0200, Antonio Terceiro wrote:
> > On Mon, Jan 22, 2018 at 07:38:41PM +0530, Kumar Appaiah wrote:
> > > Dear Debian Developers,
> > >
> > > I am part of a team working on getting Debian on low cost laptops
On Tue, 2018-01-23 at 17:53 +0530, Kumar Appaiah wrote:
> > You should definitately give the package a distinct version and you
> > should _probably_ give it either a distinct ABI or flavour (or possibly
> > both). You will probably also want to put a digit in your distinct ABI
> > so you can rev i
On Mon, 2018-01-22 at 19:38 +0530, Kumar Appaiah wrote:
> 1. The laptop will ship with stretch preinstalled, but with a custom
> kernel built using the linux-source-x.xx.xx package with a custom
> version number, such as linux-image-4.14.13-iitb-amd64.
A silly nitpick but the "4.14.13-iitb-amd64"
On Wed, 2018-01-17 at 20:31 +1300, Matt Grant wrote:
> My guess as a developer this is a release critical show stopper
> bug.
Please see
https://kernel-handbook.alioth.debian.org/ch-bugs.html#s9.2
and
https://wiki.debian.org/DebianKernelReportingBugs
for guidance on reporting a bug against the
On Tue, 2018-01-09 at 05:03 +, Wookey wrote:
> And the reason why you'd use it for something like this is that it
> lets you upstream patches (which change dependencies) in a reasonably
> clean way.
And is the reason this is preferable to `dpkg-vendor` based stuff
because `dpkg-vendor` cannot
On Mon, 2018-01-08 at 08:46 -0800, Don Armstrong wrote:
> All of that said, if you are interested in Debian supporting a nosystemd
> build profile, continuing to escalate conflicts with other developers is
> not helping your cause.
It would be more helpful if people on _both_ sides would stop
need
On Sat, 2017-12-02 at 06:06 +0200, Victor Porton wrote:
> For this I need the upstream versions of "python2.7" and "xsltproc".
The upstream version of a Debian package can be deterministically
extracted from the package version, see https://www.debian.org/doc/debi
an-policy/#s-f-version for the fo
On Mon, 2017-10-02 at 06:57 -0400, Michael Stone wrote:
> On Mon, Oct 02, 2017 at 11:50:37AM +0100, Ian Campbell wrote:
> > On Mon, 2017-10-02 at 06:27 -0400, Michael Stone wrote:
> > > On Mon, Oct 02, 2017 at 11:03:18AM +0200, Helmut Grohne wrote:
> > > > This is
On Mon, 2017-10-02 at 06:27 -0400, Michael Stone wrote:
> On Mon, Oct 02, 2017 at 11:03:18AM +0200, Helmut Grohne wrote:
> > This is a fair point, but I think the perfect is the enemy of the good.
> >
> > I agree that moving badblocks, lsattr and chattr to another package or
> > inside src:util-li
On Sun, 2017-09-17 at 12:59 -0700, Vagrant Cascadian wrote:
> On 2017-09-15, Ben Hutchings wrote:
> > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
> > [...]
> >> There is optional kernel support to trap the exceptions here
> >> and emulate the instructions, but it's really not recommend
On Fri, 2017-09-01 at 12:43 +0200, Helmut Grohne wrote:
> Whatever point you were trying to make around NEW, your argument is not
> very convincing. I think Holger is right here: Where the package is
> built should not matter. Presence of .buildinfo and reproducibility
> does.
Appollogies if this
On Sun, 2017-08-06 at 17:27 +0200, Adam Borowski wrote:
> On Sun, Aug 06, 2017 at 09:16:48AM +0100, Ian Campbell wrote:
> > What is the expected interaction with the hwcaps based library
> > installed paths? (/usr/lib/i386-linux-gnu/i686/{sse2,cmov}).
> > Presumably
> &g
On Sun, 2017-08-06 at 01:13 +0200, Adam Borowski wrote:
>
> As for a foreign machine:
> * ISA_IGNORE=y apt install »package«
How about:
ASSUME_ISAS=sse2 apt install »package«
i.e. with the ability to specify the set you expect/know that the
target machine will have. It could support "all" as
On Sat, 2017-07-15 at 10:46 +0200, Marc Haber wrote:
> On Thu, 13 Jul 2017 09:36:58 -0700, Josh Triplett
> wrote:
> >But if you run into a command that accepts filenames but for which
> >bash-completion doesn't complete filenames, *please* report it as a
> bug
> >on the package providing the bash
On Mon, 2017-01-30 at 09:53 -0700, Sean Whitton wrote:
> Dear Lars,
>
> On Mon, Jan 30, 2017 at 05:18:38PM +0200, Lars Wirzenius wrote:
> > I personally don't find "open core" projects to be fully free
> > software, even if they follow current DFSG, OSI, and FSF criteria. I
> > may be in a minorit
On Thu, 2016-12-08 at 21:39 -0800, Josh Triplett wrote:
> I've now written and submitted all of these patches.
Might it be useful to have this list of names and descriptions in some
canonical packaged location, such that updating these tools is just a
version bump on a build dep, or even a runtime
On Wed, 2016-11-30 at 12:16 +, Ian Campbell wrote:
> I think it would be really cool if etckeeper could create and maintain
> a dpkg-dist branch with all the pristine stuff in it, no idea what
> hooks or integration would be needed for that though!
Oh, looks like I'm no
On Wed, 2016-11-30 at 12:54 +0100, Ansgar Burchardt wrote:
> Hi Svante,
>
> On Tue, 2016-11-29 at 17:58 +0100, Svante Signell wrote:
> >
> > After upgrading to sid the conffiles don't seem to be installed any
> > longer?
>
> I think it would be nice to make restoring the original configuration
>
On Tue, 2016-11-01 at 22:54 +0200, Adrian Bunk wrote:
> I do not see any reason for waiting instead of sending the binNMU
> request right now.
I didn't see any movement on the dpkg front so I went ahead and did so:
#843139.
Thanks,
Ian.
On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote:
> 2016-10-31 10:38 GMT+01:00 Ian Campbell :
> > If possible I'd also prefer a solution which fixed qcontrol-static
> > without opting out for the normal dynamic/non-udeb binary.
>
> I ran the build tests on amd
On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
> export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
> ?
Thanks, but that doesn't appear to help, I think the issue is to do
with the changed default in gcc rather than the hardening settings
injected into the build by dpkg-buildpackage/dpkg-b
Hi,
I maintain qcontrol[0] which builds on armel and armhf only (it's a
tool specific to certain NAS machines). It links a version against
liblua statically for use in a udeb (the resulting binary is dynamic,
it is only liblua5.1 which is linked statically).
It seems that on armhf my latest uploa
On Fri, 2016-10-21 at 14:44 +0800, Paul Wise wrote:
> On Fri, Oct 21, 2016 at 2:35 PM, Ian Campbell wrote:
>
> > I think there are also physical arm64 systems using EDK2/Tianocore as
> > their firmware.
>
> Unmodified upstream versions that you can re-flash?
Some of the
On Fri, 2016-10-21 at 12:22 +0800, Paul Wise wrote:
> On Fri, Oct 21, 2016 at 4:20 AM, Tollef Fog Heen wrote:
>
> > If there are machines with free firmware that also support secure boot,
> > we can look at this. So far, I don't believe there are any.
>
> Tianocore (edk2 in Debian) supports virt
On Thu, 2016-10-20 at 13:25 +0200, Tollef Fog Heen wrote:
> ]] Ian Campbell
>
> >
> > Have we gotten to the point where we consider deb.d.o suitable for
> > production use? The web page still says Experimental (so I would assume
> > "not production yet"
On Tue, 2016-10-18 at 18:47 +0200, Marco d'Itri wrote:
> On Oct 17, Ian Campbell wrote:
>
> > Have we gotten to the point where we consider deb.d.o suitable for
> > production use? The web page still says Experimental (so I would assume
> I do not think that it is a
On Mon, 2016-10-17 at 15:24 +, Peter Palfrader wrote:
> On Mon, 17 Oct 2016, Ian Campbell wrote:
>
> > TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production
> > use e.g. in base images (including for Jessie)?
>
> Yes.
Thanks!
TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production
use e.g. in base images (including for Jessie)?
On Sun, 2016-10-16 at 09:11 +0800, Paul Wise wrote:
> httpredir.d.o is not well maintained
There still seems to be general grumbling (including a persistent drip
of CI failures
On Wed, 2016-08-10 at 12:19 +0200, Jakub Wilk wrote:
> * Samuel Thibault , 2016-08-10, 01:17:
> >
> > Samuel Thibault, on Wed 10 Aug 2016 00:47:43 +0200, wrote:
> > >
> > > € gpg --search-key samuel.thiba...@gnu.org
> > > ...
> > > (1) Samuel Thibault
> > > 4096 bit RSA key 7D069EE6, created: 20
On Wed, 2016-06-08 at 20:29 +0530, Balasankar C wrote:
> Tell me an "easy" way to do merging in alioth,
I think perhaps it hasn't been made clear to folks on this thread that
gitlab is more like a github style thing (with a webui for PRs and
whatnot) rather than a more "traditional"/"simple" git h
On Mon, 2016-01-11 at 10:49 +0100, Stefano Zacchiroli wrote:
> On Mon, Jan 11, 2016 at 05:43:45PM +0800, Paul Wise wrote:
> > On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote:
> > > So you don't want another component, but something that looks like a
> > > component in some places only? I.e
On Fri, 2016-01-08 at 10:11 +, Jonathan Dowland wrote:
> On Fri, Jan 08, 2016 at 10:21:00AM +0100, Marc Haber wrote:
> > The upside of this is that this will free up space in / which will be
> > needed for a dedicated recovery image. Too bad that we don't have such
> > a thing ourselves and hav
On Tue, 2015-10-27 at 23:00 +0100, Dmitry Katsubo wrote:
> On 27/10/2015 10:31, Ian Campbell wrote:
> > > Hm, kernel.org says that 3.18 is the long-term support kernel.
> >
> > I'm afraid that LTS from kernel.org != stable support from Debian.
> >
> &g
On Mon, 2015-10-26 at 14:55 +0100, Dmitry Katsubo wrote:
> On 2015-10-25 07:11, Adam Borowski wrote:
> > On Sat, Oct 24, 2015 at 10:59:47PM +0100, Simon McVittie wrote:
> > > On 24/10/15 22:17, Dmitry Katsubo wrote:
> > > > I would be happy to. However it does not allow me to use the latest
> > > >
On Mon, 2015-08-03 at 14:37 -0400, Barry Warsaw wrote:
> On Jul 21, 2015, at 06:46 PM, Ian Jackson wrote:
>
> >That is, the dgit git tree contains the patches in debian/patches/
> but
> >also contains the implied changes in the main source code. If you
> add
> >commits yourself to the dgit git
Package: wnpp
Severity: wishlist
Owner: Ian Campbell
* Package name: lua-udev
Version : 0.2
Upstream Author : dodo
* URL : https://github.com/dodo/lua-udev
* License : Expat
Programming Lang: Lua, C
Description : udev library for the Lua language
On Fri, 2015-06-19 at 16:37 +0200, Josselin Mouette wrote:
> Hi,
>
> Hideki Yamane wrote:
> Which is suitable "distribution" in changelog for Jessie and wheezy
> point release? (and why) I just looked debian-release posts and
> confused...
>
> - stable / olds
On Mon, 2015-06-15 at 18:25 +0100, pietrop wrote:
> Hi all,
>
> I am trying to setup a Debian 8 machine running XEN, which I've
> installed from the package manager, to use the USB passthrough.
>
> It looks like I need to use the module xen-usbfront and xen-usbback,
> which I can't find in the /l
On Mon, 2015-05-25 at 20:47 +0200, Julien Cristau wrote:
> On Mon, May 25, 2015 at 19:42:48 +0100, Simon McVittie wrote:
>
> > On 25/05/15 18:24, Lisandro Damián Nicanor Pérez Meyer wrote:
> > > On Sunday 24 May 2015 21:27:47 Adam D. Barratt wrote:
> > > [snip]
> > >> Due to the way that the archi
On Thu, 2015-04-23 at 11:31 +0200, Tollef Fog Heen wrote:
> ]] Ian Campbell
>
> > On Thu, 2015-04-23 at 08:12 +0200, Tollef Fog Heen wrote:
> > > ]] Paul Wise
> > >
> > > > Also accept contributions via email or git request-pull.
> > >
&g
On Thu, 2015-04-23 at 08:12 +0200, Tollef Fog Heen wrote:
> ]] Paul Wise
>
> > Also accept contributions via email or git request-pull.
>
> How do I set up a service to accept git request-pull pull requests into
> a workflow? There does not seem to be any protocol associated with it,
> so «accep
Package: wnpp
Severity: wishlist
Owner: Ian Campbell
* Package name: xss-lock
Version : 0.3.0
Upstream Author : Raymond Wagenmaker
* URL : https://bitbucket.org/raymonad/xss-lock
* License : MIT
Programming Lang: C
Description : invoke external screen
On Wed, 2014-07-23 at 17:07 +0100, Ben Hutchings wrote:
> On Wed, 2014-07-23 at 13:51 +0100, David Goodenough wrote:
> > On Wednesday 23 July 2014 13:05:11 Ben Hutchings wrote:
> > > On Wed, 2014-07-23 at 09:31 +0100, Ian Campbell wrote:
> [...]
> > > > * As
On Tue, 2014-07-22 at 20:50 +0100, Ben Hutchings wrote:
> On Tue, 2014-07-22 at 20:18 +0100, David Goodenough wrote:
> > In the above package the description reads:-
> >
> > The Linux kernel 3.14 and modules for use on ARMv7 multiplatform kernel for
> > Marvell Armada 370/xp, Freescale iMX5x/iMX6
On Sat, 2014-07-19 at 20:25 +0200, Abou Al Montacir wrote:
> Thank you Adam for this notification. I agree that #755285 is duplicate
> of #755286. But then the message should make it clear that it was closed
> because it is duplicate
755286 and 755285 were submitted by the same person and it was p
Package: wnpp
Severity: wishlist
Owner: Ian Campbell
* Package name: sunxi-tools
Version : git snapshot
Upstream Author : Alejandro Mery
* URL : http://linux-sunxi.org/Sunxi-tools
* License : GPL
Programming Lang: C, Shell
Description : tools fo
On Fri, 2014-05-16 at 20:44 -0300, Antonio Terceiro wrote:
> On Fri, May 16, 2014 at 07:43:18AM +0100, Ian Campbell wrote:
> > On Thu, 2014-05-15 at 22:49 -0300, Antonio Terceiro wrote:
> > > On Thu, May 15, 2014 at 08:20:53PM +0100, Ian Campbell wrote:
> > > > On
On Thu, 2014-05-15 at 22:49 -0300, Antonio Terceiro wrote:
> On Thu, May 15, 2014 at 08:20:53PM +0100, Ian Campbell wrote:
> > On Thu, 2014-05-15 at 02:10 +0100, Wookey wrote:
> > > Also if anyone has expertise in language porting we'd like to hear
> > > from you. B
On Thu, 2014-05-15 at 02:10 +0100, Wookey wrote:
> Also if anyone has expertise in language porting we'd like to hear
> from you. Below is the list of languages we believe still need porting to
> arm64:
Ruby wasn't on the list, is that under control?
Ruby seems to be at the bottom of the build-d
On Mon, 2014-04-21 at 13:40 -0600, dann frazier wrote:
> On Sun, Apr 20, 2014 at 05:29:13PM +0100, Ian Campbell wrote:
> > On Sun, 2014-04-20 at 09:08 -0700, Vagrant Cascadian wrote:
> > > On Sun, Apr 20, 2014 at 04:28:45PM +0100, Ian Campbell wrote:
> > > > On Sun,
On Sun, 2014-04-20 at 09:08 -0700, Vagrant Cascadian wrote:
> On Sun, Apr 20, 2014 at 04:28:45PM +0100, Ian Campbell wrote:
> > On Sun, 2014-04-20 at 16:13 +0100, Ben Hutchings wrote:
> > > Given that, it seems like a good time to add arm64 to src:linux with a
> > > con
On Sun, 2014-04-20 at 16:28 +0100, Ian Campbell wrote:
> That said I can't see any reason not to get started on an arm64 kernel.
Except:
The following packages have unmet dependencies:
sbuild-build-depends-linux-dummy : Depends: python but it is not going to be
i
On Sun, 2014-04-20 at 17:08 +0200, Florian Weimer wrote:
> > You may or may not have noticed that 'arm64' is coming. This a 64-bit
> > arm architecture also known as 'aarch64' and implemented in the ARM
> > CPU architecture 'v8'. Apart from iphones there is no publically
> > available 64-bit silico
On Sun, 2014-04-20 at 16:13 +0100, Ben Hutchings wrote:
> On Sun, 2014-04-20 at 16:30 +0200, Adam Borowski wrote:
> > On Sun, Apr 20, 2014 at 02:27:01AM +0100, Wookey wrote:
> > > You may or may not have noticed that 'arm64' is coming. This a 64-bit
> > > arm architecture also known as 'aarch64' an
On Fri, 2014-03-28 at 11:47 +, Thorsten Glaser wrote:
> Adam Borowski angband.pl> writes:
>
> > You don't need to jump through those multistrap hoops anymore. You need
> to
> > recompile the kernel with CONFIG_X86_X32=y, but after that you can use any
>
> Could this *please* become the defa
On Sat, 2013-12-14 at 13:47 +0900, Charles Plessy wrote:
> Dear all,
>
> pv-grub-menu is a package that maintains a configuration file in
> /boot/grub/menu.lst, that is read by the PV-GRUB boot system. It can not be
> part of the grub-legacy package, which is in maintainance mode, and GRUB2
> mai
On Fri, 2013-10-25 at 15:34 -0400, Joey Hess wrote:
> It would be useful if you could arrange for git-deb to produce the
> identical git commit shas for importing a given version of a package as
> does dgit. dgit uses some simple techniques, like using the
> debian/changelog date as the git commit
On Fri, 2013-10-25 at 07:51 -0700, Andrew Kane wrote:
> On Fri, Oct 25, 2013 at 6:09 AM, Ian Campbell wrote:
> >
> > On Fri, 2013-10-25 at 13:31 +0100, Steve McIntyre wrote:
> > > ...I've been
> > > told multiple times that we still have a non-neglig
On Fri, 2013-10-25 at 13:31 +0100, Steve McIntyre wrote:
> We've had this discussion multiple times over the years. I've been
> told multiple times that we still have a non-negligible set of users
> owning/running hardware that can't do DVDs.
The set of hardware which can't boot from DVDs *or* boo
On Thu, 2013-10-03 at 13:56 -0700, Don Armstrong wrote:
> On Thu, 03 Oct 2013, Guillem Jover wrote:
> > On Wed, 2013-10-02 at 10:11:58 -0700, Don Armstrong wrote:
> > > If you do this, I'd also suggest dropping in a rule for
> > > http://bugs.debian.org/libravatar, as I will eventually be moving t
On Fri, 2013-08-02 at 15:29 +0200, Guillem Jover wrote:
> > I was wondering if it is time to drop or deprecate MD5 from the apt
> > metadata and replace it with SHA512 and or SHA-3. Thoughts?
>
> Adding stronger hashes support seems in general like a good idea, but
> I've never quite understood th
On Wed, 2013-06-12 at 23:50 -0400, Chris Knadle wrote:
> One snag I ran into concerning the abstraction layer concerned customizing
> the
> "split file" configuration via conf.d/ files. Upon upgrades dpkg recongizes
> the changes in configuration files and prompts the user; choosing not to
> r
1 - 100 of 160 matches
Mail list logo
