wondering if there is something Debian can do to be even more
> successful in the container world.
You could use dck-buildpackage --create-baseimage to do that.
Feel free to create some target configs, and I'll be happy to add them.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded e
ependencies already installed - but I don't like manual things :o)
BTW: one important point w/ dck-buildpackage for me was being able
to specifiy what's in the image. I really prefer to have it really
minimal.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineer
w/ k8s ...
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
ildpackage ?
>
> AFAICT, docker-buildpackage doesn't exist
I'm pretty sure it does exist, since I wrote it :p
https://github.com/metux/docker-buildpackage
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
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 ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
igured installations.
One thing seems to be right: folks who always have been hostile towards
the whole concept of distros now have a better excuse.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
e can also release
> build
> dependency updates via stretch-security).
ACK. I haven't had a chance to take a deeper look at the rust/cargo
issue yet (currently too occupied with other things). If anybody could
come forward with a solution, I'd be really glad.
--mtx
--
Enrico Weigelt, metux I
this ...
> The AppStream metadata format includes a field for "hardware this works
> with", and beignet-opencl-icd has one, but I don't know if any existing
> tools use this field.
I don't like the idea of making driver packages depending
on some desktop stuff :o
IMHO, it shou
On 01.07.19 21:06, Enrico Weigelt, metux IT consult wrote:
Hi,
> IIRC the whole things is actually about crypto stuff. Why don't zfs> folks
> just use the standard linux crypto api (potentially introduce a>
new algo if the existing ones aren't sufficient) ?
Addendum: just had
as far as I remember).
IIRC the whole things is actually about crypto stuff. Why don't zfs
folks just use the standard linux crypto api (potentially introduce a
new algo if the existing ones aren't sufficient) ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineeri
pplications that treat "no hardware for this driver" as "fatal error"
> instead of "try the next driver".
So, installing an opencl-based package pulls in *all* cl driver stacks ?
Please don't do that. This IMHO clearly belongs into the operator's
hands (or possibly s
bianized branch) and publishes the repos to the outside world,
would be a really cool thing for me. IIRC that should also cover this
'scratch builds' usecase.
I admit, I haven't checked whether gitlab-ci can already do that.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedde
On 01.07.19 15:09, Andrey Rahmatullin wrote:
> On Mon, Jul 01, 2019 at 03:04:26PM +0200, Enrico Weigelt, metux IT consult
> wrote:
>> On 29.05.19 17:41, Andrey Rahmatullin wrote:
>>
>>>> Perhaps we should update policy to say that the .orig tarball may (or
>>
ld be better to just differenciate the statistics between
official debian and others (such as downstreams).
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
adable git repo and makes
interacting w/ upstream (eg. submitting patches) unncessarily hard.
That's something I regularily see w/ crappy vendor kernels, which then
take lots of time to bring them into some somewhat usable state :o
--mtx
--
Enrico Weigelt, metux IT consult
Free software and
le process
(eg. fully automatic, easily reproducable transformations)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
idiered "applicable" (or better: when is it okay not doing
that) and some rules on how the generation process shall be done.
(maybe having some script with a defined name ?)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
some more details on the intended workflow ?
Why does one need that information at all ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
o
> record what the most recent rebase is. Obviously I prefer
> git-debrebase since I wrote it - using a different data model - even
> after I knew about git-dpm and its data model. But maybe this isn't
> the thread for that advocacy conversation.
What exactly does this tool do ?
we could figure out a way to collaborate on something like that well,
> it might be a very interesting tool to have.
ACK.
I believe we should set some computable policies on how orig trees are
generated from actual upstream repos and patches are handled, so we can
do imports/transformations fully aut
ll required to produce a .dsc.
I don't think that .dsc really makes the picture so different. It always
can be generated automatically. IMHO, it's only needed as an output
format for creating src repos and as an intermediate transport for
traditional tools like buildd.
--mtx
--
Enrico Weigel
tary userland interface can't be accepted for mainline - it
has to be reworked to be conformant w/ standard uapi (eg. we already
have it for things like snapshots, deduplication, quotas, ...)
But it's up to ZoL developers to do the actual work and post patches
to lkml. There won't be anybody else doing that.
ours, etc. - instead I'm using separate layer 2 branches
for that.
(for maintaining lots of kernel configs based on some meta config, I've
got a separate tool)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
just
basing on their release tags. And, of course, there shouldn't be
anything autogenerated in the git repo - always recreate everything
(*especially* autotools-generated stuff). The orig tarball, IMHO, is a
long obsolete ancient relic.
For upstreams that don't have a git repo yet, I setup an
success, so I just gave up :(
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
intainers was asymptotically
approaching zero, from below.
> Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices
> / repository format"):
>> I'm always cloning the upstream repo, branch off at their release tag
>> and add all necessary chanages a
ome
the generic (non-deb specific) patches, then the deb specific ones.
No text-based patches, or even magic rewriting within the build process.
The HEAD is exactly the debianized source tree, which is then fed to
dck-buildpackage.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linu
ack source tree plus debian/, some w/ extra text-based patches,
some w/ patches already applied in git.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
rd upstreams in my list...
Maybe we should talk about some of these cases, to get a better idea.
In general, we IMHO should rethink the workflows for creating the actual
buildable debian tree from upstream releases (in many packages that's
still pretty manual and hackish)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
erything from a debianzed source
tree (eg. git repo) within a minimal container/jail, w/o any other extra
configuration outside that source tree - even for those cases where the
control file needs to be generated, which again needs some deps.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
hich is used by my build machinery
(dck-buildpackage) in a separate preparation step, when control file
is missing.
But still, IMHO, the debian packaging toolstack is much superior to
anything else i've every encountered.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linu
Okay, it's just a dream, but a very nice one ;-)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
IMHO not in official Debian
repo, but I've got it hanging around in some 3rdparty repo ...
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
On 19.11.18 20:24, gregor herrmann wrote:
> On Mon, 19 Nov 2018 17:29:37 +0100, Enrico Weigelt, metux IT consult wrote:
>
> (OT, but since I noticed it too:)
>
>> Anyways, Skype doesn't work since 8.30 as it crashes directly on
>> startup.
>
> Apparently it need
y code changes outside
git, and I'm building packages only directly from git. Frankly, I don't
see any reason why that can't be the standard case.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
haviour.
hmm, looks like good start. But it doesn't really look easy to clone
from different distros and specific or yet unreleased versions.
and one of my main problems remains unresolved: linear history ontop
of the upstream's release tag.
--mtx
--
Enrico Weigelt, metux IT consult
Free so
tworthy code them into a minimal container
w/ fine tuned minimal permissions.
Anyways, Skype doesn't work since 8.30 as it crashes directly on
startup.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
re and there, it still far away from an
fully-automated process.
I'm currently helping myself w/ lots of mappings and import scripts,
but I'd like to get rid of maintaining all these little pieces.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
sure that
nothing in that really complex cmake file can even try build/use any
piece of them.
the package was just meant for an inhouse installation for my client,
so i didn't care much about policies and orig tarball handling - I've
just patched directly in the git repo.
--mtx
--
Enrico Weigelt
affected packages.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
en and unusable anyways - for several
month now. We could reconsider once the Upstream (Microsoft) manages
get it at least running w/o segfaulting.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
bad quality or even malicious.
Finally, I'd really like to reduce complexity, not introduce even more.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
some local customizations.
(planned for future releases)
I'm also hacking on another tool which automatically clones repos
and calls dck-buildpackage for building whole pipelines - but that's
still experimental and hackish:
https://github.com/metux/deb-pkg
--mtx
--
Enrico Weigelt, metux
ations, eg. moz).
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
Hi folks,
is it possible to use the substvars mechanism for the *.install and
similar files, just like w/ control file ?
For multi-version installations, I'm keeping the whole package in a
prefix w/ the version number (see my other mail - nodejs). I don't like
to change lots of files which
On 04.05.2017 09:26, Jérémy Lal wrote:
> At the moment, in debian, /usr/lib/nodejs is there to store all node
> modules installed from debian packages.
hmm, would that conflict w/ having certain "nodejs-$version" subdirs
w/ the actual engines (the whole tree - not splitted out the several
FHS
Hi folks,
I'm currently packaging nodejs-7.9 for various deb Distros.
I'll have to maintain some applications that use the fanciest
new features, and precompiled binaries from untrusted sources
(eg. nvm+friends) of course are not an option.
Before I go all of this alone - is there anybody here
On 14.04.2017 14:34, ian_br...@mail.ru wrote:
> I was right -- it IS a Debian Policy violation:
>
> * 4.13 Convenience copies of code *
I've got a similar problem while packaging recent webkit (latest surf
needs a newer one). Their git repo is >GB (!). No idea how much I'll
have to cut out
On 13.04.2017 11:27, Vincent Danjean wrote:
> For me, the first argument explain in the first mail is not this one.
> systemd is not portable on lots of system (hurd, kFreeBSD, ...),
This is just one of many arguments for not making applications
depending on it. (and they shouldn't depend on
On 17.02.2015 18:49, The Wanderer wrote:
Hi folks,
just digging out an older thread that was still laying around in my
inbox - w/ about 2yrs distance, I hope it was enough cool down time
so we discuss it more objectively about that.
> libsystemd0 is not a startup method, or an init system.
On 11.04.2017 10:22, Andrey Rahmatullin wrote:
> On Tue, Apr 11, 2017 at 04:22:40AM +0200, Enrico Weigelt, metux IT consult
> wrote:
>>>>
>>>>
>>>> could anyone please give me some insight, was the security problems
>>>> are here exactly ?
&
On 09.04.2017 22:58, Andrey Rahmatullin wrote:
> On Sat, Apr 08, 2017 at 08:28:38AM +0200, Enrico Weigelt, metux IT consult
> wrote:
>>
>>
>> could anyone please give me some insight, was the security problems
>> are here exactly ?
> Extension auto-updating is
could anyone please give me some insight, was the security problems
are here exactly ?
--mtx
--
mit freundlichen Grüßen
--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287
Hi folks,
I'm just packaging some library to various deb distros using
pbuilder + git-buildpackage.
Unfortunately, the .so's loose the +x flag in the package
(while usual 'make install' is okay) - it seems that some of the
dh stuff drops that flag :(
maybe some of you guys might have an idea ?
On 02.01.2015 17:08, Martin Pitt wrote:
Hi,
Yes, man dh_fixperms. Shared libraries don't need to and should not be
executable.
Oh, wasn't aware of that. Just used to that as gcc sets that flag.
Is it a bug in gcc, or are there platforms where +x is required ?
cu
--
Enrico Weigelt,
metux IT
On 25.11.2014 16:29, Philip Hands wrote:
How is it that Debian changing the default for something on some of
What about the enforced replace on dist-upgrade, which at least
produces lots of extra work and can easily cause systems being
unbootable ?
cu
--
Enrico Weigelt,
metux IT consulting
On 29.11.2014 19:15, Svante Signell wrote:
Since there is no interest in adding a debconf message on new installs,
I wish for a menu entry in the advanced part of the installer to be able
to install a new system with sysvinit-core or upstart!
+1
--
mit freundlichen Grüßen
--
Enrico
On 29.11.2014 20:43, Svante Signell wrote:
The best for kFreeBSD and Hurd would be to abandoning the Debian ship.
It is sinking :( (just let the devuan people get things in order first)
Well, I'll also put my projecsts on getting rid of polkit into that
direction. Why ? Because I've got the
On 29.11.2014 20:45, Ivan Shmakov wrote:
As for Systemd being the default (on Debian GNU/Linux,
specifically), – I guess I shouldn’t bother. GNOME is also the
default, but I cannot readily recall ever having it running on
my Debian installs.
By the way: didn't
On 28.11.2014 19:09, Christoph Anton Mitterer wrote:
For many things, CGI is actually the only way to run them securely,
since it's the only way to run foreign processes in a container
environment (chroots, etc.) or with user privilege separation.
Not entirely true. About a decade ago, I've
On 02.12.2014 06:01, Paul Wise wrote:
gnome depends on apache ?
gnome-user-share uses apache2 to share files on the local network via WebDAV.
Is this an purely optional program, or does gnome itself depend on it ?
seriously ?
Sharing files with other computers on the local network seems
On 04.12.2014 22:23, Christoph Anton Mitterer wrote:
Apart from that, when you speak of non-trivial quantities - I'd
probably say that running gazillion websites from different entities on
one host is generally a really bad idea.
No, it's not, and it's pretty cheap, if done right.
Several
On 25.11.2014 18:30, Stephen Gran wrote:
Excellent. I'm sure that if they can create a deb, they can install
sysvinit, or runit, or some BSD, or whatever else they want. A default
is only a default, after all.
Just curious about the term default:
Can I still install a system w/o systemd
On 27.11.2014 00:29, Noel Torres wrote:
manpower required to maintain a distribution with more than one init
system widey installed, manpower to perform the required changes to
support multiple init systems in Jessie, centered about the most
important question: our users.
Just curious: how
On 27.11.2014 11:18, Martin Steigerwald wrote:
Desktops (not only GNOME) use a very tiny bit of systemd, interfaces
that could be provided elsewhere. The real purpose of systemd is to
provide a modern init system.
I still wonder why there are provided within systemd then.
Same for me. If
On 27.11.2014 11:53, Matthias Urlichs wrote:
Yes, the logind-related parte _could_ be provided elsewhere, but part of
the features logind needs is already implemented in systemd.
Can you understand, that this method is exactly one of the major reason
why many people dont like the systemd
On 27.11.2014 02:18, Josh Triplett wrote:
gnome Depends: gnome-core, which Depends: gnome-user-share, which
Depends: apache2-bin (or apache2.2-bin in stable, which is a
transitional package depending on apache2-bin in unstable).
gnome depends on apache ?
seriously ?
cu
--
Enrico Weigelt,
On 22.11.2014 02:13, Troy Benjegerdes wrote:
Someone will find a hole in something, and there will be fire when sysadmins
have to upgrade in the middle of the night and now are running systemd
instead of what they are used to.
Well, in that case, I'd say a rain of fire isn't entirely what's
70 matches
Mail list logo
