RFE as to list settings, and more: was: Re: system-config-printer adding Windows printer via Samba
an earlier send of this may have been 'eaten' as the list as an addressee was in a CC. I do not see it in the archive Adam (that 'well-known poster to this list' has decloaked, so I send along my half of the conversation as well) mentioned my prior communication with him, which is set out as at least a couple possib8ilities as to a test case for a Workstation class unit - R On Fri, 27 Apr 2018, Michael Schwendt wrote: > test@ list must be popular. No replies since April 10th > despite a clear subject! What other list these days would > have drawn the attention of someone with interest in > Fedora's printing functionality? Oh -- I don't know -- for reasons unclear,the 'Reply-to' is to the initial poster alone, not the list -- just noticed this That causes list traffic to simply disappear, unanswered RFE to List-Owner: Please alter the Reply-to: test@lists.fedoraproject.org for this list === I have 'cc'd the proper 'owner' identiy -- we shall see. That said, I was corresponding privately with a well known poster to this list about the fact that: acceptance testing did not include a working printer for a 'Workstation' class unit I received a prompt reply thus: > > > the upgrade criteria. That is noted here: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1503321#c7 > > Interesting bug > > I see: > > The decision to classify this bug as an AcceptedBlocker was > made, even though there is no current criteria to warrant > blocking on this. We plan to make a near-future change to the > criteria so that a bug like this from this point on will be > blocker-qualifying > > == > > What IS the process and proper venue / place to seek changes > in blocker-qualifying criteria? Send a proposal to test@ (usually worth CCing to other lists that may be interested too). Ideally include the words 'proposal' or 'proposed' and 'criteria' or 'criterion' in the subject, cos it makes it a lot easier to find it later. You can find lots of previous examples by, well, searching the list archives for those words. A proposal typically includes a general explanation of the nature of the proposed change and the reason for it, and the specific text you want to add or change or remove. Thanks! == I have not gotten back to searching the archives for a 'worked example' to follow yet -- not enough 'tuits' Long form of my prior comment to him was: I am thinking here of a comment ... made a while back, that did not provoke any response, that there was no requirement that printing actually work, much of anywhere I particularly think that a unit in 'workstation' role should: 1. have a working LPR, [and so a matching LPD] to receive print jobs, and 2. either a. (worst choice) catch and route such to root's email as a an attachment print job file via mailx -- bad idea as it fills up /var/spool/mqueue/ [/] /var/spool/mail/ b. (perhaps better) pop up a message that print services are not yet configured, and optionally offer suggestions in a 'want to know more' link c. (best of the lot) if print services ARE configured, hand off the print job to that service I've been unclear about where to champion such a proposed change in release criteria Thank you -- Russ herrold ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
RFE as to list settings, and more: was: Re: system-config-printer adding Windows printer via Samba
On Fri, 27 Apr 2018, Michael Schwendt wrote: > test@ list must be popular. No replies since April 10th > despite a clear subject! What other list these days would > have drawn the attention of someone with interest in > Fedora's printing functionality? Oh -- I don't know -- for reasons unclear,the 'Reply-to' is to the initial poster alone, not the list -- just noticed this That causes list traffic to simply disappear, unanswered RFE to List-Owner: Please alter the Reply-to: test@lists.fedoraproject.org for this list === I have 'cc'd the proper 'owner' identiy -- we shall see. That said, I was corresponding privately with a well known poster to this list about the fact that: acceptance testing did not include a working printer for a 'Workstation' class unit I received a prompt reply thus: > > > the upgrade criteria. That is noted here: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1503321#c7 > > Interesting bug > > I see: > > The decision to classify this bug as an AcceptedBlocker was > made, even though there is no current criteria to warrant > blocking on this. We plan to make a near-future change to the > criteria so that a bug like this from this point on will be > blocker-qualifying > > == > > What IS the process and proper venue / place to seek changes > in blocker-qualifying criteria? Send a proposal to test@ (usually worth CCing to other lists that may be interested too). Ideally include the words 'proposal' or 'proposed' and 'criteria' or 'criterion' in the subject, cos it makes it a lot easier to find it later. You can find lots of previous examples by, well, searching the list archives for those words. A proposal typically includes a general explanation of the nature of the proposed change and the reason for it, and the specific text you want to add or change or remove. Thanks! == I have not gotten back to searching the archives for a 'worked example' to follow yet -- not enough 'tuits' Long form was: I am thinking here of a comment ... made a while back, that did not provoke any response, that there was no requirement that printing actually work, much of anywhere I particularly think that a unit in 'workstation' role should: 1. have a working LPR, [and so a matching LPD] to receive print jobs, and 2. either a. (worst choice) catch and route such to root's email as a an attachment print job file via mailx -- bad idea as it fills up /var/spool/mqueue/ [/] /var/spool/mail/ b. (perhaps better) pop up a message that print services are not yet configured, and optionally offer suggestions in a 'want to know more' link c. (best of the lot) if print services ARE configured, hand off the print job to that service I've been unclear about where to champion such a proposed change in release criteria Thank you -- Russ herrold ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Live CD creator
On Mon, 2 Apr 2018, Adam Williamson wrote: > http://weldr.io/lorax/livemedia-creator.html heh > [adamw@adam tmp]$ rpm -qf `which livemedia-creator` > lorax-28.8-1.fc28.x86_64 so the sources would seem to now reside at: https://github.com/weldr/lorax Thank you -- Russ herrold ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Live CD creator
On Mon, 2 Apr 2018, Adam Williamson wrote: > https://fedoraproject.org/wiki/Livemedia-creator-_How_to_create_and_use_a_Live_CD > provides some help with using it. Good luck! The Documentation link at that page returns a 404 > Documentation > >Important > >https://rhinstaller.github.io/lorax/livemedia-creator.html There seems to be no separate sources at RawHide for 'livemedia-creator' -- in what package does it reside? -- Russ herrold ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
report on the Firefox / Electrolysis induced failures
This came up in Fedora's most recent testing cycle, but the failure mode was not reliably reproducable, and so did not rise to the level of a blocker. I think I have some insight It looks like there is a missing SELinux ruleset problem, causing the hang ups in Firefox, but not all of them, for reasons discussed below https://bugzilla.redhat.com/show_bug.cgi?id=1473754 I see Adam in https://bugzilla.redhat.com/show_bug.cgi?id=1439282#c20 but sadly his conclusion that it is normal, is not true, after doing some tracing of stderr noise, and then looking for why ICP processes were failing ... Selinux ;) Adam mentions a need for fedora-qa testing through SSH tunnels and did so as root, which may have masked some of the noise -- I have a similar process for starting FF only through an ssh tunnel, daily, but it is pretty paranoid and ssh's over to a non-priv'd, and non container of information I would not want to have exfiltrated https://bugzilla.redhat.com/show_bug.cgi?id=1439429 yeah -- I know -- paranoid anyway one culprit is the upstream cutover by FF to 'electrolysis' and its new Inter-Process Communication model. IPC is hard, and in this case SELinux is doing its job, as it has not been told about a need to accomodate electrolysis yet In digging down into the Mozilla development process, it appears they are deploy A B testing, invisibly, and so this is why the changes to the firefox settings: about:config browser.tabs.remote.autostart = false browser.tabs.remote.autostart.2 = false are NOT deterministically appearing -- FF developers have some back end, which is invisible in non-developer mode, which makes a selection process choosing if one is or is not in a test pool, AND silently upstreaming 'telemetry' ;( That sounds like exfiltration of data to me perhaps I an not unjustifiably paranoid starting firefox in a unpriv'd and no content containing 'sandbox' -- Russ herrold ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Getting "error: db5-error(5) from dbenv->open - In/Out-error"
On Wed, 14 Jun 2017, Jon Ingason wrote: > I just installed Fedora 26 Beta 1.4 Gnome Workstation from > Fedora-Server-netinst-x86_64-26_Beta-1.4.iso. Then I did "sudo dnf > update" in terminal window: > > $ sudo dnf update --refresh > Fedora 26 - x86_64 - Test Updates 5.4 MB/s | 23 MB > 00:04 > Senaste kontroll av utgång av metadata: för 0:00:00 sedan den ons 14 jun > 2017 19 > :16:47. > Beroenden upplösta. Tt has long been known that using potentially 'stale' cursor handles, under a scripting language such as Python, which, as we look at the transaction, is modifying the BDB backing store 'underneath itself'. This will result in corruption such as this. An ancient version of 'yum' back in the Seth K Vidal days ran into this as well. This is nothing new, or unknowable as to its source It is not RPM, it is not BDB -- it is incautious coders trying to change the tires on a moving vehicle without adequate precautions, and being surprised when 'bad stuff' TM happens -- Russ herrold ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: F21 emergency.target when root pw isn't set
Chris had contacted me off list yesterday, and surfaced his reply to the list earlier today. This was my response to that piece -- R (Russ speaking, outside of the '' markers) On Thu, 18 Dec 2014, Chris Murphy wrote: I'm not sure what this means. I wanted to document in the ML thread, an alternative approach which you might have used to avoid the unclean shutdown problems you encountered (I did to, as I tried the approach you documented) to the thread, and the d*mn systemd immaturity shows that 'real' admins are not testing the systemd code. The darn thing is just not ready yet, and RH had no business basing its enterprise product off it in RHEL 7 ... Fedora -- sure -- go nuts, and keep all the broken pieces, but not RHEL ;( OS X and Windows have a basic recovery/repair environment that do not require any sort of login to access, and that includes password resetting. the OS/X method I am familiar entails booting from alternative media (a different partition or from media on older hardware, and one assumes from USB on newer, and essentially having a guided loop mount to not just blank, but actually set a new hard passwd in the credentials database). So a variant of my loopmounting and TUI manipulating the sick image under *nix Windows is trickier as the credential 'lives' in a specific hive segment in the registry (post Win 3.51 NT), and may either be blanked, or have a hash of a credential stored on a non-running client primary image, via a recovery instance (sometimes secondary, sometimes media, etc) I'm not really grokking the point of systemd making single/emergency target locked down like this; physical access is assumed because in emergency mode there is no network. And physical access has always meant full access unless the volumes are encrypted. I'm a bit stumped how this is supposed to work without really esoteric knowledge. all great questions / observations, but the systemd folks are not to be criticized. It gets tiresome best regards, -- Russ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F21 emergency.target when root pw isn't set
On Thu, 18 Dec 2014, Chris Murphy wrote: However, after changing the root password, the command reboot is not found. And exit causes a kernel panic! WHen I hit the 'systemd wants a root password' issue, I loop mounted the image I wished to boot, and set the root PW in /etc/shadow to a blanked value (i.e., no passwd) to get around the issue -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to calculate priority for missing tests or %check
On Thu, 27 Feb 2014, Adam Jackson wrote: Btw the URL field in the spec file should be updated to http://cgit.freedesktop.org/xorg/lib/libpciaccess/ Oh yes, another useless rpm feature, I'll be sure to make that my top priority. sneer at it if you wish, but this is a feature of RPM that I use often. Being able to have at least a hint to the web presence of the upstream variant in play, and so to be able to find a security mailing list and such is MUCH easier than trawling through search engine clutter ( the old: .LSM files having fallen out of favor ) -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Tue, 17 Dec 2013, Akshay Vyas wrote: If we can do every QA stuff without being a part of QA group then what's the use of creating a QA group How do you STOP people from doing QA, and reporting stuff either to bugzilla or the mailing list? But I think the issue is that at least one element of 'every' role for a Fedora contributor is not open to me (i.e., voting) without some additional group membership beyond Looking at my accout page at fedoraproject,org, I show only: Signed CLA Group (user) Signers of the Fedora Project Contributor Agreement (user) I have one request not acted upon by a functionally dead sub project, and recall making another request to another which I never heard back on ... but last time that voting time came around, I was unable to do so. My participation in making RH derived distributions predates even the Fedora project itself, having been active since RHL's inception. I was one of the early if not original 'invited' cohort of external 'testers-list' members (2001 era as I recall), former editor of rpm.org, more bug filings thatn I care to count, the first commit for 'sqlite' when it came in for RPM purposes, and so forth Adam, to the extent I am not a formal member of QA group, please take this as my request for addition to such -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, 16 Dec 2013, Bruno Wolff III wrote: The game is to treat QA volunteers like other contributors. That way they don't have to also become packagers (or something else) in order to participate in Fedora Elections or make use of resources limited to people who are in more than just the Fedora CLA group. ... fwiw, this list is about the only Fedora list I actively read anymore in near real time. I am not directly interested in the various other roads into gaining 'elector' capacity because of the time commitments implied If there is a 'game afoot' by Adam, it is one of which approve if the end result is as Bruno outlines -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Moving away from reporting to RH bugzilla and adopting pure upstream reporting mantra.
On Tue, 24 Sep 2013, Jóhann B. Guðmundsson wrote: Really... Let's run a simple query against bugzilla for bugs in the status NEW ( as in not looked at ) and find out the oldest report from our reporters ... What does a count of the number of bug reports have to do with the bug tracker used? If there are too many packages in Fedora, cut them back If there are too few people fixing bugs, figure out if the project design is attractive to potential maintainers If the release cadence is too fast, slow it down If a moratorium of changes on favor of bug fixes is needed, call for it ... but NONE of this has more than a passing relation to the (subject line) proposal to change bug trackers used This thread needs to be refactored (or just die). People are arguing just to hear themselves talk. If it is just about 'winning' or being vindicated, there is no purpose for it here -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Draft terminal application test case
On Wed, 31 Jul 2013, Jóhann B. Guðmundsson wrote: How do you define a terminal as a crucial app for any desktop? Let alone at alpha when the user can always boot into the multi-user target for a terminal and ctrlaltF2? and that keystroke sequence works in a VM across a TLS protected connection, just how? We probably deploy 500 VMs to each new tangible one -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Really big software installation dialog: Bug or Feature ?
On Tue, 5 Feb 2013, Robert M. Albrecht wrote: I'm running rawhide on a system attached to a 27 display with 2560x1440 pixels resolution. Some application like the package manager or firstboot are running within a maximized window which is really huge, inconvenient and wastes a lot of screen space. The gui elements are scattered and easy overlooked, as the Apply changes button is literaly a mile away. I consider such behaviour a usability bug and filed on anaconda: https://bugzilla.redhat.com/show_bug.cgi?id=906431 Probably each application that needs to have sizing controls, needs to be filed separately hth -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Spamd won't listen to spamc
On Mon, 21 Jan 2013, Chuck Forsberg WA7KGX N2469R wrote: ]: spamd: unauthorized connection from omen.com [70.89.176.169] at port 55566 at /usr/bin/spamd line 1271. Jan 21 02:03:51 omen spamd[25898]: prefork: child states: II :0fw |spamc ... As has been the case for the last 6+ years, the calling spamc has been on the same machine as spamd. Something has changed in Fedora 18 to break it. Times change, and the new kid is: ... systemd I would be suspicious of a corner case of systemd, and it not handling the external interface connection, but ... that needs some research first To partition the problem, perhaps change your iptables to pass all on that IP, add a spamd 'listening interface' rules [/etc/sysconfig/spamassassin -- a '-i' option, although the man page implies all interfaces are neing listened on to accept your boxes 'external' IP, and change your spamc connection to use 127.0.0.1, all come to mind -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Anaconda and network-attached storage devices
On Fri, 27 Jul 2012, Petr Schindler wrote: It is a big problem. Lot of things will be broken (won't be in new anaconda for F18, but should be again in next releases, hopefully). ... ... and I hope that the discussion within this threads will lead to some action - for me it would be better to wait, but it looks like we could wait another six month. 'hope is not a plan' -- Here's a use case discussion ... A couple weeks ago, I had to do a system recovery on an older unit, where a partition containing the binaries one needed developed drive errors recently. It was old enough (F12 era), I could use the trick of booting with: init=/bin/sh to get the unit up 'enough' that I could do FSCKs and fix libraries enough to get ssh and rsync running, and so suck off the content not covered by backups (a couple of weeks of delta) 'across the wire'. The unit happened to be up at a datacenter, and so inconvenient to simply 'pull the drive' out of, for data recovery With the cut to systemd, none of us has those kind of 'tricks' at hand yet, and a media boot into 'rescue mode' with a kernel 'close' to what one is repairing, is pretty well mandatory. It is probably possible to do so via PXE, but would be extrordinarily cumbersome to document in the general case It may be that a live CD will turn the trick for rescue modes, but the reason one falls back to install media (and 'rescue mode') is for hardware and LV fixup/ drive detection, and finally being able to chroot into a sick drive ... that is, to perform the rescue The absence of TUI rescue may be OK is RawHide (where it is permissible to eat kittens for breakfast), but not for a formal release, I would think ... perhaps a separate 'Recovery disk' ISO might be spun, with the F17 anaconda but F18 kernel, and ancillaries? I 'get it' that it is cumbersome to maintain two paths, but without some way to address recovery, I have to think that well-advised folks will simply 'give a pass' to a 'risky' F18 - Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fc18 Nightly LiveCD / 20120619
On Tue, 19 Jun 2012, Dennis Gilmore wrote: do note that livecd-tools are no longer supported. f18 will be using livemedia-creator to make the livecds i susoect you wont see the old tools fixed. I do not see a package for: livemedia-creator in bugzilla, nor does my local mirror of RawHide disclose such a package. What SRPM holds: livemedia-creator ? Thank you -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fc18 Nightly LiveCD / 20120619
On Wed, 20 Jun 2012, Bruno Wolff III wrote: # rpm -qf `which livemedia-creator` lorax-17.26-1.fc17.x86_64 thank you -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fc18 Nightly LiveCD / 20120619
On Thu, 21 Jun 2012, Amit Saha wrote: On Thu, Jun 21, 2012 at 5:09 AM, R P Herrold herr...@owlriver.com wrote: On Wed, 20 Jun 2012, Bruno Wolff III wrote: # rpm -qf `which livemedia-creator` lorax-17.26-1.fc17.x86_64 I tried using livemedia-creator a while back and ran into a number of issues [1]. If you succeed, do share your findings. Lorax appeared around F15, and has a later Python usage which prevents building on older CentOS (my primary environment, where I would build images) /usr/bin/env python setup.py build File setup.py, line 30 finally: ^ Not clear that back porting will work here, but we will see As to the issues you have encountered, Amit, I would encourage you to file bugs at: https://bugzilla.redhat.com/ along with reproducing cases, and as possible, fixes (a form of sharing ** your ** findings ;) ). Without such reports, the developers do not know your pain points -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F17: wvdial crash
On Sun, 15 Apr 2012, Pedro Francisco wrote: wvdial is crashing when trying to start a connection. Modem = /dev/ttyACM0. $ sudo wvdial -- WvDial: Internet dialer version 1.61 -- Cannot get information for serial port. this looks ominous ... is there a SElinux intercept from some need to re-label? (I built and installed a fresh WVdial from RawHide last week, and so the package itself seems working) -- Initializing modem. -- Sending: ATZ OK -- Sending: ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 OK -- Modem initialized. given the error return noted earlier, something in WVdial may be in an undetermnined state, and until that earlier matter is addressed, it is not too surprising that a program later dies wvdial: utils/wvtask.cc:409: static void WvTaskMan::_stackmaster(): Assertion `magic_number == -0x123678' failed. Does anyone have any idea of what it is? -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
