Re: F27 System Wide Change: Graphical Applications as Flatpaks
On 14.07.2017 19:36, Rahul Sundaram wrote: > On Fri, Jul 14, 2017 at 1:27 PM Matthew Miller 05:05:23PM +, Debarshi Ray wrote: > >> >>> How about reliable online updates of running applications as a >>> benefit? >> >> AND the ability to roll back, to choose beta or stable streams, etc. >> > > These are reasonably good advantages but if there isn't a seamless > transition between them, it induces a lot of pain. For instance, dnf > cannot install flatpak apps currently and I can't use kickstart to automate > installation in the same way etc. Arguably dnf should never support flatpaks as that is not its job. Instead there should probably a tool (called "app"?) that sits on top of the lower-level dnf and flatpak tools that abstracts the idea of installing software away from the delivery mechanism (rpm, flatpak). "app install blender" would check both flatpak and rpm repositories and install the latest version it finds (by using the dnf and flatpak commands in the background). Regards, Dennis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: nodejs/npm coupling
On 21.12.2015 08:23, Tom Hughes wrote: > On 21/12/15 01:36, Dennis Jacobfeuerborn wrote: > >> I'm currently looking into using npm v3 with nodejs v4. The problem I've >> run into is that npm is apparently part of the main nodejs package which >> effectively joins them at the hip for no apparent good reason. >> >> Upstream ships npm with nodejs because they need npm to bootstrap the >> environment and cannot rely on a higher level dependency mechanism >> because there is none. As a result they encourage to simply install a >> new npm by replacing the old one. >> >> In an rpm based environment however this does not work because the files >> are owned by the rpm and any reinstall or update will overwrite these >> files again with the ones from the rpm. On the other hand rpm has its >> own dependency resolution so the bootstrapping issue doesn't exists. >> >> As a result I would like to see npm separated from nodejs so that >> alternative versions can be installed in the same way that some packages >> require a mail transfer agent but not a specific one. >> For nodejs this would mean that by default the npm version that is now >> bundled gets pulled in by default but that the user has the option to >> specify an explicit package (like npm v3) that can satisfy the npm >> dependency. > > I'm not really sure what exactly it is you're asking here... > > Who exactly is it that you want to "separate" npm from nodejs? Fedora > already ignores the npm that is bundled with nodejs and instead packages > it by packaging all the modules that make up npm directly from their own > sources, with a seprate srpm for each module. > > As far as nodejs 4 / npm 3 goes we (the Node.js SIG referred to in > Peter's answer) are already working on it - we have nodejs 4.2.3 built > in a side tag and are working on the npm stack currently. Current > working status of the npm dependency stack update is at: > > https://fedoraproject.org/wiki/Node.js/npm_update_status > > But as Peter said, the nodejs list is probably the best place to ask any > questions. It seems I have confused the nodejs package of Fedora with the one from Nodesource which actually puts npm right into the core nodejs rpm itself. Looking at the Koji builds I can see that npm isn't bundled in the core rpm and since there now exists an official LTS release of nodejs that should also deal with the fact that Fedora version was quite old which was the reason for installing the Nodesource package in the first place. Sorry for the confusion. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
nodejs/npm coupling
Hi, I'm currently looking into using npm v3 with nodejs v4. The problem I've run into is that npm is apparently part of the main nodejs package which effectively joins them at the hip for no apparent good reason. Upstream ships npm with nodejs because they need npm to bootstrap the environment and cannot rely on a higher level dependency mechanism because there is none. As a result they encourage to simply install a new npm by replacing the old one. In an rpm based environment however this does not work because the files are owned by the rpm and any reinstall or update will overwrite these files again with the ones from the rpm. On the other hand rpm has its own dependency resolution so the bootstrapping issue doesn't exists. As a result I would like to see npm separated from nodejs so that alternative versions can be installed in the same way that some packages require a mail transfer agent but not a specific one. For nodejs this would mean that by default the npm version that is now bundled gets pulled in by default but that the user has the option to specify an explicit package (like npm v3) that can satisfy the npm dependency. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
rpmbuilding golang applications
Hi,
I'm currently looking into creating an RPM for influxdb 0.9 but have run
into a problem when it comes to the %install step in the spec file.
I created RPMs for all dependencies which are installed at
/usr/share/gocode/src and these are found and influxdb builds fine
however once the "go install ./..." line is reached in the spec file I
get permission denied errors.
/home/dennis/rpmbuild/BUILD/influxdb-0.9.4.2
++ pwd
+ export
GOPATH=/home/dennis/rpmbuild/BUILD/influxdb-0.9.4.2/_build:/usr/share/gocode
+
GOPATH=/home/dennis/rpmbuild/BUILD/influxdb-0.9.4.2/_build:/usr/share/gocode
+ pushd ./_build/src/github.com/influxdb/influxdb
~/rpmbuild/BUILD/influxdb-0.9.4.2/_build/src/github.com/influxdb/influxdb
~/rpmbuild/BUILD/influxdb-0.9.4.2
+ go install ./...
go install golang.org/x/crypto/blowfish: mkdir /usr/share/gocode/pkg:
permission denied
go install gopkg.in/fatih/pool.v2: mkdir /usr/share/gocode/pkg:
permission denied
go install github.com/peterh/liner: mkdir /usr/share/gocode/pkg:
permission denied
go install github.com/armon/go-metrics: mkdir /usr/share/gocode/pkg:
permission denied
go install github.com/boltdb/bolt: mkdir /usr/share/gocode/pkg:
permission denied
go install github.com/rakyll/statik/fs: mkdir /usr/share/gocode/pkg:
permission denied
go install github.com/kimor79/gollectd: mkdir /usr/share/gocode/pkg:
permission denied
go install collectd.org/cdtime: mkdir /usr/share/gocode/pkg: permission
denied
go install github.com/golang/snappy: mkdir /usr/share/gocode/pkg:
permission denied
go install github.com/bmizerany/pat: mkdir /usr/share/gocode/pkg:
permission denied
go install github.com/BurntSushi/toml: mkdir /usr/share/gocode/pkg:
permission denied
go install github.com/hashicorp/go-msgpack/codec: mkdir
/usr/share/gocode/pkg: permission denied
go install github.com/gogo/protobuf/proto: mkdir /usr/share/gocode/pkg:
permission denied
error: Bad exit status from /var/tmp/rpm-tmp.YSKjXF (%install)
Notice how I set a special GOPATH with the intention that "go install"
then installs the binaries into that hierachy. As you can see though
that doesn't work and instead go tries to install the binaries for the
dependencies (!) to /usr/share/gocode/pkg instead of the first path in
GOPATH.
My theory is that since the sources for these dependencies are located
in /usr/share/gocode/src go ignores the GOPATH completely and simply
assumes that the corresponding binaries should be generated basically in
../pkg relative to the src directory.
My question is how am I to handle this?
At first I thought maybe I need to do a "go install" for each dependency
and ship the binaries in /usr/share/gocode/pkg for each RPM but
https://fedoraproject.org/wiki/PackagingDrafts/Go has this to say:
"The standard golang compiler only produces static libraries. There is
little value in shipping these prebuilt, especially since these
libraries are very specifically tied to the exact minor release of the
golang compiler. Instead, each library package should consist of a
-devel subpackage which installs .go source code to
/usr/share/gocode/src, under the appropriate import path.
Binary packages which build against this source will set $GOPATH to
'%{_datadir}/gocode' ( or '%{gopath}' in golang > 1.2.1-1)"
So apparently I'm not supposed to ship these binaries but also
apparently go insists installing binaries into a system path which is
obviously a no-go for rpm builds.
What is the proper way to deal with this?
Regards,
Dennis
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
On 12.06.2015 15:25, Radek Holy wrote: - Original Message - From: Kalev Lember kalevlem...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, June 12, 2015 3:09:50 PM Subject: Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides On 06/12/2015 10:28 AM, Radek Holy wrote: If a package Requires: foo and both bar and barbaz Provides: foo, they are handled as being equally suitable. DNF/libsolv is not going to prefer packages with shorter names. Yes, very much agreed here. Please don't add the yum shortest name hack to DNF. This and the rest of the depsolving quirks that choose one provider over the other depending on what else happens to be installed, have made my life quite hard over the years :) Let me try to elaborate. The issue I've had with yum's virtual provider depsolving is that there is currently no way to set a default. A default where it would by default install the package that the maintainer has chosen, but would also allow swapping it out if the user needs to. An example here would be an app that has two backends. One of those backends would be the preferred backend and other one experimantel, and maybe a third one that is for a special use case backend that isn't interesting for the general audience. The way to express this with rpm deps would be to have a virtual provide that all of the backends packages provide, so that the user could choose which one to install. An example here would be PackageKit with different backends. It used to have 2 backends, PackageKit-hawkey and PackageKit-yum (we dropped the different backends from Fedora now, but it was a valid issue in last release). Both of them would have a common virtual provide that PackageKit itself would depend on, to make sure at least one of the backends is installed. With the yum system, yum would pretty much always just pick the shortest name. It _happened_ to be PackageKit-yum, but that was totally an accident. And it made it impossible to change the default without renaming the packages - so in a new release that was supposed to use hawkey, we'd have very little options besides renaming PackageKit-hawkey to PackageKit-h for example to make sure it wins over -yum. What I feel would be a good solution to the problem above would be to have a way to specify the default. I believe this problem is already solved in apt-get with a very nice syntax: the OR syntax: Requires: PackageKit-hawkey | PackageKit-backend ... where PackageKit-backend is a virtual provide that both of the backends satisfy. With the requires above, any of the two would solve the requires, but dnf could use the information to choose the first one as the default when it doesn't have any of the backends already installed. -- Kalev I'd just add that there are multiple sources of preferences. The package maintainer may prefer something else than the user and both of them may prefer something else than the distribution. E.g. it was said to me the Fedora prefers mariadb over community-mysql. This cannot be solved on the package level. mariadb maintainers use one of these YUM hacks to achieve their goal but we'd like to find a correct solution (or make the hack an official Fedora guideline). The preferences of the package maintainer and the distribution is really a policy issue and can't be solved on the technical level. The package maintainer should select his preference and if the distribution has other ideas then they can contact the maintainer and hash out a solution. What does need to be solved technically though is how that preference is expressed in the package and I'm wondering if the Recommends/Suggests mechanism can be used for this. The package adds a Require for the virtual provide but also a Suggest for one explicit package that fulfills that dependency. The dependency to install is then selected as follows: If a package that satisfies the virtual provide is already installed then everything is ok so just install the package. If a package that satisfies the virtual provide is installed together with the dependent package then use that to satisfy the dependency and everything is fine as well. Lastly if no package from the system or the command line satisfies the virtual requirement chose the one that is suggested by the dependent package. That way the default would be explicitly expressed by the maintainer/distribution but the user can easily override this by already having a fitting package installed or by providing one explicitly on the command line during installation. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libblockdev reaches the 1.0 milestone!
On 21.05.2015 20:08, Vratislav Podzimek wrote: A year ago, I started working on a new storage library for low-level operations with various types of block devices -- *libblockdev*. Today, I'm happy to announce that the library reached the **1.0** milestone which means that it covers all the functionality that has been stated in the initial goals and it's going to keep the API stable. Read the blog post I wrote for more information: http://blog-vpodzime.rhcloud.com/?p=61 This looks very interesting. I don't see any function to deal with plain old block devices though just LVM, MD Raid, etc. Is this correct or am I missing something? Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: should we consider making CoDel the default to combat bufferbloat?
On 28.03.2015 04:42, Zbigniew Jędrzejewski-Szmek wrote: On Sat, Mar 28, 2015 at 12:34:35AM +, Pádraig Brady wrote: Following on from http://thread.gmane.org/gmane.linux.redhat.fedora.kernel/5549 Has there been any more consideration for enabling this by default? It's the default in F22+: /usr/lib/sysctl.d/50-default.conf:net.core.default_qdisc = fq_codel Are there any performance comparisons out there for fq_codel compared to let's say mq? Does fq_codel utilize multiple cores/nic-queues effectively? Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF: why does it refresh metadata all the time
On 20.06.2014 14:11, Reindl Harald wrote: Am 20.06.2014 14:04, schrieb Tim Lauridsen: On Thu, Jun 19, 2014 at 8:47 PM, Dennis Gilmore den...@ausil.us mailto:den...@ausil.us wrote: In testing dnf on rawhide I nearly always do dnf clean metadata dnf update purely because I found most of the time dnfs metadata was out of date. To me dnf fetching the metadata behind the scenes just doesn't work right. But I'm not sure that me or rawhide fits into the experience dnf is trying to give. Dennis Dnf-0.5.2 has a --refresh option, there will a check if the repo metadata is newer than the cached one. so. dnf update --refresh will check and update metadata if needed *that* would be a useful default instead background-refreshes I think these are two separate issues. Independent of the background refreshes dnf should always check if its current view of the world is up-to-date (that is the data in its cache is current). This can be fairly important when it comes to security issues. When a fatal exploit is fixed in a package you don't want dnf to say that there are not updates available when this is in fact not true. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On 23.03.2014 03:45, Kevin Kofler wrote: Dennis Jacobfeuerborn wrote: One example is the policy that patches for packages should first be submitted and accepted upstream before they make it into Fedora. That policy is only a non-normative guideline (not part of any enforced Fedora Guidelines or Policies). The decision is purely up to the maintainer(s) of the affected package. This works great because that way you can ensure that once features are added in Fedora it is unlikely that they have to be removed later again because they are rejected upstream. It's terrible though if you want to live on the bleeding edge. Take for example the networking features of OpenStack that required kernel changes that weren't yet committed upstream or the fact that Docker required AUFS for a long time. In both cases Fedora was a terrible platform to develop these technologies because of its conservative stance. In both of these examples, the affected package is the kernel. Blame the kernel maintainers for their strict policies. Those are not Fedora policies. In the AUFS case, there's additionally the problem that FESCo decided a ban on separately-packaged kernel modules as a strictly enforced Fedora policy. At the time this was decided, the understanding was that it should be possible to get needed modules into the kernel package instead. However, the kernel maintainers simply vetoed ALL non-upstream kernel modules that came up do far. They do not build even the modules in the upstream staging tree! The ban on separate kmod-* packages really needs to be repealed (for modules with GPLv2-compatible licensing), and the current RPM Fusion kmod v2 system picked up as a Fedora policy. We allow separate plugin packages for any other application with a plugin system; I do not see any reason why the kernel has to be special there. But not every change can be implemented purely as a module. This is precisely why I think the one package to rule them all policy should be changed for Fedora products. That way you can have the current kernel package policies for the regular kernel that all products by default use but the products that have specific needs can deliver their own kernel package with the required patches. As a result these products obviously also carry the responsibility for any problems that result from these changes. That would allow products to act as incubators for new ideas and technologies and when these things have matured may everntually be folded into the core of Fedora. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On 21.03.2014 13:24, Christian Schaller wrote: - Original Message - From: Matthew Miller mat...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 21, 2014 12:59:01 PM Subject: Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next On Fri, Mar 21, 2014 at 10:28:26AM +0100, Marcela Mašláňová wrote: I agree with Jaroslav. I was looking forward to have a fourth product to those three. KDE can help define what is needed for new product, what must be done by all teams, how much work it will be ... I guess we should speak more about addition of new product and don't kill the idea at the start. Like I said, I'm skeptical, but listening. :) While opinions differ on if we should 'ever' have more than 3 products, personally am very skeptical to the idea of product proliferation, I think that as a minimum common sense measure we should not even consider any further products before we have the current 3 products released and our infrastructure updated to handle them. I think this way of thinking about products is fundamentally wrong headed as that means that products are not independent from each other. As I perceive it one of the biggest problems for Fedora as a development platform for new technologies is that everything is tied to very rigorous guidelines and controls that tend to be fairly conservative. This is great when you care about overall stability and coherence of the platform but terrible if you want to enable people to use Fedora as a platform to spearhead new technologies. One example is the policy that patches for packages should first be submitted and accepted upstream before they make it into Fedora. This works great because that way you can ensure that once features are added in Fedora it is unlikely that they have to be removed later again because they are rejected upstream. It's terrible though if you want to live on the bleeding edge. Take for example the networking features of OpenStack that required kernel changes that weren't yet committed upstream or the fact that Docker required AUFS for a long time. In both cases Fedora was a terrible platform to develop these technologies because of its conservative stance. What I hope will happen with the Productization of Fedora is that these products will be allowed to have a more independent identity and given more leeway to do things different. I will go so far and hope that eventually these products will be allowed to have their own policies regarding packaging and for example be able to ship their own kernel packages likely to be derived from the main kernel but with additional patches as the ones mentioned above. This could be accomplished by making Copr an official Repository that products are allowed to rely on and which could be used to host alternative versions of packages. A product XYZ could have a channel XYZ in Copr and packages that are placed there are preferred over packages with the same name in the traditional repos. Anyway my point is that telling product A that they cannot proceed with their work until product B is released is pretty much the opposite of what you want to do. Instead the message should be: Want to create a new way to manage the update life-cycle of systems (OSTree)? Want to create a new way to manage better application deployment (Docker)? Build a Fedora product as Fedora can provide you with a solid foundation for whatever you are trying to accomplish! Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Announce: fedostree/rpm-ostree v2014.3
On 21.01.2014 08:30, Colin Walters wrote: Hi Dennis, On Tue, 2014-01-21 at 07:40 +0100, Dennis Jacobfeuerborn wrote: Interesting. I've downloaded the VM Image and tried to understand the setup. Some bits are documented here https://people.gnome.org/~walters/ostree/doc/layout.html Apparently there exist sort of two root trees / and /sysroot in the system with some links targeting the /sysroot tree. With OSTree, you boot directly into a chroot - dracut switches root and starts systemd right after mounting the rootfs. See: https://git.gnome.org/browse/ostree/tree/src/switchroot/ostree-prepare-root.c /sysroot is a bind mount to the real root /. What I'm wondering about is that /dev/mapper/fedora-root is mounted several times on /, /var, /usr and /sysroot (twice!) sometimes rw and sometimes ro. /usr is simply a bind mount to itself so it can be mounted read-only. This is important because otherwise one could corrupt the object store in /ostree/repo by mutating the hardlink farm in /usr. Note the /usr here is really /ostree/deploy/fedostree/deploy/checksum.serial/usr as seen from the physical root. /var is a special bind mount to /ostree/deploy/fedostree/var which is shared between each deployment (chroot). The impression I get is that /sysroot is the actual root fs in the image and / the ostree directory at least that's what the links seem to suggest. I still don't understand the mount-voodoo though. Is there some documentation about this available? I'll look at adding more to the gtk-doc, though I suspect I may need to make a separate system administrators new to OSTree document which is a bit distinct from the how to use OSTree underneath your package manager document that the current one is. Thanks for the information. I think I was thrown off by the fact that the root device is mounted in several places with different content but now I realize that's probably because the external path isn't available from inside the jail so mount can only display the device. Previously I've only used bind mounts in a non-chroot context. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Announce: fedostree/rpm-ostree v2014.3
On 21.01.2014 20:07, Richard W.M. Jones wrote: On Tue, Jan 21, 2014 at 07:40:00AM +0100, Dennis Jacobfeuerborn wrote: Interesting. I've downloaded the VM Image and tried to understand the setup. Apparently there exist sort of two root trees / and /sysroot in the system with some links targeting the /sysroot tree. What I'm wondering about is that /dev/mapper/fedora-root is mounted several times on /, /var, /usr and /sysroot (twice!) sometimes rw and sometimes ro. The impression I get is that /sysroot is the actual root fs in the image and / the ostree directory at least that's what the links seem to suggest. I still don't understand the mount-voodoo though. Is there some documentation about this available? Out of interest, did you boot into the alternate tree, ie: bls_import at the boot prompt? (Documented in http://rpm-ostree.cloud.fedoraproject.org/#/installation) Yes, hence the funky directory layout :) Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Announce: fedostree/rpm-ostree v2014.3
On 20.01.2014 19:03, Colin Walters wrote: Hello devel@, I'm excited to announce the first public release (v2014.3) of the fedostree/rpm-ostree project. The web page is here: http://rpm-ostree.cloud.fedoraproject.org/#/ rpm-ostree is a quite new, raw, and also quite unofficial project (the instance above is in the Fedora private scratch cloud). It is suitable for evaluation primarily by engineers who are working on build/packaging/deployment tooling in Fedora, and advanced testers. If you're one of those people, before you read any more, if you have a few minutes, please jump to: http://rpm-ostree.cloud.fedoraproject.org/images/ and start downloading the preconfigured VM. (Or alternatively see http://rpm-ostree.cloud.fedoraproject.org/#/installation for parallel install instructions inside an existing system). I've often struggled with explaining OSTree to people - but for the audience here, I want to emphasize that OSTree is designed to be *complementary* to package systems like rpm/dpkg. While OSTree does take over some roles from RPM such as handling /etc, if you study it carefully, I think you'll come to agree. The overall vision is to change Fedora (and really its prominent downstream) into a less flexible, but more reliable set of products, tested and delivered *much* *much* faster. That's about all for this mail - the Background section of the web page has more. As for what's coming next - I plan to bring gnome-continuous style fast testing to the rpm-ostree codebase too (assuming I get push notification from Koji). For example, test boot both fedostree/20/x86_64/base/minimal, fedostree/20/x86_64/workstation/gnome/core after any package affecting them changes. Then if the tests pass, tag those trees as smoketested, like: fedostree/20/smoketested/x86_64/base/minimal. If you have questions, please follow up here! (There's no mailing list for rpm-ostree at the moment; you can use ostree-l...@gnome.org for questions about the core OSTree model). What I need now is evaluation from some of the stakeholders in various parts of the deployment stack; for example, the changes to the handling of /var in RPM needs discussion. Interesting. I've downloaded the VM Image and tried to understand the setup. Apparently there exist sort of two root trees / and /sysroot in the system with some links targeting the /sysroot tree. What I'm wondering about is that /dev/mapper/fedora-root is mounted several times on /, /var, /usr and /sysroot (twice!) sometimes rw and sometimes ro. The impression I get is that /sysroot is the actual root fs in the image and / the ostree directory at least that's what the links seem to suggest. I still don't understand the mount-voodoo though. Is there some documentation about this available? Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: LVM thinp expectations in anaconda 20
On 27.09.2013 20:59, Alasdair G Kergon wrote: On Fri, Sep 27, 2013 at 11:55:43AM -0600, Chris Murphy wrote: I still can't choose a Desired Capacity that's larger than free space in the VG. Ergo, I can't create a virtual size LV. Is this expected? At this stage, yes. It might change in future, but I think it was felt to be both too much code to change and too much change for users to take on board if it was all changed at once. Wouldn't it make sense to use the thinp code by default even without providing the thin provisioning part in Anaconda? This would at least give you the much improved snapshot support. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dell XPS 13 (Sputnik) no longer working with fedora kernels = 3.10
On 08.09.2013 01:42, Chuck Anderson wrote: On Fri, Sep 06, 2013 at 12:45:03PM +0200, Łukasz Jagiełło wrote: 2013/9/5 Dennis Jacobfeuerborn denni...@conversis.de Working fine here. #v+ [root@p0x ~]# uname -a Linux p0x 3.10.10-200.fc19.x86_64 #1 SMP Thu Aug 29 19:05:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root@p0x ~]# dmidecode | grep Product Name Product Name: Dell System XPS L322X #v- Hm, what Firmware are you running (A07 here) and are you using UEFI? Version: A09 Yes, I'm using UEFI. Check this bug report to see if it applies: https://bugzilla.kernel.org/show_bug.cgi?id=59841 Thanks for the pointer this might indeed be the issue I'm seeing. So I guess I'll have to wait until the patches in there make it into a Fedora 19 Kernel. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Dell XPS 13 (Sputnik) no longer working with fedora kernels = 3.10
Hi, i seems something in Kernel 3.10 broke the intel display driver for the Dell XPS 13 (a.k.a. Sputnik). I filed a bug here: https://bugzilla.redhat.com/show_bug.cgi?id=995782 Sombody commented in the bug that since it's hard to find other reports of this elsewhere this might be related to fedora specific patches to the kernel. I had to fix up my grub config to not always boot the latest kernel to make my system usable again and for now I'm stuck on the last 3.9 kernel because of this. Does anybody have an idea for possible workarounds maybe? Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dell XPS 13 (Sputnik) no longer working with fedora kernels = 3.10
On 05.09.2013 16:32, Łukasz Jagiełło wrote: 2013/9/5 Dennis Jacobfeuerborn denni...@conversis.de mailto:denni...@conversis.de Hi, i seems something in Kernel 3.10 broke the intel display driver for the Dell XPS 13 (a.k.a. Sputnik). I filed a bug here: https://bugzilla.redhat.com/__show_bug.cgi?id=995782 https://bugzilla.redhat.com/show_bug.cgi?id=995782 Sombody commented in the bug that since it's hard to find other reports of this elsewhere this might be related to fedora specific patches to the kernel. I had to fix up my grub config to not always boot the latest kernel to make my system usable again and for now I'm stuck on the last 3.9 kernel because of this. Does anybody have an idea for possible workarounds maybe? Working fine here. #v+ [root@p0x ~]# uname -a Linux p0x 3.10.10-200.fc19.x86_64 #1 SMP Thu Aug 29 19:05:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root@p0x ~]# dmidecode | grep Product Name Product Name: Dell System XPS L322X #v- Hm, what Firmware are you running (A07 here) and are you using UEFI? Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On 27.07.2013 05:07, Chris Murphy wrote: On Jul 26, 2013, at 4:53 PM, Pádraig Brady p...@draigbrady.com wrote: On 07/26/2013 09:13 PM, Miloslav Trmač wrote: Hello all, with thin provisioning available, the total and free space values reported by a filesystem do not necessarily mean that that much space is _actually_ available (the actual backing storage may be smaller, or shared with other filesystems). If your package reports disk space usage to users, and bases this on filesystem free space, please consider whether it might need to take LVM thin provisioning into account. The same applies if your package automatically allocates a certain proportion of the total or available space. A quick way to check whether your package is likely to be affected, is to look for statfs() or statvfs() calls in C, or the equivalent in your higher-level library / programming language. Anything df(1) should do here? Example: Creating a btrfs raid1 volume from two 2TB drives, df shows it as having 4TB available: # parted -l Error: /dev/sdb: unrecognised disk label Model: ATA VBOX HARDDISK (scsi) Disk /dev/sdb: 2199GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: Error: /dev/sdc: unrecognised disk label Model: ATA VBOX HARDDISK (scsi) Disk /dev/sdc: 2199GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: # mkfs.btrfs -d raid1 -m raid1 /dev/sd[bc] WARNING! - Btrfs v0.20-rc1 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using adding device /dev/sdc id 2 fs created label (null) on /dev/sdb nodesize 4096 leafsize 4096 sectorsize 4096 size 4.00TB Btrfs v0.20-rc1 # mount /dev/sdb /mnt # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda179G 4.2G 71G 6% / devtmpfs1.5G 0 1.5G 0% /dev tmpfs 1.5G 0 1.5G 0% /dev/shm tmpfs 1.5G 680K 1.5G 1% /run tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup tmpfs 1.5G 4.0K 1.5G 1% /tmp none224G 87G 138G 39% /media/sf_chris /dev/sdb4.0T 56K 4.0T 1% /mnt The explanation is that the file system isn't raid1, but rather the allocated chunks have this attribute. Presently a volume only allocates with one profile, but the future plan is per subvolume and even per file raid profiles. So establishing how much free space there is on a btrfs volume is absolutely less than clear. Anyway, I think it will cause some confusion if by available an application thinks it can write out more than 2TB of data to this example volume. I thought one of the features of combining the block layer and filesystem layer like btrfs does is that the filesystem can actually know the state/topology of the block layer and work more efficiently. Combined with the already existing problem of getting out of diskspace errors long before use hits 100% (has this been fixed since?) this makes any sort of capacity planning difficult if not impossible. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 04:13 AM, Kevin Kofler wrote: Rahul Sundaram wrote: Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. I really don't see what we have to gain from having 2 conflicting versions of MySQL in Fedora. It'd be a big mess not only for our users, but also for the software in Fedora which depends on it. For the same reason, I'm also opposed to the plan of having MySQL and MariaDB coexist for one release. We should really move to MariaDB with hard Obsoletes and then ship only that. One word: Competition. MySQL 5.6 has made significant performance improvements and both MySQL and MariaDB have features that the other doesn't have so while they are compatible for the most part they are not identical and if you rely on a MySQL 5.6 feature that MariaDB doesn't support than you'd obviously prefer to have MySQL available as an option. Also MySQL 5.6 gains some of its speed through commercial extensions (like e.g. the thread pool). Since these cannot be packaged in Fedora you will be able to make a better/more fair comparison between the two based on the same Platform (Fedora). All of this benefits Fedoras users. Besides I don't think excluding a specific piece of software without technical reasons would set a somewhat dangerous precedent. As long as there are people willing to maintain these packages and the packages themselves follow all necessary guidelines they should be allowed to do so. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On 01/31/2013 05:30 PM, Jóhann B. Guðmundsson wrote: On 01/31/2013 04:30 PM, Kevin Fenzi wrote: I don't see how a distribution default would make any sense. I guess that's as senseless to you as it is for me fesco decision of make mariadb to be preferred default is to me... Fedora doesn't have a default database of choice. What this discussion is about is the preferred MySQL fork of choice. If you favor Postgresql then this whole discussion isn't of any interest to you. By talking about a default database you are really just trying to change the subject. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Ryu - Network Operating System
On 01/23/2013 04:25 PM, Jaroslav Reznik wrote: = Features/Ryu = https://fedoraproject.org/wiki/Features/Ryu Feature owner(s): Isaku Yamahata yamahata at private.email.ne.jp Ryu Network Operating System http://www.osrg.net/ryu/ == Detailed description == Ryu is an Operating System for Software Defined Networking. Ryu aims to provide a logically centralized control and well defined API that make it easy for operators to create new network management and control applications. Currently, Ryu manages network devices by using OpenFlow. You can say that Ryu is an OpenFlow Controller. For Software Defined Networking or OpenFlow, please refer to Open Networking Foundation [1]. Where can one get an overview of these proposed features? Neither https://fedoraproject.org/wiki/Features nor https://fedoraproject.org/wiki/Releases/19/FeatureList seem to contain a link to an overview of all the proposed features. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/13/2012 05:28 PM, Thomas Woerner wrote: On 11/13/2012 03:46 PM, Matthew Miller wrote: On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote: Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It would loose internal state if it would be D-BUS activated. Surely it could persist it somewhere? Like in the actual netfilter rules? Yes. It has to be able to save internal state *somehow*, because if restarting the service breaks everything, we're not gaining much over the old way, are we? Plus, for a critical service like this, the service needs to be designed to be as robust as possible in situations where it might crash or get killed arbitrarily. With the old static firewall model every firewall change was a complete firewall recreate with conntrack loss. With firewalld changes to the firewall are done dynamically and conntrack is preserved. That's not correct. You can modify the firewall just fine without restarting it. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/12/2012 06:03 PM, Seth Vidal wrote: On Mon, 12 Nov 2012, Tomas Mraz wrote: On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. Sounds reasonable to me. Not sure that's a good idea. ssh itself is also part of the clients package and should probably moved as well then. sftp is probably popular too. I think its better to bite the bullet and just include the clients package as a whole. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update mongodb to 2.2.0 (latest release)
On 10/08/2012 09:48 PM, Troy Dawson wrote: On 10/05/2012 04:43 PM, Troy Dawson wrote: Hello, I have updated mongodb from 2.0.7 to 2.2.0. It is currently going through the normal channels for rawhide and Fedora 18. 10gen has a very good track record for being backwards compatible. According to their documentation When upgrading a standalone mongod, 2.2 is a drop-in replacement. and MongoDB 2.0 data files are compatible with 2.2-series binaries without any special migration process. If upgrading replica sets and sharded cluster, you should follow the procedures from their release notes. http://docs.mongodb.org/manual/release-notes/2.2/#upgrading What are people's thoughts on bringing it into Fedora 16, Fedora 17, EPEL6 and EPEL5? Troy Dawson I have had requests for mongodb 2.2.0 for Fedora 17, as well as EPEL 6 and 5. I am going to build for those tomorrow and let things sit in testing for at least a week (2 weeks for EPEL). The only concern I have received thus far is whether packages will need to be rebuilt against the new mongodb 2.2. From everything I have looked at, the answer is no. The API's should be backward compatible. The libraries provided are the same name, there is no increase in number. $ rpm -qp --provides libmongodb-2.0.7-2.fc18.x86_64.rpm libmongoclient.so()(64bit) libmongodb = 2.0.7-2.fc18 libmongodb(x86-64) = 2.0.7-2.fc18 $ rpm -qp --provides libmongodb-2.2.0-6.fc18.x86_64.rpm libmongoclient.so()(64bit) libmongodb = 2.2.0-6.fc18 libmongodb(x86-64) = 2.2.0-6.fc18 Updates to existing EPEL/Fedora version should probably wait until at least 2.2.1 is out. I've seen at least one report of sharding problems with 2.2.0 that were confirmed by the developers and reported as fixed in trunk and to be released in 2.2.1. In general you should probably wait for at least one or two additional releases to catch the most blatant bugs in the new major version. In as-of-yet unreleased verions like Fedora 18 this is not such a big issue since these will all be fresh setup and bugs will be noticed then and there but someone who is running 2.0 for a while in Fedora 17 or Centos 6 should not be hit by such things. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On 08/30/2012 08:55 AM, Bill Nottingham wrote: Bill Nottingham (nott...@redhat.com) said: Olaf Kirch (o...@suse.de) said: On Wednesday 29 August 2012 21:56:45 Jóhann B. Guðmundsson wrote: On 08/29/2012 11:58 AM, Olaf Kirch wrote: Your feedback is very much welcome! The network management/solution of the future most likely ( at least will need to ) be something that is integrated into ( or with ) systemd/Core OS Indeed, and that's where I'd like to go. Which is one of the reasons for choosing dbus as the transport. The systemd people do have some ideas they've already been kicking around for this already... have you seen it? To be clear, I'm not really convinced yet that this is something we need... there is a lot of legacy admin overhead and infrastructure that is highly resistant to change here. Speaking as an admin I think something needs to happen here. The current shell script/NetworkManager chimera is really ugly since they don't cooperate well I really wished things would go one way or the other or someone would come up with something that replaces both but I consider the current situation as a worst case scenario. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 07/13/2012 09:14 AM, Roberto Ragusa wrote: On 07/12/2012 09:54 PM, Harald Hoyer wrote: Again.. tmpfs is restricted to half the RAM size by default. You can't store 8-9GB of trash.. only 2GB, which might land on swap over time. As I have already pointed out some time ago, isn't a bizarre situation that as an application developer I can either use malloc() and store things up to RAM+swap (lets' say 4+6=10GB) or use temporary files and store things up to RAM/2 (lets' say 4/2=2GB)? Once upon a time you used to use files to go *beyond* RAM limits. And the answer to this objection is? move to /var/tmp. So patch everything (and good luck with closed source stuff). An application (closed source or not) that plans to store non-trivial amounts of data somewhere should have a mechanism/config option to let the user specify where to store that data. Simply hoping that you can dump X gigabytes of data in some hard-coded place is not a good idea. Wouldn't have been more reasonable to create a /ramtmp and patch the applications? (this would have just been patched for speed, not patched for correctness as the sort case). Hey, wait, we already have /dev/shm. So we just had to patch the applications (if anyone cares). That way *every* application would have to be patched. Using /var/tmp is only required for a small number of apps that actually have more specific needs regarding the data they intend to put there. Indeed in many cases it might be better for an application to actually manage the temporary-ness of the file(s) in question themselves and store/manage them in /var/lib/app instead. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On 06/19/2012 08:36 PM, Matthew Garrett wrote: On Tue, Jun 19, 2012 at 02:12:06PM -0400, Jared K. Smith wrote: On Tue, Jun 19, 2012 at 1:55 PM, Matthew Garrett mj...@srcf.ucam.org wrote: F18 is already using grub2 for EFI. I think we can remove grub-legacy now. What about the Fedora images for Amazon EC2? I seem to recall that because of pvgrub use they can't use grub2 yet. (I don't claim to be an expert on the cloud images -- I'm just asking a question based on what I seem to recall from earlier conversations.) Isn't pvgrub in the host environment rather than the guest? I thought we just needed the ability to generate the config files. pvgrub peeks into the guest disk so it needs to understand the partition table, the filesystem and the grub config file in the guest. Initially it didn't handle things like ext4, grub2 and EFI but AFAIK these should be fine now. I'm not sure what Amazons host systems use but hopefully they run a relatively modern version of pvgrub. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On 04/02/2012 09:08 PM, Miloslav Trmač wrote: 2012/3/27 Jóhann B. Guðmundsson johan...@gmail.com: On 03/27/2012 05:15 PM, Kevin Kofler wrote: I assume that that mod_access_compat module only requires a few bytes, so I don't see why it should not be loaded by default forever (or at least as long as upstream supports it, which hopefully will be for the whole 2.4 cycle). Few bytes for mod_access_compat here, few bytes for something else there I suppose this needs repeating from time to time. One byte of disk space costs .008065817067$ on the best-selling hard drive around here. Even if there were 100 million Fedora users (which is a huge overestimate AFAIK), that is $0.008 for all Fedora users together. Compare to a tens of minutes, or hours, per affected user that needs to update their system. Disk space at this scale just cannot be a reason to drop legacy interfaces. (There might be other arguments, such as maintenance manpower.) Of course, web app packages in Fedora itself SHOULD be updated to the new directives, but that's not a reason to gratuitously break the old ones. It's my experience that things dont seem to get fixed unless they are broken Is that another way of saying that only broken things need fixing? :) Mirek Upstream apparently wants to establish a new interface for this so I think it would be a good idea to promote this too if possible. Is there a way to only pull in mod_access_compat only on updates but not on new installs? That would be the best option I think as it would not break existing installations that get updated but allows new setups to either not have to deal with the legacy stuff at all or at least see that there are some changes going on there. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SPDY in F18 (was Re: F17 httpd 2.4?)
On 03/27/2012 09:46 PM, Michał Piotrowski wrote: W dniu 21 marca 2012 15:13 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: 2012/3/21 Peter Robinson pbrobin...@gmail.com: [..] There's nothing stopping you from packaging up mod_spdy or any other modules that add support for the protocol. I will try tomorrow - I've got mod_fcgid package sources for reference. Who can mod_spdy if I make the spec file for this? I wanted to write Who can adopt mod_spdy :) I created a feature page https://fedoraproject.org/wiki/Features/F18SPDY If someone accidentally did not know what SPDY is - there is a link to interesting video from GoogleTechTalks on this page. I also created an initial version of spec file for mod_spdy that can be found at this repo https://github.com/eventhorizonpl/mod_spdy That mod_ssl_with_npn.so hack looks pretty dodgy to me. Does that even work? Have you tested this together with the regular mod_ssl that comes with the httpd package? I cannot see how both modules can coexist. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On 03/26/2012 10:10 PM, Michał Piotrowski wrote: 2012/3/26 Nicolas Mailhot nicolas.mail...@laposte.net: The following is going to kill pretty much every packaged webapp unless they are changed now: https://httpd.apache.org/docs/2.4/upgrading.html#access IMHO mod_access_compat should be enabled by default https://httpd.apache.org/docs/2.4/mod/mod_access_compat.html I disagree. Since this is a major update that gets introduced together with a new Fedora version this opportunity should be used to make switches like these. Otherwise you'll be forced to either keep this compat stuff around for a long time (given the long apache release cycles) or remove it with a minor update when people least expect it. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On 03/27/2012 03:54 AM, Ken Dreyer wrote: On Mon, Mar 26, 2012 at 6:53 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: I disagree. Since this is a major update that gets introduced together with a new Fedora version this opportunity should be used to make switches like these. In principle I agree with what you're saying, but this is still going to require changing lots of packages, and it should be properly scoped on the httpd 2.4 feature page. All the more reason for making this change now with a major version change and early in the F18 release cycle rather than being forced to go through this in a later supposedly minor update. Here's what I plan to use in Cacti. Directory /usr/share/cacti/ IfVersion 2.2 Require host localhost /IfVersion IfVersion = 2.2 Order deny,allow Deny from all Allow from localhost /IfVersion /Directory I don't think making this a runtime configuration is a good idea. Most people only run either 2.2 or 2.4 but not both so having this in their config is really unnecessary and makes things more complicated then it needs to be. Why not make this distinction in the spec file and include one of two configuration files in the rpm depending on the release version? That way F18+ users get a clean config for 2.4 and older version get a clean config for 2.2. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Canonical Will Remove Java From Ubuntu
On 12/21/2011 06:52 PM, Andrew Haley wrote: On 12/21/2011 05:09 PM, Matej Cepl wrote: On 20.12.2011 19:30, Dennis Jacobfeuerborn wrote: Probably because OpenJDK and SunJDK aren't really that compatible. Well, hold on. Both the proprietary JDK and OpenJDK meet the specification, and we try very hard to be compatible with all the things that Java programmers assume. And we fix compatibility bugs if we can. I wasn't saying that this was the fault of people involved in OpenJDK. The problem is that the applications rely on behavior that is part of the platform but not mentioned in the specifications. You cannot expect different implementations to behave the same way when it comes to things that weren't specified in the first place. I am afraid that most of these problems are caused by stupid developers who are using (against all advices they were given) com.sun.* classes (which I am said is the most common source of problems). There is no protection against stupid programmers, I am afraid. There really is very little difference between the com.sun.* classes in OpenJDK and the proprietary JDK, as far as I know. Of course, I haven't really checked, but... ;-) The more important question is if Sun didn't want people to use the com.sun.* classes then why did they include them in the platform? In my opinion the root cause for these incompatibilities is that the platform simply isn't defined well. If you want to make good on the claim write once run anywhere then you actually have to make an effort to come up with a robust core. Injecting vendor specific stuff in there is pretty much doing the opposite of that. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Canonical Will Remove Java From Ubuntu
On 12/20/2011 05:48 PM, Kevin Kofler wrote: Peter Robinson wrote: Actually that's not entirely correct. They're removing the Sun Java closed source variant due to changes in licensing from Oracle preventing them from shipping security fixes. They also ship OpenJDK which is the open source release of the Java JDK as shipped in Fedora and that will continue to be available and its completely compatible with the Sun variant as its mostly based on the same code. I personally think its a good thing. See their press release with the full details https://lwn.net/Articles/472466/ What I don't understand is why they're replacing the packages with empty packages rather than just dragging in OpenJDK as an upgrade, which IMHO would be much less disruptive. Probably because OpenJDK and SunJDK aren't really that compatible. I keep running into all kinds of software the will not run with the OpenJDK. This is one of the reasons why I'm not particularly fond of Java as a Platform. It was supposed to be write once run anywhere but that is not the case in practice. Luckily Oracle will deem OpenJDK the official JDK with the next major release so hopefully things will improve with that. I guess the Ubuntu people decided that making users consciously replace the JDK is better then to silently replace it and get all kinds of bug reports about java software behaving in strange ways. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MATE desktop environment (GNOME 2 fork)
On 12/09/2011 12:50 PM, Jóhann B. Guðmundsson wrote: On 12/09/2011 03:50 AM, Eric Smith wrote: I've submitted review requests for the first two packages for the MATE desktop environment, mate-doc-utils and mate-corba. MATE is a fork of GNOME 2. I expect that it will take me a few months to package the remaining MATE packages. Would anyone like to see the MATE desktop environment as an official feature of Fedora 17 or Fedora 18? https://bugzilla.redhat.com/show_bug.cgi?id=765666 https://bugzilla.redhat.com/show_bug.cgi?id=765667 Is it not better to just create extension and an theme on spin with gnome3 that bring back the functionality you seek? That's pretty much was Mint seems to be doing and I agree that this is probably a much more viable approach: http://desktoplinuxreviews.com/2011/11/30/linux-mint-12/ Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: bugreports for missing service-files
On 06/21/2011 12:45 PM, Reindl Harald wrote: Am 21.06.2011 07:23, schrieb Alexander Kurtakov: I wonder how could someone would put a deadline on volunteers? You can't :) oh in the thread Packages that will be orphaned you can? Yes, because if the deadline passes then the packages will be orphaned without the maintainers having to do anything. but for quality reasons not? In this particular case no because if the deadline passes then the new configs will not magically write themselves. The problem isn't the deadline itself but the fact that you cannot coerce volunteers into action and that's what you are trying to suggest. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On 06/17/2011 01:02 PM, Richard W.M. Jones wrote: On Fri, Jun 17, 2011 at 06:48:14PM +0800, Mathieu Bridon wrote: On Fri, 2011-06-17 at 12:20 +0200, Henrik Wejdmark wrote: Since you recommend not using the application menu, in other words, you agree that the application menu is useless? It is useful when you are looking for something and you don't know what exactly it is. In that case, it is much much better then the previous menus, because you have nice overview on one page and moreover you have the possibility to filter by groups for example. On my desktop it's not on one page, it's a mile long listing so you get no overview at all. In Gnome2 at least all the apps are categorized. If the graphical user interface _requires_ you to use the keyboard to type the command It doesn't require you to type the command. You can search for bro and among the results will be Nautilus and Firefox (hint: Gnome Shell also searches in the application description, and both are browsers). I can't believe real usability testing was done on the final version of GNOME 3. I keep hearing about all these completely undiscoverable keyboard shortcuts that appear to be necessary to use GNOME 3 with any sort of effectiveness. When I struggled with GNOME 3 for about a week I didn't discover or use any keyboard shortcuts. I think what is required is an application that starts when the desktop is launched for the first time and that offers the user a short introduction to the basic principles of the desktop. Easy discoverability and good usability may sometimes go hand in hand but also at times are mutual exclusive. Having a short introductory pamphlet would help the user understand the basics without resorting to awkward tool-tips or pop-ups to nudge the user in the right direction. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for f14?
On 03/24/2011 04:36 AM, Pete Zaitcev wrote: On Wed, 23 Mar 2011 20:36:33 -0400 Genes MailListsli...@sapience.com wrote: On 03/23/2011 07:58 PM, Kevin Kofler wrote: Jochen Schmitt wrote: If you want to get firefox4 on Fedora 14 now, the only way is to use the private firefox4 repository on Or you can simply download it direct from mozilla.org and install it in /usr/local/ Mozilla's own build is garbage: Input Method does not work, fonts all screwed up. Spot's is much better and is actually usable. I'm not sure how to detect if the Input Method is working but I've been using the nightly builds for some time now in /opt/firefox and things look perfectly fine here. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox 4 for f14?
On 03/24/2011 07:31 PM, Kevin Kofler wrote: drago01 wrote: On Thu, Mar 24, 2011 at 7:23 PM, Kevin Koflerkevin.kof...@chello.at wrote: Adam Williamson wrote: In the particular case of Firefox, this isn't a problem, as it just gives you one giant static executable...so it's very easy to 'uninstall'. :) Did they really manage to stuff even the resources into the binary? Wow, very un-unixy! ;-) They didn't do that ... So it's not one big file… Scattered resource files are exactly what's most likely to stick around as garbage after uninstalling or upgrading in the absence of package management. It's one self contained directory which makes its handling fairly easy. I unpacked the nightly tarball to /opt/firefox and run it from there. To get rid of it just delete the directory and you're done. So why RPMs are generally preferable in this particular case the manual approach is quite manageable. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Alpha impressions
On 02/27/2011 03:55 PM, Mike Chambers wrote: Fonts or whatever don't seem to be as nice or full looking as other releases (F14 or below). Yes the font rendering makes applications look significantly more ugly then under F14. That was the first thing I noticed after starting Firefox. When in a program (Evolution for example), it seems this is the only one I see in the task window/panel or whatever up top. I can't tell Firefox or anything is running, unleses I click on the Activities link or control tab. I think this is sort of intentional. If I understand the way this is supposed to work correctly then you are not supposed to care if Firefox is already running but instead simply click on it in your favorites and if an instance is already running it will be brought into focus or a new instance is started. Also you don't need to click on Activities but can simply move the mouse to the upper left corner to open the favorites. While this takes some getting used to I think it makes sense. Simply throw you mouse into the upper left corner and then click on Firefox. When adding a background image, that little plus/negative sign at the bottom isn't too inviting to use. Had to look at that program couple times to understand/see them at the bottom. Could be couple bigger buttons or something. How the hell do you add something to be started up when your profile starts? Such as devilspie or whatever? I used to add this to startup programs. I used to be able to hover my mouse over the time and at least it would tell me the date instead of having to click on it just to see it. I think the general problem here is that with the advent of tablet and other touchscreen driven devices the whole hover mechanic just doesn't work at all anymore. On the other hand I noticed that when I move the mouse over an icon at the bottom right corner the icon slides to the side and reveal a label for that icon. So there the hover concept seems to be still alive. This is a problem though as apparently you cannot click that label: 1. Update icon appears 2. You want to click on it and move the mouse over it 3. The icon moves away from your pointer revealing the label 4. Clicking no longer works since the label is not clickable 5. You move the mouse over to the new icon position 6. If you overshoot the icon again slides away from you pointer = continue at 2. 7. If you don't overshoot you are finally able to do what you wanted to do in the first place: click that icon. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Alpha impressions
On 02/27/2011 06:36 PM, drago01 wrote: I used to be able to hover my mouse over the time and at least it would tell me the date instead of having to click on it just to see it. I think the general problem here is that with the advent of tablet and other touchscreen driven devices the whole hover mechanic just doesn't work at all anymore. On the other hand I noticed that when I move the mouse over an icon at the bottom right corner the icon slides to the side and reveal a label for that icon. So there the hover concept seems to be still alive. This is a problem though as apparently you cannot click that label: 1. Update icon appears 2. You want to click on it and move the mouse over it 3. The icon moves away from your pointer revealing the label 4. Clicking no longer works since the label is not clickable 5. You move the mouse over to the new icon position 6. If you overshoot the icon again slides away from you pointer = continue at 2. 7. If you don't overshoot you are finally able to do what you wanted to do in the first place: click that icon. This is a bug see: https://bugzilla.gnome.org/show_bug.cgi?id=636930 This bug only seems to address the overshooting issue but not the real problem of the icon moving away from you mouse pointer. If the appearing label or summary notification would be considered part of the clickable area for the icon this would fix the problem easily and make the overshooting issue disappear since you no longer have to move the pointer to the icon (for a second time). Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On 02/23/2011 03:27 PM, Josef Bacik wrote: On Wed, Feb 23, 2011 at 9:18 AM, John Reiserjrei...@bitwagon.com wrote: On 02/23/2011 05:07 AM, drago01 wrote: Defaults should be chooses on the metric what provides the best experience for the users not based on what we have been doing in the past (i.e stagnation). *One* data corruption constitutes EPIC FAIL. Btrfs is too young, and will be for yet a while longer. Well if data corruption is the test then we shouldn't be using Ext4 either, there was one fixed as recently as the beginning of this month. File systems are software like anything else, there will be bugs. Off the top of my head I can think of 3 data corrupters we've had in 4 years of working on BTRFS, and they've all been hard to hit and have not to my knowledge been seen by users, only us developers in testing. BTRFS is young, but we have to start somewhere. Thanks, I'm actually not that worried about corruption as that is something that can be fixed once discovered. What creeps me out about btrfs at the moment is this: https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21__Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21 The fact that the FS needs manual rebalance operations and that these can take a while (even tough this can be done online) doesn't exactly make btrfs the ideal candidate for an end-user desktop system that should pretty much be able to look after itself. I'm actually quite interested in btrfs especially for servers because of it's features but this problem really worries me. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: really strange ext4 behavior
On 02/12/2011 11:52 PM, Ric Wheeler wrote: On 02/12/2011 05:31 PM, Michał Piotrowski wrote: Hi, W dniu 12 lutego 2011 23:19 użytkownik Ric Wheeler rwhee...@redhat.com napisał: On 02/12/2011 05:12 PM, Michał Piotrowski wrote: Hi, I added a disc to my box. I wanted to use ext4. I run fs_mark to test speed, to my surprise I heard a really strange noises. It's very strange because the drive is new 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 12 # fs_mark -d test/ [..] FSUse%Count SizeFiles/sec App Overhead 0 100051200 22.854347 I decided to create an ext3 file system on this drive and everything works fine. # fs_mark -d test/ [..] FSUse%Count SizeFiles/sec App Overhead 0 100051200103.757229 When I mount this ext3 fs as ext4 and run fs_mark I hear strange sounds again. I use F14 and self compiled kernel from rawhide 2.6.37-1.fc14.x86_64 + e2fsprogs-1.41.14-2.fc14.x86_64. I mount ecryptfs on top of this file system. Does anyone know what might be causing this strange ext4 behavior? Hi Michael, fs_mark run a fsync heavy test. What you might be hearing is the impact of the fsync's. ext4 defaults to using write barriers enabled, ext3 does not. Without write barriers, those fsync push data from the box to the write cache on the drive only. With barriers, the disk will flush that cache to the platter, so the platter moves and you probably hear the head, etc. You can test if this is the cause by mouting ext4 with nobarrier to see if the noise goes away. I mounted fs with nobarrier and now it works just like ext3. Thanks! This solves the riddle :) Good to hear that it worked! Note that the barrier code makes your data safer, so you should run with it on by default (unless you really don't care about the file system). If ext3 was running fine without barriers for all these years why is this such a problem with ext4? Does ext4 do something differently that barriers are now required? Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)
On 01/02/2011 04:57 PM, Genes MailLists wrote: On 01/02/2011 06:16 AM, Thomas Woerner wrote: On 12/27/2010 08:42 PM, Casey Dahlin wrote: Can I ask a stupid question? Does dbus have the kind of performance necessary to support this type of application? What kind of performance do you think is necessary? Its just a configuration interface, its not like its pushing all your packets through dbus or asking the bus every time it needs to make a routing decision (or did I miss something? I'd certainly hope not). --CJD There will be an optional firewall mode, where you can define firewall features, the user will be asked about, but this will be limited to new connection attempts and not all packets in an established connection. I have no idea how you're implenting this - but if you're using iptables to change the rules the performance can be truly awful when you have more than a few rules. (I have a lot of rules on our primary border firewall). I switched to iptables-restore and got 2 orders of magnitude speedup (yes that is indeed over 100 times faster!!) - something to consider. I think iptables-restore uses libiptc to manipulate the rules. The problem is that according to the netfilter FAQ libiptc isn't officially supported but I asked about that on the mailing list. I've always wondered how to properly manipulate iptables rules from say C/C++ (or any not shell language) in a safe manner. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On 12/06/2010 08:53 PM, Bill Nottingham wrote: Phil Knirsch (pknir...@redhat.com) said: Basically it's a statefull firewall daemon now that allows us to support and implement a lot of those features which have been so critically missing in our old way of doing firewalls (aka static crap) and basically impossible to do there. One example is libvirt and how it has to change firewall rules dynamically depending on whether a guest is started or shut down, and those rules should survive a restart of the firewall (which currently they don't and can't). Roughly speaking it's a bit similar with the switch from our static initscripts for network configuration to NetworkManager and how it deals with network interfaces nowadays. Sounds good One thing is e.g notifications to users when some service/app requests to open a port. First version won't have network zones yet, but he and Dan Williams are working on that for the next generation which will then basically allow it to let the user decide once for each interface/connection what should happen with it and never be bothered with it afterwards. ... but this seems absolutely wrong. The last thing we want is to be pestering the user with information they may not understand, and are not fully capable of acting on. Take the constant complaints about SETroubleshoot, or the constant mocking of Windows Vista's security popups, for example. I agree that this is a problem but it would be nice if firewalld could still keep track of this information and make it available on demand (basically a log). Maybe the notification could be based on that and only pop up if configured to do so by the users who care. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall
On 12/06/2010 08:43 PM, Phil Knirsch wrote: On 12/06/2010 08:40 PM, Richard W.M. Jones wrote: On Mon, Dec 06, 2010 at 11:15:37AM -0800, Jesse Keating wrote: On 12/06/2010 11:05 AM, Daniel P. Berrange wrote: The other benefit would be if the user only intended the service to be accessible to localhost, or a UNIX domain socket but for some reason screwed up their service's config opened it to the world. I could buy this if we actually alerted users to this, when in fact we /disable/ logging in the default firewall set, so your packets just magically disappear leaving the user scratching their head as to why the hell things aren't working. Yes, enabling logging of packets really helps to track down firewall misconfiguration. What we really lack is good visibility for n00bs. Sure you can do 'netstat -anp' to show open ports and (if you're more of an expert than me) look at iptables to see what's wrong, but having nice GUI tools to display this information would be better. (No, I'm not volunteering to write them ...) Rich. Thats actually a really nice idea we could tackle with the firewall stuff Thomas is working on in the future. added_to_feature_list++ :) Add accounting too. Assuming that the Zones are implemented as chains it would be nice to be able to review how much traffic a Zone and/or the services are seeing. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/14/2010 05:44 PM, Michael Cronenworth wrote: On 11/14/2010 10:42 AM, drago01 wrote: Yes unless something changed recently the filesystem's discard command never reaches the drive. Looks like I'm reformatting and dumping the LVM. Thanks. You should also file a bug against the tool that told you that discard support is available. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (LVM issues)
On 11/15/2010 12:00 AM, John Reiser wrote: On 11/14/2010 01:13 PM, Matt McCutchen wrote: On Sun, 2010-11-14 at 13:07 -0800, John Reiser wrote: When I created 14 partitions using a DOS partition label (3 primaries, plus extended containing 10 logical partitions) and gave 6 of the partitions to an LVM setup, then I could not remove one of the partitions from the clutches of the LVM, and use the removed partition for some other purpose (keeping the rest of the LVM going), unless I removed all the LVM from that drive. vgreduce + pvremove? Did something go wrong when you tried? vgreduce would not let go of the partition that I wanted to take back, claiming that the partition was still in use. - DESCRIPTION vgreduce allows you to remove one or more *unused* physical volumes from a volume group. [emphasis added] - I could not find a way to evict any usage of that partition (transparently move the information somewhere else in the same LVM) as a prelude to applying vgreduce. In theory I could have moved all of the LVM onto another drive, but I wanted to keep the LVM going on that drive, with the same user-visible information content [there was enough free space], but without using one particular partition that I had given [loaned] to LVM some time before. pvmove is the command you need to use before doing a vgreduce. That's basically what I did with the 30TB system that I mentioned elsewhere in this thread. This system was partitioned into 10 raid-5 volumes and one of those acted up when we put the system into production (it was already pre-filled with data). So what I did was a pvmove to clear out the physical volume which took a few hours and then I removed the physical volume from the volume group. The fact that I could do all of this while the system stayed online and was being used was a real life saver. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/09/2010 10:05 AM, Jon Masters wrote: On Sat, 2010-11-06 at 08:43 +, Richard W.M. Jones wrote: On Sat, Nov 06, 2010 at 01:36:43AM +0100, Dennis Jacobfeuerborn wrote: On 11/06/2010 12:21 AM, Richard W.M. Jones wrote: On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ What's the implication for people who absolutely need to use X applications remotely? Use VNC. (Or your similar protocol of choice.) That's not a serious alternative. From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core. And what happens when all the apps are native Wayland apps and none of those can be run remotely? If I wanted to step back to the pre-net era, I'd run Windows. +1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility. Looks more like a case of crying wolf to me. It's probably going to take a year before Wayland can be turned on as the default desktop and it's probably going to take several years before X can possibly go away so to use this kind of hyperbole is really just flamebait. It's fine to bring your concerns up but please postpone this we are all going to die routine until we *actually* have something to complain about. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/09/2010 07:33 PM, Jeff Spaleta wrote: On Tue, Nov 9, 2010 at 6:12 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: Then why are people already calling for the rejection of Wayland even though Wayland is still far from being finished and hasn't even touched Fedora yet. raising concerns != screaming the sky is falling Actually, if we go back to the first post in the thread... it was the premature suggestion by a by stander of bringing a still far from being finished technology into Fedora because another entity has prematurely decided to announce to the world that its going to be their default. That triggered a certain amount of bloodletting. If the original poster had come to the conclusion that it was far from being finished before writing the first post do you think that the original poster would have written that post in exactly the say way? Something the original poster should probably ruminate on. Generally speaking, if you aren't prepared to talk in detail about the suitability of a technology, you shouldn't bring it up for discussion like that. If you are personally interested in it, you should inquire as to whether there are people in our development community who are currently working on it and ask them questions about it. To come out of the gate suggesting its time to discuss it for inclusion is putting the card before the horse. What the original post is, is a classic enthusiast blunder. The active developers working on the problem space are more than capable of proposing wayland for inclusion and answer questions about wayland...when they feel its ready. By introducing it for discussion before they were ready to engage in that discussion you've actually made it more difficult for the discussion to move forward as you've taken away their best shot to me a good first impression with the tech. No. I'm sorry but it's fundamentaly unfair to hold me responsible for the behaviour of others. If you think this shouldn't have been brought up fine but if others decide to draw premature conclusions from this it's their fault and not mine. As for the the developers will come forward when it's done you apparently seem to know know about the behind the scenes connections between Wayland and Fedora than others. I was aware of the initial anouncement of Wayland when the project was started at long time ago and wouldn't have dreamed of bringing it up precisely because it would have been premature. However now Ubuntu is apparently going to introduce its influence so I thought it to be fair to make Fedora aware of the project. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/09/2010 08:04 PM, Gregory Maxwell wrote: On Tue, Nov 9, 2010 at 1:12 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: On 11/09/2010 06:12 PM, Gregory Maxwell wrote: I've mostly been watching here and I think people have been fairly clearly about their concerns: Network transparency is important to them, and they understand that the wayland message is that it will not be supported. This message has been clear enough to me here and elsewhere— with people arguing things like applications which need network transparency are all now web based. You are mis-interpreting the message probably because you are not a developer and as a result don't know how software is designed in layers. Wayland handles the visual aspects of the desktop. Networking doesn't belong there. A remote app layer will sit on top of Wayland and deal with the communication between both ends. Nice way to assume. Its pretty likely that you use software I wrote every day. So long as the _system_ provides robust and fully integrated network transparency I don't really care which sub-components are actually providing it. I think I already made that clear enough. I don't think anyone here really cares about the internal details so long as the functionality works well and is well integrated. What hasn't been made clear to me so far is that this is the case. I see you saying this, it's also argued that network transparency is not required in wayland because some toolkits will support falling back to X. Other people have argued that network transparency is no longer required because of the existence of web applications. If is so clear-cut for wayland then why can't a clear message be provided? Please don't blame me the lack of clarity in the communications on Wayland's intended capabilities and confusion that other people have created by arguing the network transparency isn't a requirement. Miscommunication happens. It doesn't even require anyone to be uniformed or incompetent. I'm perfectly capable of understanding a statement like Cairo^wWayland is just a rendering layer, the communications is provided by FooBar, and that will provide good network transparency or at least as good as X11, so there is no need to worry if network transparency is important to you. From what you wrote it sounded like you were specifically insisting that the network transparency bits were supposed to go into Wayland proper and that would make some sense if said but someone who has never developed software and doesn't understand the layering of subsystems. It was an honest mistake and not an attempt to get cute. My apologies. What I was trying to get at is that even if the Wayland developers completely ignore network transparency that has no bearing on an independent implementation of that feature (see Casey Dahlins example elsewhere in this thread). [snip] X will run as a Wayland client. That means all applications that support X will be able to run remotely without change. Since QT and GTK both run on X and virtually all apps out there are programmed to use QT and/or GTK for most people nothing will change in the next couple of years. This is exactly the sort of non-comforting communication that I was complaining about above. The fact that 'legacy' apps will continue to function in a network transparent manner for some time is nice thing... but it suggests a future which will be increasingly boxed in if it becomes a central component of common GNU/Linux distributions. You're giving a really confused message here. In some parts of the thread it's being argued that the complaints are unfounded because the system will provide network transparency, but it's also argued that transparency isn't required because old applications will continue to work the old way, or because people don't actually need the functionality. The reason for the confusion is that two cases are conflated here: Wayland + X and Wayland without X. As long as X is present as a client on top of Wayland all apps will just continue to work as usual. That is the initial state of affairs and native network transparency for Wayland is not going to be that important. Once Wayland is established and successfull people will eventually want to get rid of X altogether. At this we'll need an X-less way of doing network transparency. This point lies 2-3 Years in the future though so it's not necessary to get worked up about the details just yet. That's why it's so hard to understand why people are already bringing out their torches and pitchforks over this. Keep your windowing system out of my network transparency ;) Now let's assume Wayland is really successull. In that case people will want to get rid of X altogether and then you'd also lose the remote app support of X and in that case you obviously would need a replacement for this so apps can run remotely on an X-less Wayland desktop. I think it's
Re: Ubuntu moving towards Wayland
On 11/09/2010 10:33 PM, Jeff Spaleta wrote: On Tue, Nov 9, 2010 at 9:09 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: No. I'm sorry but it's fundamentaly unfair to hold me responsible for the behaviour of others. If you think this shouldn't have been brought up fine but if others decide to draw premature conclusions from this it's their fault and not mine. Am I holding you responsible for others? No. I'm saying very specifically that you started a topic about inclusion instead of simply inquiring as to whether people in our community are already involved. The inquiry would have been perfectly appropriate. A suggestion we talk about inclusion when we don't have a clearly defined technical expert to make the case for it is not. We have a featuring process for some very good reasons. One of those reasons is to allow the person make the propose to provide adequate amount of information as a starting point for a constructive discussion about technical pros and cons. That's like me suggesting we have a discussion about moving over to the hurd kernel as a default when I know absolutely nothing about kernel implementation details and watching concerns over the issue spiral out of control. I am saying very specifically that noone should propose a discussion for technology inclusion on this list unless they feel comfortable addressing questions of a technical nature about the technology or failing that they bring someone along at the start of the conversation who is able to be the technical expert when the quite expected questions about technical issues come up. The discussion spirals when questions go unanswered by a technical expert and the void in the discussion is instead filled up with meatheads like myself. Point taken. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/06/2010 07:39 PM, Richard W.M. Jones wrote: On Sat, Nov 06, 2010 at 05:28:08PM +0100, Dennis Jacobfeuerborn wrote: First I think you should probably head over to the Wayland mailing list and get involved there. That's something I also recommend to Richard because if you want certain features to be present now is a good time to make your voices heard over there. It's already been done, and the developers have been busily rejecting them out of hand, eg: http://lists.freedesktop.org/archives/wayland-devel/2010-November/28.html [1] http://lists.freedesktop.org/archives/wayland-devel/2010-November/31.html https://groups.google.com/group/wayland-display-server/browse_thread/thread/e7ed0c0118fb31b4?hl=en.# Rich. [1] As an aside, the point the original poster in that thread makes about client-side decorations is very valid. If you've used Windows or OS X at all, you'll have seen how a buggy application can monopolize the display so nothing can be moved or killed or switched. So they consider this a layering violation which makes sense given that Wayland has a much smaller scope than X. That doesn't mean you cannot implement remote applications at all it just means you have to implemented in a different way. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/06/2010 04:16 PM, Mark Bidewell wrote: Out of interest, do you use individual shells/terms or something that provides a more remote desktop like experience? I use ssh -Y. Anything that sits in a huge window showing an entire desktop-in-a-desktop is so obviously the wrong way to do it, from both a usability and efficiency perspective, that I'm just astonished that people suggest I use something like VNC. We use both approaches, I suppose both have their merits, and we shouldn't rule out either method of working. -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel One of the many concerns I have with Wayland involves VNC. Right now VNC on X uses some of the multiuser functions to enable multiple VNC consoles. Will Wayland still allow for this or will we be back to Windows with only one VNC session per computer. Linux/Unix is designed around multiuser/multisession, I believe we would be amiss to remove those capabilities from the OS. First I think you should probably head over to the Wayland mailing list and get involved there. That's something I also recommend to Richard because if you want certain features to be present now is a good time to make your voices heard over there. That's the reason I brought the topic up in here so people can have a discussion over what the requirements are to make this work well with Fedora as a project and then push for inclusions of these requirements in Wayland. Second I am a bit surprised by the unless feature X is implemented 1:1 we shouldn't allow progess sort of argument that is going on here. The main reason I'm excited about Wayland is the fact that it creates competition. I agree with Camilo that X doesn't seem to cope with the requirements of modern desktops well and I believe the reason for that is the fact that in the absence of a competitor it's very easy to settle for good enough. Yes X is good enough for basic desktop especially after the great improvements that happened after the Xorg split but being good enough doesn't really jive well with Fedoras claim of being a showcase for technical innovation. I've lurked on the Xorg mailing list long enough to see the various attempts of improving X being stomped by the fact that compatibility with decade old protocols that no one really cares about on a modern desktop must be maintained. The fact that X can be run as a client on Wayland makes for a pretty perfect situation in my eyes. Wayland can make design decision unhampered by the past while people who rely on specific X features can keep using these applications without change. If the advantages of Wayland weigh so heavily then X will at some point be obsoleted. I these advantages don't materialize then Wayland will disappear and we will return to X. But a third possible outcome - and one that in my opinion is pretty likely to occur - could be that a lot of the features of X (like remote applications) will actually be implemented in Wayland precisely because they have enough merit to survive and that looks like a great future to me: a modern implementation of all the features we love and care about. As for the if all apps are ported to Wayland I will not be able to use them remotely anymore I think this is bogus. Nowadays virtually all application aren't X application but gtk/qt applications and the toolkits tend to support different backends. So you will be able to use your apps as long as the toolkits support X and I think that's going to be a long time unless Wayland is dramatically successfull. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/06/2010 12:21 AM, Richard W.M. Jones wrote: On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ What's the implication for people who absolutely need to use X applications remotely? Use VNC. (Or your similar protocol of choice.) That's not a serious alternative. From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core. On the net I read that Ubuntu wants to ditch X in favor of Wayland but that's not what I read in Marks post. As I understand it the plan is to introduce Wayland but not get rid of X for years to come. Sounds like a reasonable plan if it can be implemented in a technically feasible way. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Ubuntu moving towards Wayland
Interesting move: http://www.markshuttleworth.com/archives/551 Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/14/2010 06:32 PM, Lars Seipel wrote: On Tuesday 12 October 2010 15:56:02 Dennis Jacobfeuerborn wrote: Now we are really talking semantics. The point is that users should not be confronted with choices they don't really need to make or they don't understand. I disagree. How should a user know about some nice feature if its whole existence is hidden from his eyes? Yeah, he should read the documentation but aren't we talking about improving usability right now? Imagine some random user does his installs the hard way for years and now discovers (someone tells him oder he learns about it by chance by searching the documentation for an unrelated problem) that Anaconda has the capabilities to make his life easier. He goes like: Woow cool, this is the stuff I've been searching for years. I don't have to waste my precious time anymore by setting all of this up by hand. Anaconda now takes care of it. Didn't thought those Anaconda developers are that genious. But why on earth didn't they tell me before their software was capable of doing that? Do they actually like watching people suffer? Seriously, you guys suck! Yet most of this can be done in a much better way *after* the installation. I'm not sure why you think cramming as many features as possible into anaconda is a good idea. Once you've got the desktop running you have way better means to advertise features to the user. Hiding features doesn't have to be beneficial to usability. It can be harmful, too. Clearly if we wanted to hide *everything* we would not require a user interface at all but some choices need to be made. The point is that a lot of the stuff you apparently have in mind don't actually need to happen during the installation but can happen for example as part of the first-boot configuration. As long as most of these defaults and menus are not displayed initially that would probably be fine. The problem here is that every time you present the user with data dumps (e.g. lists of defaults) or menus you create a cognitive hurdle where the user wonders what he's supposed to do or gets worried that he breaks something. Minimizing that is really key to creating a streamlined installation interface. There are other ways to prevent confusion and worries about potential brokenness. If there are sane defaults and it is clearly communicated to the user that using those is the recommended way and gives him the best results in most cases, I don't see a problem. If users can trust in those defaults being sane and that by not touching them they get a good default configuration, they aren't helpless as they know what to do. However, if they wish to change something in future attempts they already know where they have to look. new installed system. The user doesn't care at all about partitions, LVM or mountpoints. I think you are strongly limiting the definition of what an user can be. So who is an user of Anaconda? For me, that is all those people using Anaconda. There is some guy from your neighborhood installing Fedora to surf the internet. There is some developer installing Fedora to work on the latest and greatest software in the GNU/Linux/X/freedesktop.org stack. There are designers using Anaconda to install the free software they need to create your favorite layout. There are also sysadmins deploying Fedora/RHEL/CentOS to many computers in their company, a public school or at your ISP's datacenter. So when you restrict Anaconda's userbase to just one kind of user, the whole assumption on which you build your enhancements to usability is wrong and will lead to software which sucks in usability as soon as you want to do something that you didn't consider basic enough to show it to users. The problem is that you insist on cramming all these people into one single group and create an installer that will make everyone happy. That's just not going to happen and it's one of the primary reason why efforts to improve things often fail. While abstraction is good there is such a thing as too much of it. One perfect example is the idea that you can simply slap a traditional desktop on one of these new tablets or smartphones and you are done. The real genius behind what Apple accomplished wasn't some nifty technological feat or the fact that they control both hardware and software but that they recognized that these devices simply aren't traditional desktop PCs and as a result need a system that is tailored to this new world rather than simply rebranding StandardOS(tm) and putting that on there. I think what is needed here is a similar approach were we don't try to take the current installation process and put some lipstick on it but instead recognize that the needs of Joe Sixpack who doesn't care about technology but simply want to share YouTube videos, manage his photos and browse Facebook are different from Mr. Admin who worries how he can separate his /home partition from
Re: Ubuntu 10.10's installer looks rather nice
On 10/14/2010 07:05 PM, Ralf Corsepius wrote: On 10/12/2010 03:56 PM, Dennis Jacobfeuerborn wrote: On 10/12/2010 02:52 PM, Ralf Corsepius wrote: On 10/12/2010 02:16 PM, Dennis Jacobfeuerborn wrote: On 10/12/2010 10:28 AM, Gerd Hoffmann wrote: Hi, Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users. We don't have to make things inferior to improve usability. To stick with the advanved storage example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named local storage and SAN storage. Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users. If you want to appeal to the same audience Ubuntu is going for then you have to remove choice. Why? All that would be required would be to move it out of this audience's way (the defaults). Now we are really talking semantics. I don't think so. The point is that users should not be confronted with choices they don't really need to make or they don't understand. My point is to offer users who want choice the choices they want and not to force them into something they do not want. As Gerd mentioned in another mail, SUSE's installer seems interesting wrt. this. Its defaults cater the demands of uneducated desktop installers, while still allows many kinds of complex setups outside of the defaults in advanced menus. As long as most of these defaults and menus are not displayed initially that would probably be fine. Please get yourself a SUSE DVD and try yourself - I was very positively surprized, esp. about SUSE's disk partitioner's work-flow. It is easy to use for beginners (Click-through), while it still allows complex setups. The problem here is that every time you present the user with data dumps (e.g. lists of defaults) or menus you create a cognitive hurdle where the user wonders what he's supposed to do or gets worried that he breaks something. Minimizing that is really key to creating a streamlined installation interface. The second aspect is that you want to talk to the user in terms of his problem and not in terms of the underlying technology. Correct, ... my needs differ from that of others, ... therefore the tools being provided by a distro need to cater my needs, otherwise the distro doesn't fit my needs. For example a user wants to either replace the current System completely or install the distribution into free space on his HD and but into either the old or the new installed system. Correct, that some user's demand .. but definitely not all, and could not be further away from my demands. The user doesn't care at all about partitions, LVM or mountpoints. This is different from the more apt user who wants to actually have control over these details (where exactly to put partition(s) on the disk for example). Correct ... The latter for instance is what I had needed. I wanted to compare SUSE against Fedora. So I installed SUSE in parallel to other OSes (amongst them Fedora and Windows) on to the same machine. If my only choice would have been erase Fedora and/or Windows, ... this distro would have disqualified itself. For all of the above select the advanced installation. I'm not sure why you recognize that you have very special needs for you installation yet at the same time seem to insist to be able to use the same installation procedure tailored to users who don't even understand a lot of the words you were using above. Nobody is forcing you to do anything. The issue here is that keeping these advanced features available could have a negative impact on the easy-mode experience.If you manage to prevent that from happening than more power to you but if not then creating two distinct workflows is really the only option. I can't avoid to disagree. Spawning different installers means duplicating work and wasting resource. Nobody is talking about spawning different installers. You'd start the same installer but it would present you with a different workflow i.e. in the advanced workflow you'd create your partitions manually and in the easy workflow you select to wipe your disk or install next to you existing windows os and anaconda would determine the necessary partitioning itself without bothering the user. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/13/2010 05:21 PM, Adam Williamson wrote: On Wed, 2010-10-13 at 10:16 +0200, Gerd Hoffmann wrote: And it probably shouldn't be labeled Advanced ... but say what kind of advanced stuff is hidden there, i.e. the advanced storage button should be labeled Add SAN storage ... because this is what it actually is about. Now you can figure whenever you need that or not without klicking and looking, see? Nope, because that's not all it does. You also need the 'advanced' storage mode if you want to explicitly exclude disks from being considered during installation at all, which was previously part of the normal installation flow; now you're only shown that screen if you pick the 'advanced' mode. A button saying 'SAN storage and explicit device selection...' is rapidly getting uglier, and I'm sure there's other stuff that's in that path which that description still doesn't cover. This discussion is what you get when you try to make both groups happy with a single solution and in the end this usually kills any progress because not only do they not come to an agreement initially but even if they do any future changes now have to be agreed upon by both sides. This sort of tight coupling is exactly what should be avoided if you want to make both groups of users happy. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/12/2010 10:28 AM, Gerd Hoffmann wrote: Hi, Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users. We don't have to make things inferior to improve usability. To stick with the advanved storage example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named local storage and SAN storage. Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users. If you want to appeal to the same audience Ubuntu is going for then you have to remove choice. The whole storage bit needs to be completely removed or at least stripped down. advanced storage certainly has to disappear completely. The only way to accomplish this without actually removing the features is to have two anaconda modes one for easy desktop installation and one full featured mode. This mode should be chosen not by the user but by the spin e.g. the desktop spin would use the easy mode and the server or workstation spins would use the full featured one. You cannot make two distinct target audiences happy with one workflow especially if one of those groups requires a limitation of choice. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/12/2010 02:57 PM, Jean-Francois Saucier wrote: On Tue, Oct 12, 2010 at 8:16 AM, Dennis Jacobfeuerborn denni...@conversis.de wrote: On 10/12/2010 10:28 AM, Gerd Hoffmann wrote: Hi, Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users. We don't have to make things inferior to improve usability. To stick with the advanved storage example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named local storage and SAN storage. Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users. If you want to appeal to the same audience Ubuntu is going for then you have to remove choice. The whole storage bit needs to be completely removed or at least stripped down. advanced storage certainly has to disappear completely. The only way to accomplish this without actually removing the features is to have two anaconda modes one for easy desktop installation and one full featured mode. This mode should be chosen not by the user but by the spin e.g. the desktop spin would use the easy mode and the server or workstation spins would use the full featured one. You cannot make two distinct target audiences happy with one workflow especially if one of those groups requires a limitation of choice. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Why this mode could not be selected by the user? I would say that the default mode be more like the Ubuntu installer and give the choice of an advanced mode like the current one. When you boot the CD/DVD, you could easily add the new choice in the list (Install, Install (advanced features), Boot from hard drive, etc). That would certainly be an option. The key point here is that you need a way to provide a distinct experience for regular users that is not hampered by considerations for more advanced ones. That's one of the things that Ubuntu does differently than Fedora in my opinion although with the latest ideas for a simplified package manager Fedora is certainly heading in the right direction. Let me clarify my position: I have no problem with with providing advanced features but in order to create a truly polished experience for regular users you need to be able to truly focus on them. If every time you think If we did X, Y and Z we could make the lives of users a lot easier you have to immediately go to but because of the advanced audience we can't do X and Y and we can only do an awkward implementation of Z than you will not be able to create a truly exceptional experience. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/12/2010 05:13 PM, Chuck Anderson wrote: On Tue, Oct 12, 2010 at 08:06:59AM -0700, Jesse Keating wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/12/10 7:20 AM, Matthew Miller wrote: On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote: The only way to accomplish this without actually removing the features is to have two anaconda modes one for easy desktop installation and one full featured mode. This mode should be chosen not by the user but by the spin e.g. the desktop spin would use the easy mode and the server or workstation spins would use the full featured one. Anaconda actually has the ability to do this with install classes. Anaconda used to have an Advanced mode where things like the complex partitioning and package selection were hidden. Turns out, the vast majority of people who used anaconda and said something about it had picked advanced mode, because they felt their case was special. If everybody uses advanced mode, that becomes the norm... Making advanced only a choice at the beginning of a 10 step process is a non-starter and leads to the problem you describe above. If instead there were Advanced Options... in each step along the way that could be opened/closed at will, that would allow users to explore the advanced options without worrying that they made the wrong choice way back at the beginning of the 10 step process, whether or not they actually end up using the advanced options. This assumes that the workflow for both methods is always the same which is pretty limiting. Maybe for the simple installation you don't want a storage configuration screen at all and simply put up an option to overwrite the hd completely or install next to an already present os. Perhaps you can even put this on the screen where the user enters his name since this selection doesn't really warrant its own screen at all. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On 10/06/2010 08:31 PM, Richard W.M. Jones wrote: Seems quite complex. What's wrong with a directory: /etc/iptables.d/ where RPMs like libvirt just drop the required additional rules (in a separate chain if you like) and restart the iptables service? It's low-tech but simple and it's all that libvirt needs. If you do an /etc/init.d/iptables save and then reboot the machine you will probably end up with duplicate rules because the libvirt rules are now created from /etc/sysconfig/iptables and then again from the respective iptables.d file. That's why I mentioned the two layer approach. You basically need a layer that loads the basic rules and then applies the per-subsystem ones and that is able to extract the per-subsystem rules again on save. This could be relatively easy or very hard depending the subset of rules you want to support for the subsystems. Thomas Woerners idea looks like the best approach to this. I was aiming for a more iterative approach using scripts instead of a daemon but if Thomas has fleshed this out already and some code working then more power to him :) Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On 10/04/2010 03:34 PM, Brandon Lozza wrote: On Mon, Oct 4, 2010 at 9:24 AM, Rahul Sundarammethe...@gmail.com wrote: On 10/04/2010 06:53 PM, Brandon Lozza wrote: On Mon, Oct 4, 2010 at 9:13 AM, Rahul Sundaram wrote: So according to you any free software with a trademark is non-free software? Good luck getting anyone including FSF to agree with that interpretation. Rahul I'm sure they will. Trademark restrictions violate one of the four freedoms and if you want I can ask Richard Stallman directly if this trademark rule makes software non-free. Actually I'll just go ahead and do it just to prove a point. Sure. I have asked and know the answer but go ahead. Rahul The freedom to run the program, for any purpose (freedom 0). The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this. The freedom to redistribute copies so you can help your neighbor (freedom 2). And the freedom Trademark law prevents in Firefox's case: The freedom to distribute copies of your modified versions to others (freedom 3)[SIC]. By doing this you can give the whole community a chance to benefit from your changes[SIC]. Access to the source code is a precondition for this. Notice how the last clause misses using the same name? You are perfectly free to distribute modified versions as long as you don't call them Firefox. That's what the Iceweasel people decided to do. So all freedoms are intact. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
