(In reply to Pierre Fortin from comment #0)

> install fails on:
> cups-2.0.4-1.3.mga5.x86_64    (in repos)
> gutenprint-cups-5.2.10-5.mga5.x86_64  (already installed)
> hplip-3.15.6-1.mga5.x86_64      (from updates_testing = no such file)
> hplip-gui-3.15.6-1.mga5.x86_64      (from updates_testing = no such file)

Those hplip packages are indeed no longer available, they were deleted from updates_testing.

Before trying to install something, it is advisable to first update your media, e.g. in this screen

http://doc.mageia.org/mcc/5/en/content/rpmdrake.html 

Click on: File => Update media => select all (or the one you need) => update

@ docteam

I don't manage to find those instructions in the rpmdrake page of our manual, but did maybe not have enough coffee.... please check whether the instructions are there.

CC: (none) => doc-bugs, marja11
Summary: After update failure, unable to install updates because files not in repos + workaround => MIssing instructions about updating your media? (Was:After update failure, unable to install updates because files not in repos + workaround)

The instructions are there:
http://doc.mageia.org/mcc/5/en/content/drakrpm-edit-media.html#d4e274

CC: (none) => lebarhon

(In reply to André DESMOTTES from comment #2)
> The instructions are there:
> http://doc.mageia.org/mcc/5/en/content/drakrpm-edit-media.html#d4e274

You're right, thanks André :-)

@ Pierre

The hplip packages that couldn't be installed were already removed from the updates_testing repo over two months ago, see 
https://bugs.mageia.org/show_bug.cgi?id=16498#c41

Instead of updating the media in MCC, the enabled media can also be updated easily by running (as root):

  urpmi.update -a

When normally updating your system, the media are updated as first step in the process. 
However, when installing a printer or installing any package, the media are not updated.

I assume you did not use updates_testing as update medium, so that that medium never got automatically updated?

Summary: MIssing instructions about updating your media? (Was:After update failure, unable to install updates because files not in repos + workaround) => After update failure, unable to install updates because files not in repos + workaround

This begs the question: what justifies putting *testing* updates in the mainstream binaries?  

You are right that I don't use *testing* media, unless it's one of my bug reports; so this was not expected for routine updates.

(In reply to Pierre Fortin from comment #4)
> This begs the question: what justifies putting *testing* updates in the
> mainstream binaries?  
> 
> You are right that I don't use *testing* media, unless it's one of my bug
> reports; so this was not expected for routine updates.

Huh? Please have a look at your first post:

(In reply to Pierre Fortin from comment #0)
> hplip-3.15.6-1.mga5.x86_64      (from updates_testing = no such file)
> hplip-gui-3.15.6-1.mga5.x86_64      (from updates_testing = no such file)
> lib64hpip0-3.15.6-1.mga5.x86_64  (3.14.6-8 installed - updated to 3.14.6-8.1)

If you don't use testing media, how come you saw packages from testing media available? hplip 3.15 packages were only available via the testing repos and they have not been released yet to normal update repos. And currently there are no hplip packages anymore available via the testing repos.

I say that's a cornercase, and you could have removed all the hplip packages via rpm -e --nodeps and then reinstalled all hplip packages from normal repos. Not something that we can really fix.

CC: (none) => doktor5000

Apparently I wasn't clear enough...  I have NEVER used *testing* as install/update sources in mcc.  So, I agree with your "how come you saw packages from testing media available?" -- that was my point and wasn't from anything I did outside of normal "updates available"-notification and apply...

Likewise, I never use "-e --nodeps" -- that would only happen if directed to do so in a bug report.

So that I can look at the internals, what tool(s) allows me to view the contents of the .cz files?  Never mind...  Just did a search for hplip in mcc install and the 3.15* packages no longer show in the list.  They were there a few days ago, so must've been in a synthesis file -- how else could I see them?

BTW, this is not my first rodeo in being burned by install/upgrade issues:
- bug 10162 - x86_64 install | upgrade fails -- looking for 32-bit core...
- bug 16510 - conflicting packages (i586) on x86_64 system
- bug 11826 - install fails trying to access empty update/synthesis.hdlist.cz
- bug 12064 - setup rpm update offers to empty /etc/fstab and /etc/shadow
- bug 13461 - 64 bit Install fails -- boot.iso fails to use specified path to
              find synthesis.hdlist.cz [SOLVED: bad MD5SUM]
- bug 16291 - upgrading from mga4 kernel-tmb-laptop leaves system with mga4
              kernel, and no wifi

(In reply to Pierre Fortin from comment #6)
> Apparently I wasn't clear enough...  I have NEVER used *testing* as
> install/update sources in mcc.  

Updates_testing sources are available, but *disabled*, by default.

It is very easy to accidentally enable a medium in this screen
http://doc.mageia.org/mcc/5/en/content/drakrpm-edit-media.html

However, ticking the box to set it as update medium is not possible in MCC. Your system didn't fetch a new list of available packages for that medium, when checking for updates.

If you agree that you did possibly accidentally enable updates_testing, then please close this bug.

>Updates_testing sources are available, but *disabled*, by default.

I know that and have never enabled them.  In fact, to avoid getting testing packages, whenever I'm directed to try one, I download ONLY the package I'm to test and install it via urpmi.  This bug is related to the use of mcc. 

I NEVER change mcc media sources after initial install or major upgrade (e,g., mga4 to mga5).  I then apply updates almost as soon as they are available, and ONLY by using mcc->Software Management->Update your system; never going into Configure media until the next major release.

>It is very easy to accidentally enable a medium in this screen

Again, can't change what I don't access...  The updates_testing/<pkgs> appeared on their own and disappeared again over the weekend without me doing anything.  In fact, even IF I had accidentally ticked Core Testing Updates, how do you think I could have missed the "This medium needs to be updated to be usable. Update it now? [No] [Yes}" dialog? Not to mention that it would still be ticked unless I also accidentally unticked it...  Rather difficult when I don't go into Configure media...  Too many accidents -- I'll freely admit when I screw up so as not to waste our time; but this is not possible here IMO.  That's why I included a list of previous bugs showing how something as simple as a bunged file creation date (MD5SUM) can screw up the update process, to more complex issues...

This bug was most likely a procedural issue with dependencies because hplip was still at 3.14.6 whilst it displayed 3.15.6-1 in Updates & Install/Remove (w/o *testing) for a few weeks. Strange that it auto-corrected right after I reported it...

All I can do is report it...  it's now corrected; but you can decide to close this report with or w/o getting to the root cause.  I'm fine with either choice for now...

Cheers,

I won't close it, because you're sure you can't accidentally have enabled updates_testing, and that you didn't disable it, either.

Please provide us with the following information:

* What is the current time stamp of /etc/urpmi/urpmi.cfg ?

(So e.g. the output of  "ls -al /etc/urpmi/urpmi.cfg")

* Can you please also attach that file?

* And attach file.txt that is the result of (as root)
 
journalctl --since="YYYY-MM-DD hh:mm¹" --until "YYYY-MM-DD hh:mm²" > file.txt

where YYYY-MM-DD hh:mm¹ is at least one hour before the time stamp of urpmi.cfg, and YYYY-MM-DD hh:mm² is at least 10 minutes after the time stamp, so e.g.:

 journalctl --since="2015-11-15 19:30" --until "2015-11-15 21:00" > file.txt

Thanks

Keywords: (none) => NEEDINFO
CC: (none) => thierry.vignaud
Summary: After update failure, unable to install updates because files not in repos + workaround => updates_testing got auto-enabled (and auto-disabled) without user interference
Source RPM: (none) => urpmi

Created attachment 7210 [details]
/etc/urpmi/urpmi.cfg

[Hope the following makes sense. My dog Trixie was killed in a hit&run Sunday ( I saw it happen & she died in my arms), so I'm an emotional wreck...]

Your request misses some key points, so I'll fill in the blanks...

1. I enabled/disabled updates_testing, which is how I discovered the dialog that I could not miss when enabling -- so file date/time is irrelevant.

2. After disabling, which it is now, "ignore" is not restored -- assuming it should be there:
-----------
Core\ Updates\ Testing /distros/x86_64/media/core/updates_testing {
}
-----------

3. I have a cron job that logs the output of "rpm -qa" daily at 00:00. Based on the output of these files, the initial problem where updates_testing triggered the problem actually happened 2015/10/16 and I got it working again on Sat 2015/11/14 -- the delay was due to printing being low priority, and I didn't want to report something without more info...

# grep cups-2 RPMS.20151???
RPMS.20151001:cups-2.0.2-5.mga5
RPMS.20151002:cups-2.0.2-5.mga5
RPMS.20151003:cups-2.0.2-5.mga5
RPMS.20151004:cups-2.0.2-5.mga5
RPMS.20151005:cups-2.0.2-5.mga5
RPMS.20151006:cups-2.0.2-5.mga5
RPMS.20151007:cups-2.0.2-5.mga5
RPMS.20151008:cups-2.0.2-5.mga5
RPMS.20151009:cups-2.0.2-5.mga5
RPMS.20151010:cups-2.0.2-5.mga5
RPMS.20151011:cups-2.0.2-5.mga5
RPMS.20151012:cups-2.0.2-5.mga5
RPMS.20151013:cups-2.0.2-5.mga5
RPMS.20151014:cups-2.0.2-5.mga5
RPMS.20151015:cups-2.0.2-5.mga5
RPMS.20151016:cups-2.0.2-5.mga5
RPMS.20151115:cups-2.0.4-1.3.mga5
RPMS.20151116:cups-2.0.4-1.3.mga5
RPMS.20151117:cups-2.0.4-1.3.mga5
RPMS.20151118:cups-2.0.4-1.3.mga5

4, As I write this, journalctl outputs only:
-- Logs begin at Sun 2015-04-19 21:31:09 EDT, end at Wed 2015-11-18 10:34:01 EST. --

There is no other output until this entry:
Nov 10 20:51:18 prf systemd-journal[498]: Runtime journal is using 8.0M (max allowed 1.5G, trying to leave 2.3G free of 15.6G available â current limit 1.5G).

5. Found the other entries in the older syslogd's /var/log/messages.

I will upload a merged syslog/journal file shortly...
   (sheesh...  2 new bugs reported while trying to process this one...)

Created attachment 7211 [details]
journalctl output

I suspect syslogd changed over to systemd-journald over the period where the initial cups problem began as there is no relevant data in /var/log/messages... :(

This file does cover the day where I got cups working again.

Nothing in /var/log/messages...  Going through /var/log/syslog now which is much larger... Nothing...

ARGH!!
# ll /etc/systemd/journald.conf
-rw-r--r-- 1 root root 811 Oct 10 07:54 /etc/systemd/journald.conf

Just days before the this cups problem occurred, I changed the journal retention time because I'd run out of space on / 
MaxRetentionSec=1month

(In reply to Pierre Fortin from comment #10)
> Created attachment 7210 [details]
> /etc/urpmi/urpmi.cfg
> 
> [Hope the following makes sense. My dog Trixie was killed in a hit&run
> Sunday ( I saw it happen & she died in my arms), so I'm an emotional
> wreck...]

I'm very sorry to hear that.

I hope the pain will become bearable, soon, and will decrease while the good memories of Trixie will increase and become a comfort.

> 
> Your request misses some key points, so I'll fill in the blanks...
> 
> 1. I enabled/disabled updates_testing, which is how I discovered the dialog
> that I could not miss when enabling -- so file date/time is irrelevant.

True
> 
> 2. After disabling, which it is now, "ignore" is not restored -- assuming it
> should be there:
> -----------
> Core\ Updates\ Testing /distros/x86_64/media/core/updates_testing {
> }
> -----------

Why do you have "current.64" in e.g. those paths:

  Core\ Release /distros/current.64/media/core/release {
    key-ids: 80420f66
  }

and

  Core\ Updates /distros/current.64/media/core/updates {
    key-ids: 80420f66
    update
  }

while there is "x86_64"  in the path for core/updates_testing?

Thanks.  Most difficult loss I've ever experienced & going on 70, that's huge.  Working some bugs today is helping.

>Why do you have "current.64" in e.g. those paths:
>while there is "x86_64"  in the path for core/updates_testing?

Ah-ha...  another clue that I was not using updates_testing.  With mga3/4, I used to point directly to the media. With mga5, I had to download the i586 tree to work a problem where the 64-bit install/upgrade still insists on enabling 32-bit media.  So I added current.{32,64} like this to simplify installs[1][2]:
$ cd /run/media/pfortin/1T-2.BAK/   # external backup/mirror disk
$ ll
lrwxrwxrwx ... 5.32 -> distros/remote/mageia/distrib/5/i586/
lrwxrwxrwx ... 5.64 -> distros/remote/mageia/distrib/5/x86_64//
lrwxrwxrwx ... cauldron.32 -> distros/remote/mageia/distrib/cauldron/i586/
lrwxrwxrwx ... cauldron.64 -> distros/remote/mageia/distrib/cauldron/x86_64/
lrwxrwxrwx ... current.32 -> 5.32/
lrwxrwxrwx ... current.64 -> 5.64/
drwxr-xr-x ... distros/
... = info removed to avoid line wrapping -- only link info is relevant anyway.
[redacted user directories]

The old mga4 link used to be /distros/x86_64/ -> /mnt/hd/..../x86_64.  With mga5, I also gave up trying to maintain /etc/fstab and went with more automatic use of /run/media/...   I've been constantly refining my setups since I first used Linux in 1998; but that's orthogonal here... :)

[1] see https://bugs.mageia.org/show_bug.cgi?id=10162#c15
[2] maybe someday, major upgrades (such as mga5->mga6) will leave urpmi.cfg untouched, so we don't have to redo our local mods each time -- just change current.{32,64} symlinks...  :)

@ Pierre,

I've read your reply many times since you wrote it, but now, after 8 months, I still don't know anything smart to say. :-(

It puzzles me that no one else reported this issue. I'm tempted to think it has something to do with your special setup (with the links), but if there's any proof for that, I'm blind to it.

Anyway, is this particular issue still valid for you?

I hope it magically got fixed, so this report can be closed.

Don't feel bad...  
I have decades of history stumbling upon the most obscure of bugs.  :)

Closing.  Will re-open if I see it again.

Status: NEW => RESOLVED
Resolution: (none) => OLD

(In reply to Pierre Fortin from comment #16)
> Don't feel bad...  
> I have decades of history stumbling upon the most obscure of bugs.  :)
> 
> Closing.  Will re-open if I see it again.

Thanks, Pierre :-)