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 source
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 either
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 o
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 "informe
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 auditin
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 bot
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:
https://lists.debian.org/msgid-search/20191
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 differe
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) aren'
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 j
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 /usr/share/keyring
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 usin
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 trackin
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:
https://mentors.debian.net/intro-
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 unde
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 autopkgtest.
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 systemd-n
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 th
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 a
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
module
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 ke
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
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 s
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 sensib
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 u
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, i
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 randomi
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 to
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 a
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
too
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 gues
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 st
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.
>
> https://salsa.debian
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/
https://bugs.debian
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 th
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
app
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
https://tracker.debian.org/news/85184
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 an
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,
p
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 th
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 s
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 fr
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 upstream
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
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 us
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 se
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, b
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 (testi
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 add
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
securit
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 a
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/
https://www.omgubuntu.co.uk/2019/05/open-l
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
developers
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 https://
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 mu
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 provid
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 arch
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 homepag
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 reme
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 was
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 to
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 from
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 s
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 yet.
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 a
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:
http
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 mainta
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 a
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 cust
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, maybe?
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 c
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 alr
On Tue, Apr 9, 2019 at 2:09 PM Bastian Blank wrote:
> You use your display in HiDPI mode or, worse, in fractional HiDPI mode?
I don't own hardware that is new enough.
> mpv knows about the real resolution
Could you try totem too?
> This package is maintained by QA.
>From a user PoV the Mainta
On Fri, Apr 5, 2019 at 11:25 PM Mo Zhou wrote:
> I second that since I always refuse to use Wayland, due to
I'm currently using GNOME on Xorg because:
Under Wayland applications seem to have a problem displaying
fullscreen, for example totem only displays video in the upper left
corner of the sc
On Mon, Apr 8, 2019 at 3:34 PM Mo Zhou wrote:
> However, the translator itself is not trivial, as it might need
> it's own shell parser or something alike to be reliable enough.
Couldn't you just run makepkg (with some hooks) and dpkg-deb to
convert the results to Debian packages?
--
bye,
pabs
On Sun, Apr 7, 2019 at 9:26 PM Mo Zhou wrote:
> Such idea about informal packaging repository has been
> demonstrated successful by the Archlinux User Repository (AUR).
> Hence, it should be valuable to think about it for Debian.
Seems like a PKGBUILD-to-deb script would be a simple way to do thi
On Sun, Apr 7, 2019 at 10:14 PM Peter Silva wrote:
> We would love to be able to upstream to debian, but haven't figured it out
The process is pretty simple, but reliant on the limited number of
Debian members who do package sponsorship. The ones we do have are
fairly active though. The process
On Fri, Apr 5, 2019 at 11:25 PM Mo Zhou wrote:
> 2. redshift doesn't work under wayland. There seems to be no CLI
>program available for such purpose.
GNOME/Wayland in buster supports this natively: Settings -> Devices ->
Displays -> Night Light
--
bye,
pabs
https://wiki.debian.org/PaulWis
On Fri, Mar 15, 2019 at 11:15 PM Gaurav Mishra wrote:
> ITP: fossology -- FOSSology is an open source license compliance software
> system and toolkit.
...
> - Why is this package useful/relevant?
>- FOSSology is a famous tool used for open source license compliance.
> We have a large d
On Sat, Mar 16, 2019 at 6:06 AM Guillem Jover wrote:
> $ deb-why-removed fossology
I think this script would be a good addition to devscripts, could you
file a bug about that?
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Mon, Feb 25, 2019 at 11:22 PM Roberto C. Sánchez wrote:
>
> On Mon, Feb 25, 2019 at 02:44:22PM +, Jonathan Dowland wrote:
> > On Mon, Feb 25, 2019 at 11:19:35AM -0300, Inaki Malerba wrote:
> > > On behalf of the Salsa CI Team I'm pleased to announce some of the
> > > changes we've been worki
On Mon, Feb 25, 2019 at 7:14 PM Philipp Meisberger wrote:
> Poorly libpam-fprintd is not suitable as libfprint0 seems to support
> ZhianTec fingerprint sensors. libpam-fingerprint is especially for those
> sensors. I see it would be more precise to use "Pluggable Authentication
> Module for ZhianT
On Sat, Feb 16, 2019 at 12:00 PM Sean Whitton wrote:
> Use of the Build-Conflicts field is currently mostly optional, but Ian
> Jackson and I have been working on text for Debian Policy that would
> require its use in certain cases. See #824495 for the discussion.
Personally, the main RC use-cas
On Tue, Feb 5, 2019 at 6:02 PM Steffen Möller wrote:
> at times I now find pointers to Patron (https://www.patreon.com),
> Flattr (https://flattr.com/) et al.
> (https://alternativeto.net/software/patreon/) in the READMEs of a
> software I am about to package. Is this something that should be
> r
On Sat, Jan 19, 2019 at 10:43 AM Hideki Yamane wrote:
> At
> https://qa.debian.org/debcheck.php?dist=unstable&package=fonts-sawarabi-mincho,
> it show as below but debhelper-compat (= 12) is satisfied in sid
>
> > BuildDepends
> >
> > Package declares a build time dependency on debhelper-compat
On Wed, Jan 9, 2019 at 10:40 AM Hideki Yamane wrote:
> Thanks, but at some releases like stretch doesn't have "InRelease"
> file but have "Release" file as
> http://ftp.debian.org/debian/dists/stable/InRelease
> and http://ftp.debian.org/debian/dists/stable/Release
Release and InRelease are i
On Wed, Jan 9, 2019 at 10:23 AM Hideki Yamane wrote:
> Could someone tell me that, at InRelease file in repository,
> is "Valid-Until:" not mandatory or not?
It definitely isn't mandatory, Debian stable does not use it:
http://ftp.debian.org/debian/dists/unstable/Release
http://ftp.debian.org/
On Tue, 2019-01-08 at 13:20 +0100, Bastien ROUCARIES wrote:
> I could add a sensible-x-www-browser to be more nice to our user to
> sensible-utils
We already have a x-www-browser alternative, so sensible-x-www-browser
would just duplicate that and is thus not needed.
--
bye,
pabs
https://wiki.
401 - 500 of 2399 matches
Mail list logo
