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
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
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: 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: 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 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
smtp blacklisting [WAS: Re: Devuan]
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: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
Re: Devuan
On 02.12.2014 08:27, Martin Pitt wrote: > Enrico Weigelt, metux IT consult [2014-12-02 7:55 +0100]: >> By the way: is it then be mandatory ? > > Yes, it will be. As Scott and others have already pointed out, Ubuntu > never offered a choice of init systems, and doesn't plan on doing so. Okay, thanks for the clear statement. So we don't have to bother w/ Ubuntu anymore at all (besides migrating away), we can concentrate on Devuan. (eg. getting rid of polkit etc). The only blocker right now is Zimbra, which is currently not packaged for Debian yet - but as we'll move to OpenZimbra anyways once it's stable, we won't have any need for Ubuntu anymore. 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 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
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: redmine packaging
> Would be cool if ChiliProject could be packaged too (a Redmine fork). > https://www.chiliproject.org/ Well, that project seems to be much more active, so it _maybe_ could be a replacement for current redmine-core. As we're still at 1.4.4 base and now attempting to upgrade to 2.x, chiliproject might be an alternative candidate. Does anybody here has some experience in redmine->chilli migration ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Mobile: +49 (151) 27565287 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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: non-free software in Ubuntu
Hi, > It's best for these packages to be self-hosted on the web-servers you > control. Of course. we already have that: http://packages.vnc.biz/openerp-ubuntu-precise/ But we'd like to feed back to the community as much as possible. > Note that OpenERP installations & paths vary widely between > installations and one deb/rpm will not fit all. We're following FHS and the Debian/Ubuntu scheme (eg. openerp main tree is at /usr/share/pyshared/openerp/). Addons are splitted into separate packages, with canonical package names. That should be pretty straighforward, and I dont see any technical reason why distro-packaged installations should differ from that on other distros. (manual deployment is a completely different issue) cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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: non-free software in Ubuntu
Hi, > As you probably already know, the AGPL version OpenERP is already in > universe, what's the difference between the free version and the > non-free > version? Are there any benefits to the user in having it there or > otherwise, why would you want it there? Just for clarification: I'm talking about specific modules developed on our side, not OpenERP in general. By the way: our OpenERP aptrepo is now making good progress towards an usable state. Feel free to play around with it ;-) http://packages.vnc.biz/openerp-ubuntu-precise/ cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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: non-free software in Ubuntu
> > Could those packages be candidates for the multiverse section ? > > Yes, but IANAL. Your license needs to allow distribution. Of course. We havent't decided on the exact terms yet. Our goal is: a) allow distros to redistribute the binary packages AS-IS (for now just .deb's, maybe .rpm and other will follow) b) deny integrators to repackage and essentially sell it as their own, (these parties should have explicit contracts with us) c) free-of-charge for small companies, personal or educational use This only affects a few packages that contain branch specific business logic (it's not so much about the actual code, but the business process knowledge behind), which are developed on specific demands from our partners. General-purpose helper modules etc will be FOSS anyways. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
non-free software in Ubuntu
Hi folks, we're currently thinking about publishing our proprietary OpenERP packages under an free-of-charge license for parties that aren't in our business scope: personal or educational use, small companies (not yet defined how small exactly ;-o), etc. Could those packages be candidates for the multiverse section ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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: chromium memory conumption on x86_64
Hi, > I think the former invalidates the latter and makes all arguments > moot. Even more so now that it seems that you have not tested on the > latest releases in any of the repos to confirm if this is still the > case and now that you have come out with that you can't remember but > don't seem to be trying to just gather information on the latest > release. Correct me if I'm wrong but to me your statement implies > exactly as I stated. Well, yes, right now, I've got no real evidence, just a feeling. I had put the issue aside for too long, so I cannot reconstruct the exact situation for some valid comparison. OTOH, my question was just about whether somebody else also noticed this and might have some more information. ATM, I'm fetching the source repo (several GB still take a while) and then I'll dig deeper into it and try to build directly from upstream and create a new package (I'll start afresh, not reusing the current debsrc, as the current approach with doesnt look practical to me). Let's see when I've got something usable ... cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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: chromium memory conumption on x86_64
Hi, > You have not mentioned what build of chromium you ran on Gentoo Honestly, I dont know anymore, as it's now several month ago (I guess it was somewhere in spring / early summer). But: I've noticed that problem almost immediately after switching to Ubuntu, and I've got the feeling that it gets slightly worse over time. Perhaps I'll find some spare time to repackage everything from current upstream. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
chromium memory conumption on x86_64
Hi folks, some time ago, when I've moved my notebook (4GB RAM), from 32bit gentoo to 64bit ubuntu, I've noticed a big increase in memory consumption. I haven't had a chance for deeper look at the code, but my suspicion is that a lot of objects (eg. vectors, etc) are doubled in size. Is anyone else already working on this topic ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
possible bug in git-pbuilder + friends ?
Hi folks, just tried to create a new cowbuilder chroot image w/ `git-pbuilder create --distribution precise`, and it failed because it could not find the cowdancer. Seems I need to pass additional COMPONENTS= parameter. But shouldn't this be done automatically ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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: pbuilder create crashes
> Yes, /usr/share/distro-info/ubuntu.csv is outdated. Please make sure > that you have updated distro-info-data to version 0.8ubuntu0.2 from > precise-updates. Ah, already suspected that. His system didnt have them source.list, while my systems all have it. thx -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
pbuilder create crashes
Hi folks, my collegues have problems creating pbuilder chroot images for precise (on recent prcesise), while everything' running fine at my site: erp@erp-virtual-machine:~/workspace_build/openerp-main$ pbuilder-dist precise create Traceback (most recent call last): File "/usr/bin/pbuilder-dist", line 462, in main() File "/usr/bin/pbuilder-dist", line 456, in main sys.exit(subprocess.call(app.get_command(args))) File "/usr/bin/pbuilder-dist", line 286, in get_command if self.target_distro == UbuntuDistroInfo().devel(): File "/usr/lib/python2.7/dist-packages/distro_info.py", line 92, in devel raise DistroDataOutdated() distro_info.DistroDataOutdated: Distribution data outdated. My research showed up that some people already had such problems while trying to create quantal images. I'd suspect /usr/share/distro-info/ubuntu.csv wasn't up to date yet. Any idea what could be wrong ? thx -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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 -> install from uncompressed trees ?
Hi folks, for my regular pbuilder runs, I'd like to keep the dependenc packages in uncompressed form and instead of always uncompressing .de file each time, just hardlink the files into the chroot tree. Is such an aproach already possible w/ current dpkg ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
pbuilder + directly building from git
Hi folks, is there already some way for building packages (w/ pbuilder) directly from a git ref, w/o creating any tarballs, diffs, et ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
pbuilder performance
Hi folks, I'm regularily building quite huge packages with large dependencies, eg. libreoffice, using git-buildpackage. And it's really slow. Is there any way for speeding up the builds ? I'm already using cowbuilder, but it only seems to be able to use an existing base system tree, while still needs installing all the dependencies one by one. Is it possible to do some similar logic with dependencies ? (something like an tweaked dpkg that fetches everything from per-package directories instead *.dpkg files and just hardlink instead of copying) ? cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
package dependencies on versions
Hi folks, I could use some little assistance in packaging and version dependencies. My remdine source package creates a bunch of binary packages: * 'redmine': metapackage pulling in redmine-core and one redmine-pgsql, redmine-mysql or redmine-sql * 'redmine-core': the actual redmine code * 'redmine-mysql' / 'redmine-pgsql' / 'redmine-sqlite': metapackage pulling in the database backend dependencies Now, I'd like to make sure, that all of these packages are always on the same version by dependencies. How can I do that ? Source repo: https://github.com/vnc-biz/redmine-core/tree/precise/master-1.4.4 thx -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
redmine packaging
Hi, we have packaged redmine (1.4.* line) and lots of plugins for Ubuntu, and contihously improving it. (will mirror everything to github in next days) Anybody interested in getting it into Ubuntu mainline ? Our dep repo: http://packages.vnc.biz/vnc-ubuntu-precise/ Experimental repo: http://packages.vnc.biz/redmine-testing/ cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
Specialized kernel/base system for VM's/VE's
Hi folks, is anyone currently working on optimized/minimized kernel and base packages for VM's ? My goal is having a really minimized base system for VMs and VEs, which don't have anything that's really needed there (eg. VEs dont need all the kernel related stuff, VMs just only those parts which are really required for running in an virtio-based environment, etc, etc). cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
