Re: Proposal: Let's drop i386
On 12.05.2018 18:40, Tobin Davis wrote: I work with FPGA accelerators, both at Intel and for a startup. A majority of the tools we use (Quartus, Modelsim in particular) only support 32bit (and very old at that). The companies developing these tools are all too happy to ONLY support Redhat Enterprise 6 (and barely RHEL 7), and so far refuse to budge. There're many more of those examples out there in the wild. Sad enough that we depend on such commercial crap that's even hard to deploy (several weeks ago I had the unpleasant job of building fully automatic deployment - burned quite some time to figure out a proper way, write expect scripts, etc) - but the dependencies to 32bit libs (even though it is supposed to run on 64bit - the installer is 64bit!), makes that even much uglier. A wide variety of our customer base prefer Ubuntu and have their infrastructure geared towards this, so I have had to be very creative in getting everything working for them (adding 32bit support, swapping out the linker that ships with these tools, etc). If Ubuntu drops i386 all together, this can have a major impact on the whole FPGAaaS model. Let's share our stuff. I still got some ansible scripts flying around. Outside of that, I also have a large collection of older software (games mainly) that are still fun, but also 32bit only. Dropping i386 would render them entirely useless, or force people away from Ubuntu. Yep. For compatibility, we really need 32bit libs. But I can live w/ a small chroot system for that. OTOH, I'm running several 32bit systems on 64bit kernels, some for historical reasons, but also saving resources. This leaves image and installer testing. My vote is to drop the images (except core as it is very useful for embedded projects which Intel still sells 32bit only chips for IoT. This at least keeps Ubuntu as a prime development environment for these devices. Please also keep a minimal installer. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [14.04] nVidia GeForce 1080TI
On 01.06.2017 08:45, Sebastian Busse wrote: > We are thinking of upgrading to current nVidia graphics cards. As far as > I can see, the GeForce 1080 is supported since 367.27 while the GeForce > 1080 TI is supported since 381.09. Considering the hostilty of that company against the FOSS community, and adding their various frauds (eg. less vram than officially sold) I would never ever buy anything from them. I've got no idea how well nouveau works nowadays, but their proprietary crap always had been practically unusable since back in the 90th. --mtx -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Packaging nodejs-7.9
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 parts yet) there ? Meanwhile I've also added some update-alternatives support. (yet have to add version into package name). But this will conflict w/ current versions, as they directly install /usr/bin/nodejs. Can we make a minor update of 0.10.* for update-alternatives ? > Are you talking about installing modules depending on their > compatibility with node engines (as found in package.json) ? Actually, not sure whether that's really required. Are there any known (already packaged) modules that break w/ newer nodejs ? If not, I guess, just adding depend son newer engines where needed should be enough. --mtx -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Packaging nodejs-7.9
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 who already done this ? Or anything I should consider ? My current plan is: * install in similar way as jvm (/usr/lib/nodejs/nodejs-$version) * for now I'll just directly symlink - update-alternatives support comes in a later step (or maybe someone here likes to help ?) * the actual nodejs package will be named "nodejs-$version", the symlinks in package "nodejs". The tricky part will be a safe upgrade path from current 0.10 and npm's dependencies. What do you folks think about that ? --mtx -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: backports for trusty
On 14.04.2017 08:31, Ralf Mardorf wrote: > I'm neither an Ubuntu developer, nor do I maintains some backports. > However, a lot of backports easily could be counter-productive regarding > the Long Term Support's policy. Why so ? > Consider to provide your packages by a PPA. I'm already trying this, but somethings not right yet. What I've done so far: * created a ppa: https://launchpad.net/~metux/+archive/ubuntu/cairo-drm * created a project w/ git repo and my uploaded (debianized) tree https://launchpad.net/cairo-drm https://code.launchpad.net/~metux/cairo-drm/+git/cairo-drm --> git upload seems to be fine (git ls-remote showed it up), but the branch doesn't appear on the lp web frontend * created a build receipe: https://code.launchpad.net/~metux/+recipe/trusty * build ran but failed: https://launchpadlibrarian.net/315946016/buildlog.txt.gz >> subprocess.CalledProcessError: Command '['git', '-C', '/home/buildd/build-RECIPEBRANCHBUILD-1353331/chroot-autobuild/home/buildd/work/tree/recipe', 'fetch', 'lp:cairo-drm', 'HEAD:refs/remotes/source/HEAD', 'refs/heads/*:refs/remotes/source/*']' returned non-zero exit status 128 That looks a bit strange to me - it should just clone and checkout refs/branches/trusty/master, and not care about the symbolic ref 'HEAD'. --mtx -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
backports for trusty
Hi folks, anybody around here who also maintains some backports for trusty ? I've collected several packages which I maintain locally (eg. right now I'm packaging recent cairo w/ drm patches applied) and I'd like to put that into bigger community. --mtx -- mit freundlichen Grüßen -- Enrico, Sohn von Wilfried, a.d.F. Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
dpkg packaging problems
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 ? See: https://github.com/metux/fskit/tree/jessie/master https://github.com/metux/fskit/tree/trusty/master the build process is driven by: https://github.com/metux/packaging cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: dpkg packaging problems
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 consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The fate of Upstart
On 03.12.2014 23:32, Vittorio wrote: If really you could succeed in getting rid of polkit and dbus, that would be a very good work. I completely agree with you. Polkit has given me a lot of headaches. Well, you're welcomed to join me :) I'll yet have to sort out certain conceptional issues regarding authentication. For now, I'm pretty clear that it will be something 9P and factotum based and shall be compatible with the usual Plan9 ways (so it's also suited for distributed systems). But I haven't sorted out, who exactly will maintain the sessions (and session keys), and how to do service startup and mounting, especially regarding the differences between Linux and Plan9. My current thoughts go like this: * user services visible to some user can be expected to be posted within some directory in his home directory. perhaps this will directory will be configurable via env (to support multiple sessions w/o separate namespaces) * system services are posted in some global (world readable dir) * maybe: those which are accessible to some user are also symlinked to his home / session dir * traditional group-based access controls can be used here * for finer access control, services can be authenticated via factotum (user and host factotum) * an separate control agent (maybe acting on user login, eg. via pam, etc) generates keys for system services and adds them to host factotum, so system services can be accessed by them * users that should be allowed to access them also get the corresponding keys into their user / session factotum, so it can authenticate * in case we really need a hard separation between sessions (so session privileges cannot be stole by the same user, into other sessions), we can run the session factotums under a different uid and configure it to never tell secrets uhm, I might expect too much Plan9 knowledge here ... sorry for that ;-o maybe we should get into deeper discussion on the 9fans list. cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Devuan
On 02.12.2014 11:24, Martin Pitt wrote: Hi folks, Indeed that's another example where Debian offers a choice but Ubuntu doesn't -- we examine the alternatives, pick one, and support nothing else. (cf. combinatorial explosion and efficient maintenance and support). by the way: could anybody please enlighten me why you folks are rolling an own distro at all ? I'd guess it has something to do with LTS ... right ? But wouldn't it be more efficient to just pick stable Debian releases and do the LTS there ? Am I missing some vital aspect ? (Technical problems, not I don't like it :-) ). Well, the I dont like it aspect shouldn't be underestimated. I regularily observed migration projects failing, not for technical reasons, but users simply not liking the new systems (sometimes even pretty trivial things like menus looking different). This also relates to usability, which is _very_ subjective. cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
smtp blacklisting [WAS: Re: Devuan]
big_snip / Some time ago, I observed even major ISPs being blacklisted in some spamfilter appliance network (just forgot its name ;-o), where I'm *pretty* sure that they're not spamming (I know these guys personally, and they're quite professional, compared to other companies of this size) - and there was no way of finding out why they have been blacklisted. Oh, did you say marketing server ? Well, if you're sending much newsletters etc, that could be the reason - some operators are a bit too overcautious and block anybody who's traffic exceeds some (pretty low) threshold - these also usually hit hi traffic maillists like LKML. cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Devuan
On 02.12.2014 11:11, Stephen P. Villano wrote: Personally, I prefer SElinux to polkit, but such isn't part of the Dont they play in entirely different areas ? I just started to care about polkit, when began doing weird things and causing network-manager to break (more precise: the gnome frontend suddenly wasn't authorized anymore). So I digged a bit deeper, wondering why the usual group memberships didn't work anymore (had to rewrite several polkit configs to make it work again). At that point it was clear to me that it's a pretty useless invention, just caused by the fact that some folks, for dubious reasons, prefer doing everything via RPC on an broadcast channel (dbus) and then have the problem of selective access control - things which old-fashnioned Unix guys like me always did via direct links and filesystem permissions. One of my side projects now is getting rid of polkit/dbus at all, replace it by a clean plan9-alike approach, of course using factotum for authentication. I used to run SuSE until Novell screwed it up. They've been screwing up even before Novell. 4.4.1 was the best release they ever had - after that it just went worse and worse. All the good people had been running away (I just happen to know some of them personally, and know some of their reasons) - the novell merge was more a logical consequence of that path :p cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The fate of Upstart
On 29.11.2014 22:31, I.E.G. wrote: Hi, I was a little surprised to see the ...has been converted to an upstart job message some time ago in response to a ~$ /etc/init.d/ stop/start/restart/foo . I tried the ~$ service stop/start/restart/foo and it either didn't work or produced the same ...has been converted to an upstart job. Yeah, had the same problems... I'll just offer one example of what I don't want to see . A deployment or migration such as the the protracted abortion that was PulseAudio . I still have several hardware instances that never did (and I suspect never will) tolerate PulseAudio. For me, it at least works w/ my hardware, but far from rock-stable. I regularily have to kill and restart it. In fact, I never really understood why it's necessary at all. Okay, moving more stuff into userland has some benefits (eg. adding virtual devices running as separate servers, etc) - but then it should be done more consequently, like Plan9 does. Maybe, if i've someday got enough spare time, I'll fork it and rebuild it to an plan9'ish system-wide service. Then it would make sense to move all audio applications to that service only (dropping all native alsa support). But for now, I'm still too occupied with other things. For now I'm more concerned with getting rid of dbus/polkit. I even had PA/Devl tell me to upgrade my month old hardware in order to make it work (a long and only slightly humorous story I'll spare you ) . Well, the usual Lennartists behaviour ... cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Devuan
On 01.12.2014 19:15, Tom H wrote: Especially after deciding a few months ago to switch to systemd! By the way: is it then be mandatory ? Because, for me, that would mean leaving Ubuntu, definitively. I'm currently exploring ways for getting rid of polkit, and also trimming down in other places (eg. get rid of cups stuff). In case of Ubuntu will force me to use systemd, I wont invest any resources here (also never again rollout Ubuntu for my customers), instead fully concentrate on Devuan. cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The fate of Upstart
On 28.11.2014 13:41, Ben Tinner wrote: Hi, Recently, the developers of Ubuntu have decided to migrate the init system from upstart to systemd. So, I would like to find out what will happen to upstart after Ubuntu complete its transition to systemd. That might also depend on which init systems the debianfork project is going to support upstart (besides openrc and sysv init), and how many Ubuntu folks move over to debianfork. I, personally, *will* move over, as soon as systemd becomes mandatory (if there wasn't debianfork, it would be Gentoo). The already mandatory Lennartware already caused more than enough pain. Actually, I'm preparing a fork of NetworkManager, getting rid of all the dbus and polkit crap, which causes more problems than it solves. Haven't decided yet, whether the interface will be fuse or 9P (both have their pros and cons), but definitively will be a data driven filesystem-based approach. In the next round, I'll heavily trim down network-manager-gnome to get rid of all the unnecessary stuff (eg. I dont use BT, and i dont want it. period.) cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The fate of Upstart
On 29.11.2014 00:39, Dimitri John Ledkov wrote: Hi, Similarly, 16.04 LTS is not yet planned, thus i'm not sure whether it will or won't ship upstart. If it does, it will be another 5 years from then, or 2021. I really hope, it will continue to ship upstart and doesn't push towards systemd than it already does (eg. could anybody perhaps explain, what I really need that logind for ?). Otherwise people will move away (and never come back). cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
