[ubuntu-studio-devel] Ubuntu Studio 18.10 fails on Supermicro X7DAE
I reinstalled on my desktop and tried using the normal LINUX kernel rather than the low-latency one. Same problem, very slow operation. My current guess is that the problem may be in my use of the 3ware PCI Express SATA RAID controller since it appears that programs run more-or-less normally once loaded but take a very long time to load or to open new windows. I will next try the most recent XUBUNTU once I get the drive-swapping arrangement fixed. Hardware is a Supermicro X7DAE motherboard, dual quad core Xeon 2 GHz CPUs, 20GB RAM, ATI 5000 PCI-Express video. The on-board Adaptec SATA Raid controller is not supported by Windows 7 which is why I'm using the 3ware controller. 20GB RAM, all ECC and registered. 3ware 9750 4 channel SATA controller with 2 Seagate 2 TB Constellation drives in RAID 1. M-Audio sound card. Operation under 16.04 is normal, as is operation under Windows 7 X64 (system dual-boots using "grub"). UNIXBench output in HTML format is attached. This is for the system running 16, not 18. Nothing obviously odd there. Mike Squires -- Michael L. Squires, Ph.D., M.P.A. 546 North Park Ridge Road Bloomington, IN 47408 Home phone: 812-333-6564 Cell phone: 812-369-5232 www.siralan.org or www.smithgreensound.com UN*X at home since 1985 Title: Benchmark of ubuntu / GNU/Linux on Thu Dec 06 2018 Benchmark of ubuntu / GNU/Linux on Thu Dec 06 2018 BYTE UNIX Benchmarks (Version 5.1.3) Test System Information System: ubuntu: GNU/Linux OS: GNU/Linux -- 4.4.0-140-lowlatency -- #166-Ubuntu SMP PREEMPT Wed Nov 14 21:03:09 UTC 2018 Machine: x86_64: x86_64 Language: en_US.UTF-8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968") CPUs: 0: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (4000.4 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization 1: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (3999.4 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization 2: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (4000.4 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization 3: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (3999.4 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization 4: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (4000.4 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization 5: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (3999.4 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization 6: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (4000.4 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization 7: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (3999.4 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization Uptime: 17:31:58 up 7:24, 0 users, load average: 0.46, 0.65, 0.45; runlevel Benchmark Run: 8 CPUs; 1 parallel process Time: 17:31:58 - 17:56:20; 24m 22s System Benchmarks Test Score Unit Time Iters. Baseline Index Dhrystone 2 using register variables 19173468.8 lps 10.0 s 7 116700.0 1643.0 Double-Precision Whetstone 2104.4 MWIPS 9.9 s 7 55.0 382.6 Execl Throughput 1383.2 lps 30.0 s 2 43.0 321.7 File Copy 1024 bufsize 2000 maxblocks 244825.5 KBps 30.0 s 2 3960.0 618.2 File Copy 256 bufsize 500 maxblocks 66775.4 KBps 30.0 s 2 1655.0 403.5 File Copy 4096 bufsize 8000 maxblocks 568017.9 KBps 30.0 s 2 5800.0 979.3 Pipe Throughput 369606.6 lps 10.0 s 7 12440.0 297.1 Pipe-based Context Switching 80728.6 lps 10.0 s 7 4000.0 201.8 Process Creation 4641.5 lps 30.0 s 2 126.0 368.4 Shell Scripts (1 concurrent) 5322.5 lpm 60.0 s 2 42.4 1255.3 Shell Scripts (8 concurrent) 2158.1 lpm 60.0 s 2 6.0 3596.8 System Call Overhead 305724.6 lps 10.0 s 7 15000.0 203.8 System Benchmarks Index Score: 562.5 Benchmark Run: 8 CPUs; 8 parallel processes Time: 17:56:20 - 18:20:50; 24m 30s System Benchmarks Test Score Unit Time Iters. Baseline Index Dhrystone 2 using register variables 150709347.4 lps 10.0 s 7 116700.0 12914.3 Double-Precision Whetstone 16565.6 MWIPS 9.9 s 7 55.0 3011.9 Execl Throughput 8203.7 lps 30.0 s 2 43.0 1907.8 File Copy 1024 bufsize 2000 maxblocks 357689.4 KBps 30.0 s 2
Re: Anacron/Cron needed by default anymore?
On Tue, 12 Feb 2019 09:59:01 -0800, Bryan Quigley wrote: >Subject: Anacron/Cron needed by default anymore? ^^ Oops, I missed that part :D. You don't want to drop it completely. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Anacron/Cron needed by default anymore?
On Tue, 12 Feb 2019 09:59:01 -0800, Bryan Quigley wrote: >Based on a disco desktop current jobs: >apport - clean all crash reports which are older than a week. >apt-compat - says to prefer the systemd timers >bsdmainutils - BSD mainutils calendar daily maintenance script >cracklib-runtime - make a wordlist for stronger password checking >dpkg - Backup the 7 last versions of dpkg databases containing user >data. logrotate - skips if systemd is installed >man-db - skips if systemd is installed >mlocate - regenerates locate database >passwd - backups passwd group shadow gshadow >popularity-contest - sends package info >ubuntu-advantage-tools - runs status and stores in a cache >update-notifier-common - Try to rerun any package data downloads that >failed at package install time. FWIW https://packages.ubuntu.com/search?searchon=contents=fstrim.timer=exactfilename=cosmic=any https://packages.ubuntu.com/search?searchon=contents=systemd-tmpfiles-clean.timer=exactfilename=cosmic=any Neither for my Ubuntu, nor for my Arch Linux install I need much timers. I'm booted to Arch Linux now, but it should be similar for my Ubuntu install: $ systemctl list-timers --all NEXT LEFT LAST PASSEDUNIT ACTIVATES Wed 2019-02-13 00:00:00 CET 4h 40min left Tue 2019-02-12 00:00:51 CET 19h ago logrotate.timer logrotate.service Wed 2019-02-13 00:00:00 CET 4h 40min left Tue 2019-02-12 00:00:51 CET 19h ago shadow.timer shadow.service Wed 2019-02-13 13:34:46 CET 18h left Tue 2019-02-12 13:34:45 CET 5h 44min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Mon 2019-02-18 00:00:00 CET 5 days left Mon 2019-02-11 00:00:21 CET 1 day 19h ago fstrim.timer fstrim.service 4 timers listed. However, backwards compatibility might be useful for those who make intensive use of individual cron jobs that aren't provided by packages. Should they be forced to redo all the work they already have done? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Backports and a Proposal for Changing the Process
My apologies for a slower reply, been messing with my mail gateways and had to deal with that first. On 2/7/19 11:01 AM, Robie Basak wrote: > Minor comments on some aspects of your proposal below. > > On Mon, Jan 14, 2019 at 04:39:32PM -0500, Thomas Ward wrote: >> Backporting Requirements >> >> >> The uploading of backports is now to be performed by Ubuntu developers. >> The ~motu team >> can upload any backport, and we will request the DMB to extend PPU >> rights to apply to >> all backports pockets too. > I suggest that it might be easier and cleaner to simply say "anyone who > can upload a given package to the development release can also upload > its backport", at least to start with. Assuming we can configure > Launchpad to allow this. I am not in disagreement with this. >> 1) Developers file requests in the regular Ubuntu project, try their >> best to >> ensure that the backport is good (build/install/run test, post in the bug >> confirming this has been done), and upload it to the queue. The "Continued >> Functionality of Reverse-Dependencies" requirement from [0] is to be >> relaxed. >> Each and every reverse dependency need not be tested; the uploader >> should use >> their judgement, which the backports team will need to concur with. >> This requirement >> has been responsbile for making it practically impossible to backport >> anything complex. > Perhaps ask for it to be demonstrated working in some (driver-defined) > PPA and tested from there? Then there'd be a nice progressive procedure > to get a backport landed - so interested parties could be using a PPA > before "graduating" the package to the official backports pocket. > > We might still need to use the backports project though, to avoid > collisions with SRU bug tasks. Driver-defined PPA is going to be a little trickier, I think, here, Robie. Assuming you mean that it'd need uploaded to a 'proposed' PPA like the Security Team has for landing patches, then that'd be locked for uploads to just the Backporters team - we could sponsor/stage such uploads to the PPA, though, but then we're back where we currently started - too many things to upload, not enough manpower to drive it. Even if I were driving this, it'd turn with burnout eventually. >> >> 1.5) People who need sponsoring can perform step 1) and subscribe >> ~ubuntu-sponsors *once there is a debdiff/package on the bug to upload*. >> >> 2) The ~ubuntu-backporters team reviews uploads from the queue and >> accepts/rejects, >> in much the same way as the SRU team does currently. > I suggest that we discuss and then define specifically what aspects of > the upload are the responsibility of the uploader and the backporter > team isn't expected to review. If we agree to cut down on what the > backporter team has to check, then hopefully that will help with > velocity. > >> 3) Any changes to the package which are required for backporting must >> be minor >> in nature or otherwise required, and will be reviewed specifically by the >> Backporters Team prior to backport acceptance. > I suggest we define how to communicate these aspects with the > backporters team, so they don't have to rediscover the changes by a > potentially more time consuming review. This can be a requirement during the backport process. During a backport request, even in the 'current' broken process, we need to make notes about the package and whether any changes are required for building in the backported release. Typically, these'd be determined by the person seeking the backport via PPA testing, etc. and then defined in the backport request. We can possibly do a similar thing here - if no 'changes' are defined and the backport FTBFS in a PPA (such as a staging/proposed PPA like described above or like the Security team has), then reject the backport as-is because it fails to build. Any requests that require changes that aren't defined could be rejected because of FTBFS due to undefined changes necessary to get the package to build. Putting the requirement on defining changes to the individuals requesting/testing would offload that from the Backporters team. This would also be part of the requests process - proof has to be made that the package builds and works in the target backported release with the Backports repo enabled (which as far as I can tell PPAs can be configured to do so). >> -- >> >> An additional point of discussion is that if we can remove 'random end user >> requesting' from the equation, that would also lighten up the backports >> queues. When an end user wants to make a request, they should field the >> request via ubuntu-backpo...@lists.ubuntu.com or a similar mailing list for >> community input on the request; if a developer or sponsor wants to assist >> for that request, then with the revisions to the process above, the >> backport >> process can move forward without major impact to the queue and without >> adding additional major
Re: authbind in platform/supported-sysadmin-common
Thanks for the extra tracking! :) On Tue, Feb 12, 2019 at 10:46 AM Jeremy Bicha wrote: > > On Tue, Feb 12, 2019 at 7:10 AM Andreas Hasenack > wrote: > > while investigating removing authbind from the server-ship seed[1], we > > noticed it's still included via platform/supported-sysadmin-common. I > > tracked this back to 2008 when the file was created already with that > > content, so no particular reasoning was logged in the commit. > > I tracked it back further to > https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=a8d5ac595 > > Ubuntu Server has obviously changed dramatically since 2005 so I don't > think that you need to give much weight to its inclusion back then. :) > > Thanks, > Jeremy Bicha -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: authbind in platform/supported-sysadmin-common
On Tue, Feb 12, 2019 at 7:10 AM Andreas Hasenack wrote: > while investigating removing authbind from the server-ship seed[1], we > noticed it's still included via platform/supported-sysadmin-common. I > tracked this back to 2008 when the file was created already with that > content, so no particular reasoning was logged in the commit. I tracked it back further to https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=a8d5ac595 Ubuntu Server has obviously changed dramatically since 2005 so I don't think that you need to give much weight to its inclusion back then. :) Thanks, Jeremy Bicha -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
authbind in platform/supported-sysadmin-common
Hi, while investigating removing authbind from the server-ship seed[1], we noticed it's still included via platform/supported-sysadmin-common. I tracked this back to 2008 when the file was created already with that content, so no particular reasoning was logged in the commit. authbind has: Reverse depends: * sauce (universe) Reverse recommends: * jetty9 (universe) * tomcat8 (universe) And rdepends[2] shows: authbind * Supported-Sysadmin-Common seed * Server-Ship seed * Reverse Recommends: +- tomcat8 * Extra seed Does anybody know why it's in the supported-sysadmin-common seed, and if it could be removed from there as well? Thanks! 1. https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu/+merge/363001 2. http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.disco/rdepends/authbind/authbind -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
