Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Wednesday, 3 January 2024 10:07:02 IST Marián Konček wrote:
> Note that mingw-* packages currently in Fedora install into the
> /usr/i686-w64-mingw32/ or /usr/x86_64-w64-mingw32/ directories.
>
> This is a different topic but if each archful package installed its
> files into a directory containing the arch name, it would allow parallel
> installability without configuring dnf and possibly make it more
> convenient for cross-platform development.
This is very similar to Debian's Multiarch[1], but they have
/usr/lib/ (less pollution of top-level /usr)
Indeed, such organization is ideal for cross-platform development:
* Libraries are installed in the same path, both for native and for cross
compilation
* As a result, normal packages in the distribution already have the
libraries in the correct locations for both native/cross compilation
* The packaging system (APT) was adapted to allow co-installation of such
packages (since the files don't conflict)
* At a later stage, the distribution began shipping complete toolchains
for all supported architectures -- built from exactly the same source (same
gcc, same binutils, etc.)
* I.e: a developer that need cross-compilation, install the wanted
toolchain(s) and all library packages are immediately available from standard
repositories.
I guess Fedora people that work on ARM/ARM64/RISC-V would love such a support.
Bye,
--
Oron Peled
> On 2. 1. 2024 16:23, Vít Ondruch wrote:
> >
> >
> > Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a):
> >>
> >>
> >> On Tue, 2 Jan 2024 at 06:21, Vít Ondruch wrote:
> >>
> >>
> >> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
> >>> The dynamic linker already has the `glibc-hwcaps` mechanism to load
> >>> optimized implementations of ''shared objects'' [3]. This means that
> >>> packages can provide optimized libraries and they linker will be
> >>> automatically load them from separate directories if appropriate.
> >>> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
> >>>
> >>
> >> Is this something specific to x86_64 that the libs needs to be
> >> nested in a place such as
> >> `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g.
> >> `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more
> >> universal.
> >>
> >>
> >> Adding directories to the /usr sub-space generally gets bogged down
> >> into 'You are polluting my name-space' arguments which get no-where
> >> because some of the people getting angry is having to live with some
> >> 3rd party rules and regulations which stipulated how things look and
> >> will only get updated once a decade or so. [The same goes with
> >> subdirectories in /usr/bin etc where it causes similar problems.]
> >> There tends to be no 'general' case which works unless it gets
> >> 'agreed' upon by some outside of the distro body that publishes
> >> 'versioned' standards.
> >
> >
> > Checking what Debian does, they have paths such as
> > `/usr/lib/x86_64-linux-gnu/`. So we would not be alone.
> >
> >
> > Vít
> >
> >
> >> Vít
> >>
> >> --
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct:
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines:
> >> https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> >>
> >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >> Do not reply to spam, report it:
> >> https://pagure.io/fedora-infrastructure/new_issue
> >>
> >>
> >>
> >>
> >> --
> >> ___
> >> devel mailing list --devel@lists.fedoraproject.org
> >> To unsubscribe send an email todevel-le...@lists.fedoraproject.org
> >> Fedora Code of
> >> Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List
> >> Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >> Do not reply to spam, report
> >> it:https://pagure.io/fedora-infrastructure/new_issue
> >
> > --
>
Re: gpg-agents all over the place
On Thursday, 17 December 2020 00:08:48 IST Sam Varshavchik wrote: > Roberto Ragusa writes: > > > On 12/16/20 2:55 AM, Kevin Kofler via devel wrote: > > > >> Believe it or not, GNU/Linux is no longer a text-only operating system, nor > >> are window managers just a container for terminal emulators. :-) > > > > But that is different than saying the GNU/Linux has become a no-text > > operating system.Version 2 of gpg is impossible to use in scripts. More problematic, but possible. The key is using "--pinentry-mode=loopback" (I don't have my scripts in front of me for further details) > Oh, look, someone else is using scripted build tools that use gpg. Nice to > meet you. I actually use them in build scripts that sign repositories, (in Debian, but don't tell anyone ;-)) -- Oron Peled Voice: +972-4-8228492 Ignore Your Rights And They'll Go Away ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Updating Rawhide vs GPG keys
Hi, I suspect it's a chicken and egg issue: * Look at /etc/yum.repos.d/fedora-rawhide.repo * You can see the line: gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch * But "$releasever" is determined by the version of "fedora-release" package. * So dnf, tries to (re)import f30 gpg key. * The import is OK, but doesn't help, because packages are signed with f31 key. I cannot test it now, since I already did the "manual upgrade" workaround yesterday. Anyone that want to check it: * Temporarily edit "gpgkey" and modify "$releasever" to "31" * Use dnf to upgrade and check if it imports the new GPG key and work correctly. Bye, -- Oron Peled Voice: +972-4-8228492 "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru On Monday, 11 March 2019 15:05:17 IST Steven A. Falco wrote: > On 3/11/19 7:31 AM, Vít Ondruch wrote: > > Hi, > > > > Can somebody please enlighten me, how to update Rawhide after branching > > and not using --nogpgcheck? > > > > It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is > > the package which is still "rawhide" package and has "f31" keys. But > > this package was not probably signed, because this directory is empty: > > > > https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/ > > > > Installing anything from Rawhide fails, because of missing GPG keys. > > > > So is there a way to get the GPG keys via DNF? Would it be possible to > > sign fedora-repos and fedora-release packages by older key to allow > > smooth updates? > > I was able to update by first manually updating the keys via: > > cd /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages > rpm -Uvh \ > fedora-gpg-keys-31-0.1.noarch.rpm \ > fedora-release-31-0.1.noarch.rpm \ > fedora-release-common-31-0.1.noarch.rpm \ > fedora-repos-31-0.1.noarch.rpm \ > fedora-repos-rawhide-31-0.1.noarch.rpm > > Then I was able to do a normal "dnf update --refresh". > > Note that your package directory location may be slightly different. I don't > know if the "rawhide-2d95c80a1fa0a67d" part is consistent or just where mine > happened to be. But if you search for one of the "keys" packages inside the > dnf cache area you should be able to find it. > > Steve > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing DNF 3 development
On Monday, 26 March 2018 11:16:14 IDT Tom Hughes wrote: > On 26/03/18 09:06, Marcin Juszkiewicz wrote: > > Debian has APT. APT uses one copy of metadata. Be wise. Like Debian. > > Do we know how? Do they just not allow non-root users to get up > to date data, or do they do something cleverer? With APT, cache update and using the cache are orthogonal operations: * Running "apt-get update" is privileged and update the cache. * There's obviously an optional service to run "apt-get update" periodically if root prefer this mechanism. * Doing just query (e.g: apt list ...) always use latest cache data. * So query by root or any user are the same -- no privileged and work on the cache (which may/may-not be updated). KISS, -- Oron Peled Voice: +972-4-8228492 May the Source be with you! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support (Take Two!)
On Thursday, 12 January 2017 05:23:52 IST Kevin Kofler wrote: > FHS multilib is designed only for binaries that can be natively executed, > where there is a clear, fixed preference on one architecture over another. > (If you can run both i686 and x86_64 binaries, you automatically want the > x86_64 one in case of conflicts.) Debian multiarch attempts to support use > cases that fail that assumption hardcoded deep into RPM and into Fedora > packaging practices. Correct. > Those use cases are much better served by full GNU sysroots (/usr/target, not > /usr/lib/target). Incorrect. As I mentioned in another thread, sysroot force you to place your libraries under the sysroot. IFF all you build are end applications, multiarch has no advantage over sysroot, BUT... If someone use sysroot and need to develop many libraries, they: * Either need to move the built libraries under the sysroot so the cross-compiler will link applications with them. * Or (as you suggested elsewhere), build them twice: first for the target device and than (with sysroot prefix) for the sysroot. Both alternatives are far worse than the nice multiarch solution which is building once and use the same binary package both on the target device and for your cross-compiling. To set the record straight: * Multiarch is paradigm shift and maybe Fedora use-cases doesn't warrant going this last-mile. * But claiming multilib is "better" than multiarch is simply wrong: multiarch solve the general case, while multilib solve only the specific case you described. (both archs are executable but one is prefered). Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support (Take Two!)
On Friday, 6 January 2017 19:02:16 IST Kevin Kofler wrote: > The right way to do cross toolchains is to cross-build sysrooted packages > from source in dedicated cross packages, which is how the Fedora cross > toolchains work. Mixing binaries for completely different machines in the > same directory tree, which will not even run on the host machine (or at > best, very slowly through software emulation), strikes me as a horrible > hack. We are not talking about running binaries, but rather linking with libraries. > The de-facto standard for cross compilers (i.e., what, e.g., the GNU > toolchain supports out of the box and defaults to) is /usr/$triplet > (sysroot), not /usr/lib/$triplet (multiarch). And that is for a reason, > because the former can accomodate /usr/$triplet/bin, /usr/$triplet/libexec > etc. easily I've used and built such toolchains for years (thanks crosstools-ng). They are fine if all you use them for is building "leaf" applications. But when your project is composed of many developed libraries -- this is hell: * Let's say you use your toolchain to build some libfoo shared object: - On the target device, it may be located under /usr/lib - But this is useless for further development, because in order to link your applications with libfoo, it should be installed under your $sysroot, where your toolchain will search for it (e.g: /usr/$triplet/usr/lib) * The common hack was to build these packages for the target device (libraries located under /usr/lib) and than use some "conversion" scripts that create a new package (with only libraries, headers, pkg-config, etc.) that install them on the development host under $sysroot. With multiarch, libfoo will be always under /usr/lib/$triplet: * On the target device, the dynamic linker will search there before falling back to /usr/lib (for legacy libraries). * And the Debian cross-compiler will search the same paths, so you can install it on your development host (non-colliding directories). > > * With multiarch distribution (Debian/jessie in my case): > >- Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu > > *regardless* if they were built natively or cross-compiled. > >- These packages may be co-installed on my development host and be used > > by the cross compiler. > >- So I have an ARM repository, everything built (natively + cross) is > > uploaded there and I can pull library dependencies into my build > > environment. > >- And the *exact* same binary packages installed on the ARM target are > > installed and being used by the cross compilers. > > That will not work with Fedora packages, for a simple reason: Fedora > packages often contain both executables and libraries. Correct. That's why I said multiarch is far greater effort than just directory relocation and it took Debian years to reach this level. In fact, if you'll read through the Debian documentation, you'll see how many facets of the distribution it touches, from compilers and build tools, through packaging tools and package installation tools (dpkg + apt, dependency calculation etc.) > For multilib (which does not support the cross-compilation use case you > mentioned), > RPM automatically resolves the conflict between different ELF executables by > "coloring" them with their architecture and then preferring one "color" over > the other. E.g., it is clear that x86_64 binaries shall always be preferred > over i686 ones, because if you have both, you are on a 64-bit system and > will almost always want the native ones. But if RPM sees an x86 binary and > an ARM binary, it will have absolutely no way to decide which one to prefer, > so it will just raise a file conflict and you will not be able to install > the package. True. One of the changes Debian introduced to "dpkg" was the concept of secondary architectures. You can install multiarch libraries side by side, but when you install non-multiarch package (e.g: executables) it'll know to pick the primary architecture. > For Debian multiarch to work, we would also have to introduce Debian's > aggressive subpackaging of libraries, which is IMHO not an improvement. It's true that multiarch package should contain only libraries and not (arch-full) executables. It's not an improvement for end-user system, but... * For embedded -- regretfully, I can't even consider Fedora for embedded system development. * Maybe also lowering total footprint (by finer granularity) which may be boon for container people (but I haven't checked, so maybe it's not significant). Overall, going multiarch is major multi-year effort, so I agree Fedora should not jump in this direction unless it wants to cater for embedded/
Re: Proposal: Rethink Fedora multilib support (Take Two!)
On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote: > ... > * I do not see any practical advantage of Debian multiarch over FHS > multilib. Good question, multiarch is a huge win for *embedded* developers. Let me give real life example from my $day job: * We build stuff for arm and x86_64 (I ignore our legacy platforms like x86, ppc, whatnot...) * We cross compile most stuff (faster), but not everything is easily cross-compilable: - Notorious examples are libraries with their own code-generation tools. - Examples: thrift, dbus-c++ (you need to *run* built tools) - So we build some packages natively (either on real ARM or in chroot with qemu-user-static). * With old, non-multiarch scheme: - Library packages compiled natively on ARM would be under /usr/lib. - But they cannot be installed on the build machine, so I can cross-compile applications against them. - The workaround was to unpack them, relocate the libraries, headers, etc to the prefix expected by cross compiler (e.g: /opt/toolchain/) and repack the result into an "all" architecture package. * With multiarch distribution (Debian/jessie in my case): - Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu *regardless* if they were built natively or cross-compiled. - These packages may be co-installed on my development host and be used by the cross compiler. - So I have an ARM repository, everything built (natively + cross) is uploaded there and I can pull library dependencies into my build environment. - And the *exact* same binary packages installed on the ARM target are installed and being used by the cross compilers. This is by far better and cleaner than the multilib, but: * It is a very big change, far wider in scope than just library directories. (pkg-config, cross-compilers, dynamic linking, rpath, packaging tools, etc.) * Debian introduced it in Debian/wheezy (~2012) but the real benefits were reaped only since Debian/jessie (~2015) when many libraries were already pre-built as multiarch and Debian shipped a multiarch aware cross-compilers. * So, I'm ambivalent here -- multiarch is great, but it's a big change and I'm not sure it's worth it *for Fedora users*. * Meanwhile, I'll keep using Fedora (KDE) as my personal workstation/server OS but develop everything at $day job on Debian (KDE) and for Debian (targets). Long live Linux ;-) -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron "Debugging is at least twice as hard as writing the program in the first place. So if your code is as clever as you can possibly make it, then by definition you're not smart enough to debug it." -- Brian Kernighan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: notion of base or minimal image
On יום שלישי, 19 ביולי 2016 9:20:41 IDT Colin Walters wrote: > On Tue, Jul 19, 2016, at 07:32 AM, Nikos Mavrogiannopoulos wrote: > > Hi, > > Is there some notion or definition of a Fedora minimal or base image? > > A lot depends on whether "image" is a container or OS, which mostly > boils down to "contains a kernel". That's a good start, but I think it could be (usefully) refined. Here is an example taxonomy: | +- Minimal Container (enough for chroot or entering into shell in container) | +- Minimal Build Container (Minimal Container + ) | +- Minimal Bootable Container (Minimal Container + systemd) | +- Minimal OS VM (Minimal Bootable Container + kernel + boot-loader) | +- Minimal OS Metal (Minimal OS VM + udev + <hardware-related-packages?>) Sounds reasonable? * Should we assign '@' for each of these combinations? * What about ? (x86*, arm*) * What about some package (similar to Debian) so there's a centralized definition for all implicit build dependencies (gcc, make, etc.) which should not be specified in "Build-Requires". * Other categories? Something that breaks this taxonomy? Thanks, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
On יום שלישי, 19 ביולי 2016 15:23:25 IDT Matthew Miller wrote: > ... > I remember when this came up before but can't find it now. I think it > was changed to 99 when UIDs went to 32 bit and it suddenly started > being 65535 on some systems and 4294967295 on others. * I was trying to > figure out why 99 was eventually chosen, but can't find it now. I believe the uid 99 come from trying not to overlap regular users. Back then (end of 90's), regular users uid's were: * On old RedHat Linux >= 500 * On some other Linux systems >= 1000 * On many legacy Unices >= 100 (except on Irix >= 1000) It was very common to have NFS mounted /home across all servers (with different *NIX vendors/versions). So '99' was the "last" uid that was assured not to collide with uid's of regular users on NFS. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron No, You Can't Have My Rights, I'm Still Using Them -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Thursday 02 June 2016 14:38:38 Matthias Clasen wrote: > I think the discussion is starting to go in circles. It is pretty clear > that we have different opinions about the desired behavior of logout. I'll take this as an opportunity to raise a separate issue. The current implementation has only 2 levels of control: global and individual (lingering). For non-tiny organizations this isn't good enough: * I would expect that root may set lingering for *groups* as well. * Otherwise, administrators need to set policy per-individual and we are back to square one (killing individual user processes). * Than we can have better default policy (e.g: members of groups wheel and staff have "lingering" on). * Example: something similar to access.conf(5) (but ".d/*.conf" not a monolithic file). * The design should assume that in the future, large organization would expect it their directory service. (e.g: like sudoers can now be integrated in IPA). A separate thought: maybe have a list of exceptions (tmux/screen/vnc/whatever) but this really opens a new can of worms, so it may be better not to mix this with the user/group granularity issue. Thanks, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Ignore Your Rights And They'll Go Away -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Monday 14 December 2015 09:34:56 Paul Wouters wrote: > On 12/12/2015 09:11 PM, Oron Peled wrote: > > Still, IMO, the goal to warn users can be achieved quite easily. Two > > examples from the top of my head. > > 1. log + notify: > >* The information may be logged with special prefix (or special field > > via sd-journal). > >* Users would have a small desktop service that would monitor for these > > messages and notify about them. > > You can do that logging using tools like dnssec-system-tray pointing to the > unbound log file. IMO, the question is not if I can do that (or others on Fedora-devel mailing list). It's if we can have such a warning setup be the *default* for end-users in Fedora-24. > > 2. dbus: > >* The local DNS server would send specific DBUS signal (e.g: > > net.dnsseq.InsecureDNSReply). > >* A desktop process would listen on these signals and show proper > > desktop notification. > > But these solutions can quickly become a denial of service through popups. Good point, but that could be mitigated at both ends: * The local DNS server can apply a "rate-limit" for these DBus signals. * Also, the display don't have to use desktop "notifications". Alternatively, it can be implemented as a single process that listen to these signals and show one popup with minimal info (global warning, with a possible list of latest problematic domains). > >* large-numbers: millions of machines would reveal much more varied > > use-cases > > than what a 500-1000 machines of "fedora-devel" people can show. > google dns, verisign dns and many large DNS deployments already validate and > break setups of > people using 8.8.8.8 manually. Those DNS deployments are good for general DNSSEC technology validation. They have nothing to do with the problem I pointed: * They do not test the crazy DNS world *inside* NAT'ed networks. * In these private networks is where most bad DNS setups exists. * This is the environment that the new Fedora DNS setup will likely encounter. factoid: In a medium corporation I know (few thousands desktops/servers across ~5 timezones), they still use internal domains like "foobar.local" (which practically kill great technologies like mDNS). This is pretty obvious as ".local" was considered *best-practice* by some Microsoft Active Directory setups when this corporation was small. > We've gone out of our way to try and be nice to existing DNS > deployments, but at some point you got to treat the wound, cause some pain > and fix things. I agree, but still think doing it in *two steps* would be beneficial for both Fedora and DNSSEC. First make it default and analyze the backlash (which won't be fatal, as it's only warnings) Than make it "enforcing" and force the pain (after you already have clear notification mechanisms that are *familiar* to the end-users). > > So my hunch feeling is still: make F24 with DNSSEC by default, but not > > "enforcing". Than, F25 will enforce DNSSEC validation. > > That just postpones the hurt for 6 months. We've already had a few of these > cycles. As I said, > I run this since fedora 17. As I said -- "you" (or me) running it for some time is nothing like few million Fedora users. My proposal does not "just postpone" -- Let's make it Fedora-24 default, but *warn* about bad replies instead of *rejecting* them -- this would give us valuable information. > Really, the biggest issue people fear is their split view DNS. Which is > easilly solved by extending > the concept of firewalld zones into Network Manager, and always use broken > DNS forwarders on > "trusted networks". Hmmm... "easily solved" is not "solved": * Has this "biggest issue" really been solved? Do we have this NM integration? Does it show in "nm-applet" (I avoid bringing up KDE which I personally use, or other desktops) * What other issues we don't know, simply because this Fedora setup hasn't been *widely* deployed? Thanks, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Friday 11 December 2015 09:09:28 Paul Wouters wrote: > On 12/09/2015 06:02 PM, Oron Peled wrote: > > Why don't we plan this feature in two stages: > > * Fedora 24: turn it on by default, but *keep using results* from bad DNS > > servers, > >just issue a user-visible warning, possibly with a link to a page with > > friendly > >explanation and suggestions for further action. I'll answer both Paul and Reindl which replied "there's no safe and clean way to solve that"... > DNS lookups don't have users like web browsers. First, that's only partially correct: * The client (resolver) normally *does* have a user (the uid of the process calling the resolver library). * But after that, your are correct that the caller identity is gone. Still, IMO, the goal to warn users can be achieved quite easily. Two examples from the top of my head. 1. log + notify: * The information may be logged with special prefix (or special field via sd-journal). * Users would have a small desktop service that would monitor for these messages and notify about them. 2. dbus: * The local DNS server would send specific DBUS signal (e.g: net.dnsseq.InsecureDNSReply). * A desktop process would listen on these signals and show proper desktop notification. BTW: SELinux failures may also be found in non-desktop-user context, but still the desktop user can receive warnings about them. > I have been running this setup since Fedora 17. Breakage is not that bad. Hmmm... even if all of us, fedora-devel subscribers, would run this it's still a far cry from a full release cycle of Fedora: * large-numbers: millions of machines would reveal much more varied use-cases than what a 500-1000 machines of "fedora-devel" people can show. * I suspect Fedora developers are very different from Fedora users (like developers/users in other technologies), so we are bound to miss important use-cases. So my hunch feeling is still: make F24 with DNSSEC by default, but not "enforcing". Than, F25 will enforce DNSSEC validation. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron MCSE: Must Consult Someone Experienced -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Wednesday 09 December 2015 13:37:12 Paul Wouters wrote: > On 12/09/2015 01:04 PM, Debarshi Ray wrote: > > Since this is likely to break networking on a lot of client-side systems, I > > would have expected you to do this research before submitting it as a System > > Wide Change. > > We did. We are the First at undertaking this at an OS level. If the others > proceed they will run in the exact same issue. The problem of broken and > badly designed DNS setups is, is that they only go away when it finally > breaks down. OK, but currently it's hard to estimate the amount of real-world breakage. E.g: if 90% of user setups will break -- the backlash would damage not only Fedora, but also DNSSEC adoption. Why don't we plan this feature in two stages: * Fedora 24: turn it on by default, but *keep using results* from bad DNS servers, just issue a user-visible warning, possibly with a link to a page with friendly explanation and suggestions for further action. * Fedora 25: we would have much better view of the amount and types of failures in real world (from F24). This would enable to improve/fine-tune the ways to handle problematic use-cases. So at that stage, we may ship DNSSEC as "fail-bad-DNS-servers-by-default". Make sense? -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Monday 07 December 2015 14:57:36 Paul Wouters wrote: > But you gain nothing with waiting. There is no "fix" to wait for. Those > stolen domains are broken and they will start to fail. The only difference > could be that fedora won't be the first where this breaks on, but I > thought "First" was one of our motto's ? Yes, as long as the "first" to fail use-case isn't too massive. So I have a question about another very common use-case: * Many times, Linux users or groups are a small "island" inside a big traditional corporation. * Usually, it translates to MS products: lousy DHCP server + lousy DNS server, managed via Active Directory (TM). * I think we should test this kind of setup and have very clear policy and instructions how to deal with it. * Remember, in most of these places the Linux team hardly knows who manage all the Windows stuff, let alone affect corporate internal policies (e.g: internal domain names and DHCP setup). * Failing in this kind of environment is shooting both Fedora and DNSSEC adoption in the foot. IMO, when introducing DNSSEC as default it should not be *enforcing*: * There's a lesson to be learned by what happened to SELinux in Fedora-2 (I personally do have SELinux "enforcing" on all my systems, but many would never try it again). * It's far better to accept "broken" DNS servers *at first* and just warn. (I know warning end-users isn't effective, but its important as a stop-gap until we know how such a feature affect millions of users in the real world. * E.g: "WARNING: the yellow icon is a reminder that your local network use non-secure technology " (someone may have an idea how to warn server people [/etc/issue?]) * BTW: hits on the above link would give us *some* measurement about people having problems/investigating this. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron "A standard for copy protection is as premature as a standard for teleportation." --- Noted computer security expert and Princeton University Professor Edward Felten. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Urgent F23 testing request: logout bugs
On Wednesday 21 October 2015 13:53:35 Adam Williamson wrote: > At this point the most valuable testing would be to see if anyone can > reproduce disappearing-cursor on KDE, and confirming the fix for the > black screen bug with the updated cogl. Another input, totally different environment, but still: * At work, we moved a user from an older Lenovo laptop to a new model (I can fetch the exact details if needed). * Both latptops have the same software and fully up-to-date (Debian/jessie/64bits/KDE4) * The new laptop /home is a copy from the old one. * Ever since, on docking-station hotplug, the user get a mix of both problems: disappearing-cursor (always) and black screen (sometimes one screen, sometimes both, sometimes closing/opening of lid helps, sometimes not, sometimes unplugging fix it, sometimes not). * So my suspicion is more about driver issues with new hardware. * Please ignore if you think the Fedora case is very specific to the software versions in Fedora. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Problems cannot be solved at the same level of awareness that created them. -- A. Einstein -- 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: Proposal: Drop comps
On Tuesday 14 July 2015 10:13:43 Vít Ondruch wrote: Can we just drop comps entirely (or at least trim them down significantly)? I know that this will not happen from day to day, but I see the comps just as an ugly workaround for missing weak dependencies, which we have now. With all its ugliness, comps groups have another important feature -- localized *names* and *descriptions*. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Real programmers confuse halloween and christmas because OCT 31 = DEC 25. -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Thursday 08 January 2015 08:52:22 Chris Adams wrote: Simpler version (if the change is desired): PermitRootLogin without-password BTW, Debian introduced this default for the upcoming Debian/jessie. Ref: Review for PermitRootLogin without-password change [https://lists.debian.org/debian-ssh/2014/03/msg00024.html] So another small benefit is increased uniformity in Linux and less surprises for new admins. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron A standard for copy protection is as premature as a standard for teleportation. --- Noted computer security expert and Princeton University Professor Edward Felten. -- 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: Poll: How users use DNF
On Tuesday 09 December 2014 18:39:25 Radek Holy wrote: Wow, I have already received a lot of feedback from you. I have not read it all yet. I very much appreciate it. Feel free to add even more feedback :-) I just forgot to mention that even your own aliases, plugins, workarounds and the other hacks you always need to do your job properly would be very interesting for us. OK, this isn't a direct DNF/YUM item, but still... I have several workstations/laptops with the same Fedora version (currently 20): * Downloading the same RPM's/DRPM's for each of these hosts is a huge waste. * OTOH, I haven't found a no-brainer yum-proxy (a-la Debian's apt-proxy or apt-cacher-ng) * I update them daily. I do this manually to have a quick look at what changes. * Sometimes I update via KDE apper (which use PackageKit, which calls yum backend). * But most of the time I do this over ssh, using DNF (it's faster...) So my workaround is: * I have a script: yumcache_to hostname * This copies (via rsync) all RPM's/DRPM's under /var/cache/yum. Last year I also added /var/cache/dnf. * It doesn't copy the meta-data files (for safety -- maybe they are in the middle of update via PackageKit or some cron-job). * When I started using DNF, I modified my script to also cross-hard-link all packages between yum and dnf caches before the rsync. * This effectively make them behave as a unified cache. Since some of my updates are via yum (e.g: via PackageKit) and some via dnf -- this cross-hard-linking also save extra downloads. For this to be effective: * I have a keepcache=1 in /etc/yum.conf and keepcache=true in /etc/dnf/dnf.conf * I have another yumcache_dillute script that remove old RPM's from caches (by time-stamp). As said, this isn't directly yum/dnf issue, but your are the people that can think of the missing pieces (some yum/dnf proxy -- that maps url's across mirrorlist -- so the same RPM's is a proxy hit, regardless of which exact mirror it was pulled off) Thank you all, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron ...there are two types of command interfaces in the world of computing: good interfaces and user interfaces. - Dan Bernstein, Author of qmail -- 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: blivet-gui announcement
On Friday 05 September 2014 23:57:46 Adam Williamson wrote: I like GNOME Disks, it's a great handy toolbox for doing simple manipulation of drives, but I'm not sure it quite fits the same mental box as blivet-gui would, for me. So, to extend the theoretical POV the way to go may have been: * Make the backend (udisks or equivalent) use python-blivet for a complete partitioning stack. * Let GNOME Disks expose only a naive-user-friendly subset of the functionality. * Let a full blivet-ui expose the full functionality. (obviously it's easier for me to do the talk than do the walk ;-) On another related front, can anyone relate this to similar technologies: * SystemStorageManager (https://fedoraproject.org/wiki/Features/SystemStorageManager) * openlmi-storage (https://git.fedorahosted.org/git/openlmi-storage.git) * The last one is even implemented in python. Just to make clear -- I think multiple competing solutions in the same domain are totally OK, especially when it's not clear which technologies will get traction. So even though running UI's as root is really bad, thanks for the blivet-ui people for the effort to expose an important storage stack. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron But it does move! -- Galileo Galilei -- 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: New Fedora 22 Change proposal: systemd-sysusers
A non-API related question... On Thursday 10 July 2014 01:49:41 Lennart Poettering wrote: Please understand that we are not duplicating adduser here. Already in the name of the tool we wanted to make clear thtat this is abotu system users, nothing else. The file format we defined has been reduced to the minimum possible, in order to make it difficult for people to use it for anything else than this. There are cases where a home directory of system users carry some semantics. Two examples from the top of my head: * Some tftpd implementations use it as the base path (and chroot into it) * Some anonymous ftpd implementation have similar use (chroot into ~ftp) So I assume *all* of these cases should be replaced by systemd explicit settings -- e.g: WorkingDirectory, RootDirectory in the unit file. Generally, I prefer the explicit systemd settings over home directory with magical effects, but I wonder if anyone is aware of existing system users which carry more complex semantics. Thanks, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Promises are like babies: fun to make, but hell to deliver. -- Nadav Har'El -- 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: Maybe it's time to get rid of tcpwrappers/tcpd?
On Thursday 20 March 2014 19:45:32 Lennart Poettering wrote: No. systemd is not a firewall. It currently supports libwrap checks for socket activated services. And I'd really like to get rid of that... Confession: I've never bothered looking in tcpwrappers code/api, so I'll take your assessment that this code should be thrown away... However, the functionality *at the service level* has its value, as a complement to firewall rules which are global by nature. Let's look at familiar NON-tcpwrappers examples: * Every sane network service allows you to bind to specific interfaces although you could protect them via firewall rules. It's not *only* security, but also flexibility (e.g: running several instances on several [physical or virtual] network interfaces). Sometimes it's just extra *safety* (e.g: you don't want an internal DHCP server to answer hosts on the corporate network by mistake). * You mentioned yourself the sshd Match keyword. Again, it's not just security per-se, but the softer ability to control a network resource *at the service level*. * xinetd also support some socket control options (besides optional tcpwrappers integration). E.g: per_source or cps directives. * Last, a somewhat theoretical example. User-level services. (e.g: screen sharing of personal desktop like krfb). The non-root user may not have global control on the host and firewall but may want to set limits who can bother him/her. (it's theoretical simply because current implementations doesn't give the user any such control ;-) So is there any chance to have similar functionality? * IMO, exact feature/syntax parity with tcpwrappers isn't important at all. * However, *some* optional socket control/limits in service.socket file would go a long way. * If this happens to be implemented in a small library with sane API, it may even contribute to the direct replacement of tcpwrappers in other network services that need similar features... Thanks, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron The wonderful thing about standards is that there are so many of them to choose from. -- Grace Murray Hopper -- 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: Service units for web applications
On Tuesday 25 February 2014 22:41:29 Lennart Poettering wrote: On Tue, 25.02.14 15:49, Stephen Gallagher (sgall...@redhat.com) wrote: For example, I might have http://reviews.myserver.com/systemd-reviews/ http://reviews.myserver.com/networkmanager-reviews/ http://otherreviews.myserver.com/ But a vhost is not a systemd concept, it's entirely foreign to it. It does not track it, maintain it, introspect it, know it. We really shouldn't turn systemd into something that can manage things that are inherently private property of other packages. Indeed. grief Actually, demultiplexing different applications should conceptually be at the port level (e.g: IRC/FTP/SSH/etc), potentially with pervasive service discovery for dynamic port assignment. This would have made web applications a first class citizen where it would be trivial to run multiple instances of the same/different applications under generic OS supervision (systemd), with all the benefits that come with it: * Privilege separation to different users (without risking SuExec) * Separate resource limits. * Separate chroots. * User initiated web-applications (on non-privileged ports). * What's not... However, over the years, the proliferation of NAT + firewalls basically killed everything but the venerable ports 80/443 -- maybe in IPv8 they would drop the src/dst port numbers from the protocols ;-) As a result, totally different application protocols and sites are multiplexed on these ports and can only be separated by parsing http headers. This limitation makes it the private property of the http server :-( We could have a kernel mechanism to parse the GET/POST/... urls and map them to some dynamically registered local port number (similar to netfilter). OTOH, do we want *more* parsing code inside the kernel? (probably not). Oh well, we can't fix it all -- httpd is the kernel for web-applications with all the trust, resource allocation and management issues that goes with it. /grief -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Real programmers confuse halloween and christmas because OCT 31 = DEC 25. -- 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: Fedora.next: I would like working configurations
class (via, to be designed, declarative syntax). * Pass our package specific data to this class constructor. Where the package-specific data would be a file containing relevant Augeaus code. * This also contains end-user visible text for each option including i18n. I think it would be better to handle this at the API layer, rather than in a database. There's a trade-off: * API layer -- more flexible. * Just i18n strings -- easier, may be given to translator teams, etc. If you look at i18n -- the FOSS community already made this choice -- almost everybody model it as data strings (.desktop files, pot/po files, etc.) Again, if we build a sensible API, it should be possible to build whatever presentation layer we want to atop it. Of note, we're planning to work with the Cockpit Project for our reference implementation. OK, * All front ends need only understand the generic types of the options. (I.e: they provide generic configuration UI widgets which aren't modified when new packages/options are added) I don't agree with this. Providing just a text entry box and a description isn't an effective UI technique, particularly if you want to be able to produce guided or wizard-based operation. (For example, if you have branching decisions during configuration). * The basic widget depends on the richness of your type system. For example, debconf has a multi-select type and its typical presentation is a drop-down list or something similar. * But you are correct that even with rich widget collection, the basic model is: one-widget-at-a-time which is somewhat limiting. * Maybe someone can find some generic enhancement to the one-widget model? However, a fully flexible UI model may present a lot of obstacles: * Packagers would need to write/maintain non-trivial UI models. I suspect this won't be maintainable (unless most of it would rapidly flow to upstream... hmmm... chicken and egg problem, related to wide adoption). * It would limit the available presentation formats. One of the huge benefits in debconf is that it can be used *everywhere*: - GUI - TUI (try to implement the Anaconda spoke interaction on a console...) - Regular text -- yes you can use it over plain old serial port (these days ignoring embedded systems doesn't sound like a good idea). - Preseed -- injecting (seeding) data beforehand. If you inject *some* but not all data -- How should it affect the interaction with complex UI ? Maybe the right approach for Wizards and other complex UI would be: * Create *optional* complex UI separately (maybe include it in its own (foobar-server) package). * This code would collect arbitrary info via arbitrary UI and would inject it (preseed) into the regular configuration items. * Obviously, this high-level configuration UI would have tight coupling to the low-level configuration details (item names and types). Other ideas? * The debconf API allows fetching any option from the database and the values of these options are used to configure the actual software. See above for the sync problem with this. As I explained, there's no problem since *values* are kept only once (inside the configured program native files/databases/whatever). The only database I was talking about was describing *which* options exist, what are their types, etc. Thanks for the feedback, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron ...there are two types of command interfaces in the world of computing: good interfaces and user interfaces. - Dan Bernstein, Author of qmail -- 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: Fedora.next: I would like working configurations
On Monday 27 January 2014 14:01:32 Stephen Gallagher wrote: ... or some mechanism to interactively configure and deploy a DHCP server. IMO, that's exactly the crux of the matter. Most non-trivial services requires some administrative decisions to configure them properly. Since rpm does not allow interactive query of the user (IMO rightfully), everybody implement custom solutions: * Some custom scripts (e.g: freeipa-server-install) * Only hand configuration (e.g: dhcpd) * Some web-based PHP configuration (many php web-applications that look for an easy solution to a tough problem and forget about security along the way...) Just like packaging systems implemented a common framework to install software, we need a common framework to *configure* it (at least base configuration if the full configuration management problem is too tough). My suggestion is to look first at the debconf abstract model. Let's start with one design decision which I think we should avoid: * Debian triggers debconf operations from the package installer. This means package installation is potentially interactive (not good). I think the configuration mechanism should be explicitly called from elsewhere. (e.g: when administrator want to activate/configure the service). But now, let's look at the good properties which we can learn from: * All configuration options are name-spaced (in debconf it's done by package name) * Each configuration option has specific *type* info (string, boolean, multi-select, etc.) * A package installation register its configuration options in a system-wide database. * This also contains end-user visible text for each option including i18n. * The debconf database may be populated via different front-ends: GUI, TUI, command-line, web-based (experimental), preseed (for kickstart install). * All front ends need only understand the generic types of the options. (I.e: they provide generic configuration UI widgets which aren't modified when new packages/options are added) * The debconf API allows fetching any option from the database and the values of these options are used to configure the actual software. Note: I tried to abstract away the properties, because I don't think the debconf *implementation* fits what we need. However, the model shows how very different packages can use a common framework for basic configuration, just like RPM shows how very different packages can use a common framework for installation. Having such a framework would allow a *standard* way of configuring a set of packages for specific roles. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron I love deadlines, especially the whooshing sound they make as they go by. -- Douglas Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ModemManager and generic USB hardware (was: Fatal flaw in the udev paradigm?)
On Thursday 31 October 2013 12:00:10 Dan Williams wrote:
If you're on a server, and that server does not
have any SMS me when you're down functionality, then you may not want
ModemManager installed there.
+1
But also in other cases, like the following:
* Software/hardware developer use a Linux laptop
* They remove ModemManager so it won't mess with their electronic
hardware testing.
* Later on, they are on the road and need something urgently.
* No problem, we have GSM modem, but... it's not working...
* No problem, we'll re-install ModemManager, but... we need a chicken
for this egg (or maybe vice versa ;-)
All of this just begs for a global disable flag for ModemManager:
* This should probably go into NetworkManager.
* It should be a boolean runtime flag, e.g: some dbus property.
* This way it could be exposed in UI (enable/disable modems).
But we'd also like to hear about devices
that MM probes-but-shouldn't-probe so we can black/greylist them as
appropriate.
While this will solve many problematic cases, it would still leave
a lot of unresolved cases:
* Either permanently (because of broken hardware)
* Or temporarily (until packages with updated graylist are installed).
[yes, the admin may create something temporary in /etc/udev/rules.d
but I'm talking from a *user* pov]
It looks like ModemManager should be able to pass some decision to the end
user.
Here is one possible model for doing this:
* All *potential* modem devices (serial ports, known USB id's, etc.) that
are reported to ModemManager build a list of Possible modems.
* However, ModemManager scan all this list *only if* a scan_all_devices
property is true -- in this case, it behaves like today.
* Even when this property is false, the user would be able to call
a new ScanDevice(dev) method to scan *a specific* device (from
the possible modems list).
Combining the two changes with the suggested global disable flag, would allow
a UI (e.g: nm-applet) to provide an interface which is both easy to grasp
and highly flexible (IMHO):
* With modems disabled -- everything is silent.
* With modems enabled -- the user can see a list of devices:
- The UI may optionally augment this list with some sysfs properties if
they exist (e.g: idProduct for USB devices, or the strings from the
USB hardware database, etc.) -- this extra info is public anyway and
doesn't require any MM involvement, it's just a UI thingy.
- If scan_all_devices is true, the UI may augment the list display
during the scan by MM. E.g: gray out devices that haven't responded yet,
show some progress for currently scanned device, display SIM information
when MM read it, etc.)
- OTOH, if scan_all_devices is false, the user may click a specific
device from this list to start ScanDevice(dev) on it.
* Optionally, the UI may implement further selection rules. For example:
- Allow the user to blacklist specific devices in the UI.
- This blacklist would be a UI list (i.e: client side).
- The UI would simply ScanDevice(dev) all other devices, so MM wouldn't
know/care about the extra granularity that was added by the UI.
Last, unrelated, suggested MM udev tweak:
* A lot of USB modems have several USB interfaces which translates to several
/dev/ttyUSB* etc.
* Some of the drivers (e.g: ZTE) provide a way for udev rules to hint them
about the preferred MODEM interface, e.g:
... ENV{.MM_USBIFNUM}==00, ENV{ID_MM_ZTE_PORT_TYPE_MODEM}=1
* Since there are so many no-name/broken USB modems out there, it would be
nice if this provision could be re-factored so it would apply to any USB
modem plugin (including the generic one):
... ENV{.MM_USBIFNUM}==00, ENV{ID_MM_PORT_TYPE_MODEM}=1
Now I wait to see:
A. If these ideas are just stupid and I don't understand anything about MM.
B. Or they are OK, but MM people cannot be expected to implement any
random nice idea suggested by someone on the Internet...
If it's B. -- please let me know and I'll try to see if I can prototype
something that may even function on some lucky days ;-)
Thanks,
--
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il http://users.actcom.co.il/~oron
Microsoft: We make virii work!
--
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: Hello! Also, packaging baresip for Fedora
On Sunday 29 September 2013 21:22:24 Lars Kellogg-Stedman wrote: I went ahead and generated a patch to the Makefile that uses the package version for the library version. That's wrong, as library versions represent API/ABI changes and the numbering has different *semantics* than package version numbering. [the libtool info file has a good introduction to ABI version numbering] IMO, there are two alternatives: * If upstream decide to manage ABI versions that's best. * Otherwise, you can number the library as n.0.0 and increment n for every new upstream release -- which means we assume each of them breaks ABI compatibility :-( (since currently, this library has only one client, it shouldn't be too painful). -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron I love deadlines, especially the whooshing sound they make as they go by. -- Douglas Adams -- 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: Firewall blocking desktop features
On Friday 13 September 2013 01:51:00 drago01 wrote: On Fri, Sep 13, 2013 at 1:26 AM, Oron Peled o...@actcom.co.il wrote: - This means that any privileged service controlled by GUI client (e.g: NetworkManager) is still only as secure as it's controller (e.g: nm-applet). This is wrong. That's not how controlling the service works. Care to explain? * Let's assume someone exploit a buffer overflow in nm-applet to execute arbitrary code. * Now she can ask (over dbus) from NM to do legitimate operations without the user consent/knowledge -- e.g: connect to some random-joe wireless network, etc. (btw, the user can still discover the truth via other client which isn't subverted -- like nmcli, the kde widget, etc.) * I don't claim this attack is easy, because the arbitrary code would have to hook into all relevant dbus callbacks for the wanted transaction to complete successfully, but I don't see any theoretical show-stopper. * IMO, all this just set some upper bound to our security expectations. Privilege separation of services into controller-controlled pair is an improvement over the previous state of affairs, but a verified-good controller can still become rogue during runtime due to a buffer overflow -- it than still have the same power it had before :-( -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron It's not the software that's free; it's you. - billyskank on Groklaw -- 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: Firewall blocking desktop features
On Thursday 12 September 2013 08:25:21 Pierre-Yves Chibon wrote: Application should request the ports to be opened and the firewalld layer should then confirm with the user stating which ports and which app requested said ports. The app can't lie if the firewall layer is the one asking for confirmation. But a malicious app can pretend to be another one, unless there is a way for the firewall to know which app is asking in a way that cannot be forged. But there is a way: * The firewall management software (firewalld?) would listen over a local stream socket. * The requesting application would connect to this socket with SO_PASSCRED and send its request for ports. * The firewall management software would ignore (and log) connections without SCM_CREDENTIALS. * with SCM_CREDETIALS you have uid, gid and pid of the caller. * From pid you can find the real executable (/proc/pid/cmd). Oh, and btw, when the client closes the connection (e.g: when it terminates) we should close the requested ports so we don't leave unused ports open for future malicious apps. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Simplicity is prerequisite for reliability. -- Edsger Wybe Dijkstra -- 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: Firewall blocking desktop features
On Thursday 12 September 2013 09:23:13 Colin Walters wrote: On Thu, 2013-09-12 at 10:01 +0300, Oron Peled wrote: * From pid you can find the real executable (/proc/pid/cmd). And this is the step that's worthless: https://bugzilla.gnome.org/show_bug.cgi?id=533493 Thanks, that was a very good read. However, there may be still way out for some cases... * First, let's talk about the primary mentioned attack vector -- LD_PRELOAD/ptrace attacks: - These should be ignored by suid/sgid binaries on modern Linux systems (sans kernel bugs). - So if we can sgid all these binaries to a specific group -- this threat is mitigated. - Actually, with this, the service can simply talk to clients running in this firewalld-control group. - Obviously, SELinux (which was mentioned in the URL) is a better solution along the same lines (labeling), but I think it wouldn't be easy to upstream a solution that can only work with SELinux. * But thinking more about attack vectors, I got a more depressing picture: - Assume a valid UI controller get subverted *during* run-time. - Examples: a buffer overrun, dlopen() malicious plugin, loading other dynamic code (e.g: via embedded python interpreter), etc. - This looks pretty hopeless to me in any case (be it SELinux or what's-not) As the same trusted process instantly becomes a bad-guy. - This isn't very different than a hypothetical security hole in ssh that would enable attacker to steal my private key. - *BUT*, since typical GUI programs are far bigger than ssh (including the whole UI library stacks), the risks for buffer overruns are not marginal. - This means that any privileged service controlled by GUI client (e.g: NetworkManager) is still only as secure as it's controller (e.g: nm-applet). - It's true that this is somewhat better than the old suid-root GUI wrappers that could do *anything* to your system. But still, we have no idea how to protect system-wide services *if* they need GUI control. - Or am I missing something here? -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Your fair use of this book is restricted You may only read this book once -- 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: Summary of accepted Fedora 20 Changes - week 30
On Saturday 27 July 2013 18:36:23 Matthew Garrett wrote: On Sat, Jul 27, 2013 at 01:12:25PM +0300, Oron Peled wrote: On the other hand, aliasing root to the installing user in /etc/aliases is trivial and adding the local spool mailbox as a default to MUA's would make these mails *visible by default* to that user. Really? I'd expect most users to be using gmail at this point. Any solution needs to account for them as well. 1. By the same logic we can ship just a browser, why bother building LibreOffice if many use just google-docs? 2. People can still use gmail and other online services like twitter via desktop applications (in my case kmail and choqok respectively). 3. Having quality desktop experience is part of what gives value to any Linux distribution -- just see the heated debates about any desktop related issue. 4. The sendmail discussion raised two small but important points: * That our default MUA's (e.g: kmail, evolution) aren't configured to show our default Linux mailboxes on first startup. * That root mail is not redirected by default to the installing user. 5. While I, as a Linux/Unix veteran, would always fix these two items without even thinking -- they are definitely integration-bugs (or miss-features if you want). Last side note: helping non-expert people get used to quality local applications which have convenient defaults, is part of the push for Freedom -- if both your data and your applications are locked in vertical clouds, you aren't left with too much freedom. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron In theory, it's practical. In practice - it's only a theory. -- 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: Summary of accepted Fedora 20 Changes - week 30
On Sunday 28 July 2013 08:01:25 Matthew Garrett wrote: On Sun, Jul 28, 2013 at 09:56:16AM +0300, Oron Peled wrote: 1. By the same logic we can ship just a browser, why bother building LibreOffice if many use just google-docs? Because not everyone uses Google Docs, and so any solution needs to account for those who don't as well. And I thought those few power-users would install it by themselves ;-) Or, to make the example more to your taste -- if, as many claimed here, most people use Gmail can't we forgo installing MUA's by default? Hmmm new feature for F21? 2. People can still use gmail and other online services like twitter via desktop applications (in my case kmail and choqok respectively). But most don't, and therefore an error reporting scheme that depends on users running a local mail client is inappropriate. You don't suggest any alternative, so let me suggest an easy one (which btw I use on all my desktops for the last 20 years): * Something important is sent to local MTA. * User get mail notification on their desktop. * User click on the notification. * MUA opens. * User reads mail. All of this is plain configuration on any MUA/desktop-system. Just make these *DEFAULTS* and the problem is solved: * Alias root to installing user in /etc/aliases * Configure installed MUA's to include local spool mailbox by default. * Configure your desktop to notify about new mails. Last side note: helping non-expert people get used to quality local applications which have convenient defaults, is part of the push for Freedom -- if both your data and your applications are locked in vertical clouds, you aren't left with too much freedom. There are benefits in running local applications, especially when it comes to freedom. However, we are unable to force our users to run local applications. Don't force them -- expose the better value proposition: * Read mail accounts from different providers via single interface. * Get mail notifications, regardless of mail origin. * Subscribe to different IM systems via single IM application Correct default configuration of MTA+MUA is great way to hook people into these benefits -- especially those newbies (veterans already know this and configure this for themselves). -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Life is a sexually transmitted, 100% lethal disease. -- 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: Summary of accepted Fedora 20 Changes - week 30
On Sunday 28 July 2013 10:29:47 Nicolas Mailhot wrote: 17. there's no need to work on this, technical users will know how to set up an MTA → that's what Solaris people thought before Linux people ate their lunch integrating stuff they didn't want to bother with Very good example, it's called batteries included. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Ignore Your Rights And They'll Go Away -- 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: Summary of accepted Fedora 20 Changes - week 30
Hi, On Friday 26 July 2013 08:06:10 drago01 wrote: Well it is a desktop spin after all. Most of the keep sendmail and syslog arguments where more server related things. Definitely not. On our desktop installs we clearly have an interactive user which is defined during install/firstboot/etc. This audience is rarely expected to use the command line shell, and even less so looking at logs (with all journal advantage, running journalctl or tail -f /var/log/messages have the same problem -- the user). On the other hand, aliasing root to the installing user in /etc/aliases is trivial and adding the local spool mailbox as a default to MUA's would make these mails *visible by default* to that user. Please note that both steps mentioned are an improvement in default user-experience of Fedora, even if later it's decided that installation of MTA *isn't a default*. (less people some system outputs are lost [tongue in the cheek]) Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron ... It's like a Windows.. litle blow and it crashes... (c)Broker -- 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: F20 System Wide Change: No Default Sendmail
On Monday 22 July 2013 20:18:04 Matthew Miller wrote: On Tue, Jul 23, 2013 at 03:14:32AM +0300, Oron Peled wrote: BTW: nobody ever answered how desktop users are supposed to read the output of their cron-jobs (they don't have permissions to read logs). They do have permissions to read journal entries that come from their userid. 1. Thanks, I've seen Lennart's reply regarding this in a separate sub-thread (boy, it's getting hard to follow this topic) 2. But as I've shown in my reply to him, cron-jobs output is not logged to this personal log, but rather to the system-wide log which isn't readable by regular users. So although the per-user syslog feature is really good, it doesn't apply to the case at hand. Do you have a real (i.e: working) solution for users to read the output of their own cron-jobs (besides mail of course). Without this, you propose to cut an important functionality from almost everyone (default). Instead, let's remove MTA from *minimal* install, but not from *default*. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Normally the saying is: 'Fast, Reliable, Cheap. Pick any two.' But with Linux you can pick all three! --from a Slashdot post -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Tuesday 23 July 2013 02:34:25 Lennart Poettering wrote: On Tue, 23.07.13 03:14, Oron Peled (o...@actcom.co.il) wrote: BTW: nobody ever answered how desktop users are supposed to read the output of their cron-jobs (they don't have permissions to read logs). Actually, if you'd look closely it has been answered 3 times now, already, just on this thread. This turned out into a huge forest of QA. I've read your reply to my other mail, just after sending my BTW:... reply to another -- sorry. However, if you've read my response you know the question wasn't really answered -- regular users only access to the output of their cron-jobs is still via email. Cron currently logs the output to the system-wide syslog which isn't accessible to regular users (just try it yourself I've tested it on F19). So as I've replied Matthew Miller few minutes ago: do you have a real (working) solution for this? If not, it's premature to remove MTA's from default install. That's without even touching the totally different use-cases for logs and email in general. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron In theory, there is no difference between theory and practice. In practice, there is. -- Yogi Berra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Wednesday 24 July 2013 13:23:08 Lennart Poettering wrote: On Tue, 23.07.13 04:03, Oron Peled (o...@actcom.co.il) wrote: There are two issues however: * The log-splitting of journald is really nice feature. But it doesn't work for cron: $ echo '* * * * * /bin/echo Test output from cron' | \ crontab '-'# than wait a minute $ journalctl# only shows crontab, not the cron output $ su - # journalctl# Cron output is properly shown. Also as mentioned on this thread, this doesn't work for cron right now as cron actually collects all log output of a job and then posts it under its own identity, which is why it is attributed to cron/root. Sounds reasonable, but please look at the result of previous tests: # journalctl SYSLOG_IDENTIFIER=CROND --output verbose Tue 2013-07-23 03:31:01 IDT ... PRIORITY=6 _UID=0 _MACHINE_ID=... _HOSTNAME=... _EXE=/usr/bin/bash _TRANSPORT=syslog SYSLOG_FACILITY=9 _SELINUX_CONTEXT=system_u:system_r:crond_t:s0-s0:c0.c1023 _GID=501 _AUDIT_LOGINUID=501 _SYSTEMD_OWNER_UID=501 _BOOT_ID=... SYSLOG_IDENTIFIER=CROND _COMM=sh MESSAGE=(oron) CMD (/bin/echo Test output from cron) _CMDLINE=/bin/sh -c /bin/echo Test output from cron SYSLOG_PID=19788 _PID=19788 _AUDIT_SESSION=194 _SYSTEMD_CGROUP=/user/501.user/194.session _SYSTEMD_SESSION=194 _SOURCE_REALTIME_TIMESTAMP=1374539461144186 It seems it was filtered by _UID, but what's the difference between that and _AUDIT_LOGINUID and _SYSTEMD_OWNER_UID? THis is, if you so will, a misdesign in cronie. Maybe: * But if it writes to syslog as root (_UID=0), how come _AUDIT_LOGINUID is my uid? * This missdesign cannot exist in the mail interface, since any sane MTA delivers local mails as the recipient user. In any case, this latent bug is triggered by removal of MTA -- so solving it would drop at least this show-stopper for the suggested feature. * Logs are inherently line-oriented (which is very good for their intended use case). However, many cron-jobs produce various reports which are multi-line in their nature -- not a very good fit. Cron currently collects all the job's logs in one go and then writes them under its own identity in one big transaction out. THis means that there's no way to get live access to the logs of current long-running jobs. Which is certainly suboptimal. Hmmm... you are right that for *some* cron-jobs, logging is better fit than mailing. However, for *others* it's the reverse. The examples I gave are reports (e.g: think about HTML report -- is there any sense in div... line without its matching /div?) There are obviously orders of magnitude of the report case cron-jobs then the prior -- just due to the fact the default cron-to-mail existed from early 80's on very wide OS range and the cron-to-log is relatively new feature that few heard about (I only heard about it in this thread -- thanks). The default mentioned in this thread -- mail and fall back to logging if there's no MTA sound very reasonable design to me. It would be *nice-to-have* if there was a way to specify cron-to-log per-job (or even per-crontab) without resorting to | logger..., but that's for another mail-thread :-) Note that due to the context we collect of messages it should be preferable these days if logging happens immediately per-line and then is recombined at display time, rather than collected and done at the end, simply to make sure latencies are low, and you get a live view into the system. But either way, both philosophies (log individual log lines immediately + log them all in one) work fine with journald, we can do both, better than syslog ever could. Obviously, journald manage its log data better than syslogd. However, we compare *logging* in general against *mail*: * Mail is pushed to the user, while the user need to actively read (pull) the log. So mail, by definition is a kind of notification-system. * Unlike desktop notifications which are normally transient, mail can be read offline, sorted by arbitrary user criteria (this mail is important *to me* so I put it in that folder), is normally saved long-term (and usually backed-up), can be trivially be forwarded (automatically/manually), shared between systems etc. * Logging shares most previously mentioned mail attributes (as compared to desktop notifications) -- i.e: it's persistent, may be backed-up, may be routed. However, it's line-oriented and not message oriented. * Obviously, messages may be re-constructed from lines, just like messages may be constructed from byte-streams -- do you use SOCK_STREAM for SOCK_DGRAM use-cases? (let's talk local-sockets, so we don't drift to reliability/ordering issues which
Re: F20 System Wide Change: No Default Sendmail
On Monday 22 July 2013 21:00:36 Lennart Poettering wrote: If you argue from the viewpoint of how universially available an API is to make it standard, then I would like to remind you that there are probably more Ubuntu installations in the world thatn Fedora installations, and they haven't included any MTA by default in 6 years or so. Finally I know what I was missing all these years ;-) [sorry, it was just too good, though you have a valid point] BTW: nobody ever answered how desktop users are supposed to read the output of their cron-jobs (they don't have permissions to read logs). -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron write your own operating system. It has worked every time for me -- Linus Thorvalds -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
Hi, On Monday 22 July 2013 20:33:32 Lennart Poettering wrote: On Sun, 21.07.13 01:50, Oron Peled (o...@actcom.co.il) wrote: OK, I won't count mailx and mutt because we talk about different audience, should we open bug-reports for the rest? (kmail? evolution?) Goog luck filing bugs against Thunderbird, GMail and Zimbra to add support for local mail queue reading... Hmmm... I didn't know any of them was installed by *default*. After all, the issue is *default* setup, isn't it? [bit-off-topic: unlike the others you mentioned, Thunderbird is a local MUA. Not being able to process any local mailbox (mbox/maildir/whatever) was the primary reason I never used it -- I cannot afford loosing almost 20 years of email history, much less convert it to some HTML based private format] Cron was already mentioned, but every one seem to ignore the fact that regular users don't have permission to read system logs. journald actually splits out user logs and use filesystem ACLs to ensure that the user gets read access to his own logs. This doesn't work for syslog (and also not if cron first collects all logs and then logs them as root). [thanks for referring to this issue. In a separate sub-thread I complained about not being addressed before seeing this mail] There are two issues however: * The log-splitting of journald is really nice feature. But it doesn't work for cron: $ echo '* * * * * /bin/echo Test output from cron' | \ crontab '-'# than wait a minute $ journalctl# only shows crontab, not the cron output $ su - # journalctl# Cron output is properly shown. So this issue is still outstanding (but I'll bet you knew that) * Logs are inherently line-oriented (which is very good for their intended use case). However, many cron-jobs produce various reports which are multi-line in their nature -- not a very good fit. IMO a reasonable path may be: * Not installing MTA at all for the *minimal* case. * Install MTA for the default case (especially desktops). * In that case, no SMTP port listening is needed. The default use case is about the ability to deliver messages by piping them to the MTA. No application/tool that I know of, tries to notify by sending to STMP on localhost (am I wrong here?) * Automatic mail-alias of root to the installing user will go a long way to make it more visible/useful. * Adding local mailbox as default configuration of MUA's (at least those installed by default for desktops) is even better. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Linux: If you're not careful, you might actually learn something. -- Allen Wong -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
Hi, On Monday 22 July 2013 21:15:14 Lennart Poettering wrote: The point I am trying to make is that if you have something that is vulnerable to a DoS attack you need to have a strategy to handle that. A very simple strategy exists -- alias root's mail to a regular user. I previously said it should be done during installation for usability reasons -- now you've just added another good reason. Please note that this is relevant even for the suggested world of non-MTA-by-default, because some people (horror, shock, awe) may actually install one. (unless DoS traps are OK for non-default installed packages...) Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Linux: like the air you breathe, ubiquitous and free -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Friday 19 July 2013 15:46:25 Adam Williamson wrote: ... We don't set up any mail reader to read this mail out of the box. OK, I won't count mailx and mutt because we talk about different audience, should we open bug-reports for the rest? (kmail? evolution?) No app is very likely to know your user name and send mail to you. Cron was already mentioned, but every one seem to ignore the fact that regular users don't have permission to read system logs. [or are you suggesting that regular users should not be allowed to use cron?] I run my own mail server, ground up. I'm not talking about running an SMTP server, but rather: - Programs being able to pipe stuff into /usr/sbin/sendmail (or mailx FWIW) - Knowing it would be routed to the correct location (with persistence). - The default location (/var/spool/mail) is well-known (and could easily become more visible via correct defaults for modern MUA's) - An administrator can centrally re-route all this to anywhere they want without having to fiddle with settings of individual applications. It's just ludicrous that we have it in @core. Rip it out, now. I agree about @core, I disagree about default (desktop/server) installs. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Linux lasts longer! -- Kim J. Brand k...@kimbrand.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
Hi, On Friday 19 July 2013 14:16:57 Matthew Miller wrote: As discussed earlier, I think it's significantly better for applications to get errors (which they can handle) than to think they've sent a message which really gets buried forever. True, but it doesn't have to be buried forever, at least not for the default (desktop) install: * Default delivery as today (no smart host, deliver to local mailbox) * We should add the local inbox to the default configuration of all MUA's that can handle it (kmail, evolution, etc.) * When Anaconda (or would it be first boot? I lost tracking...) is setting the first user, add it to /etc/aliases as a mail alias to root. With this, on every *default* desktop the installing user start getting useful system mails from various packages as they are installed (logwatch, arpwatch, cron-jobs, etc.) IMO, removing sendmail from the *minimal* install is good idea, but we should have an MTA for the default install with local delivery. I think the way forward is to encourage applications to _log_ rather than to send e-mail, via this or any other API. That can be configured for e-mail alerts if the admin really wants. Logging and mail have totally different use-cases. With mail you can send an extensive multi-line report to a human. As explained in the previous section, with very basic default configuration for MUA's and MTA's you get a very high chance that the desktop user who installed the system would actually see these mails (and any user would see the output of their cron-jobs). These same users are very unlikely to know that logs even exist, much less how to read them. [and all non-privileged users cannot see the output of their own cron-jobs...] But without configuration, nothing is going to happen _anyway_. Other use-cases would need configuration anyway. If you install a VM you may really want remote logging (as well as smart-host mails). But then such deployments are usually done by knowledgeable people with appropriate tooling (kickstarts, configuration-management tools, etc.) To summarize: * Remove from minimal install -- so advanced use cases can get rid of MTA. * Leave on default install: - Adding local mailbox to default configuration of MUA's would be an improvement. - Adding the installing user as a root alias to /etc/aliases would be another improvement. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron It's almost like we're doing Windows users a favor by charging them money for something they could get for free, because they get confused otherwise. - Larry Wall. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Monday 17 June 2013 02:13:06 Sérgio Basto wrote:
Hi,
I'm trying follow this (aarch64 support) but
https://bugzilla.redhat.com/show_bug.cgi?id=922257#c1
could/should be closed now, as this is done automatically from %
configure, so no need update it anymore ?
we had updated dpkg some major versions sine bug opened, how I know if
dpkg is now ready for aarch64 ?
When I fixed one of my packages (libhocr), I chose a different fix:
* Added: BuildRequires: autoconf, automake, libtool, pkgconfig
* In %prep added: autoreconf --install --force
IMO this is better then the new rpm kludge:
* In autotools based projects, the tarball contain *many* generated files.
(e.g: configure, config.h.in, config.{guess,sub}, INSTALL, etc.}
* The only reason they are in the tarball is to enable build without
the autotools suite (e.g: on other platforms)
* As such, these files are not [and should not be] committed to version
control systems.
* So although they are packages in the source tarball, they are no
part of the package real source -- they just happen to
come from the platform of the one who maintain the source tarball.
(via make dist)
* The autoreconf solution let autotools handle this complete problem
without trying to mess in its internals (rpm replacing only some files).
* As an example how wrong it is for rpm macros to interfere with the
internal logic of autotools, you could have a look in %GNUconfigure
macro in /usr/lib/rpm/macros. This one, tries to second guess
autoconf behavior, but it still search for configure.in files.
(For those who don't know -- while these files are still supported,
most modern packages correctly renamed them to configure.ac).
In the Fedora spirit of everything buildable from clean sources, I think
the autoreconf solution should be globally adopted (regardless of aarch64):
* It doesn't use generated files as input to the build process.
* It delegates the actual management to where it belongs.
Bye,
--
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il http://users.actcom.co.il/~oron
In theory, there is no difference between theory and practice. In practice,
there is.
-- Yogi Berra
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Monday 17 June 2013 22:58:53 Alec Leamas wrote: On 2013-06-17 21:17, Jerry James wrote: ... I'd rather not spend the small amount of time I can devote to open source software work messing with a configure script just because somebody thinks they should be able to run autoreconf with a newer version of the autotools and get away with it. Fair enough. Hope you did not recognize me as one of those who just thinks they should be able to run autoreconf with a newer version of the autotools and get away with it - that was not my idea. Actually, that was me who *hoped* we could get away with this ;-) ... If we ever will be able to write GL about it, we should keep both doors open. Perhaps with a recommendation about one of them being preferred, but nothing more drastic. Agreed. Let me be more specific: * If upstream uses a modern autotools, than autoreconf should be preferred (IMO). * If not, we should advise them to modernize (and if we can, try to help them). Because using very old autotools version isn't so different than using other very old development tools (think about compilers, support libraries, etc.). It is OK, but not the most advisable practice. Helping upstream to modernize is helping our ecosystem and helping Fedora being First. Again, all of this should be *recommendation*. Like Jerry James mentioned, it should be weighted by the package maintainer against other tasks which may be more urgent/important. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Without the wind, the grass does not move. Without software, hardware is useless. -- Tao of Programming -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging alien, debhelper and po-debconf
On Friday 14 June 2013 17:45:51 Sérgio Basto wrote: On Dom, 2013-06-09 at 13:02 +0300, Oron Peled wrote: As soon as dpkg-1.16.x hits f18. dpkg-1.16.10-4.fc18 hits f18 (status stable) Now alien is waiting for debhelper https://admin.fedoraproject.org/updates/debhelper-9.20120909-1.fc18 Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron LINUX is tied fairly closely to the 80x86. Not the way to go. - LINUX is obsolete, Andy Tanenbaum, 29 Jan 92. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sharutils license correction
On Wednesday 29 May 2013 19:36:31 Tom Tromey wrote: Paul convert all info pages to proper man pages and obsolete: the info Paul package. Man pages aren't really a replacement for info. Replacing info with HTML would be more reasonable,... There's no need to convert input format in order to have your preferred presentation. For example, in konqueror you can simply type the info:/ URI and browse the info documentation with proper fonts, highlighting and links. (IIRC, the GNOME help browser had similar functionality) -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Gratis is nice, Libre is an inalienable right. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On Monday 27 May 2013 18:17:19 Sérgio Basto wrote: I try fedpkg switch-branch f19 git rebase master Git rule #1 -- NEVER rebase a public branch (use git merge) [because rebasing rewrites history] -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron First they ignore you, then they laugh at you, then they fight you, then you win. -- Gandhi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On Friday 24 May 2013 13:41:41 Kevin Fenzi wrote: On Fri, 24 May 2013 15:15:30 -0400 Rahul Sundaram methe...@gmail.com wrote: Not really. We are focusing only on the x86_64/x86 case and ignoring the broader problem which Debian has tackled. Jumping to the conclusion that because you had some multi-lib issues in Ubuntu, we are doing better is premature. Considering the fact that ARM is going to become primary architecture for Fedora, we really need to solve the broader problem one way or the other. It was my understanding that arm is not going to do any multilib. aarch64 cannot run other stuff, so you cannot run armv7 or whatever on a aarch64 box, it's just completely different. I think you missed the whole point of Debian's multi-arch -- instead of special handling for sister architectures (e.g: x86/x86_64), or proving there aren't (e.g: aarch64/armv7) -- it creates a symmetric world. The *huge* benefit of multi-arch is to people that *cross-compile*. Example (without multi-arch -- like in Fedora today): * You cross compile libfoo (e.g: on x86 you compile for arm) * You can install the resulting libfoo rpm on the arm device * Now you want to cross-compile an application that use this library, so you need to install libfoo-devel on your workstation -- BUT! * The libfoo-devel you have is for arm (not installable on your x86) * Furthermore, even if you manage to install it, it will put the files in the wrong location (/usr/lib) and not where the cross-compiler will search them (e.g: /usr/arm-unknown-linux/.../lib) * So you have to extract the arm libraries from libfoo-devel and manually put them into the correct location. (btw: Debian embedded developers has automatic tool to convert these packages -- dpkg-cross). * If you maintain an embedded arm based product, multiply this scenario by the number of libraries your developers maintain and their daily commits does it scale? How does it affect your whole build environment, continuous integration tools, etc. Same example (but with multi-arch): * Every compiler/linker/dynamic-linker for every architecture search first in /usr/lib/arch and falls back to /usr/lib (to cover legacy libraries which haven't been migrated yet). * Under this scheme, *both* the native and cross toolchains search for libraries in the same location -- /usr/lib/arch * With careful package design, there should be no problem installing the arm based libfoo-devel on our x86 system (no conflicting files). * Please note, that it doesn't matter if libfoo-devel was built on an arm machine (native compilation) or on x86 with a cross-compiler -- in both cases the resulting library files would be on /usr/lib/arm-unknown-linux * This means cross-toolchains becomes first class citizens. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Gratis is nice, Libre is an inalienable right. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On Wednesday 22 May 2013 23:33:05 Richard W.M. Jones wrote: TBH I don't think we need Suggests AND Recommends. I can never remember the difference on Debian. Wouldn't most people would be satisfied with a single way to suggest useful packages? Thinking about it, the terminology adopted by comps is clearer and provides a generalization of this -- if someone select something they get: - Mandatory packages (cannot be deselected) - Default packages (selected, but the user may deselect) - Optional packages (deselected, but the user may select) Borrowing similar logic for rpm we could have in the spec file: Name: acme Requires: foo, foo-utils InstallDefault: bar, perl-bar, python-bar InstallOptional: baz, baz-ldap Now it would be classic to use --with/--without as command line flags, but it's already taken :-( -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Boycott Microsoft -- http://www.vcnet.com/bms -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?
On Sunday 19 May 2013 15:22:12 Richard W.M. Jones wrote: On Sat, May 18, 2013 at 10:15:54AM -0700, Adam Williamson wrote: ... so on a minimal install you only had to set a root password and you wound up with a system with just the root user. I know, and it was a pain to remember the right groupadd/useradd commands! Huh? What's wrong with a simple useradd foobar? On Fedora/RHEL/Centos the defaults for useradd in /etc/login.defs are very sane, so you don't need extra commands: - Create private group (USERGROUPS_ENAB) -- yes - Create home directory (CREATE_HOME) -- yes So all that is left is to passwd foobar, but that is routine to any Linux user even during normal life-cycle. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron write your own operating system. It has worked every time for me -- Linus Thorvalds -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging alien, debhelper and po-debconf
On Wednesday 01 May 2013 22:21:20 Richard W.M. Jones wrote: On Wed, May 01, 2013 at 03:00:34AM +0100, Sérgio Basto wrote: https://bugzilla.redhat.com/show_bug.cgi?id=591190 I'm prepared to take debhelper. But: (1) It looks like the latest package is over 1 year old. I think a newer package should be presented (in this bug or in a newly opened one). (2) Can debhelper be used to make .deb's on a Fedora host? If it works, that would currently be very interesting to me. I'll start with (2): * I can build .deb's on Fedora using pbuilder/pdebuild. * Here is the tree of RR for making it work: https://bugzilla.redhat.com/showdependencytree.cgi?id=591388 * Credit goes to Jeroen van Meeuwen. I just joined to help move it forward [ with very little success so far, mind you :-( ] * And yes, I think it makes Fedora a better development platform if you can use it to build both rpm's and deb's (on Debian, you can do both). Now to (1)... Ouch: * The stalling of po-debconf is my fault, but see today's update to rhbz#591389 (I'm fixing my ways...) * If we resolve it quickly, the next is debhelper (rhbz#591190). IMO the main blocker there is finding someone committed to review (I'm willing to maintain it). There's another problem in the chain (dpkg too old), but hopefully it will be OK soon (maintainer updated today the BR and said he would fix it RSN) * I uploaded a temporary pbuilder SRPM: http://oron.fedorapeople.org/deb-package/pbuilder-0.213-1.fc18.src.rpm - It's up-to-date (Debian/wheezy) - But I didn't have time to clean it up for review. Hope to do this in the next few days and update the RR. So maybe we finally have a chance to move this along before the dedicated bug zappers would zap it (no criticism -- they work hard to clean the mess we leave behind us). Unrelated note: * I've been using schroot(1) a lot in the last years on both Debian/Fedora to maintain multiple clean build environments of different OS. * However, one of the most useful features -- snapshots via LVM -- is not usable in Fedora due to rhbz#600636 * That bug-report is stalled since 2010, and exactly a year passed since I sent a tested patch... OK, back to work now. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Linux: Because rebooting is for adding new hardware -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging alien, debhelper and po-debconf
On Tuesday 07 May 2013 17:29:09 Sérgio Basto wrote: OK so lets cleanup all this reviews, do you finish the reviews requests ? I can only do it on week ends. I intend to do my best . But other people (the reviewers) are also involved. we have Richard W.M. Jones and Dmitrij S. Kryzhevich also interested in this packages. So as a first step you can start with my proposed srpm's: * Check/build them yourselves. Report problems/deficiencies. * See if they are OK for your use case. * As a bonus, if you find why '%check' in po-debconf failes -- even better. (the spec has commented out instructions + results) As alien is ready just need be updated to 0.88 , the most priority are debhelper and po-debconf , but we can do the others Here is the checklist: - po-debconf almost OK, waiting for cwickert comments (reviewer) - dpkg upgrade, waiting for maintainer, he would try to finish it this weekend - debhelper, ready (IMO), reviewer is silent for ages -- can you take it? how? - pbuilder, working package, need cleanup (me), after the 3 pre-requisites are ready it would be justified to bother the reviewer. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron If it's there and you can see it, it's REAL If it's there and you can't see it, it's TRANSPARENT If it's not there and you can see it, it's VIRTUAL If it's not there and you can't see it, it's GONE! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Friday 03 May 2013 22:22:47 Bruno Wolff III wrote: It's not like the people entering the password don't know it is visible. I for one, will finish typing the password *way before* realizing it's visible: * Touch typing is fast * With passwords it's even faster: - Because it's very common. - Because I don't want by-standers to be able to grasp it from looking at my fingers. * You never expect the Spanish Inquisition will make such a UI change ;-) -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Saturday 04 May 2013 04:58:13 Matthew Garrett wrote: No, this isn't the most appropriate mailing list for the discussion - anaconda-devel-list is a better choice if you want to interact with the people who actually work on that code. What separate a Linux distro from a random batch of software is *policy* and what happened here is a radical policy change without any *prior* discussion. Why only installation? By the same token we should apply this logic to any other password entry -- should this go according to each packager taste? IMO, this kind of change belongs first to fedora-devel and *than* to Fesco. (and I'm still repeating my previous question in this thread -- are any security related people involved? Or do we assume their opinion on the subject matter isn't relevant) -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron It's almost like we're doing Windows users a favor by charging them money for something they could get for free, because they get confused otherwise. - Larry Wall. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Friday 03 May 2013 14:26:22 Dan Mashal wrote: ... And closed as NOTABUG. https://bugzilla.redhat.com/show_bug.cgi?id=959541 https://bugzilla.redhat.com/show_bug.cgi?id=958608 I've read through it and didn't know if I should lough or cry. Before referring the subject matter: Are security-related decisions taken without speaking with security-people first? (Dan Walsh? Any other?) But I'll try to analyze few of the points raised in the BR... Hiding the password as you type doesn't actually do anything for security, as anyone watching your monitor could just watch your keyboard instead. Not really: * The keyboard is much closer to the body and someone has to be *really close to me* to see it (even then it may be partly obscured). * On the other hand, a password on a monitor may be visible even to someone passing by for a split second (even by mistake) -- the exposure is orders of magnitude higher. Not if you're a fast typer. Okay, I'll record your typing with my phone and play it back slower later. Typing speed has nothing to do with anything. Again: * Someone can easily record my screen from across the room (zoom) * How much of my keyboard they'd see from such a distance? Considering my back, elbows, palms (yes I type with 10 fingers) -- not much. And here comes the best part... There's quite a few papers about this right now ... and in a way that does not require yet another widget which needs layout, translation, and all that kind of stuff. Passwords are really bad security mechanism (and you can find lot's of papers describing their drawbacks). By this line of thought, maybe we can get rid of the whole root password thingie... This would save us at least 3 widgets (two text fields and a done button), with all their layout, translation and all that kind of stuff. OK, so that last one was a bad joke, just like exposing typed passwords... -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron “If I have seen a little further it is by standing on the shoulders of Giants. --Isaac Newton. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wednesday 23 January 2013 23:49:48 Kay Sievers wrote: ... We had no better idea really, than to copy the successful model we do for disks (and other subsystems) with /dev/disk/by-*/ symlinks. It was a well-known scheme, but it was certainly not know for network devices so far. So we picked up the basic ideas from biosdevname and combined them with the proven scheme we do for all other subsystems in udev. This necessarily lead to different names, but from udev's point of view they are entirely justified. The /dev/disk/... is nice because of *two* properties: * It indeed provides unique, persistent names * But people can still use /dev/sda Which is useful in the super-common case of single disk PC I.e: the predictable names are just aliases for the traditional names. In another mail on this thread, someone mentioned that this possibility was looked into, but the related kernel code cannot be easily modified to support multiple-names per interface. However, maybe implementing this aliasing in user-space is more tractable? IMO, my following proposal is only feasible if (and it's a big iff), the number of system calls and library functions that accept a network interface name is not large [things like if_nameindex(), the ifreq ioctl()'s, etc.] If that's the case, we can map predictable names to traditional ones in user-space, on the entry to said library functions, or entry to the said glibc syscall wrappers. Example of a possible mapping scheme: * Have udev create a symlink that maps the predictable name into the string of the traditional name. E.g: /dev/netdev/enp2s0 - eth0 * Of course, there's no eth0 file, but nevertheless the symlink can contain this string. * Now implement ifname_mapto(const char *name, char *new_name) as follows: - If there's no /dev/netdev/name, use name as new_name (identity) - Otherwise, new_name is the result of readlink(/dev/netdev/name) Now if there aren't zillions of functions that process network interface names, modifying them seems reasonable. The advantage is that it allows the use the traditional names for the most common cases (e.g: a laptop with one eth0 and one wlan0) while still providing a predictable naming to be used when needed. Now, what do my .signature try to tell me? ;-) -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron ... Complex problems have simple, easy to understand wrong answers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prefered way of configuring X11 keyboard layouts in F18
On Saturday 01 December 2012 23:38:49 Sérgio Basto wrote: system-config-keyboard should do this: 1. Get the old settings: cat /etc/sysconfig/keyboard 2. Set the new settings: su -c 'localectl set-x11-keymap layout [model] [variant] [options]' 3. Remove the old configuration file: su -c 'rm /etc/sysconfig/keyboard' Replace item 3. with an even better one: 3. Overwrite /etc/sysconfig/keyboard with following content: # This file is obsolete and may be removed, its settings # were migrated on date by running: # localectl set-x11-keymap Thus, making people understand what happened to their old file. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron There are only 10 types of people in the world- Those who understand binary, and those who do not. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages in need of new maintainers
On Thursday 04 October 2012 08:42:01 Ralf Corsepius wrote: On 10/03/2012 08:23 PM, Jon Ciesla wrote: As a result of FESCO ticket 952*, Lubomir Rintel's 200+ packages are in need of new maintainers. Under normal circumstances we'd simply orphan them all, but given the large number we want to handle this in a more orderly fashion. Please reply to the list with any requests for ownership changes, and I'll complete them on a first-come, first-served basis. The current list: debootstrap -- Debian GNU/Linux bootstrapper If no-one else steps up, I'd take this. However, my package portfolio already has reached extents, I'd rather leave this package to somebody else. I'll be happy to take it (FAS username 'oron'). -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron .--. |o_o | |:_/ | // \ \ (| | ) /'\_ _/`\ \___)=(___/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: new feature in yum-langpacks - langinstall/langremove
On Wednesday 08 August 2012 16:15:38 Bill Nottingham wrote: I've added code to yum-langpacks so you can now run: yum langinstall language and yum langremove language to install any langpacks for that language. It also now stores what languages you've done installations for in the past, so it acts consistently on future installs. Which begs for: yum langlist yum langlist installed -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron If it's there and you can see it, it's REAL If it's there and you can't see it, it's TRANSPARENT If it's not there and you can see it, it's VIRTUAL If it's not there and you can't see it, it's GONE! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
InitialExperience (was: Schedule for Monday's FESCo Meeting (2012-06-11))
On Sunday, 10 בJune 2012 17:10:05 Jon Ciesla wrote: ... #topic #857 F18 Feature: Initial Experience - https://fedoraproject.org/wiki/Features/InitialExperience Being a KDE user, this feature page was my first encounter with this interesting proposal. As a result I also followed the mentioned: http://live.gnome.org/ThreePointFive/Features/InitialSetup and related: https://live.gnome.org/ThreePointFive/Features/UserPanel I wanted to raise 3 separated issues not mentioned in Fedora feature page: 1. There's no mention of other desktops: * For example, let's assume KDE has no equivalent feature. * We still need the KDE (or other desktops) spin to have during the first boot a functionality (but not necessarily the same look) of firstboot * So IMO, this feature should explicitly mention how it intends to treat other desktops (e.g: booting with KDM, LXDM) regarding basic mandatory configuration (e.g: creating new user, setting timezone) 2. The GUI seems to bundle system-wide settings with per-user ones: * What if *other* GNOME users would like to use the same modern GUI to enroll into their online accounts on their first login? * It seems to me a lot better not to mix first boot functionality with first login functionality. * Even if the design people want to pack them into a single integral UI, the per-user part should still be designed to be operational by itself on first login of any user (not only the one that installed the system). [obviously, a new user should have her chance to take the tour on first login even if the system was installed 5 months ago by someone else] 3. No mention of kickstart integration: * Would we still be able to have fully automatic install? [without the first user being bothered with system level stuff like networks, timezones, etc.] I think these 3 aspects should be marked in the feature page and with proposed strategy to handle each of them. Thanks (maybe it's all taken care for, and I simply missed it in the feature page...) -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron But it does move! -- Galileo Galilei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On Friday, 8 בJune 2012 20:07:20 Gerry Reno wrote: On 06/08/2012 01:04 PM, Adam Williamson wrote: That is only assuming that Windows on ARM is successful, of which so far there's been precious little indication. There is a tidal wave of these PC ARM devices coming: http://www.itworld.com/hardware/240039/qualcomm-targets-pcs-takes-aim- intels-ultrabooks Hmmm... we've seen this Windows-on-non-x86 movie twice before: - Remember Alpha's? Digital (RIP) really thought MS would give them the keys to the kingdom. There was a released version. It was good enough to frighten Intel at the time (which was probably the reason MS did it). Linux sold manyfolds more Alpha's than Windows. - Ahhh, and of course MS found new suckers who bought the same used story few years later (yes, I'm talking about Windows/PPC that lived a very short life). So far, MS failed misserably in the cellular space so there's a good chance their exclusionary move on ARM will only help convince vendors that shipping Androids (and by extension other Linuces) is safer bet. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On Saturday, 9 בJune 2012 00:47:30 Richard Vickery wrote: On Fri, Jun 8, 2012 at 2:15 PM, Oron Peled o...@actcom.co.il wrote: On Friday, 8 בJune 2012 20:07:20 Gerry Reno wrote: On 06/08/2012 01:04 PM, Adam Williamson wrote: That is only assuming that Windows on ARM is successful, of which so far there's been precious little indication. There is a tidal wave of these PC ARM devices coming: http://www.itworld.com/hardware/240039/qualcomm-targets-pcs-takes-aim- intels-ultrabooks Hmmm... we've seen this Windows-on-non-x86 movie twice before: - Remember Alpha's? Digital (RIP) really thought MS would give them the keys to the kingdom. There was a released version. It was good enough to frighten Intel at the time (which was probably the reason MS did it). Linux sold manyfolds more Alpha's than Windows. - Ahhh, and of course MS found new suckers who bought the same used story few years later (yes, I'm talking about Windows/PPC that lived a very short life). So far, MS failed misserably in the cellular space so there's a good chance their exclusionary move on ARM will only help convince vendors that shipping Androids (and by extension other Linuces) is safer bet. I heard (a rumor?) that MS has 100,000 phones in the public. Granted, it's not much, but it might be a start. If your numbers are correct it means some MS employees and family members were deprived of the right to carry MS phones and still have to use IOS or (shock, horror, awe) Android phones... ;-) -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron No, You Can't Have My Rights, I'm Still Using Them -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Guidelines - creating tarball from VCS with script
On Tuesday, 15 בMay 2012 17:40:27 Colin Walters wrote:
On Tue, 2012-05-15 at 10:19 +0200, Tomas Radej wrote:
Discussion with pingou and sochotni on #fedora-java brought us this: What
about using an RPM macro with this grammar:
%create_tarball git|svn|cvs URL revision [additional commands]
The build system has no network access.
Yes, that's an important feature (so our sources are always rebuildable
regardless of extenal changes).
For the present Fedora/Fedpkg/RPM architecture, you really can't get out
of mashing git repositories into tarballs without a serious
architectural rework of everything.
I think the real needed rework is not in the infrastructure, but
adding a new build mode to rpmbuild(1):
* We currently have:
1. The '-b[bsa]' build from .spec + sources
2. The '-t[bsa]' build from tarball with embedded .spec
3. The '--rebuild' build from SRPM
Notes:
- Modes 2, 3 actually extract the parts and continue as 1.
- Both mode 1,2 can be used to generate SRPM which enable us
to preserve all components in encapsulated form (no fuzzy
external dependencies).
* Which calls for two new modes:
4. rpmbuild -b[bsa] --from-vcs-repo url spec_file
5. rpmbuild -b[bsa] --from-vcs-wc directory spec_file
* Notes:
- Obviously mode 4 would be implemented in terms of mode 5
(clone the URL to temporary wc and use it)
- Just like mode 1 and 2 the '-bs' would enable us to encapsulate
the result as SRPM that would not depend anymore in the vcs repo
or wc -- this SRPM could be uploaded to koji, etc.
- I think trying to abuse existing %prep section and %setup semantics
for vcs use, will create more problems than it solves.
My suggestion is that these command line flags could be used only
if the .spec file also contains *alternative* %vcs_prep
* Example:
Name: acme
...
Source0: %name-%version.tar.gz
Patch0: foobar.patch
...
Vcs-URL: git://something_we_can_clone_from
# Would be used when no --from-vcs-* flags were given
# e.g: when we --rebuild from SRPM
%prep
%setup
%patch0 -p1
# Would be only used for --from-vcs-repo
%vcs_prep
# No %setup (no tarballs here, move along)
# No %patch (the vcs should be used for this)
# Maybe we can have a nice macro for common cases
%vcs_setup
# Or alternatively, can be done manually
git clone [some-special-flags-I-want] %{VCS_URL}
# Both %prep and %vcs_prep would be skipped for --from-vcs-wc
# Only the %_builddir would be set to the given directory
# The rest is normal, since all execution paths now converge
# into a prepared build directory + .spec file
%build
...
Advantages:
* All existing packages are unaffected (but --from-vcs-repo cannot
be used with them yet).
* A developer that work on a vcs-wc can create a package for testing
imediately from her expanded wc.
* A .spec file with the extra %vcs_prep and Vcs-URL can create SRPM
directly from the vcs-repo. This SRPM can be uploaded to our
build system and be used for building *without* any interaction
with the vcs.
Problems:
* The --from-vcs-wc is very handy and can be easily abused to generate
RPM's from non-clean working trees:
- Maybe this mode can mark some dirty flag in the RPM header.
(RPM_WIP_UNRELEASED).
* With --from-vcs-repo there is no clear model to separate upstream
code from packager changes:
- Maybe the solution is to map this information from the vcs.
E.g:
Vcs-URL-upstream: git://server/path master
Vcs-URL-build:git://server/path fc17
Now, is this a science fiction?
--
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il http://users.actcom.co.il/~oron
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld / iptables.service past F17
perspective its installation should IMO behave similar to smolt. I.e: ask for install (default=yes), allow to choose no, if no is chosen, re-confirm with an explanation. * Wishfull thinking for longer-term: - Existing high-level tools, may be persuaded to generate firewalld commands/config instead of low-level iptables config. - As an example fwbuilder already has plugins to generate rules for several engines (iptables, ipfilter, cisco, etc.) in some futuristic pipe-dream it may have a firewalld plugin. Cheers, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Make it idiot proof and someone will make a better idiot. credit: http://www.jr.co.il/humor/signatur.txt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
On Wednesday, 11 בApril 2012 17:49:29 Richard W.M. Jones wrote: On Wed, Apr 11, 2012 at 10:11:40AM -0400, Adam Jackson wrote: So that's a factor of 25ish more data in the Requires list. No, thanks. I'm assuming your argument is that you don't want to ship RPMs or repositories where part of them grows to be 25x larger. I may be wrong, but I think 25x number of nodes in the dependency graph would kill us faster than the size of RPM/yum metadata. Can our SAT-solvers handle this increase at all? -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Mary had a little lambda, Its syntax white as snow, And every program Mary wrote, She wrote in Lisp, you know. -- Karl Pflästerer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)
On Monday, 26 בMarch 2012 11:32:10 Richard W.M. Jones wrote: On Mon, Mar 26, 2012 at 12:57:44AM +0200, Oron Peled wrote: - This means that a Debian/Ubuntu workstation can build both .deb and RPM packages, and we cannot use Fedora for a similar role. Is this really true? What happens if, say, your program depends on PCRE, which has different sonames on Debian/Ubuntu and Fedora (for essentially the same library): You are correct that packaging tools by themselves do not solve *all* portability problems (e.g: Suse/Mandriva/Feodra use RPM, but nobody sane would try to install cross-distro -- even with same package format) However, there are many important working use-cases. Examples: * If the programs or libraries you compile yourselve, use just glibc, you are normally good to go (due to the very strict ABI provided by glibc): oron@squeeze1:~$ objdump --all /lib/libc-2.11.3.so | grep SONAME SONAME libc.so.6 [oron@localhost ~]$ rpm -q fedora-release fedora-release-15-3.noarch [oron@localhost ~]$ objdump --all /lib/libc-2.14.1.so | grep SONAME SONAME libc.so.6 * Noarch packages (perl/python/ruby/you-name-it) * Packaging cross-compiler toolchain/libraries (which is really a special case of the two previous items) * Manipulating packages: - createrepo - downloading/extracting source packages I don't understand how a binary built on one platform could be copied across to the other and work. Moreover, if we have pbuilder on Fedora (which is one of the packages I listed), we are done, as it build in a chroot environment (similar to Fedora's mock). Actually, even when building on a Debian host I always use either pbuilder(1) for unattended builds, or build in an schroot(1) for interactive builds. This enables me to build the same source tree (maybe with pending commits) for different OS releases. [Note: schroot(1) is already packaged in Fedora -- anybody who didn't try it is missing a crown jewl] -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron The future is here, it's just not evenly distributed yet. - William Gibson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)
On Monday, 26 בMarch 2012 13:08:33 Jeroen van Meeuwen (Kolab Systems) wrote: I'm still interested in making available the packages through Fedora repositories proper, but I'm also, admittedly, not paying attention to the review tickets. I have what I need (rubygem-passenger and many others included), and while I'd like Fedora to also make available what I have, I have little interest in completing the slow, lengthy, scrutinizing and therefore painful and time-consuming review process. Understandable. Would you like to assign me as maintainer/co-maintainer? My plan is: - Refresh build for Fedora/rawhide - Refresh source version to what exist in Debian/squeeze as a minimum. (I think Debian/testing [wheezy] is a better match for Fedora release cycle, but I prefer to be conservative at the beginning) - Go through the review process. So, will I get this hot-potato? -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron In theory, it's practical. In practice - it's only a theory. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)
On Sunday, 25 בMarch 2012 20:01:37 Kalev Lember wrote: On 03/25/2012 02:44 PM, Fedora Branched Report wrote: Broken deps for i386 -- [snip] [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper For the past 17 months, each rawhide report has had broken dh-make deps. The package was imported 21 Oct 2010 depending on a non-existing debhelper package and has been broken ever since. Regretfully, you are correct. What's not so clear is how can we *fix* this instead of abolishing all this package chain: * IMO, it's important to have Debian packaging tools for Fedora so it can be used as a more complete development platform: - Currently, there's no problem building rpm's and yum repos on Debian as a development platform, but not the other way around - This means that a Debian/Ubuntu workstation can build both .deb and RPM packages, and we cannot use Fedora for a similar role. * As I mentioned on some of these bug-reports, I'm willing to maintain all these packages (see below). However, I wasn't the one submitting the BR, nor the reviewer. What process should I follow to make this happen? * The following dependency tree would help clarify the situation: https://bugzilla.redhat.com/showdependencytree.cgi?id=591332 - Original packager of all these: Jeroen van Meeuwen Long time the following RR are without any response from him. (some of the reviewers seem also to lose interest) - #591332 - debconf - Debian configuration management system Reviewer: Miroslav Suchý - #591389 - po-debconf - Tool for managing templates file translations Reviewer: Christoph Wickert - #591190 - debhelper - Helper programs for debian/rules Reviewer: Chen Lei - #591192 - dh-make - Tool that converts source archives into Debian Reviewer: Miroslav Suchý (acked, but without blocker #591190) - #591388 - pbuilder - Personal package builder for Debian packages Reviewer: Christoph Wickert * Is someone brave enough to take-over reviewing all these? (Christoph?) I'm definitely willing to work though the review and maintain them all as a unified collection of packages (as the BR in the subject shows, they are useless otherwise). We have the orphan removal process where releng purges orphaned packages and those that have failed to build for 2 Fedora releases. But what about packages with broken deps? Can these stay in the distro forever, even though they are impossible to install and thus unusable? Original package review: https://bugzilla.redhat.com/show_bug.cgi?id=591192 Open bug about the broken dep: https://bugzilla.redhat.com/show_bug.cgi?id=716298 Totally agree with you. If both dh_make and the other RR can be orphaned (can they?), than we'll just need a brave reviewer to work with me on these packages in correct dependency order. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Reality must take precedence over public relations, for Mother Nature cannot be fooled. -- R.P. Feynman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
