Stephen John Smoogen writes:
> I would talk with the mirrors in your area and find out why they don't
> mirror it.
Do mirror sites have the option to not include sources? [*]
If so, does letting them have this choice have GPL implications? I
mean, if they're distributing binaries without makin
> What's the rationale here? I mean, we have so many dependencies, if
> you want to minimize them, you have a lng way to go...
When I bootstrapped Fedora for ARM way back when, I had to deal with
these dependencies. A lot. Finding a minimal set of RPMs to
cross-compile to get a bootable cor
> If I saw systemd-filesystem installed, then I would think that
> something needs to be placed into the systemd folder structure,
Perhaps the bug is this: that you need to install a whole other RPM
just to make a directory exist so you can put a file in it.
Why can't the RPM providing the file
> The coding in assembly is necessary currently?
Yes, but only for limited cases where a higher level language is
inappropriate or insufficient.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject
> that question makes no sense at all and it's the wrong mailing-list
The question made sense to me, and where else would one discuss
development besides a devel@ list?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Condu
> For the journal you always keep all log history in it's original
> state
On low-bandwidth systems, like laptops or diskless nodes, it's a
performance hit to generate the log entry in the first place. It's
really important to be able to configure the system to *generate* a
minimal amount of com
> Why not? The user surely knows better what a good password is than the
> software does. If the user picks a crappy password, there's probably a good
> reason.
You have an alarmingly naive understanding of our user base...
(not that *I* want to give up control of my passwords, but I'm not an
Neal Gompa writes:
> Oh man, that takes me back! I started on DOS with the MS-DOS Editor,
> then went onto the DOS port of Emacs and using DJGPP, then jumped to
> Linux years later...
Now *that* takes me back to the days when I wrote DJGPP ;-)
And for anyone who thinks vi is hard to use, try the
> Where is the hardware?
-- development boards --
BeagleBoard
PandaBoard (dual-core 1GHz, 1GB)
PandaBoard ES (dual-core 1.2GHz, 1GB)
You can buy the above at digikey, they've been shipping for a while.
They come with Ubuntu Desktop, just add keyboard, mouse, and monitor.
Raspberry Pi - slower,
> From what I know about the Fedora on ARM,
Please check your "what you know" against the current situtation, it's
very easy to let obsolete impressions carry forth, but they're no
longer applicable.
> they use a rather scary looking pile of development boards with very
> poor I/O.
Buy a trimsl
> always with the caveat that you can't just use "make -j 288" on them.
Why not? Multi-CPU machines is very old technology.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> Glad it works for you, but I need a real system, like a Netwinder.
So buy a trimslice and use the internal SSD or sata disk. The
trimslice has everything the netwinder has (and more), and uses half
the power.
http://trimslice.com/web/
--
devel mailing list
devel@lists.fedoraproject.org
https
> So I see, thanks. DJ's original suggestion was too forceful in insisting
> on iSCSI.
Sorry, I'm a big fan of iSCSI on trimslices. The SATA interface is on
USB but the gigE isn't, so network (iscsi) is about 3x faster than a
local disk, if you have a big raid server on the other end.
I have tw
> i.e., by buying a Trimslice, you give money to The Enemy!
What a horrible thing to say about a company that's put a lot of
effort into supporting their products on Free Software platforms!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/deve
> Any particular reason why you boot the thing via tftp? I'd expect
> just having /boot on the sd card (which you need for boot anyway) is
> easier, especially when it comes to kernel updates.
I wanted the minimum on the sdcard (it just has the tftboot script)
because our build farm only has one
> Which leads me to a rant about ARM. G RANT!! I didn't think
> I'd ever love the BIOS, but compared to the alternatives (UEFI and a
> million different ARM bootloaders) it's simple and effective.
This is getting way off-topic, but... most linux-capable ARM chips
support a BIOS in the "pc"
> Given that the "pc" sense of BIOS includes having arguments returned in
> x86 registers, I really don't think that's true.
ARM has registers too...
My point is, the ARM chips *do* support an on-board flash bootloader,
and there's no reason why that bootloader couldn't export a standard
ABI th
> The rules are, it has to be rack mountable hardware
Hmmm... how many Raspberry Pis can we fit in a rack?
And at $35 each, spares would be cheaper than a warranty ;-)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> I don't think those were ever targetted as the ARM builder hardware
> that would go in PHX2. Jon mentioned "enterprise class" ARM servers
> numerous times. I was assuming that meant rack mountable.
It was a joke! Don't you people have a sense of humor?
--
devel mailing list
devel@lists.fedo
Ok, giving money won't work, and the tax stuff is a mess. Let's
ignore that for a second.
What about equipment?
Consider: if a box showed up at PHX, which contained hardware that met
the technology requirements of PHX, with a note that said "here,
yours, no strings attached" - what would happen
> To be clear, it would be used but ownership still resides with whomever
> purchased the hardware.
Really? You can't donate hardware, you can only let Fedora borrow it?
If you sponsor catering at a con, do you need to get the food back at
some point too? Sounds like a silly distinction.
--
de
> Used. There is a process for donating hardware in place, and it's been
> used before.
Ok, so it sounds like there's a method in place for entities-with-cash
to use that cash to benefit Fedora, as long as they are OK with not
getting the tax break and they're willing to go through a little
eff
> Hardware is likely classified in tax code as an asset, where as food
> at a conference is not.
Well, it's an asset until you eat it :-)
Ok, that explains things. Legal technicality, but still a workable
process.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.
> Seems that some people unhappy with the "Beefy Miracle" are trying
> to make sure that we won't ever had any nice and fluffy codename.
I voted against all the names that sounded like Ubuntu copy-cats.
Ubuntu names have always been (intentionally) adjective-noun, Fedora
names have always been a
> Is LLVMpipe needed on, say, ARM? (Does anyone have a screenshot of
> GNOME Shell running on such a system?).
Is this close enough?
http://www.delorie.com/arm/f15-gnome-on-olpc.jpg
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> > Is this close enough?
> >
> > http://www.delorie.com/arm/f15-gnome-on-olpc.jpg
>
> That's GDM, and so useless unto the purpose. It's not accelerated.
I could log in and got the fallback shell, but it all worked
sufficiently well.
--
devel mailing list
devel@lists.fedoraproject.org
https://
> o Default web browser: A web browser is not installed in any image.
> Suggestions for a suitable browser welcome. Todo.
> o Desktop testing was minimal but breadth is incomplete (no web
> browser). Todo.
I did install and test firefox, it worked fine, including installing
add-ons, downloading
> Right- followup question: Is Firefox what we want in the X images?
What's the default browser for x86 ?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> Maybe we should draw more of a distinction between LLVM and clang,
> and use ExclusiveArch: on the latter to whitelist only architectures
> we feel comfortable supporting?
That would only make it worse, for surely x86-32 and x86-64 would be
whitelisted, so most developers would "just use clang
I'm going to chime in once to add my thoughts... It's already way too
late for me to influence the decision (first I heard of it is "it's
decided") so my only recourse is to add it to the long list of things
I have to "undo" after installing Fedora.
> Sorry guys, this feature sucks.
+1 on this
> The feature may be adopted/promoted on the basis of SSD writecycle
> preservation,
I'm about to put in an SSD boot disk, so I care about this argument,
but I'm still not using tmpfs, for my reasons stated previously.
> but tmpfs also offers considerable performance improvements for
> workloads
> If they really aren't transient then /tmp is the wrong place for them.
I will categorically disagree with any argument of the "the user
shouldn't be doing that" type. Software exists to serve the user, not
the other way around.
Besides, I often don't realize that a file isn't transient until
> I am not sure asking is the right thing, I think tmpfs in RAM should
> be an *optional* supporte dfeature for those users that have a
> workload that *will* benefit from this feature and therefore *will*
> seek it.
It could have been as easy as a checkbox in the disk partitioning screen
of the
> Your quoting removed the fact that I was responding a statement that
> ram was the "wrong place". I was simply extending the comment. If
> you're willing to say that ram is the wrong place for something then
> there is nothing user hostile to say tmp is too.
"Wrong" in general has been used he
> it's a bad design to ask the end user about this kind of thing
> during installation.
IIRC, I suggested a checkbox in the disk partitioning page, where
we're already asking the user all sorts of questions about the
filesystem layout and mount points (including putting /tmp on a
separate partiti
> Since you can look at it either way in that regard, it's completely
> reasonable to have the option that's best for most users as the
> default. As I see it, that's to enable tmpfs for /tmp .
Given a choice between "works for everyone" and "works well for most,
but fails in obscure ways for som
> Additionally, it's been turned on in rawhide.
Rawhide nightlies have been failing, though, so how do we test this?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> Why do we care about using the Firefox trademark? We should just
> rename the package. Debian do that and it hasn't hurt them.
Debian has different core values than Fedora does. The relevent
Fedora value is this one:
Friends
We believe success comes from a strong community, made of peo
> A party who is molesting me with ads and tries to spy on me, hardly
> is my friend.
Those are strong words, and based mostly on here-say. Even the Fedora
installer "molests you with ads" for various non-default packages.
Should we ban the installer? Of course not.
There are specific issues t
Forcing the users to type a different command name to get exactly the
same functionality only serves to annoy the user.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Nothing will change for you, the yum command will still exist for a
> few more Fedora releases,
Which only postpones the problem.
> just as the `service` command that was superseded by systemctl like
> 5 releases of Fedora ago exists.
Which is currently annoying me, for the same reason.
--
d
> Actually it is. The "pretty much" part is exactly the reason why to
> change the name. If we didn't, a ton of users who are not reading
> this conversation would start filing regression bugs. If we set
> their expectations right, warning them that yum is no more, they are
> far less likely to do
> If you have any other suggestions other than keeping the name, we
> will be open to consider them.
My suggestion is to keep the name, but as you're not open to that
option, there's no point in me bothering, is there?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproje
> Welcome to the 21st century!
Do we have different eyes and brains than we did last century?
Because otherwise, excessively wide paragraphs are just as hard to
read now as they were then.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> > 1) Some magic command to run after remove to remove the now unneeded
> > cruft.
>
> The vast majority of users don't care about saving that $0.0001 of disk
> space, so never need or want to run this and don't.
One would hope (assume?) that there's something to keep dnf from
thinking I no lo
> If the package yumdb entry (now dnfdb) says it was installed as a
> dependency
This is the part I assumed was there.
Is there a separate dnf command to list all installed-as-dependencies
that nothing depends on any more?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedorapr
so do electronics, woodworking, and metalworking as
hobbies, so I tend to show up in lots of forums...
In my new role at Red Hat I'll be focusing more on glibc work, so
expect to see me poking my nose around there too now :-)
DJ Delorie
work: d...@redhat.com
personal: d...@delorie.com
fedoraprojec
> Hey D.J.!
And not to point you out, but I should have clarified this... my first
name really is DJ - it's not Dj or D.J. or DeeJay or any other
variation (although my account names are always lower case dj). Yes,
I have legal proof of this, and no, I won't share it ;-)
DJ
--
devel mailing lis
> 2012/8/22 Richard W.M. Jones :
> > broken tmp on tmpfs
>
> Could you give a reason why you think so?
Can we not repeat the VERY long thread on why this is/isn't a broken feature?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> * /root was initially on a root partition because 'root' user should be
> able to login even when all other FS (including /usr) are not mounted.
> Since now it can't do anything without /usr anyway, /root dir don't have
> to be in /.
As an example of why this is a bad idea...
I have a file ser
> i will look at throwing together a script to give us some comparisons
> between the build times on the different arches.
I've already done this, last time it came up...
http://www.delorie.com/arm/koji-compare-build-times.tar.gz
--
devel mailing list
devel@lists.fedoraproject.org
https://admin
> > http://www.delorie.com/arm/koji-compare-build-times.tar.gz
>
> HTTP request sent, awaiting response... 403 Forbidden
> 2013-07-12 08:53:13 ERROR 403: Forbidden.
"wget" is blocked unless you're clueful enough to use the -U flag.
Consider it a spot check for "smart enough to not recursively do
> i will look at throwing together a script to give us some comparisons
> between the build times on the different arches.
> I've already done this, last time it came up...
> http://www.delorie.com/arm/koji-compare-build-times.tar.gz
Also, I'm running the script now, I'll post results when it fi
> Also, I'm running the script now, I'll post results when it
> finishes, let's not ALL hit the koji database at the same time ;-)
Results here:
http://www.delorie.com/arm/f19-times.html
includes the raw time data from koji
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fed
I worry about the security implications of mail that would have gone
to root@ being either silently discarded or unknowingly ignored.
If there is no other way to send mail to local users, we should have a
local MTA configured for such.
--
devel mailing list
devel@lists.fedoraproject.org
https://
I think this is a bad idea, at least for my setup. I really don't
want my small expensive boot SSD being beaten to death trying to cache
a multi-terabyte array, especially since I have plenty of RAM that
already serves that purpose (the machine rarely reboots).
At the very least, this feature sh
> But these core parts should work for 100 % users. In all cases, which
> are in scenarios you can imagine. And in 90 % of scenarios you can not
> imagine. Or in scenarios, which are anecdotal for you.
+1 - anything which reduces the tools we have to repair systems or
investigate security
> And the outputs of these files are the exact same text streams you are
> used to. However, enhanced with a lot of niceties that make them more
> user friendly. For example, you get colors based on the log level, or
> there's a line drawn between reboots. You get the time zone corrected,
> and yo
> it's not going to be shoved down your throat.
I've found this to be untrue in Fedora.
> > At the very least, this feature should be disabled if the
> > SSD is the boot/root drive. When SSDs fail, they fail
> > completely, and it's irresponsible to cause early failure
> > on a drive that's cri
> If your package reports disk space usage to users, and bases this on
> filesystem free space, please consider whether it might need to take
> LVM thin provisioning into account.
Perhaps you could include a small code snippet explaining *how* to do
this? Is there an lvm_thin_statfs() we can use
> FWIW, if you log in to https://badges.fedoraproject.org/ and visit
> your profile,
I got "Internal Server Error" when I tried this... and now I'm on the
home page, when what I really wanted was to make sure I had nothing to
do with it :-P
> you can opt out of all badge-stuff in one click ("De
> Oh no! Sorry about that. I just tried it too but I couldn't
> duplicate the error.
It worked this time, must have been new-account-mess.
> > > you can opt out of all badge-stuff in one click ("Deactivate
> > > Account").
> >=20
> > Does this deactivate your FAS account, or just the badges?
>
> That said, please don't top-post: [1]
Also, please trim irrelevant material [1]
> [1]
> http://fedoraproject.org/wiki/Mailing_list_guidelines#If_You_Are_Replying_to_a_Message
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Co
I'm WAY out on the bell curve...
I have two PCs. One of them, the one I sit in front of, has four
monitors (on one Radeon HD card), video capture and playback, digital
and analog audio (digital goes to a surround system receiver, analog
to gaming headphones), an SSD plus a dual-3Tb raid1 all in
> ## Use $MOZ_TMPDIR if set. Otherwise use /var/tmp instead of /tmp
> ## because of 1GB /tmp limit in Fedora 18 and later.
>
> It is insane to hardcode /var/tmp.
Considering the comment, they probably think it's insane to put /tmp
in RAM, and since web browsers are often used to download huge
If at 9:50am on release morning, aliens threatened to blow up the
world if we shipped, we'd certainly do something about it.
But it would be insane to expect us to *document* that we'd do
something about it.
IMHO it's perfectly reasonable for documented policy to simply say
"bugs after this poin
> So what you're saying is that you negotiate with terrorists? :-p
"Anyone else want to negotiate?"
(sorry, couldn't resist ;)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> Stack protector is not a new requirement in Fedora. It's been part of
> the distribution for years.
xterm has been part of the distribution for years also, but it's not a
release requirement.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/
Lennart Poettering writes:
> Sorry, but systemd is pretty exactly this: a process babysitter.
It's becoming a user nanny instead. I wish it would stop trying to
enforce its "my way or the highway" approach to system rules. I've been
playing whack-a-mole trying to keep up with all the tweaks I
Lennart Poettering writes:
> Again, as mentioned before: key here is that permitting user processes
> to stick around after all sessions of the user ended needs to be a
> privilieged concept. It should not be allowed for user code to stick
> around after logout, unless this is explicitly permitte
Lennart Poettering writes:
> Again, this isn't just work-arounds around broken programs. It's a
> security thing. It's privileged code (logind, PID 1) that enforces a
> clear life-cycle on unprivileged programs.
You're making three invalid assumptions here:
1. You're assuming that such programs
Not sure where to send this, but...
From 1280b78688baaf9a576af5a0a0a658fd0f0ea7e4 Mon Sep 17 00:00:00 2001
From: DJ Delorie
Date: Fri, 17 Jun 2016 19:27:55 -0400
Subject: Fix FTBFS due to gcc and glibc updates
- comment out tautological asserts that gcc 6 complains about
- replace readdir_r
> How about
> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=ltrace
Done, BZ 1347879
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Nico Kadel-Garcia writes:
> It's certainly a direct violation of the intent of the GPL licensed
> tools that form so much of the base of Fedora's build environment.
The GPL3 no longer requires us to provide tools used to compile such
objects, as long as such tools are general-purpose and used unm
> U.S. rural areas? :-D
I'm pretty rural, and even I have good internet. Maybe we need to
redefine "rural" to be independent of physicality :-)
> Based on feedback from Ambassadors, DVD images may still be useful
> giveaways in regions with less access to bandwidth. I'm not sure what
> to do ab
> Hmm, we still have xmms in the repo?
/me is very glad we still have xmms in the repo
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> Have you tried using Audacious ?
Just did. No thanks. /me uninstalls those five RPMs...
> You can set it to classic mode, at which point it user experience is
> identical to xmms.
No, it's not. It's close enough to fool someone who doesn't use xmms
regularly, but it's different enough to r
> But, e.g. if openssl is updated for security issues, all dependent
> services need to be restarted. If not, you're still e.g. vulnerable.
> That can't be your wish.
Ah, but if sshd is restarted in the middle of the update, and you
ssh'd into the machine to do the update, it kills the install ha
> and change my Firefox and emacs cursors.
And now I have to restart my entire session to reset my gtk themes,
because of one rogue app. Thanks.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> You have other serious system issues not affiliated with Audacious if
> this is the case.
If "I don't run gnome" is considered "other serious system issues", I
suppose so.
Restarting didn't help, I still had the wrong cursor in emacs and
firefox, but only the emacs and firefox run remotely bac
> Well, it looks like you aren't running ANY desktop environment,
fvwm2, emacs, firefox, xterm. Plus a few other things as needed.
This is for two computers running four monitors (one computer is the
local one with the monitors, the other is strictly ssh and remote X,
each computer has its own d
(subject changed, please strip the [was...] when replying)
> On 13/02/13 10:15 AM, DJ Delorie wrote:
> > (well, more like crap, since I still haven't figured out how to
> > get pulseaudio to use my digital audio outputs).
>
> Really? It's not that hard. It'
> We nowadays live in times where BIOS POST takes 500ms,
HA! I wish mine was that fast. With all the different BIOS chips
doing thier own thing for all the add-on cards and peripherals I have,
it takes about 45 seconds just to get to GRUB at all.
--
devel mailing list
devel@lists.fedoraproject
> That's also a questionable "feature". Such a text box should not send
> anything before you confirm it.
Perhaps as part of the firewall installation step, the user could be
given a list of sites that their PC may "call home" to - including
official repos - and let them opt-in or opt-out accord
> Ugh .. sorry but that's the worst suggestion so far. No image the user
> goes to http://addons.mozilla.org/ to install addons ... it won't
> work. (just one random example but you get the idea).
I imagine the user would change the start page to about:blank, then
open the firewall, then everythi
> Not every user understands the connection between "website does not
> work" -> "firewall configuration"
True, which means that we have to use words that they *do* understand.
For extra coolness, a per-user firewall and some way of popping up a
query dialog when they violate a firewall rule. "
> Next time, don't be 6 month late if you're going to be flippant.
I, for one, am happy to welcome our new more-reasonable-less-paranoid
overlords. I've been disabling my firewall for ages, as my machines
are behind an enterprise firewall anyway.
--
devel mailing list
devel@lists.fedoraproject.
> > I, for one, am happy to welcome our new more-reasonable-less-paranoid
> > overlords. I've been disabling my firewall for ages, as my machines
> > are behind an enterprise firewall anyway
>
> that don't apply for a notebook, especially not if the enduser is=20
> connected to a public WLAN and
> So the target audience has shifted from developers to developers who
> don't understand ports, don't like user prompts and are behind
> enterprise firewalls.
Certainly not. I've never assumed I was an "average user". There are
many different reasons why people might want a more open firewall
> The best analogy would probably be a condom with a whopping 129024
> holes in it.
That's a horrible analogy, and totally inappropriate for this mailing
list. Could we please keep this civil and reasonable?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mai
> and developers deserve a better environment.
No, developers deserve the environment they ask for, not what someone
else thinks is "better".
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.or
> > So if we truly want to address this feature, we should also disallow
> > non-root user password based ssh logins.
>
> Do I get this right? You want to disallow any remote logins (which
> nowadays means using ssh)?
No, he means that ssh connections should require a pre-shared key. My
systems
Can you wildcard the greylist so that modemmanager *never* runs? I
haven't used a modem in decades but MM keeps mucking with all my
serial-connected toys.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fed
> But better yet, mind sharing which toys you have so we can update the
> black/greylists as appropriate?
I make them myself using FTDI chips, usually, and they talk plain
RS-232 using terminal emulators and such:
http://www.delorie.com/electronics/
I also get a lot of eval boards with usb-seri
Igor Gnatenko writes:
> Why do you want to build such packages for EOLed distro?
Because he's a nicy guy and it's an important patch?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
I'm in, at least for chatting and such. I've got a Rostock MAX V1 delta
with a custom Repetier 0.92 firmware and a few hardware mods, and use
OpenSCAD, slic3r (modified), and pronterface to drive it.
http://www.delorie.com/photos/3d_prints/
--
devel mailing list
devel@lists.fedoraproject.org
htt
Tomasz Torcz writes:
> Shouldn't that be /usr/lib/distro.repos.d (for distribution-provided
-1
Having such a small amount of information spread all over the filesystem
only makes things harder to manage. Keeping it in one place means the
whole "where am I getting stuff" question can be answer
Jan Kurik writes:
> Note that coredumpctl is intended as a developer tool,
As a developer, I remove abrt and anything else that redirects cores
away from my development area. It's really hard to debug a core dump if
you can't find the core file.
Just sayin'
Zbigniew Jędrzejewski-Szmek writes:
> You still can restore such behaviour pretty easily. Just set the
> kernel.core_pattern sysctl.
Yup, that's what I do. Just adding my two cents on Fedora trying to
help me "be a developer" without doing what I need as a developer.
But I typically uninstall
"John M. Harris Jr" writes:
> it is important that issues such as this can be talked about publicly,
I disagree. It has nothing to do with Fedora development[*], and allowing
EITHER side to continue this "discussion" allows either side to badger
and bully the opposition until people comply jus
1 - 100 of 136 matches
Mail list logo
