16:17:48 <itchka> #startmeeting
16:17:48 <chwido> Woof! Let's start the meeting. It's Wed Feb 21 16:17:48 2018 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:17:48 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:17:48 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:17:48 <chwido> Have a good meeting, don't bark too much!
16:18:00 <itchka> #item 1
16:18:42 <itchka> #topic Cooker report and rpm
16:19:09 <bero> So from where I stand Cooker is starting to work again after the Qt update...
16:19:15 <bero> still needs a few more rebuilds
16:19:47 <bero> for rpm, we're getting ready to make the move, but essentially waiting for a good time when all of us are around to fix things if they break badly
16:19:59 <itchka> bero: Anything big? I saw that float 128 is kicking around again
16:20:22 <bero> where? I haven't seen that one since glibc 2.27-4
16:20:57 <_TPG> fdrt: hi, latest docker does not work on 3.x
16:21:12 <itchka> Maybe I have old news I saw _TPG and crisb talking about it.
16:21:18 <proyvind> bero: what kind of extra attention are you paying when switching to rpm.org? I assume it won't qualify for a mere drop-in replacement? :o)
16:21:20 <_TPG> fdrt: returned error: OCI runtime create failed: flag provided but not defined: -console-socket: unknown"
16:21:46 <_TPG> itchka: bero yes glibc-2.27-4 segfaults on 3.x on i586
16:22:33 <proyvind> ie. are there any rpmdb compatibility issues?
16:23:28 <bero> proyvind: already got rid of a couple of things that are known to work differently (mostly inline python stuff), and adapting filetriggers etc. -- most stuff is expected to continue to work, but of course rpmdb will be really messed up to the point that we'll probably have to some variant of "rpm -qa >dump ; rm -rf /var/lib/rpm; urpmi `cat dump`"
16:23:58 <proyvind> b
16:24:03 <bero> _TPG: We need to switch i586 -> i686, that's what fixed glibc-2.27-4 segfaults on cooker. Looks like just about every upstream doesn't care about i586 anymore
16:24:23 <proyvind> bero: ouch, that sounds like a really awfully crude "conversion"..
16:24:24 <Pharaoh_Atem> bero: I believe tmb has a few patches in Mageia for i586 fixes, but more or less yeah
16:26:24 <bero> proyvind: It is... but it's doable that way and allows us to move on without having to invest even more manpower we don't have. Obviously can use --justdb etc. to make it a little less crude
16:27:15 <bero> Pharaoh_Atem: my preferred fix is to just switch to i686 -- it's not like there are any i586 boxes that have enough RAM to run a modern distro in anything but text mode anyway
16:27:22 <Pharaoh_Atem> true
16:28:59 <proyvind> bero: such hard measures shouldn't be necessary, I think merely using dbconvert was sufficient when I installed mageia into guest chroot environment from cooker rpm5 host environment..
16:29:31 <Pharaoh_Atem> bero: I've pushed the proposed libdnf packaging to the packaging repo
16:29:41 <proyvind> the trigger implementation is the biggest incompatibility issue IIRC
16:30:07 <Pharaoh_Atem> at least from the chroot point of view, it doesn't seem to be a problem
16:30:15 <Pharaoh_Atem> so we can rebootstrap the system and switch trigger implementations
16:31:28 <Pharaoh_Atem> bero: I'm working through pushing proposed packaging for dnf, dnf-plugins-core, and dnf-plugins-extras
16:31:56 <proyvind> the different trigger implementation isn't that big issue either, besides not firing between different implementations..
16:35:10 <bero> proyvind: do you have any details on the dbconvert thing? That would indeed by nicer if we could get it to work
16:35:46 <Pharaoh_Atem> does our live media use a special dracut module, or the standard dmsquash-live stuff?
16:35:55 <proyvind> well, there's the code in dbconvert.c and also implemented in URPM.xs
16:37:41 <proyvind> what was necessary when we switched to rpm5 was to switch from using hash tree to binary tree and ordering from little endian to big endian, which the tool took care of
16:39:03 <proyvind> I think rpm.org might even have followed since
16:39:35 <proyvind> for at least one of those changes, I think perhaps both
16:40:21 <proyvind> it's been a while since I noticed, so not entirely sure of
16:41:13 <proyvind> if so, a --rebuilddb might be all that's needed..
16:45:30 <bero> Pharaoh_Atem: have you ever tried a rebuilddb or something similar after switching?
16:45:38 <Pharaoh_Atem> I have not
16:45:46 <bero> Worth a try then...
16:45:47 <Pharaoh_Atem> not recently anyway
16:46:07 <Pharaoh_Atem> the last time I tried, before my hack patches, it choked on the "invalid" data in the rpmdb for scripts
16:46:09 <_TPG> bero: this issues is in 3.x
16:46:43 <_TPG> bero: https://github.com/OpenMandrivaAssociation/glibc/tree/3.0
16:49:24 <proyvind> Pharaoh_Atem: sounds familiar, I don't remember whether I came up with a fix, but if someone sends me a compressed rpm5 /var/lib/rpm/Packages, I might possibly give it a peek..
16:57:55 <_TPG> fdrt: runc-1.0.0-17.rc4.git9f9c962 does not obsoletes  runc-1.0.0-0.rc2.1
16:58:33 <bero> proyvind: http://lindev.ch/Packages.xz
16:58:54 <Pharaoh_Atem> bero: dnf is now pushed (note, like everything else, not built yet)
17:02:54 <Pharaoh_Atem> brb
17:05:37 <proyvind> bero: no errors on 'rpm --rebuilddb' & 'rpm -qa'
17:06:03 <bero> nice! We may have a better option after all...
17:08:41 <proyvind> so for when updating, be sure to update rpm first before proceeding to the rest (ie. like urpmi does) in order to have packages with migrated triggers properly installed
17:11:14 <Pharaoh_Atem> we'll probably want a wrapper script to do a one-time split for transitioning from urpmi to dnf for omdv 3 to omdv 4
17:23:42 <itchka> We will if we don't want to be incredibly unpopular with users
17:24:19 <itchka> bero: Are you on a cooker box at the moment?
17:24:30 <bero> itchka: sure, don't have anything else
17:27:19 <itchka> If you are can you check whether you have  /sys/bus/platform/drivers/sram/queue
17:28:23 <itchka> The bits in udev that set up the scheduler aren't working here because the queue entries are missing,
17:30:25 <itchka> bero: ^^
17:30:53 <bero> I don't have it either
17:32:25 <itchka> Looks like our kernel is missing something. Can you try find . -name queue on /sys and see if it returns queue at all (there should be more than one)
17:34:17 <itchka> /proc/cmdline should have this appended which is supposed to enable it all.  scsi_mod.use_blk_mq=1
17:36:08 <Pharaoh_Atem> bero: I just pushed dnf-plugins-core too
17:36:29 <Pharaoh_Atem> once I do mock, we'll have "theoretically" enough to make this work
17:36:36 <Pharaoh_Atem> the rest can come a bit later
17:40:29 <bero> /sys/devices/pci0000:00/0000:00:01.1/0000:01:00.1/ata6/host5/target5:0:0/5:0:0:0/block/sdb/queue
17:40:29 <bero> /sys/devices/pci0000:00/0000:00:01.1/0000:01:00.1/ata5/host4/target4:0:0/4:0:0:0/block/sda/queue
17:40:29 <bero> /sys/devices/pci0000:00/0000:00:01.2/0000:09:00.0/nvme/nvme0/nvme0n1/queue
17:40:29 <bero> /sys/devices/virtual/block/ram11/queue
17:40:37 <bero> (+ the same for all the other ram* devices)
17:41:15 <bero> scsi_mod.use_blk_mq=1 is set in my /proc/cmdline
17:41:26 <itchka> Then perhaps the udev rules is wrong
17:41:40 <itchka> cd /sys
17:44:31 <_TPG> itchka: what is the problem ?
17:46:46 <_TPG> we have set CONFIG_SCSI_MQ_DEFAULT=y in kernel
17:47:10 <itchka> There's an error showing up in systemd which is prventing the live iso from booting the last entry the I can get by redirecting the journal to the console is a udev failure relating  a file not found error in /sys/bus/platform/drivers/sram/
17:47:30 <itchka> it's look for queue in the sram directory.
17:48:53 <itchka> Reproducible on a hardware install as well as VB
17:49:06 <_TPG> itchka: can you give me some logs ?
17:49:29 <_TPG> itchka: why does 3.03 boot fine, if both uses same systemd and initscripts
17:49:36 <_TPG> ?
17:51:49 <itchka> _TPG: I wish I knew. I can boot the calmares install entry and install and I can boot the live image by supplying an incorrect systemd target and after a ctrld it will boot the default which is the live image and it all works absolutely fine.
17:53:07 <_TPG> itchka: wild guess, things dies on X11 start
17:53:31 <_TPG> itchka: boot iso into multi-user.target
17:53:45 <itchka> I think it must be that because I see sddm start up fromn systemd
17:54:03 <itchka> _TPG: Ok
17:54:07 <_TPG> itchka: guess somethig is wrong with graphical stack
17:55:31 <itchka> Tryimg
17:55:38 <itchka> root
17:56:36 <itchka> startx and startlxqt work fine
17:57:00 <bero> Let's try again when all the qt related rebuilds are done
17:57:11 <itchka> systemctl start sddm works fine.
17:57:38 <bero> smells of a timing issue somewhere then, given systemctl start sddm is exactly what happens on bootup
17:57:51 <itchka> It bizarre
17:59:00 <itchka> Anyway we have a full lxqt iso which installs and with a bit of friggery it will also boot.
17:59:58 <bero> Plasmashell crashes on startup for me (not too worried because I think that is definitely just plugins needing a rebuild after 5.10.1)
18:00:01 <bero> maybe it's the same cause
18:00:05 <itchka> The most bizarre thing about this is if I build the iso locally on my box it works. Somehow something abf does causes it to fail.
18:00:51 <itchka> LxQt has been fully rebuilt against the new stuff where it needed it. It's all sound
18:01:04 <itchka> Everything on the iso works.
18:02:28 <crazy> itchka: for sram you need CONFIG_SRAM=y
18:03:05 <_TPG> looks like glibc segfaults on i586 cooker too
18:03:38 <bero> yes, that's because someone built a newer version targeting i586
18:03:51 <bero> I "fixed" cooker before by manually moving in a glibc built with --target i686
18:04:06 <_TPG> bero how to fix it for "real" ?
18:04:22 <bero> drop i586 and add i686?
18:04:36 <_TPG> bero: :) i mean semi-real
18:04:37 <bero> Other than that, maybe adding -march=i686 to the compiler flags will do
18:04:44 <_TPG> like %ifarch %ix86
18:04:47 <bero> haven't tried anything of that kind
18:05:03 <crazy> itchka: also with CONFIG_SCSI_MQ_DEFAULT=y forget old-style scheduler they do not work .. and won't be fixed upstream to work in mixed mode ..
18:05:21 <bero> and I don't really have the time or motivation to fix something that's easily fixed by just setting the lowest target that still exists anyway
18:10:05 <_TPG> bero|2: well at least somehow we need to keep 3.x running
18:14:33 <itchka> Guys are we about done with cooker?
18:18:37 <bero> just switched to lxqt, works well
18:18:51 <bero> nice change from having a couple of konsoles over a defunct desktop background
18:20:54 <itchka> bero: Just watchout for the qterminal dropdown it's not stable just use qterminal
18:21:30 <itchka> the dropdown exits sometimes for no apparent reason. Especially when you run uromi
18:21:34 <itchka> urpmi
18:22:02 <bero> I never use dropdown terminals in the first place - can't keep enough of them open at the same time
18:22:20 <itchka> I tried to install Konsole  and it kind of works but there's an issue with the cursor.
18:22:47 <itchka> It used to work in LxQt
18:22:50 <bero> konsole works for me
18:23:34 <itchka> Hmm maybe it's a VB foible
18:23:38 <bero> I've seen an issue with konsole a lot earlier, that was related to it somehow not picking the right font (and konsole with a proportional font causes the cursor to go to the wrong place...)
18:23:49 <bero> This might still be "fixed" for me by my config files
18:24:13 <itchka> Ah that might well explain I try changing the font.
18:26:57 <bkeys> https://github.com/OpenMandrivaSoftware/hardware-MACCHIATObin/issues/1https://github.com/OpenMandrivaSoftware/hardware-MACCHIATObin/issues/1
18:26:57 <bkeys> I posted an issue regarding the script to build an image for the MACCHIATObin
18:26:57 <bkeys> If anyone has the time/expertise to give it a look. I don't know much about mandriva
18:28:43 <itchka> bero: ^^
18:36:02 <itchka> bkeys:  I'm not getting tha page
18:36:23 <bkeys> Oh my keyboard pasted the link twice -_-
18:36:28 <bkeys> https://github.com/OpenMandrivaSoftware/hardware-MACCHIATObin/issues/1
18:40:21 <itchka> Hmm
18:41:07 <bkeys> Yeah bero was helping me set up my MACCHIATObin with the bios and all, and I had to rebuild the firmware so I set up a qemu vm of mandriva to run this script on then I got my error
18:41:42 <bkeys> But I picked up an old ATI card today so I should be ready to get a fully working desktop if everything goes smoothly
18:45:12 <itchka> Take a look here in your browser http://abf-downloads.openmandriva.org/cooker/repository/aarch64/main/release/
18:45:56 <itchka> I can see cross-aarch64 binutils binaries. Maybe they have had a name change
18:46:08 <bero> bkeys: Just added a comment on the bug, the script relies on newer tools that are only available in cooker (our development branch, like Fedora's rawhide)
18:46:29 <bkeys> Where can I download your cooker image?
18:47:17 <bero> itchka: I think you have a semi-working one?
18:47:37 <bkeys> bero: Is it possible that you could just upload the firmware you already have built?
18:47:47 <bero> bkeys: sure
18:47:51 <bero> bkeys: just a second...
18:47:59 <itchka> Yes Uou can find one here
18:48:01 <bkeys> It might make sense to include it in the repo
18:48:27 <itchka> https://abf.openmandriva.org/platforms/cooker/products/50/product_build_lists/1870
18:48:37 <bero> bkeys: http://lindev.ch/flash-image.bin
18:48:51 <bero> bkeys: You install it by using bubt from the uboot prompt
18:50:31 <bkeys> Alright minicom'ing into it now
18:51:19 <bkeys> bero: What commands do I run to upload the firmware?
18:52:11 <bero> bkeys: check https://github.com/OpenMandrivaSoftware/hardware-MACCHIATObin
18:52:48 <bero> you need to put it on a tftp server and run "bubt"
18:52:49 <itchka> Guys I have to go I have a meeting tonight and I must eat before I go. bero can you close the meeting when all is finished. ben79 may have some bugs for review.
18:52:56 <bero> set all the variables it complains about
18:53:02 <bero> itchka: sure
18:53:12 <itchka> Thnx
18:53:19 <bkeys> I run the tftp server on my laptop right?
18:53:40 <bero> yes
18:54:32 <bkeys> I have a /srv directory, but not a /srv/tftp/
18:55:01 <bero> Make sure the tftp-server package (or equivalent) is installed
18:55:02 <bkeys> The service itself is up and running though
18:55:17 <bkeys> Yes systemctl status tftp says it's running
18:56:04 <bkeys> https://unix.stackexchange.com/questions/285772/using-tftp-on-fedora-22
18:56:11 <bkeys> Strange, the config file this guy talks about isn't there
18:56:45 <bero> /srv/tftp is the location in cooker, chances are fedora uses another default
18:56:55 <bero> the link you pointed at seems to suggest /tftproot
18:58:45 <bkeys> It's /var/lib/tftpboot for me
18:59:10 <bkeys> So cp the binary there and it automatically knows to upload it?
19:00:04 <bero> yes, sort of...
19:00:18 <bkeys> Alright well the file is in there
19:00:20 <bero> when you run bubt on the board it will scream about some variables not being set
19:00:28 <bkeys> Gonna run env default -a env save bubt
19:00:36 <bero> you have to set them correctly (e.g. point to the ip address of your laptop)
19:00:40 <bero> that's 3 different commands
19:00:42 <bero> first
19:00:44 <bero> env default -a
19:00:45 <bero> then
19:00:46 <bero> env save
19:00:47 <bero> then
19:00:49 <bero> bubt
19:00:59 <bkeys> Ah I thought those were 1 command
19:01:02 <bkeys> ALright one second
19:01:13 <bero> (on the last one you have to watch for the output - it will complain about some variables not being set)
19:01:25 <bero> set them and run bubt again
19:01:51 <bero> I don't remember them off the top of my head and don't have a board to play around with right now
19:02:01 <bero> so have to rely on bubt's output
19:02:06 <bkeys> Yeah I get a
19:02:06 <bkeys> *** ERROR: `serverip' not set
19:02:10 <bkeys> How do I set the variables?
19:02:13 <bkeys> Like what is the syntax?
19:02:55 <bero> setenv serverip
19:03:01 <bero> where is your laptop's IP address
19:04:47 <bkeys> What is ipaddr?
19:05:17 <bero> the IP address you want the board to take -- set it to any free IP in your network
19:07:12 <bkeys> https://8n1.org/12814/daac
19:07:16 <bkeys> I got this output
19:07:26 <bkeys> I don't know what went wrong here
19:08:32 <bero> is the ethernet cable on the board plugged into the right port? The one next to the USB port?
19:08:42 <bkeys> Yep
19:09:20 <bero> Try running "ping" on the board
19:09:23 <bkeys> Given it sees that the file is on the tftp server, this shouldn't be a network issue
19:09:47 <bkeys> ping failed; host is not alive
19:09:51 <bkeys> So that makes sense then
19:10:10 <bkeys> The cable is certainly all the way in there
19:10:45 <bero> try the other ethernet ports, maybe board revision 1.3 changes which one can be used by the bootloader
19:11:32 <bero> also make sure your router (if any) doesn't block the board because it isn't using an IP address assigned by it or something
19:11:43 <bero> some routers can be paranoid
19:11:52 <bkeys> Yeah switching ports didn't fix it
19:12:08 <bero> you can also try to run "dhcp" on the board to get an IP address automatically, haven't tried it but in theory it should work
19:12:10 <bkeys> Can I do this with a usb drive or sd card and avoid the network all together?
19:13:38 <bkeys> I keep getting this
19:13:38 <bkeys> ARP Retry count exceeded; starting again
19:13:38 <bkeys> It did it on the ping commands too
19:16:15 <bero> In theory yes, but it didn't work for me when I tried
19:16:19 <bero> maybe they fixed that though
19:17:12 <bero> The syntax should be something along the lines of "bubt flash-image.bin spi usb" (if it's on a USB storage device)
19:17:26 <bero> or "bubt flash-image.bin spi mmc" (if it's on an SD card)
19:18:01 <bkeys> Let me try that
19:22:43 <bkeys> Ah it only want ext2 filesystems
19:23:02 <bero> should handle ext4 too
19:23:19 <bkeys> I was using fat32 since that is what ARM boards usually like
19:54:16 <bkeys> bero: Yeah SD card doesn't seem to work either
19:54:26 <bkeys> It says it can't find the file. I don't know why
19:54:53 <bero> that's the same thing that happened to me, that's why I went to tftp
19:55:14 <bkeys> Alright, well dhcp didn't work when I ran it
19:55:23 <bkeys> Kinda back to square one on that one
19:55:57 <bero> have you tried booting anything without updating the firmware? Maybe the various issues are already fixed on the 1.3 boards
19:56:17 <bkeys> I tried a hard drive, SD, and a USB drive
19:56:57 <bero> using the right commands in the bootloader to start from those?
19:57:24 <bkeys> What would those commands be?
19:57:26 <bero> e.g. booting from the harddisk should look something like this:
19:57:30 <bkeys> I mean I don't want to minicom everytime I want to boot
19:57:39 <bero> scsi reset; ext4load scsi 0:2 $kernel_addr /boot/Image; ext4load scsi 0:2 $fdt_addr /boot/armada-8040-mcbin.dtb; setenv bootargs $console root=/dev/sda2 rw; booti $kernel_addr - $fdt_addr
19:58:14 <bero> assuming you have a root filesystem on the 2nd partition of the harddisk, the kernel filename is /boot/Image and the DeviceTree filename is /boot/armada-8040-mcbin.dtb
19:58:24 <bero> you don't have to use minicom every time to boot...
19:58:30 <bero> Once you have a sequence that works, you can
19:58:44 <bero> setenv bootcmd 'the boot commands go here...'
19:58:47 <bero> env save
19:59:03 <bero> from there on it will run your boot commands automatically unless interrupted on minicom
20:00:30 <bkeys> Let me examine the partition layout of my hard drive
20:00:46 <bkeys> If I ever need to boot a rescue disk am I gonna have to do all the minicom stuff?
20:01:01 <bkeys> I thought that the mcbin was supposed to have a UEFI, and that this would be point click
20:03:04 <bero> there actually is a UEFI bootloader available (I just don't know anything about it other than the fact that it exists), but it's certainly not point and click
20:03:28 <bero> It just provides the interfaces some distro kernels need to get hardware information
20:03:59 <bkeys> Here is what my partition layout is, I would guess that /dev/sdc4 is the partition I want
20:04:07 <bkeys> That and I probably want to expand it so I have some space
20:10:28 <bkeys> bero: Wouldn't I point it to the boot partition and not the root one?
20:11:15 <bero> bkeys: yes, if you have a separate boot partition you need to point it at that
20:11:51 <bkeys> Your README said that without your firmware that the PCIE slot didn't work right?
20:11:54 <bkeys> What happened there?
20:12:49 <ylyco> hi there
20:14:22 <ylyco> I need some help, on OpenMadriva forum, they told me to join this IRC to discuss about a package issue " webkitgtk "
20:14:46 <ylyco> https://issues.openmandriva.org/show_bug.cgi?id=2312
20:15:13 <bero> bkeys: The memory assignment for the PCIE slot was wrong in the stock firmware on the 1.2 board -- I don't know whether or not they fixed it on 1.3
20:15:24 <bero> ylyco: let me look at that bug report...
20:15:47 <ylyco> bero: fine...
20:17:29 <bkeys> bero: I can break that up in multiple commands, right? Cause it doesn't return when it runs out of room
20:18:15 <bero> bkeys: yes, the semicolons are command separators
20:18:23 <bkeys> Just making sure
20:19:28 <bero> ylyco: I agree with Ben Bullard's comment on the bug report -- There are no 2.4.11-2 packages in the 3.0 tree and I don't know where you got them... So try removing them and going with the 2.4.11-1 packages that actually are there
20:19:28 <bkeys> Gonna figure out the path to the boot image
20:19:42 <bkeys> So gonna write that down then restart this process
20:19:53 <bero> bkeys: you might need to put a custom kernel on it as well, but let's try booting what you have first...
20:20:43 <ylyco> bero : yesterday they were still present, but today they are out of the tree : someone must have erase them
20:20:52 <bkeys> There is a file in the boot partition called vmlinuz-4.11.8-300.fc26.armvhl
20:20:57 <bkeys> That is the boot image, rigt?
20:20:59 <bkeys> right
20:21:24 <ylyco> bero : I installed from scratch with my dvd OpenMandriva Lx 3.03 : and they are indeed inside...
20:24:02 <ylyco> bero : I did the --downgrade, but there were " failures ", and trying to install " devel " package can't install it because of :
20:24:17 <ylyco> bero : The following package cannot be installed because it depends on packages
20:24:17 <ylyco> that are older than the installed ones:
20:24:17 <ylyco> lib64webkitgtk3.0-devel-2.4.11-1
20:34:16 <bero> bkeys: that one is way too old and 32-bit on top of it... Let me upload one that will work
20:35:03 <bero> ylyco: Try going a step further and removing it before installing the devel package... urpme lib64webkitgtk3.0_0, then urpmi whatever you need
20:35:37 <fdrt> _TPG weird
20:36:09 <fdrt> make sure that runc is runc-1.0.0-17.rc4.git9f9c962-omv2015.0.x86_64
20:37:16 <bero> bkeys: Grab http://lindev.ch/Image and http://lindev.ch/armada-8040-mcbin.dtb and put them in the same directory where you found the 32-bit 4.11 kernel
20:37:40 <bkeys> bero: One second I am gonna reflash this hard drive with fedora 27 instead of 26
20:38:08 <bkeys> Wait, so the image I was using is 32 bit?
20:39:01 <bero> yes, if it says "armvhl", that's 32bit with hardfloat enabled
20:39:46 <bero> If it were 64bit, it would say aarch64 instead
20:40:02 <bkeys> Let me find an aarch64 image then
20:41:46 <ylyco> bero : seems good so far, thanks. I have to reboot first, then I'll try to compile wxPython Phoenix
20:42:22 <ylyco> see you guys, good night
20:42:28 <bero> good night ylyco
20:43:02 <bero> ben79: Did you have any bugs you wanted to bring up for the meeting?
20:46:11 <ben79> Um, just a minute.
20:47:09 <ben79> This first one I need someone knowledgable to look at it and tell me if what I told poster is correct
20:47:13 <ben79> Webkitgtk : no package “devel” available in same version
20:47:23 <ben79> https://issues.openmandriva.org/show_bug.cgi?id=2312
20:47:50 <bero> ben79: we just covered that -- essentially your comment was right, just needed to take it a step further
20:48:01 <ben79> OK
20:48:47 <ben79> MTP protocol is not available at OMX LX 3.03
20:48:57 <ben79> https://issues.openmandriva.org/show_bug.cgi?id=2310
20:49:50 <ben79> and I'll stop there as it is getting late for some folks
20:50:13 <bero> Hmm, that's supposed to work
20:50:18 <ylyco> bero : hi again, the rurpme command deleted the " system tools / system configuration ", I can't access to the configuration panel..
20:52:19 <ylyco> bero : wasn't the best idea... is it possible to have the devel package in "...-2.4.11-2-omv2015.0.x86_64 " ?
20:52:47 <bero> ylyco: simply reinstall it -- "urpmi drakxtools"
20:53:16 <bero> I have no idea where that 2.4.11-2 thing came from - I've never seen it
20:57:23 <ylyco> bero : It is present when you install from DVD, and yesterday was present too in the package control center
20:57:59 <ylyco> bero : your friend have to delete it for few hours
20:58:20 <ben79> from what DVD?
20:58:51 <ylyco> bero : OpenMandrivaLx.3.03-PLASMA.x86_64.iso
20:59:54 <ben79> ylyco: what is the number of the ISO they are numbered and it matters
21:01:03 <ylyco> ben79 : sorry, it's not a dvd, it's an iso I downloaded from OpenMandriva website
21:01:46 <ben79> OK, but do you know the number. It is at the top of grub2 menu when you first boot the ISO
21:04:00 <ben79> The Lx 3.03 release for instance was # 1588 for x86_64
21:04:33 <ben79> I want to know if those packages are on that ISO or on one of the weekly spins so I can warn other users
21:04:40 <ylyco> ben79 : BULD ID 1588
21:04:50 <ben79> OK, thanks
21:05:05 <ylyco> you are welcome
21:06:29 <ylyco> one last question : the urpmi drakxtool, didn't install again the usual control panel : I can't reach to launch it, it is missing
21:08:59 <ben79> ylyco: In the terminal where you ran urpme can you scroll back and post the exact, complete command you ran?
21:09:56 <ylyco> ben79 : urpme lib64webkitgtk3.0_0-2.4.11
21:10:05 <ylyco> sorry mistaken
21:10:31 <ylyco> ben79: yes it was this... I not mistaken
21:11:14 <ben79> OK, then it gives a list of what packages it is going to remove
21:11:25 <ben79> can you post those?
21:11:47 <ylyco> ben79 : sorry, I reboot
21:12:13 <ylyco> ben79: sorry, I rebooted the system, and losted the messages
21:12:54 <ylyco> ben79: tomorrow, I can do a fresh new install on VirtualBox, and do it again ?
21:14:01 <ben79> OK, you could use a newer ISO one of our weekly spins from: https://abf.openmandriva.org/platforms/3.0/products/38
21:14:36 <ben79> and that should remove the issue of the lib64webkitgtk package version
21:15:30 <ylyco> ben79 : fine. I'll do that. I'll contact in case the issue remains.
21:16:02 <ben79> Use ISO 1742, I have that one installed so I know it works ,
21:16:45 <ben79> if you give me a minute I'll check and see if it has correct version of lib64webkitgtk
21:17:06 <ylyco> ben79 : ok, I can waite some more
21:19:19 <ben79> ylyco: ISO 1742 has correct version so you should be good with that one. Post on forum if you have any issues
21:19:49 <ylyco> ben79 : perfect. Thanks to you all
21:19:49 <ben79> you can also personal message me on forum to get my attention
21:20:13 <ylyco> good night all... I'm off
21:20:23 <ben79> OK
21:21:42 <ben79> bero: _TPG: The original Lx 3.03 ISO # 1588 does have some webkit/libsebkit packages in version  2.4.11-2 though our repos only have
21:22:19 <ben79> Could or should we rebuild them all to version 2.4.11-3 to avoid any further issues?
21:24:55 <ben79> Otherwise I'm done with AIB, thanks bero and everyone
21:29:46 * bero would prefer to simply nuke anything with gtk in its name, as it's broken in the first place...
21:29:58 <bero> but we should definitely find out how we went backwards, that should never happen
21:30:09 <bero> and I'm not opposed to building a 2.4.11-3 without changes
21:32:02 <bero> hmm... Probably happened while fixing the naming mess with the compat package being unversioned and the new version having a version suffix
21:32:08 <bero> but that was supposed to affect cooker only
21:32:29 <bero> either way can't hurt to just build 2.4.11-3 or even just build 2.4.11-6 from cooker on 3.x
21:41:25 <ben79> OK, that was just my best guess how to get past the issue easily, maybe we should upgrade to 2.4.11-6?
21:43:17 <bero> let's try
21:44:58 <bero> started a build
21:50:20 <ben79> bero: I'll happily test webkitgtk packages but will be in and out. Just point me to  them and I'll get to it soon as I can
21:51:11 <bero> ben79: https://abf.openmandriva.org/build_lists/151736 -- will probably take a while to finish
21:51:20 <bero> (and probably will finish only after I've gone to bed)
21:51:39 <ben79> OK
21:53:15 <ben79> Maybe I won't get to it till tomorrow morning
21:57:18 <bkeys> That is where I am with this ARM stuff
22:04:14 <itchka> back. I didn't expect to find you guys still at it :)
22:18:06 <bero> #endmeeting
22:18:17 <bero> should have done that given we're not still at it ;)
22:18:26 <bero> but it looks like chwido is ignoring me anyway
22:18:31 <bero> probably because he wants to go outside ;)
22:20:50 <bkeys> bero: Is vmlinuz-4.13.9-300.fc27.aarch64 a decent boot image?
22:48:39 <itchka> bero: It's ok I'll do it
22:48:47 <itchka> #endmeeting