On Wed, Jan 8, 2020 at 11:45 PM Richard Laager wrote:
> We do lose the automatic cron emails
This is the main reason I haven't switched to systemd timers for my
personal crontab, I have some jobs that generate output (diffs of
various things mostly) but don't fail. There doesn't appear to be any
On Wed, Jan 8, 2020 at 12:21 PM Lisandro Damián Nicanor Pérez Meyer wrote:
> On Wed, 8 Jan 2020 at 06:51, Carsten Behling wrote:
> >
> > I get the following error while trying to rebuild
> > 'qtbase-opensource-src_5.7.1+dfsg-3+deb9u1' for Debian Stretch armhf in a
> > pbuilder environment:
>
>
On Mon, 2019-12-30 at 11:29 +0100, Kurt Roeckx wrote:
> Is it .deb and .changes file that you would move?
That would be the idea yeah.
> Note that the name of the .changes file by the maintainer and the
> buildd will be the same, and dak will reject it if that .changes
> file already exists.
I
On Sun, Dec 29, 2019 at 1:29 PM Roberto C. Sánchez wrote:
> Would it not be possible to eliminate the need for the second
> unnecessary upload by requiring two signed .changes files to go into
> NEW? A signed binary changes which would form the basis of the FTP
> master review and a signed
On Sun, Dec 29, 2019 at 11:32 AM Paul Gevers wrote:
> [1] Source packages that build binaries unknown to the archive currently
> need these binaries to be uploaded by the maintainers for reviewing by
> ftp-master in NEW. IIRC there have been multiple proposals to avoid
> these binaries from
On Sun, Dec 29, 2019 at 12:42 AM Robie Basak wrote:
> I file serious bugs when I discover this kind of behaviour in Debian
> packages. I've come across this only twice, but I've never spent time
> actually looking, so perhaps there are many more?
I expect there are quite a few more, some listed
On Fri, Dec 27, 2019 at 6:01 AM Norbert Preining wrote:
> Upstream states clearly what he is collecting, and the rest is obvious
> because displayed on start. No magic necessary.
> Also no hidden stuff, all is clearly stated and open.
That sounds reasonable then.
> What do you mean with
On Thu, Dec 26, 2019 at 5:52 AM Norbert Preining wrote:
> Calibre is normally doing the following checks:
I am wondering how you discovered these, was it just reading the
upstream code/website or are you monitoring traffic on your machine?
Personally, I think we need much more systematic
On Sat, 2019-12-21 at 08:42 -0800, Joshua Hudson wrote:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861053
I think it would be appropriate to add some more information to this
bug to make it easier to understand and take action on.
These bits of information would help:
The output of
On Sat, Dec 21, 2019 at 5:21 AM Joshua Hudson wrote:
> Basically, the existing package maintainer doesn't want to maintain
> lilo anymore, says "will disappear by end of 2020"
You might want to read through the thread about this if you haven't yet:
On Tue, Dec 17, 2019 at 9:25 PM Thomas Goirand wrote:
> If we are already shipping the license (non-free) text as part of
> packages, what difference would it make to have them all shipped in a
> single package? Can't the exception also apply to that one package Jonas
> is suggesting?
One
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 16 Dec 2019 14:49:09 +0800
Source: libpst
Architecture: source
Version: 0.6.71-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise
Changed-By: Paul Wise
Closes: 792257 856524
Changes:
libpst (0.6.71-1) unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 11 Nov 2019 10:33:39 +0800
Source: libforms
Architecture: source
Version: 1.2.3-1.4
Distribution: unstable
Urgency: medium
Maintainer: Peter S Galbraith
Changed-By: Paul Wise
Closes: 941535
Changes:
libforms (1.2.3-1.4
On Sun, Nov 10, 2019 at 1:40 AM Russ Allbery wrote:
> Maybe one of these days I'll take a couple of days and turn it into
> something vaguely maintainable and usable by someone else.
We already have a lot of similar tools for this, unfortunately the
most accurate ones (FOSSology & ScanCode)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 08 Nov 2019 10:03:39 +0800
Source: purple-discord
Architecture: source
Version: 0.9.2019.11.04.git.6552cde-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise
Changed-By: Paul Wise
Changes:
purple-discord
On Mon, Nov 4, 2019 at 4:44 PM Ansgar wrote:
> I would recommend against doing this as long as sources.list is a
> configuration file: it would need regular updates to change to the new
> signing key. That doesn't work out of the box.
No updates are needed if you use what Timo suggested:
> I
On Mon, Nov 4, 2019 at 4:52 AM Guillem Jover wrote:
> The official archive-keyring packages that use these, I think it's mostly
> for backwards compatibility reasons.
I wonder if it is feasible to and how the debian-archive-keyring could
migrate from /etc/apt/trusted.gpg.d/ to
On Sat, Nov 2, 2019 at 7:06 AM Bernd Zeimetz wrote:
> That leads to the question how long it takes until these bugs are being
> noticed.
>
> I am definitely not going to test init scripts properly when the systemd
> units are exactly doing what they are supposed to. The number of people
> not
On Wed, Oct 23, 2019 at 2:32 PM Ansgar wrote:
> It gets confused if a source & binary package with the same name, but
> otherwise unrelated exist; or when the same binary is built from
> different sources on different architectures; or when binary and source
> versions don't match (version
On Mon, 2019-10-21 at 18:58 +0200, Enrico Weigelt wrote:
> I'm pretty sure it does exist, since I wrote it :p
>
> https://github.com/metux/docker-buildpackage
I couldn't find it in Debian so I incorrectly assumed, sorry.
In case you want to get it into Debian:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 21 Oct 2019 11:15:20 +0800
Source: libapache-mod-auth-kerb
Architecture: source
Version: 5.4-2.4
Distribution: unstable
Urgency: medium
Maintainer: Ghe Rivero
Changed-By: Paul Wise
Closes: 934043
Changes:
libapache-mod-auth
On Mon, 2019-10-07 at 11:29 +0100, Simon McVittie wrote:
> I think "re-bootstrap, don't upgrade" is an equally good principle for
> autopkgtest and sbuild? Both will be equally susceptible to accumulating
> cruft during upgrades that wouldn't have been there in a fresh debootstrap,
> which is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 07 Oct 2019 14:30:00 +0800
Source: purple-discord
Architecture: source
Version: 0.9.2019.10.05.git.862f925-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise
Changed-By: Paul Wise
Changes:
purple-discord
On Sun, Oct 6, 2019 at 7:23 PM Simon McVittie wrote:
> FYI, this is because autopkgtest has an abstraction for multiple
> container/virtualization mechanisms (lxc, lxd, qemu, schroot)
It seems like this abstraction should be split out of the autopkgtest
source and then depended on by
On Fri, Oct 4, 2019 at 10:49 PM Enrico Weigelt wrote:
> On 24.07.19 08:17, Marc Haber wrote:
>
> > Do we have a build technology that uses containers instead of chroots
> > yet?
>
> Something like docker-buildpackage ?
AFAICT, docker-buildpackage doesn't exist but whalebuilder does.
For
Hi all,
Since 2017 I have been using the script below (please ignore the
hackyness) to filter out messages from my apt upgrade logs (mailed via
unattended-upgrades) that are indicators of success or "normally"
happen and highlight messages that are indicators of failure or are
weird in some way
On Sun, Sep 15, 2019 at 5:48 AM Anthony DeRobertis wrote:
> On 9/13/19 7:05 AM, Simon Richter wrote:
> >
> > Mandatory Encrypted SNI with no fallback option -- everything else can be
> > circumvented easily.
> >
> > This is a game that we should not play, really. It raises the cost of
> > running
On Thu, Sep 12, 2019 at 3:24 AM gregor herrmann wrote:
> ~/.devscripts already exists (typically) which similar variables,
> maybe this could be re-used?
Using ~/.devscripts means running shell and passing variables out of
it, which is quite hard to get right. The devscripts config loading
On Tue, Sep 10, 2019 at 4:18 AM Thomas Gaugler wrote:
> Therefore I intend to switch win32-loader from an x86-ansi to an
> x86-unicode installer. The drawback would be that Windows versions prior
> Windows XP would no longer be supported.
Would it be possible to build both versions in order to
On Mon, Sep 9, 2019 at 2:31 AM Ondřej Surý wrote:
> Mozilla plans to enable DoH to CloudFlare by default to US based users
Does anyone know if there is any plan for the DNS root servers to
enable any of the DNS privacy options? AFAIK the available options are
DNSCurve, DoT or DoH.
--
bye,
pabs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 30 Aug 2019 09:30:58 +0800
Source: purple-discord
Architecture: source
Version: 0.9.2019.08.26.git.df0d11a-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise
Changed-By: Paul Wise
Changes:
purple-discord
On Thu, Aug 29, 2019 at 4:00 AM Sam Hartman wrote:
> Using native source formats (1.0 and 3.0 (native)) is attractive for
> some git workflows. It means you can just export the git repository and
> don't need to make sure that you use the same upstream tarball when
> upstream versions are the
On Fri, Aug 23, 2019 at 7:31 PM MAD wrote:
> Has anyone else perceived this email as spam?
The message you have quoted is definitely spam.
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Wed, Aug 21, 2019 at 2:48 PM Andreas Tille wrote:
> DEP-12 is declared as "Work in progress" (without any progress since 5
> years) while DEP-5 is well established and decided. Charles and I
> invented d/u/metadata to store publication information and it turned out
> that there is other
On Wed, 2019-08-14 at 17:44 -0700, Mo Zhou wrote:
> * For a source package that produce binary package containing ML models,
> it's encouraged to write a "reproduce-original-model" that may e.g.
> download a dataset from internet and redo the same procedure to
> produce the original model.
On Tue, Aug 13, 2019 at 8:45 AM Sam Hartman wrote:
> In cases where the model is not recreated, but where software in Debian
> could create the model, I think a README file is better than a package
> relationship.
Personally, I'd like to see Policy specify a standard mechanism that
people could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 08 Aug 2019 14:56:30 +0800
Source: uhubctl
Architecture: source
Version: 2.0.0-5.1
Distribution: unstable
Urgency: medium
Maintainer: gustavo panizzo
Changed-By: Paul Wise
Closes: 925913
Changes:
uhubctl (2.0.0-5.1
On Thu, Aug 8, 2019 at 4:59 AM Andrei POPESCU wrote:
> 1. Delete the contents of /etc (all of it)
> 2. If a package doesn't find its "stuff" in /etc it regenerates it from
> defaults.
There is still way too much stuff that defaults to installing
important files in /etc (default config settings,
On Tue, Aug 6, 2019 at 7:34 PM Bill Allombert wrote:
> A related issue is that the submission time is randomized, but if
> 2600 systems have identical /etc/cron.d/popularity-contest files, they
> will report at the same time, causing network spikes.
BTW, a systemd service timer has native
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 02 Aug 2019 13:57:30 +0800
Source: purple-discord
Architecture: source
Version: 0.9.2019.07.29.git.763ba75-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise
Changed-By: Paul Wise
Changes:
purple-discord
On Mon, Jul 29, 2019 at 3:02 PM Simon McVittie wrote:
>
> On Mon, 29 Jul 2019 at 00:17:17 +, Thorsten Glaser wrote:
> > echo "deb [trusted=yes] file://$base ./"
> > >"/etc/apt/sources.list.d/$this.list"
>
> sbuild and autopkgtest (and probably other build/CI tools) also rely on
> being able
On Sun, Jul 28, 2019 at 10:33 PM Johannes Schauer wrote:
> If we choose the "src:" prefix to pick source instead of binary packages, then
> it's important that we don't have any binary packages called "src" and no
> source packages with a name equal to a valid debian architecture.
Could we have
On Sun, Jul 28, 2019 at 10:04 PM Mo Zhou wrote:
> Is such demand common enough among developers?
There are several ways this would be useful:
To replace all librust-*-dev and golang-*-dev packages (they contain
source code).
To replace all toolchain -source packages, so that cross-compiling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 27 Jul 2019 19:01:18 +0800
Source: apt-xapian-index
Architecture: source
Version: 0.50
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group
Changed-By: Paul Wise
Closes: 758403 804099 841417
Changes:
apt
On Thu, Jul 25, 2019 at 3:03 PM Abibula Aygun wrote:
> It is ok to insert in Academix GNU/Linux installation media the non free
> firmwares?
This depends on what is allowed by the licenses of the non-free
firmware files. I expect most of them allow redistribution though,
especially since Debian
On Thu, Jul 25, 2019 at 2:18 PM Johannes Schauer wrote:
> But you'd have to ask somebody who is more knowledgable about the security
> implications of such a change. There certainly is a reason why #898446 is
> still
> open.
>
> Furthermore, since buildds currently use the schroot backend, I
On Wed, Jul 24, 2019 at 2:42 PM Johannes Schauer wrote:
> Or using the built-in "unshare" backend which uses linux user namespaces:
>
> $ sbuild --chroot-mode=unshare --chroot=debian-unstable.tar
Do you think it is feasible to use this on some of or the majority of
Debian buildds (most run
On Thu, Jul 18, 2019 at 1:12 AM Seth McClain wrote:
> xTuple recently took most of their git repos off of github and is
> changing the license to much of the code moving forward.
>
> https://xtuple.com/blog/ned/free-software
>
> Debian currently offers builds of Postbooks.
>
>
On Wed, Jul 17, 2019 at 7:05 PM Helmut Grohne wrote:
> If you want to make firewalld the desktop default
To me, something like opensnitch seems like a better option for a
desktop firewall once it becomes more mature and enters Debian.
https://github.com/evilsocket/opensnitch/
On Tue, Jul 16, 2019 at 7:00 PM Javeed Ahmed wrote:
> can i make my own os using debian as a base and distribute it?
Yes, but you can also join the Debian project and help us improve the
Debian operating system for your use-cases.
Would you like to share your plans for how you want to change
On Mon, Jul 15, 2019 at 6:48 PM Simon Richter wrote:
> The main limitation seems to be that it's not permitted to modify
> inetd.conf from maintainer scripts. We could probably "fix" this by adding
> an "inetd.conf.d" mechanism.
There is update-inetd, but it doesn't support xinetd and doesn't
On Sun, Jul 14, 2019 at 9:57 PM wrote:
> Please Insert Mozilla Firefox Release in Debian.
Mozilla Firefox is available in Debian, the package name is firefox-esr.
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Sun, Jul 14, 2019 at 9:51 PM wrote:
> Please add a Search field in LXDE Menu.
This suggestion sounds like it would be best to send to the LXDE community:
https://lxde.org/
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Sat, Jul 13, 2019 at 5:27 AM Joe Irungu wrote:
> Thus is there a system-config-lvm for Debian 10 or how else can I manage
logical volumes in Buster?
system-config-lvm was removed from Debian buster in 2017:
https://tracker.debian.org/pkg/system-config-lvm
On Sat, Jul 13, 2019 at 1:21 AM Joe Lobeck wrote:
> in the meantime I found that the most things work form kernel 5.0 or higher.
> Unfortunately so I will have to choose an other linux distribution as such a
> kernel
> is for debian only from the experimantal repository avaiable.
> If you have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 11 Jul 2019 11:52:27 +0800
Source: foxtrotgps
Architecture: source
Version: 1.2.2-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise
Changed-By: Paul Wise
Closes: 926575
Changes:
foxtrotgps (1.2.2-1) unstable
On Wed, Jul 10, 2019 at 7:59 PM Julian Gilbey wrote:
> So I read apt-secure(8), which gives no indication of how to "accept
> this explicitly", and neither do any of the linked wiki pages.
>
> Any suggestions?
There are two options:
# apt update
# apt-get --allow-releaseinfo-change update
--
On Wed, Jul 10, 2019 at 4:18 PM Julian Andres Klode wrote:
> What's the use case for having oldstable in your sources.list on
> unstable/testing machines?
I have it in a chdist so that I can look up package versions in old releases.
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Tue, Jul 9, 2019 at 11:24 PM Nicholas D Steeves wrote:
> To be fair, doesn't the QA team (and random acts of kindness) often
> keep these packages alive?
There is no specific team maintaining orphaned packages, other than
the set of Debian contributors who are motivated to do that.
--
bye,
On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
> Timeline suggestion
> ---
> now add a warning to apt 1.9.x for repositories w/o InRelease, but
> Release{,.gpg}
> Aug/Sep turn the warning into an error, overridable with an option (?)
> Q1 2020 remove
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 09 Jul 2019 15:58:49 +0800
Source: harmony
Architecture: source
Version: 0.6.0-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise
Changed-By: Paul Wise
Changes:
harmony (0.6.0-1) unstable; urgency=medium
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 09 Jul 2019 14:58:32 +0800
Source: librecaptcha
Architecture: source
Version: 0.6.2-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise
Changed-By: Paul Wise
Changes:
librecaptcha (0.6.2-1) unstable; urgency
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 09 Jul 2019 13:47:05 +0800
Source: purple-discord
Architecture: source
Version: 0.9.2019.06.12.git.f8ea0ae-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise
Changed-By: Paul Wise
Changes:
purple-discord
On Tue, Jul 9, 2019 at 7:42 AM Colin Watson wrote:
>A memory-safe language with good testing support and a good testing
>culture would be great, though it does also need to work on every
>Debian architecture, which IIRC Rust doesn't quite; we've kicked
>around the idea of maybe a
On Thu, 2019-07-04 at 13:53 +0100, Ian Jackson wrote:
> Does every DD have (i) access (ii) social authority, to make changes
> to the upstream repo, the same way we do for the Debian package ?
I was simply talking about standard upstream contribution mechanisms;
pull requests, requests to pull
On Thu, 2019-07-04 at 12:19 +0100, Ian Jackson wrote:
> What should another Debian contributor do, who wants to make a change
> to the upstream source, but wants to do so in your own git workflow
> and collaborate via your git branch, rather than by uploading a .dsc ?
Do upstream changes
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
On Sat, Jun 29, 2019 at 8:16 PM Tomas Pospisek wrote:
> Let's seriously consider using year based release identifiers.
At this point in the thread it is very clear that which identifier one
prefers is very individual and dependent on use-cases. So we should
add support for more individuals and
On Wed, 2019-06-26 at 14:54 -0400, Michael Stone wrote:
> Wouldn't it be nicer to have a reliable and simple source of version
> ordering rather than relying on ugly names and symlinks? As a bonus, it
> would be useful for a lot more things and for more than n-2
> calculations.
That doesn't
On Tue, Jun 25, 2019 at 4:39 PM Paul Wise wrote:
> On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
>
> > what do people think about getting rid of current suite names ("stable",
> > "testing", "unstable") for most purposes? We already recommend u
On Tue, Jun 25, 2019 at 8:04 PM Michael Stone wrote:
> Having "stable" in sources.list is broken, because one day stuff goes
> from working to not working, which requires manual intervention, at
> which point someone could have just changed the name. Having codenames
> in sources.list is broken,
On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
I use these
On Thu, Jun 13, 2019 at 8:54 PM LeJacq, Jean Pierre wrote:
> I'm hoping to have my key signed by a Debian Developer at the SouthEast
> LinuxFest this coming weekend.
The debian-events-na (North America) list might be a good place to repost this.
https://lists.debian.org/debian-events-na/
In
On Wed, Jun 12, 2019 at 10:34 PM Vincent Lefevre wrote:
> I have gtk3-nocsd installed on my machines, but I don't think a
> default install is a good idea, as its necessary use via LD_PRELOAD
> breaks *any* program using ASan.
The sanitisers shouldn't be used in production binaries due to
On Wed, Jun 12, 2019 at 1:21 AM Benjamin Drung wrote:
> * I had to patch reprepro to support multiple versions:
> https://github.com/profitbricks/reprepro
I think it would be very helpful to a lot of derivative distros and
small or private apt repositories if this patch could be merged
upstream
On Sun, Jun 9, 2019 at 3:44 AM Adam Borowski wrote:
> So if you took current d-i and planted it into a regular live image
IIRC debian-live used to have that but it was too buggy so it got
removed. Later Calamares replaced it.
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Fri, Jun 7, 2019 at 11:24 PM Adam Borowski wrote:
> In general: could we please do something to appearance beyond choosing a
> wallpaper once a release?
Please note that modifying the appearance of apps can annoy upstreams:
https://stopthemingmy.app/
On Sat, Jun 8, 2019 at 10:09 AM Russ Allbery wrote:
> Please let us have internal conversations without using them to
> prematurely pick fights with external maintainers.
It definitely wasn't my intention to pick a fight.
I strongly disagree with hiding upstream problems from upstream
On Sat, Jun 8, 2019 at 4:48 AM Julian Andres Klode wrote:
> On Fri, Jun 07, 2019 at 03:36:08PM -0500, Federico Mena Quintero wrote:
> > On Fri, 2019-06-07 at 11:48 +0800, Julian Andres Klode wrote:
> >
> > Why am I getting BCCed on this? Is this low-key unsolicited
> > complaining like in
On Tue, Jun 4, 2019 at 4:12 AM Yves-Alexis Perez wrote:
> My gut feeling is that light-locker just uses codepaths not really used
> otherwise, like vt-switch at the same time as suspend/resume or screen off/on.
> Unfortunately debugging i915 is completely out of my league (and I already
> tried
On Fri, May 31, 2019 at 5:32 AM Holger Levsen wrote:
> LTS is accepted by the Debian community.
I'm not entirely sure this fully represents the range of feelings
about the LTS efforts.
There are a few things that are possibly concerning:
Freexian is essentially the only available-to-hire
On Wed, May 29, 2019 at 8:46 PM Raphaël Halimi wrote:
> What would be the "cleanest" solution according to you ?
The cleanest solution would be to get this code into Linux mainline.
Some discussion of workarounds:
dak needs a way to restrict the availability of arch:all packages to
certain
On Wed, May 29, 2019 at 5:36 PM Mo Zhou wrote:
> For example, many years ago I proposed that we could hire some
> web developers to rewrite our homepage, to make it more good-looking
> (Generally I don't care about superficial stuff but our homepage
> is really old enough. Look at Gentoo's
On Tue, May 28, 2019 at 4:12 PM Ulrike Uhlig wrote:
> - is a Salsa account created automatically for every DD? This includes
> non-uploading DDs.
Yes.
> how does one recover the password?
I expect the normal gitlab password reset works, I haven't tested it though.
> /* I
MENGUAL Jean-Philippe wrote:
> For non-uploading DD, is a salsa account created? I tried to auth
> with it, but not possible, then to reset the passwd, but I dont
> rceive mail to do it on @debian.org.
Typos were made in the Debian LDAP data of another recently accepted
Debian member and that
On Mon, May 27, 2019 at 2:52 PM Vincent Bernat wrote:
> People using tools like fpm will never get familiar with our tools and
> will never be contributors.
I enjoyed your blog post about pragmatic packaging using Debian's
tools instead of fpm, it seems like a good approach if one is
committed
On Fri, 2019-05-24 at 10:43 -0400, Sam Hartman wrote:
> I wonder whether we'd accept a developer's assertion that some large pdf
> in a source package could be rebuilt without actually rebuilding it on
> every upload.
As I understand it, ftp-master policy is that things in main be
buildable
On Fri, 2019-05-24 at 03:14 -0700, Mo Zhou wrote:
> Non-free nvidia driver is inevitable.
> AMD GPUs and OpenCL are not sane choices.
So no model which cannot be CPU-trained is suitable for Debian main.
> Don't doubt. Nouveau can never support CUDA well.
There is coriander but nouveau doesn't
On Fri, May 24, 2019 at 1:58 AM Sam Hartman wrote:
> So for deep learning models we would require that they be retrainable
> and typically require that we have retrained them.
I don't think it is currently feasible for Debian to retrain the
models. I don't think we have any buildds with GPUs
On Tue, 2019-05-21 at 03:14 -0700, Mo Zhou wrote:
> They are added to the case study section.
Are there any other case studies we could add?
Has anyone repeated the training of Mozilla DeepSpeech for example?
Are deep learning models deterministically and reproducibly trainable?
If I re-train
On Tue, May 21, 2019 at 3:11 PM Mo Zhou wrote:
> I'd better write a draft and shed some light on a safety
> area. Then here is the first humble attempt:
>
> https://salsa.debian.org/lumin/deeplearning-policy
The policy looks good to me.
A couple of situations this related to this policy:
On Wed, May 15, 2019 at 2:31 AM Sam Hartman wrote:
> How do we feel about people making build system conversions when those
> conversion make it easier to fix some other bug that they are fixing as
> part of an NMU?
If the maintainer is MIA enough to not express an opinion when asked
if adding a
On Mon, May 13, 2019 at 8:34 PM Sam Hartman wrote:
> As promised, I'd like to start a discussion on whether we want to
> recommend using the dh command from debhelper as our preferred build
> system.
This is already the case AFAICT.
> But I think what we're really talking about is whether
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 04 May 2019 14:53:44 +0800
Source: corekeeper
Architecture: source
Version: 1.7
Distribution: unstable
Urgency: medium
Maintainer: Paul Wise
Changed-By: Paul Wise
Closes: 924397 924398
Changes:
corekeeper (1.7) unstable
On Wed, May 8, 2019 at 9:27 PM Vipul wrote:
> I've been using Debian from couples of years but haven't contributed yet back
> to community.
There are a number of different ways to contribute to Debian:
https://www.debian.org/intro/help
> I want to contribute to Debian by maintaining packages
On Thu, May 9, 2019 at 1:38 AM Adam Borowski wrote:
> Thus, even though we'd want to stick with xz for the official archive, speed
> gains from zstd are so massive that it's tempting to add support for it,
> at least for non-official uses, possibly also for common Build-Depends.
Could we use
On Mon, May 6, 2019 at 9:42 AM wrote:
> We've been discussing possible Monero implementation into Debian and not sure
> how we can proceed.
It sounds like Monero is only suitable for Debian experimental due to
the rate of upstream introducing backwards-incompatible versions.
> AppImage,
On Tue, Apr 30, 2019 at 9:03 AM Ben Finney wrote:
> My opinionated recommendation: Track the Debian packaging in a separate
> repository (which contains only the ‘debian/’ directory tree). When it's
> time to build the Debian source package for testing, export the upstream
> source to a temporary
On Fri, Apr 12, 2019 at 3:27 PM Simon McVittie wrote:
> Flatpak treats /usr as immutable (with the exception of mounting
> "extensions" on pre-prepared empty directories) and mounts it read-only in
> the container. If it didn't, it wouldn't be able to use content-addressed
> storage (the storage
On Thu, Apr 11, 2019 at 7:01 PM Simon McVittie wrote:
> The "app" (directly-user-facing part) in a Flatpak package will be mounted
> on /app and so is expected to be built with --prefix=/app, so you can't
> reuse a compiled binary .deb unless it's for something that happens to be
> relocatable
401 - 500 of 2824 matches
Mail list logo
